November 2006 - Project Management - Early Warning Signs
This is a summarized version of an article published in Information Systems Management, Fall 2006. We are delighted to be able to share this article with our readers. We continue to see a strong need for better project management techniques to be understood and used by both business people and IT people.
Early warning signs of IT project failure: The dominant dozen
By Leon A. Kappelman, Robert McKeeman and Lixuan Zhang
The mastery of risk distinguishes modern times from the past: By understanding and measuring risks and their consequences, modern humans no longer perceive the future as a whim of the gods and thereby have been empowered to transform their world.
Strangely, Information Technology (IT) project management — despite the fact that it deals with "modern" technologies — is embarrassingly immature in the mastery of risks.
We see similar recriminating data year after year reminding us that about 20 percent of IT projects are canceled before completion and less than a third are finished on time and within budget with expected functionality; the Standish Group has been tracking this for several years. And if we limit the discussion to larger and therefore riskier projects of 10,000 function points, the cancellation rate more than doubles. Obviously, effective risk management is needed to avoid troubled projects and make aggressive risk taking possible.
The postmortem examination of failed IT projects reveals that long before the failure there were significant symptoms or "early warning signs" of trouble.
A warning sign is defined as an event or indication that predicts, cautions, or alerts one of possible or impending problems. Early warning signs (EWSs) provide an indication of manifesting risks and thereby an assessment of a project’s propensity to future difficulties and failure. Keil and Montealegre (2001) recommend that:
This article contributes to our knowledge about IT project management in several ways.
First, it focuses on early warning signs, instead of general IT project risks. In our study, to qualify as an early warning sign, the event or indication must occur in the first 20 percent of the project’s initial calendar.
Second, this study builds on risks identified from IT project management articles in both the academic literature and practitioner journals, as well as input obtained from experienced IT project managers, to identify the most important EWSs.
Our findings are based on the ratings of 55 IT project managers who participated in our study to rank the top early warning signs. The dozen IT EWSs that emerged as the most important are described in detail in the next section.
IT project risks can be grouped into the three general categories:
Or simply people, process and product risks, respectively. It appears that the EarlyWarning Signs rated highest by our 55 survey participants belong only to the people and process risk categories.
This is not surprising because IT projects almost never fail because of technical causes, despite the fact that people and process problems may manifest technically.
Just like most physical maladies can be traced to behavioral and dietary causes that exploit inherent health risks, the technical ailments of IT projects can be traced to people and process causes that exploit inherent product risks, such as large size, high complexity or novel technology. Nevertheless, these technical risks can be mitigated with proper people and process practices, just like genetic propensities to certain diseases can be mitigated with proper behavioral and dietary practices. Technical risks cannot be eliminated, but they can be managed.
Further, a careful examination of the 17 highest identified risks led to the combination of several of these, yielding a final list of the 12 most influential EWSs. These dominant dozen EWSs are listed below and described in more detail following the list.
The six people-related EWSs of IT project failure center on five not altogether mutually exclusive groups of people: top management, project management, project team members, subject matter experts (SMEs) and stakeholders in general.
1. Lack of
top management support.
In many cases, IT projects get caught up in enterprise politics where there are fundamental disagreements about overall enterprise priorities. In these cases the resources and enterprise-wide commitment required for success are lacking.
Middle managers do not see the project as being important to the enterprise or to their performance evaluations and therefore redirect resources and attention to activities that top management does support.
Weak project manager.
Successful analysts or programmers are sometimes promoted to project managers. However, like sales and sales management, the jobs are fundamentally different.
The project manager has to plan and coordinate many efforts rather than perform the effort. Effort is almost always required from stakeholders and other staff that do not work for the project manager. These factors point to leadership and communication skills as essential for project management success.
"Accidental" project managers that do not have or cannot apply solid leadership and communication skills cannot realistically be expected to deliver the promised project scope, reliability and performance on time or on budget.
stakeholder involvement and/or participation.
If all relevant stakeholders are not engaged and committed to project success, it is just about guaranteed the project will not get the resources and attention required to deliver the promised project scope on time and on budget.
If key project stakeholders do not participate in major review meetings, it signals they are not engaged in the project and therefore the project is not a high priority for them. Other stakeholders soon begin to disengage too.
The project manager then finds it harder to get the participation and resources necessary for project success, especially from those who are not full-time members of the project team. Often such project team members get reassigned to other projects that are perceived to be more important. However, the project scope and due date remain fixed. The project falls into a death spiral.
Important projects have and keep the attention of major stakeholders.
commitment of project team.
Project team members with a weak commitment to the project scope and schedule can always find other worthwhile activities to work on. Sponsors may have imposed unrealistic budgets or schedules. The project team may not have the skills and resources they know they need for success. The project objectives may be counter to a project team member’s personal interests.
Regardless of the reason, weak commitment to success is just about certain to result in being late, going over budget and/or not delivering the promised scope.
5. Team members
lack requisite knowledge and/or skills.
If the needed skills aren’t there to start with, then project management needs to make sure they are acquired.
matter experts (SMEs) are overscheduled.
SMEs that are not allowed to dedicate adequate time to project teams are a clear EWS of IT project failure.
The six process-related EWSs of IT project failure center on five project management processes and their associated deliverables that are essential to success: requirements (including a business case), change control, schedule, communications and resources.
7. Lack of
documented requirements and/or success criteria.
Asking for sign-offs on requirements documentation forces differences in expectations and assumptions to the surface where they can be resolved.
If everyone is not pulling the oars in the same direction, the project is going to founder.
Projects with undefined success criteria by definition cannot succeed.
Stakeholders who must provide resources and support for the project will not do so, or will soon withdraw those resources, if the objective and benefits have not been articulated.
A project with undefined success criteria is doomed to disappoint.
8. No change
The team can declare that "requirements are frozen" at the start of the project, but in the real world, they change anyway. Competitors change, business processes change, regulations change, laws get passed, market opportunities change, technology changes and senior management changes.
Perfect requirements from six months ago are no longer perfect.
As ice hockey great Wayne Gretsky says, "You have to skate to where the puck is going to be."
Change is inevitable, so every project must have a process to manage change.
schedule planning and/or management.
If project milestone deliverables and due dates are not documented, there will be multiple opinions about what needs to get done and when. A project team must understand and agree on what short-term tasks must be accomplished to get to the long-term objectives. Various skills and resources are needed at different times. Later, tasks often depend and build on the successful completion of earlier tasks.
Completing a project on time requires that all the project team members have a consistent understanding of the intermediate milestones, deliverables and due dates that must be met to reach the overall objectives. Similarly, no status reporting process means that no stakeholder or team member has a way to know if tasks are on schedule or late. Because later tasks depend on the completion of earlier tasks, a project that does not know its status has no realistic chance of being completed on time or on budget.
A project needs to be estimated from the bottom up by determining what steps depend on prior completed steps and then estimating the time required for each step. The bottom-up schedule needs to be reconciled to the top-down project schedule.
Although some tasks might be able to be done in parallel, there is some minimum amount of time the project will require. An arbitrary project deadline can ignore this minimum project time, but that does not mean it can be done in less than the required minimum.
Another schedule-related EWS is when early project delays are ignored. One might expect that the first 10 percent of the project would be the smoothest part because initial tasks should be known, well planned and not affected by problems from earlier tasks. Short-term assumptions should be quite accurate and change has not had time to occur.
However, if the project kicks off late, planned resources are not committed on time, or other immediate delays occur, then it is illogical to expect that later tasks will go as planned or be completed earlier than planned to "make up the difference."
Communication breakdown among stakeholders.
If all stakeholders do not communicate and work together on an ongoing basis, the project team will be pulled in multiple directions. If consensus on project success criteria is lost, there may be little hope of completing the project on time and on budget, or perhaps of completing it at all.
assigned to a higher priority project.
12. No business
case for the project.
Projects with a clear business case will typically get resources and management attention. The exception is "save the enterprise" projects, where survival is at stake and the enterprise will follow through with the project regardless of any economic business case.
Successful IT project management is critical to enterprise success and to the career growth and success of participating executives, project managers and project team members. This study identified a list of early warning signs of IT project failure, from which a dozen EWSs — or IT project risk factors — were found to be the most important during the first 20 percent of an IT project.
Knowing about and paying attention to these EWSs — the earlier in the life cycle of a project, the better — increases the probability of successful project outcomes.
Some projects should be stopped, because circumstances have changed or it was a bad idea to start with and these EWSs can also help identify those situations before they become project "death marches."
Just as we notice the warning lights and gauges on the dashboards of our automobiles, paying attention to these Early Warning Signs during our project journey can help us avoid problems and successfully reach our destinations.
LEON KAPPELMAN is a professor of information systems, director emeritus of the IS Research Center and a Fellow of the Texas Center for Digital Knowledge at the University of North Texas. His project management consulting includes the White House and United Nations. His e-mail is kapp [at] unt.edu.
ROBERT MCKEEMAN is an IT project management consultant and speaker with more than 20 years of experience. He has an MBA from Harvard Business School and is Project Management Professional #2130 with the Project Management Institute.
LIXUAN ZHANG is an assistant professor in the School of Business and Economics at the College of Charleston.
© 2006, Auerbach Publications, all rights reserved. Summarized from a detailed article published in Information Systems Management Fall 2006 edition. Used with permission of the authors and Auerbach Publications.
Related newsletter articles:
About our resource links: We do not endorse or agree with all the beliefs in these links. We do keep an open mind about different viewpoints and respect the ability of our readers to decide for themselves what is useful.
Page updated: October 05, 2013
| Barbara Taylor | Books |
FAQ | Feedback | Interesting Links
| Mailing List |
| Barbara Taylor | Books |
FAQ | Feedback | Interesting Links
| Mailing List |