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.

Converge in 1/3 of the time, get to market, generate revenue and then iterate further technology generations. Knowing when to converge is the trick. Converge too soon and you may end up with the wrong product, wait too long to converge and you run the risk of delivering too late.

How do we practice the "Planning with no constraints" philosophy during the build/model session?

It seems counterintuitive not to consider constraints when planning.

Constraints are real and should be a factor, shouldn't they?

How do risks get reflected in a development schedule?

Risks are unknowns. How does one incorporate the impact unknowns could have on a schedule if they don't know what they don't know? What "is known" is that risk or uncertainty will cause a schedule to move to the right (expand in duration), especially when it is missing from the baseline schedule.