There are many project planning approaches in project management practices.
When you have completed this chapter you should be able to demonstrate an understanding of the following:
- project deliverables and intermediate products;
- work and product breakdowns;
- product definitions (including the identification of ‘derived from’ and ‘component of’ relationships between products);
- relationship between products and activities in a project;
- checkpoints and milestones;
- elapsed time and effort required for activities;
- activity networks (using the ‘activity on node’ notation);
- calculation of earliest and latest start and end dates of activities and the resulting float;
- identification and significance of critical paths;
- resource allocation, smoothing and levelling, including the use of resource histograms;
- work schedules and Gantt charts.
Introduction to Project planning in project management
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. See Development Life Cycle in Project management.
APPROACHES TO PLANNING
There are two approaches to identifying the components of a project: product-based and work- or activity-based.
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:
Common software functionality, which enables members of the public to book online boating holidays provided by the previously separate Canal Dreams and Minotours companies via the merged website;
Enhanced network systems that can cope with the expected additional traffic to the Water Holiday Company website;
A new merged network support and customer service centre to support 24-hour/seven days a week activity rather than the two separate sites for the two former trading entities.
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):
- consolidated business process models;
- interface design documents which take account of the new corporate identity, such as a corporate website style guide, site maps, ‘wireframe’ designs;
- an enhanced IT infrastructure architecture plan;
- software specifications;
- acceptance test plan;
- progress reports.
Progress reports relate to management or quality control of the project
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).
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:
- The identity of the product – for example ‘acceptance test plan’.
- A description of the product – for example ‘a plan of the test cases and the results that users expect the application to produce’.
- The product or products that have to exist before this one can be created; that is, those it is derived from – for example, the acceptance test plan is stated to be derived from the requirements specification, which describes the main transactions of the application.
- The components that make up the product – in the case of an acceptance test plan, the main sections in the document.
- The format of the product – for example, that it is a word-processed document or a spreadsheet or a piece of software.
- The quality criteria that explain how the product will be judged as satisfactory – for example, the acceptance test plan being reviewed against the requirements specification. These are also known as acceptance criteria.
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:
- analysing, merging and redesigning business processes;
- designing web interfaces;
- redesigning unified network architecture;
- specifying software;
- acceptance testing;
- reporting progress.
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. This is a traditional waterfall project management model.
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.
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).
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. In Agile practices all activities and plannings may be approached differently. See Agile project management and project plans.
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.
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.
In this activity network, match the activities with the boxes so that the activity network is compatible with the product flow diagram in Figure 2.2. 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.