Continuous Project Planning is a set of core concepts to handle some of the inherent difficulties associated with planning and managing projects.
This document will describe what they try to solve, when they are applicable, and present these concepts with motivations.
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 be equally wrong in both directions, so that half the tasks takes half the time, and half takes double the time, the average is still 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.
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 – The 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.
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.
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 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 it is a reasonable assumption, and it has some nice mathematical properties.
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.
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 difficulties you might come across. 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.
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.
With uncertainty information, you can councisly choose what risks you can accept. By monitoring how the probabilities and risks change as work progresses, you will get an early warning if you need to do something.
The report swedish-project-review-2020 finds a strong correlation between project success rate and the organization risk management maturity level. Organizations with a self rated low risk management maturity level reported 25 % project success rate, while those with a high maturity level had a 75 % success rate.
Even though almost everyone thinks that risk management is important, only 19% of respondents in the report rates their risk management maturity as high.
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.
Good information is key to making good decisions. By continuously updating, you are always ready when desicions need to be made, and you will discover if project success is in peril earlier.
Again referring to the swedish-project-review-2020 report, almost everyone thinks project data and reporting is important. Despite this, only 21 % of the respondents rate the relevance and accuracy of their data as high. The report also found a significant correlation between relevant and accurate data and reporting, and project results.
The report also finds a correlation between the ability to manage and adapt to change and project results. You live in an uncertain and changing world, so do not expect your plan to ever be done.
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. The rule of thumb is that the last 10 % takes half the time.
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 the head.
Regarding milestones and deadlines, acknowledge the uncertainties and that you never can be 100 % certain of a date. This may be uncomfortable as it is much more pleasant to get a straight “Yes, it will be ready on time”.
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.
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 do about it. There will be a natural reluctance to make this signal, until it is an undeniable problem, and probably too late to do something about.
You prefer to hear good news, and your co-workers prefer to give you good news. If you instead want accurate information, you must work with how you ask, and the work place culture.
"Going according to plan" refers to a static plan. The plan should not be static, it should be kept up to date to reflect reality.
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.
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.
There is a study from NASA showing the correlation between how much time is spent on project preparations, and how much the project goes over budget. At 25 % they could stick to the budget pretty accurately.
If you are not NASA, you may find it difficult to spend 25 % of a project budget before making the decision to start it. Prepare until you have the certainty you need to proceed, and keep the plan up to date as work progresses. Be ready to act when the updated plan reveals new or changed risks, or opportunities.
The activities that make up the project should be reasonably sized and logically scoped. 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.
To not micromanage at a detailed level also empowers the team to make their own more optimal decisions.
Logically scoped mean that those involved understands what work it includes, and what it means that it is completed. If it is unclear, some required work may not be included in any of your planned tasks, or there may be overlap.
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.
Empower your team to ignore the plan when necessary to help each other to solve critical problems. Make information available so that everybody knows the priorities, and can make these calls without a lengthy formal approval process.