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 activity 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 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).
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 involve 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 style stages and consider each of these separately.
Rather than doing this in an ad hoc manner, with 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 are 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.
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 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 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 activities 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 which 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 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, 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.
Attribute/ Data Item Descriptions
Grouped Domain Descriptions
Enquiry Access Paths
User Role/ Function Matrix
Required System Logical Data Model
Entity Ufe Histories
Effect Correspondence Diagrams
Logical Data Structure
Figure 6.3 SSADM Product Breakdown Structure for Requirements
Specification (adapted from Goodland and Slater).
Most good texts on SSADM will explain 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.
The SSADM Reference Manual also supplies generic activity networks and, using the project-specific PBS and derived PFD, 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 Figure 6.4, activity 340 (Enhance required data model) requires products from activity 330 and activity 360 needs products from both activities 330 and 340.
The 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 size, 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, having 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 all of 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 placed on the fact that these are generic structures and it is important that project-specific versions are created. A project-specific PFD would be produced as part of this process.
Data Catalogue Logical Data Flow Model Logical Data Store/Entity Xref User Catalogue Requirements Catalogue Selected Business System Option
Current Environment LDM Requirements Catalogue Selected Business System Catalogue
Define Required System Processing
Required System DFM
Required System DFM
Develop Required Data Model
Required System LDM Data Catalogue
EffiSXT teoeumeentS Guide ' Catal°9ue
User Role/Function Matrix I/O Structures
Derive System Functions
Enhance Required Data Model
Command Structures Prototyping Report
Function Definitions Requirements Catalogue User Role/Function Matrix I/O Structures
Requirements Catalogue Required System LDM Function Definitions
Confirm System Objectives
Function Definitions Required System LDM Requirements Catalogue
I/O Structures Function Definitions Requirements Catalogue
Data Catalogue Required System LDM
Develop Processing Specification
Effect Correspondence Diagram Enquiry Access Paths Entity Life Histories
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. For example, in their MITP methodology, IBM recommend that the following five levels should be used in a WBS:
• Level 2: Deliverables such as software, manuals and training courses.
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 that will normally be the responsibility of a single person.
Was this article helpful?
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.