PPM Tips
If You Are Not Doing Hybrid Projects Yet, Chances Are You Will Be Soon
September 24, 2020

Traditional project management has been around for a while. Taylor’s scientific management, which provided a way to define, analyze and improve workflows, was published in 1911 and Henry Gantt created the Gantt chart in 1917 (in case you ever wondered why it’s called a Gantt chart).

But despite the long history, we still have a ways to go before a project methodology hits the mark. PMI’s pulse of the profession shows 69% of projects meet the original goals, 57% are on budget, and 52% are on time. As if 48% of projects coming in late isn’t bad enough, 15% completely fail. That’s a lot of lost time, money, and effort. Every one of those failed projects started with a vision that just didn’t turn out the way they planned.

Before we get too hung up on failure, remember that just like the Starship Enterprise – each of those projects aimed to go where no one had gone before. In normal business operations, process improvement specialists have the advantage of taking a repeatable process and improving it, but with projects, we are working with something different every time. That’s not an easy job.

Traditional project management

In his book Accelerate – Kotter suggests that every company started out as a network; a few individuals finding a way to get everything done. As the company grows, it needs more repeatable, controlled structure, so it adds a hierarchy. Often, the hierarchy takes over. Kotter suggests the most effective companies figure out how to run both at the same time — a network to quickly react to strategic changes, and a hierarchy to maintain the control and predictability for operations. I would argue that project management is the same. The best project managers understand what tools are available and choose the right one for the right job.

Maslow is credited with saying, “when all you have is a hammer, everything starts to look like a nail.” With all of the management innovations in the last hundred years, we have far more than a hammer today. So, let’s talk about the right tool for the job and discuss Traditional vs Agile Methodologies and where we might meet in the middle with Hybrid.

Traditional Strengths

Before you throw traditional project management out the window, look at some of the accomplishments it’s given us, such as:

These traditional projects are marvels at human ingenuity and each involved:

  • A clear design to understand what the end product would look like.
  • Planning to understand the materials, people, costs, and timeline, as well as how everything would fit together.
  • Strict controls during the delivery process to ensure needed tasks were completed and the project remained on time and on budget.
  • Quality assurance to ensure the project was delivering to original needed design requirements.

This works where:

Traditional project management

  • We know what the end project should look like. Construction is a great example.
  • We’ve done it before, so we know what’s needed.

The key here is efficiency. Since we know what the end will look like, and can figure out how to do it –finding the best way to integrate all of the different people to get the job done within in the shortest time/budget can be possible.

Agile Strengths

Since the Agile manifesto was drafted in 2001 and the concepts have been in place since the 1990’s, I don’t know that we can still call Agile new, but it’s much younger than the traditional approach. Where traditional project management focuses on the most efficient way to solve a known problem, Agile focuses on creating a solution when we may not completely understand the problem or what the end product will look like. Because of the unknowns in these projects, they are often funded in stages. For example you may approach the solution as – let’s see how much progress can be made in 3 months and then reevaluate from there.


These Agile projects involve:

  • Starting with a problem, an idea for a solution, and a set time and budget. Instead of scope being fixed like it is in a traditional project, we’ll see what the team can get done in the allotted time.
  • Creating a prototype quickly that will let everyone see and feel the ideas to speed the learning process.
  • Adjusting the prototype along the way, adding depth to the parts that work and letting go of the parts that don’t.
  • Evaluating progress at the end and deciding the next steps, i.e. it may be good enough or it is worth continuing to invest.

This works where:

  • We’re building something new – so we are not sure what the end solution will look like. This often applies to products like software, new reports, marketing, or training materials.
  • Innovation is important in finding the best way, and in building a solid architecture, to make it easier to support the product in the future.
  • The solution can be built in small increments. If you think about an analytics project – there are a lot of different pieces, but any insights found along the way could be used and add value now.
  • Instead of efficiency, the key is learning. There is no point in being on time and on budget if you’re building the wrong solution.


Combining the Two – A Hybrid Approach

This all sounds great on paper, right? Well as we know, most projects are not purely Agile or purely traditional. Rather than getting religious about which one to choose, good project managers can grab the right principles from either to apply to their projects.

In addition to the two approaches discussed here, there are other methodologies, such as Design Thinking, Lean Product Management, and Servant Leadership, that also have great concepts but we won’t get into the details of those this round. Join me on an upcoming blog for those.

Scrum, one of the Agile methodologies, breaks projects into 1-4 week Sprints. Each Sprint starts with a planning meeting where the team commits to what they will accomplish and then ends with a review where they show customers or stakeholders what was accomplished. Lastly, there is a retrospective, where the team reviews and makes recommendations on improving their overall process.

Similarly, every traditional project I’ve seen (and even most business units) have a weekly meeting to discuss progress and plan the next week. It’s a simple change to formalize these meetings to “Sprints” and commit to what will be done during the week, review last week’s commitments, and then take some time to think about how the process is working to build in continual improvement.

From a traditional perspective, it makes sense to incorporate at least some kind of a plan for an Agile component in the project by defining what will be done during the project (but understating it could adjust). Combining some of the traditional project skills, for example thinking about what resources will be needed outside of the team, risk management, or procurement, along with the required order of tasks are great skills to leverage for managing a project.

Whichever methodology you use, the key isn’t what you call it. It’s thinking about the results you want and what way will be best to deliver them.


One of the hard questions PMOs have to answer is how we keep leadership up to date. Whether projects lean more traditional or more Agile, leadership still needs to know:

  • What’s the problem, what’s the proposed solution, and how does it link to our overall strategy?
  • How much will it cost, how long will it take, and what overall resources will be needed?
  • How are projects progressing, where are we at, and are we on track?
  • Are we getting the results or value we originally planned for?

Since we’ve been reporting on traditional projects for quite some time, most teams already have that figured out and you can leverage many of the same components for Agile projects:

  • Just like a traditional project, Agile projects should have a clear problem, solution, and tie directly to strategy. Both should have a measure of expected value before they start.
  • As mentioned with traditional projects – scope is set, cost and duration are variable. With Agile the opposite is true. Cost and duration are fixed. Teams should talk about how much the expected investment is before the project starts and that should be baselined. At the end of the allotted time, teams should have a conversation with leadership about where they’re at and next steps.
  • You can use many of the same measurements with both projects (money invested, expected finish date). Where traditional projects will have weekly written updates, Agile projects should add value delivered each week (or Sprint for Scrum) and invite stakeholders to come see the value in reviews.
  • Both projects should be measuring value delivered. In Agile projects, that value should be delivered sooner, and then measured as the project goes (instead of having to wait till the end). Tying progress to value will align the Agile team with customer goals.


Between Agile and Traditional project management approaches, it’s easy to feel like the world is far more complicated. It is. Having to choose between a wrench, a screwdriver, or a hammer is more complicated, but it’s also far more efficient. As a project manager, a department manager, or a leadership team, understanding what tools are available gives you more flexibility to evaluate and decide the most effective methodology for each situation and how to create the right mix of tools for your organization. It may not be as simple as we would like, but when you learn how to use the right tools, you’re apt to be far happier with the end result. Learn more about our Agile Transformation support!


We Want You To Succeed!

We are here to help! Schedule time with Kim Essendrup, for a Free, 30-minute consultancy to discuss your agile transformation needs and best steps forward.

More from this topic

Together we fight for project success,
Live for happy teams,
Geek out on PM software, and
Love what we do!