FTTM Planning Methodology
/
Introduction
FTTM is fast-time-to-market. In this screencast, I’ll discuss a project planning and tracking process, which has evolved over a 20 year period and through our work on thousands of client projects. The foundation of this process is based on the best practices of fast teams, who we’ve been studying since the early 1990’s.
It’s better to roughly right - than exactly wrong.
Roughly right is the philosophy of fast teams, since they know that things can be continuous improved over time. The same idea applies to their schedules, which are “a common base for change.” They are dynamic living tools that must reflect what is actually going on in the project in order to be of predictive value.
We implement this concept through continuous and frequent “low-overhead” cycles of refreshes, more on that idea later.
FTTM Thinking
We’ve documented nine elements of FTTM Thinking. These principals contribute to accurate schedules, and schedules that can be used to drive projects, not just report progress.
Start with the end in mind--Covey’s concept of working backwards from what you want to achieve, rather than from where you are... to where you are going.
Ignore constraints--during initial planning in order to find the optimal path, then apply constraints later to see the gap, then make trade-offs. Planning inside constraints limits innovation and possibilities.
Make a realistic plan--seems obvious, but most of the new product plans we see were manufactured for executive or external consumption. It seems they don’t want people to really know.. that what was expected, can’t be done. Realistic planning pushes the threshold of pain to the front, where before-the-fact decisions can be made to avoid problems and possibly to achieve success.
Plan macro to micro--in order to see the forest for the trees. It sets the high-level architecture for the plan and provides the structure on which to hang the detailed information. More detail does not equal better quality, this is only true in school!
Know the gap--between what is expected and what can be delivered. This is essential for making trade-offs when you have to respond, rather than just react.
Short interval planning--focuses the team on the near term, 2-3 weeks out. The schedule can be very accurate with these near sighted glasses on, while the macro plan provides the necessary “distance vision” needed to manage the project.
Engage the team to accelerate--the schedule. Schedules done by individuals are of no value. Teams, when engaged in problem solving, will find the solution--individuals “selling” plans are just more noise for the people in the trenches trying to get the job done.
Refreshing the schedule--is the rhythm of accountability that keeps the schedule data current and keeps the cost of delay per day--front and center in everyone’s mind. Refresh planning is the system for getting continuous schedule pull-ins.
Manage trends--in the schedule. Who cares if you’re late, rather what we want to know is are you getting later or are you catching up? Schedule trending tells us the health of a project and is the basis of the actions teams take each day on the project.
Macro-Micro Planning
Macro-micro planning is a core principal. It was born out of the fast-prototyping concept and the notion that you can only plan what you know, the rest is a guess, especially in developing leading edge technology.
Fast teams first plan the complete project at the macro level to determine the feasibility of a project. Can it be done in time? And, what is the gap? For more than 20 years we’ve answered these questions with just a handful of macro activities, developed with experienced teams after only one-day of planning. Strategic visibility can only be found in the macro.
Once the project starts and we update the schedule, we look out and break-down the near term schedule. The lookout window depends on the project and how much is known. This refresh cycle continues though the complete project duration, so in effect the planning never stops and is continuously refreshed as new information becomes available. It is a planning commitment that only fast teams make.
Planning Steps
Build
Let’s review the planning steps, starting with build.
This is always a group activity, it’s participatory and should involve the core team and as many individual contributors that can spare the time. Building a proper schedule typically takes 1-2 days and longer on large programs. Fast team invest in planning, the payoff later is worth the investment. Slow teams don’t plan and pay for it later.
The work-breakdown-structure (WBS) creates the architecture of the plan. This is the most important step in that it defines the boundaries or scope of what “is in” and what “is not in.” We specifically don’t think about “when” it is needed at this point, since we don’t want to compromise the work that is really needed to achieve the project goal. We’ll deal with the time constraint later.
Model
Model is where we create the schedule by linking depended work in order to get a critical path to the end of the project. At this point we can see the gap, between when it’s expected to be delivered… and when the team can get it done. Typically this is 50-75% longer than expected. Strategic pull-in is a process to close that gap, through various thinking techniques such as “lateral” and “challenge” and through a systematic process of compressing the critical path.
Refresh
The final step is Refresh. First, we update the schedule with what has happened. Absent an accurate project update as to where you are; it’s like being lost with a map, but not knowing where your position is on the map. We never ask “why” when doing updates, in order to get accurate information from the task owners, we just want to know “what.” Our focus is forward looking to pull-in, not looking back to find fault.
Breakdown is the process of decomposing long duration activities into detail tasks with 1-5 day durations. Breaking down is the only way to discover the near term opportunities to pull-in the schedule. We breakdown to enable the team to get control, but never to micro manage them.
In the same weekly refresh session we look forward 1-2 weeks with the team and try and pull-in the schedule. We try and get 1-2 day pull-ins every session. They really add up. This is a group innovation event that we do with teams 1-5 times a week, for less than 20 minutes each session. The more people on the team that participate the better.
Tracking trends is the final part of schedule refresh. This is where we plot the movement of the schedule towards our targets or away from them. Three slips is a trend and requires intervention. Done early these can cause schedule acceleration.
Build Process
We start with the mission statement. Seems simple, but we rarely reach consensus quickly when we ask this question. It tells the team why, how much, for who (i.e., customer), and when something is going to be delivered. The doneness criteria is “an exit check list” used to measure if the team has achieved the mission. This discussion frames the boundaries for the plan to come.
Then we define customer focused or critical integration milestones starting with the end deliverable. These also have doneness criteria. That criteria “informs” the clusters of activities what are required. The first level of the WBS is created at this point, no schedule elements are discussed yet. We just want to know what is needed to be done. Each macro task gets owners assigned and overall duration estimates made.
Model Process
This is where the team, using a beamer for the people in the room and online meeting software for remote groups, “wires” the schedule with dependencies… these are links between tasks.
This generates the critical path and shows us the gap between when they want it and when the team can actually get it done.
The pull-in process walks down this critical path looking for opportunities to eliminate, reduce, or change. As schedules accelerate, risks go up. The risk/reward calculus determines what and where trade-offs need to be made. This is an essential part of the team taking ownership of the schedule and the outcome. In this example, I changed a link to make a group of tasks happen concurrently, in order to cause a pull-in.
Refresh Process
Refreshing the schedule starts with updating it with actuals, not just changing estimates. This is again a group process that takes about 10 minutes a day for most projects, even the big ones. It is fast and not judgmental. In this example, I have estimated a new remaining duration for my second task, making it longer than the original duration. Since it is on the critical path, my example project slips.
Now I’ll breakdown the macro task into three smaller tasks where I can see the overlap and where I can make better duration estimates. When I do this I have found a way to make the project go faster.
The planning process is continuous. Fast teams do this daily, or at least three times a week. Since it takes just 20 minutes or less, teams are willing to invest the time to do it since they get so much value out of it in terms of knowing where they are--and because of the predictive, before-the-fact psychology that becomes the new norm for the team.
Also see: