- The Projectleaders newsletter
- Posts
- Fix Time to Fix Your Project
Fix Time to Fix Your Project
Why fixed scope projects don't work, and what to do about it
This week’s episode is presented by… me.
Jokes aside, I announced a few weeks ago that I’m building a project management course: Project Management Unraveled.
Project management has become way too complex. Project Management Unraveled is my answer to that. Built for small teams with big ambitions that want to get more stuff done.
Built on fundamentals & first principles
Guides you through defining, aligning, and planning
Full of templates, worksheets, and real-world examples
And above all, practical. Everything you need, nothing you don’t.
We launch next month. Register here to secure a special launch offer and let’s build your next project together.
Fixed scope is fiction
Most people fear deadlines, but I’m here to argue that they might be the answer to most of your project issues.
Before you cancel me, hear me out…
Last week we discussed priorities & constraints. Most projects start with a (way too) detailed scope and a top-down deadline of yesterday.
A team then breaks down the work, does some magic, and comes up with their best-educated guess. The sponsor & client call it crazy, and so the denial of reality starts.
Sounds familiar?
The underlying problem is uncertainty.
Projects are unique and one-off by definition, and that means there are unknowns. If there are unknowns, why would we plan like we know everything and then wonder why it’s wrong?
Let’s try a different approach.
Instead of starting with a scope and ending with a number, flip it around. Start with a number and work towards a scope.
Fixed time, variable scope projects are nothing new. But it’s an underrated way to get stuff done.
A personal example
Let’s take a hypothetical example where a guy tries to develop a project management course.
It’s hard to ship a course when there’s always time to add something, explain more, or do another revision of what you wrote yesterday. Without a deadline, there are no tradeoffs. No decisions. No forcing function.
By introducing a deadline (and announcing that), you know what you’re optimizing for. You have choices to make.
Will you add that other module, or film that introduction again where you had that toothpaste stain on your shirt? With a few days left, you’ll have to start making choices. You’d skip that interesting but not necessary module to make sure you don’t look like a fool in your intro.
Without that, you can always do more. And while you think you’re pursuing perfection, you’re actually creating a monster. Scope creep means more complexity, more money, and more time used.
In the case of a course, it becomes a showcase of everything you know rather than a solution to a problem. And customers pay to have their problems solved.
How you’ll know what to build
We’ve discussed in a previous newsletter that defining what to build is not the same as a full scope. You define the contours of it, not the nitty gritty.
Clients define what problem they want to be solved and what success looks like. Not what color the button should be - that’s your team’s job to find out.
If you have a clear project purpose, know the problem that you’re solving, and what a successful solution looks like, time will act as a forcing function. The urgency drives priority and focus.
Flexible scope means flexible on how you’ll solve the problem. It allows you to discover the details as you execute, instead of seeing that as failure.
If you had to, could you solve that problem in 5 steps instead of 7? I bet you can. That’s the power of fixing time. It doesn’t mean shipping bad work. It means tough choices, guided by first principles from your project definition.
Fixing time forces you to focus on progress, not (theoretical) perfection.
Why you should try it too
Before you dismiss this idea because your project or industry is different, hear me out. I’m not advocating for a rigid method here. You can apply this to any style of project management, and to almost every industry.
Sure, it’s easier with software than it is with building a skyscraper. You can’t decide to build a foundation for 30 floors and then “iterate” your way to 100 floors from there.
But what you can do is see the design & engineering as individual deliveries, with a fixed timeline for example. Think how you can apply this, not if.
Try it on something small and see if it works for you. You’ll be surprised.
Cheers,
Jasper