Twelve early warning signs of IT project failure

Twelve early warning signs of IT project failure

Summary: Managers often express surprise upon learning their project will run late or over-budget. Nonetheless, we frequently ignore early warnings signs that indicate a project faces trouble.


Managers often express surprise upon learning their project will run late or over-budget. Nonetheless, we frequently ignore early warnings signs that indicate a project faces trouble.

For an academic article on this subject titled Early Warning Signs of IT Project Failure: The Dominant Dozen, two researchers collected data from 19 experts and 55 IT project managers. The researchers discovered an important lesson: "signi?cant symptoms or 'early warning signs' of trouble" often are present long before a project actually fails.

The article describes twelve warning signs, divided into people-related risks and process-related risks:

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

  • No business case for the project
  • 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

Continued high rates of failure suggest that most organizations ignore these early warning signs. While we can speculate why, one fact is clear: enterprise software buyers are well-advised to recognize potential failure earlier in their projects.

Writing on precisely this topic, CIO advocate Chris Curran, discusses several methods for detecting "weak signals" that indicate downstream problems:

[M]aybe we are ignoring some fundamental, but less obvious signs that our projects are not positioned for success.  These signs, or weak signals, require different mindsets and toolsets to gather, track and act upon.

In my view, we cannot overstate the importance of listening carefully to uncover early warning signs of risk.

Does your organization do a good job detecting the weak signals of impending failure?

Image from iStockphoto

