My #NoEstimates approach for project plans

This article is built upon a single analogy: planning a project cannot be done with a GPS, it requires a roadmap. Why? Because GPS simply does not exist in software projects. We only have roadmaps.

Here are the things that a GPS does automatically, and that we have to do manually in a project:

  • define the exact road between the start point and the final point
  • estimate the length of the road
  • estimate the time to cover this length
  • decide the intermediate points to get to the final one

But, with a simple road map and no GPS, we can make a very accurate and flexible plan for a Software project.

How to plan without any track-record?

Some years ago we decided, me and a friend of mine, to make a bike trip across France. We had never done anything like this before (i was better at running)! We had some 700kms to go, from Caen (near the French north coast), to Severac-le-Chateau – a little town not very far from Montpellier (in the South of France). The global distance was around 700kms. It was in 1994, we had no GPS,no Internet,  only a roadmap, and a simple curvimeter. Our host in Severac-le-Chateau wanted to know when we would arrive, and we were not able to answer him in the first place. Even with a map, we had to do some preliminary work.

Divide into one-day tasks

We knew that for us it was not very difficult to ride at 25kms/hour during one or two hours, so we should be able to ride 3 hours at an average of a little less than 20km/hours, then stop for a lunch, and then perhaps ride again during 3 or 4 hours and cover in a day the distance of 120kms.

We planned to do only 90 kms the first day, because it would be the first stage and we would have to find the good pace, then probably we could cover 110kms the second day, and start riding at an average of 120kms per day from the third day.

With our manual curvimeter, we measured the rough distances on the map: we saw that the first day we could arrive in the town of Mortagne-au-Perche, which situated at more or less 90kms from our starting point. We then measured the stages for the next days: we found for the second day a town that was situated at more or less 110 kms from Mortagne-au-Perche, and so on.

By doing that we noticed that from the 5th day, we would ride across mountains  – the Massif central in the center of France – and therefore we decided that during these days we would travel an average of 90 kms per day. We finally planned that that it would take us 7 days to arrive at Severa-le-Chateau, our final destination.

We did it because we were able to divide the trip into one-day tasks.

Readjust each day

It is interesting to point out that even with our lack of experience, this day to day estimates was more or less accurate. We did not cover each day  the exact number of kilometers in the given time, but we were not mile away from our estimate. Moreover each night we were able to adjust the stage that was scheduled for the day after, because we had several interesting indicators:

  • where we were;
  • how much kilometers we had covered in a day;
  • where roughly, we should roughly be be the next day, so that we could still arrive at the scheduled date at the end of our trip.

So we just had the readjust the parameters that we had first scheduled for the next day. We had several options:

  • decide that we would ride until a later time the next day
  • decide to have a shorter lunch breack
  • decide to get up earlier
  • (…)

But it was just some parameters that we had to adjust, based on gained experience, and a better knowledge of our performances.And guess what? We finally we arrive at the scheduled date.I think we could apply the same principles for a software project.

Planning a software Project as a bike trip

Here is what I recommend:

– Slice the project into one-day tasks (This will help us, because it is much more difficult to estimate something for more than one day)

– Reassess each night what we had scheduled for the day after. We can adjust the following parameters:

  • Adapt the number of resources at a given time
  • Adapt the scope
  • Decide some overtime during a short timespan if needed
  • Change the priority of the tasks

On a day-to-ay basis, these changes will be small, and won’t seriously affect the project. Moreover, the team and the customer will have the (true) feeling that the project is under control, and has flexibility.

Deal with the unexpected

To go back to the bike trip, several unexpected events happened during the trip: one day my friend had to change his wheel, and the nearest bicycle shop was 30kms backward. I had to go there by bike, come back to where my friend was waiting for me, then we repaired and continued riding. Unpredictable events like this could be managed: as we knew where we were supposed to arrive that night, we decided to ride until late in the night. The next day, we slept a little longer, made a short lunch break, and arrived where we we had planned this next day.

Final point: references for estimates

My final point will be a remark concerning the traditional thought that states that when we do a project that is similar to another, we have a good reference to estimate it.

If I compare with the example of this road-bike, that is not really true: after a two-weeks rest at our hosts house we made the trip by bike to go back from where we had started. Guess what: it took us half the time that we had needed to arrive to Severac-Le-Chateau. Nobody could have guessed that!

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s