The current issue of CIO Magazine arrived today with an article on Agile Project Management. A case study of Farm Credit and its adoption of Scrum. Some references to Standish statistics on project failures, a 2006 "State of Agile Development" report for The Agile Alliance and VersionOne. Some more bashing of the red herring of Waterfall and a general description of benefits and the process of deploying Scrum. Well worth the read.
Also in the mail was an article in Aviation Week & Space Technology on the new configuration of the Orion Crew Vehicle (formerly known as Crew Exploration Vehicle). I worked the proposal (both proposals actually) for the winning team as an architect of the Integrated Master Schedule, which is still pretty much in place going on a year after award. This article describes how changes are being made to the Service Module portion of the spacecraft, which sits between the Crew and the Upper Stage. The truss adaptor design has been radically changed, reducing weight, simplifying it configuration, testing, and manufacturing. Here's the components of the "flying machine" whose design and fabrication is "evolving." The truss is in the lower left corner of the picture.
Managing in the Presence of Uncertainty
Both articles describe the process of "managing in the presence of uncertainty." Change and uncertainty are part of any non-trivial project - be it business software or flight hardware. I odd thing though about the two articles is the builders of the Orion Crew Module know that uncertainty is part of the process, have a Plan and a Schedule for that Plan that deals with this uncertainty.
The three components of a project like Orion Crew are Cost, Schedule and Technical Performance. This technical performance is not "computer technical" but requirements compliance technical performance. Nature and unnatural variations in all three of these parameters are part of the project Plan and its execution. Waterfall is not a word found in that world. Spirals, Design Analysis Cycles (DAC), incrementally increasing maturity of all deliverables, testable and later flyable prototypes and other deliverables that represent iterative and incremental development.
These are all part of the "Risk Buy Down" process of any complex, emerging requirements system. The theory and practice of these types of systems is the domain of Systems Engineering, whose professional society is INCOSE.
So what's all the fuss about in the spacecraft development world about "agile." Not much really. No one in their right mind would commit to building anything but the simplest piece of "iron," without a multi-step Design, Develop, Test & Evaluation (DDT&E) process. It would just be bad Systems Engineering to follow the Water Fall approach of Design, Build, Test. Continuous feedback, continuous assessment of the outcomes, continuous discussion with the customer is part of the development process.
So why hasn't corporate IT figured this out. My not-so-humble opinion is that:
Corporate IT doesn't see the "Management of Projects" as a profession.
They see software development, database design, user interface deployment and the myriad of other "building" professions as the most important part. In the spacecraft building business, these disciplines - in both software and hardware (electronic and metal) - are of course critically important. But right along with them is the profession of Planning and Project Controls (PP&C). Much of the "grief" of project management in IT comes not from the theory of the processes - setting aside the red herring of Waterfall - but from the poor practices of project management. This of course is an opinion of a project and program manager. Having worked in both domains and many others where uncertainty and risk are the norm, I am biased to this view. As an observer of practice IT project management, I'm also biased by the lack of understanding of sometimes the most simple of concepts.
- Measure only physical percent complete - never confuse effort with results. The natural processes of Scrum are a near perfect fit for this paradigm.
- Explicitly "buy down" risk - if risk isn't identified, mitigated and these mitigations funded, then the risks will turn into issues.
- Only build what the customer wants - the customer measures success in "units meaningful to the customer."
Side by side articles on my desk - Scrum in IT and configuration 606 of the crew vehicle. One a new and emerging concept, the latter a standard way of developing complex, highly risky, multiple-vendor, wickedly complex products with as much software as there is real hardware.
Are we missing something in the IT world? Something that is already well understood in other worlds. Something that is "not new under the sun?"
