2 PROJECT PLANNING

LEARNING OUTCOMES

When you have completed this chapter you should be able to demonstrate an understanding of the following:

2.1 INTRODUCTION

Having described the context in which IT projects exist, we are now going to explore the steps in producing a plan for a project. You will recall from Chapter 1 that before the detailed planning of a project starts, the business case for the project is set out. This, among other things, lays out a technical strategy or ‘solution’ identifying the practical steps needed to achieve the project’s objectives. It also gives an idea of the costs of developing the solution. You need to show that the value of the proposed IT application’s benefits will outweigh the costs of developing and managing it. The overall objectives of the project, which define the successful outcomes of the project as agreed by the main participants in the project, also need to be identified.

2.2 APPROACHES TO PLANNING

There are two approaches to identifying the components of a project: product-based and work- or activity-based.

2.2.1 Product-based planning

With the product-based approach, detailed planning usually begins with identifying the project deliverables; that is, the products that will be created by the project and delivered to the client. A product must be in some way tangible; perhaps a software component, a document, a piece of equipment, or even a person (for example, a trained user) or a new version of some existing product, as with a modified version of a software component.

In the case of the Water Holiday Company integration project, the deliverables include:

Once the deliverables have been defined, intermediate products can be identified. These are products created during the course of the project, but which may not actually be delivered to the client at the end of the project. In the case of the Water Holiday Company integration project, intermediate products include (among other things):

Some products, such as progress reports, will relate to the management or quality control of the project.

The deliverable and intermediate products can be written simply as a list of products, but sometimes they are shown in a product breakdown structure diagram (PBS); see Figure 2.1 for an example.

Some of the stakeholders in the project may find there are some products with which they are unfamiliar. Some users, for example, may be unsure of what is meant by an ‘acceptance test plan’. To remedy this, planning should include drawing up product definitions. For each product, the following should be documented:

Figure 2.1 A product breakdown structure diagram

2.2.2 Work and product breakdown structures

An alternative method of planning is the work- or activity-based approach, which identifies the required work activities or tasks in a work breakdown structure (WBS). In this case, the intermediate products listed on the previous page relating to setting up the Water Holiday Company integration project would be replaced by activities such as:

As nearly all activities will generate a product – or else why do them? – and all products will need to have some activities that give birth to them, there may not really be much difference between the two approaches in practice.

2.3 PRODUCT FLOW DIAGRAM

If you have adopted a product-driven approach, it is possible to draw up a product flow diagram (PFD) showing the order in which the products have to be created. This should be relatively easy to draft if you have already produced product definitions that specify from which other products each product is derived. Figure 2.2 gives an example fragment of a product flow diagram.

Note the oval with ‘requirements document’ in it. This refers to a product that already exists and that will be used to generate one or more of the products in the PFD. There is no one correct PFD – its structure depends on the technical solution adopted to achieve the project objectives. For instance, in Figure 2.2 the assumption is that the business process model will provide most of the information needed to design the sequence of screens for both the website and the mobile phone app for the merged Water Holiday Company. A unified corporate image is needed for the company business entity and it was felt that the business models would give the designers of the style guide a good idea of the business environment. The structure needed for the interfaces and the style guide would both be taken account of in the final interface design.

Figure 2.2 A product flow diagram

The flow of a PFD is normally from top to bottom and then left to right. Looping back is not allowed – not because this cannot happen in real life, but because it is almost always possible technically to go back and re-work a product previously thought to be completed. In this case all the products depending on the reworked one might also need some re-working.

In two places in Figure 2.2 we have put boxes of broken lines around a sequence of products. This is not part of the official PFD notation. We wanted to show that a group of components (in one case, site maps, style guide and ‘wireframe’ models) will be treated as one large product (the interface design).

2.4 ACTIVITY PLANNING

Whether a product flow diagram has been drawn up or whether the planner has simply drawn up a list of activities, the next step is to draw up an activity network. This shows the activities needed for the project and the order in which they are to be carried out.

2.4.1 Activity network diagram

There are two sets of conventions for drawing up activity networks: activity on node and activity on arrow. Figure 2.3 shows an example of an activity on arrow diagram.

Figure 2.3 Activity on arrow network

As the name implies, the arrows in an activity on arrow diagram represent activities, while the circles that link the arrows (that is, the nodes) represent the ends of some activities and the starts of others. The arrows with broken lines indicate ‘dummy activities’, which simply show a dependency between two of the event nodes – for example c, the end of ‘do B’, and e, the start of ‘do D’.

We will use a different set of conventions, activity on node, which is used by most modern project planning tools, including Microsoft Project.

