d.Construct 2007 Live: Leisa Reichelt - Waterfall Bad, Washing Machine Good
September 7, 2007 at 5:41 AM
Eschewing Keynote, or even PowerPoint, Leisa Reichelt‘s slides are simple photos of Post-It notes, and this lo-fi approach carries through into the meat of her talk on project methodologies.
The old way of running projects — scope-design-build-test, also known as the ‘waterfall’ method — is outmoded, wasteful, and just doesn’t work, says Reichelt. Instead, make incremental improvements, quick-wins, and adopt more of a ‘washing machine’ project lifecycle. It’s difficult to argue with her when even the guy credited with inventing the ‘waterfall’ agrees: “I believe in the concept, but the implementation is risky and invites failure.” (W.W. Royce)
You can’t analyse experience, Reichelt adds; it has to be experienced — but by only testing right at the end, you risk discovering problems that can send you right back to the beginning. So why is it that today, this ‘waterfall’ methodology has become the standard project management process for tech companies, when it’s bad for both designers and humans?
The ‘washing machine’ approach — iterative, early releases, multi-disciplinary, collaborative, and involving actual end users — is far-better suited to the way we as designers think, allowing us to make design decisions right the way through the project instead of stopping at an arbitrary cut-off point, and furthermore does not assume that we know what we want to end up with when we start our projects.
The waterfall model may stem back to the Kennedy administration. A prominent bean counter dismantled defense procurement processes, and instituted the present Federal Acquisition Regulations (FAR). Secretary of Defense Robert McNamara may have been the most expensive and crippling bureaucrat of modern America history.
By mandating paper-evaluations of proposals, of demanding ‘competition’ for government contracts, McNamara created an entire edifice of bureaucracy. One observation of defense procurement procedures a decade ago was that no project could be completed in less than three years – so the military officer in charge when the project started would be rotated off the project before it ended. Thus no military careers were in jeopardy from a bad project.
The waterfall methodology was one deliberate attempt to meet federal guidelines. It has the advantage of clear milestones and delivery points – important considerations to contract officers, auditors, and bean counters. The technical people all work in the back room, it is the accountants that speak loudest in corporate and federal offices.
Realistically, the waterfall model has been used for decades. It defined careers, minicomputer and mainframe computer designs, and the details of federal procurement defined the Cobol-like interfaces still prominent in many business applications, from Lowes hardware stores in house system to custom accounting systems for small businesses. I swear you can see the 2-second delay built into to the text screen of the IBM System 360 terminals, so that users couldn’t detect by screen response time whether the system was busy. (Yesterday, ordering material at Lowes.)
For internal projects there is latitude to do what works best and cheapest. Where contracts are involved, fixed milestones and defined deliverables still have an advantage.
What I find hilarious is all these people saying the same thing and treating it like they invented it by naming it something else.
I’ve found that the “washing machine” model works very, very well when you have an engaged, cooperative client happy to work with you as a team. When you have an antagonistic, nervous, panicky, or controlling client, this development model can become the source of many headaches and make it more difficult to wrap up a project and a relationship with a client. I don’t think I’d ever try the iterative model with a client I didn’t already have a good working relationship with, because it’s much more difficult to CYA.