From Unknown to Kind of Known

View fullsize

Volume of what is known over time and the quality of information’s “predictability index”

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.

Often teams are forced to predict/commit with 100% accuracy and certainty at the very beginning of a project; when very little is known and when the end state is not clearly defined. During this early stage of product/project definition we see teams pressured to be precise, using imprecise available information.

The external pressure often comes from market or competitive influences; “We must commit to customer X, by Y date…” or “We have intelligence that says our competitor will release project X with Z functions by Y date, therefore I need to know now if we can hit that date, and I want you to be fully confident in your estimate, regardless of the fact that we have not yet fully defined the product nor do we understand the innovations needed to make the product do what we expect it to at that time…but give me a date…”

In the early stages of a project you have to diverge (i.e. open up) in order to collect new information, with which to use to create a plan — a prediction of when a project could be finished. This is a discovery process that requires divergent thought to consider all possibilities and not limit thinking. The more complex technical problems with long duration projects are the most difficult to predict with certainty well into the future. If the project involves invention, then it is even harder to be certain.

At some point, the team must converge on a target, be it a time frame or a functional specification. We find that the optimal ratio is 1/3 diverge, 2/3 converge. When divergence exceeds this ratio, the project takes longer, since you still need 2/3’s of the time to converge. During the convergence phase we accelerate (in order to finish on time). We do this by challenging current thinking to find creative alternatives in order to cause the project to go faster. This usually forces tradeoffs in order to achieve the “minimum viable value proposition.”

During the “converge” state, the quality of the information improves as product and project matures. Executives often want to know when the quality of the plan will be sufficient to make an estimate of completion. We find that this can be done when the team converges on the target; at about the time when trend data stabilizes (using Wigglecharts) and there is enough information known about the product or technology being developed.

One of the biggest mistakes we see repeated over and over is when teams are forced to make early commitments without sufficient information. These commitments become expectations locked in concrete, to both the executives overseeing the project and to external customers expecting the product (i.e. a specific product feature set, at a specific point in time is expected). It is very hard to change expectations once they are set in stone like this. Yet this is usually done when very little is known. 100% accuracy with 10% information!

In most 2-3 year advanced development projects we work on, the point where the “predictability index” is sufficient to make external commitments, is about 2-3 months into the project. This is usually part way through the design phase. General Colin Power has written about making decisions/commitments with about 40% of the information needed. Predicting advanced development is a lot like this; you never have enough information to be certain, yet you can’t wait to make commitments until you are 100% certain. It is better to be roughly right, than exactly wrong.”

The continuous Refresh Planning process we apply to innovation projects is the key to hedging your bet and improving predictability, based on project history which is used to better predict future performance.