Frank Hayes wrote in ComputerWorld today about the preliminary results of the annual Standish Group study on IT project failure rates. They are actually up from last year. This year saw 28% of IT projects were entirely successful (delivered expected functionality within budget) and 18% were canceled before completion - complete failures. Last year's study had things at 34% - 18%. Apparently the numbers are not yet finished being tabulated and analyzed, but Hayes learned from Standish that there were a few things of note:
1) Projects are getting bigger again, and we know from experience that big projects are more likely to fail
2) Larger projects have meant a return to more traditional development schedules
3) Lack of user involvement has gone back into the #1 spot for project failure. (Last year's #1, lack of executive support is still running a tight second).
The obvious advice is to work to keep projects small. Hayes correctly identifies well-known reasons smaller projects are more likely to succeed: fewer people means less communication and management overhead; small projects can more easily be developed iteratively with a high degree of user involvement; finally, they avoid the corporate politics that can come to pass with large projects.
Hayes doesn't mention it, but another reason that small projects have higher user engagement levels is that small projects tend to be identified and approved farther down the management chain. The day-to-day user of the system might actually report to the system's sponsor. Also, because they originate closer to where the work is being done, they are usually solving a very well-defined and typically concise problem, which also naturally contributes to the odds of project success. The key point is: small projects have a better chance of success, so try to "think small" when defining a new project and control scope to keep it from turning into a big project.
But Hayes goes beyond just thinking small and controlling scope: "[W]e know that our biggest success rate for IT projects came right in the middle of the recent downturn. After the bubble burst, budgets were tight, resources were strained and big projects were rare. And -- not coincidentally -- our success rate jumped and our project cancellation rate dropped. When projects are small, we succeed. That suggests that we don't just need to keep projects from getting too big. We need to work actively to dismantle big projects." This is good advice, and it may work in some cases, but it isn't always an option.
I am pretty certain about the hidden (or at least unmentioned) reason the success/failure ratio has declined this year, and it is very much related to Hayes' comments about budgets being cut and then coming back to life. Most enterprises deferred upgrades of their enterprise applications and ERP systems during the economic doldrums. ERP upgrades spiked in late 2003 and into this year, if the markets my firm serves is any indication. Actually, "spiked" is probably not even accurate, "skyrocketed" might be a better way to put it. In many cases, these upgrades also involve substantial changes to the underlying technical stack or architecture, making them feel more like a new implementation.
This would be consistent with the other data Hayes mentions: Large-scale ERP upgrades or implementations have to follow a more traditional development cycle because of their size, and also because you are running the business on them, you need to get it right, iteration is not a good strategy. Also, user involvement is almost always a bigger problem with ERP projects because they demand an incredible number of users. (Last year we built a system for one of our clients to help streamline and manage the user acceptance testing process for their SAP upgrade cycle: they needed to coordinate over 300 users just for the testing phase.) Oh, and because the company is running the business on it, you usually do have to meet the "explosive requirement" of "The new system must do what the old system did," as Hayes suggests avoiding whenever possible.
The problem is that you can't really chop these projects up very easily and they keep getting larger and larger as companies tend to consolidate larger and larger portions of their application portfolios under one of a handful of "suite" vendors such as Oracle or SAP. If a company used SAP for Financials, Peoplesoft for HR, Siebel for CRM, and one or two other custom or boutique packages for other business functions, upgrading any particular one of them could be a confined project. When the company is running everything on one package, the entire enterprise and every function in it is affected by the upgrade.
I don't want to open up a can of worms with the suite vs best-of-breed discussion right now. There are good arguments on both sides of the question as to whether or not to buy into the suite approach ERP vendors offer and consolidate applications. For example, the environment I described above with several different vendor packages would probably be an on balance bigger problem. In September, I wrote Things to "Think About With Integration Projects" and mentioned the Standish Group finding that only 5% of integration projects meet the on-target, on-budget criteria of a successful project.
In addition to the ERP explosion, I also would not be surprised if the rise in offshore outsourcing played a role as well. Offshore projects almost always follow traditional development cycles because there's no choice: they don't have the opportunity for frequent user involvement. Also, they tend to frequently have problems delivering all expected functionality. (See "Return to Sender") Again, this is a bigger debate, but I could see offshoring as being another possible factor that is consistent with the numbers.
Also, I will be back on a more regular writing schedule now. I have been occupied with the election.
If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.
Why Successful Projects regularly create Discontented Clients, and What to Do About It.
See: http://www.diblog.com/2004/04/why_successful_.html
When Project Managers gather one of the common griefs they share with each other is the client who hates them. All the more puzzling and enfuriating to the group because in many cases the project has been "delivered successfully" - at least as far as the aggrieved project manager in concerned.
In my experience, when I ran a Systems Integration business, and when I consult to Systems Integration business clients, this lament of project managers is not uncommon. And even more infurating is the fact that competitors, who our lamenting project managers regard as technically inferior, are liked by the same clients for their project work.
What's going wrong here - what's the cause of this project managers' lament and how do we fix it?
The first point to make is that it can be fixed.
Posted by: Walter Adamson | June 17, 2005 at 05:38 AM