Starting late — The Superior Scheduling Approach

How, despite being identical, one company delivers almost ten times the value of its competitor using flow-oriented project initiation.

15 min readDec 28, 2019

tl;dr: This post compares three different approaches to managing a portfolio of product initiatives (projects) — especially the part of when to start working on one portfolio item. The comparison is backed with simulations that indicate the massive impact different project scheduling approaches have on the value-generation capabilities. Corp A starts all the product initiatives as soon as they come up, and they consider themselves super-responsive. In contrast, Corp C has a huge backlog of great feature ideas that only start when their ‘delivery’ teams have finished another feature implementation. Corp C uses ‘Drum Buffer Rope’ scheduling and delivers 18 times faster and generates in 2 years almost ten times the value of Corp A.

This post dives into the comparison of three different scheduling approaches. Corp A: start as soon as possible. Corp B: WIP limited process steps with early starting. Corp C: Drum Buffer Rope scheduling with the latest possible starting point.

Let’s begin a little thought experiment. Consider yourself very lucky; you’ve won some million Euro in the lottery.

Since you’ve read that spending all that money to advance your standard of living does not increase your overall satisfaction, in the long run, you’ve decided to buy a pretty significant piece of a running business venture. You are confident that this will produce a lot more satisfaction for the rest of your life.

You’ve narrowed down the field of possible investment prospects to three. You are still in an early stage of business evaluation, but you already have the following data to compare the success of the potential investments. The firms are equal in the number of teams and employees overall. All three ventures operate a web-based software product that runs on a subscription model. Due to their similarities, you’ve figured out they have the same lever to increase their bottom line. In all three companies adding a new feature to the current product generates an additional 250 Euro per day for two years.

The returns performance

That sounds awesome, you think. With surprise, you realize how differently those three companies have performed over the last two years.

In two years, Corp C generated almost ten times the profit compared to Corp A.

Wow, you think. Corp C seems to be a safe bet. But how come there is such a massive difference in just two years? Since all three businesses operate on the same business model with the same amount of people and since all three companies have the same lever to increase their returns, you are intrigued why the results differ so vastly.

You take a closer look at which rate those three possible partner companies generated their returns.

You notice that Corp C pulls away after one quarter while Corp B increases the distance to Corp A after around one year but not with the same trajectory as Corp C. Moreover, you recognize that Corp A generated an uplift in returns after one and a half years (Q6).

This looks like three companies that generate their returns organically. All three ventures accumulate returns gradually, with Corp C by far exceeding the accumulation rate of the other two companies.

The delivery speed

You want to understand if there is a difference in how the three companies add features to their product. Maybe, you are afraid Corp C is turning out to be a scam. So, you start to investigate how long it takes on average for the three investment candidates to add a new feature to the product. Features are added to the product in all three companies by starting product initiatives. Inspecting the data astonishes you.

Corp C is almost 18 times faster than Corp A.

After checking the numbers twice, you start to wonder how on earth Corp C is capable of being so fast. In the end, Corp C is 18 times faster than Corp A. Again; Corp C is stealing the other contestants the show.

While Corp A delivered 12 features in 2 years, Corp B delivered 26. At the same time, Corp C delivered 85 features to the user. Since every feature adds 250 Euro per day to the company’s bottom line, it’s no wonder that Corp C is so well off.

The effort per feature delivery

Maybe the product initiatives for each new feature consume different amounts of effort in each company, you wonder. Maybe Corp A is running on a massive legacy monolith that makes it almost impossible to add new features?

You kindly ask to get additional data on the booked effort* needed on average to add one new feature to the product. You don’t believe your eyes.

* Booked effort is the actual effort recorded by the employees while doing the work. It has nothing to do with the effort estimation that sometimes is done in software projects.

All product initiatives consume the same average effort to get done.

On average, the effort that is needed for a product initiative to add a new feature is identical in all three companies. But how is it possible to have so vastly different results when it comes to delivery speed?

Of course, you know that high delivery speed equals better adaptability to changing market conditions, user needs, and regulations. So again, Corp C seems to be a very sweet deal for your lottery investment.

But now you are hooked. You need to understand what’s the secret behind Corp C’s success.

The process design

You assume that the processes must be different in all three ventures. Maybe Corp C runs on a super lean process that does the trick. But again, you seem to run into a dead end with your hypothesis. The delivery process is identical for all three companies.

In each firm, there is a pool of fresh feature ideas selected to be initiated and pitched. After the initiatives are accepted, the preparation and validation start. When this is done, the features are delivered and closed, including a communication statement sent out to the users.

Nothing special here, you think. You’ve seen similar processes many times before. Mysterious; it’s calling out the detective in you.

All three companies are looking forward to your investment. That’s why it is no big deal to ask all three companies to hand out some process monitoring data transformed into three neat simulations. Based on those simulations, you hope to find out the difference in how all three companies handle their product initiatives.

The simulation that solves the mystery

