by Phillip Smith
Our clients rely on us, their IT team, to move them to a future state of better technology, better business process integration, and stronger competitive advantage. Our challenge is to get them there as quickly and inexpensively as possible.
Facing up to that challenge means that IT organizations must look for better ways to do things. New efficiencies can be found in many areas: staffing, training, monitoring of status, cost, tools, planning, and the list goes on. But here I’ll address the “approach”—specifically, the decision of whether to use waterfall or agile in the organization of your project events.
Project managers should avoid any personal bias toward waterfall or toward agile. Every project is different, and some will fit better with waterfall while others will fit better with agile. The decision is no different than deciding whether to use a hammer or a screwdriver: you need to know what problem you are solving, and then reach for the correct tool.
Consider Your Project’s Risk Tolerance
The waterfall framework encompasses phases, preset deliverables, and tollgates. It is risk-averse by design. Waterfall invests time and resources in the assurance of a well-controlled and sustainable project. When using a waterfall approach, projects complete an entire phase prior to planning and executing the next phase. In general, phases can be labeled as planning, requirements, design, construct, validate (test), implement, and support. Pre-defined deliverables (e.g. architecture, validation of required features, training plans, documentation, and many others) exist within these phases. There are also tollgates between the phases. Tollgates validate process execution, and they require corrective actions prior to authorizing a project to continue.
In an agile approach, project deliverables are accomplished in sprints. The term sprint implies speed and short runs. It is critical to organize these sprints in the correct fashion. Parsing the delivery portion of the agile project in to smaller pieces optimizes the critical path for the benefit of the client, and should improve time and cost, although there will be additional cost associated with integrating components one by one rather than as a whole. If the project can withstand the small additional risk in exchange for the overall lower time and cost benefits, an agile approach should be considered.
Consider your project’s tolerance for risk of rework, and the need to optimize the integration of all the components. If rework and integration costs need to be optimized, then you will want to go with waterfall. If your project can tolerate some risk of rework and additional integration cost, then consider the project’s:
- timing requirements,
- potential for breaking scope in to logical components,
- need to prove its business value
- need to prove its technology solution
- team capacity to deal with sprints vs. lump sum scope
Consider Your Timing and Resources
Project managers should also consider timing requirements for the various project components. Is it critical that they all be available on the same day, working as a complete solution, or it is better to have them implemented in phases?
You should also consider the project team. If the number of resources available for the delivery phases is small, the team may be more successful executing in sprints. If the number of resources is large, it may be appropriate to take on the entire scope all at once, so that integration testing will only need to be done one time.
Involve the Client
The client should be involved in the decision. If the project is expensive and high risk, it may be beneficial to put a small part of the scope in place initially, to allow a fair evaluation of the value of completing the remaining components.
A similar argument could be made when using newer technologies, when it is wiser to implement in sprints so that solutions can be proven and lessons can be applied to follow on components.
Finally, when you are making your decision about waterfall vs. agile, make sure it is a project-specific decision. Your organization’s standard SDP should be flexible to allow you to use one or the other.