Hierarchy of Objectives

Project success is defined in terms of meeting project objectives.  One example of an objective is meeting the project schedule.  If the project meets that schedule, then the project is a success.  What makes things tricky is that projects have more than one objective.  The project is required to meet this schedule, but within this budget, and without having any scope left behind. 

Besides the traditional constraint triangle, there are other objectives: ensuring the project team is happy, ensuring the the project stakeholders are happy, etc. 

Not all of these objectives are equally important. Some are more important than others.  That is why team members are asked to work on weekends rather than letting the schedule slip.  That is why team members are often asked to work without extra pay -- to ensure the project budget is not exceeded.

In a project, it would be helpful to prepare a list of objectives and rank them in order of decreasing importance. That way, all objectives are kept in mind, yet at the same time clear which objective is more important. 

The list might best be kept private.

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 modeled 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 executing the task will normally take 7 days to accomplish the task, but has other stuff on their plate, so may take more that 7 days to complete the task.  Why?  Because their 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, their machine might break down, they could misunderstand the specifications,  or what's required of them 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.

***

Tip of the Day - Estimating

When scheduling any task, especially a time-consuming task, it is always prudent to assume the task will take longer than you expect.  

Things happen.  

Therefore, add an allowance as a contingency.

This is not padding schedules for the purpose of billing higher.  Neither is it about covering your behind and ensuring you deliver before the target date.

It is simply common prudence.

If you believe a task will take 3 days and you promise to deliver it in 3 days, whoever is depending on your task may decide to commit himself to starting their task 3 days later, on the assumption that you will have delivered by that time.

If you fail to deliver as scheduled, then he will probably fail to deliver his task as well.  This chain could go on through to several persons.

Not adding a contingency to your estimate is not merely being gung-ho, it's plain irresponsible.

In addition to adding a contingency to your estimate, however, you must also be prepared to work on the next task if the current task gets completed sooner than scheduled.