Are We There Yet?

This week’s episode is brought to you by… me.

Jokes aside, I announced a few weeks ago that I’m building a project management course: Project Management Unraveled.

The course will be everything your standard course is not:

• It’s not an expensive & theoretical 12-week thing.

• It’s not made for corporates that love pushing paper.

• It’s not full of what & why, leaving you hanging on the how.

Instead, it’s a practical course that gives you the first principles of project management. It shows you how you turn those principles into a project plan that helps you deliver successful projects with confidence.

I’m launching it in a couple of weeks, and you can be the first to know (and secure a couple of bonuses). Want to learn more? Join the waitlist here.

One of my favorite movies of all times: Shrek 2.

And the best scene?

For those unfamiliar with the scene, Shrek and Fiona are on a journey to a land far, far away (the actual name). Their friend Donkey is with them, and he’s bored.

So, like a toddler, he asks “Are we there yet?”. But not once or twice. More like 10 times.

Shrek’s answer? NO!

Until it’s yes.

And in that scene are two incredible project management lessons.

Lesson 1: Donkey’s question

As a project manager, you want to know the status of your project at all times.

But within that lies a risk. The risk of becoming a Donkey.

Asking if something is done 17 times a day is annoying and it kills team morale. The PM becomes more of a police officer, pointing at the schedule and saying something should have been done yesterday.

Yes, you should know where you are compared to your plan. But no, it should not become annoying or perceived as micromanagement.

You’ve assembled a capable team and have agreed on expectations (right?).

Let them take ownership, and give feedback if it’s not up to the agreed standard.

Lesson 2: Shrek’s answer

This is an even bigger lesson.

Notice how Shrek says no every single time, until he says yes?

He never says “we’re 42% there”.

42% of what? Kilometers? Vertical meters? Carrots eaten by the horse pulling the carriage?

Project managers are often obsessed with the completion % of their projects. But the completion percentage is a flawed metric.

Hear me out…

It’s subjective because two people have different opinions on whether a task is done 52% or 61%. And then you have two problems.

1. Which percentage is the correct one?

2. How does that compare to where you planned to be?

And once those two battles are over, you’re left with the real question that no one is asking.

“Great, but what does 57% complete mean for the future?”

It means that you are somewhere between start and finish. And at best, it gives you a theoretical idea of where you are compared to your initial plan.

But what if the earlier tasks were the easier ones? The ones with low uncertainty, or that take fewer hours to complete?

The whole point of knowing the completion % is to have steering information for the future. Is your plan still realistic? Do you need more time, or will you finish under budget?

A percentage only makes sense if all underlying units are standardized. Like a poll for example.

Each vote carries the same weight, so if 71% voted for option A it actually means something. But 71% of a task done means nothing. It tells you that part of the to-do list has been checked off, but it tells you nothing about what’s really left to do.

This would only hold true in project management if every task had the same:

• Complexity

• Uncertainty

• Resource needs

• Etc.

AKA: never.

So please, don’t fall for the trap. Don’t spend days comparing 52% actual to 54% planned.

A task is either done, or it’s not.

What should you do instead?

When you're planning a project, break down the tasks into manageable chunks that are either done or not.

But how far should you break down the tasks? There is no one-size-fits-all answer, but as a general rule, you should break the tasks down until they are:

• Specific: Each task should be clearly defined and have a measurable outcome.

• Achievable: Each task should be something that can be completed within a reasonable timeframe.

• Relevant: Each task should contribute to the overall goal of the project.

You give that task ONE owner, and let them do their thing.

The higher the trust and the lower the uncertainty, the bigger a task can be.

The goal is to find a level of detail that is right for the project and the team. Too much detail can be overwhelming and lead to procrastination, while too little detail can lead to confusion and missed deadlines.

Test it for yourself: if all you knew is done or not, do you know enough? If not, you need to break it down further.

That’ll do for this week - thanks for reading!

Cheers,
Jasper