A post in Twitter about a Software Development project that had 6,000 pages of specifications that failed is an example of Doing Stupid Things on Purpose.
This article was held up by a #NoEstimates poster as an example of something - can't tell. But not doing estimates is unlikely the solution to any project failure. In fact not doing estimates is unlikely to provide any value to non-trivial project when spending other peoples money.
Some where, some how, some one needs to know an estimate of how much it will cost to deliver the planned value from the project.
No root causes provided in the article, but having been on a few train wrecks for Enterprise ERP projects I could imagine the sources of the problem.
- No clear, concise, or measurable description of done, in any units of measure meaningful to the decision makers.
- Progress measured by the passage of time and consumption of resources (money).
- No Technical Performance Measures defined on fine grained boundaries used to correct measures of progress. If you're on budget and on schedule, but your thing doesn't work as specified - than you're not on budget and on schedule.
- Probably not fine grained deliverables. We work $600M flight software programs with 44 day assessment of physical percent complete. No work can cross more than one accounting period before tangible evidence of progress to plan is reviewed and approved. This is standard DCMA (Defense Contract Management Agency) guideline.
- I doubt I would be able to find a Requirements Management System (DOORS is one we live on) for all the traceable requirements. Traceable up to the needed Capabilities and traceable down to the Work Packages producing the code that enables those Capabilities
The Root Causes of most IT projects starts long before the writing of any code. The Buyers don't have a clue about what done looks like. Not have they likely ever managed a procurement of this size. So the vendor makes claims that can not be substantiated and doesn't actually have the ability to manage the project or manage the customer.
The industry is littered with failed projects subject to these failure modes. Some recent comments on this all too common problem
- The real Root Cause of Project Failure
- Discovering the Root Cause
- The Problem with Platitudes for Management Guidance
Agile techniques are a powerful tool for actually writing the code, verifying the outcome is what the customer wanted, and taking corrective actions to make it right. But without a tested description of what Capabilities are needed by the business (in this case Orange County), Measures of Effectiveness of those outcomes, Measures of Performance of the system, Key Performance Parameters, and Technical Performance Parameters - all the processes for writing code will fail.
The Customer (and the providers) don't know what DONE looks like
