An approach to planning

Planning a project involves identifying the activities required to deliver the project and the inter-dependencies between those activities.  These activities and the dependencies are then modelled onto a network diagram.

Task duration estimates are often padded, as a matter of good practice, but also as a matter of covering one's behind.  Things often don't go according to plan and one has to allow for that.  If I estimate that task A will take 10 days, and I say it will take 10 days, and then something goes wrong, then not only do I look bad, I might also I end up delaying the next task which was set to begin 10 days later.  So the common practice is to be generous with our estimates and pad them for contingencies.  Such padding implicitly addresses the risks faced.  

There is another approach that integrates project schedules with risk management, and at the same time highlights the possible sources of these risks.

One way to bring this planning to a different level is to first make a realistic and optimistic estimate of how long each task will take.  Let's say if a task will take 7 days if no problems occur, then we start with 7. We do the same for each task. Then we study the task and its dependencies and try to understand what could go wrong that can cause its accomplishment to exceed 7 days.  Then we try to address those things that can go wrong.

Let's say the person doing the task will normally take 7 days to accomplish this task, but has other stuff on his plate, therefore it may take more that 7 days for him to complete the task.  Why?  Because his time and attention could be diverted to the other tasks.  If we don't highlight this reason then we can't manage it.  Suppose we identified that this person really has other stuff on his plate, then we can take steps.  We can schedule his task to be done after he has finished his other stuff, or we can arrange things so that he suspends work on other stuff, or we can just accept things as they are and simply pad the number of days.  At the very least, we have identified a possible cause of problems.  

There could be other factors to consider: this person could get sick during that time, his machine might break down, he could misunderstand the specifications,  or what's required of him and then we will need to redo things, and so on.

By thinking through the possible reasons for exceeding the optimistic estimate, we begin to identify possible causes of delays and we begin to be able to plan for those causes: try to minimize their chances of occurring, minimize the impact if they occur, etc..

Project management

Any undertaking, no matter how small, faces the possibility of taking longer than anticipated and costing more than expected. In addition, there also exists the danger that the job will not be done right. Or if indeed done right, was not what we thought was needed.

The bigger the undertaking, the bigger the likelihood of unwanted problems occurring.  The culprit is complexity.

Consider the undertaking of changing your shower curtain versus the problem of defending Normandy beach from Allied invasion.  Yes, you might slip on the floor and bang your head while doing the former, many, many more things could go wrong in the latter (and many did).

One is more complicated than the other. It is this (vast) difference in complexity that makes the other undertaking much more likely to have potential problems. Complexity is like having open doors and windows where problems are free to let themselves in. The more complex the undertaking, the more numerous the open doors and windows.

We could stay small and be content with simple undertakings, but our society's progress will be limited. We can choose to limit our undertakings to nothing more complex than mastering the art of candle-making, but our society will not progress much. If we want progress, we have to face complexity. 

Fortunately, we have tools at our disposal. 

Look at the skyscrapers and other technological marvels we now have.  Science and engineering has progressed such that it is now possible to design buildings that will not randomly fall down. We now know how to design such buildings. Complexity and its associated problems have been reduced by scientific and engineering knowledge.
But we like to push the envelope, and so complexity remains.

Every undertaking requires activities. No activity, no undertaking. The more complex the undertaking, the more numerous and varied the activities are.

Activities depend on and interact with other activities, and therefore must be coordinated. Those who need to fit glass windows to a building cannot start working until the building structure has been built. Those who need to test software cannot begin until there is some software to test.

Knowing how to design a building is not the same as knowing how to organise the activities required to build that building, and vice versa. They're not the same thing.  The training, skills, and mindset is different. The orchestration of these activities demand a different kind of knowledge, attention, and discipline from that required to design a building.

To harness the benefits of science and engineering, there is another discipline that was developed to help us with our complex undertakings. This discipline is intended to help us manage the activities and ensure that:

• We can have a confident estimation how long a undertaking will take, so we can plan for it.

• We can have a confident estimation how much the undertaking will cost

• We can identify the activities required to complete the undertaking.

• We can ensure that the undertaking will take no longer than planned

• We can ensure that the undertaking will cost no more than planned.

• We can ensure that the undertaking will be completed.

• Everyone's valid expectations are met.

That discipline is called Project Management.