The Busy Person's Project Management Book

Chapter 4 - Different projects, different paths

Having determined your scope, objectives, stakeholders, risk and potential strategies, you and the team can begin to determine the specific tasks and estimates for your project.

Again, when planning a journey, we are faced with similar activities. For our business trip, we have to decide what tasks, time and sequencing are involved in getting packed, organising the kids, getting care for the pets, packing and so on.

In our day-to-day projects, we tend to do these activities informally and often by rote. When planning projects, the processes of task identification and estimation are too important to be done quickly and informally. As with the other activities required for developing our plans, the task listing, estimation and scheduling should be done in a open team session. If there are tasks which require stakeholder involvement, they should also be involved in these key processes.

Task identification or work breakdown

It is surprising that task listing is probably the easiest part of project planning yet one of the most important. One of the most common reasons why projects take longer than expected is the simple fact that the team forgot an important task while planning their project. When you're working on a 6 week project and discover that you have to add another 6 week task - you're 100% behind schedule immediately.

Task identification involves an approach that is formally known as project development life-cycle or work breakdown structure or, for technical projects, a methodology. However, despite these impressive terms, it simply involves a series of loops involving the brainstorming of tasks and then breaking up the tasks into smaller sub-sets as shown in Figure 14. You should allow the brainstorming process to be as creative and as free-flowing as possible. It is very important to not confuse the task identification with the process of scheduling the tasks. Just let the team identify the tasks in any order and then worry about the sequence of undertaking the tasks in a separate session - see scheduling later in Chapter 5.

As we get more experience in project work, you will begin to notice that some projects tend to involve similar tasks. As a result, you can begin to develop basic templates of tasks or work breakdown structures for specific project types. A basic project development life-cycle is included in Appendix C. This can provide a basic framework for developing your own project task list.

While you and your team are identifying the tasks, the following tips should help you in the process:

• 5/10day rule

  It is a good idea to keep breaking up the tasks into smaller tasks until you arrive at tasks that would take between 5 to 10 days to complete. This makes it easier to keep track of how you're going during the project;

• has anyone been here before?

  See if you can find anyone who has experience in the type of project you're planning or who has been involved in doing similar tasks in other projects. This is common sense but it is surprising that the "not invented here" syndrome exists in projects as well as in other activities;

• what is the output from the task?

  For each task you list check out that everyone in the planning session understands the outputs that will be produced when the task is complete. For example, a visit to other user sites of the training vendors will result in a Site Visit Report.

Fig. 13 - A work breakdown structure

Probably the most important tip is that a team will always produce a more comprehensive work breakdown than an individual. By using your team members and stakeholders to help you identify tasks, you will get a more accurate list and a better understanding by all team members of what is required from them in the project.

Task estimation

Having got your task list, the next step in planning your project is to estimate the tasks. Before we look at a couple of techniques that can help you derive more accurate estimates for the tasks, we must get some ground-rules clear.

Look at different scenarios

In our day-to-day activities we have been taught to estimate using a single estimate. For example, most of us will say to friends whom we are meeting for dinner " I'll meet you at the restaurant at 8.00 pm". In estimating projects, it is better to consider three scenarios : Best case which assumes everything is perfect; Likely which allows for some things not going well and; Worst case where everything goes badly. In our restaurant example, the Best case is when the babysitter is on time, the kids do not want you to help them with their homework and the car has enough petrol. As a result, you get to the restaurant at 7.50 pm. The Worst case is that the babysitter is 20 minutes late, the kids want you to watch the end of Neighbours and the car is out of petrol, etc. You arrive at the restaurant at 9.15 pm and your friends have left. As you can probably see, the same things can happen in projects and your project sponsor, team and stakeholders should all be made aware of the Best, Likely and Worst case situations and estimates. This approach is called Sensitivity Analysis;

Risk has an impact on estimates

Our risk assessment which you must complete before you estimate the tasks, will have a significant impact on the size and accuracy of your estimates. Simply, the higher the risk the bigger the estimate and the higher the probability that your estimates will be wrong. Let's assume that Mary is planning a visit to various companies that use an education vendor that she wishes to review. She has three sites to visit. In a low risk project scenario, the three sites are within walking distance of her company, the training people in the sites are prepared to co-operate and Mary is allocated full-time to the project. In a high risk project scenario, the three sites are in different cities, the training people in the sites are busy and are giving Mary's visit a low profile and she are part-time on the project. Clearly, in the high risk scenario, she will take much longer to achieve the review;