Figure 2.4 shows the same activities as Figure 2.3, but using activity on node notation. Here the boxes (which are the ‘nodes’ in this case) represent activities, while the lines between the boxes show where the start of one activity depends on the completion of some other activity. Note that at this stage the constraints may be technical or external. A technical constraint normally means that a product has to be created by one activity so that another can use it. An example of an external constraint is a system that can only be tested out of office hours, so it has been agreed contractually that testing will take place at weekends only.

What are not taken into account at this point are resource constraints – for example, that a person will not be able to start on one task because he or she will not have finished another. These considerations are deferred because we do not know all the competing demands on a particular resource until all the activities in a project have been set out.

Figure 2.4 Activity on node network

In Activity 2.2 we added a ‘start’ and ‘finish’. These are important points of time (or ‘events’) in the life of the project, but they will not actually take up any time. If, for example, the finish of the project was marked by a celebration that took up several hours, then the ‘event’ would become an activity in its own right. We call these important events milestones. Milestones can also be located in the middle of a project, for example at the end of one important phase and the start of the next. Always remember, though, that milestones do not take up time. Sometimes an important point in a project may be marked by a meeting to check that everything planned has been completed successfully before the next part of the project starts. This checkpoint would be an activity in its own right.

2.4.2 Estimating elapsed time

Having identified the activities and the order in which they have to be worked on, we now need to estimate how long we think each activity is likely to take. Note that we are concerned here about elapsed times. This is the time from the start of an activity to the finish. This is not the same as the effort spent on an activity. Effort could be more than elapsed time – for example, where we have three people working together on a job for two days, the elapsed time would be two days, but the effort would be six staff days. Effort could also be less than elapsed time – for example, where someone works only afternoons. Estimates of effort become important when projects are being costed. Estimating is covered in more detail in Chapter 6.

Let’s assume that we can allocate estimated durations to the activities in the activity network of Figure 2.4 (see Figure 2.5).

We want to know the earliest day that each activity can start. Rather than worry about taking account of weekends and public holidays at this point, we simply allocate each working day a sequence number, starting with day 0. (Technically, day 0 means ‘the end of day 0’, which means the start of day 1, as explained below.)

The earliest start date for ‘do A’ is day 0 by definition, because it is the first activity in the network. The earliest time at which the activity can finish is day 0 plus the duration of the activity: that is, the end of day 4.

earliest finish date = (earliest start date + activity duration)

Figure 2.5 A network activity fragment with activity durations

The earliest start dates for the two activities ‘do B’ and ‘do C’ are governed by the earliest finish date of the preceding activity, ‘do A’. In fact, we can say that in this case the earliest start dates for ‘do B’ and ‘do C’ are the same as the earliest finish date for ‘do A’, that is, day 4.

You may wonder why it is not the following day. Well, the convention is that when we say ‘do A’ finishes on day 4, we mean at the end of day 4. When we say ‘do B’ and ‘do C’ start on day 4 we really mean at the end of day 4, which of course really means the start of day 5. It is best just to accept this as the convention. It saves problems arising where activities do not take whole numbers of days, for example 5.5 days.

We can now work out the earliest finish days of ‘do B’ and ‘do C’ as day 11 and day 9, respectively. What about the earliest start date for ‘do D’? We have two preceding earliest finish dates, so we take the one which is later: that is, day 11.

earliest start date = the latest of the earliest finish dates of the preceding activities upon which the current activity is dependent

We end up with the day numbers shown in Figure 2.6, where ES means the earliest start date and EF means the earliest finish date.

Figure 2.6 Earliest start (ES) and finish (EF) days

It is possible for some activities to start or finish late without the project as a whole being delayed. To see where this is the case, the latest finish and latest start dates for each activity are calculated. We will assume that we want the project as a whole to take the shortest time possible: that is, to finish on day 14. Day 14 becomes the latest finish date for the activity ‘do D’. The latest start day for this activity is calculated by subtracting the duration from the latest finish: that is, 14 − 3 = Day 11.

latest start date = latest finish date of current activity − duration

We now work backwards. The latest start day for the activity ‘do D’ becomes the latest finish day for ‘do B’ and ‘do C’. By subtracting the durations for these activities from their latest finish days we get their latest start days: that is, 11 − 7 = Day 4 for ‘do B’ and 11 − 5 = Day 6 for ‘do C’.

In the case of ‘do A’, we have to decide whether to base the latest finish on the latest start date of ‘do B’ or ‘do C’. The earlier of the two is taken as the latest finish time for ‘do A’: that is, day 4, which comes from ‘do B’.

