Agile and predictive project management: a simple overview

A company is moving its customer service to a new platform. The data migration has a fixed cutover weekend, a signed budget and a list of steps that must run in order. The self-service portal built on top of it has a launch date and a team, but nobody has agreed yet on which features it should offer.

Can both halves of the same initiative be managed the same way? They can, but no single method fits both well. The migration behaves like a classic, predictive project and the portal like an agile one. Most organizations carry both kinds of work at once, so the useful question is how to give each the method it needs without losing sight of the whole.

Scope, cost and time

A project sets out to reach a defined objective under constraints, usually a budget and a timeframe. Its three basic variables, scope, cost and time, are traditionally drawn as a triangle.

Scope is what the project has to deliver. Cost is what it may spend. Time is when it has to finish.

Scope is the hardest of the three to pin down, because it means turning an idea into something concrete. The client has a mental image of the result and the team has to build it, so the client’s expectations and the team’s need to converge early.

Once the scope is as clear as it can be, the work is broken down into smaller parts and the team estimates the effort each one requires, in hours and in money. Planning then arranges those parts over time according to the people and resources available.

Why the way a project is managed matters

Projects that meet all three targets at once are a minority. In the Standish Group’s CHAOS Report 2015, which covered software projects from 2011 to 2015, 29% finished on time, on budget and with a satisfactory result. Another 52% were delivered late, over budget or with less than expected, and 19% were cancelled or never used.

Part of that gap comes from how projects are run. Guides such as the PMBOK® Guide and the Scrum Guide collect practices that improve the odds, but they only help when the people applying them know them well and can adapt them to their organization. A project that is never completed loses the whole investment, so part of that investment is well spent on managing the project properly.

Turning the triangle upside down

Predictive and agile management work with the same three variables. What changes is which of them are fixed at the start.

In predictive management, the scope comes first. The team breaks it down into the tasks it requires and derives the cost and the schedule from them. This is the classic picture: a client and a supplier agree on what will be built, then negotiate price and delivery date.

In agile management, the triangle is turned upside down. Cost and time are fixed first, typically as a team of a given size working in short, regular cycles. Client and supplier then move forward together, deciding at each cycle what to build next, and the scope adapts as they learn.

Predictive: fix the scope, estimate cost and time. Agile: fix cost and time, let the scope adapt.

Each approach has a price. Our article on the advantages and drawbacks of agile and predictive methodologies goes through them one by one.

What agile methods have in common

Many agile frameworks have appeared since the Agile Manifesto of 2001. They differ in their practices but share a few traits:

• Transparency. Everything that affects the result is visible to the team, and often to the client too.
• Autonomy. The people doing the work know its needs best, so management leaves them room to decide how to do it.
• Measurement. Results are measured so that deviations in the process or the product show up early. Agile does not mean working without objective indicators: velocity, work in progress and cycle time are all numbers.
• Adaptation. The team can change both how it works and what it builds as the project reveals new information.

Scrum and Kanban

Of all agile frameworks, Scrum and Kanban have the widest following. They are not mutually exclusive, and many teams combine them.

Scrum

The name comes from rugby, where the whole pack pushes in the same direction. The current Scrum Guide, revised in November 2020, organizes the framework around three accountabilities, five events and three artifacts.

• The Product Owner orders the Product Backlog so that the most valuable work comes first.
• The Scrum Master is not a traditional project manager. They help the team and the wider organization understand and apply Scrum.
• The Developers are the people who build each increment, whatever their specialty.

Work happens in sprints of one month or less. The Product Backlog lists everything the product may need and keeps changing as the project advances. At Sprint Planning the team selects the part it will tackle, which becomes the Sprint Backlog, and by the end of the sprint it delivers a usable Increment that meets the Definition of Done. That increment is a finished piece of the product, not the whole project.

For a fuller introduction, read what Scrum is and how it works.

Kanban

Kanban started in Toyota’s factories in Japan. The word means roughly “visual card”, and the method arranges those cards on a board divided into columns. A basic board has three: to do, in progress and done. More detailed boards split a column into stages, so that “in progress” might become design, development and validation.

Kanban rests on two ideas. The board shows at a glance how many tasks sit in each column, and a limit on work in progress per column makes the team finish tasks before starting new ones instead of piling them up. A Scrum team can run each sprint on a Kanban board.

In ITM Platform, an agile project is planned on a board like this one. Each column is based on one of three status types (to do, in progress or completed), whatever name the team gives it, and swimlanes can separate types of work or sprints.

How to choose for each project

Before a project starts, decide which approach suits it instead of applying the same one to everything.

If the project…	Lean toward
Has a clear direction but an uncertain end product	Agile
Needs frequent feedback from users or the client	Agile
Repeats work the organization has done before	Predictive
Depends on a fixed sequence, permits or contracts	Predictive
Mixes parts of both kinds	Two projects in one program

Agile methods handle uncertainty well. They suit projects where you know which direction to take but not exactly what the final product will look like. Predictive methods work best when the result is known because similar work has been done before. If the aim is to repeat that work more efficiently, cutting cost or time or raising quality, a predictive approach is probably the right one.

Using agile for everything simply because it is newer is a mistake. Each way of working has its place.

Different, but with more in common than it seems

Some companies hesitate to adopt agile because they think the two models share nothing, or that agile projects cannot be measured. The differences are real, starting with the project manager’s role, which changes a great deal from one model to the other. In an organization that runs both, a project manager has to adapt to the method of each project they lead. The rest of the staff face the same challenge, since moving to another project can also mean moving to another method.

The common ground matters as much. In both models, constraints and expectations have to be managed openly, and the results of every project have to end up in one shared portfolio, whatever method each part of the work used.

How to make both models work together

The first step is to use a single tool for both kinds of project. When agile teams work in one system and predictive projects in another, the two cannot be compared, and someone has to rebuild the portfolio view by hand.

For a mixed initiative like the one in the opening example, it often helps to split it into two projects, one agile and one predictive, and group them in the same program. Each team plans with the method that suits its work, and the program reports on both together.

In ITM Platform, you choose whether a project is Waterfall or Agile when you create it. Waterfall projects are planned on a Gantt chart and agile projects on a board, and each type has a tracking view suited to its method, as fundamental project concepts explains. Both types carry a budget, costs and progress reports. A program can group projects of either type and gives them a shared budget, schedule and progress view, described in program management. Sprints can be enabled in both types as well, which gives a mixed program a common cadence.

Next steps

• Try ITM Platform and create an agile project and a Waterfall project inside the same program.
• See how programs and portfolio management brings every project into one view, whatever its method.
• Explore planning and monitoring, with Gantt charts and agile boards in the same tool.