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.

Breaking-set is a key technique fast teams use to reset and accelerate.

A walk through observations of how a new product development project evolves. We’ve observed three distinct phases; gestation of an idea, creation of the product, and overrun. Overrun should not be a phase, but by default it has become a default part of development, as a result of poor planning.

Why break-down long duration activities that fall within the near-term planning window (i.e. next 2 months)? Following, is a discussion of why this is important and how best practice teams do it. Call it “the duration game” because it is one of the most common games we see played out between those that manage and those that do. We know you’ve seen this next example on your last project.

You have to accelerate the schedule in order to be on time. In other words, you need to pull-in the schedule just to be able to meet the committed target date. This is called "time banking." You accelerate to gain time now, since you know unexpected things will happen in the future, where you will need to use that banked time. What is certain, is uncertainty! Only a fool assumes a plan will materialize as planned.

The underlying concept is to track schedule trends and use the movement to predict future events and/or to generate energy today to influence the future. Challenge Targets are the most aggressive form of a schedule goal. Many times, Target Dates are confused with the “real” schedule. The Target Date is when something is “wanted,” but this is not always when it will be delivered. Knowing the gap between when it is wanted and when it can be delivered is one of the key factors that differentiated fast teams from the norm.

There’s usually a gap between when something is wanted and when something can be delivered. Sometimes it is known, often times it is “felt” — yet teams lack data to prove it. Sometimes when its known, attempts are made to ignore the gap for fear that the gap will become a self-fulfilling prophecy. Yet “knowing the gap” can be a powerful tool to create a sense of urgency, well before-the-fact.