Optimise outcomes with hybrid project management

By Graham Gibson and Paul Thibodeaux

While much has been written about pros and cons of waterfall versus agile, the reality is often dictated by what needs to be delivered and in what environment. When working on technology infrastructure projects, the framework of waterfall with the ability to react to a changing environment in an agile way can be the ideal balance. And the opposite is true when working on application development. While incrementally releasing value is key, the business still needs some type of time and cost certainty. Adding the framework of waterfall to sprints could add just the right amount of structure without constraining flexibility. 

Business leaders are often keen to see a project become more “agile” by which they probably mean faster and cheaper. Associating the colloquial meaning of the word agile with the methodology can lead to misalignment. The most effective – and therefore cheapest and fastest – methodology depends on the needs of the project. 

Getting the terms straight 

It can be helpful to define meanings in top-level terms so that stakeholders understand why a project has been planned in a particular way. 

Waterfall is a traditional project management methodology, which follows a linear, sequential approach. It works well when the end goal is clearly defined, the requirements are stable and the path to delivery is well understood. This process can be fairly rigid, so the downside is that when things change, or if the requirements weren’t properly scoped at the start, it is difficult or even impossible to change the plan. 

Agile in contrast assumes that you won’t know all the answers up front, so it prioritises iterative development, customer feedback and flexibility. Created primarily for the software/app development environment where needs are changing, the project evolves over time. While it is very flexible, this format in its pure form just wouldn’t work for an infrastructure project where all the elements need to be in place. You can’t half build a (usable) bridge, but you could do a basic version of an app and then iterate with additional features. 

Our advice is always to be pragmatic depending on the needs of the individual project. Very often this means hybrid approaches that tailor delivery methods to the nature of the work itself. 

The best of both 

Hybrid project management isn’t about creating a middle-of-the-road compromise to placate everyone but please no-one. It’s about intelligently applying the right tools to the right parts of the problem. How it works will depend on the specific project, but to get the balance right, there are some key steps to consider: 

Tailor your methodology: First, understand what your minimum viable product (MVP) looks like. Run a proof of concept so that you can tailor the methodology to the needs of the organisation.  

Set parameters: Agree a minimum set of standards and processes by identifying where critical updates and decisions will be needed such as for investment committees and architecture boards submissions. 

Lean approach: Identify where inefficiencies and errors could occur within the process. Develop reporting and communication standards to help mitigate potential issues. Too many meetings or not enough discussions can be equally wasteful. Documentation standards must also have the right balance to be efficient.   

Develop qualification methods: Qualify projects at inception. Review key attributes around solutions to be delivered or developed. Within this take into account the wider business context and end-customer engagement as well as the delivery partners and resources available then apply the appropriate framework attributes needed to operate the project. 

Manage change: Establish a centre of excellence to provide support and resources to manage the new journey.

Iterative development: This is where the strengths of agile really play in as you can modify and improve as the project develops.  

Focus on outcomes, not process 

Within businesses there can sometimes be a misalignment between what the technology team knows and what the leadership see. Communicating success, milestones and the realities of a project are much more important than what methodology is used. Making sure from the outset that all the stakeholders are reassured about the elements of cost and speed should help to avoid misunderstandings about the language of project methodology.