12 characteristics of doomed projects

12 characteristics of doomed projects

Summary: Can you recognize a failing project zombie before it's too late? Although there's no simple or easy answer, the failures do tend to share certain common traits.

TOPICS: IT Employment, CXO

 12 characteristics of doomed projects

Can you recognize a failing project zombie before it's too late? Although there's no simple or easy answer, the failures do tend to share certain traits.

Adapted from Project Smart, here are 12 attributes of bad projects:

  1. Doesn't meet expectations
  2. Lacks change management processes
  3. Lacks project sponsorship
  4. Insufficient resources or budget are available
  5. Team doesn't report or escalate critical problems quickly
  6. No risk planning
  7. Schedule delays and missed commitments are rampant
  8. Project is over-budget with no end in sight
  9. Low morale is a problem
  10. Uncontrolled scope creep abounds
  11. Project direction and end-game aren't clear
  12. Showstoppers haven't been identified

There are a zillion reasons why IT projects collapse, most of which boil down to an ugly set of organizational or political issues. Denial, fear of communicating bad news, and related loveliness are usually the underlying culprits.

If this list describes your project, perhaps it's time to consider serious intervention. If so, read about rescuing software train wrecks.

Topics: IT Employment, CXO

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
  • RE: 12 characteristics of doomed projects

    Incorrect assessment as original work when it's been done many times before. Most probably on mainframes decades ago.
  • Doomed projects are usually lacking in two key elements...

    1st) there is typically insufficient communication between the developers and the prospective end-users, and 2nd) the requirements specification was set by some clue-less manager and not by those who actually *do* the job you are attempting to automate or support.

    Either of these kill any chance the project may have had to succeed.

    Managers seldom have any idea what their team *really* does to get things done, and instead focus instead on how their MBA college textbook says it is *supposed* to be done. The fact that these two are often *not* the same process seems to elude them.

    The developers work from this specification --and if they don;t have good communication with the proposed users -- are unaware of what steps are really part if the task. Lack of communication means they never hear back from the users that the solution doesn't address their true process... and they keep trying to fix a problem which may not even exist while remaining unaware of the ones that do.

    Meanwhile, the poor end-users simply circumnavigate the new system and complete the process manually.

    In the end, no-one wins. The project fails, the managers look like idiots, and the employees have twice the work in order to be half as productive.

    After more than 25 years in the business, I'd say it all comes down to effective communication.

    Just my two US cents, however little our currency may be worth today...

  • RE: 12 characteristics of doomed projects

    Having audited numerous projects, the above indicators are good ones if by "Project direction and end-game aren???t clear" you mean that their is no spec or reasonably complete working prototype. Very frequently the "reward" for blowing the whistle on a project in trouble is to be sent in as a white knight to "fix" the problem. I do not ever recall being asked by management to audit a project where the result was positive. Some project managers disregarded the mythical man month rule and thought that adding people would complete the project on time rather than making the project later. Sometimes the addition of a really key skill does shorten the project delivery time eg someone who knew the older product being replaced extremely well.

    Typically I am talking about neither small nor huge projects but projects in the 50 to 200 person year range.

    One project I audited had fellow auditors who believed they had a magic bullet to fix an impossible situation since the existing product was not understood by any living mortal. As I recall the 3rd, 4th and 5th line management who pushed this new solution ended up with jobs that had no meaning and eventually they quit. Important customers for whom the project was intended were golf buddies of the country president of our company and gave him an earful.
  • RE: 12 characteristics of doomed projects

    One thing I don't see on this list is problems with the appropriate level of project governance. I have seen a couple of projects take fatal wrong turns because decisions were being made by high-level managers who didn't understand the requirements.

    This is sort of the opposite extreme of #3 (Lacks project sponsorship) - cases where what should be project sponsorship turns into micromanagement and interference, and the project leader doesn't have full authority to lead.
  • I am always surprised about this type of article

    About 50% of all projects 50% of the time are in failure mode, even with all the hand wringing and project management tools we still can't reliably reproduce project success. Maybe some time in the future people will be able to punch out successful projects like a machine shop makes widgets, but until then people constantly run in circles over this issue.

    The closest comparision to what project managers do in software is in the construction industry when it comes to complex building like a skyscraper. Even worksite supervisors however have much the same issues and they have dealt with most of them better. In my opinion construction can do this because they don't have to deal with the problems with kid gloves.

    In construction, problems are dealt with ruthlessly, probably a side effect of working with blue collar workers rather than white collar workers, however they usually do better in construction.

    Bottom line is that constuction has been around since the dark ages and before so managers in construction have more historic solutions to choose from. When software gets to this level of maturity in the future I dare say software project management will be better.

    Until, then, particularly if you are a consultant EXPECT that everything is on the verge of destruction and you will do OK. All these articles with the hyperventilated slant don't help, except maybe to ward off new people. Focus on defeat and you will find it.
    • So, ignore the problem?

      Let's bury our head in the sands, wring our hands together, and then moan collectively.

      No, until failure rates improve, I'll continue bringing the so-called "obvious" issues to the foreground.
  • RE: 12 characteristics of doomed projects

    Thanks for the list Michael. I agree with your contention that we should continue to focus on these issues until they become the exception instead of the norm. I would like to add to your suggestion to use the list to trigger intervention. This intervention is twofold. First, the intervention required to decide whether to kill or fix the project followed by the appropriate tactical response. Second, the intervention required to address the insufficient project and portfolio governance that continually creates this situation. As challenging as it is save the effort, it is a far greater challenge to establish the governance that reduces the need to do so.

    Steve Romero, IT Governance Evangelist
    Steve Romero