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.
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"?
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.
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.