Identifying (and Fixing) Failing IT Projects

Esther Schindler writes "Often, the difference between the success and failure of any IT project is spotting critical early warning signs that the project is in trouble. CIO.com offers a few ways to identify the symptoms, as well as suggestions about what you can do to fix a project gone wrong. ' The original study (which is still sometimes quoted as if it were current) was shocking. In 1994, the researchers found that 31 percent of the IT projects were flat failures. That is, they were abandoned before completion and produced nothing useful. Only about 16 percent of all projects were completely successful: delivering applications on time, within budget and with all the originally specified features. "As of 2006, the absolute failure rate is down to 19 percent," Johnson says. "The success rate is up to 35 percent." The remaining 46 percent are what the Standish Group calls "challenged": projects that didn't meet the criteria for total success but delivered a useful product.'"

Comments

AA meeting?

[disasm]

This reads like an Alcoholics Anonymous meeting:

Step 1: Get everyone to admit the project has a problem
Step 2: Figure out what that problem everyone admits is wrong really is
etc...

Sam

Re:AA meeting?

[Tackhead]

> Step 1: Get everyone to admit the project has a problem
> Step 2: Figure out what that problem everyone admits is wrong really is

1. We admitted we were powerless over this schedule -- that our project had become unmanageable.
2. Came to believe that a Power easier to blame than ourselves could restore us to schedule.
3. Made a decision to turn our will and our lives over to the care of the Consultant as we hired Him.
4. Performed an overreaching and mindless team-building exercise.
5. Admitted to the Consultant, to ourselves, and to the CEO the exact nature of our incompetence.
6. Were entirely ready to have the Consultant take over our jobs duties.
7. Humbly paid the Consultant to fix it for us.
8. Made a list of all persons we had harmed, and became willing to make suck up to them all.
9. Sucked directly up to the CIO wherever possible, except when to do so would involve our beating him at golf.
10. Continued to perform team-building exercises, and when we thought it was silly, we still faked it to HR.
11. Sought through kickback and corruption to improve our friendship with the Consultant as we understood Him, paying only for Coverage of Our Asses and the budget to carry that out.
12. Having had a Machiavellian awakening as the result of the project's inevitable failure, we fired the Consultant and resolved to carry the blame to other departments, and to re-hire the Consultant next year so that we can practice these principles when the next project goes off the fucking rails too.

Sounds like MY career, anyway...

[The_REAL_DZA]

That 31%-flat-failure rate sounds just about right; about a third of the projects I've worked on over the last 15 years have been complete flops (with the usual list of various reasons from "bad idea to begin with so it needed killin' " to "we changed bosses and since your project wasn't the new boss' idea..."), but I'd have to challenge the notion from TFA that they "produced nothing useful", because I've learned something I didn't know and wouldn't have otherwise known from each of them -- in other words, I'd count them all as at least partial successes because I personally gained something from them.

Re:Sounds like MY career, anyway...

[Anonymous Coward]

Well, sure, you always learn something.
But did you pay for all those projects?

I'm going to make the wild assumption that was not the case, since you mentioned org changes ('new boss'), etc. as apparently external factors.

In general, the judgement of whether a project is a success or not rests on the hands of those who put in the capital / resources.
The project is typically started with a particular goal, expected cost, and time of opportunity.
For the investiors, a failure to move towards that goal and the corresponding loss of investment is almost always worse than not starting the project at all.

As an employee, you (normally) get paid whether the project succeeds or not - your risk factor is a matter of time, and perhaps reputation. Your main goals are to get stable pay, and increase your worth in terms of skills / experience, and perhaps better remuneration as a consequence of consistent success.
From an employee's point of view, even the most abject failure is a partial success: you get paid for your time, and you typically get lots of hard-won experience and skills (since the sky is always falling).
It is not easy to make the case that it was better not to do anything at all - rent, food, and other minutae of life are good motivators.

I'm not minimizing the value of the learning experience for everyone involved - it's just that it is both trivially true and besides the point.

Re:Sounds like MY career, anyway...

[jafac]

well, the project lead should have known whether his team had the critical skills necessary to accomplish the task, or whether his team was going to have a 'learning' experience. Of course, you're always going to learn new things on almost any project. But if the project failed BECAUSE of that - then that is the fault of the person who planned it - and also, IMO, the fault of Project Planning methodology in general (or what they're calling "Systems Engineering" these days) - which has, as a specific goal, removal of the planner, from the details of the implementation. If the planner does not know the details, then he does not know the technology, and does not know what kinds of licensing and proprietary corners he could be painted into, and does not know whether his team has the critical skills necessary to accomplish the task.

I'm more of a low-level guy myself, so I'm not sure I understand what the benefits are of removing the architect from the implementation details are, but the downsides are pretty strongly evident. I see it happen all the time.

