* We keep saying "what we think we have to do", because however good the requirements are, they will change, because we learn, they learn and the circumstances change. The longer the project, the more the requirements have a chance to change. And they will change! However, what we do not yet know, we cannot yet plan for. So we keep improving our knowledge about the real requirements, but we only can plan based on what we currently think we have to do.


The Evolutionary Planning process uses three main elements, see also booklets 2, 5 and 7:

We’ll show now how these three elements fit together to get and keep the project under control.


figure 1: Standard approach: it takes what it takes, but often that’s too late

In many projects all the work we think* we have to do is cut into pieces, the pieces are estimated, and the estimates are added up to arrive at an estimate of the effort to do the work. Then this is divided over the available people (however, beware of Brooks’ Law!), to arrive at an estimate of the duration of the work, which, after adding some contingency, is presented as the duration of the project (figure 1).

A problem is that in many cases the required delivery date is earlier. The tension between estimated and expected delivery causes extra time spent in discussions, while the required delivery date doesn’t change, leaving even less time for the project.
Because the delivery date is a requirement just as all the other requirements (see:'The importance of time'), it has to be treated as seriously as all the other requirements.

With TimeLine, we treat delivery dates seriously and we meet these dates, or we very early explain, based on facts, why the delivery date really is utterly impossible to meet (because it's in the nine-mothers area1).
We don’t wait until the FatalDate to tell that we didn’t make it, because if it’s really impossible, we know it much earlier. If it is possible, we deliver, using all the time-saving techniques we have at our disposal to optimize what we can deliver when.

figure 2: Basic TimeLine: what will surely be done,
what will not be done, and what may be done
if we would keep working the way we're working now

TimeLine can be used on any scale: on a program, a project, a sub-project, on deliveries, and even on Tasks.

The technique is always the same. We estimate what we think we have to do, see that we need more time than we have and then discuss the TimeLine with our customer or other appropriate Stakeholders and explain (figure 2):

If what surely will be done is not sufficient for success, we better stop now to avoid wasting time and money. Note that we put what we plan in strict order of priority, so that at the FatalDate at least we’ll have done the most important things. Customers don’t mind about the bells and whistles if Time to Market is important. Because priorities may change very dynamically, we have to constantly reconsider the order of what we do when.

Setting a Horizon

figure 3: TimeLine: find out top-down what will happen, calibrate bottom-up
to see what will really happen, then use your disappointment of what
you see to do something about it (see option#6 at 'Saving time')

If the total project takes more than 10 weeks, we define a Horizon at about 10 weeks on the TimeLine, because we cannot really oversee longer periods of time. A period of 10 weeks proves to be a good compromise between what we can oversee, while still being long enough to allow for optimizing the order in which we deliver results. We don’t forget what’s beyond the horizon, but for now, we concentrate on the coming 10 weeks.


Within these 10 weeks, we plan DeliveryCycles (figure 3) of maximum 2 weeks, asking: "What are we going to deliver to whom and why?"

Deliveries are for getting feedback from Stakeholders. We are humble enough to admit that our (and their) perception of the requirements is not perfect and that many of our assumptions may be incorrect. Therefore we need communication and feedback. We deliver to eagerly waiting Stakeholders, otherwise we don’t get feedback. If the appropriate Stakeholders aren’t eagerly waiting, either they’re not interested and we may better work for other Stakeholders, or they have to be made eagerly waiting by delivering what we call Juicy Bits. How can Juicy Bits have a high priority? If we don’t get appropriate feedback, we will probably be working based on incorrect assumptions, causing us to doing things wrong, which will cause delay later. Therefore, if we need to deliver Juicy Bits to Stakeholders to make them eagerly waiting in order to get the feedback that we awfully need, this has a high priority.


Once we have divided the work over Deliveries, which are Horizons as well, we now concentrate on the first few Deliveries and define the actual work that has to be done to produce these Deliveries. We organize this work in TaskCycles of one week. In a TaskCycle we define Tasks, estimated in net effort-hours (see booklet#2, section 6.1, for a more detailed explanation). We plan the work in plannable effort time, which defaults to 2/3 of the available time (~26 hrs in case of a 40 hr week), confining all unplannable project activities like email, phone-calls, planning, small interrupts, etc, to the remainder of the time. We put this work in optimum order, divide it over the people in the project, have these people estimate the time they would need to do the work, see that they don’t get overloaded and that they synchronize their work to optimize the duration.

Continue with Calibration and
with Feeding Portfolio Management

  1. Nine mothers area: Some people think that if you take nine mothers, you can make a baby in one month.