A team estimate is always better than an individual estimate

Each one of us has skills that we have mastered and as a result we have a good understanding of how long it will take us to undertake tasks involving those skills. In project work, you will often be required to estimate how long a task will take and that task is one where you do not have experience or skills. In this case, an open discussion with the team about the task estimate (as we'll discuss later) will enable you to get a better grip on what the task involves and how long it should take. In many cases, it is not the estimate of the task that is wrong but the understanding of what the task involves. Further, because we are all so different in skills and capability, a group discussion of estimates will provide different views, assumptions and a more detailed understanding of the complexity and risks of the task resulting in a more accurate estimate.

Fig. 14 - Let's talk about it

Separate effort from duration

This guideline may appear a little strange to some of us. However, in projects we are really working in two times. The first is the actual time (effort) required to complete the tasks and the second is the duration (elapsed effort) required to allocate the effort. For example, Mary requires 6 hours to review the specifications of her project but because of other tasks she can only allocate 2 hours a day so the elapsed time is 3 days for the 6 hour task. You should estimate in effort first then as discussed in the next chapter, adjust the effort estimates to duration during the scheduling of the tasks.

Delphi estimation

A very good approach for estimation of both effort and duration is based on the Delphi technique developed by Herman Kahn of the Hudson Institute for use in predicting long-term social and economic trends. It is a team-based technique and is easily applied for all types of projects.

It involves 9 simple steps:

• Step 1 - provide team members and stakeholders with the relevant information regarding the project, ie. the scope, objectives and stakeholders as described in Chapter 2;
• Step 2 - conduct a formal risk assessment and select the project development strategy as described in Chapter 3 to ensure that all team members have discussed their assumptions and views;
• Step 3 - brainstorm the task lists as described earlier in this chapter;
• Step 4 - each person individually estimates each task using Sensitivity Analysis to provide a Best case, Likely and Worst case estimate for each task. The Best case assumes everything goes as well as it can, the Likely assumes that some problems will occur and the Worst assumes that many things will go wrong and our assumptions are incorrect;
• Step 5 - all estimates are written on to a whyte-board and grouped in the three ranges;
• Step 6 - each person discusses the various assumptions and issues they considered when developing their estimates;
• Step 7 - where required, the various estimates are adjusted based on the team discussion;
• Step 8 - each range is averaged with out-riders (those estimates that are not adjusted through the team discussion and are outside the ranges evidenced in the estimates) are discarded;
• Step 9 - the resultant ranges are used as the basis for scheduling as discussed in the next chapter.

The Delphi process results in a highly-discussed and ranged set of estimates as shown in Figure 15.

Fig. 15 - Wide-band delphi estimates

Now that you have three estimates for each task, there are two easy ways for determining which of the three estimates you and your team will use for developing the project schedule. The first is to select the range reflecting the risk of your project. That is, for a Low risk project you will use the Best case estimates; Medium risk uses the Likely and; High risk you will use the Worst case. A better variation is for you and the team to complete a quick and informal risk assessment of each task and to use the ranges as above for each task. For example, in Mary's project, she and the team see the analysing of the current system as Low risk and use the Best case estimate for that task. However, the programming is seen as High risk and the team uses the Worst case estimate for that task.

Don't worry if you spend a fair bit of time in developing your task lists and estimates during the project planning process. The task listing and estimation process is vital in developing the costs for the project and for providing the basic data for developing the final project planning outcome - the project schedule. It is obvious that the more rigorous the estimation and task listing the more realistic would be the schedule and other project information.

Given that many projects are about significant changes to the way we do things, it is probable that our estimates will be wrong because of the "newness' of the tasks we have to undertake. What is important here is not to hide the fact that you have made estimation errors but rather to immediately see your project sponsor and discuss what needs to be done to re-plan the project. We'll discuss this in more detail in Chapter 7.

A very brief note on project costing

The team estimates can be used as the basis for developing the project costs. In most small projects, the biggest cost component will be people and their time. However, in some projects, there will also be some costs required to purchase new equipment such as computers, furniture, printing and training equipment, for example.

Your organisation's Finance people in your area can give you assistance in developing the various costs involved in your project

copyright: Thomsett INTERNATIONAL 2010 | contact