Social Enterprise

Six types of IT project failure

Michael Krigsman shares a list of six categories of IT project failure. What failure root causes would you add to the list?

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

Projects fail for many different reasons, so I took notice when reading a blog post that describes six specific categories of failure. I thought the list worth sharing because it's a clever way to view the problem.

This list comes hot off the press from the Preventing Project Failure blog (gotta love the title) written by Michiko Diby, Principal at project resolution firm Sealight:

  • Intent Failure - Occurs when the project doesn't bring enough added value or capability to beat down the obstacles inherent throughout the process. This suggests the original intent of the project was flawed from the beginning.
  • Sponsor Failure - Occurs when the person heading up the project is not actively engaged and/or does not have the authority to make decisions critical to project success.
  • Design and Definition/Scope Failure - Occurs when the scope is not clearly defined, so the project team is unclear on deliverables.
  • Communications Failure - Occurs when communications are infrequent or honest discussion of project problems and issues are avoided.
  • Project Discipline Failure - Occurs when process/project methodology is allowed to lapse so that the mitigation factors inherent in the process are never used.
  • Supplier/Vendor Failure - Occurs when the structure of supplier /vendor relationships doesn't allow for communication and adjustments.

Categorizing failure by type is an interesting way to bring attention to root causes. Although the list does not break new ground in pinpointing sources of failure, if offers a convenient way to discuss the problem. For a contrasting approach to slicing and dicing causes, see my post 7 fundamentals of IT project success.

Poor communication and mismatched expectations lie at the root of many failures, so we should welcome any serious efforts that raise the profile of these issues. If categorizing failures makes it easier for folks to discuss challenging situations then it's helpful indeed.

What would you add to the list of failure root causes?
14 comments
mdinca
mdinca

All project fail from a "technical" problem (typically it requires more resources to solve that financially foreseen or acceptable). All technical problems are benign unless there is a political answer given to a technical problem (see Tchernobil - technical failure due to political pressures). For e.g.: - The customer politically decide to not deliver the whole technical information in order to obtain a lower price offer (asking for a turnkey application but avoids to specify that they need also the computers) - The manager decide not to provide the predicted number of persons or the proper competences to the project because they are needed on another project, politically more important - We won't say or want to know that the things are going wrong, because we don't want troubles or because it is not politically correct to embarrass some important person that may be wrong - And so on ... In order to make a successful project: - Technical issues must have technical solutions. - Financial issues must have financial solutions. - Political issues must have political solutions. In real life it is impossible to totally avoid them mixing.

sharris282828
sharris282828

The ultimate cause of project failure is simple: failure to spend adequate time in the beginning planning the project. If you don't take the time to define the project 100%, determine the high-level risks, document the requirements at a high level, complete a Work Breakdown Structure, and create a viable schedule with realistic durations IN THE BEGINNING OF THE PROJECT, then the project is doomed no matter what!

mhpries
mhpries

These failures are all valid but differences exist if the project is company-defined staffed by company IT, vs. packaged solution staffed by solution vendor/contracted implementor vs. custom software consulting firm. But there are two other types of failure not listed that are common to all. First is Customer Expectations Failure, the failure of the acquiring stakeholders to to adopt reasonable expectations despite the information received from implementators (many times the messenger gets unfair blame) Second is Expectations Setting Failure, where the third-party vendore,contractor, consultant over-promises or ineptly allows the customer to buy into an exaggerated or accelerated vision of what is doable within the proposed timeline. Uusally this happens when there is a lot of pressure to win at the proposal stage. Then, of course, the development partner cannot reel that big fish back into line during the execution phase.

jacob3273
jacob3273

The worst situation I was involved with was the old syndrome known as "the moving target." One meeting would enumerate and clarify project goals, and though I'd return to my desk with a clear idea of how my module was supposed to perform, that definition would invariably and profoundly change at the next status meeting. My protests were met with charges that I didn't take notes or took them erroneously, and that nothing had changed. I soon learned to keep my mouth shut and just make the changes, but this was the norm, not the exception. That project of course failed, and unsurprisingly the company did as well, but I was long gone by then. After several incidents like that, I accepted the next decent contract offer.

tonycopp
tonycopp

Failure by Politics: When the fix is in, the best solutions be damned. More often than is noted, conflicts power and control vectors are an important cause of a project going nowhere. It sure feels like failure to the consultant while red herrings are reported.

rrickett
rrickett

A couple more things that can cause failures include: 1. TOO MANY FINGERS IN THE POT. The project leader needs to understand all aspects of the project and manage the inputs to the project. 2. MANAGEMENT APPROVAL. Top down approval is needed for a project to be a success. If you go with bottom up, you end up with staff members controlling the project direction and it gets completely out of hand.

MidwestITLady
MidwestITLady

Another one that I have experienced personally is when the [purchased] technology solution doesn't deliver the results the vendor promised. This is especially true when you're an early adopter, and you don't have much, if any, other customer feedback to draw from, or your environment is different from most others.

sutyakk
sutyakk

I would add blind trust in technology and the esoteric arrogance of developers. Also, inability to address conflict due to over-dependence in teams, which leads to a "groupthink" mentality.

TownsendA
TownsendA

That is from my point of view. I have found working on ERP projects much easier with defined WBS setups but when integration projects and other add-ons (mods) come along the lack of business analysis causes massive delays because processes and management requirements have not been planned in up front and the WBS and scope look very light.

Tony Hopkinson
Tony Hopkinson

Goods ones will deliver and maintain control. If managementapproves the wrong thing it won't matter how good your staff are....

viveka
viveka

I see this in a lot of development and "enhancement projects" A solution looking for a problem as my previous supervisor used to say! Basically it is the development organization with no governance.

Tony Hopkinson
Tony Hopkinson

on why the rush to completion is often accretes failures. Rings pretty true as well, like the author I hope I'm at least making new mistakes. :p

Tony Hopkinson
Tony Hopkinson

not the sole province of the devlopment organisation. How about a years effort and 1 trial customer? Or an ordering application crippled so you could only have one order per customer, because that's all that was needed initially... Or two apps using a common xml document, but linked via a system that couldn't deal with Xml. All management decisions at about your level, if not your ability....