I read a lot of articles every week in curating these round-ups, and not all of the content is produced by project managers. Probably less than half, most weeks. I see a lot of excellent content from non-project managers, and a lot of gibberish, in about the same ratio that I see from project managers. Not everyone shares the same understanding of project management methodologies, even among the practitioners. I typically use the general classifications “Established” or “Traditional” methods and “Agile” methods while some folks refer to a methodology called “Waterfall.” So, in an effort to over-simplify these three commonly referenced methodologies, I’d like to show five boxes, three different ways.
This first version is frequently referred to as “waterfall.” Back in the 80’s, there were a few projects that were actually run in a fashion similar to this. Most failed, because you have to monitor while executing, or you don’t catch the errors until it’s too expensive to correct them. Ever seen that poster of two teams, building a bridge from opposite shores of a river, getting to the middle and suddenly realizing that they’re not matching up? Yeah, like that.
The second version is the way most projects have been managed for the last few decades: complete the planning stage, and then move on to execution, while monitoring the process and quality as you go. This is especially critical in civil engineering projects, like the apocryphal bridge, but also for those where compliance with some external protocols or requirements is required, or where powerful stakeholders have to be satisfied, or where a lot of sub-contractors, inspectors, or other contributors are involved.
These days, many projects are being run using Agile methods: plan enough to begin execution, monitor more-or-less continuously, and re-plan based on what you learn as you go. This is great for certain kinds of software and consumer product development projects; not so much for civil engineering, pharmaceutical development, and other projects where the product will have a lot of potentially catastrophic failure modes and a very long life.
Note that the contents of the boxes have not changed. Poor execution will doom a project, no matter what else is going on. Initiating the wrong project or starving the right one for resources will generate a negative ROI, no matter how you manage it. And failing to monitor scope, schedule, cost, quality, and the mood of the stakeholders will burn any project to the ground. Simply re-arranging the boxes, like re-arranging the deck chairs on the Titanic, won’t change the outcome. But there will always be people who want to try.