Why Enterprise Projects Fail, or Pitfalls in Practice
In one of those water-cooler moments at the office, a colleague of mine asked me "what percentage of enterprise scale projects fail and why?". Upon reflection, considering the scope of the last several adventures in which I had a part or observed from the outside, I had to answer "all of them, at least by some measure." The subsequent conversation prompted me to summarize here why, in my view, this is so.
The Top Ten Reasons Why Enterprise Projects Fail (sorry Dave, but I'm not the first or last to cop this one):
10. Inappropriate Project Scope or Trying to Hit a Moving Target. When the constraints and objectives of the project are too ambitious or the scope incrementally creeps larger over time, the problem is ill-defined. The project scope and deliverables must be clearly defined in advance, or incrementally refined through prototyping and actively managed along the way with timely feedback from business sponsors.
9. "Not Invented Here" Syndrome. Often projects start with a review of applicable vendor based solutions. Frequently, the outcome of these system evaluations are stacked against vendors from the beginning. Software developers have a disappointing predisposition to prefer to build solutions from scratch rather than buy a third-party product or work with a vendor to adapt an existing commercial solution, thereby ignoring the real maintenance costs of homegrown work. If a third-party solution matches or closely matches the goals of your project it is invariably cheaper and faster to buy versus build once the true project costs are considered. If your project is big enough, most vendors will work with you to refine their offerings to accommodate your needs.
8. Loss of Political Sponsorship. Projects loose their champions when their expectations are not properly managed and the timeline/budget is not met. Stay visible and stay employed by delivering results early. It is critical to under-promise and over deliver.
7. Project Risks Not Properly Assessed. Development efforts, unlike engineering projects in other disciplines, always uncover unknowns as the project progresses and must fluidly accommodate unforeseen setbacks. The closer to the bleeding edge your project is, the more certain it is that serious setbacks will occur.
6. Inadequate Resourcing. Every carpenter knows you need the right tools for the job. Enterprise projects require the right people in the right roles from inception to completion. Management needs to set priorities, schedules and expectations and run air cover so that technical resources can do their jobs effectively. Developers need to have the discipline, experience and abilities necessary to complete project milestones on time, overcoming the many obstacles on the way.
5. Fear, Uncertainty and Doubt. Other players can and will influence project sponsorship for their own purposes. Count on it happening if budgets are large, spreading FUD is a key weapon in the arsenal of external consultancies who routinely attempt to undermine project management's credibility and subsequently 'correct' the project course by restaffing it with their own people for their own financial gain. It works because it is self fulfilling. This technique is also a favorite of other internal department managers who want to appropriate your budget for their priorities -- after all you are all competing for a piece of a finite pie. The bigger the budget, the bigger the potential target your project funds are. It may not be right, but it happens all the time.
4. Not Knowing When to Cut Your Losses. Fear of failure often motivates throwing good money after bad and making a bad situation much, much worse. If a milestone looks doomed to fail, forget your pride, re-tool, work proactively for the good of the business to recover as many positive benefits of the effort as possible and constructively move on with an alternative approach.
3. Inability to Overcome Technical Roadblocks. Often related to number 6 above, unstructured teams, inappropriate use of methodology or failing to correctly use best practices will exaggerate the chance of technical failure because the team cannot apply the rigor required to properly formulate a solution and move forward. After all, software development is both a team and a contact sport, so it is important to choose the development methodology that best matches project objectives and best facilitates inter-player communication.
2. Impedance Mismatch. Organizational structures rarely match project responsibilities. Whenever functional reporting lines do not line up with project objectives you can bet the motivation of others to deliver are diminished, often crippling the entire effort. Think about it, if you need that guy in London to deliver something to your New York development team and he does not report to you, your priorities will understandably be at the bottom of his activity list. After all, he's a busy guy with his own problems and he is not organizationally motivated to respond to your needs.
And the number one reason why large-scale projects fail?
1. It is a Government Project. There are countless examples, governments just can’t responsibly spend taxpayers money or run a development project. A poster child of project mismanagement and arguably exhibiting the previous nine characteristics, perhaps the most stinging of recent examples is the Canadian Gun Registry, initiated by the Liberal Government of Canada to require gun owners to register all guns in the country. In spite of the fact that the whole idea is one of the most ill-conceived notions one could imagine (after all, crooks don’t register guns), the Liberal government initially budgeted the cost to taxpayers at a net outlay of 2 million dollars. Still incomplete, the costs are now over an astonishing one billion dollars and rising, in a country with one tenth the population of the United States. Whatever your position on guns, whether you believe registration is an effective crime prevention tactic or not, a database development effort should not cost a billion+ dollars. In other words, when political ideology hijacks the project agenda your spidey sense should tingle because project funds are being bailed, taken out back and lit ablaze. Everybody looses.
I am a big believer in incremental development as a tool to help manage project expectations and mitigate risks. Following the old 80-20 rule, incremental development plans can, through rapid prototyping and continual refactoring, help refine project requirements and show visible results early. This can really help to out maneuver the FUD slingers and give your project champions needed confidence that you and your team will deliver as promised. Look back over the last firm-wide development project you were on. In spite of the fact that your efforts may have been considered successful and valuable business benefits were realized, it is highly improbable that the complete vision of the original project was achieved, within the promised timeline and budget. When you come to think of it, we all decry the fallibility of the weatherman, and scoff at the inaccuracy of the previous day's forecast. Next time you're deriding your local meteorologist, consider he's at least an order of magnitude better in delivering on his promises than we are.
The Top Ten Reasons Why Enterprise Projects Fail (sorry Dave, but I'm not the first or last to cop this one):
10. Inappropriate Project Scope or Trying to Hit a Moving Target. When the constraints and objectives of the project are too ambitious or the scope incrementally creeps larger over time, the problem is ill-defined. The project scope and deliverables must be clearly defined in advance, or incrementally refined through prototyping and actively managed along the way with timely feedback from business sponsors.
9. "Not Invented Here" Syndrome. Often projects start with a review of applicable vendor based solutions. Frequently, the outcome of these system evaluations are stacked against vendors from the beginning. Software developers have a disappointing predisposition to prefer to build solutions from scratch rather than buy a third-party product or work with a vendor to adapt an existing commercial solution, thereby ignoring the real maintenance costs of homegrown work. If a third-party solution matches or closely matches the goals of your project it is invariably cheaper and faster to buy versus build once the true project costs are considered. If your project is big enough, most vendors will work with you to refine their offerings to accommodate your needs.
8. Loss of Political Sponsorship. Projects loose their champions when their expectations are not properly managed and the timeline/budget is not met. Stay visible and stay employed by delivering results early. It is critical to under-promise and over deliver.
7. Project Risks Not Properly Assessed. Development efforts, unlike engineering projects in other disciplines, always uncover unknowns as the project progresses and must fluidly accommodate unforeseen setbacks. The closer to the bleeding edge your project is, the more certain it is that serious setbacks will occur.
6. Inadequate Resourcing. Every carpenter knows you need the right tools for the job. Enterprise projects require the right people in the right roles from inception to completion. Management needs to set priorities, schedules and expectations and run air cover so that technical resources can do their jobs effectively. Developers need to have the discipline, experience and abilities necessary to complete project milestones on time, overcoming the many obstacles on the way.
5. Fear, Uncertainty and Doubt. Other players can and will influence project sponsorship for their own purposes. Count on it happening if budgets are large, spreading FUD is a key weapon in the arsenal of external consultancies who routinely attempt to undermine project management's credibility and subsequently 'correct' the project course by restaffing it with their own people for their own financial gain. It works because it is self fulfilling. This technique is also a favorite of other internal department managers who want to appropriate your budget for their priorities -- after all you are all competing for a piece of a finite pie. The bigger the budget, the bigger the potential target your project funds are. It may not be right, but it happens all the time.
4. Not Knowing When to Cut Your Losses. Fear of failure often motivates throwing good money after bad and making a bad situation much, much worse. If a milestone looks doomed to fail, forget your pride, re-tool, work proactively for the good of the business to recover as many positive benefits of the effort as possible and constructively move on with an alternative approach.
3. Inability to Overcome Technical Roadblocks. Often related to number 6 above, unstructured teams, inappropriate use of methodology or failing to correctly use best practices will exaggerate the chance of technical failure because the team cannot apply the rigor required to properly formulate a solution and move forward. After all, software development is both a team and a contact sport, so it is important to choose the development methodology that best matches project objectives and best facilitates inter-player communication.
2. Impedance Mismatch. Organizational structures rarely match project responsibilities. Whenever functional reporting lines do not line up with project objectives you can bet the motivation of others to deliver are diminished, often crippling the entire effort. Think about it, if you need that guy in London to deliver something to your New York development team and he does not report to you, your priorities will understandably be at the bottom of his activity list. After all, he's a busy guy with his own problems and he is not organizationally motivated to respond to your needs.
And the number one reason why large-scale projects fail?
1. It is a Government Project. There are countless examples, governments just can’t responsibly spend taxpayers money or run a development project. A poster child of project mismanagement and arguably exhibiting the previous nine characteristics, perhaps the most stinging of recent examples is the Canadian Gun Registry, initiated by the Liberal Government of Canada to require gun owners to register all guns in the country. In spite of the fact that the whole idea is one of the most ill-conceived notions one could imagine (after all, crooks don’t register guns), the Liberal government initially budgeted the cost to taxpayers at a net outlay of 2 million dollars. Still incomplete, the costs are now over an astonishing one billion dollars and rising, in a country with one tenth the population of the United States. Whatever your position on guns, whether you believe registration is an effective crime prevention tactic or not, a database development effort should not cost a billion+ dollars. In other words, when political ideology hijacks the project agenda your spidey sense should tingle because project funds are being bailed, taken out back and lit ablaze. Everybody looses.
I am a big believer in incremental development as a tool to help manage project expectations and mitigate risks. Following the old 80-20 rule, incremental development plans can, through rapid prototyping and continual refactoring, help refine project requirements and show visible results early. This can really help to out maneuver the FUD slingers and give your project champions needed confidence that you and your team will deliver as promised. Look back over the last firm-wide development project you were on. In spite of the fact that your efforts may have been considered successful and valuable business benefits were realized, it is highly improbable that the complete vision of the original project was achieved, within the promised timeline and budget. When you come to think of it, we all decry the fallibility of the weatherman, and scoff at the inaccuracy of the previous day's forecast. Next time you're deriding your local meteorologist, consider he's at least an order of magnitude better in delivering on his promises than we are.
posted by John Free at
3:04 PM
Links to this post
