Activity Planning 129

FIGURE 6.1 Ac vity planning is carried out in Steps 4 and 5

6.5 Projects and Activities

Defining activities
Before we try to identify the activities that make up a project it is worth reviewing Activities must be
defined so that they
what we mean by a project and its activities and adding some assumptions that will be meet these criteria.
relevant when we start to produce an activity plan. Any activity that does
not meet these criteria
● A project is composed of a number of interrelated activities.
must be redefined.
● A project may start when at least one of its activities is ready to start.

● A project will be completed when all of the activities it encompasses have been completed.
130 So ware Project Management

● An activity must have a clearly defined start and a clearly defined end-point, normally marked by the
production of a tangible deliverable.
● If an activity requires a resource (as most do) then that resource requirement must be forecastable and
is assumed to be required at a constant level throughout the duration of the activity.
● The duration of an activity must be forecastable – assuming normal circumstances, and the reasonable
availability of resources.
● Some activities might require that others are completed before they can begin (these are known as
precedence requirements).

Identifying activities
Essentially there are three approaches to identifying the activities or tasks that make up a project – we shall
call them the activity-based approach, the product-based approach and the hybrid approach.

The activity-based approach

The activity-based approach consists of creating a list of all the activities that the project is thought to involve.
This might require a brainstorming session involving the whole project team or it might stem from an analysis
of similar past projects. When listing activities, particularly for a large project, it might be helpful to subdivide
the project into the main life-cycle stages and consider each of these separately.
Rather than doing this in an ad hoc manner, with the obvious risks of omitting or
WBSs are advocated
by BS 6079, the British double-counting tasks, a much favoured way of generating a task list is to create a
Standards Institution’s Work Breakdown Structure (WBS). This involves identifying the main (or high-level)
Guide to Project tasks required to complete a project and then breaking each of these down into a set
Management.
of lower-level tasks. Figure 6.2 shows a fragment of a WBS where the design task has
been broken down into three tasks and one of these has been further decomposed into
two tasks.

FIGURE 6.2 A fragment of an ac vity-based Work Breakdown Structure

Activities are added to a branch in the structure if they contribute directly to the task immediately above – if
they do not contribute to the parent task, then they should not be added to that branch. The tasks at each level
in any branch should include everything that is required to complete the task at the higher level.
 Activity Planning 131

When preparing a WBS, consideration must be given to the final level of detail or depth of the structure.
Too great a depth will result in a large number of small tasks that will be difficult to manage, whereas a too
shallow structure will provide insufficient detail for project control. Each branch should, however, be broken
down at least to a level where each leaf may be assigned to an individual or responsible section within the
organization.
Advantages claimed for the WBS approach include the belief that it is much more A complete task
likely to result in a task catalogue that is complete and is composed of non-over- catalogue will normally
include task definitions
lapping activities. Note that it is only the leaves of the structure that comprise the along with task input
list of activities in the project – higher-level nodes merely represent collections of and output products
activities. and other task-related
information.
The WBS also represents a structure that may be refined as the project proceeds. In
the early part of a project we might use a relatively high-level or shallow WBS, which can be developed as
information becomes available, typically during the project’s analysis and specification phases.
Once the project’s activities have been identified (whether or not by using a WBS), they need to be sequenced
in the sense of deciding which activities need to be completed before others can start.

The product-based approach

The product-based approach, used in PRINCE2 and Step Wise, has already been described in Chapter 3. It
consists of producing a Product Breakdown Structure and a Product Flow Diagram. The PFD indicates, for
each product, which other products are required as inputs. The PFD can therefore be easily transformed into
an ordered list of activities by identifying the transformations that turn some products into others. Proponents
of this approach claim that it is less likely that a product will be left out of a PBS than that an activity might
be omitted from an unstructured activity list.
This approach is particularly appropriate if using a methodology such as SSADM or USDP (Unified Software
Development Process), which clearly specifies, for each step or task, each of the products required and the
activities required to produce it. For example, the SSADM Reference Manual provides a set of generic PBSs
for each stage in SSADM, which can be used as a basis for generating a project specific PBS.
In the USDP, products are referred to as artifacts – see Figure 6.3 – and the sequence
of activities needed to create them is called a workflow– see Figure 6.4 for an example. See I. Jacobson,
G. Booch and J.
Some caution is needed in drawing up an activity network from these workflows. Rumbaugh (1999)
USDP emphasizes that processes are iterative. This means that it may not be possible The Unified Software
to map a USDP process directly onto a single activity in a network. In Section 4.18 Development Process,
Addison-Wesley.
we saw how one or more iterated processes could be hidden in the single execution of
a larger activity. All projects, whether they contain iterations or not, will need to have
some fixed milestones or time-boxes if progress towards a planned delivery date is to be maintained. These
larger activities with the fixed completion dates would be the basis of the activity network.

