The Standish Group’s original 1994 CHAOS Report has been often quoted but is currently hotly disputed. It purports to explain, in general terms, the reasons that IT and programming-oriented project management operations tend (arguably) to fall short of reasonable expectations in terms of projected delivery time, financial budget parameters and functionality upon completion -- if indeed, there is a fixed point of completion of the Minimum Viable Product (MVP) pursuant to original specifications..
It would seem, by the Report, and based upon some compelling anecdotal evidence that where IT and software-involved projects tend to run off of the rails in a number of ways and for a number of reasons, infrastructure projects (each with a physical result and expectations which can much more easily be visualized at the project’s inception) in contrast, tend to meet initial expectations and produce the contemplated result.
The Report is not based upon so much science and fact as it is upon observation, supposition and somewhat biased cause and effect logic -- yet, despite its failings and its detractors, there are some elements in the document that make it worth some serious consideration.
The gist of the original Report’s observations and findings:
Every software engineering researcher has heard of the 1994 CHAOS report from the Standish Group. It reported that the large majority of software projects fail, and that they incur in an average of 189% cost overrun. It’s a very popular report – the cited exemplary reference for researchers who wish to make the case that the software industry is in crisis and is therefore desperately in need of whatever tool or method can be thrown their way. It begins begins with the premise that 1) a highly-tangible infrastructure project (i.e., the construction of a bridge) generally comes in or close to on time, within budget and fully-functioning [perhaps back in the 1990’s, anyway], and that if something should go wrong, the gravity of the tragedy leads to a thorough investigation of the failure and the reasons for it, while 2) IT and programming-related projects almost never are finished on schedule, are invariably over-budget, and seldom perform to an anticipated standard of expectations. If one of these projects goes off of the rails (the Standish Group would have it), it is either covered up, obscured by incorporation into some larger project, or simply considered, euphemistically, to be a “Phase 1” in a surprisingly multi-phased project.
While the Report is thought by many to be unscientific, speculative and conflictory, there is some validity to it in terms of some of its reasoning, and as such, I cannot dismiss it in its entirety:
1) A bridge or critical infrastructure project involves Human life or death - most IT projects do not...at least directly;
2) A plan for a tangible construct tends to be far less flexible in terms of changing specifications, scope creep and “collective management” (perhaps a nice way of saying that these projects are committee-built, and become amorphous -- the cliche here is that “a camel is a horse that was designed by a committee.”;
3) The end product of the process is more functionally than physically-defined in the case of IT, programming and the like -- whereas, on the other hand, everyone knows what a bridge is supposed to look like...and if collapses there will be tremendous liability involved.
---------------------------------
*A downloadable .pdf file of an abbreviated version [published in 1995] of The Standish Group’s original 1994 CHAOS Report can be accessed by clicking on this link. Once you taken a look at it, please press the “BACK” button on your browser, and then come back to us.
http://bit.ly/StandishChaosReport
-------------------------------
After reviewing the Report, and “seasoning” it with your life’s experiences, you will likely come to several general “common sense” conclusions as to how this report relates to business planning and project management. Here are several which I have been able to glean:
1) There is a Murphy’s Law, and it operates with its own ironic type of “intelligence.” If contingencies are not provided for, and specific issues not addressed, there will be an increased likelihood of the plan resulting in disappointment;
2) If the end result of your project or plan is more easily visualizable in terms of a definitive list of its properties and physical appearance, it is more likely that your management and team efforts toward that result will be linear, instead of “fuzzy,” “spiralling,” or contra-centric;
3) If the project has a plan and process which is not subject to constant scope creep, design correction, committee efforts, and excessive intellectual or technological fluidity, you might wind up with an on-time, on-budget, fully functional result...like an automobile or a horse, instead of a spruce goose or a camel;
4) If the stakes are higher in terms of life, liability and necessity, the gravity of the project is increased and operates as a disciplinary force;
5) A plan or project with a nebulous starting blueprint, process, and roles for each team participant is more highly likely to fail -- to this, I must add that if you have more complexity and moving parts (i.e., variables) you have more sources for error. This example would exclude such operations as progress reports and inspections - those are more like motivators.
A wonderful, simple video presentation produced by Veronica Peng follows which focuses intelligently and usefully on the applicable parts and implications of CHAOS. A hyperlink to this video follows:
http://www.slideshare.net/pys0209/chaos-project-management
*****
When it comes to CHAOS, the Standish Group might have made some procedural errors in its informal and slightly high-handed study, but there are some implications that are seriously worth considering.
Douglas E. Castle http://www.LinkedIn.com/in/douglascastle
Tweet 
No comments:
Post a Comment