Based on each product initiative’s starting and finishing dates, you’ve created the following simulation.

That solves the puzzle! Corp C is superior, and now you know why. The only thing that lets Corp C pull away from Corp B and Corp A is the timing with which they start a new product initiative.

Corp A uses no particular scheduling mechanics.
All feature ideas are pitched, prepared, and delivered as soon as they come up. However, you recognize that no process step can handle more than ten feature initiatives parallel, and that’s why working on the 11th initiative is refused in all process steps. This is more an implicit effect of the people being wholly overwhelmed by more than ten initiatives than an explicit work in progress (WIP) limit.
Corp B strictly uses work in progress (WIP) limits.
This, for instance, avoids working on more than five initiatives in the ‘delivery’ phase in parallel.
Corp C applies a scheduling method called ‘Drum Buffer Rope’.
This company acknowledges that ‘delivery’ is that part of the product initiative process that takes the longest. Respecting that feature ideas may only ‘enter’ the process if the ‘delivery’ phase has the capacity available to work on that feature idea. Since ‘initiation’ and ‘preparation’ can be done faster than ‘delivery’, Corp C starts new initiatives at the latest reasonable moment. The started initiatives arrive in front of the ‘delivery’ phase just in time.

After all your investigation, you now know for sure that your lottery money will be well invested in Corp C. The simple scheduling method ‘Drum Buffer Rope’ applied by Corp C gives them a clear competitive edge.

Effects of ‘Drum Buffer Rope’ scheduling for portfolios

Of course, the apparent effects of ‘Drum Buffer Rope’ schedules have been outlined above. Applied to initiative or project portfolios, a delivery process is going to deliver significantly more value to the users while at the same time being more nimble and adaptive. Although counter-intuitive, this approach yields the benefit of reacting to market trends more quickly, giving a competitive edge when considering the cost of delay.

Looking at the delivery process, you reveal a lot of valuable ‘excess capacity’ that can immediately be used to improve the ‘delivery’ part of your process. Whenever people are no longer super busy maintaining senseless multitasking work, innovation sparks all over the company. This innovation may be directed at improving the overall process of value generation, or it may be directed at the customer’s needs both, of course, is highly welcome.

As soon as your delivery system no longer creates constant busyness for the people involved, the real impediments become visible more clearly, making improving the company’s performance even more straightforward.

How to switch to ‘Drum Buffer Rope’?

This post is not supposed to explain how to proceed step by step in elaborate detail. However, some basic things have to be in place to start seeing the benefits of this scheduling approach.

Step zero. Manage the project portfolio. I am not going to describe how but all the other steps will need some sort of active management for all those initiatives, projects, and features in your portfolio. I am not talking about some kind of committee. I am talking about deliberate management. This includes many decisions on what to start, to kill, which sequence to use, when to start, when to stop, and so on. All those activities and decisions need visualization; What is part of your portfolio, what is currently running, the respective success criteria for each element of your portfolio, and the portfolio as a whole.

Following, you’ll find the tangible steps to introduce the ‘Drum Buffer Rope’ schedule.

First, stop starting new projects. Yes, I know that is the hardest part, and I know the pressure to react to new ideas and changing demands immediately is always high. But please, take your time to look at the simulation again. You will be faster and more productive but only after you’ve emptied the queues.

If you want flow, stop the flooding. Sally Elatta *

For the second step, you have a choice. Do you want it the hard way or not?

If you want it the hard way, then stop all running projects that don’t have all the necessary ‘resources’ to run to the finish line in one fell swoop — and I mean all the resources. Usually, some teams or subject matter experts have to support many projects simultaneously. Since we aim for responsiveness and not for high resource utilization, we want to come as close to single-tasking and one-piece flow as possible. This is the hard way because this may hurt someone’s feelings, or it takes a lot of shared contexts to accept the decisions to ‘freeze’* projects. Maybe it helps to reflect on the simulations together.

* Thanks, Wolfram Müller, who brought that term to me!

If you want it the soft way, you finish the initiatives one by one as fast as possible without starting new projects. You will experience the increased delivery speed with every project that comes to an end. Unfortunately, this sometimes may take a year or more, and often the patience of senior executives does not cope with such a slow change when there is not enough shared context and interests.

The third step is to ‘install’ a ‘pull-signal’ that indicates when there is capacity available to ‘deliver’ a new initiative, feature, or whatever. There are several ways to create that ‘signal’. The most common way is to use a hole in the buffer to indicate available capacity. You can see that in the simulation. If the buffer is not filled, the right number of initiatives is started to fill the buffer — not more. The obvious question that I’m not going to answer in this post is the right size of that buffer. There is plenty of literature out there to get the buffer size right, and I’m going to direct you to some sources in the links at the end of this post.

Of course, there is always the need to inspect and adapt, which needs delivery, observation, measurement, reflection, and improvement.

But our capacity utilization!?

