Balance of Traditional Project Management & Agile Methodology
Between Agile and Traditional project management approaches, it’s easy to feel like the world is far more complicated. As a project manager, a department manager, or a team lead, understanding the strength of each methodology allows you to combine the right tools and management approach to your project.
Not Doing Hybrid Projects Yet? Chances Are You Will Be Soon.
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.
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 a 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 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 the Traditional vs. Agile Methodology and where we might meet in the middle with Hybrid.
Traditional Project Management 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, timeline, and 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 delivered to the original needed design requirements.
This works where:
- 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 the shortest time/budget can be possible.
Agile Methodology Strengths
Since the Agile manifesto was drafted in 2001 and the concepts have been in place since the 1990s, 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 Methodology 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 the 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 up 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 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. Additional Articles on these approaches under PPM Tips.
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 for 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 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:
- Like a traditional project, Agile Methodology projects should have a clear problem and solution and tie directly to strategy. Both should have a measure of expected value before they start.
- As mentioned with traditional projects – the scope is set, and 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, which should be baselined. At the end of the allotted time, teams should have a conversation with leadership about where they’re at and the 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 delivered value each week (or Sprint for Scrum) and invite stakeholders to come to see the value in reviews.
- Both projects should measure the value delivered. In Agile projects, that value should be delivered sooner and then measured as the project continues (instead of waiting 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. Choosing 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 to use the right tools, you’re apt to be far happier with the end result.
Learn more about our Agile Transformation support!