Comments on: Why Your Senior Managers Like Serial Lifecycles http://www.pmhut.com/why-your-senior-managers-like-serial-lifecycles Sun, 12 Feb 2012 01:06:07 +0000 http://wordpress.org/?v=abc hourly 1 By: Kyosti http://www.pmhut.com/why-your-senior-managers-like-serial-lifecycles/comment-page-1#comment-15697 Kyosti Wed, 20 Jan 2010 23:30:18 +0000 http://www.pmhut.com/?p=4592#comment-15697 "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. “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.

]]> By: Owen Head http://www.pmhut.com/why-your-senior-managers-like-serial-lifecycles/comment-page-1#comment-15437 Owen Head Fri, 15 Jan 2010 01:26:53 +0000 http://www.pmhut.com/?p=4592#comment-15437 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. 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.

]]>