Positive vs Negative Buffer (i.e. Margin)
/For projects that require little to no innovation, eliminate time buffers. We call these “negative time buffers.” For these types of projects, work will expand to fill the time available for its completion when excessive buffer or margin time is added to the schedule. Pull the schedule ahead of target. Deposit that time into the time-bank. That time ahead of the target is the positive buffer.
All teams add buffer time to their schedules. Once added, people are reluctant to give it back. This is the problem with buffers.
Adding buffer makes sense when there are unknowns or innovation required in the form of invention. The team must consider risk in terms of what they don’t know, then how long it will take them to solve a difficult problem. The harder the problem, the more difficult it is to estimate.
When innovation/invention is required to solve a technical problem, we use Learning Cycles (LCs), in other words the number of try-it-fail-learn cycles you have to go through before finding a solution. We estimate the average duration of an LC (or experiment), then estimate the number of try and fail cycles we might need. The higher the risk, the more unknowns, the more cycles will be needed. Adding LCs are a form of schedule buffering on innovation projects.
Estimating Learning Cycles is logical from an engineering perspective. The situation in which it tends to fall down is when a team is faced with an aggressive target date. Take for example a case where we assume three LCs are needed, yet the last two LCs push the schedule past the target date.
The classic management solution to this schedule problem is easy, just delete two Learning Cycles. Tell the team they need to “Be right the first time” and to “Stop being so negative, else it will become self-fulfilling.” At the end of the day, the team is given no option but to go against their best judgement and cut the Learning Cycles to meet the target date. Later, when the project is really late, everyone is surprised (expect the team), management asks, “How could this have happened? How could you people be so far off?” Everyone forgets the team was forced to cut out the LCs they knew would be needed.
We provide links to other articles on Learning Cycles (below). However in this article we would like to discuss an example project that was not at the bleeding edge of technology, rather the more common project that was an incremental improvement of an existing known technology. It had no new innovations, therefore at lower risk for missing the committed date. This is not to say the project was easy. It was complex and required close-in management to make sure it was on time. This can be characterized as an “execution problem” versus an innovation problem.
Example project
Let’s further consider this hypothetical case study. A team was faced with an ~18 month project to replace an existing product line that had become uncompetitive. It was an extremely critical project for the company’s survival. It had to be on time or even better, it was expected to be early. The product was a complex industrial product involving hardware, firmware, and software development and then extensive systems integration and testing.
Multiple companies had partnered to develop this new product, so they had many teams located around the world working on the project. The target time frame was admittedly aggressive. Failure to deliver a first customer shipment on or before the target could result in the end of the company, which is why the team had been told that failure was an existential threat to their existence, so the stakes were high. The pressure to deliver on time was very high. This message was reinforced to the team every week by the leadership.
Historically, the company culture was characterized as “Risk adverse and urgency avoidant.” The other problem was the “COVID-carryover”factor, where most of the workforce continued to work remotely. This made building a trusting team very difficult. Further, remote team members made communication slow and ineffective. Another factor influencing people’s reluctance to make accurate duration estimates was an environment that had punished those that had stuck their necks out. In the culture, it had been better not to act and be wrong, than to have taken a risk then failed.
We had formed a cross-functional core team with a strong engineering leader, then developed an Integrated Master Schedule (IMS) to first customer ship (FCS) with the team. Our initial schedule was 3 months past our target date. Over the first 3 months of the project the team was able to pull 2 months out of the schedule through schedule refinement, adding resources, and optimizing interdependencies, etc.
When we pulled as much time as we could out of the front of the schedule we scrubbed the back-end of the schedule to find more time. This was not an innovation project. All the technical problems/solutions were known. The team ’just’ had to execute, yet a significant about of buffer had been added into the back-end of the schedule during system integration and testing to account for bug fixing, which historically had been problematic for this team.
When we tried to scrub out that buffer, we ran into resistance, even though everyone agreed that there were opportunities to accelerate. Everyone agreed that the schedule was too conservative, yet was unwilling to give back that time once it was baked into the schedule. We explained that the 4 bug fix iterations estimated at 30 days each was put in during the early planning as placeholders, to be refined at a later date. That later date had arrived, yet no one wanted to remove the total “wild-ass guesses” they had made. It was as if the 120 days had become the real schedule because it sat in the schedule for the past 3 months. Yet it was never real. It was a placeholder that no one would reduce.
Why did they stop short of a big pull-in which would have pulled the schedule ahead of the target date? Why was the team reluctant to “bank time” by accelerating ahead of the target? We explained the advantage of using banked-time later on when unknown events caused the schedule to slip and that time in the bank could be withdrawn later. The logic made sense to everyone, yet why were they still reluctant to give back that buffer? Why were they reluctant to sign up for a more aggressive schedule? Even when they knew that schedule was their own schedule. No one above them was forcing the to pull-in further.
They saw the 2 week gap and knew they had 2-3 months of buffer behind that gap. They reasoned this was a safe place to stop the acceleration. Remember, if they were wrong and later needed that buffer, they would be exposed to criticism. They thought that if they pulled out 2-3 more months they would be held to the more aggressive date, so when they slipped, it would be considered a failure. This was the company’s project history.
Further, they were risk adverse. One person said, “You know what happens during systems integration, we always find problems so we will need that 2-3 month buffer.” In fact, that 2 month buffer they all knew was not necessary, became a self-fulfilling prophecy. They were aggressive at pulling-back the schedule to the target date, but stopped short of pulling-ahead of the target.
“A self-fulfilling prophecy is a prediction that comes true at least in part as a result of a person's belief or expectation that the prediction would come true.”
This team had done this type of project many times. The only variable was that multiple companies partnered to do the development together, but this was being well managed through the Core Team and IMS process. All parties understood their deliverables and their interface points. The team was working well together with clear lines of communications. In fact, they collaborated nicely to achieve the initial 2 month pull-in. More was possible.
What keeps a team from going further by accelerating ahead of schedule? We know that all projects slip. They also tend to slip more at the end during the integration and verification phases. We also know that teams have to bank time early to account for these later slips. When done well, the deposits and withdrawals of time balance out and you finish on time.
More interesting is the group-think within a team that resists giving back their safety margin to the project, even when they have all acknowledged their schedule is conservative which includes time that is not needed. Maybe it is the historic consequences of being punished for missing dates or maybe it is an unwillingness to take risks (due to being hammered when they have failed), regardless of the reasoning, this behavior separates the Normal team from the Best Practice team.
Best Practices
Best Practice teams are aggressive, yet realistic. They add margins when they have unknowns. They scrub out margins when they have more confidence. They know that margin left in a schedule could become self-fulfilling. They use the schedule to challenge themselves to do better, but never do this when there is risk. They balance risk vs acceleration. They always set the bar higher for themselves than others would set for them.
More:
Learning Cycles