I’ve used the term “Big Bang Software Development” to describe a process where all of the software project scope is delivered at the same time. Traditionally it’s been called the waterfall model. Industry experts have compared the waterfall model to newer agile methodologies for how they differ in the approach to deliver software. But what about the impact these two different approaches have on a portfolio of project work?
Project Managers and Project Management Offices are impacted as well.
Project Management Offices (PMOs) and Portfolio Managers look for balance, priority, and results from the breadth of work they manage. The challenge they have is balancing multiple concurrent projects and maintaining a queue of prioritized work that is ready as projects close. Making adjustments or changes to work queues can be disruptive and expensive for the total work output of the organization.
Reprioritizing work has a cost.
Moving work is expensive because it may require stopping some work to complete other. Financially, this may make sense so the organization can go after the highest yielding project outcome. However, stopping a project is much more expensive in a waterfall approach than an agile approach. If the waterfall project is stopped then none of its output is delivered. It’s an all-or-nothing. It’s the Big Bang. There’s also a delay while teams reset to change over to a new project. Agile methods tend to focus on smaller work units with set delivery schedules (i.e. every 8 weeks). So changing in-stream work doesn’t have the same level of disruption.
Long delivery cycles create unanticipated organizational requests.
In the waterfall method work is delivered in uneven intervals because projects by nature have varying levels of scope. When this happens, stakeholders look for ways to combine projects to avoid the overhead of project spin-up. This places further pressure on PMO managers to deliver work consistently. It’s also a threat to project managers because it impedes on their ability to deliver the project under the original specifications.
Project value is based on the few, but project scope the many.
Prioritization is for complete projects rather individual elements that add business value. How often do you see projects loaded with many scope items that don’t produce large returns? Often times, the project has a few scope items that provide all of the financial return while others are there as special interest items. How much quicker would projects reach delivery if they contained only the essential items for return? That’s starting to sound a little like agile.
As I think about it, the agile method allows the PMO to be more nimble too.
With the agile approach work units are based on individual requests, not full project scopes. Think about how much more flexibility that allows PMOs with decisioning around priority. Making changes doesn’t have large effects of immobilizing big blocks of work which ultimately create larger gaps between work output deliveries. The big idea is that agile organizations can move and adjust individual work requests rather than project requests.
It’s a different mindset. But if you’re not there, you should be thinking about it.