by Phillip Smith
The discussion about which project management approach to use is irrelevant if the chosen approach is not implemented correctly. The IT industry, while relatively young, does have reasonably well thought out software development processes (SDP’s) that are mature and reliable. Taking shortcuts within an SDP is never a good idea.
Whether using agile or waterfall, always make sure your plan includes stable requirements, optimized design, and rigorous testing. You should never tailor out critical deliverables, breeze conditionally through tollgates, or attempt to support truly impossible timelines. It is better to execute in a reliable and true fashion and finish the project the right way, with quality. Stated another way, project managers should never use a difficult timeline or a low budget to justify chaos.
For example: in an agile approach, if you start with a very large scope and parse it into smaller components, and then execute all of the SDP phases for a single component prior to going in to the requirements for any other part of the scope, you will be running a great risk. The lack of definition of follow-on components, combined with the finality of having the first component implemented, will certainly lead to integration issues and rework.
It is much safer to sprint, in small sections, through all of your scope, and then sprint through all of your high level design. Make sure that you have a full understanding of the complete project, the architecture, and the high level design before you sprint through any of the build. You can use a proof of concept if it will help with requirements definition or with the design.
Once you’ve validated the complete set of requirements and high level design, it is appropriate to execute the delivery phases, specifically the low level design, then construct, test, and deploy component by component. With this approach you will gain the benefits of forcing all of the difficult conversations about scope, requirements, and solution to the front of the project, where it is appropriate to obtain stakeholder consensus. Then you are free to optimize the delivery path by carving it in to digestible bites.
There is still some risk, because there is construct activity for some components taking place prior to low-level design of other components. But implementing the agile approach as I described it above retains most of the benefits of risk adversity that are available to waterfall projects.