An abstract introduction to the methodology we’ve developed to manage large programs over the past 20 years, through hundreds of client experiences around the world--from the $6B Saturn program at GM to multi-million & billion dollar solar and semiconductor fabs. They all share a common foundation in our best practice research into how teams deliver the right “thing” at the right time.

Daniel Pink confirms what we've seen, since our first best practice studyin the early 1990's, about the intrinsic drivers that motivate people to achieve high performance results.

We created this fictional "story" to describe a composite of obersations and experiences we've had over the years concerning strategy and the resulting product portfolio. Have you ever been to a Dinner Party like this?

Aggregate, then drill down by exception.One problem when assessing a multi-project portfolio is knowing where to focus. In some cases there can be hundreds of projects in various stages of completion.

Refresh Planning... The weekly rhythm of refreshes is what makes them work. Team members know they are accountable to their colleagues every week at a set time. It can’t move and it can’t be postponed. And doing them more than once a week is even better, but they must be short and crisp value-added events.

These concepts are based on increasing the cycles of learning. More learning cycles in a shorter period of time = more rapid acquisition of knowledge = faster results. The other principle of fast cultures is the idea that you have to "fail fast" in order to learn faster.

Best-in-class teams do refreshes three or more times a week. The fastest teams we’ve worked with do it every day (<15 min/session). One client recently had six teams doing it twice a day on a very time senstive program.

For many years we have worked with clients on “process research and development projects.” These are characterized by projects to create (in most cases) bleeding edge manufacturing capability for a complex fabrication process.

The essence of FTTM success is Refresh Planning. The key to deploying Refresh Planning is to make it a habit. It is the rhythm of the process which drives team rhythm that makes it effective as one of the key factors of schedule acceleration -- it is the rhythm of accountability.

We often see advanced development teams miss the obvious; in terms of a technical solution or an innovation in the way they work, which could result in an acceleration of the project schedule. Why do brilliant people sometimes miss the obvious?

We’ve observed two types of project environments; one where people seem to have their head’s in the sand; they try to avoid looking into the future for fear they may find potential problems, and another type on fast projects where they design-in an “early warning system,” so they can quickly identify future failures while they have time to prevent or fix them.

When are you able to predict a project end date, with confidence? Of course it depends on the specific project, the quality of planning, the experience of the estimators, the experience of the team, what is known or not known, the degree of innovation/invention required, the fluidity of requirements, and sufficient historical trend information with which to forecast forward.

We have been experimenting with using Pixar's Braintrust idea to conduct critical project reviews.

Perhaps the hardest part of planning a technology development project is to answer these rather basic questions.

A target date is a point in time, in the future, that something is needed. It is essential for measuring the performance of a project. Is the project getting closer to hitting the target date or is the project trend showing that a team is predicted to miss the target date? And by how much time? It only works if the target date is real, and one that the project stakeholders agree to, in advance.

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.”

Successful teams use the "do-it, try-it, fix-it" cycle. Slow teams typically spend long periods of time trying to "get it right" for fear of failing. Some corporate cultures tend to punish for failure rather than reward for success. They don't make the trade-off between long duration and that last 10% to make something "perfect." They default to getting it right over getting it done (soon). This model means that you had better be right at the end of the cycle. If you have to rework then this will take even more time.