Continuous Project Planning

Continuous Project Planning

Continuous Project Planning

Continuous Project Planning is a set of core concepts to handle some of the inherent difficulties associated with planning and managing projects.

The Problem

Humans are inherently bad at predicting how long things will take to do. There are many interesting reasons to why. One is that evolution has made us optimists, because it has in evolutionary times been better to try and fail, than certainly fail by not trying. Our optimism and willingness to please results in projects generally taking more time than we originally thought. Even if we would manage to equally wrong in both directions, so that half the tasks takes half the time, and half takes double the time, the average is more than originally anticipated.

Humans do not like to be wrong. Making a plan is hard work, and changing it means redoing some of that work. And it would mean that you were originally wrong. Therefore it tends to take too long to acknowledge that a plan is wrong. And there is an incentive to stick with the plan, long past it no longer makes sense compared to reality. This leads us to bad decisions, just like navigating by an inaccurate map would.

Applicability

There are many project management methodologies and methods, each more or less applicable to different situations. The concepts of Continuous Project Planning assumes that:

  • Complexity – A project requires coordination of different people or teams with different skill sets.

  • Size – The project encompasses more than two people, and at least a few weeks of work, or shares resources and needs coordination with other projects.

  • Need – There is a need to predict and monitor budget and / or when the project will finish. This may include hard deadlines, or not.

Core Concepts

Estimate uncertainty

When you are estimating the time an activity will take, do not give one absolute number. Acknowledge that you do not know for certain, and estimate a probability distribution for how much time it will take.

Put one number down for the minimal time the task will take. This is the time it will take if everything goes without problems. It should be an estimate that is not impossible, but it should be unlikely that it will take less time than this.

Then you estimate how much time you reserve for this task if you are to be reasonably sure that it will be finished within this time. Reasonably sure is defined as seven times out of ten it will take less time. If you are estimating correctly, this also means that three of ten activities will take longer.

Rationale

There are several benefits to estimating time using two numbers. You can put all your optimism and peer pressure into the minimal time and say “Yes, I could do this fast, if there are no complications”, and then imagine all things that could go wrong and have a more reasonable “Reasonably sure” estimation.

Defining reasonably sure as 70 % is quite arbitrary, but it tends to fit reasonably well with what reasonably sure feels like, and it is a range of possibility that we as humans can grasp.

Having the time estimate as a probability distribution means that you actually can not be proven to be wrong based on a single estimate. If you estimate a given task to take at least 30 hours, and reasonably sure less than 60, and it ends up taking 80 hours, it just means that it ended up on the less likely end of the probability distribution. That is supposed to happen to three out of ten activities. And as we hate being wrong, this is a good thing.

Estimating uncertainty gives you much more information than a single number. You can spend more effort reducing the uncertainty before you commit to the project, if the uncertainty for a task, or a group of tasks, is unacceptably high.

The definition of the proposed time estimation is quite precise, even if the act of estimation still is difficult. This is an advantage compared to giving one number. If not explicitly defined, different people may put different uncertainty margins in their one number estimate. You will not know if this is a best case scenario, an expected average, a reasonably sure or an almost guaranteed number.

You do not need to understand the mathematics behind this method, but we will treat this estimation as the minimal time plus a stochastic variable with an exponential distribution. The assumed distribution is probably not correct for a specific task, but on average is a reasonable assumption, and it has some nice mathematical properties.

Involve the developers in planning and estimation

If possible, it is best to let the person that will do the job in the end estimate the task. No estimation should be done in isolation. More than one person should be involved, ideally someone that has done something similar before. Look at how long similar tasks have taken before, and what unexpected problems they encountered.

Rationale

Who will do the work will affect how long a task will take. Different people have different skills and experiences, and the person doing the task may know a thing or two about their own capabilities.

To estimate a task accurately you will need to get a good idea of what it entails, what the problem is, how to solve it and what problems might occur. How much effort you spend on this depends on previous experience and need of accuracy. If this effort is done by the person who is later doing the work, it is not a wasted effort. It becomes to some extent part of actually getting the task done.