The hybrid approach

BS 6079 states that
The WBS illustrated in Figure 6.2 is based entirely on a structuring of activities. WBSs may be product-
Alternatively, and perhaps more commonly, a WBS may be based upon the project’s based, cost-centre-
based, task-based or
products as illustrated in Figure 6.5, which is in turn based on a simple list of final function-based but that
deliverables and, for each deliverable, a set of activities required to produce that product-based WBSs
product. Figure 6.5 illustrates a flat WBS and it is likely that, in a project of any size, are preferred.
132 So ware Project Management

FIGURE 6.3 USDP product breakdown structure based on artefacts iden fied in Jacobson, Booch and
Rumbaugh (1999)
it would be beneficial to introduce additional levels – structuring both products and activities. The degree to
which the structuring is product-based or activity-based might be influenced by the nature of the project and
the particular development method adopted. As with a purely activity-based WBS,
Not all of the prod-
ucts in this activity having identified the activities we are then left with the task of sequencing them.
structuring will be final
products. Some will be A framework dictating the number of levels and the nature of each level in the
further refined in sub- structure may be imposed on a WBS. For example, in their MITP methodology, IBM
sequent steps. recommend that the following five levels should be used in a WBS:
● Level 1: Project.
● Level 2: Deliverables such as software, manuals and training courses.
● Level 3: Components, which are the key work items needed to produce deliverables, such as the modules
and tests required to produce the system software.
 Activity Planning 133

FIGURE 6.4 A structuring of ac vi es for the USDP requirements capture workflow based on Jacobson,
Booch and Rumbaugh (1999)

FIGURE 6.5 A hybrid Work Breakdown Structure based on deliverables and ac vi es

134 So ware Project Management

● Level 4: Work-packages, which are major work items, or collections of related tasks, required to produce
a component.
● Level 5: Tasks, which are tasks that will normally be the responsibility of a single person.

6.6 Sequencing and Scheduling Activities

Throughout a project, we will require a schedule that clearly indicates when each of the project’s activities
is planned to occur and what resources it will need. We shall be considering scheduling in more detail in
Chapter 8, but let us consider in outline how we might present a schedule for a small project. One way of
presenting such a plan is to use a bar chart as shown in Figure 6.6.

FIGURE 6.6 A project plan as a bar chart

The bar chart does
not show why certain The chart shown has been drawn up taking account of the nature of the development
decisions have been process (that is, certain tasks must be completed before others may start) and the
made. It is not clear,
for example, why activ-
resources that are available (for example, activity C follows activity B because Andy
ity H is not scheduled cannot work on both tasks at the same time). In drawing up the chart, we have therefore
to start until week 9. done two things – we have sequenced the tasks (that is, identified the dependencies
It could be that it can-
not start until activity among activities dictated by the development process) and scheduled them (that is,
F has been completed specified when they should take place). The scheduling has had to take account of the
or it might be because
Charlie is going to
availability of staff and the ways in which the activities have been allocated to them.
be on holiday during The schedule might look quite different were there a different number of staff or were
week 8. we to allocate the activities differently.
Separating the logical In the case of small projects, this combined sequencing–scheduling approach might
sequencing from the be quite suitable, particularly where we wish to allocate individuals to particular tasks
scheduling may be
likened to the principle at an early planning stage. However, on larger projects it is better to separate out these
in systems analysis of two activities: to sequence the tasks according to their logical relationships and then
separating the logical to schedule them taking into account resources and other factors.
system from its physi-
cal implementation.