To finish projects on time, start every single step as late as possible(twitter.com)
twitter.com
To finish projects on time, start every single step as late as possible
https://twitter.com/fortelabs/status/770671266625785856
12 comments
Tiago here.
Roadrunner mode probably sounds a lot like the "crisis mode" we're all used to in most orgs, but it's actually more like supercompensation principle in all types of learning and training. You focus w/ everything you have, and then recover. Most orgs try to balance capacity, which results in this steady state of draining yet not really productive work. Theory of Constraints (which is what this thread is based on) says you should instead balance flow.
Roadrunner mode probably sounds a lot like the "crisis mode" we're all used to in most orgs, but it's actually more like supercompensation principle in all types of learning and training. You focus w/ everything you have, and then recover. Most orgs try to balance capacity, which results in this steady state of draining yet not really productive work. Theory of Constraints (which is what this thread is based on) says you should instead balance flow.
But why not say "starting working at the correct time" and address the issue head on vs. playing psychological games?
But what is the correct time? There is a whole subfield of project mgmt dedicated to exploring the theories around this question. And the line between "psychological games" and "psychology" is very thin, some would say non-existent.
Exactly my point, figure out the correct time and optimize for that, introducing what's effectively a neurosis seems kinda of neurotic way to work :)
But there is no correct time. That's a deterministic paradigm, whereas tasks are probabilistic events, with a distribution of possible points. Take a given task, and there are versions or scenarios where it takes 1x units of time, all the way to 100x. What critical chain does is help the worker play with the 3 sides of the PM triangle, time, budget, and scope, in a way that optimizes for the global throughput, not just their little local optimum.
That makes sense. Yep.
I seriously love Tiago's work. I don't know if anybody remembers, but I once wrote a post about procrastination that got to the frontpage of HN, a couple of years ago [1]. And since then, I've been basically reading everything relevant I've been able to get my hands on. (Here's a 'research review' of sorts: [2]).
I'd put Tiago squarely in my top 3-5 list of 'People Who Get It'. I highly recommend reading the rest of his work on the subject. [3]
__
[1] https://news.ycombinator.com/item?id=6468521
[2] http://visakanv.com/1000/0333-procrastination-pt1/
[3] http://www.fortelabs.co/blog
I'd put Tiago squarely in my top 3-5 list of 'People Who Get It'. I highly recommend reading the rest of his work on the subject. [3]
__
[1] https://news.ycombinator.com/item?id=6468521
[2] http://visakanv.com/1000/0333-procrastination-pt1/
[3] http://www.fortelabs.co/blog
His workshops[0] and online courses[1] look interesting, can anyone testify for them?
[0] http://www.fortelabs.co/workshops/
[1] http://www.fortelabs.co/design-your-workflow
[0] http://www.fortelabs.co/workshops/
[1] http://www.fortelabs.co/design-your-workflow
Yup I paid for Design Your Workflow (primary on the merit of his writing/insight) and I found it very helpful. It restructured my entire GTD system and just clarified my actions a lot.
No rss on that blog, is this a thing now?
Harder to follow unless I go to Medium
Harder to follow unless I go to Medium
Yeah, sorry about that. Next best thing is to sign up for email updates: http://www.fortelabs.co/blog
What about https://medium.com/feed/forte-labs ? Or did I miss something?
Isn't there a bit of a trick here in knowing when is "as late as possible" and not "too late"? Does this not require knowing exactly how long everything will take?
Another way of saying this is, do not waste effort by starting early on non-critical tasks. This all has to do with the critical path, the series of sequential, dependent tasks that determine the minimum project length.
Think of building a four-legged chair with multiple people (A, B, and C). You need to cut the wood into legs, a seat, and a back. You need to buy wood from the lumber yard, and buy screws and glue from the hardware store. You need to sand and finish the wooden pieces. You need to assemble the pieces with screws and glue.
The naive approach would be to have everyone go buy materials (and wait for everyone to get back), then together cut the wood (and wait for everyone to finish cutting), then together finish the wood, then together assemble the chair. This takes a longer time, because people will wait at each step, if there is any difference in task completion time between people. The length of each stage is the maximum of each individual task completion time.
The critical-path approach would be to send A to wood store. A returns and starts cutting leg 1, not waiting on B to return. B starts sanding the leg 1 completed by A, while A starts cutting the next leg, 2. C starts by finishing leg 1 after B finished sanding, while A starts cutting leg 3, and B starts sanding leg 2. Near the end, A has finished cutting the chair back, and goes to the hardware store to buy the screws and glue. A returns and starts assembling the chair as the pieces become ready.
Note how much earlier all the wood was cut in the naive approach. This is "early starting". In the critical-path approach, the cutting of each piece by A was delayed until it was needed by B for sanding. Buying the screws and glue was delayed until much later, when they were finally needed for assembly. That is because the critical path is:
(Buy Wood) -> (All Parts Are Finished) -> (Assemble Chair)
Other tasks can be delayed as appropriate, when doing so allows more resources to be spent on the critical path. I.e., wait until you are almost ready to assemble the chair before you buy the screws and glue, as time is better spent on getting those pieces finished!
I hope that makes sense.
Think of building a four-legged chair with multiple people (A, B, and C). You need to cut the wood into legs, a seat, and a back. You need to buy wood from the lumber yard, and buy screws and glue from the hardware store. You need to sand and finish the wooden pieces. You need to assemble the pieces with screws and glue.
The naive approach would be to have everyone go buy materials (and wait for everyone to get back), then together cut the wood (and wait for everyone to finish cutting), then together finish the wood, then together assemble the chair. This takes a longer time, because people will wait at each step, if there is any difference in task completion time between people. The length of each stage is the maximum of each individual task completion time.
The critical-path approach would be to send A to wood store. A returns and starts cutting leg 1, not waiting on B to return. B starts sanding the leg 1 completed by A, while A starts cutting the next leg, 2. C starts by finishing leg 1 after B finished sanding, while A starts cutting leg 3, and B starts sanding leg 2. Near the end, A has finished cutting the chair back, and goes to the hardware store to buy the screws and glue. A returns and starts assembling the chair as the pieces become ready.
Note how much earlier all the wood was cut in the naive approach. This is "early starting". In the critical-path approach, the cutting of each piece by A was delayed until it was needed by B for sanding. Buying the screws and glue was delayed until much later, when they were finally needed for assembly. That is because the critical path is:
(Buy Wood) -> (All Parts Are Finished) -> (Assemble Chair)
Other tasks can be delayed as appropriate, when doing so allows more resources to be spent on the critical path. I.e., wait until you are almost ready to assemble the chair before you buy the screws and glue, as time is better spent on getting those pieces finished!
I hope that makes sense.
There is a bit of a trick, but there are ways to make it easier. This is why in the tweetstorm I said the various parts of critical chain have to be used together, like forces balancing a building. In order to use median (most likely) time estimates and late starts, you also must use buffers. Instead of putting a little bit of safety margin at every little step, which explodes the lead time of the project w/out actually reducing risk (since delays are passed on and early finishes are wasted, as the table-building ex above explains), w/ buffers you pool all the safety margin together, where it can be used by whoever actually needs it. This works better because Murphy always strikes one part of the project disproportionately, not every step equally.
A story split in 37 tweets. Are some clients supposed to display that better than 1/, 2/ etc? What happened with Twitter's experiment with the 10,000 characters limit? https://news.ycombinator.com/item?id=10844306
> A story split in 37 tweets
I don't understand why people do this instead of just writing a blog post and tweeting a link to that.
I don't understand why people do this instead of just writing a blog post and tweeting a link to that.
Writing it inside Twitter means people can't share/like [retweet/favorite] the whole thing, but instead readers will pick specific parts they find most interesting. This gives the author more finely grained data about which sentences hit the mark for their audience.
Some sites (Medium comes to mind) allow readers to "highlight" sections, and even expose some threshold of those "highlights" to other readers. It may be that that feature isn't used enough to give authors much data, but I also wonder how much people use Twitter the way you describe.
This is exactly why I do it. One tweet in the stream always ends up resonating more than all others combined, and that gives me great insight.
All my tweetstorms of the past few weeks are "research" into a blog post I'm writing for ribbonfarm.com.
All my tweetstorms of the past few weeks are "research" into a blog post I'm writing for ribbonfarm.com.
Excellent point! I think there's something powerful about this format - blog posts with inline comments haven't worked that well, but there are often interesting discussions inside tweet storms
[deleted]
I've read this phenomenon described recently as "Fortune Cookie Wisdom"'ing a story.
It irritates me, but I'm old.
It irritates me, but I'm old.
I bet more people read more of the overall article if you publish it on Twitter. When you're faced with reading one big article, a lot of people would probably just skip it and not read any of it.
That's crazy talk. And the described PM is crazy beef-jerky resource abuse.
Think that it is just a different medium. Great for prototyping longer posts and thinking aloud as there is audience that sees your posts and can easily comment (parts) of them. Just like Hacker News comments.
Someone taught me, years ago, some technique (don't remember the name) where you would move all the tasks to begin in the last possible day.
Then, study the critical path to exclude all those "extra fat" that everybody includes in each task, assuring that the critical path is really critical, without hiding days/hours that would lead to procrastination in the critical path. Save it to an "emergency buffer".
Review if something else became the critical path. Repeat until stability arises.
Now, manage it, use your buffer when required, always take care if something else becomes the critical path (as everything will begin in the last possible time).
And, even if something becomes critical path and takes more time than required, you have some buffer...
Then, study the critical path to exclude all those "extra fat" that everybody includes in each task, assuring that the critical path is really critical, without hiding days/hours that would lead to procrastination in the critical path. Save it to an "emergency buffer".
Review if something else became the critical path. Repeat until stability arises.
Now, manage it, use your buffer when required, always take care if something else becomes the critical path (as everything will begin in the last possible time).
And, even if something becomes critical path and takes more time than required, you have some buffer...
Until you drown in technical debt.
Yes... If the PM don't let some time to that tech research about the "good enough" solution, the long run can be ugly.
Well yeah of course this is one way of thinking, in that if you could use the early times to do something else meaningful then why not, instead of wasting all of the time on that one single thing which might not be improved that much by all the additional time. That's true to an extent. A good example I can think of is the exam preparation for university entrance exams in China. It's a common practice by high schools to dedicate all three years to it at the expense of other useful developmental activities for students, which is an absolute waste. Just at most one year is totally enough, as proven by some alternative high schools.
However, I'd still argue that the problem of most people/individuals (especially as contrasted to huge organizations with loads of formal methodologies) is still delaying/procrastinating too much instead of too little. Too much pressure sucks, so is a rushed product/result compared with a carefully prepared one. So no, unless you really know very clearly what you're doing and how your plan will work out, which 99% of people have no clue about, start as early as possible, much earlier than your estimate, otherwise you'll definitely regret it. Though I acknowledge that this guy mostly talks about management methods, not productivity for individual endeavors.
However, I'd still argue that the problem of most people/individuals (especially as contrasted to huge organizations with loads of formal methodologies) is still delaying/procrastinating too much instead of too little. Too much pressure sucks, so is a rushed product/result compared with a carefully prepared one. So no, unless you really know very clearly what you're doing and how your plan will work out, which 99% of people have no clue about, start as early as possible, much earlier than your estimate, otherwise you'll definitely regret it. Though I acknowledge that this guy mostly talks about management methods, not productivity for individual endeavors.
Here is the full text:
1/ The key to finishing projects on time is to start every single step as late as possible (exactly the opposite of what most PMs do)
2/ First, because only progress on the critical path matters for final delivery, therefore all other starts are distractions
3/ It would be like spending hrs on a huge dinner prep by making all the side dishes, only to realize u forgot to pre-heat oven
4/ Second, starting early doesn't mean you'll finish early. Parkinson's Law: the task simply expands to fill the extra space
5/ Third, even if u do finish a step early, that gain will be wasted: next person won't be ready
6/ Starting a step early actually has all sorts of negat conseq, which is why procrastination is evolutionarily & logically a good strategy
7/ Starting early increases likelihood u don't have all info and prereqs, making rework likely (i.e. estimate blowout)
8/ Starting early increases the surface area for interruption attacks (internal & external), since u "have plenty of time"
9/ Starting early explodes the amt of lead time not spent actually working (i.e. Touch time)
10/ 70-99% of task lead time is waiting time, queueing, pending confirmation, waiting on approval, learning, rampup, setup, etc
11/ Ppl complain about estimation being hard, but it's not "uncertainty". It's them starting things early due to supposed uncertainty!
12/ But maybe the worst effect of starting early is that ppl start late anyway. Who actually begins a step before they have to?
13/ So you get worst of both worlds: a LONG plan with huge lead times, which are ignored as ppl do everything last minute. Vicious cycle
14/Last reason early starts suck, is they give illusion of safety. But Murphy doesn't hit everywhere evenly, he concentrates chaos at 1 spot
15/ Irony is this is self-reinforcing: did you hit the deadline because u executed well, or because you had excessive safety (100-200%)?
16/ So person who adds the most excessive safety is rewarded for "hitting their estimate," as if estimating and executing are independent
17/ Late starts fix all this: when the step is "released," they have barely enough time to finish if they go at full speed
18/ This pressure helps them focus, get into flow, ignore distractions/interruptions, optimize for 1 thing, get it done!
19/ Procrastination isn't an issue, because they're already behind, since u also cut their estimated lead time in half (oops!)
20/ If they finish on time it's actually a cause for celebration, and the next person can actually take advantage of the time gained
21/ The PM knows what to focus on, since u start with few steps (critical path ones) and only gradually begin new ones as late as possible
22/ Another benefit: once crit path person passes hot potato, they're free! U don't assign them new work, that would be punishing perform.
23/ Late starts also help with resource contentions (the same person doing 2 steps), esp important in cross-funct creative teams
24/ Instead of "start everything NOW!" You're saying "U must not start anything until the last poss moment. Focus on the current task!"
25/ This helps ppl not multitask, since they only have one task at any given time, and it's late!
26/ Ppl are generally happier: focus + flow + roadrunner mode (only 2 speeds, 100% & 0%) + fast results = happiness for both emp & co
27/ ANOTHER benefit of late starts: u have much better estimation data, since lead time now more closely approximates touch time
28/ 3 main results of all this: throughout (output x sales) explodes, lead time per project plummets, and huge excess capacity is revealed
29/ U read that right: earlier u start steps, the later u deliver projects, the more excess capacity you're likely to have
30/ Why? Because the almost universal response to late projects is "we need more capacity!" False. U need to use what u have
31/ The busier everyone in your co seems to be, the more confident I am that you have tremendous, double-digit excess capacity
32/ To add insult to injury, emps in such companies also say they're "too busy to invest in productivity." Speed up the hamster wheel!
33/ BUT to use late starts, u also need buffers. Bec some steps do in fact go late, just not as many and not as late as u think
34/ And I don't mean buffers as a general concept, u need very precisely placed and sized buffers divided into zones, updated daily
35/ There is a buffer for every purpose: project buffers, feeding buffers, iteration buffers, bottleneck buffers. Gotta know which 1 to use
36/ The PM's job becomes easy: just watch the buffer penetrations. No need to do anything until it gets to Zone 3 or 2, all else is noise
37/ If u want to know where all this comes from, Critical Chain Project Mgmt: https://en.wikipedia.org/wiki/Critical_chain_project_managem...
1/ The key to finishing projects on time is to start every single step as late as possible (exactly the opposite of what most PMs do)
2/ First, because only progress on the critical path matters for final delivery, therefore all other starts are distractions
3/ It would be like spending hrs on a huge dinner prep by making all the side dishes, only to realize u forgot to pre-heat oven
4/ Second, starting early doesn't mean you'll finish early. Parkinson's Law: the task simply expands to fill the extra space
5/ Third, even if u do finish a step early, that gain will be wasted: next person won't be ready
6/ Starting a step early actually has all sorts of negat conseq, which is why procrastination is evolutionarily & logically a good strategy
7/ Starting early increases likelihood u don't have all info and prereqs, making rework likely (i.e. estimate blowout)
8/ Starting early increases the surface area for interruption attacks (internal & external), since u "have plenty of time"
9/ Starting early explodes the amt of lead time not spent actually working (i.e. Touch time)
10/ 70-99% of task lead time is waiting time, queueing, pending confirmation, waiting on approval, learning, rampup, setup, etc
11/ Ppl complain about estimation being hard, but it's not "uncertainty". It's them starting things early due to supposed uncertainty!
12/ But maybe the worst effect of starting early is that ppl start late anyway. Who actually begins a step before they have to?
13/ So you get worst of both worlds: a LONG plan with huge lead times, which are ignored as ppl do everything last minute. Vicious cycle
14/Last reason early starts suck, is they give illusion of safety. But Murphy doesn't hit everywhere evenly, he concentrates chaos at 1 spot
15/ Irony is this is self-reinforcing: did you hit the deadline because u executed well, or because you had excessive safety (100-200%)?
16/ So person who adds the most excessive safety is rewarded for "hitting their estimate," as if estimating and executing are independent
17/ Late starts fix all this: when the step is "released," they have barely enough time to finish if they go at full speed
18/ This pressure helps them focus, get into flow, ignore distractions/interruptions, optimize for 1 thing, get it done!
19/ Procrastination isn't an issue, because they're already behind, since u also cut their estimated lead time in half (oops!)
20/ If they finish on time it's actually a cause for celebration, and the next person can actually take advantage of the time gained
21/ The PM knows what to focus on, since u start with few steps (critical path ones) and only gradually begin new ones as late as possible
22/ Another benefit: once crit path person passes hot potato, they're free! U don't assign them new work, that would be punishing perform.
23/ Late starts also help with resource contentions (the same person doing 2 steps), esp important in cross-funct creative teams
24/ Instead of "start everything NOW!" You're saying "U must not start anything until the last poss moment. Focus on the current task!"
25/ This helps ppl not multitask, since they only have one task at any given time, and it's late!
26/ Ppl are generally happier: focus + flow + roadrunner mode (only 2 speeds, 100% & 0%) + fast results = happiness for both emp & co
27/ ANOTHER benefit of late starts: u have much better estimation data, since lead time now more closely approximates touch time
28/ 3 main results of all this: throughout (output x sales) explodes, lead time per project plummets, and huge excess capacity is revealed
29/ U read that right: earlier u start steps, the later u deliver projects, the more excess capacity you're likely to have
30/ Why? Because the almost universal response to late projects is "we need more capacity!" False. U need to use what u have
31/ The busier everyone in your co seems to be, the more confident I am that you have tremendous, double-digit excess capacity
32/ To add insult to injury, emps in such companies also say they're "too busy to invest in productivity." Speed up the hamster wheel!
33/ BUT to use late starts, u also need buffers. Bec some steps do in fact go late, just not as many and not as late as u think
34/ And I don't mean buffers as a general concept, u need very precisely placed and sized buffers divided into zones, updated daily
35/ There is a buffer for every purpose: project buffers, feeding buffers, iteration buffers, bottleneck buffers. Gotta know which 1 to use
36/ The PM's job becomes easy: just watch the buffer penetrations. No need to do anything until it gets to Zone 3 or 2, all else is noise
37/ If u want to know where all this comes from, Critical Chain Project Mgmt: https://en.wikipedia.org/wiki/Critical_chain_project_managem...
And here it is reformatted into paragraphs:
The key to finishing projects on time is to start every single step as late as possible (exactly the opposite of what most PMs do). First, because only progress on the critical path matters for final delivery, therefore all other starts are distractions. It would be like spending hrs on a huge dinner prep by making all the side dishes, only to realize u forgot to pre-heat oven.
Second, starting early doesn't mean you'll finish early. Parkinson's Law: the task simply expands to fill the extra space. Third, even if u do finish a step early, that gain will be wasted: next person won't be ready. Starting a step early actually has all sorts of negat conseq, which is why procrastination is evolutionarily & logically a good strategy:
* Starting early increases likelihood u don't have all info and prereqs, making rework likely (i.e. estimate blowout)
* Starting early increases the surface area for interruption attacks (internal & external), since u "have plenty of time"
* Starting early explodes the amt of lead time not spent actually working (i.e. Touch time)
70-99% of task lead time is waiting time, queueing, pending confirmation, waiting on approval, learning, rampup, setup, etc. Ppl complain about estimation being hard, but it's not "uncertainty". It's them starting things early due to supposed uncertainty! But maybe the worst effect of starting early is that ppl start late anyway. Who actually begins a step before they have to? So you get worst of both worlds: a LONG plan with huge lead times, which are ignored as ppl do everything last minute. Vicious cycle.
Last reason early starts suck, is they give illusion of safety. But Murphy doesn't hit everywhere evenly, he concentrates chaos at 1 spot. Irony is this is self-reinforcing: did you hit the deadline because u executed well, or because you had excessive safety (100-200%)? So person who adds the most excessive safety is rewarded for "hitting their estimate," as if estimating and executing are independent.
Late starts fix all this: when the step is "released," they have barely enough time to finish if they go at full speed. This pressure helps them focus, get into flow, ignore distractions/interruptions, optimize for 1 thing, get it done!
Procrastination isn't an issue, because they're already behind, since u also cut their estimated lead time in half (oops!). If they finish on time it's actually a cause for celebration, and the next person can actually take advantage of the time gained. The PM knows what to focus on, since u start with few steps (critical path ones) and only gradually begin new ones as late as possible.
Another benefit: once crit path person passes hot potato, they're free! U don't assign them new work, that would be punishing perform. Late starts also help with resource contentions (the same person doing 2 steps), esp important in cross-funct creative teams. Instead of "start everything NOW!" You're saying "U must not start anything until the last poss moment. Focus on the current task!"
This helps ppl not multitask, since they only have one task at any given time, and it's late! Ppl are generally happier: focus + flow + roadrunner mode (only 2 speeds, 100% & 0%) + fast results = happiness for both emp & co.
ANOTHER benefit of late starts: u have much better estimation data, since lead time now more closely approximates touch time.
3 main results of all this: throughout (output x sales) explodes, lead time per project plummets, and huge excess capacity is revealed. U read that right: earlier u start steps, the later u deliver projects, the more excess capacity you're likely to have. Why? Because the almost universal response to late projects is "we need more capacity!" False. U need to use what u have. The busier everyone in your co seems to be, the more confident I am that you have tremendous, double-digit excess capacity.
To add insult to injury, emps in such companies also say they're "too busy to invest in productivity." Speed up the hamster wheel! BUT to use late starts, u also need buffers. Bec some steps do in fact go late, just not as many and not as late as u think. And I don't mean buffers as a general concept, u need very precisely placed and sized buffers divided into zones, updated daily. There is a buffer for every purpose: project buffers, feeding buffers, iteration buffers, bottleneck buffers. Gotta know which 1 to use. The PM's job becomes easy: just watch the buffer penetrations. No need to do anything until it gets to Zone 3 or 2, all else is noise 37/ If u want to know where all this comes from, Critical Chain Project Mgmt: https://en.wikipedia.org/wiki/Critical_chain_project_managem...
The key to finishing projects on time is to start every single step as late as possible (exactly the opposite of what most PMs do). First, because only progress on the critical path matters for final delivery, therefore all other starts are distractions. It would be like spending hrs on a huge dinner prep by making all the side dishes, only to realize u forgot to pre-heat oven.
Second, starting early doesn't mean you'll finish early. Parkinson's Law: the task simply expands to fill the extra space. Third, even if u do finish a step early, that gain will be wasted: next person won't be ready. Starting a step early actually has all sorts of negat conseq, which is why procrastination is evolutionarily & logically a good strategy:
* Starting early increases likelihood u don't have all info and prereqs, making rework likely (i.e. estimate blowout)
* Starting early increases the surface area for interruption attacks (internal & external), since u "have plenty of time"
* Starting early explodes the amt of lead time not spent actually working (i.e. Touch time)
70-99% of task lead time is waiting time, queueing, pending confirmation, waiting on approval, learning, rampup, setup, etc. Ppl complain about estimation being hard, but it's not "uncertainty". It's them starting things early due to supposed uncertainty! But maybe the worst effect of starting early is that ppl start late anyway. Who actually begins a step before they have to? So you get worst of both worlds: a LONG plan with huge lead times, which are ignored as ppl do everything last minute. Vicious cycle.
Last reason early starts suck, is they give illusion of safety. But Murphy doesn't hit everywhere evenly, he concentrates chaos at 1 spot. Irony is this is self-reinforcing: did you hit the deadline because u executed well, or because you had excessive safety (100-200%)? So person who adds the most excessive safety is rewarded for "hitting their estimate," as if estimating and executing are independent.
Late starts fix all this: when the step is "released," they have barely enough time to finish if they go at full speed. This pressure helps them focus, get into flow, ignore distractions/interruptions, optimize for 1 thing, get it done!
Procrastination isn't an issue, because they're already behind, since u also cut their estimated lead time in half (oops!). If they finish on time it's actually a cause for celebration, and the next person can actually take advantage of the time gained. The PM knows what to focus on, since u start with few steps (critical path ones) and only gradually begin new ones as late as possible.
Another benefit: once crit path person passes hot potato, they're free! U don't assign them new work, that would be punishing perform. Late starts also help with resource contentions (the same person doing 2 steps), esp important in cross-funct creative teams. Instead of "start everything NOW!" You're saying "U must not start anything until the last poss moment. Focus on the current task!"
This helps ppl not multitask, since they only have one task at any given time, and it's late! Ppl are generally happier: focus + flow + roadrunner mode (only 2 speeds, 100% & 0%) + fast results = happiness for both emp & co.
ANOTHER benefit of late starts: u have much better estimation data, since lead time now more closely approximates touch time.
3 main results of all this: throughout (output x sales) explodes, lead time per project plummets, and huge excess capacity is revealed. U read that right: earlier u start steps, the later u deliver projects, the more excess capacity you're likely to have. Why? Because the almost universal response to late projects is "we need more capacity!" False. U need to use what u have. The busier everyone in your co seems to be, the more confident I am that you have tremendous, double-digit excess capacity.
To add insult to injury, emps in such companies also say they're "too busy to invest in productivity." Speed up the hamster wheel! BUT to use late starts, u also need buffers. Bec some steps do in fact go late, just not as many and not as late as u think. And I don't mean buffers as a general concept, u need very precisely placed and sized buffers divided into zones, updated daily. There is a buffer for every purpose: project buffers, feeding buffers, iteration buffers, bottleneck buffers. Gotta know which 1 to use. The PM's job becomes easy: just watch the buffer penetrations. No need to do anything until it gets to Zone 3 or 2, all else is noise 37/ If u want to know where all this comes from, Critical Chain Project Mgmt: https://en.wikipedia.org/wiki/Critical_chain_project_managem...
Actually the PM BOK (Project Management Body of Knowledge) added Critical Chain in the 5th edition (current one is 6th edition).
https://4squareviews.com/2013/04/18/5th-edition-pmbok-guide-...
https://4squareviews.com/2013/04/18/5th-edition-pmbok-guide-...
Ah, so I guess he'd approve of the way I stumbled through university :)
I get what he's saying, but I can't imagine adhering strictly to this would be healthy. I've waited until the last minute to finish enough projects to know how stressful and anxiety-inducing it can be, and have enough experience to know that my time estimates are never accurate.
I get what he's saying, but I can't imagine adhering strictly to this would be healthy. I've waited until the last minute to finish enough projects to know how stressful and anxiety-inducing it can be, and have enough experience to know that my time estimates are never accurate.
I think the caveat is obvious here, that this is a method that applies to organizations with the help of a lot of formal methodologies, not individuals. For individual endeavors, it's always the right idea to start as early as possible, since without all the formal methodologies and structural control your estimate will always be literal laughing stock. Starting at the last moment is the absolute thing not to do for an individual who has no clear idea/experience about project management on her own(95% of people really). Not to mention another issue deadly enough on its own is that there's simply nobody supervising a hard deadline for your own projects, unlike within a company structure. If you do so, just wait for series of trainwreck to happen to you. I think this is proven by countless examples and experience already and nobody would really object to that.
My experience has shown that this is actually a much less stressful way to work. You're asking ppl to give estimates, with the caveat that there will be no penalty for not hitting it. Because all overruns will be absorbed in the common pool of safety margin, the buffer. This removes all the politics from estimating - the grandstanding, the making others look bad, the not-so-subtle pressures, the over-inflating to avoid looking bad. Estimates become what they're supposed to be: just estimates.
Also, notice that as hard as everyone says estimating is, they know EXACTLY when to start on that thing they're procrastinating on to finish it just before the deadline. Could it be this interesting phenomenon is a feature, not a bug?
Also, notice that as hard as everyone says estimating is, they know EXACTLY when to start on that thing they're procrastinating on to finish it just before the deadline. Could it be this interesting phenomenon is a feature, not a bug?
One amazing attempt to apply project management to software development can be found in the work of Steve Tendon at http://chronologist.com/blog/2012-09-25/critical-chain-proje...
I just wish more people would read Critical Chain books, there are several very interesting books that discuss this technique - including some that were released just last year.
amazon.com/dp/1934979074/
amazon.com/dp/1499660901/
amazon.com/dp/1498746039/
amazon.com/dp/0884271536/ - the original book that started it all
amazon.com/dp/1934979074/
amazon.com/dp/1499660901/
amazon.com/dp/1498746039/
amazon.com/dp/0884271536/ - the original book that started it all
Twitter? Really?! I guess that fits with the overall _missive_.
Well, 15m of tweeting on BART has led to dozens of high-value interactions, new followers, and insights for the upcoming blog post. Not bad as a case study!
Wow, I just don't know what planet this employer lives on where employees supposedly _enjoy_ sitting around idle until suddenly "holy crap tight deadline must crunch to make it!" Every once in a while, fine that stuff happens, but if a job were consistently putting me in "roadrunner mode" for every project, I'd be out of there in roadrunner mode too. Preferably before the anxiety and pressure turns into burnout.