Why Aren't You Jumping Off the Sinking Ship?

[asphaltjesus]

Seriously.

Most IT projects I've been involved with that got to some difficult points suddenly had no one willing to discuss them, much less do anything.

Woe is the girl/guy with no authority brought in to get the project back on track.

Re:Why Aren't You Jumping Off the Sinking Ship?

[cromar]

Woe is the girl/guy with no authority brought in to get the project back on track.

Hey, at least I get good salary and benefits! Coding a huge web application by myself for 7 months wasn't so bad: I like coding and money. Now I just hope they find something else for me to do... I hate being underworked.

consultants

[Lord Ender]

When management wants a project that IT knows is bound to fail, our company will sometimes hire an outside consultant to run the project. That way, half way through the project, as we miss milestones, we can fire the consultant and blame it all on him. He gets paid, and we get out of the blame. Win-win.

Article is self-contradictory

[mcrbids]

The article starts out by stating that "agile project management is notoriously least effective on very large projects." but then goes on to propose using Agile Programming techniques to fix it! Such as:

From TFA:

"Small, discrete and often" are the guidelines for the milestones for a successful project. And from the Agile Manifesto:

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale. From TFA:

"Make sure everybody really agreed to what the project is going to do," he says. "Make sure everyone has the same goals even when they have conflicting agendas." And from the Agile Manifesto:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. This is just another shoddy example of "journalism" from an IT rag whose job it is to produce buzzword-laden tripe that can be used to get advertisements in front of tech weenies. Ultimately, the actual value of the articles in mags like CIO.com are marginal at best, and usually only slightly more interesting than the advertisements!

The problem is usually awful requirements

[The Media Mechanic]

I haven't read the article but I would bet good money that they are allowing clueless managers and CEOs who gave very bad requirements in the first place, to determine if something was a success or failure. In other words, software is only as good as the initial requirements and design. If your client / customer is clueless then they will give you some hand-waving description of what they want ... something like "Listen, we need a new computer system that kind of does what the old one does, but just works better and makes more profits for us! Now hurry up and make it work, Code Monkey! Now excuse me while I retire to my executive suite / relaxation salon and get my manicure."
( Not that I'm bitter or anything. )
http://blogs.warwick.ac.uk/images/steverumsby/2006 /01/30/dilbert20060121046729.jpg

Heuristic methods

[mutterc]

Spotting a failing IT project: If it's a project, and it involves IT, then it's failing. (The summary's cited statistics bear this out).

Fixing a failing IT project: Rewrite the laws of economics. (My experience bears this out). This may involve fiat, chemical means, or founding a new religion.

Grain o' Salt

[vinn]

I gotta say, I always take this kind of stuff with a grain of salt. As an IT manager (director, or whatever the hell you want to call it) I've got a little perspective on it.

There's quite a few projects that we arguably start (probably even close to the figures quoted) that we don't finish. They're not failures, often I (me, not the department or project managers) had no intention of completing them anyway. Here's why some don't get done:

1. I can't get it past the budget process. There's a time and place to pick your battles. Maybe throwing HR's new whiz-bang software project under the bus to make the operations manager's project swim along is worth it. It doesn't mean HR's project is a failure.

2. We start a project to investigate a new technology. Hey - sometimes (dare I say most of the time?) the new stuff doesn't work as advertised. Sure, we've got an older 802.11b network running side-by-side our 802.11g. We looked at ripping it out and starting to get into the 802.11n, but it's not worth it right now. But the exposure to 802.11n was worth it. We'll revisit it next year (when Cisco gets an n product.)

3. The "nice to do" list also creates some "failures". Boy, right now we need a strong asset tracking system. Well, screw it. We can track the licenses on paper as we've been doing. We've got more important things to worry about.

However, the shit that needs to get done, gets done. That new accounting system? Hell yeah we're going to get that right.

SAT Effect

[Reason58]

In 1994, the researchers found that 31 percent of the IT projects were flat failures. [...] As of 2006, the absolute failure rate is down to 19 percent.

I have serious doubts that IT projects have made any significant improvements in management efficiency in the last decade or so. More likely the people estimating timelines, budgets and features have learned from their mistakes and simply set the bar much lower than they did in the early 90s.

It's the "SAT Effect" (tm). Why actually improve performance when you can simply tweak the metrics by which you measure?

Re:SAT Effect

[nine-times]

You make it sound like a such a bad thing. I don't necessarily think it's just about "lowering the bar", but instead an issue of having realistic expectations. In 1994, having a dedicated IT department was still relatively new for many companies. To put it in perspective, people were still using Windows 3.1. The Internet wasn't even a blip on the pop-culture radar, and (IIRC) Netscape was just being released around that time. Most people understood practically nothing about computers and networks. In a lot of colleges, CS was still a relatively new major, and many colleges didn't even offer IT-specific majors yet. For a long time, the "computer experts" came out of other majors relating to math, engineering, and science.

So it wouldn't surprise me at all to learn that the managers of IT projects in many companies had practically no idea of what they were doing. I wouldn't be surprised to hear that they had silly expectations about how things would work or what their new systems would allow. After 13 extra years of seeing the reality of computing and being frustrated by computers, one would think their expectations would be lowered somewhat.

If you aren't part of the solution......

[Proudrooster]

If you aren't part of the solution, there is much money to be made in prolonging the problem. (My second favorite de-motivator)

Seriously, though the classic problem with IT projects are two-fold: 1) Unclear Requ2irements and, 2) Scope Creep. Unfortunately, while IT is bemoaned as incompetent, the truth is that most of the users are even more incompetent, yet the IT departments ask the users for INFORMATION.

