Why Your Senior Managers Like Serial Lifecycles
Why Your Senior Managers Like Serial Lifecycles
By Johanna Rothman
Serial lifecycles have lots of downsides. They don’t manage technical, schedule, or cost risk, they increase the duration of the project, and they don’t provide feedback early enough for the project team. One might ask, “If waterfall or phase-gate lifecycles are so bad, why do senior managers like them?”
Because the serial lifecycles are a simplification of what we do. They make more sense for a product with a physical component, because you do have to do some testing (certainly not all), once the product is built. But, especially for software, where we don’t have to wait until the end to get feedback–and should not wait until the end of the project to get feedback – serial lifecycles make sense only under certain circumstances. My general rule of thumb is to consider a serial lifecycle only if you have two or three people for no more than 1 month of work. Otherwise, use a different lifecycle.
But there’s an another, more insidious reason: serial lifecycles work for simple projects. The projects your senior managers worked on were much simpler than the products you’re working on now. With determined, dedicated people, your managers made those projects work. The lifecycle may not have helped them, but they managed to make the project work anyway. But your projects are not the same as your senior managers’ projects back when they were individual contributors or even project managers. Your projects are more complex.
Possibly the most seductive reason of all: Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction that’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by–the first possible, optimistic date.
If you’ve been struggling with how to explain to your managers, first understand their context. Then, maybe you can have a conversation.
The original article can be found at: http://jrothman.com/blog/mpd/2009/01/why-your-senior-managers-like-serial-lifecycles.html
Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference (http://www.ayeconference.com). You can see Johanna’s other writings at http://www.jrothman.com.
Not to be argumentative, but this seems like a vast oversimplification. It’s an undeniable face that thousands upon thousands of projects have delivered using waterfall techniques on-time, under-budget, and with the highest possible quality.
Telecommunications equipment providers have delivered huge real time network projects involving 100s of developers with 1+ year durations on the exact week laid out in the original plan for decades (no simpler than today’s projects in any way). They’ve done so while meeting extremely high quality requirements like 1.5 hours of downtime over 40 years in operation.
I agree that waterfall process isn’t for every situation. Agile is a better way to go for smaller more user interactive software deliverables. Too many in management want to toss all the old valuable learnings every time a new approach. It amounts to tossing the baby out with the bath water.
Like any other tool, a waterfall approach is only as good as the use it’s put to.
“Telecommunications equipment providers have delivered huge real time network projects involving 100s of developers with 1+ year durations on the exact week laid out”
Yeah. With 75% or more buffers on estimates, or with quite different content and internal cost than planned.
Telco engineer.