I gave a talk last night at the Software Quality Group of New England about schedule games. During the talk, I explained how serial lifecycles don't manage technical, schedule, or cost risk. Serial lifecycles actually increase the duration of the project. And, serial lifecycles don't offer feedback early enough for the project team. (They only offer feedback at the end of the project.)
One of the attendees asked, “If waterfall or phase-gate lifecycles are so bad, why do senior managers like them?”
Serial Lifecycles Simplify the Work
Because the serial lifecycles are a visual 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, I use a different lifecycle.
Sometimes, Serial Lifecycles Work
But there's 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.
Serial Lifecycles Offer False Prediction
Possible 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 hat'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 your managers' context. Then, maybe you can have a conversation.
BTW, I offer the Create Your Successful Agile Project Workshop and Manage It! Pragmatic Project Management Workshop and many other workshops aimed at people who struggle with their agile transformation.