Projects and activities

Defining activities

Before we try to identify the activities that make up a project it is worth reviewing what we mean by a project and its activities and adding some assumptions that will be relevant when we start to produce an activ ity plan.

• a project is composed of a number of inter-related activities;

• 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;

• 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 activ ity 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 ac tivities

Essentially there arc 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 activ ity-based approach The activity-based approach consists of creating a list of all the activities that the project is thought to involve. This might involve a brainstorming session involving the w hole 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 style stages and consider each of these separately.

Rather than doing this in an ad hoc manner, w ith the obvious risks of omitting or double-counting tasks, a much favoured way of generating a task list is to create a Work Breakdown Structure (WBS). This involves identifying the main (or high-level) tasks required to complete a project and then breaking each of these down into a set 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.

Activities arc added to a branch in the structure if they directly contribute 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

Activities must be defined so that they meet these criteria. Any activity that does not meet these criteria must be redefined.

WBSs are advocated by BS 6079. which is discussed in Appendix B.

Project

1

1

Analyse

Design

Build

1

1

Data design

Process design

Ptiycal design

Relational

Logical

data analysis

data design

Figure 6.2 A fragment of an activity-based Work Breakdown Structure.

A complete task catalogue will normally include task definitions along with task input and output products and other task-related information.

include everything that is required to complete the task at the higher level - if they are not a comprehensive definition of the parent task, then something is missing.

When preparing a WBS. consideration must be given to the final level of detail or depth of the structure. Too great a depth w ill result in a large number of small tasks that w ill be difficult to manage, w hereas a loo shallow structure w ill 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 likely to result in a task catalogue that is complete and is composed of non-overlapping activities. Note that it is only the leaves of the structure that comprise the list of activ ities comprising the project - higher-level nodes merely represent collections of activities.

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 w hich activities need to be completed before others can start.

The product-based approach The product-based approach, used in PRINCE 2 and Step Wise, has already been described in Chapter 2. It consists of producing a Product Breakdow n 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. which clearly specifies, for each step or task, each of the products required and the activities required to produce it. The SSADM Reference Manual provides a set of generic PBSs for each stage in SSADM (such as that shown in Figure 6.3), which can be used as a basis for generating a project-specific PBS.

SpaoftCMOn

Oata

ScwActSOK

Oouoad Oo~i»r OMCCOont

lit* Row FwnctO" Warn

F v*e»0" OaAntton»

COTTMPOodtnc* Oagram*

I I

1 1

Svuctj'w

fmwy AccMsPans

E»man«fy P>oc*M

looea Oata

V'UCSj*«

OMcrpbom

W^BtO^lNp OMcrçfto«*

Figure 6.3 SSADM Product Breakdown Structure for Requirements Specification (adapted fnm Good land and Slater).

Most good texts on SSADM will expiain the tailoring of the generic PBSs and Activity Networks. The illustrations here are taken from M. Goodland and C. Slater, SSADM Version 4: A Practical Approach. McGraw-Hill. 1995.

T he SSADM Reference Manual also supplies generic activity networks and. using the project-specific PBS and derived PIT), these may be used as a basis for developing a project-specific activity network. Figure 6.4 illustrates an activity network for the activities required to create the products in Figure 6.3.

Notice how the development of a PFD leads directly to an activity network that indicates the sequencing of activities - in Figure6.4, activity 340 (Enhance required data model) requires products from activity 330 and activ ity 360 needs products from both activities 330 and 340.

T he hybrid approach The WBS illustrated in Figure 6.2 is based entirely on a structuring of activities. Alternatively, and perhaps more commonly, a WBS may be based upon the project's products as illustrated in Figure 6.5, which is in turn based on a simple list of final deliverables and. for each deliverable, a set of activities required to produce that product. Figure 6.5 illustrates a flat WBS and it is likely that, in a project of any si/e. 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, hav ing identified the activities we are then left with the task of sequencing them.

The activity numbers in Figure 6.4 are the step numbers used by SSADM version 4.

BS 6079 states that WBSs may be product-based, cost-centre-based, task-based or function-based but states that product-based WBSs are preferred.

Not ail ot the products in this activity structuring will be final products. Some will be further refined in subsequent steps.

The current version of the SSADM reference manual provides generic PBSs and generic activity networks, but not generic PFDs. Stress is ptaced on the fact that these are gener/c structures and it is important that project-specific versions are created. A project-specific PFD would be produced as part of this process.

Figure 6.4 A structuring of activities for the SSADM Requirements Specification stage (from Goodland and Slater).

A framework dictating the number of levels and the nature of each level in the structure may be imposed on a WBS. l or example, in their MITP methodology, IBM recommend that the following five levels should be used in a WBS:

• I-evel 2: Deliverables such as software, manuals and training courses.

Donvo System Functions

Enhanco Roqu*od Data Model

Assemble

Requirements

Specification

Rat»*«] SfW^n OFM

Develop Required Data Model

Dehne Required System Processing

Ra<»*'«0 Syttam Of M ^^ lo»cai Data Sscatitfy Xsl L OMiCMMOgu*

Confirm System

Objectives

Funcaon W^tCH

OuCuogu« lopen Data Fio» Mod* 109c« Data SKv»EnKy *tt> uwcwool* «•»•'»^•n»» Catato?* Satoctad Buvnau Syst*™ Opeo«

Fun** 0«Afw!cn» CtiA&jj» UM> Ro«»*uncton Mam.

tOSt'UCtu'M

Project

Installed system

Software components

User manuals

Tramng course

-

Analyse requirements

Review requirements

-

Analyse requirements

-

Analyse requirements

Outline design

Outline design

Design manual

Design course

Detailed design

Detailed design

Write text

Write material

Iniegrale system

Code software

Capture screens

Pr«t handouts

Test system

Test software

Do page layout

Deliver course

system

Print manuals

Use* testing

Figure 6.5 A Work Breakdown Structure based on deliverables.

• 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.

• 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 (hat will normally be the responsibility of a single person.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment