After Hours

10+ things that can send an IT project off the rails


Depending upon the unique aspects of a situation, a multitude of reasons can cause a project to go out of control. Here are some of the most common risk factors.

Note: This list, which is based on the article "How to identify a failing project" by Jason P. Charvat, is also available as a PDF download.

#1: Sloppy requirements

Every project depends upon solid user requirements being firmly locked down prior to any work being undertaken. Failure to do so is a leading cause of project failure. Somehow, the trend is that many project teams think they can get started by rushing the requirements-gathering phase. These projects are then eagerly started with incomplete requirements. If you are developing a project using a standard waterfall methodology, any incomplete requirements will have both a negative cost and schedule impact on the project. On iterative development projects, user requirements are still of utmost importance, but they can be negotiated ahead of any actual development.

#2: Schedule slippage

Many times, project schedules spiral out of control when dates and deliverables aren't aggressively monitored and tracked on a daily basis. All too often, managers leave issues unresolved for days, which then results in schedule overruns. I recommend that that you check project schedules daily.

#3: Budget overrun

Projects that run over budget are sometimes more prone to being canceled because senior executives are concerned about cash going into and out of company coffers. If a project starts showing gradual cost overruns, it's often still given a chance. But as the losses mount and show no sign of recovery, canceling the project may be necessary. In reality, though, some projects are so critical to business survival that they can't be stopped. Therefore, the cost overruns are simply absorbed or skillfully transferred elsewhere. This means that project managers must manage their actual budgets against the planned budget and keep their stakeholders aware of any deviation.

#4: Scope creep

When clients insist on ever-increasing changes to the product being developed, scope creep can jeopardize the project. I don't know of too many project managers who can handle too many changes all at once. An even more difficult situation for a project manager surfaces when new changes are introduced after the project has been launched. This usually drives up the cost, resource requirements, deliverables, and completion time. Scope creep needs to be managed and the project manager needs to have a change control process in place to assess the impact and cost of the change and, possibly, negotiate the change for a future release.

#5: Poor planning and estimation

Those projects that are poorly estimated and planned tend to fail both in cost and schedule, which eventually causes the overall project to fail. Managers tend to start projects without relying on proper analysis and sizing and fail to consult subject matter experts or cost estimators to validate how much project work packages will cost.

#6: Poor documentation

Maintaining inadequate project documentation is cause for concern and should raise the red flag. Lessons learned from many failed projects reveal that there was too little documentation to adequately describe the project in its broader terms and serve as a clear communication channel.

#7: New technology

Projects that require integrating new tools and deploying new vendor applications/devices are always far more difficult because usually, only the vendor engineers clearly understand the limitations and functionality of the products. This results in delays in project schedule and could require weeks or months before the products are stable enough to be deployed. If a project is undertaken using new technology, managers should be aware of the associated risks and plan their schedules accordingly.

#8: Poor communications

One of the biggest reasons why any project goes bad is due to a lack of communication. I have seen many projects fail simply because no one understands what to do and receives no communication regarding current progress. Inevitably, this results in project failure.

#9: Poor decision-making

Decisions that aren't made at all and decisions that are delayed due to second-guessing are both risk factors. In addition, some decisions are so turned out-of-context as responsibility for them is passed down the line that they end up being made based on faulty information. This doesn't bode too well for any critical project.

#10: Poor project management

The person managing the project may not have the skills or experience to pull it off. Yes, any project can be stuck with a lame duck manager. In such cases, it may be necessary to stop the project, replace the project manager, make the necessary adjustments, and start again. The departing manager should be given the option to provide his/her version of the story, though, before moving on.

#11: Poor testing

A big culprit on any project is having either too little testing or, in many cases -- if a test team is involved -- testing too late in the process. Both testing and quality assurance need to be built into the project from the day the project is launched.

11 comments
PMPsicle
PMPsicle

Interesting list. However, it does seem to be primarily based on killing a project which would have succeeded. The problem of course being that studies have shown that the majority of project failures occur prior to any of these issues applying. The construction industry has an interesting tool which can predict success/failure of a project with an 80% probability ... with the final step being assignment of a skilled project manager. The sad truth is that most projects which fail should never have been started in the first place. Why? Poor understanding of estimate limitations, poorly defined PROJECT requirements, group think (especially around budgets), no sponsor, no (or improper) management oversight, negative political situation and poor project processes are just a few reasons. There are a lot of possible reasons. Most organizations will tend to have a selection of reasons based on their own culture. By the way for the anti-waterfall method folks -- project requirements are different from systems development requirements. Regardless of your development methodology you still need "fixed" project requirements in order to define project success. Otherwise there is no limitation to scope change (ie a political football or an "approved" runaway project).

mdfloyd
mdfloyd

I have experienced all these which is why so many projects do not succeed. You have to be able to refine the project as quickly as possible (limit scope, change delivery dates, etc.) present the alternatives to the project "sponsors". Then the sponsor(s) can make the executive decisions on your potential solutions. The statistics have not changed very much on projects that do not keep up with, nor meet, the intended user need by the time they are delivered. Still over 60% of projects are pretty much a bust. I have even had executive signoffs ignored late in a project with a simple statement such as "I don't care what I agreed to before. I want it now!"

kpak44wh
kpak44wh

HR department misses paying the contractors on the job, that has happened twice to me. Lately I have seen companies hire us for a contract job, and either miss a check or pay less than what it is.

rma
rma

Some of the points in the article are tied much to one specific paradigm of project management. An example is #1 sloppy requirements. Are you completely sure that if the specification is not done fully up front, then it is an indication of a project in trouble? I think the view of this article is way too narrow, thus rendering the article fairly irrelevant.

software_concepts
software_concepts

do you mind clarifying what you meant by the difference between project requirements and systems development requirements?

Tony Hopkinson
Tony Hopkinson

But designed to what specification? If the constraints change, scope is ambiguous.. Given project constraints eg time and money, could the design ever have been good. How many times have the resources allocated to a project been cut to make a budget... Who was the designer ? I've seen a number of projects fail, because some gave the design to a bright, bushy and above all cheap developer instead some old crusty type. A project manager should be able to get on top of this sort of thing early. At the very least failure should not be a end of project surpise 'gift' for the client.

ashao
ashao

Solid requirements are certainly make or break with Waterfall methods, but going into an iterative/agile development project without some clear goals for each iteration is just as disastrous. Iterative requirements should come out of initial customer discussions and/or lessons learned/results from previous iterations. These single iteration requirements should include things like high level component development and architecture (initial or changes), evaluation criteria (benchmark improvements, improved score on User Review, etc). Agile development methods and core project management concepts aren't mutually exclusive. In my experience, project management of agile development methods is even more critical because there are more opportunities for making decisions that can lead to the failure of the project. Communication, having clear goals/scope for each iteration and practicing change management techniques per iterative cycle are imperative to project success.

Tony Hopkinson
Tony Hopkinson

because of the delusion that it was specified up front than any other. In fact you can lay every other 'reason' for failure at the door of this fallacy. Need to add 12 - Even when successfully completed in budget and schedule, it may and up not being what the customer needs now. Change is a given, any management system that resists change fails in the real world whether change is rebuffed or not. Get the scope nailed down, and be prepared to revisit the resource required if it get's changed.

Locrian_Lyric
Locrian_Lyric

Scope creep is the only REAL killer I've ever seen. Scope creep is the grandfather of all other problems. Nail down the scope, enforce versioning, and you've won half the battle. If the scope creeps enough, you can end up recoding the entire thing and then YOU are the one responsible for the delays.