Hybrid project management – enjoy the journey!

As the world recovers from the massive travel disruption of the last few years, the only certainty has been that a flexible but well-organised approach to getting from A to B or Z is the most successful. Rigidity, for the sake of it, has not proven the best strategy for most in these times, as many stranded travellers will attest.   

The best-case scenario is that all flights connect perfectly. The travel budget covers every possible contingency, and the stunning hotel and surrounding attractions live up to their Instagram hype. Every step of the journey is seamless.  

And the worst case? Flight departure times overlap, too much time is spent sleeping on airport chairs and eating fast food, and the accommodation is disappointing and inadequate. All of which require cash and effort to rectify.  

Likewise, in an ERP implementation project, the approach is everything. When choosing a project management methodology, the key considerations include cost and budget, project type and size, timeline, the need for flexibility, and stakeholder collaboration.   

But does one approach fit all? Is it that clear-cut? We think not. What may work for users may not work for developers or stakeholders and even hinder project progress and performance.  

In their article ‘The impact of project methodologies on project success in different contexts,’ PMI (Project Management Institute) quote The Standish Group, who say the selection and use of a project methodology is one of the top ten contributing factors to project failure, and that closer attention should be given to the correct choice and application of the methodology and tools.  

The PMI article additionally references an assortment of researchers who say that ‘it’s not just using a methodology that leads to project success; it is the experience of using a project methodology and the ability to tailor to the context of a project that is linked to project success.’  

Conventionally, technology partners have been spoilt for choice when choosing project methodologies. You are likely familiar with the popular Waterfall and Agile methodologies, but here’s a quick recap if it’s been a while (feel free to skip to the next section if we’re telling you old news).    

The Waterfall method dates back to the 1970s. Using this methodology, project tasks and phases are completed in a linear, sequential manner. And each project stage must be finished before the next one begins. The stages generally include project requirements, analysis, design, construction, testing, deployment, and maintenance. Like a real waterfall, progress flows in one direction – so changing direction midstream and trying to swim back uphill is challenging – and best left to salmon. So, if you don’t have a crystal-clear vision of all requirements before you start, there’s little flexibility if you have a change of mind or requirement. 

The Agile methodology was born from a growing frustration with the linear Waterfall approach and the inability to adapt a project as it progressed. Accordingly, Agile takes a more iterative approach, allowing revisions to be made during the project instead of revisiting them at the end. Scrum, Kanban, Lean and DevOps project frameworks and methodologies were all spawned from Agile. All these similar approaches tend to involve short phases of work requiring frequent testing, reassessment, and adaptation throughout the project. While that may sound ideal, if you are on a tight budget or require lots of project documentation, Agile isn’t always the right choice.  

In choosing the methodology, the bottom-line decision is determined by your requirements and often the type of digital transformation you are undertaking. And it’s up to your technology partner to listen closely and appreciate what you want to achieve, i.e., your project goal, to help you decide what will work best for you. 

Earlier, we quoted PMI: ‘it is the experience of using a project methodology and the ability to tailor to the context of a project that is linked to project success.’ 

And we agree. Deep knowledge of and experience with a range of project methodologies should enable your partner to assess the project and recommend a forward path that successfully delivers your ‘must-have’ project outcomes.    

The ability to break down the stages of your project and understand the needs of those involved at each milestone is key to mapping the right methodology. And that methodology doesn’t need to be the same the whole way through – hence the evolution of the hybrid project approach. However, hybrid doesn’t mean a chop-and-change approach. 

It’s having the experience to carefully determine and align the best parts of several methodologies with the project stages to deliver the best outcome. So, for example, using Waterfall for the first two phases, then moving to DevOps-type sprints or iterations during the build, and then back to Waterfall for testing and user acceptance of functionality, training, and deployment.   

This hybrid approach requires the partner to have a firm understanding of the project objectives, and to document them carefully to determine which framework will be used – and when. To help overcome any internal resistance, a hybrid approach should be socialised at the sales stage and then worked through in detail with the project manager.  

As a partner, when it comes to successful delivery, hybrid is the passport to success for most projects.  

It drives a collaborative and engaging project approach where clients are involved in the ownership and improvement of the solution from the very beginning. They have a more fluid hands-on experience throughout much of the project, so there are no surprises and every opportunity to continually improve processes and outcomes. Compare this with a commitment to using just Waterfall and the rigidity that methodology can impose if applied to the entire project.

There’s little wriggle room for the client if the outcome is disappointing – without adding costs and generating delays and frustration on both sides.  

The final live solution is better too. The hybrid approach allows clients’ users to validate their predetermined (and agreed) expectations of each piece of functionality and mark it as acceptable. So, quality control is maintained and ticked off at every step.    

While it’s tempting to point the finger at one project methodology and blame it for a poor outcome, it can happen as easily with any other methodology. Poor or no structure, a lack of strong governance, no quality management system or internal audit process, and no checkpoints will all have a negative impact - no matter whether the methodology is Waterfall, Agile or hybrid. 

It’s that journey undertaken across a major continent in an unreliable van with no travel visas and insufficient funds. And no option to call home for help.