latest finish date = the earliest of the latest start dates of the activities that are dependent on the current activity

We now have the situation shown in Figure 2.7, where LS means latest start and LF means latest finish.

Figure 2.7 Latest start (LS) and finish (LF) dates

It can be seen from Figure 2.7 that for all the activities except ‘do C’, the earliest and latest start days are the same, as are the earliest and latest finish days. This means that if these activities are late, the project as a whole will be delayed. In the case of ‘do C’, if you look at the day numbers you can see there is a difference of two days between the earliest and latest day numbers. This means that ‘do C’ could be one or two days late and the duration of the project as a whole would not be affected.

This leeway is called the float and can be defined as:

float = latest finish date − earliest start date − duration

A quick way of calculating this is by subtracting the earliest start from the latest start (or the earliest finish from the latest finish).

In Figure 2.7, ‘do A’, ‘do B’ and ‘do D’ all have zero float. They form a small chain of three activities from the beginning to the end of the activity network. This chain is the critical path (CP). If any activity on this path is delayed, then the whole project will be delayed.

The details for each activity can be displayed more clearly if the boxes on the activity diagram are divided up as shown in Figure 2.8.

Thus, for the activity ‘do C’, the activity box in the activity network could be drawn up as in Figure 2.9.

The activity span is the total period during which the activity could take place, and is defined as:

activity span = latest finish day − earliest start day

In this case it is 11 – 4: that is, 7 days. Where an activity has float, there is a ‘window of opportunity’, reflected by the activity span (see Figure 2.10), within which the activity can start and be completed.

Figure 2.8 Layout of an activity box

Figure 2.9 Activity box for ‘do C’

Figure 2.10 The activity span

The activity has to take place within the activity span. Because in Figure 2.10 there is some float, there is some freedom about when it can take place within that period. However, the start must be in the period between the earliest and the latest start. If it is not, it will not be completed within the activity span – unless its duration can be shortened in some way.

In Section 1.7.3 the iterative model was introduced where one or more activities could be repeated, with each loop creating a new version of the products of the process. Activity networks assume that all activities are executed just once. Clearly, some – such as usability tests – can be carried out more than once on revised versions of the software. We deal with this by concealing the iteration within an activity. Usability tests may be carried out a number of times on revised versions of the software, but all the iterations are together expected to take no longer than one week in the example.

2.5 RESOURCE ALLOCATION

So far we have taken no account of the availability of the resources needed to carry out any task. It is assumed that they will be available when they are needed. The resources that now need to be considered include raw materials, staffing and equipment. Usually with IT projects, the main concern is staffing, although sometimes equipment can also cause problems. For example, when conducting acceptance testing for a modified IT application, there is often a need for some testing of the whole operational system. This may need to be done on a public holiday or at the weekend, when no normal operational use is being made of the system. Here, we focus on staff resourcing.

For each activity, the resource types needed are identified. A resource type is a group of people of which any member could carry out a particular task. For example, if a software component needs to be written in Java, identifying Ali as the needed resource would be too precise; Jane may be equally proficient in Java. Identifying the resource simply as a software developer, on the other hand, may be too vague: Alfred is a software developer but, as a Cobol programmer, he has no knowledge of Java. Identifying the required resource as a Java programmer may be just about right.

In order to illustrate the process of resource levelling and smoothing, we break down one of the activities in our Water Holiday Company integration project, ‘G. Write software’, into more detailed tasks (see Figure 2.11).

Having allocated resource types to activities, we now go through the activity network and note the resources needed for each unit of calendar time (in this case each week) if the activity is to start at its earliest start date. In the top part of Table 2.1 we have, for example, identified the different resource types and allocated particular activities to them by putting the alphabetic characters we used in Figure 2.11 to identify each activity (for example, ‘GA’ for ‘design provisional booking function’) into the relevant week cells. Where the same type of resource is needed for different activities in the same week, we identify different instances, for example SDes 1, SDes 2 and so on and allocate them to the different parallel activities where they are needed. When we have finished this allocation, we can count the number of each type of staff needed in each week. We can also depict this information as a resource histogram (see Figure 2.12).

Figure 2.11 Water Holiday Company project: ‘G. Write software’ activity

Table 2.1 Numbers of each resource type needed in each week

Figure 2.12 A resource histogram for each resource type

In some cases, the project plan needs more staff of a certain type at a particular time than we have available. Also, where temporary staff need to be employed on expensive contracts, we try to avoid having short periods of intense activity alternating with periods when nothing much is happening and staff are underemployed. Delaying certain activities may allow these peaks and troughs to be ‘smoothed’, which will lead to more economical staff costs and more productive work distribution.

