Does "Reality Distortion" Work?
/
The path to schedule predictability
The ongoing challenge when managing real innovation projects at the bleeding edge of technology is,“To improve the project planning and tracking system in order to better predict schedule performance.”
Predictability is very hard when you are working at the edge, where most is unknown. You are asked to predict with accuracy, yet the basis of the prediction is a series of experiments you have yet to run and worse, have yet to fully understand/characterize. You don’t know what you don’t know and people demand you hit a deadline 24 months from now with 100% accuracy.
This is the world of advanced development today, where research and development is blended into one - product creation. The time needed to research and learn is compressed and merged into what used to be the product development project. Teams have to invent on a schedule.
This becomes a large barrier for most companies working on advanced technology. Because schedules are so hard to estimate/predict we see a resulting lack of trust at the leadership level of the very teams they have empowered to create the breakthroughs. When there is a lack of mutual trust (top down and bottom up) we see all sorts of strange behavior.
Executive leadership see the only route to Fast-Time-to-Market (FTTM) is though the imposition of even more aggressive target dates. Their logic is that if you raise the bar higher then people will naturally jump higher. The fact that we are asking them to jump 4 meters and no human has ever jumped more than a few does not factor into the equation, yet they keep raising the bar. This rarely works. In fact, we have observed that it tends to have the opposite effect - where a project team will stop trying because they know they can’t hit the unrealistic dates.
They continue to report that they can, but when privately interviewed most team members admit it is impossible (in the desired time frame). These false hopes result is catastrophic failures when teams fail to deliver. We see this clearly with clients pushing the physical limitations of their technology into spaces where the physics of the problem have yet to be defined. “We did x-fast over the past 20 years, so we will do it x/2 fast this next time… and if you can't do it, I will replace you with someone that can… blah blah blah.”
They ignore the fact that the complexity has changed, the skills are not in place, and basic research understanding is not known. Ignoring reality because it contradicts with the expected outcome is one of the root causes of many failures we have observed in Silicon Valley, over many years.
“Reality Distortion” has only worked for one guy, but then again when you study what he really did you find he carefully narrowed the focus to create the minimal viable product (MVP) in order to force early trade-offs in order to finish on time. He also minimized required invention (<10% of the project work) and carefully managed that part himself, so the rest (~90% of the project) could focus on what they knew they could do in the timeframe defined. For example, the invention was in the user interface and industrial design of the first iPhone, while much of the hardware was relatively known commodity. So even he might agree with the rest of my argument. In fact, I would argue that his “distortion” of reality was not at all a distortion, but rather very good planning and then ruthless uncompromising execution. But the sexy distortion term is a good way to sell books!
The solution is “reality-based planning” that properly considers risk and uses the reality of the schedule gap to accelerate urgency and force early decision making about possible solutions. To start earlier in order to finish on time. It requires a different corporate culture to make it work, which means that this can’t be implemented at the team level alone. It must also involve the host and the environment as one integrated system or ecosystem.
The normal reality distorted company it is difficult to get realistic schedules, because everyone is playing the “schedule game.” People below are afraid to reflect the true learning cycles needed (or they don’t know) because it will push out the schedule, so they make commitments to things they know are impossible. This behavior is encouraged by top management because it proves that their unrealistic targets are achievable. So everyone lives the lie. They know at the end of the day they can hide behind technical complexity when it all comes unraveled. Most have adapted excellent survival skills to avoid blame and shift that to others, which lead to promotions. The Peter Principal is alive and well.
The best example is the prediction of a “right first time” tape-out of a new semiconductor technology node (e.g. 14nm, 7nm, 3nm etc). Yet we know from years of similar projects that taping out a device (i.e. moving a design from an electronic state to a physical one as manufactured device) with no errors, the first time, is virtually impossible. Each new node development requires multiple iterations. It always has and always will, that fact is proven.
Each fail/learn iteration is one learning cycle. Most of these breakthrough projects take 7-10, some more, of these fail/learn cycles. Each cycle takes 6-12 months, so you can do the math on how long these projects could be predicted to take. The cycle time is reduced by overlapping the learning cycles and trying to optimize each cycle. Yet because a team did a new node project in 2 years, 30 years ago, then the logic goes that the team today can do it in 2 years (or less) because we are all so much smarter today! We have to report from the field, this logic does not work.
When complexity goes up and cycle time goes down we have to anticipate problems. This is a known fact in the technology business, yet people continue to ignore this reality because, for example, it is contrary to when the CEO told Wall Street/his customers something would be delivered. They put schedules together that have target dates that assume everything will be perfect, the best case plan. The team is doomed to fail before it starts in these data-free operating conditions.
We see companies continue to plan as though there are no risks and everything will happen as it is supposed to - this dream-world does not exist, but to do anything else other than play this dream-game can be a “career limiter” in some organizations. So the game goes on.
How can you fix this?
The first step in “Predictability” is getting a “Valid Critical Path” schedule. Once a valid critical path plan is in place the team can focus on looking forward to find ways to accelerate the schedule, rather than looking back and focusing on the reasons why the schedule slipped.
Most CPM schedules we see are not valid. They fail our best practices Schedule Analysis test. They are being used as predictive tools, yet they lack basic technical quality which would make them usable are predictive devices. Some are so bad that they are actually reporting erroneous information, yet the users of the data don’t know it.
The foundation of the model (illustrated above) is based on a good critical path. The example that illustrates this the best is the review of the ABC Project schedule (this is just an example). It scored zero on the Schedule Analyzer test, there was no critical path and it was impossible to use it to determine the status of the project, yet the team had 80 slides a week being shown in a project review with more than 50 people in attendance. The dashboard on the slides showed this project was “green” yet we were told it was slipping week-for-week. For us, looking in from the outside, it was hard to imagine that this schedule was being used to drive the work on the project and make decisions (more critically, pull-in decisions), given that it was not up to date or technically accurate.
This is a great example of the foundation not being sufficient to do a risk assessment or use it to predict the future. It was also clear from our quick analysis that they were not updating the schedule on any regular basis, so it was very much out of date. Out of date schedules are of little value when predicting future events or in driving weekly actions.
This example illustrates the challenges in front of Program Managers of advanced technology development projects. Many Engineering teams need help to create a good foundation from which to make predictions. They need training, they need coaching, and they need assistance in getting Refresh Planning implemented so the schedule is up-to-date and accurately reflects what is going on in the project.
This is always the challenge for a the Program Manager and Core Team - how to make information more transparent and people more accountable, yet when doing so one can expose their problems/failures/what they don’t know. Many times, the reason they are resistive is because of the exposure problem. Yet the only way to solve problems it to force failure quickly and then fix it. If failure can’t be exposed, it becomes difficult to fix it. It is just basic engineering principles, yet it is very hard to create a supportive environment were this can flourish, where failure is encouraged it is good, and people are trying to fail faster.
Risk Assessment
Once the clean schedule passes the Schedule Analysis tests with a greater than 90% score, the next step is to conduct a proper Risk Assessment. This is a critical thinking study of the potential things that could go wrong. So instead assuming everything would go “right” we assume the worst. As Andy Grove put it, “Only the paranoid survive.” This study results in the addition to the schedule of contingent activities to compensate for the potential anticipated problems, extended durations, and additional learning cycles. This Potential Problem Analysis is essential to creating an accurate schedule.
It is astonishing how many plans we see that assume perfection when developing very advanced technology, much of which of the core elements are more of a research project than a product development effort. Yet over and over again we see companies making bold predictions of very fast cycle time, not because they have a plan that shows they can achieve it, but rather because they have a target date that is demanding the innovation be completed at a specific point in time. I wish it was as easy as just setting a date when creating something new, that has never been created before, and magically the new thing would just appear on cue. When these projects fail, everyone is surprised, except for the technologists who knew it all along, but had been silenced early on for being negative.
When proper risk is assessed, critically, the schedule can reflect these anticipated problems. This always results is a schedule that misses the target date. The gap becomes the driver for making early decisions that could close the gap. Rather than pretending something can be done in time, FTTM teams working on advanced technology anticipate the problems and start early to mitigate them. If the gap is too big, they kill the project and use those valuable resources on something that has a better chance of succeeding or change the project scope so the team can win. Assessment of risk is essential before you can be predictable.
Finally, FTTM teams use the schedule trend information to anticipate when something will really be delivered. The criticism we’ve heard leveled at teams is that their schedules are not predictable. That the delivery of a product is in effect a “random event.” We disagree with this characterization.
This example illustrates a schedule that required four learning cycles, yet the target was set assuming right-the-first-time with no need to iterate to get it right. Each learning cycle generated a reset in the target. When the target was reset, the schedule tracked to the new target date. What was interesting about this project was that 4-7 learning cycles could have been anticipated on day one of the project. The company had not done a new technology project like this in the past without at least 4+ cycles to learn and correct, yet top management set a target date for the team that required that get it right without needed to iterate. They were told that they “Had better get it right or they would be replaced.”
Is this a prediction problem, a problem with the quality of the engineers, or a problem of bad planning and a lack of critical-thinking risk management? Did the corporate culture conspire to cause the team to stay silent, when most of them knew that the target was unrealistic before the project even started? From our perspective this is a failure of leadership and less a failure of a team to execute. However, it is interesting to note that at this company they normally take 7 learning cycles to get it right, yet this team did it in 4. In fact they beat the best-in-class by doing it in 4, yet are considered failures because they missed the target date by a year.
This schedule was predictable. You can draw a trend line on the Wigglechart and it roughly predicts when the milestone will be complete. In many cases it is not a predictability-problem, but rather that people don’t accept the answer the data is presenting. They don’t want it to finish where it is trending, so they reject the information and question the sources/people generating the information. This is very common in the semiconductor business where Moore’s Law has guiding planning decisions for the past 50 years, yet new node development in the sub-20nm realm is proving that a new law may be needed!
Some times we have seen the “predictability problem” characterized as a “philosophical alignment problem,” but rather its an inability to deal with reality in advance of that reality manifesting itself as a real crisis. Many times senior leadership is unaware of the environment they have created by their aggressive target setting behavior and lack of critical thinking about potential risks. That behavior tends to generate the opposite of what they want. We see more schedule padding, more people trying to put positive spins on what is really failed situations, a lack of objective critical thinking, or outright “obfuscation” of data to blur lines so as to avoid accountability and blame once the failure becomes known.
Rather than getting early warning, transparency, and before-the-fact actions… leadership creates an environment that inadvertently rejects contradictory information. The more “can do” a culture is, the more we see repeated failures to deliver on time. Of course this is the opposite result the “can-doers” want. This is really a failure of objective critical thinking and a host environment that is not properly structured to reward transparency and early-warning behavior.
FTTM companies have host structures and systems that encourage critical thinking in order to find problems before they happen. They force the pain forward. They want to hear it so they can deal with it, early when there is time. They would have set the target in this example above at 3-4 learning cycles and then provisioned the team by removing interrupts. The team would have responded (they always do in this environment) with solutions to accelerate each learning cycle or run concurrent experiments to overlap learning cycles. When reality is recognized, we see it over and over again, that teams step-up to find creative solutions. When their professional opinion is ignored, we see just to opposite happening.
Many companies in Silicon Valley continue to set targets based on perfect outcomes, no/few learning cycles, right the first time expectation, and with projects that are fully staffed (on paper). These perfect project outcomes are rare, the schedule inevitably slips, and projects become seriously over budget. It is then a big surprise, people get fired, yet these slips and overruns were predictable if people were willing to listen.
Senior leaders must be willing to “accelerate the pain” and deal with reality at the start of a project, and then to take the actions necessary to mitigate risk before the project slips. Many companies have been in “damage recovery mode” for so long that it becomes a way of life - most don’t even realize they behave like this. In order to solve the predictability problem of very advanced technology development, organizations need to break the cycle of unrealistic planning.
A foundation of a successful project is an accurate schedule. Yet the schedule, like a building foundation, is not the complete building, but without the foundation the building does not stand up.
Our focus on the schedule, and engaging people in its creation and maintenance, is because this is the first step in accelerated product delivery. We don’t see the FTTM problem in compartments with schedule in one box and the rest of the things you need to do to manage a project in other boxes (i.e. communication, leadership, transparency, team work, common goals, etc.). Rather, we see it as an integrated system with each piece working together, each important but none more important than the other. When the schedule or foundation is not solid one can’t build the project on top of it. It can’t be used to predict and influence future events.