More than one person should be involved, because it is easy to forget parts of the task, overlook complexities, miss the glue needed to connect different tasks, and overlook risks.

Calculate probabilities

When you are adding up the estimated activities, use the uncertainty information in the estimates to get a new probability distribution. This gives way more information than absolute numbers with unknown uncertainty.

You get an expected cost for a budget calculation, and a cost at any confidence level you desire. This is information you can use when deciding whether to start a project or not, as you can weigh the probability and benefits of success against the probability and cost of failure.

Also when scheduling tasks in calendar time, keep track of uncertainties. Calculate probabilities for when tasks will be finished and milestones reached. Calculate the probability for reaching each deadline on time.

Continuously update

The plan should be updated as the work progresses. Everyone working on the project reports the work they have done, so progress can be tracked. As you work with an activity, you will gain more knowledge, and you should update how much work remains as you gain this knowledge.

When working with one activity things learned may also give you more information on other activities, which then also should be updated. New activities may be discovered and added, and others may me removed as requirements and priorities change.

Never ask if things are going according to plan

One important principle when keeping a plan up to date is that you always focus on the future. Never on what you did think in the past.

There is no point in saying that you are 90 % done, when the basic principle is that you are not certain how much work 100 % is. (It is common knowledge that the last 10 % takes half the time.)

One common practice is to mark a task with green, yellow or red. If you mark it with yellow or red it is a signal that there is a problem, and a manager will come and ask you what you are going to to about it. There will be a natural reluctance to make this signal, until it is an undeniable problem, and probably too late.

For activities you should ask for a new estimate on how much work is left. This way the instinct shifts to making an as good estimate as possible, even if the original estimate still may linger in the back of your head.

Cultivate a culture where cooperation and asking for help, and helping, is encouraged. And as a manager you should actively probe if someone has problems and would benefit from assistance.

Regarding milestones and deadlines, acknowledge the uncertainties and that you never can be 100 % certain of a date, unless you are certain that you will miss a deadline. This may be uncomfortable as it is much more pleasant to get a straight “Yes, it will be ready on time”.

Automate updates and scheduling

Making a plan is hard work, and keeping it up to date is repeating that work. Continuous Project Planning is therefore almost impossible if you do not have tools to help you. This tool should do the uncertainty calculations, and it should automate the scheduling of activities in calendar time.

To facilitate this you divide your project into estimated activities. Define how these depend on each other, as in: “This must be completed before that can start.” and “This deadline requires these activities to be completed.”

Assign activities to people or teams. Prioritize your projects, or milestones within projects.

This information is enough to automatically create a Gantt like schedule defining who does what when. This automation is necessary to calculate probability distributions for when things will be done, and is crucial for being able to continuously update the plan.

Adjust your planning effort to your need

Estimating a plan requires work. Estimation becomes more accurate if you spend more time on it, to the point that it is perfectly accurate when the project is completely done. Therefore you must weigh how much effort you put into planning and estimation against how important accurate predictions are.

If you do not need more information, it may be perfectly OK to leave a giant activity named Software with an estimate of 500 minimum and reasonably sure less than 2000 hours, until you actually need to know more.

Additional advice

Defined logical and reasonable sized activities

The activities that make up the project should be reasonably sized and logical. It must be possible to complete in one continuous work effort by one person (or team), and produce some meaningful result.

Many really small activities becomes cumbersome to administrate, and activities that are not estimated to be completed within three to four weeks with reasonable certainty becomes to big to grasp. It is perfectly fine to define an activity as several smaller tasks that are strongly related and should be performed by the same person.

The scheduling tool is not your boss

On the same note as to adjust your planning effort to your needs, you are free to ignore the scheduling the tool suggests. You may have more information than you care to put into the tool, and can foresee at least the short term consequences. As you report work done, the tool will adjust scheduling accordingly.

The calculations the tool presents can never be more accurate than the information put in to it, so you should try to keep the input accuracy as high as possible. If the scheduling the tool presents differs from what you plan to do beyond the current week, you should make the effort to make them match.

Who we are

The_PlanMinder_logo

by:

Who we are

The_PlanMinder_logo

by: