November 2006 - Project Management

November 2006 - Project Management - Early Warning Signs

Early warning signs of IT project failure; Dominant Dozen Early Warning Signs of IT Project Failure; People-related Early Warning Signs; Process-related Early Warning Signs; Resources (links, books, articles, the lighter side)
Printer-friendly version

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 postmortem examination of failed IT projects reveals that long before the failure, there were significant symptoms or "early warning signs." This article describes the top 12 people-related and project-related IT project risks, based on "early warning sign" data collected from a panel of 19 experts and a survey of 55 IT project managers.

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: Red flag graphic

At the earliest possible stage, managers need to ask themselves whether any "red flags" . . . are serious enough to warrant project termination or significant redirection. By institutionalizing such an early warning system, organizations can save considerable sums of money simply by identifying failed projects while they are still in the early stages of development.

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.

The Dominant Dozen Early Warning Signs of IT Project Failure

IT project risks can be grouped into the three general categories:

Social subsystem risks
Project management risks
Technical subsystem risks.

Or simply people, process and product risks, respectively. It appears that the Early Warning 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.

PEOPLE-RELATED RISKS

Lack of top management support
Weak project manager
No stakeholder involvement and/or participation
Weak commitment of project team
Team members lack requisite knowledge and/or skills
Subject matter experts are overscheduled

PROCESS-RELATED RISKS

Lack of documented requirements and/or success criteria
No change control process (change management)
Ineffective schedule planning and/or management
Communication breakdown among stakeholders
Resources assigned to a higher priority project
No business case for the project

People-Related Early Warning Signs

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.
It is not surprising that this is the top-rated EWS because employees tend to focus on activities that their management deems important. Potentially problematic projects include those that get started "from the bottom up" and departmental projects that do not have the required support from across the enterprise.

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.

2. Weak project manager.
Project managers who cannot effectively lead or communicate pose a serious risk.

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.

3. No stakeholder involvement and/or participation.
Any project of significance has a number of stakeholders. These stakeholders have to contribute resources if the project is going to succeed and often have to take away resources from lower priority activities to do so. There are always more demands for resources than there are resources available.

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.

4. Weak commitment of project team.
Delivering the originally promised project scope with high quality, on time and on budget requires hard work and hard choices.

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.
More than the other people-related EWSs, this risk directly addresses the team’s ability to mitigate product-related risks, such as novel technology or complexity.

If the needed skills aren’t there to start with, then project management needs to make sure they are acquired.

6. Subject matter experts (SMEs) are overscheduled.
It is unrealistic to expect SMEs from the participating business units to be able to provide guidance and requirements to the project team if they continue to retain all their full-time operating responsibilities and workload. Yet success is impossible without the requisite knowledge that only these SMEs can provide about business processes, data, timings, objectives and rules.

SMEs that are not allowed to dedicate adequate time to project teams are a clear EWS of IT project failure.

Process-Related Early Warning Signs

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.
If functional, performance and reliability requirements are not documented, then each project team member and stakeholder inevitably will have different expectations and assumptions about the project, because each participant is working from a different mental blueprint.

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 control process.
From a database of more than 10,000 IT projects, Jones (1995) reports that requirements change at an average rate of 2 percent per month.

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.

9. Ineffective schedule planning and/or management.
Project scheduling processes showed up several times in our study and these were combined into one of the dominant dozen. Every journey consists of many steps.

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."

10. Communication breakdown among stakeholders.
Any significant project has multiple stakeholders and requires an ongoing choreography of various tasks and resources. Change over the life of the project is inevitable — business environment, competitor strategic and tactical moves, laws and regulations, management team, staff turnover, resource availability, and cost — to name just a few possibilities.

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.

11. Resources assigned to a higher priority project.
If resources planned for the project get reassigned to another project it is unrealistic to expect the short-changed project to be completed as planned. The only way this could occur is for the remaining resources to be utilized far more productively than planned. However, this is highly unlikely if the project was estimated on a "best-case" productivity basis to generate as high an ROI or payback as possible in the first place.

12. No business case for the project.
No documented business case for a project is closely related to the top people-related and process-related risks: lack of top management support and lack of project success criteria.

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.

Conclusion

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.

Authors

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.

Internet Resources

