July 23rd, 2008
Delivering nada. Zip. Zilch. Zero.
The aftermath of large-scale failure is never pretty, but sometimes looking back reveals problems so obvious and severe they take your breath away.
Bruce Webster’s blog describes a large project where a major consulting company failed to deliver anything:
The project in question was a major IT re-engineering effort for a mission-critical system; at the time I did this review, the project had been going on for several years and had cost millions of dollars; it would eventually be canceled and the work products abandoned.
Here’s an excerpt from Bruce’s outstanding post-mortem (he redacted the names):
Quality of work and effort: Several consultants said — and the rest pretty much agreed — that far too many of the deliverables, artifacts, and activities (e.g., algorithms, source code, system configuration, design/architecture documents, testing, defect tracking, scheduling etc.) are substantially below any acceptable professional standards and represent a profound threat to FUBAR ever going into production.
Project planning and execution: Project planning and execution is all to often poor or missing completely. Milestone dates, usually unrealistic if not impossible, are based on political considerations or wishful thinking, not bottom-up grounding.
Quality assurance and process: Quality assurance appears to be low-priority concept within the FUBAR project. In the opinion of several consultants, the current person in charge of it is not particularly strong or competent. There appears to be a systemic inability to establish good testing criteria and methods to gauge FUBAR’s progress toward production.
Architecture: FUBAR doesn’t have a viable, consistent architecture. The irony is that FUBAR itself is not a big, complex problem; it is a relatively straightforward problem that has been made big, complex, and possibly unsolvable in the current implementation.
Application performance: FUBAR was never properly architected and designed for the performance required. There is a current effort to increase performance after the fact, but the implementation makes that impossible.
Staffing: Many of the people involved in FUBAR — developers, testers, team leads, managers — lack the qualifications, insight, or experience to make FUBAR a success. The project is overstaffed for the actual complexity of FUBAR, possibly for political reasons (i.e., promotion/stature based on the number of people supervised).
[BrandName team management approach] principles: Mid-level management tells the developers that mood, sincerity, and commitment are everything, and that with them “we can accomplish anything.” At the same time, the principle of granting sincerity appears to be used to justify a lack of accountability and consequences.
Intellectual honesty: Managers reject or explain away bad news and real problems, looking instead for people who will tell them what they want to hear.
Closing remarks: [T]here are some profound problems and flaws with the FUBAR project that will not go away until the project team acknowledges and addresses them. Indeed, it will be hard enough to make them go away even then.
Draw your own conclusions, but I don’t think these problems are uncommon. Sure, this case is more severe than most, but the basics happen all the time.
Combining organizational hubris and over-reaching personal ambition with vendor incompetance is a definite prescription for failure.
[Image via FreeFoto.com]
Michael Krigsman is CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures. Click here to discuss this post with him on Twitter. See his full profile and disclosure of his industry affiliations.
Subscribe to IT Project Failures via Email alerts or RSS.
| 07/23/08
