To finish projects on time, start every single step as late as possible

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.

No rss on that blog, is this a thing now?

Harder to follow unless I go to Medium

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

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.

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

I don't understand why people do this instead of just writing a blog post and tweeting a link to that.

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.

Reminds me of Goldratt's Critical Chain - he of Theory of Constraints (TOC), The Goal, etc

Until you drown in technical debt.

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

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?

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.

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!