Project Management Institute www.pmi.org
Computerworld Magazine - Project Management Resources
CIO Magazine www.cio.com
Project Leadership Resources http://projectmanagement.ittoolbox.com/topics/t.asp?t=311&p=311&h1=311
Six Sigma resources http://www.isixsigma.com/library/content/six-sigma-newbie.asp
Business balls http://www.businessballs.com
Project Failures http://projectfailures.com
TechRepublic Project Management resources http://builder.com.com/5173-6315-0.html
McGraw Hill Education: Leadership Development http://answers.mheducation.com/management/leadership/leadership-development

Books - Disclosure: We get a small commission for purchases made via links to Amazon.

Project Management Tool Kit, The: 100 Tips and Techniques for Getting the Job Done Right. Tom Kendrick. American Management Association, 2004. ISBN: 0814408109
eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility. Douglas DeCarlo. Jossey-Bass, 2004. ISBN: 0787974099
A Guide to the Project Management Body of Knowledge, Third Edition (PMBOK Guides). Project Management Institute, 2004. ISBN: 193069945X

Articles

Early warning signs of IT project failure: The dominant dozen http://www.ism-journal.com/ITToday/projectfailure.pdf ()
Cutting Your Losses, M. Keil and R. Montealegre, MIT Sloan Management Review http://sloanreview.mit.edu/smr/issue/2000/spring/4/
When Failure Is Not an Option http://www.cio.com/archive/060106/ag_edwards.html
Project Planning: Fuzziness = Failure http://hbswk.hbs.edu/archive/3631.html
Your Mission, Should You Choose To Accept It: Project Management Excellence http://spatialnews.geocomm.com/features/mesa1/
IT project failure is rampant – KPMG: When will we ever learn http://www.theregister.co.uk/2002/11/26/it_project_failure_is_rampant/
Project management failure -Why projects fail http://www.databasedesign-resource.com/project-management-failure.html
Project Management Tips: How to be a good Project Manager http://www.anandnatrajan.com/FAQs/ray/PM/ProjectManagement.html
Office Discipline: Why You Need a Project Management Office http://www.cio.com/archive/070103/office.html
The Money Pit http://www.cio.com/archive/120100/pit.html
Why Wait Do Project Retrospectives Midstream.
Process skills most important to successful project managers
Project Management 101 http://management.about.com/cs/projectmanagement/a/PM101.htm
Lack of IT Skills = Job Burnout
Leadership development tips http://www.businessballs.com/leadership.htm
Taming a Wild Vendor http://projectfailures.com/blog/2006/5/10/interview-barry-j-brunetto-on-taming-a-wild-vendor.html
Recognizing Project Warning Signs http://www.esi-intl.com/public/publications/122003executivewarningsigns.asp
See You in Court http://www.processimpact.com/articles/court.html
How to Cause Information Technology Disasters http://faculty.washington.edu/ocarroll/infrmatc/managing/howto/
Top 10 Warning Signs of Problem Vendors http://www.michbar.org/journal/pdf/pdf4article550.pdf
Project Purgatory: Nine Project Warning Signs and What Can Do About Them http://www.pmiolympia.org/programs/purgato.pdf
Several Articles "Why Projects Fail" http://www.stsc.hill.af.mil/CrossTalk/2006/06/index.html
Evolving The Project Management Office: A Competency Continuum http://www.auerbach-publications.com/dynamic_data/3186_1937_PMO.pdf
Early Warning Signs of IT Project Failure
Identifying and Rescuing Runaway Projects http://www.caseygrp.com/pdf/RunawayProjects.pdf
Avoiding IT Disasters the Expert Way http://www.itsecurity.com/security.htm?s=1313

The Lighter Side

Suspicion, Secrets and Stupidity (Computerworld Magazine)
Tom Peters Company www.tompeters.com
personality styles, types, theories and psychometrics models, personality tests and quizzes theory
Project Management Proverbs http://www.project-training-uk.freeserve.co.uk/index.htm
Project Management Truths http://www.project-training-uk.freeserve.co.uk/page1.htm
Project Management Laws http://www.project-training-uk.freeserve.co.uk/page2.htm
You and Your Boss: The Subtle Differences http://www.withfriendship.com/jokes/manager/the-differences.php
Manager jokes http://www.joblatino.com/jokes/managers.html

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.

If you have comments about this month's topic, please let us know or take our newsletter survey. If you would like to receive free notices of the new monthly topic, please sign up for our mailing list. See our Privacy Policy.

This page is http://www.itstime.com/nov2006.htm Printer-friendly version

tr>