FTTM System
/
The following article is a more detailed discussion of the concepts outlined in the video above.
FTTM System (Fast-Time-To-Market)
The individual elements of the “system” involve more than our software implementation of the fast-team best practices using Microsoft Project. The software foundation is necessary, but not sufficient to change patterns from late to on-time. The planning methodology that sits on top of the software gives teams a process to build and model their schedules. They simulate acceleration ideas and use the schedule to communicate the impact of various decisions; i.e. change development approach, make vs. buy, reallocate resources, etc.
The software and method drive change; structural and behavioral when the process is adhered to over time (6-12 months for it to become a unconscious way of working for a team). Behavior changes when new habits are adopted, such as refreshing the schedule every week with the core team and then using it to pull-in the schedule. The habit or rhythm of the weekly meeting and refresh process changes how the team uses information to make decisions and get early warning of potential problems.
Structural change occurs when a plan is constructed around the work-flow rather than the more traditional planning that produces functional outputs (i.e. software deliverables, hardware deliverables, etc.). FTTM System tends to identify the gaps in the functional organization, since it deals with the development problem across silos, or in other words “laterally” from end to end rather than vertically by function.
For the FTTM System to be sustained over time, it needs to have the involvement of executive leadership, which we call the “Host.” The host are the functional executives that provision teams with resources, information, and tools to enable the teams to get the work done. The host is critical to the system “sticking,” since most accountability systems eventually get rejected by organizations since few want to be measured and held accountable against performance targets. If not rejected, they get rendered impotent and marginalized, such that they take lots of time to maintain, with very little information value returned. Yet this is what most business decision-making is based on. People spend most of their time trying to get around accountability or trying to make sure others are associated with a problem, just not them.
What makes FTTM different is that the “system” is Adaptively Implemented. This means that one size does not fit all. The system needs to morph to fit the culture and people’s readiness to change. It can stretch the envelop of behavior change, but it can’t push through and break it. So the FTTM System is a set of components that interact with one another to form a whole. They are all required in order to produce behavioral change, one that sicks after the consultants depart.
Single Source Normalized Lateralized Database
The core of the FTTM system is a mouthful; a “Single Source Normalized Lateralized Database.” All these words are important descriptors, so let me talk about each one.
Single Source; Refers to one central repository of schedule and performance information about a project. Seems simple, yet most project information is scattered in multiple locations, databases, and formats. Trying to assess status and project health is difficult and much time is wasted trying to consolidate or understand data. The FTTM System is a single source that is “Normalized” around a common framework. It all looks the same, was created using the same method, and is maintained the same way using the Refresh Planning, so when it is integrated and presented it makes sense. Further, it is based on the raw source data and information does not get filtered or translated to meet different audience needs.
Lateralized; Means that information that is usually developed and managed within the silos is forced to laterally connect across the silo boundaries as a horizontal work flow; which represents all the pieces of the development project, eventually terminating in an integrated customer deliverable (versus a functional deliverable). It is like having a string that connects all the components being developed, and when you pull the string, you can see how it affects all the elements in the connected chain, since they are integrated into one contiguous critical path built around customer focused integration points.
The system produces Indicators and Metrics. Indicators enable forward looking analysis to spot problems before they happen while Metrics permit you to look backward to assess why things happened the way they did, so that this knowledge can be used to improve future work on the project.
Our use of historical information, such as baseline duration variance and schedule trends are used to determine root causes of failure, so improvement can be made in real time so that future outcomes will improve. We never use this historical information for finding and assigning blame for failure. Failure in a FTTM environment is valued as a rich source of learning material. On the other hand, failure on typical projects is a source of fear. Tremendous amounts of energy is consumed trying to forensically decompose root causes and who was at fault for causing the failure. This creates environments that hide information, resists transparency, and rejects systems that attempt to expose truths. This anti-learning environment is also associated with slow, failing, or failed projects. Yet sadly, it is the norm.
When it is done right, the result is an environment where honest and open discussion surfaces the reality of the project. It is encouraged and rewarded. For example, a project is really late, and everyone knows it, yet no one wants to say it; the FTTM System will force this reality out on the table. The key players “get” permission to surface the gap, rather than being attacked as negative non-team players. The indicator of a healthy FTTM System is Transparency. We all say we want it until our work is “made transparent” and evaluated. But transparency is the key to Early Warning. You can’t change what you don’t know. If you know in advance, you may have enough time to do something differently that could change the future outcome.
The Urgent environment pulls pain forward and forces Tradeoff Decisions to be made well in advance of when they would normally be addressed. One project team we worked with was unable to close a >10 months schedule gap, after having pulled 8 months out through weekly refresh planning; they met offsite to challenge their technical assumptions about the project. The result was a set of choices to change the way they would develop the product; using different components in order to save time. They took a hit to COGS of 2%, costing them $250M due to lower yield, yet the 12 months schedule pull-in gained them more than a $500M benefit. That product trade-off decision was accelerated by more than a year due to the reality that they were not closing the gap fast enough.
In order to make this decision, they had to have a laterally integrated, reliable and accurate schedule. Further, they needed to see the historical trend showing that they had in fact closed part of the gap, but had leveled off at more than 10 months past the target window. At the rate of closure they would surely miss the window by a large margin. This information indicated that they needed to make some choices to close the gap, now rather than later. This was all being done 2 years before the end of the project. In the past these kinds of decisions were not made until the very end of the project when people eventually realized they would miss the window, but then it would have already been too late to recover. The key to FTTM is to anticipate and act, well in advance of when you think you must.
Planning Process
It all starts at the macro level. The macro is the abstract representation of a development project. It is very hard to abstract complex problems, but the process itself forced people to a higher level of thinking to see the development strategy and to understand interconnectiveness of the pieces. The hardest thing to do is to simply explain complexity. When you can do this, you really understand the problem. In doing so, the team gains “grasp” of the way a project needs to be organized in order for it to be successful. Macro planning is the key to this understanding. Easy to explain, but very hard to do. Abstraction is an anathema to most engineering teams.
We describe the project in the Build and Model steps as a series of high-level activities, called macros. These macros are typically 30-90+ day duration events, big chunky things. Most projects can be described with 50 or less of these macros. We’ve even done a $10B semiconductor fab with less than 50 macro activities. We could show the flow of the project with a one page schedule.
The macro plan explains the high level flow and interface points in the project. It usually fits on one page/screen. The core team can grasp it and run modeling studies to explore how to optimize it to fit inside the target time windows. Macro plans produce macro discussions. It is a way to train a team to look at problems at a high level, and it keeps them out of the technical “weeds and ratholes” that consume lots of wasted energy/time on projects. It is done in a day or two. It sets the framework for the development of the micro plan, which in the case of those big fab projects, had activities in the 50,000+ range. But it all started with a rapidly developed <50 activity macro plan, and with a fully engaged core team. Core teams can understand a macro plan, but they can’t understand detailed plans. The macro plan trains them to understand the context of the project, so that the detail makes more sense.
Refresh Planning is what makes the theoretical macro plan a real plan that can be used to manage the project. Refresh Planning breaks down into three steps; looking back to update the schedule with what actually happened in the prior weeks, and then a decomposition of near term long duration tasks so they can be Pulled-in. You can’t pull-in long duration tasks very easily because you don’t know what could trigger a future task to start sooner, since you lack sufficient granularity. Hence the need to breakdown tasks.
The final step is to use the newly updated and refreshed critical path to Look-Forward. Forward looking behavior is an advanced skill that only few teams are able to master. Most of their time is spent looking in the rear-view mirror and in not spending enough time looking out the front wind-screen at what is coming at them. The really good teams spend equal amounts of time looking forward and back. They have learned that they can influence the future to mitigate slips before they happen. It is easier to pull-in what has not happened than to pull-back and recover after something has slipped. This requires less energy than trying to recover lost time from the past.
Macro-Micro
There are top-down expectations and bottom up reality on every project. The top-down expectations and bottom-up “reality” are equally unreliable; one is exaggerated to compensate to poor past performance (i.e. set the bar higher than they can reach and they will reach higher!) and the other is padded to account for top-down “exaggerations” and to cover up for potential future unseen technical risks. At the end of the day, its just one big game where no one really knows if a project is on track or totally off the rails, until a big deliverable is missed and everything hits the fan. But at this point the exaggerations just get worse, people overcommit since this is the path of least resistance, and the terribly painful cycle repeats. In the end, there is an attempt to find the people to blame who “caused” the failure.
The FTTM system is based on both macro and micro being reconciled before the project starts. You can also call it “alignment.” Expectations and reality must meet and be rationalized. If a project can’t be aligned, then kill the project before it starts and use those resources on something that has a better chance of success. The FTTM System has process designed-in to force top down and bottom up reconciliation. It does not permit the players to move forward if they are not aligned and if expectations have not been properly set. This results in proper or realistic expectations being set at the start of the project, with all parties in agreement (i.e. marketing, engineering, manufacturing, and most importantly the Customer).
Incremental Work Break-Down
Once the macro plan is developed and multiple simulation studies are conducted on it to find the fastest path to the project end point, the focus shifts to detailing the work in the near term. The macro activities are broken down into smaller increments of duration. These can be as small as 5 days (or less) within the near term, which is about 4-8 weeks ahead.
We don’t break-down anything beyond 8 weeks out because it is a waste of time. Things change to much on technology development projects. If things change, then so does the schedule, which consumes valuable time messing around with the schedule. The project is to develop a product, not a schedule. Further, on innovation projects where future learning cycles (LC) are unknown, you are only able to breakdown the current learning cycle into, for example, Design Experiment, Conduct Experiment, Analyze Results, Design New Experiment. The future cycles are based on the current LC results, so why waste time planning what you don’t know and rather just approximate them as LC2, LC3, and so on. These remain big chunky activities with ~30-180 day duration estimates. The only thing in FTTM schedules that gets broken down are those activities that fall within the near term time window.
The pattern then is to breakdown activities and update them with actual performance information (i.e. actual start, actual finish, and remaining duration if they are still in-progress at the time of the update). Then in the same weekly Refresh meeting, Look Forward to breakdown more activities that fall on the critical path in order to see if there is a way to do them sooner. This is called “incremental pullin.” Teams usually get 2-5 days a week out of a schedule this way. The big strategic pull-ins happen when the core assumptions about a project are Challenged (see Challenge Workshop). This is where you get months out of a schedule.
The refresh pattern continues through the project. Periodically, teams meet in 1-2 day workshops to re-plan future sections of the project, based on what was learned to date. Project schedules go stale quickly if they are not constantly maintained. Re-planning is also an opportunity to rethink the way the project is being managed/how the product is being developed.
8 Core Principles of the FTTM System
End in mind; FTTM schedules are always constructed from a Doneness Criteria. This is list of completion criteria for exiting a milestone. We initially do the “Program Doneness Criteria,” which define the completion criteria for the overall program, “This program is done when…” Then we do it again for the 5-7 major milestones. We define doneness further with each activity breakdown, always defining what it means to be complete, before defining the activities to achieve this end-state. The “end in mind” is used to define the activities that precede the end point. This results in a better structure for the plan with clear end-states. It is critical to get the stakeholders to agree on the deliverables and how these outcomes will be measured. Unclear deliverables are one of the common and frequent factors causing schedules to miss their target dates. “I thought you wanted 2X… no I told you I wanted 3Y…. It was clear to me, why didn’t you understand and why didn’t you say anything sooner?” and so on.
No constraints; When we studied the differences between slow and fast projects we observed that slow projects plan from within their given or perceived constraints. On the other hand, fast projects ignored constraints (initially). Constraints include people, skills, equipment, materials, money, and time.
Planning within constraints mean that if you were told to deliver a new product in 8 months with 15 developers at a budget under $5M; you would produce a plan to fit those constraints. Your plan would show it finishing within 8 months, no resources would be over-utilized, and you would show that you would not spend more than $15M. Everyone above you would be very happy since the plan matched their expectations. Feeling good at the start of a project is what everyone wants. Of course the outliers on the team that complained that “it was impossible to do it in 8 months” would be silenced, and coached to be better “team players” and that negative talk like that could become self-fulfilling. They would also be encouraged to take a team building class! However, the slip would show up much later when people eventually realized they couldn’t actually do the project, per the spec, by that time frame.
The fast team would ignore these constraints and spent time to clearly define the end state and make sure everyone agreed on what was to be delivered, based on customer requirements. They would build the optimal plan from these deliverables without considering time, resource, cost, or other constraints. They would determine if the project deliverables could be achieved and how long it would take them to do it, per the desired quality specification. Then they would do a gap analysis in terms of time, cost, and resources. What is the schedule gap, assuming we do the project the right way and not compromise the outcome? What resources are needed to close the gap and when? What technical product decisions are required to close the gap? What marketing decisions are needed to close the gap?
They determine the optimal solution without constraints, assess the gap, and then use the model to simulate alternative ways of achieving the desired goals and close the gaps. In this way the project goals are not compromised. When you start with constraints as the planning basis, then you usually compromise the outcome and hide the reality, which will pop up and bite you later. So why do so many start and plan within their constraints? Because it is the path of least resistance to do it this way, and everyone feels good because the plan maps to what people want to have happen. Sometimes “feeling good” in organizations trumps dealing with reality.
Of course people also know that there are a million technical things they can blame later when it misses the target window. This condition just hides the fact that people usually know that a project is late before it starts, yet have no way of communicating it without sounding like non-team players, so they remain quiet. The FTTM System gives voice to these people, assuming the environment around the team is set up for this level of transparency. When it is, we see fantastic results.
Engage team (they will accelerate); People will usually beat their own goals, but it is much harder for them to meet/exceed goals imposed from above, especially with engineers developing advanced technology. They are professionals that know how long things actually take. The team must be engaged in the planning effort and the solutioning process to finding ways to close schedule gaps.
Another team we worked with was permitted to reflect their true estimate putting the project >24 months past the target market window. Through refresh planning they took 12 months out of the schedule over a four month period, but the wigglechart trend indicated they had flattened at around 12 months late. Senior management did not beat them up. They let them try to figure out a way to close the gap. This had the affect of empowering the team and gave them the feeling that they owned the project and its outcome. Instead of being told when to do something, they got together as a team and tried to find a way to do the project faster. After an intensive Challenge Workshop they found the key, which was a combination of product and technical decisions they could make to shorten the schedule. This involved using a different technical solution which would increase product cost, yet dramatically shorten the schedule. Management was advised to let them make the case for the new approach. They used the plan to illustrate the trade-off analysis. The 12 member core team unified around the alternative development strategy. They spoke as one voice to the leadership. They basically signed up to deliver the product on time if they could get the design changes approved. They did and the schedule gap was closed. People will always beat the goals they set for themselves!
As executives provision teams, you must also create the conditions that cause this ownership to transfer to the core team. Executives we coach often miss the opportunity to transfer and lock in team commitment by assuming personal ownership of an unrealistic target date. They end up owning it and the resulting failure if they are unable to convince a team to sign-up. Engineers doing the work will always have control over when the work gets done, regardless of how much top-down pressure they get. The FTTM System recognizes this and redirects this energy to productive ends. But it takes trust and faith from the top to make the change to a new way of thinking and to drop old punishing methods.
Realistic planning (identify the gap); This means making plans that reflect the best known information available and not being influenced by aggressive top-down pressure to, metaphorically “fit 10 pounds of flour in a 5 pound sack.”
Organizations have may ways to pressure teams to deliver faster than a team thinks is possible; peer pressure, pressure to be the “team player” by “signing-up” to what is known to be impossible, position power (i.e. being told how long it will take), unwillingness to buck the group consensus, and a calculation that says that it is easier to go along with what makes people feel good rather than try to accelerate the pain by forcing the conflict to be resolved. These reasons, and others, all contribute to unrealistic plans, not to mention the development of poor estimating skills.
Fast, learning organizations, on the other hand, know that the sooner they grasp the problem, then the more time they will have to fix it. They want reality and they want it fast. To get real plans you must have a culture that supports transparent truth and uses that information to find solutions, even if it is an imperfect representation of what is known at that point in time.
Schedule is driver vs. reporter; Slow teams use a schedule to report progress, when asked. Fast teams use a schedule to drive future actions. As a side benefit, their schedules provide excellent reporting vehicles, but this is always a secondary use. First they use it themselves to drive activities on the project. This means the schedule must be accurate and current. This is accomplished through the Refresh process. When the schedule reflects what is going on today on the project, it can be used to predict what might happen in the near term future. If it is out of date or if it does not reflect the actual work, then it has no value.
Macro to micro, detail over time; The essence of the FTTM System is macro planning, Macro plans set the top-level architecture of the project. Like a top-level design sets the framework for all the components and their interfaces, the macro plan structures the project plan around high-level integration points in which the maturity of a product’s evolutionary development can be assessed. These integration points are based on the lateral work flow and not functional deliverables, while functional outcomes are embedded much lower in the micro detail.
Once the macro framework is set up (<50 activities describing the end-to-end project), the near term schedule is broken down into smaller duration increments, such as 5-15 days each. The near term detail is developed in the context of the macro structure. This permits the development of very large complex projects, since the structure is correctly set up from the beginning. This is also important for smaller projects since schedules with no more than a few hundred activities can quickly become unmanageable if they are incorrectly structured. Structuring a project from the top-down is perhaps the most important first step. We often change the structure at the top over time as we see the project and schedule evolve together.
Innovation projects require macro planning; when scheduled inventions are needed to meet project time frames. On innovations projects you must express the future in vague terms (i.e. macro), because you just don’t know what will happen in the future until you understand the results of current experiments. You can’t plan what you don’t know with any degree of specificity. The rolling window of detail breakdown is really the only solution to planning the unknown. You usually know the steps today and those are the things that get detailed in the schedule.
One way to plan/approximate the unknown is to use learning cycles (LCs). Say you anticipate needing three LCs to find a solution. Each LC is made up of a 1) design of experiment, 2) fabricate, and 3) evaluate (i.e. measure per DOE goals). You may know that each of the steps 1-3 will take 3 weeks in the fist LC, but may only be able to express LC2 and LC3 as 9-10 week activities happening in the future with a 2 week overlap. The near term is detailed, while the future is left macro. When you get to LC2 you can break it down. When you get to LC3 you may not even need it if you find the solution in LC2, in which case you get a big schedule pull-in. You may also need to add LC4 and LC5 if you fail to find a solution by LC3’s completion (see “Innovation can’t be managed” article).
Urgency (before-the-fact); Normally, urgency is generated on projects when teams get close to a committed deliverable. However, fast teams create urgency well before a major deliverable is due. They force urgency right at the start of the project by identifying the real schedule gap.
When projects are on schedule nothing changes, since there is no urgency or need for change. When there is a gap identified early, people start to think about different ways to do things so that the gap can be closed. When it is done right, this urgency creates anticipatory “before-the-fact” mindset on the project. People take action before they have to, or are forced to by events not happening as expected or planned. When you do something sooner than later you have more time to find a solution. They start sooner and take longer, but finish faster.
Refresh; Is the key to the FTTM System. Refresh is done weekly and involves updating what has happened on the project, and breaking down near term detail to find pull-in opportunities. Schedule pull-in “banks time” that will be used later in the project when the unexpected happens. Fast teams track this time-banking using a Wigglechart to show the trend of key milestones; are they continually slipping over time or are the working their way back to the committed target date? The trend is an indication of the health of a project. Late projects are not bad if the schedule trend is good (i.e. trending back to the target window). If a project’s trend is bad and it indicates that a project can not hit a target window on time, then that project can be killed so its resources can be put on projects where the chances of finishing on time are greater. If the project is ahead of schedule, yet the project is trending away from the target window then this is bad. Without the Refresh Process, the FTTM System would not work, since this is the source of data used for trend analysis.
Effective Core Team
The FTTM System is deployed by a Core Team. This is a cross-functional body that owns the development effort from start to finish. They are typically 5-12 key functional managers/resource owners that together share the success or failure of the product creation process. At the end of the day, they are ultimately responsible for the project’s outcome. To be effective they must have these six key success factors (KSFs) in place.
Customer focused means that they integrate the voice of the customer, if not the actual customer into the development process. The schedule is based on customer focused deliverables and that voice is what is used to drive product decision-making. The team is cross-functional so that each function that touches the product have a seat at the core team table. In the fastest teams these people are dedicated to a single project. When people are fully assigned to one project they tend to have a great sense of ownership over the successful outcome. Yet fully dedicated core teams are rare in our practice. Few companies have the bandwidth or discipline to dedicate core teams. But speed is directly tied to the degree to which people can focus. We have years of project experiences to illustrate this fact.
As I have said, the lateral integrated schedule that is refreshed every week is the key to it being used to drive the project. All these elements must be operating in order to make a project go fast. One or two are not enough. Effective core teams use all of them to deliver the right products at the right time.
The purpose is to accelerate the schedule
The reason to do any of this is to make the project go faster. We know from many many on time (and before target) projects that we must accelerate just so we can finish on time. So accelerating is not just to make things go faster in the end, but really it ensures that things finish on time. The accelerated time is banked, then withdrawn from the bank account when things slip. The net result is to finish on time if the deposits and withdrawals are managed. We can’t predict the future, but we can organize a project so that there is more time to solve the difficult problems by starting sooner, permitting things to take longer, and then finishing early. Seems obvious, but so few do it because it takes a totally different mindset about planning and predicting future events.
The goal is to get strategic acceleration at the start of the project and then incremental tactical wins throughout the project. This is a list of some, not all, of the strategic decisions that can be made when the project map is clearly defined. All these strategic ideas result in major time savings in the order of 1-12 months.
Since most projects we see are between 12-24 months late, ideas like these are often needed to close the gap. But they are difficult, because they require base assumptions about the project to challenged. People want to get everything and they want it on time. We can report, through hundreds of project experiences around the world, that you can do this without making tradeoffs, if you do it right. Fast teams call it the “no trade-offs paradigm.” Right product at the right time does not always have to be a compromise with a “kind-of” right product at “kind of” the right time. Accelerated decision making and proper planning can produce un-compromised results, if the right decisions are made early enough in the development cycle. The trick is to focus where and when to make these decisions.
The Refresh Planning process is the mechanism to identify tactical pull-ins. Tactical means small duration time accelerations such as 1-2 days here and there in the schedule. For example, can this activity be done in parallel with that activity this week? If so, we can save 2 days. Can we remove a group of activities or do the work differently? Can we get resources from outside the project to handle this part? These are all examples of tactical pull-ins.
The FTTM System uses tactical pull-ins every week, combined with strategic decisions made in the early stages of a project to bring projects within target delivery windows. It is not a one time action, but rather a continuous never ending process of putting in more force to pull the project to the left, than the project wants to exert to push itself to the right. The “tug-of-war” battle is not easy and a small percentage of teams win it. Those that do, win big since the ROI on an FTTM System investment is huge when teams commit to this new way of working
Also see: