What is your confidence in solving that problem on that date?
/This question is typical in every innovation project. Innovation projects, by definition, drive the technological envelope into the unknown.
So how can you plan what you don’t know?
You can’t, but you can make assumptions about how many tries it may take before you find a solution, based on the complexity of the problem you are trying to solve, in order to achieve the innovation required.
We call these design/build/fail iterations “Learning Cycles.” Learning Cycles can be defined in terms of tasks, durations, and dependencies. These assumptions can result in a schedule or a prediction of when you will fail. The faster you fail; the faster you learn, the faster you solve the problem, and the faster you innovate. The trick is to have enough information and experience to be able to estimate how many Learn Cycles might be needed. We find the number of failure cycles needed are universally under-estimated. It is usually 10X what ever anyone estimates them to be at the end of the day.
Along the way you get read-outs of progress. These typically take the form of improved performance or a better understanding of why something is not working as designed/expected. When you know why it’s not working, then you have a better chance to redesign it so it does work.
Why don’t people make better estimates of failure cycles? Because, if they put down what they really thought they’d need then their schedules would be way too long. So they force-fit the Learning Cycles into the time available for its completion… but we all know how this comes out. Almost 100% of these projects fail to meet their targets on time, because the targets failed to consider how much learning was really required to achieve the technical breakthroughs. Typically, the problem is one of how target dates are determined, not how effectively engineers find solution
When we plan innovation projects we use Cycles of Learning and periodic Read-outs to help us measure schedule performance. Since it is impossible to predict when a team will find a breakthrough or invent something, the best we can do is approximate the number Learning Cycles and estimate a Confidence Level, again based on what we know and don’t know at that given point in time. By placing a Confidence Level (albeit an arbitrary guess) on a Learning Cycle or Read-out milestone we can communicate to a leadership group when technical achievements will be realized with a confidence “caveat.” Further, we can use the schedule to show how that confidence changes (or hopefully improves) over time as the team conducts more experiments and the read-outs from each cycle are evaluated.
fastProject has a Confidence Trend capability to implement this concept in order to provide more realistic assessment of a new technologies maturing over time. We can’t predict the future, but when using this function in fastProject, we can answer the question; “We have X confidence in hitting Y Performance on Z date.” The following illustrates the confidence trend concept on a simple example schedule.
An Example of Confidence Trends
Simple schedule showing confidence levels
In this example we have two experimental paths to solve a problem, one based on finding a Profile solution and the other an Angle solution. We made this up, so think of this as a conceptual example. We can’t use any real client examples for the obvious reasons, but their schedules are much more interesting, so this example should suffice. We have identified the desired result that is expected from each experimental cycle (i.e. text in the "Confidence %” column). Also in this column is the estimated % confidence through each iterative cycle.
When you estimate “confidence” levels you are really saying “I expect certain results by a given date and I have x% confidence in those results by that date.” The confidence level is your estimate of, in effect, risk. It is an estimate of the results expected as well as on those results being known at a specific point in time.
If you don’t expect much, then your confidence level has to be low. If you are hunting for a solution and you don’t know exactly how to get there, then your confidence level has to be low. Confidence levels should improve over time as you learn more. So it is expected that the confidence estimates in the schedule will also be updated based on the knowledge learned from the results of the experiments.
Example Confidence Trend Report (based on the schedule above)
Above is an example of the Confidence Trend Report. This clearly shows the maturing of the solution over time for each of the paths outlined in the schedule above.
EXAMPLE of confidence level placed on the target (i.e. project milestone)
When adding the confidence % to a project milestone associated with a target, it is presented on the Wigglechart. In this example above, I’m 17 days late and I’m 60% confident in hitting the predicted date with the technical results I’m expecting, based on the DOE’s I’m running. So I’m late, yet still have a relatively low confidence that I will have a solution by the predicted end date. This provides leaders above me with a better understanding of timing and expected results. Imagine this Wigglechart minus the confidence factor. I would be showing that I’m close to target, but would not be reflecting the concerns of the team that they still don’t have all the answers. The next question I should expect is, “So how many more learning cycles do you need to raise your confidence level?” Using this process I can answer that question.
For more on the Learning Cycle concept read this article.