Hybrid Project Management: From Frameworks to Whatever works
“Hybrid” is one of those topics doing the rounds in recent times and, while I’m crazy about cars and this applies to the automotive industry too, I’m actually referring to the latest trend in the project management space: “hybrid project management”, to be more precise.
What is hybrid project management?
Hybrid, as per the definition in the dictionary, concerns something of a mixed character, made by combining two different elements, species or varieties. In the world of project management, it translates as project management approaches that combine two or more apparently contradictory (so some say…) delivery methods, such as the infamous Agile (adaptive approach) and Waterfall (predictive approach). For the record, I don’t like to see reality as pure black and white and, from my experience, there are several shades of grey between these two, however, extremes always tend to work better to make a point, thus, let’s say that hybrid would be a sort of “Wagile” approach.
At Wellingtone, we prefer the idea of “project management bricolage ” – the basis is the same, in the way that you could mix and match tools and techniques from several methods – however, it emphasises the role of tacit knowledge and it opens room for improvisation and novel practices in a DIY (do it yourself) mindset. Besides, it has a much cooler name if you ask me.
Why would I need it?
The emergence of hybrid approaches reflects a challenge that most organisations face when dealing with change, meaning, all the time: they need to be efficient and exploit opportunities while, at the same time, they need to be adaptable and explore new ventures if they are to stay relevant in the market. Have a look at ‘organisational ambidexterity’ and ‘dynamic capabilities’ research for more into this matter and allow me a synopsis: we need to pursue both.
It’s no wonder, then, that this idea has been cascaded down to projects. After all, many projects are started with aggressive timescales to be met but with a vague scope – an implementation risk that could be easier tackled by Agile approaches, conceived to address unknown requirements and accelerated delivery. However, going full-Agile can be too much of an ask for some organisations, particularly, if they are heavily regulated or are missing a culture that can support Agile. In these cases, a hybrid of agile and waterfall may be the better approach.
How to implement it?
With a hybrid approach, the project is managed in a more typical “waterfall” fashion - where scope and requirements are defined upfront - but the delivery of it (including development and testing) are broken down into iterations similar to scrum “sprints” as used in Agile methodologies.
领英推荐
You’ll then have the best of both worlds: on one hand, the structure and peace of mind of having a defined and agreed scope; on the other hand, accelerated delivery, empowering the delivery teams to manage their work within the sprint as they see fit. This approach, as described in PRINCE2 Agile or Choose your WoW, combines flexibility and structure, leading some authors to refer to it as 'structured’ or ‘disciplined’ agile. You define the boundaries/tolerances within each project that is expected to be run but leave the delivery team to decide on how to work within those boundaries. Everyone is happy.
Although it may sound simple, such an approach requires the right mindset and clear guidance on what is expected from the different roles. See below a set of hints and tips to get you started:
Hints and tips to do hybrid project management effectively
Interested in knowing more or assessing your maturity for a transition to new ways of working? Get in touch!
About Wellingtone
Wellingtone is a Project & Portfolio Management consultancy and training company. We enable our clients to make a step-change in their Project & Portfolio Management maturity.?Learn more ?about how we can support your organisation.
Written by Marisa Silva - Senior PPM Consultant, Wellingtone
Integrated Master Scheduler at Rolls-Royce
2 年I've been thinking about this a bit lately and I don't understand your position on this. Part of the supposed benefits of "agile" is that you don't wait for a complete set of requirements and scope before designing the solution, you start working with what you've got in order to start figuring out if the requirements are right in the first place. Your proposal appears to lose any benefit of agile here and then in the design phase (which depending on the industry) is probably the more predictable phase you've proposed an agile methodology which could just be seen as adding short interval controlif the product is not something which can be released to the customer incrementally. I'm starting to believe that an agile methodology is best applied at the start of the project where uncertainty is the greatest, and reversion to a "waterfall" methodology will add more value in the mid to latter phases as estimating risk is reduced. That's not to say "agile" can't be applied throughout, but there are industries where its not appropriate for the complete life cycle of the product within th projecte in my opinion.