Usually, one of the first reactions when considering ‘Drum Buffer Rope’ schedules is the concerning question about the utilization of all the people in the process steps in front and after the ‘delivery’ process step since they are going to have spare time that will not be fully dedicated to the product initiatives.

The simulation clarifies that starting work too soon is bad, and high utilization is absolutely nothing to aim for — except in the delivery process step (which is the constraint process step of this whole value delivery process). High utilizations systemically create long project durations, busyness, and waste. I know that many companies aim for a high ‘resource utilization’. That’s why so many companies out there are Corp A’s. If you want to deliver more value in less time, screw broadband resource utilization. It’s that simple.

If you consider that all that ‘excess capacity’ is an excellent opportunity to “save cost”, be aware that only this excess capacity makes the smooth flow of work possible. Workers that wait for work are the safest way to increase responsiveness. That’s why high-performance companies call it “protective capacity”. (That does not mean that there is nothing to gain, but I want to avoid that the first reaction to the observation of excess capacity is to “reduce cost” which often means “fire people”.)

And by the way, be happy to have those problems. Every company has ‘excess capacity’ hidden behind all that busyness.

The underlying assumptions in this simulation

Each product initiative (project) delivers a feature to the product
Each feature adds 250 Euro in profit per day for two years as soon as the feature is released and communicated to the users (no bad apples in this simulation)
The average effort for each product initiative (project) is the same for all initiatives and all three companies (24,6 person-workdays)
Multitasking reduces the effort that can effectively be added to the initiative (due to coordination, dependencies, and context-switching)
The more items are ‘in process’ at the same time, the less effectively the process step adds value to the product initiative
Each process step has a particular capability to add effort to a product initiative. If there is more than one work item in a specific process step, the effort is spent evenly across all the initiatives in process subtracted a realistic ‘multitasking-penalty’ (based on experience)
Since all the initiatives generate the same value and need the same effort, the prioritization scheme is ‘first in, first out’

The limitations of this simulation

I am aware that this simulation does not fully represent your working reality. However, it offers a safe and fast learning environment where you can experience the effects of different scheduling mechanics without launching a huge change initiative in your company. :)

Be sure that the effects and the boundary conditions of that simulation are absolutely in effect in your company as well.

If you want to make the simulation more realistic, you can use the “spice it up” slider and add random variations to your simulation. But be aware that this makes it harder to reproduce the simulation results consistently. You can do a sensitivity analysis to have both predictability and randomization, but this exceeds the content of this post.

How to read the simulation

I know the simulation above is pretty ‘raw’, and it only shows some jumping dot’s with switching colors. Nevertheless, I thought it makes the point. The simulation was created with insightmaker.com, which is a donation-based web application.

Read on if you want to use the simulation to explain the ‘Drum Buffer Rope’ concept to someone else and if you need a bit more information on how to ‘read’ the running simulation.

In this image, you can see that all ten process steps have been mapped out on a simple kanban board that you read from left to right to see the ‘way’ a product initiative hast to travel to deliver a valuable feature for the user.

Each product initiative is indicated with a little rhombus that moves from left to right across the board. If the product initiative is worked on, the rhombus is green; if the initiative is waiting to be worked on, it switches to orange. Waiting may be due to the work of a particular process step needing to be finished or that the following process step is already ‘loaded’ and can not accept a new initiative ‘item’.

The thin grey line indicates with which process step a product initiative item is associated.

Each initiative needs a certain amount of effort from every process step to proceed to the next process step. Every process step has a specific capacity that can be added per workday. As soon as a process step has added ‘enough’ effort to an initiative, the process step is finished and proceeds to the next process step.

The item can only proceed if the following process step ‘accepts’ this item, meaning there is no explicit or implicit ‘rule’ that prevents the work from starting in this particular process step. A rule in that sense is a work in progress (WIP) limit or the process step being overwhelmed (which is also a WIP limit). The implicit limit is set to 10 items.

As soon as a work item is wholly done, it moves to the 10th step of the process and switches to gray.

Now and then, new initiative/idea ‘items’ pop up in the first process step. Whether a new item is created or not is based on a random event.

Ideas have an expiry date. If an item did not enter the process within 50 workdays, the ideas evaporate and can no longer be started. The simulation indicates this event by switching the rhombus to yellow and then making the item disappear.

The blue and red dots indicate the capability of any process step to add effort to the item. More dots indicate more capacity. The process step with the red dots has the least capacity of the whole process. This is the constraint process step.

Feel free to drop me a line if you need more information on reading the simulation. Feel free to play around with the more advanced simulation to see the impact of the different parameters of the simulation.

Why use simulations?

In one of my last posts, I’ve explained why I consider simulations valuable. Feel free to read through → Simulating the negative consequences of multitasking on flow, throughput, and value generation

On my account

Feel free to follow me on Twitter or LinkedIn to receive excerpts of related content regularly.

Let me know if this was valuable for you and if you would like to see other simulations.