IMHO, You have to assign someone from IT to LEARN THE BUSINESS before trying to create solutions. For example, if you are creating an application for a Shipping Department, send people from IT to go work in shipping for a week and UNDERSTAND how the department operates and how it can be improved. Asking the users what they need without true understanding leads to disaster and inefficiency. If you gain understanding and insight into how to create a solution, you can make real improvements and possibly even eliminate inefficient/useless tasks and save labor.

Scope Creep.... The old, hey while you are at it, could you just add one more feature to the program? You have to respond NO, but we will add that to the feature list for version 2.0 of the application. Imagine if Henry Ford tried to add all the features we have on the modern automobile to the Model-T. The Model-T wouldn't have ever been delivered. Creating software is an iterative process and just like car models you have to stop adding features at some point.

Good Luck! Just remember, the problem is rarely technical.

As long as you're up front about it

[Doctor Memory]

That's all part of the consulting game, but you have to play fair. Offer a fixed-price contract with no early termination penalty, or provide an escape clause that pays some fair amount if the contract is terminated early. I've known a couple of projects that badly burned some consultants, because management knew the project was going to fail, but they still put the contract out light on the rate but heavy with incentives. And what really sucks is, you'd like to say "Boy, you'll never catch me working for someone like that", but when they're one of the major players in town, you know you may have to play. Unless you're happy writing VB front ends to Access databases...

Re:With Major Hopeful's help

[spazLizard]

All projects from civil engineering through to social engineering exercises and time sheet programs can fail if not well designed and well executed.
How many civil engineering projects are planned by someone with someone with little to no experience and implemented mainly by fresh graduates? Software's often lack of physical safety issues and low visibility of mistakes make the seat of our pants approaches way too common. My personal favorites are the schedules that assume no one will ever get sick or take vacation plus introduces tools and technology team members are not familiar with.

Re:With Major Hopeful's help

[ElectricRook]

One problem I see, is that many IT projects begin with the goal of making the project manager look good.

The proper way to start a project is: How can we fix BAD THING. Instead of the usual "We should migrate this to SAP cause that would look so cool on my review".

Many times IT projects become a destination, instead of a method to reach the companies destination be it ( manufacturing / sales / service ).

How to spot the places where late is normal

[Aceticon]

As a contractor (aka freelancer) software engineer and analyst i have over the years learned to spot a number of indicators which are usually associated with the kind of groups/companies where software projects tend to be late and/or not deliver what the business needs. Here's a couple of indicators for that kind of place:
- The bigger/more-complex projects have little or no analysis.
- There is neither a formal Requirements Gathering stage nor (in Agile Programming) an easilly available user/user-representative with which to discuss business features.
- Delivery of a project to a client is an unstructured process. In other words, there is no list of standard types of documents and deliverables to deliver which is common across projects.
- Project planning does not have a built-in margin for unforseen problems and sometimes relies from the start in people working extra (unpaid) hours to make the budget.
- Sales dictates the deadlines without consulting (or consulting but then ignoring) the technical side.
- There are no specialized Testers.
- There are no standardized software components, software frameworks, good practices or documentation for use across the company.
- There is a vast number of software languages, software libraries or frameworks of different versions used across the projects done in the company. Similar projects use different languages/libraries/frameworks and/or use different major versions of those. Developers are totally free to choose the languages and libraries they want to use for the projects. Maintenability is not taken into consideration in the choice of languages/libraries which instead are chosen on the basis of "cool sounding", "fun" and "CV enhancing".
- The project manager has little formal or informal power within the company beyond his subordinates (this is harder to spot but a surprisingly good predictor of failure).

There's quite a lot more, but these are some of the more obvious ones and i've seen all of them already more than once.

More in general, what software development environments where late or failed projects are common share is a failure to organize and/or a failure to prepare and/or lack of "soft skill" from project management and/or ignorance of the characteristics of the software development process.

Responsibility without authority

[Anonymous Coward]

"Woe is the girl/guy with no authority brought in to get the project back on track."

It's called "responsibility without authority". That's a key concept. If you recognize the situation, you learn to either change it or get out fast, as this situation ALWAYS leads to disaster, with your name on it.

Annoying

[steveoc]

I find this article very annoying.

So a bunch of companies (who all sell expensive proprietary project management software) get their heads together and conduct a study on project success/failure ratios .. and conclude that things are improving, and then attribute the improvements to things like .. This awesome new, expensive, proprietary project management software.

Umm .. excuse me, but I have NEVER seen a project that was conceived AND executed solely by any number of 'project managers', using any form of project management tools, meetings, and other justifications for their existence.

Projects are successfully delivered by good coders with good tools, and a thorough understanding of the requirements. There have been RADICAL advances since 1994 in the way that software is built, and its these advances more than anything else that lead to successful projects.

Coincidentally, Prior to 1994, if you were working in software, you were working blindfolded with one hand tied behind your back. By 1995, this Linux thing starts gaining momentum, and very quickly we see this massive rise of open source projects in a huge number of areas. Prior to 1994, an SQL engine is some mythical binary blob that you have to purchase from Oracle or others .. after 1994, an SQL engine is something tangible that you can download of the internet and get your hands dirty with the source code. Ditto with 'internet enabling' your applications - Ditto with having a real freely available and portable C compiler - ditto with having a raft of languages (perl, PHP, etc, etc) that open up new possibilities.

Suddenly, as a software coder, the blindfold is removed and you have both hands free to work. Whatever problem domain you are likely to encounter, you can easily find open source projects that have already dug very deep into that problem domain, and have code and design discussions open for general peer review.

So its no surprise that in this new and extremely fertile post-1994 world .. software projects are more successful. But can you simply attribute that to a small selection of expensive, proprietary project management tools ? WTF, I dont think so.

Another thing to note is that the core developers in a lot of projects are older and wiser now. Many are well past the wrong side of 40 and still coding day and night for the sheer joy of the art. Perhaps they have also grown more politically savvy, and know how to take management speech, distill the essential elements out the mouths of managers, and then go away and do the project their own way regardless. Except this time, they know how to twist it so the 'managers' can feel like they deserve some credit for the project as well, whilst at the same time keeping them discretely out of the way - so that the project itself can move forward smoothly.

Maybe that is one benefit of shiny new project management tools - it gives the managers something to occupy their time with, so they can keep out of the way.

Re:Annoying

[Shados]

Then again, software "coders" are almost never the ones that are responsible for the success or failure of the project -either-. Architects, analysts, team leaders, researchers, etc, are. Actually "building" the thing is completly trivial once these people succeed on their side of things.

Almost like building a house. Once the plans are drawn, the ressources allocated, etc, if the project is managed correctly, its almost impossible for the coders to screw something up.

Re:Annoying

[MartinB]

Projects are successfully delivered by good coders with good tools, and a thorough understanding of the requirements.

*sigh* I can tell you've either never worked on anything with complexity, or paid attention when you did.

Right, Mr "I'm so smart, I can fix everything with software development tools". Who does the following for your projects?

1. Ensures that the *right* people (As opposed to J Random Client Staffmember) make decisions about changes to requirements so they get accepted throughout the project lifecycle? And that the bad change requests are rebuffed?
2. Ensures that potential $badthings are spotted and either avoided, or planned against?
3. Ensures that the plans to resolve actual $badthings are carried out? That the actions needed actually happen (and if not, the responsible people are taken out and slapped)
4. Plans the work, end to end, including all external and cross-dependencies? Incidentally, the coding bit is usually a relatively small bit in the middle.
5. Ensures that appropriately skilled people are found to work in all the necessary roles, at an acceptable cost. Or if they cannot be found, workarounds found. And if they're not located within commuting distance, how they're going to travel (and have that recovered), whether they need work permits, etc. How they're going to get building passes, system logins, desks, chairs, PCs (etc). Ever tried it for a 100+ person team?
6. Procures external services (eg server infrastructure), and ensures it arrives on time, cost and quality?
7. Maintains supportive relationships between the project and all the people it needs to keep going (including whoever has to sign the invoice for it to be paid)? Those progress reports aren't there just for fun, you know.
8. Ensures that the thing that the client *asked for* is the thing the client *actually needs*? (ie ensures the requirements capture process is robust)
9. Ensures that you get paid?

Doesn't matter what you call them, anyone doing this is a Project Manager.

Good PM software isn't necessary to do this. Good PM methodology is. And if you're limited in PM time, SW helps (like any good tool).