In project management, the core methodologies reign supreme, and hybrid project management methodologies are often regarded as blasphemy. Your team either has to be predictive or adaptive (depending on what camp you’re in), and there’s no room for blurring the lines, lest you be exiled from the realm of pure project management methodologies.
Project managers, and digital project managers in particular, have always been obsessed with methodologies. Why do we hinge everything we do around them—and do they really matter that much?
In this article I’m going to look at what hybrid project management methodologies are, the benefits of using one, and why they aren’t as subversive as they might seem to be.
What Is A Hybrid Project Management Methodology?
A hybrid project management methodology is a combination or two (or more) of the many, many different approaches to delivering projects. It's taking elements of a few project methodologies (often the waterfall method or one of the agile methodologies) and making it your own to fit the needs of your project.
And this notion of hybridizing or tailoring your project approach is not as uncommon or as criminal as some folks have led you to believe. In fact, a recent study from ProjectManager.com reported that 60% of the surveyed practitioners were using a hybrid approach or a tailored blend of many styles.
But before we get ahead of ourselves, let’s get aligned on the basics.
What Are Project Management Methodologies?
Project methodologies are frameworks or systems that are made of specific practices, techniques, rules, and processes that govern your project and your management of it. It generally involves core tasks, principles, or standards across project stages like project initiation, project planning, executing, monitoring, and closing the project.
There are a seemingly endless number of choices when it comes to selecting a project management methodology, but they can all be broken down broadly into two categories: Predictive methods like waterfall, and adaptive methods including agile, which has several branches and frameworks including Scrum and Lean, for example. Read more about the differences between waterfall and agile here.
I’m going to focus on the two big hitters that come up time and time again when talking about digital project management—waterfall, a more dependencies-driven traditional approach that works best when predictability is crucial, and Scrum Agile, the popular sprint-driven framework that is well suited for projects that require nimbleness to navigate the unknown at speed.
Why? Because despite the fact that Scrum is seen as the sensible choice for many digital teams and waterfall gets a bad rap as being outdated, rigid, and unrealistic, the fact of the matter is that both methodologies have specific benefits and project contexts that they are more suited for.
What Could A Hybrid Methodology Look Like?
The reality is there are many digital project teams and organizations that think they have adopted a single methodology, but are actually using a blend of methodologies to deliver their projects. For our purposes, let’s call these “accidental hybrids”.
For example, just splitting the work into two-week development sprints and doing a daily catch up does not immediately make you a Scrum team. Actually, it’s more akin to borrowing a few elements from Scrum to increase communication, urgency, and a spirit of iteration.
Likewise, just because you have specific milestone dates with known task dependencies doesn’t mean waterfall is the only option for you. Many Scrum teams groom their backlog and conduct sprint planning to deliver specific outputs by specific milestone dates.
Generally speaking, there will be elements from different methodologies that can be advantageous for a specific project or organization. There will also be elements from different methodologies that will limit the project’s ability to meet its goals. And that’s where designing a hybrid or tailored methodology comes into play.
But what does that even look like?
To place this in a tangible context, let’s say your project involves partner organizations that need requirements to be fully baked and committed to upfront before anything can be built. Meanwhile, your stakeholders are concerned about waiting until the end of the project to see the final output for the first time.
With a Scrum approach, you could allay your stakeholders’ “black box” concerns through sprint reviews and a team culture of building a potentially-shippable output in each sprint. But Scrum doesn’t generally favor the upfront requirements gathering that is needed from your partners.
With a waterfall approach, you could elicit and get approval on all requirements at the outset, and maybe even schedule some demos for stakeholders throughout the build. But you wouldn’t have a clean way of dealing with new requirements that come through stakeholder feedback.
One option might be to break the project up into phases, with each project phase tackling a component of the solution. Full requirements for each component would be gathered upfront, approved, and then built before moving on to the next component’s phase.
Visually, it might look like this:
But you also might want to design a hybrid approach that borrows the “best of” each methodology you’re considering.
For example, you might take upfront requirements gathering from a waterfall approach and then execute development using Scrum-style sprints and ceremonies that empower stakeholders to provide feedback into the product backlog where partner organizations could review new requirements as change requests.
That might look more like this:
Hybrid Project Management Methodologies As A Transition To Agile
Hybrid methodologies can also be a great interstitial phase as your organization or team is moving toward an agile way of working.
It’s not always easy to implement agile approaches fully or straight away in organizations, let alone at a large scale. Implementing agile requires an organization-wide change in operations and culture, and there are a lot of other factors involved. Agile approaches don’t necessarily mix with clients who want things like project scope, budget, and timelines defined up front.
With the struggles around implementing agile methods, a seamless move over to agile delivery is very difficult for a lot of organizations. There are lots of factors which make it tricky to implement:
- A high amount of client involvement can be disruptive to the agile process and interrupt carefully planned build phases, or sprints
- A general lack of understanding of what agile is and how it can be used for a particular type of project
- You might have a history of using a waterfall approach or another predictive methodology with a client, which might lead to hesitation for fear of straining the relationship
It’s easier to implement a gradual move over to adopting agile principles or the Scrum process. This situation calls for a hybrid, which can be a more realistic solution, at least during the transition.
Here’s an example of how you might adjust your project planning practices to be more agile using a hybrid approach.
Let’s say you are a digital agency who has served clients for decades using a fixed-price, waterfall-style approach. Clients would generally always know what they’re getting, when, and how much it will cost.
One day, you tell your clients you’re moving to agile ways of working, which immediately rings an alarm bell in their heads that they might not get anything they wanted after 7 sprints, creating cost and timeline overruns.
To make it a smoother transition, you might decide that your next engagement will use fixed requirements delivered in sprints on specific days. Perhaps high-level requirements gathering happens upfront, with more detailed planning prior to commencing the next sprint.
Then on the engagement after that, you might revisit the change request process with them and get them on side with the idea that change should be built into the process through sprint reviews and backlog re-prioritization instead, reducing the time spent gathering full requirements upfront.
Then a few engagements later, you might be almost completely agile, with your clients understanding the value of purchasing sprints as a way of being nimble now that they are further from a mindset of mistrust and needing to have everything figured out at the beginning and are more in a mindset of being the champion of value and outcomes alongside your team.
But I think the thread of steel and most important takeaway throughout all these examples is this: creating a hybrid is best when done deliberately. Instead of starting with a “pure” approach and then making exceptions along the way, start with the intention of making a tailored or hybrid approach that is a glove fit for your project.
Learn To Blend Project Methodologies The Right Way
Check out our mini course on Customizing Your Project Approach. You’ll get:
- A 40-minute deep dive into hybrid methodologies and the tailoring process
- A project methodology tailoring toolkit
- A template for documenting your tailored project approach
What Projects Are Best Suited To Hybrid Methodologies?
This isn’t a question of particular project types, exactly, but more a question of certain scenarios or circumstances around projects that might suit your project for a hybrid methodology.
Here are some situations where you might use a hybrid methodology.
- Maybe your software development team wants to use sprints, but your client isn't empowered to make decisions on the fly in your Scrum ceremonies, which slows your momentum to a halt.
- Maybe your team is comfortable with a traditional project management approach like waterfall, but your product just has too many unknowables. You can try to make a clean sequential plan that predicts the future to the exact date of delivery, but if you're building something that has a lot of ambiguity, you might not know what all the steps are and how long they're going to take.
- Maybe your team wants to use incremental iterations, but your project has some regulatory requirements that make rapid product increments just a little bit more complicated due to long audit processes, or even on a smaller scale.
- Maybe your agile team follows Scrum, but your vendor operates with Kanban (read about Kanban vs Scrum here)
- Maybe your engineering team has three week dev sprints, but your design team has two week sprints.
What Are The Benefits Of Hybrid Project Management Methodologies?
Why would anyone invest the time to tailor or hybridize their project approach?
- It can leverage and combine advantages from two different methodologies, like, for example, speed and predictability. Let's say you wanted to combine the mindset of creating potentially shippable products in two week sprints, but you have a project sponsor that wants to be a bit more hands off. You might feed multiple sprints into a few formal review milestones throughout your project life cycle.
- It can provide a familiar foundation in the face of special constraints. So for example, if the project team is accustomed to Kanban, but you've got specific elements in your project that need to be delivered on specific dates for a regulatory body to review, you might add milestones to your otherwise continuous flow.
- It can be used to build trust where there is uncertainty. For example, if your client doesn't believe that an agile approach will guarantee a specific scope, you might have an upfront discovery phase to outline the solution before diving into agile iterations. Pro tip: use these discovery session questions to make it a useful exercise.
- It's a great way to start exploring new ways of working as an organization. You might decide to have a tailored hybrid methodology for specific categories or tiers of projects, or even just one de facto custom methodology for all projects in your organization.
- As people get involved in conversations about project methodologies, their understanding of how projects are delivered will deepen. They might even appreciate your role as a project manager a bit more.
- A tailored methodology can become a competitive differentiator for your team or organization. If you successfully tailor your approach for delivering to a niche, like, for example, digital tools for junior mining exploration companies, you become more attractive than your competitors. Simply evolving how you work can be a differentiator against competitors who have a more static approach.
Challenges With Hybrid Methodologies
When defining your own hybrid process, there are some common challenges to look out for.
Wrong Team Culture
You need to ensure adaptability within your team and stakeholders, as well as a highly skilled team and group of stakeholders. These are people who can do their job effectively, even if parameters are changing.
Also, you need to have a strong record of great communication with all parties involved. Teams are going to be working in a new way, and they're gonna need to collaborate and share information effectively to keep the project on rails.
Wrong Organizational Culture
A flexible organizational culture that is ready to handle change is also key. Everyone needs to be willing to accept a little bit of methodological compromise to make your project succeed. Popular frameworks and approaches all have their own intrinsic benefits and efficiencies.
So as soon as you start swapping parts out, you start to compromise that original design. It's kind of like circuit bending your iPhone to have a USBC charger.
When teams are siloed, polarized, or lack the experience to work effectively outside of their comfort zone, those aren't great ingredients for a modified project approach. Also, if your goal is to placate a stakeholder, it might be worth pausing. Trying to satisfy a squeaky wheel without being strategic about it can endanger your ability to deliver project success.
No Process or Structure
A hybrid project management approach doesn’t mean ‘however we feel like doing it’. You still need to give your team guardrails and be strategic about how and why you’re tailoring the methodology.
Instead of following something, you’ll just go the complete opposite and have nothing concrete defined. The project becomes a mess because there is no way of working at all. If your team members don’t really know how they should be working, they might start going off on a tangent, and not focusing on what they should be doing.
On the flip side, don’t put processes in place for the sake of processes. Don’t add unnecessary documentation just because. Keep the process as streamlined as possible.
Defaulting To a One Size Fits All Approach
Beware the one size fits all approach. This is the idea that because something was successful once, it’s going to work for everything. Make sure you are thinking about every project as its own entity. There needs to be a cohesion in processes across an organization, however each project is different in their own right and needs to be treated as such.
No Team Buy-in
Your team might think that your hybrid is just one methodology pretending to be another. Like it's a marketing label more than a valid descriptor. Make sure to justify your decision.
That's why it's important to document your rationale. Also, reframe the benefits of each approach in the context of your specific project. What's important is doing what's right for the team and for the project, so make the team understand how it benefits them.
For example, if you can't use an agile project management approach, explain what would happen if the project was agile and explain what would need to change in order for the project to support agile.
How To Blend Project Management Methods To Create A Hybrid
Here are the steps for creating or deciding on a hybrid project management methodology, and how to make that usage successful.
1. Consider Project Goals & Context
For starters, sit down with your team and your key stakeholders to understand, prioritize, and rank what's important to your new project.
Here are some examples (this is not an exhaustive list!):
- Speed: Does this project need to get done quickly or nimbly? Do we need to be able to pivot?
- Cost: Are we trying to do this as cheaply and cheerfully as possible?
- Quality: Are we trying to make this perfect on the first go?
- Compliance: Are there external review processes that are going to impact the way that we work?
- Customer involvement: How important is it that we get customer feedback from end users along the way?
- Innovation: Is the purpose of this project to do something different from the norm and break new ground? Or is it more important that we have predictability in terms of fixed dates, fixed requirements, and fixed functionality?
Then it's worth considering your project context. Again, this is not meant to be an exhaustive list:
- How complex is the team makeup? Are these folks set up to work outside of their comfort zone?
- What is the culture of the teams and the organizations involved? Is it collaborative? Are they siloed? Are they flexible or rigid?
- How stable are the requirements? Are they going to stay the same or will they almost certainly fluctuate?
- Do we have regulatory requirements that we need to take into account or other partners that are going to be involved?
- Can the thing that we're building be iterated on at all?
- In terms of dependencies, do we depend on other projects or other projects depending on us?
- Are we going to have direct access to stakeholders and users?
- What methodologies have been used successfully before?
2. Pick a Methodology as your Starting Point
Having a place to start gives everyone a relatable foundation. But not all methodologies are created equal.
For example, Scrum is great for delivering in iterations, getting the customer involved, and failing fast and early. If I was building a first of its kind app within an emerging industry, I'd probably consider Scrum. But Scrum isn't always great for heavily regulated industries, fixed scope projects, or slow bureaucratic organizations.
Waterfall project management is great for predictability and setting expectations around specific dates and deliverables. It's also great for work that has interdependencies and it's good for fixed budget projects with specific outcomes.
But waterfall isn't great at handling change mid-flight (which throws your Gantt chart out of whack), getting feedback early and often, or efficiency in terms of creating documentation. So if your sponsor isn't really sure what they want, the waterfall methodology might not be the best fit.
Now that you've created your short list, how do you whittle it down to just one or one or two? There are many different tools and methods you can use for this. The important bit is that you are using your project goals and context to inform your decision.
3. Team Decision Making
Once you've picked a starting point, you need to put on your operational design hat and start making some decisions with your team.
Evaluate each component of your chosen methodology:
- What components of your methodology will work and what won't work for your particular project.
- What needs a substitution from another methodology or a modification to better suit your project parameters?
- What's missing; what needs to be added to this?
Let’s say you decide that planning poker and velocity based burndown charts won't be valuable for the customers, so you substitute them with more traditional dollars and hours estimates.
You might also decide that standups put too much strain on the teams that are working on concurrent projects, so you modify them to have standups happen only once per week.
The process of modifying and substituting can get more complicated quickly, so proceed with intentionality and care. Some of the questions you should be asking your team, your stakeholders, and yourself, include:
- What has to happen when?
- How does information need to be shared between stakeholders and team members?
- How do things need to be delivered and reviewed?
- How will people need to engage and interact?
- What tools and templates are appropriate versus what needs refinement?
Next, test this out in the wild. Some ideas here:
- Have a pre-mortem session for team leads where they can come and poke holes in your approach.
- Host a role playing practice session. Step through a project cycle or increment together to see how it's going.
- Start small and pilot it, and gather continuous feedback along the way.
As you’re doing this, make sure you are defining how you are measuring success or failure.
For higher complexity projects, document your rationale, map out your replacement workflow, evaluate the risk involved with the change, and build the outline of a playbook that you can use to get buy-in and onboard people who are involved in your project.
4. Get People On Board
The important thing here is that people understand the concept and the rationale behind it, and that they have a clear, usable document they can refer to.
Start by creating the playbook and include a brief summary that is easily digestible and communicates the approach to people. Then, share the approach and the rationale with your team leads, and present it to your sponsor or client and get key stakeholders on board. Finally, use this document to onboard your team as well as your vendors.
Treat the playbook like a living document and track the things you change along the way so that you can have a meaningful project post-mortem after the fact.
5. Measure and Refine
You've just created something new. It isn't battle-tested like the established methodologies, and your project parameters are unique enough that you decided to tailor a methodology in the first place.
So how do you know if your hybrid method is working?
- Make it a habit to check in with team members and stakeholders regularly, just to get some informal anecdotal feedback. How do they feel like this is going?
- Combine that with some formal feedback via surveys throughout the project
- Make sure that you're always measuring your KPIs and your success criteria
- Do a project retrospective and document the lessons learned
Hybrid Project Management Methodology Examples
Here are some examples of hybrids that have currency in the project management world that you may already be familiar with.
- Scrumban, which typically adds routine meetings and structure to an otherwise continuous Kanban style flow.
- Water-Scrum-Fall (or water-agile-fall), which is typically an iterative process that has predictive waterfall phases at the beginning and the end. In other words, a scrum sandwich.
- Wagile (or watergile), which typically has an upfront discovery and requirements gathering phase, followed by iterative design and development.
What’s Next?
Go forth and start tailoring your methodologies! If you’d like to learn more on the subject, we have a workshop available through our membership program, which you can find more about here. Read about another 'sandwich' hybrid methodology here.
Don’t forget to subscribe to The Digital Project Manager newsletter to keep up to date with all the latest methodologies and other developments in the project management world.