The Insider's Guide to Choosing a PM Method

“Can we ride at 5 am tomorrow?”

I thought he was joking.

But my buddy doesn’t joke when it comes to training.

“Dude. Why?!”

“Because the wind picks up at 11, and on race day I have to get up early too.”

Can’t blame him. He’s a triathlete.

The planned nature of a triathlon is like a perfect waterfall-style project. There are very few unknowns. All solo. You versus the clock. The distance is known, and the calories and pace are calculated months in advance.

Nothing is left to chance.

He even adjusts tire pressure to the air temperature on race day to save a watt (not joking).

Needless to say, I let him bike a loop before I joined after coffee at 8.

But he’d make a great project manager, don’t you think?

Well…

It depends.

Waterfall is 100% effective on 20% of projects.

Or 30%. I made that number up.

The number doesn’t matter. What matters is that it’s not a one-size-fits-all solution.

As a reader of this newsletter, you’ve probably seen your share of waterfall-style projects. It’s been around forever, and is still seen as “how it’s done”.

Or is it?

As software development matured in the 90s, more lightweight approaches to project management started appearing.

More adaptive, less predictive.

In 2001, a group of 17 software developers wrote the Agile Manifesto, which is a set of principles rather than a strict method.

The important thing to note here is that this was a group of software developers - they didn’t make cars, build bridges, or merged governmental organizations. More on this later…

Without digging into the basics of either one of them, it’s safe to say that they both have their raving fans. It’s a polarized world. Almost like politics - us vs them.

And I’m here to argue that it’s not that simple.

You’ll rarely do a pure waterfall or agile project

As with everything in life, the truth between two extreme opinions is probably somewhere in the middle.

I see Agile & plan-driven project methodologies as either end of a sliding scale, and I let the project decide where on that scale I sit.

How?

Let me walk you through the 6 factors that I consider.

The Stanford (?) project method selector

This model was shared with me by a reader a long time ago. I believe it comes from a Stanford paper, but I’ve never found its true source.

It really resonates with my approach, so I’m running with it. If you have the original source, please let me know!

Let’s walk through the factors 1 by 1.

Stability of requirements

How many changes do you expect? If you’re engineering a skyscraper, you can’t decide halfway through to add 10 extra floors. With software, an extra feature request the night before go-live is almost the norm.

The lower the stability of your arguments, the stronger the argument for an agile approach. You can’t plan what you don’t know about, right?

Organization’s culture

What kind of environment are you operating in? Some companies & teams thrive in ambiguity, big goals, and freedom. Others are built around order, structure, and a plan for everything in detail.

Neither of them is right or wrong. But ignoring the nature of the beast when selecting your project management approach is a recipe for disaster.

Team size

This is a tricky one. Agile is all about collaboration, and you can’t effectively collaborate with 100s of people without structure. It’s simply impossible for an individual to take all the moving parts into account.

Thus the larger the team, the more structure and planning you apply - right?

As a rule of thumb, yes.

But some of the largest organizations in the world work very agile. This is where the hybrid comes in - more on that later.

Consequence of failure

Although a website pushed live in the wrong font might give a designer a proverbial heart attack, it’s unlike to kill someone. But a medical trial? Or landing an airplane? Let’s plan that in minute detail, please.

The bigger the consequences of a (small) error, the more homework you’ll have to do before you execute. You can’t iteratively build a bridge and discover that the lanes don’t meet in the middle of the river.

In software, this is a different story. Sure, some stuff is harder to fix than others, especially if you’ve made wrong architectural choices. But it’s unlikely that you’ll have to re-do the entire project, or kill anyone.

More on this in the hybrid section later, too.

Worker skill levels

I don’t like this title from the model. I prefer to look at it as creative vs standardized work.

The effect is the same: the higher the need for creativity and problem-solving on the job, the harder it is to plan exactly. But work that’s either standardized or relatively easy to calculate lends itself to a planned approach.

Back to our bridge example: concrete strength & settling time = math. It’s easier to plan than knowledge work. That doesn’t mean that knowledge work is an excuse for not planning though!

What the model missed

There’s one huge factor that the model skips, but that we have to talk about: the sequential nature of some projects, or parts of it.

In other words: physical limitations.

Building a bridge is different from building software. And it seems like this is often lost in the “best method” discussion.

Quick story: I worked at a shipyard for a few years. Big industrial vessels - $150M projects, the type of stuff you see on the Discovery Channel. These vessels are built in 100s of small blocks, that are then stacked as legos to form a vessel.

If you have unlimited space, materials, and welders, you can build 100 of these blocks in parallel. But the stacking starts with the keel and ends with the helipad.

So even if all of the factors above tell you that you should go as agile as possible, please check if there is a physical need for a critical path or not.

You can’t make a baby in 1 month with 9 mothers, remember?

The hybrid approach

As I said earlier, the truth is probably somewhere in the middle. The “best” project management approach is the one that fits the project and its context.

Here are a few common examples:

Some large organizations run a planned operation on a company level, while their actual projects are run agile. This quickly becomes complicated program management, but that’s for another day.

On a very high level, it means that you have milestones or several individual projects in a planned order, while some parts are run more agile.

It can also be done the other way around. Big organizations let their business units or teams operate as individual and agile units, while within those units the projects are run very strictly planned.

On an individual project level, a hybrid approach is common too.

Let’s say you’re developing a new software solution. The overall project is planned. You have to do your research before you can design, and you need (some) design before you can start developing.

But the development itself is done agile. It looks like this:

And I could go on and on. There are 100s of different variants. None of them are wrong or right. And no one approach works every time.

Selecting the right approach is part art, part science. It’s not easy, but that’s why you’re making the big bucks 😉

Wrapping it up

Agile vs waterfall. If there’s one thing you take away from today’s newsletter is that it’s never this polarized. The approach you choose has to fit the project and the context it operates in.

To determine where on the sliding scale you should operate, look at:

1. Stability

2. Culture

3. Team size

4. Consequences

5. Required skills

6. Physical limitations

As a final note, please remember that the further you deviate from the “optimum” for your project, the more it will demand from you as a project manager.

If you have a team of 200 creatives spread around the world working in a high-risk environment, sure - you could do that without any planning.

But don’t call me if it goes wrong and say I didn’t warn you!

Jasper.

PS: Spam rates are slowly going down, thanks to all the replies I got. Keep them coming, it means a lot!

PPS: I still have the capacity for one more client project. Read more here!

PPPS: next week, we’re buying back your time. We’re going deep into building SOPs for all recurring activities within your projects!

PPPPS: If you wonder why I join competitive triathletes for a bike ride: their warmup is my workout. Or in this case, his easy endurance is my tempo training.