There is a myth in the agile community that the Big Design Up Front (BDUF) style project is what takes place in high ceromony firms.
I received a copy of The Space Shuttle Decision: 1965 - 1972: History of the Space Shuttle, T. A. Heppenheimer, Smithsonian Press, 2002. This book describes the orgins and development of the Space Transportation System (STS) that we call the Shuttle.
In it are details of early rockets. What struck me at first is how "agile" the early development processes were. Designs changed constantly. Missions changed as world events changed. The Cold War, Russian launch vehicles, failures of the early NASA (before NASA really) equipment.
What happens today is similar. We've had the original mission change (see page 54) on our current project to a more confined goal. We were going to Mars, now we're going to the International Space Station (ISS).
The current mission profile is shorter in duration and narrower in scope. Our previous design is lower down the page describing the total mission. The competition got better billing. That's a pretty big mission change. The plans for the first mission were detailed enough - probably too detailed - to show how and when specific hardware and software would be ready for operation along the way to 2020.
For contractors these types of changes happen all the time. They're part of the process. Being agile and adaptive is mandatory.
So Why All The Fuss over BDUF
Turns out the BDUF process does not actually exist in programs that look like they should be BDUF. Like building and flying manned spacecraft. But for some reason the development of large complex IT projects is "stuck" in the mindset that BDUF is both needed and loathed. Needed because of the commitments required to invest time and effort to build an application. Loathed because the changes - the naturally occurring changes - disrupt the plans of those developing the IT system.
It's as if something is missing from the thought processes of those managing the project. No one on our planning staff would ever be surprised that the customer changed a major portion of the project. They'd be whining of the work that was lost in building the plan, resource loading it, and synchronizing schedule with cost. But they would not be surprised. It's simply part of the process of doing what we do.
So why the disruptive outcome when an ERP customer changes their mind about something. The answer is...
The original plan and cost model was not "risk tolerant"
Simple as that. The project managers, the planners, the designers, the architects did not understand that the plan MUST tolerate changes, risks - both known and unknown and possibly unknowable. Without a risk tolerant plan, change - any change - becomes a disruptive event.
This disruption must be avoided at all costs. Some the first response is to do Big Design Up Front. Get it all down on paper, freeze the design, install rigorous change control and build the design straight through to the end.
Trouble is there is no project on the planet or on Mars that works that way.
Anyone who tries to control a project that way, or believes that a project should be controlled in that way will be disappointed when the first disruptive event arrives on their doorstep. This doesn't mean you have to be "extreme" about planning, but you have to be agile and adaptive and that starts with being risk tolerant.