Topics: CXO, Enterprise Software, Security, IT Employment

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • After many years as a project manager

    Ignoring the warning signs is usually not an oversight, but an intentional act. There is always some motivation to discount a warning sign, or cover it up. Organizational failures in assigning responsibility and accountability is one of the earliest warning signs of all. So is underfunding and understaffing. You might consider these to be pre-project warning signs, since these problems occur even before the project kicks off in most cases.
    terry flores
  • Beware the "fine"

    Failure follows when anyone uses the term "fine". How is that server build coming along? "fine". Should we invest more time in that security module? No, it will "fine".

    I have found that "fine" never really means what you think it means. Never accept it as an answer - always follow up!
    Roger Ramjet
  • Warning signs?

    Several of the items listed, like 'weak project manager' and 'team members lack knowledge' are hardly warning signs - they are the kind of things that you realize AFTER the project has failed. How many companies start up a project intentionally with a weak manager as leader and team members who don't know what they are doing?
    • Answer: many do

      @dbsteele@... I understand your point, but in my experience there is always prior knowledge that either a manager is weak and/or some team members lack requisite skills, experience, or proper attitude. It may not be senior management who knows this, but someone does. Often someone who could make a difference, but lacks the fortitude to do it.
    • RE: Twelve early warning signs of IT project failure

      @dbsteele@... I agree that these two items are often found in the project's postmortem analysis, though not always. I have been involved in projects where these specific two items where boldly identified in the PRE-project SWOT analysis. Still, management decided to forge ahead as-is despite all of the, not just warning, but blaring DANGER signs. As Roger mentioned, the typical dismissal of the risk is that "we will be fine".
    • Human Nature

      @dbsteele@... In a webinar given by Carl Pritchard, he stated that people don't voice the risks they see because they feel that voicing it makes the risk more inevitable to occur, and they don?t want to be seen as a naysayer or not a team player.

      He also said that organizations typically don?t take action even if risks are identified, until the buzz saw hits. Usually, by that time, the project is in the hands of the powerless (project team or end-users) and all they can focus on is to keep the ship from going down.
      • Completely true in today's management system

        @elizab There is absolutely no reward to anybody who points out problems to management, even if the problems are blindingly evident. In fact the person speaking up will not only be labeled a naysayer, they will often be saddled with resolving the problem without assistance or resources. It's a no-win situation.
        terry flores
  • An understanding of IT software project budgets vs. other domains.

    John V. Karavitis Project management in any domain is going to have to face the budgeted time and cost issue. All the points listed above are very important, yes. But in the IT world, you're traveling uncharted territory, regardless of how well everything has been "planned out" beforehand. Wiring a software program is different than having an architect plan out a building. Construction is pretty much an established science, software writing still qualifies more as an art. Thus, when you have corporate cost and time limitations on software projects, these are more "artificial" than would be the case for building a new skyscraper. I propose, as an example, the Windows operating system for PCs. In a sense, it's been an ongoing project for decades, and, from recent news, still full of bugs. Perhaps the best way to "budget" for software projects is not a formal budget that tries to predict the future, but rather a "rolling forecast" based on established milestones. At each milestone, the remainder of the IT project is re-evaluated from scratch. John V. Karavitis
    John V. Karavitis
  • Honesty works here...

    When in project meetings, it is best to say with full honesty, "Such-n-such isn't going well. I need some help addressing this right away." Obviously some things are beyond control. But what you can control, you must.
    • The real world of IT project management

      @andy.hefty@... Hi Andy. When you have a signed contract with a client, the emphasis is on doing what has to be done to get in under time and budget. Your position is the correct one, but in the real world, ignored due to corporate greed. John V. Karavitis
      John V. Karavitis
  • Want Project Success? Learn Team Building....

    The quickest way to both the financial bottomline and a successful development project is "Team Building" ... "Team Leading" ... "Team Reward". The Senior Team Leader (Project Manager) can only be as effective in creating results as the manager above him/her is in providing effective guidance and support. Badgering a Team Leader into submission breeds deception, lack of motivation, and lack of creative problem solving. Some very smart, very skilled people can and typically do make some very critical and unavoidable process errors, costing time, money and rob everyone's creative energy when they are improperly "handled."

    Dr. Raymond C. Rask
  • Qualified Project Managers

    The good news is that PMP certification is being looked at more and more in the IT field:

    So perhaps better days are ahead for the field of IT project management.
    • RE: Twelve early warning signs of IT project failure

      @ParrotHead_FL The only problem with that is that there are companies that teach and train the "managers" the way to pass the PMP test. So you ask how do I know this? Our last CIO was making it a mandate that everyone pass a PMP on the IT Team. ( ~ 80 - 90 people we are a small shop for a worldwide company of ~3500). They take classes totally designed to pass the PMP Cert. We have 20 of them, and I can tell you right now most would be considered "weak". There are better project managers here that are not PMP certified.
      • RE: Twelve early warning signs of IT project failure

        @ItsTheBottomLine: That can be said of most every certification, unfortunately. Still, it's hard to study for the PMP exam--even in a crash course--and not come out learning something beneficial.
    • Only if Project is Defined to Succeed at the Front End

      @ParrotHead_FL ... Project management methods and tools are very effective when the issues are execution issues. But most projects that suffer major problems are flawed either due to flawed project mission, or optimistic project requirements and definition.
      • Project Management Methodology

        @elizab: Standard project management methodology calls for the project manager to be selected first, during the initiation process group. Through the initiation and planning groups, the PM's job is to ensure that the project mission, requirements, and definition are all feasible. If they're not, it's ultimately the PM's fault because that's where the buck stops.

        At least, that's the ideal situation--it assumes that project management methods and tools are used fully and correctly. In reality, this often doesn't happen. That's not a reflection on flaws in those methods and tools, though; it's a reflection of flaws in the organization that fails to use them.
    • RE: Twelve early warning signs of IT project failure


      I am truly hoping that you just left out the word "skeptically" in your sentence (as in "PMP certification is being looked at more and more skeptically in the IT field"). The IT world probably has 10x the concentration of PMPs of any other profession, even defense tech, and they tend to be people who deeply believe what they read in the PMP manuals. Then go on to create the largest disasters imaginable.

  • Essential article, indeed

    The referenced academic article is absolutely essential reading; thanks for this post, Michael.

    To respond to the comment above, I honestly don't see PMP certification as solving these issues (although it's helpful, without a doubt). About half of the issues (indeed, ones that I'd consider to be more "prime mover" in nature) are issues for senior management: things like stakeholder involvement, management commitment, team makeup, etc. We've got to fix the problems at the head.

    I'd also point to what I call the "big project psychologies" that settle in and prevent the detection of these issues: things like wishful thinking, denial, gridlock, moving the goal posts, etc. I've written on these here: "The IT Project Failure dilemma: how to get early warnings" at
    Peter Kretzman
    • RE: Twelve early warning signs of IT project failure

      @Peter Kretzman... Well put. What you refer to as "prime mover" stuff is really foundational to any IT-backed initiative or project. The human dynamics adds complications to addressing the situation.
  • RE: Twelve early warning signs of IT project failure

    > Lack of top management support
    > Weak project manager
    > No stakeholder involvement and/or participation

    I would say rather:
    * No involvement by _managers_ from the groups that will be actually using the technology (managers being defined as people with the responsibility and authority to allocate personnel, manhours, and dollars, and to directly affect promotions and firing.
    * Use of the "project manager" model of organization, instead of the "real manager" (see definition above). It is beyond me why any organization thinks that putting a person with no real authority as the "head" of a project and telling him to "use his indirect influence" will accomplish anything. Read Joe Sutter's book on designing the 747: he had to use his political skills and influence, but he also directly _managed_ 3000 people!