For example, in Figure 2.12, three system designers are needed in week 1 and only one in week 2. If we have only two system designers on the staff, then we could employ a third system designer, possibly on an expensive temporary contract, for the first week. However, if we calculate the float for each activity in the activity network (Figure 2.11), we can see that two of the activities needing system designers have two weeks’ float. If we delay starting one of these activities until week 2, this part of the project as a whole will not be delayed, but we will need only two system designers.

When there are not enough staff of a particular resource type to carry out the activities due to take place at a certain time, there is a resource clash. Even if there are no resource clashes, a planner should try to arrange activities so that the use of a resource type is as stable as possible.

Where there is a resource clash or the demand for a resource is very uneven, the following options may be considered:

We are now in a position to put our plan into a form that will be easily understood by all those who are going to be carrying it out. The most common format used is a Gantt chart (see Figure 2.13). The activities are listed down the left-hand side and the calendar units (in this case, weeks) are shown along the top. In the body of the diagram there are blocks for each activity, showing when the activity will be carried out. In the diagram, the free float related to each activity is indicated by the lighter blocks that extend the base period for an activity.

Figure 2.13 Gantt chart

Free float is the amount of time that an activity can be late without any other activity being late. For activity A (Allocate room), this is 3 weeks. If activity A is later than 3 weeks, the start of activity D (Install infrastructure) will be delayed and activity D’s free float will be reduced. However, activity A can be up to 7 weeks late and, as long as activity D does not take longer than planned, the project as a whole will not be delayed. The 7 weeks is known as activity A’s total float.

For a smaller project, an alternative layout is to list each member of staff down the left and show what they are doing in each time period in the body of the diagram. This is not dissimilar to the holiday planning charts on the walls of many offices showing when staff will be away. A disadvantage of this format is that activities involving more than one team member have to be duplicated.

If an activity has to be delayed until a member of staff becomes available upon the completion of some other activity, this should not be indicated by a dependency link between the two activities on the activity network. Rather, the start date of the waiting activity should simply be amended on the Gantt chart. If other staff were to be released earlier than foreseen, they could be used to expedite the waiting activity. If the waiting task had a dependency link to another task, it would imply a technical reason for waiting until the other was complete and would mask the opportunity to use other staff.

2.6 USING SOFTWARE TOOLS FOR PLANNING

In this chapter it has been assumed that all the planning, and calculation of the consequences of particular planning decisions, will be done by hand with no computer assistance. It will be a relief for most people to know that there are software packages that will carry out most of the calculations for you. Examples of these are Microsoft Project and Oracle Primavera.

There are numerous alternatives available – just search on the internet for ‘project management software’. With many of these, the creation of a Gantt chart is just one function among a range of facilities to support large multiuser projects. Some provide the opportunity for a free limited trial period and there are also open source planning tools available.

In most cases, for each activity you will input the activity name, the duration of the activity, the activities upon which it depends and the resources that it will use. Given this information, the software then produces activity networks, resource histograms, Gantt charts and other useful reports. Some packages suggest ways of resolving resource clashes, but users need to check that the results are what they really want. Where activity networks and Gantt charts are produced, the planner often has to tweak them to make them easy for others to understand. For example, a Gantt chart often spreads over several pages, many of which are blank. The advantage of using a software tool is that it is easy to make changes to the plan and see what the consequences of the changes will be.

SAMPLE QUESTIONS

Questions 1, 2 and 3 are about the diagram below. The number of days in each box show the duration of the activity.

1. Which of the following is the critical path?

2. What is the float for activity F?

3. Activities B and C have to be completed by the same person. What is the delay to the finish time of the project?

4. Which of the following does not take account of the dependencies between activities?

POINTERS FOR ACTIVITIES

Activity 2.1

Among the products that may be created for each activity are:

Activity 2.2

Activity 2.3

Activity 2.4

One way of allocating resources would be:

 

Activity	Resource type
allocate room	premises manager
analyse business processes	business analyst, users
carry out acceptance tests	users, business analyst
carry out usability tests	interface designer, users
devise usability tests	interface designer
design interface	interface designer, users
draft acceptance test cases	business analyst, users
install infrastructure	IT infrastructure support
recruit staff	human resources manager
write software	software developers

Activity 2.5

Activity 2.6

Activity 2.7

GANTT does not stand for anything. Gantt charts are named after their inventor, Henry Gantt. Gantt should, therefore, not be written in capitals!