I have found this particularly helpful for getting 'important, non-urgent' things done (especially on my personal to do list). Without a deadline, these high-impact strategic actions can languish due to a day-to-day focus.
Of course there is a balance: I have also seen many times that made-up unrealistic deadlines caused a lot of unnecessary suffering and demotivation. My view is that this balance is down to the skill of the individual manager in question and the specific context they are operating in: are we "delivering sustainable results to the business over time"?
Usually the pushback for deadlines (especially ‘fake’ once, not connected to external events) is that it’s a way to make us work harder. In reality - it’s just a way to make us more FOCUSED.
The triangle is a great concept, but often abused. Playing with the time ‘lever’ is the worst option in my opinion, that’s how you end up with never ending projects.
But the resources vertex is also problematic. I’ve experienced PMs using it, pushing back on deadlines with the argument that I can get more developers. They forget about “Brook’s law” - adding human resources to a late software project makes it later. It holds also for non-late projects - beyond an optimal number, adding more resources can be inefficient.
For example if it’s a medium sized project, and I already have 3 people working on it, adding developers from another team will just slow us down.
(If you have a tip on how to explain it to non-technical people, I’ll be forever grateful)
The best lever to use is the scope. A fixed deadline, with fixed resources, and a scope that is open to negotiation. The best PM/EM duos I’ve seen, worked that way.
One method to explain how you can't just always add more people is to compare it to building a hotel that needs to be completed in a week.
Sure, you could add 10 more people to the project (although even that is a trade-off since that assumes that whatever they're doing is unimportant, which I've never experienced), but it's going to take a ton of time to:
- Walk them through the blueprints so they know what they're building
- Understand the current status, timeline and who is working on what
- Look at all of the current tasks and see if they can be divided up even further as there are now more people (and this isn't always possible, of course)
- Get them ramped up on to the tools and help them understand what's been built so far
And, probably, doing all of that will make the project late before they've really started. And just replace "hotel" with "project" and it's pretty much the same thing.
From the triangle of options, I find playing with the scope to be the most efficient way of moving faster. I can't tell you how many times I've introduced scope bloat for no good reason, which slowed everything down.
As a PM, I'd recommend looking scope & time initially if things tend to repetitively go poorly (i.e. epics not finishing on time etc.). Resources are harder to influence on an epic-by-epic basis, particularly if you are 'just' a PM.
Let's reframe the dealine as a time-based goal. When will we try to have finished something? When shall we close the timebox and focus somewhere else? Then such a goal es very helpful.
This is a good read. There are people who can make a deadline for themselves, but usually, people just postpone tasks and they never get done. Deadline is important. It determines the scope.
It is absolutely true! Without taking this seriously, I wouldn't have launched my first coding course last week. Despite designing multiple courses over the past two years and perfecting the topics and the examples, I never launched anything.
I was overplanning. Once I gave myself a limited time to plan, I could focus on the recording, and once the first couple of videos were done, I could finally see the end of the process.
I organise my day by timeboxing all my tasks first thing when I get up. This manufactures some of the deadlines and helps me progress throughout the day; very useful.
Great article! If we consider the area of the triangle as a representation of quality, regarding overall expectations, then extending any side of the triangle leads to potentially missed expectations… if expectations are not reset.
The art of project management includes setting expectations while the science includes measuring progress, towards the agreed goals.
Setting deadlines only works when you know how to accomplish the task at hand. When there is a lot of unknowns at how to do particular task then deadline loses its restriction nature.
I have found this particularly helpful for getting 'important, non-urgent' things done (especially on my personal to do list). Without a deadline, these high-impact strategic actions can languish due to a day-to-day focus.
Of course there is a balance: I have also seen many times that made-up unrealistic deadlines caused a lot of unnecessary suffering and demotivation. My view is that this balance is down to the skill of the individual manager in question and the specific context they are operating in: are we "delivering sustainable results to the business over time"?
Yes, I agree: being able to wield the tool deftly is the key.
Usually the pushback for deadlines (especially ‘fake’ once, not connected to external events) is that it’s a way to make us work harder. In reality - it’s just a way to make us more FOCUSED.
The triangle is a great concept, but often abused. Playing with the time ‘lever’ is the worst option in my opinion, that’s how you end up with never ending projects.
But the resources vertex is also problematic. I’ve experienced PMs using it, pushing back on deadlines with the argument that I can get more developers. They forget about “Brook’s law” - adding human resources to a late software project makes it later. It holds also for non-late projects - beyond an optimal number, adding more resources can be inefficient.
For example if it’s a medium sized project, and I already have 3 people working on it, adding developers from another team will just slow us down.
(If you have a tip on how to explain it to non-technical people, I’ll be forever grateful)
The best lever to use is the scope. A fixed deadline, with fixed resources, and a scope that is open to negotiation. The best PM/EM duos I’ve seen, worked that way.
One method to explain how you can't just always add more people is to compare it to building a hotel that needs to be completed in a week.
Sure, you could add 10 more people to the project (although even that is a trade-off since that assumes that whatever they're doing is unimportant, which I've never experienced), but it's going to take a ton of time to:
- Walk them through the blueprints so they know what they're building
- Understand the current status, timeline and who is working on what
- Look at all of the current tasks and see if they can be divided up even further as there are now more people (and this isn't always possible, of course)
- Get them ramped up on to the tools and help them understand what's been built so far
And, probably, doing all of that will make the project late before they've really started. And just replace "hotel" with "project" and it's pretty much the same thing.
Great analogy, thanks.
From the triangle of options, I find playing with the scope to be the most efficient way of moving faster. I can't tell you how many times I've introduced scope bloat for no good reason, which slowed everything down.
I've had to learn this lesson so many times that I wrote about it recently: https://alexdebecker.substack.com/p/7-signs-of-scope-bloat-i-no-longer-ignore
As a PM, I'd recommend looking scope & time initially if things tend to repetitively go poorly (i.e. epics not finishing on time etc.). Resources are harder to influence on an epic-by-epic basis, particularly if you are 'just' a PM.
I also found this interesting and true and witnessed this happening many times
Let's reframe the dealine as a time-based goal. When will we try to have finished something? When shall we close the timebox and focus somewhere else? Then such a goal es very helpful.
That's a neat way of phrasing it! I like it.
This is a good read. There are people who can make a deadline for themselves, but usually, people just postpone tasks and they never get done. Deadline is important. It determines the scope.
My learning: https://glasp.co/kei/p/d438610448aa80ae6455
It is absolutely true! Without taking this seriously, I wouldn't have launched my first coding course last week. Despite designing multiple courses over the past two years and perfecting the topics and the examples, I never launched anything.
I was overplanning. Once I gave myself a limited time to plan, I could focus on the recording, and once the first couple of videos were done, I could finally see the end of the process.
Parkinson's law is a real time-saver!
I organise my day by timeboxing all my tasks first thing when I get up. This manufactures some of the deadlines and helps me progress throughout the day; very useful.
Great article! If we consider the area of the triangle as a representation of quality, regarding overall expectations, then extending any side of the triangle leads to potentially missed expectations… if expectations are not reset.
The art of project management includes setting expectations while the science includes measuring progress, towards the agreed goals.
Setting deadlines only works when you know how to accomplish the task at hand. When there is a lot of unknowns at how to do particular task then deadline loses its restriction nature.