There are many ways to measure a plan’s quality. Some of these are: flexibility, how realistic it is, and the number of internal or external dependencies. But in the end for most people a plan is about delivering some end result within some stated time.

A plan shows both approach and time—How and When. It shows how we’re going to get to our end result, and when the various elements (let’s call them “tasks”) will fall into place. The How is mostly of interest to those inside the project team and to those seeking assurance. For those outside the project the When is more interesting. In fact, if the How changes multiple times it’s perhaps of little consequence as long as it delivers largely to expectations.

For those people who really care about the When, the quality of a plan is tested in one of two ways: either at the end (by which time it’s too late) or by tracking progress throughout its execution.

But tracking progress throughout is often misleading, for two reasons.

First, if each task is a different kind of activity (e.g. design a process, complete a contract, recruit a team) then how quickly we complete one has no bearing on how quickly we complete another. For example, if we design our process slightly ahead of the estimated time then it doesn’t follow that we’ll also complete our contract ahead of its estimated time. All it means is that we over-estimated the design process. Thus it may look like we’re ahead of schedule, but that past performance tells us nothing about future performance.

Second, if an earlier task is needed in a later task (i.e. there’s a dependency) then we can’t really say the earlier task is “done” unless we’ve proved that it works in the later one. For example, if our process design tells us how we recruit a team then we’ll only really know how good that design was when we’ve completed the recruitment. We may find it’s slightly lacking and we have to adjust the design. This will set us back. Our perceived progress is found to be false.

There is a good solution to both the above—it’s to structure our plan so that we demonstrate end delivery throughout execution. Of course we can’t demonstrate full delivery before the end (by definition) but we can demonstrate doing something that touches every bit of the process early on. This is a simple delivery. Then we repeatedly improve that, resulting in repeated deliveries.

We can be more confident about progress using this approach because we’ve tackled the two problems above. Each sweep through the system or process is touching areas we’ve largely worked in before, so there are fewer unknowns. And we’ve connected the various elements early on, so our dependencies are much better understood and tested.

Thus testing when we will get to our final goal is fundamentally tied to how we structure the work.

There are other advantages to structuring our work to deliver incrementally. But for the purposes of this blog post the lesson is this: It’s very difficult to assess whether a plan will deliver on time unless it’s first structured to deliver end-to-end repeatedly throughout its life.

Photo by Norbert Relmer