Availability: In Stock

Price: $139.94
Ex Tax: $127.22

Available Options

* Options:
- +

More and more engineering and technical professionals are making career transitions from product design into project management. This, however, requires formal training and a willingness to learn new skills. All the technical know-how in the world will not deliver a project successfully, without proper project management skills. Unfortunately very few engineering professionals have any degree of formal project management training, which results in a great deal of personal stress as well as cost blowouts and other woes.

To address this problem, this manual focuses on the critical project related activities such as work breakdown, scheduling, cost control and risk management, and shows how these can be performed with software to lighten the project manager's workload. The 'soft' (but equally important) aspects such as team leadership and contract law are also covered in detail.

Download Chapter List

Table of Contents


  1. Fundamentals

Learning objectives

The objective of this chapter is to:

  • Provide an introduction to the concept of project management. This includes fundamental definitions, basic project management functions, project life cycles and phases
  • Review the types and influences of alternative organization structures, with respect to both the organizations within which projects are undertaken, and the organization of the project team
  • Review the issues fundamental to successful project outcomes
  • Review the essential elements of effective project planning and control

This overview will show how the specific planning and control techniques introduced during the course are incorporated into the project management function.

These concepts are applicable to the management of projects of any type.  While specific industries and certain types of projects will often require specialist knowledge to effectively plan and control the project, the principles outlined in this course will generally apply in all cases.

The definitions and techniques presented here are generally accepted within the project management discipline. That is; their application is widespread, and there is consensus about their value.

1.1          Definitions

1.1.1          Project

Performance of work by organisations may be said to involve either operations or projects, although there may be some overlap.

Operations and projects share a number of characteristics in that they are:

  • Planned, executed, and controlled
  • Constrained by resource limitations
  • Performed by people

Projects are, however, different from operations (such as maintenance or repair work) in that they are temporary endeavours undertaken to create a. unique product or service. Table 1.1 shows the differences and similarities between operational and project activities.

Table 1.1

Operational vs. project activities













Resources consumed


















The primary objectives of a project are commonly defined by reference to function, time, and cost. In every case there is risk attached to the achievement of the specified project objectives.

1.1.2          Program

A program is a grouping of individual, but inter-dependent, projects that are managed in an integrated manner to achieve benefits that would not arise if each project were managed on its own.

1.1.3          Project management

Project management is the application of specific knowledge, skills, tools, and techniques to plan, organise, initiate, and control the implementation of the project, in order to achieve the desired outcome(s) safely.

Note that ‘Project Management’ is also used as a term to describe an organisational approach known as ‘Management by Projects’, in which elements of ongoing operations are treated as projects, and project management techniques are applied to these elements.

1.2          Project management

1.2.1          Elements

Successful project management requires that planning and control for each project is properly integrated.

Planning for the project will include the setting of functional objectives, cost budgets and schedules, and define all other delivery strategies. Successful planning requires the proper identification of the desired outputs and outcomes.

Control means putting in place effective and timely monitoring, which allows deviations from the plan to be identified at an early stage. As a result they can be accommodated without prejudicing project objectives, and corrective action can be initiated as required.

A project organisation appropriate to the task must be set up, and the duties and responsibilities of the individuals and groups within the organisation must be clearly defined and documented.  The lack of clear definition of structure and responsibilities leads to problems with authority, communication, co-ordination and management.

The project management procedures put in place for the project must ensure that monitoring is focused on the key factors that the results obtained by monitoring are timely as well as accurate, and that effective control systems are established and properly applied by the project team. Project management involves five basic processes:

  • Initiating: Undertaking the necessary actions to commence the project or project phase
  • Planning: Identifying objectives and devising effective means to achieve them
  • Executing: Co-ordinating the required resources to implement the plan
  • Controlling: Monitoring of the project and taking corrective action where necessary
  • Closing: Formalising the acceptance of the project or phase deliverables (the ‘handover’), and terminating the project in a controlled manner

Within each of these processes there are a number of sub-process involved, all linked via their inputs and outputs.  Each sub-process involves the application of skills and techniques to convert inputs to outputs.  An example of this is the preparation of a project network diagram (output) by the application of the precedence method (technique) to the identified project activities (input).  

1.2.2          The professional body of knowledge

Project management has developed as a professional discipline since the 1950s. It is claimed, reasonably, that the military was the first institution that adopted planning and control processes that could be characterized as formal project management – specifically for the Normandy invasion, and subsequently for the Manhattan Project. Since the 1970s there has been a sustained development of project management as a professional discipline.

There are professional project management bodies in most countries. In Australia the professional organisation is the Australian Institute for Project Management. In New Zealand it is the New Zealand Chapter of the Project Management Institute (PMI). The international body is the International Project Management Association.

In defining the knowledge base for project management it is useful to refer to the structures adopted by the PMI in the USA and the Association for Project Management (APM) in the UK. Their web addresses are and respectively.

Table 1.2

Project management body of knowledge


·        Project Plan development

·        Project Plan Execution

·        Overall Change Control



·        Initiation

·        Scope Planning

·        Scope Definition

·        Scope Verification

·        Scope Change Control



·        Activity Definition

·        Activity Sequencing

·        Activity Duration Estimating

·        Schedule Development

·        Schedule Control



·        Resource Planning

·        Cost Estimating

·        Cost Budgeting

·        Cost Control



·        Quality Planning

·        Quality Assurance

·        Quality Control



·        Organisational Planning

·        Staff Acquisition

·        Team Development



·        Communications Planning

·        Information Distribution

·        Performance Reporting

·        Administration Closure



·        Risk Identification

·        Risk Quantification

·        Risk Response Development

·        Risk Response Control



·        Procurement Planning

·        Solicitation Planning

·        Solicitation

·        Source Selection

·        Contract Administration

·        Contract Close-out


IIA            PMI PMBOK


·        Systems Management

·        Programme Management

·        Project Management

·        Project Lifecycle

·        Project Environment

·        Project Strategy

·        Project Appraisal

·        Project Success/Fail Criteria

·        Integration

·        Systems % Procedures

·        Close-Out

·        Post Project Appraisal



·        Organisation Design

·        Control and Co-operation

·        Communication

·        Leadership

·        Delegation

·        Team Building

·        Conflict Management

·        Negotiation

·        Management Development



·        Work Definitions

·        Planning

·        Scheduling

·        Estimating

·        Cost Control

·        Performance Measurement

·        Risk Management

·        Value Management

·        Change Control

·        Mobilisation



·        Operational/Technical Management

·        Marketing and Sales

·        Finance

·        Information Technology

·        Law

·        Procurement

·        Quality

·        Safety

·        Industrial









IIB            APM PMBOK


1.3          Project life cycle

1.3.1          Lifecycle elements

Projects proceed through a sequence of phases from concept to completion. Collectively, the separate phases comprise the project ‘life cycle’.

There are only a limited number of generic lifecycles, though the breakdown of the phases within can be at differing levels of detail. The generic types are usually considered to include capital works, pharmaceutical, petrochemical, defence procurement, research and development, and software development. Consequently the initial starting point for managing the project is to define the type, and select an appropriate life cycle model as the planning framework.


                   Figures 1.1 and 1.2 illustrate generic project life cycles for two project types.


Figure 1.1
Project life cycle: capital works project


Figure 1.2
Project life cycle: defence acquisition project

1.3.2          Project phases

Different industries generally have specific standard definitions for each phase, but a generic description of each phase identified in Figure 1.1 for a capital works project is:

  • Pre-feasibility: Identification of needs, and preliminary validation of concept options
  • Feasibility: Detailed investigation of feasibility, including preliminary brief, project estimate and investment analysis
  • Planning: Detailed definition of the project with respect to scope, organisation, budget, and schedule, together with definition of all control procedures
  • Implementation: The execution of the scoped project.  The components of this phase will depend upon the nature of the project
  • Handover: Passing the facility into the control of the principal. This includes formal handover of the facilities, user training, operating and maintenance documentation etc.
  • Close out: Archiving of the project records, establishing appropriate performance evaluations, capturing and transferring lessons learned, and dissolving the project organisation

Project phases share defined characteristics.

  • In every instance project management processes undertaken with a specific phase comprise initiating, planning, executing, controlling, and closing. 
  • A project phase will have one or more tangible deliverables.  Typical deliverables include work products such as feasibility studies, software functional specifications, product designs, completed structures, etc.
  • Outputs from a phase are typically the inputs to the succeeding phase

Normally, deliverables from any phase require formal approval before the succeeding phase commences. This can be imposed through the scheduling of compulsory ‘milestones’ (e.g. design reviews) between phases.

1.4          Project organizations

1.4.1          General

Where projects are set up within existing organisations, the structure and culture of the parent organisation has great influence on the project, and will be a deciding factor in whether or not there is a successful outcome. Where the project team is outside the sponsoring or client organisation, that organisation may exert significant influence on the project.

The organisation of the project team also directly influences the probability of achieving a successful outcome. The benefits and disadvantages of the various options for project team organization need to be appreciated. 

1.4.2          Projects within existing organizations

Organisational structures have traditionally been defined within the spectrum from fully functional to fully project oriented.  Between those extremes lie a range of matrix structures.

The classic functional structure is a hierarchy, with staff grouped within specialist functions (e.g. mechanical engineering, accounting etc.), with each staff member reporting directly to one superior.  Such organisations do manage projects that extend beyond the boundaries of a division, but within a division the scope of the project is considered only as it exists within the boundary of that division.  Project issues and conflicts are resolved by the functional heads.

In a project management organization the staff are grouped by project, and each group headed by a project manager who operates with a high level of authority and independence.  Where departments co-exist with the project groups, these generally provide support services to the project groups.

Matrix organisations may lie anywhere between the above. A matrix approach applies a project overlay to a functional structure. Characteristics of matrix organisations may be summarised as follows:

  • Weak matrix organizations are those closely aligned to a functional organization, but with projects set up across the functional boundaries under the auspices of a project co-ordinator.  The project co-ordinator does not have the authority that would be vested in a project manager  
  • A strong matrix organization would typically have a formal project group as one of the divisions.  Project managers from within this group (often with the necessary support staff) manage projects where specialist input is provided from the various functional groups.  The project managers have considerable authority, and the functional managers are more concerned with the technical standards achieved within their division than with the overall project execution
  • In a balanced matrix the project management is exercised by personnel within functional divisions who have been given the appropriate authority necessary to manage specific projects effectively

The different organizational structures, and the corresponding project organization options, are identified in Figure 1.3. In many cases an organization may involve a mix of these structures at different levels within the hierarchy. For example, a functional organization will commonly set up a specific project team with a properly authorized project manager to handle a critical project.

The influence of the organisation structure on various project parameters is illustrated in Figure 1.3.

While a matrix approach may be seen as providing an inadequate compromise, in reality it is often the only realistic option to improve the performance of a functional organization. It does work, but there are some trade-offs. One factor critical to the effectiveness of the matrix structure is the authority vested in the person responsible for delivery of the project. A key predictor of project performance is the title of this person i.e. whether he/she is identified as a ‘project manager’, or something else.

Briefly, the benefits and disadvantages of the matrix approach include (see Table 1.3), also see Table 1.4:

Table 1.3

Matrix benefits and disadvantages                            



All projects can access a strong technical base

Dual reporting structures causes conflict

Good focus on project objectives

Competition between projects for resources

Sharing of key people is efficient

There may be duplication of effort

Rapid responses to changes

Management and project goals in conflict

Individuals have a protected career path








Figure 1.3

Project structures within organizations

Table 1.4
Influences of organization

Organization type









Project mgr


Little or none


Low to


Moderate to


High to


% Personnel

assigned 100%

on project






Project mgr


Part time

Part time

Full time

Full time

Full time

Project mgr












Project mgr

Support staff

Part time

Part time

Part time

Part time

Full time


1.4.3          Project organization

The organisation of the project team is characterised by:

  • The principal or project sponsor. This is the beneficial owner of the project
  • The Project Control Group (PCG). In some cases this will be the principal, but when the principal is a large company it is required to identify and make accountable certain nominated individuals. The function of this group is to exercise approvals required by the project manager from time to time, controlling the funding to the project manager, and maintaining an overview of the project through the reporting process
  • The project manager. In a ‘perfect world’ the responsibilities, roles and authority of this person would be defined and documented
  • A project control officer or group, if this function is not undertaken by the project manager. This group of people is responsible for the acquisition and analysis of data relating to time, cost and quality, and to compare actual figures with the planned figures
  • The rest of the project team, which will vary in composition according to the project type, as well as specific project variables

The project organization may be vertical or horizontal in nature, depending on the span of control chosen by the project manager. That choice will be a balance between available time and the desired level of involvement. Typical project structures for a capital works project are illustrated in Figure 1.4. These illustrate the difference between horizontal, intermediate, and vertical organisation structures.   

In general the horizontal structure is the best option, because the communication channels between those who execute the project work and the project manager are not subject to distortion. For instance, in the vertical organisation there is a far higher probability of the project manager receiving and acting upon inaccurate information. Such inaccuracies may arise unavoidably, by oversight, carelessly, or deliberately. The impacts can be severe. Reducing that opportunity, by shortening communication channels and removing the intermediate filters, improves the likelihood of achieving the desired project outcome.

On large projects the desire to maintain a horizontal structure can be largely achieved by increasing the size of the ‘project manager’. This is typically done by augmenting the project manager with support staff that have direct management responsibilities for a portion of the project. Their interests are aligned with those of the project managers, and a higher reliability of information may be expected.





Figure 1.4

Project team organization

1.5          Project success

1.5.1          General

Many projects qualify as successes, but we all have experience, anecdotal or otherwise, of projects that have gone severely wrong. Project failures exist within all industries. Even today, with the level of awareness for project management processes as well as advanced tools, there are spectacular failures. These occur even on very large projects where it is assumed that the investment in management is high. The consequences of failure can be significant to the sponsoring organisations as well as project personnel.

A 1992 study of some 90 data processing projects, completed in the previous 12 years, provides a common profile of experience. The study identified the primary factors affecting the project outcomes as set out in the Table 1.5. These are listed by frequency and severity (ranked in descending order of impact) in respect of their negative impact on project success. This analysis provides an instructive basis for any organisation operating, or setting up, a project management methodology. Note that most of these issues are project management issues.

Table 1.5

Project problem issues

(O’Connor & Reinsborough, Int’l Journal of Project Management Vol 10 May 1992)










Scope management



Quality management












User involvement



Implementation issues
































1.5.2          Project success criteria

It is a vital step, yet one commonly omitted, to define the project success criteria before commencing planning and delivery. In other words, define what needs to be achieved if the project implementation is to be considered a success. The project stakeholders must identify and rank the project success criteria. The ‘client’s’ preferences are obviously paramount in this process, and will consider performance right through the life of the product under development as well as the factors present only during the project.

The objectives of cost, quality, and time are frequently identified as the definitive parameters of successful projects. These are a very useful measure in many capital works projects where they can be defined in advance, adopted as performance indicators during project implementation, provide a basis for evaluating trade-off decisions, and applied with relative simplicity.

However, this approach to measuring project success is necessarily only a partial assessment in almost every situation. Projects completed within the targets for such constraints may be successfully completed from the perspective of the project implementation team, but are not necessarily from alternative viewpoints such as those of the sponsors or users. In some instances projects that are not completed within some of the time/cost objectives may still be considered a success. Common project success criteria include safety, loss of service, reputation, and relationships.

The process of defining ranked success criteria provides surprising insights in many instances, and enhances project planning. During project implementation the project success criteria provide a meaningful basis for establishing project performance indicators to be incorporated within project progress reports. They are also helpful in making trade-offs, should that become necessary.

1.5.3          Critical success factors

The results of a study of the critical success factors in projects, published in the June 1996 issue of the International Journal of Project Management, proposes a framework for determining critical success factors in projects. This study classified critical success factors applicable to all project types within four interrelated groups. These are set out in Table 1.6 with examples.

Table 1.6

Critical success factors

Factors related to:


The specific project

Project size, complexity, technology, number of interfaces

The project manager and team

Project management expertise, authority, systems, personality, resources

The customer organization

Customer commitment, response times, knowledge

The external environment

Environment: social, cultural, political, economic, financial, technica

In practice, this is a particularly important and useful framework within which critical success factors can be identified. Where necessary, these can be managed proactively in order to maximise the probability of project success.

A survey was conducted amongst members of the PM, seeking to correlate project success criteria (specified as time, cost, quality, client satisfaction, and other) against the above factors. Projects included in the survey covered construction, information services, utilities, environmental and manufacturing. The study concluded that the critical project success factors primarily arose from the factors related to the project management and project team. For each industry the project manager’s performance and the technical skills of the project team were found to be critical to project outcomes. This confirms the conclusions from the 1992 study noted earlier.

It is important to identify, within this framework, the specific critical success factors which may impact on the project. It is then the reponsibility of the project team to develop strategies to address these factors, either in the planning or in the implementation phase.

1.5.4          Critical project management issues

The skills, knowledge, and personal attributes of the selected project manager have a critical impact on the success of the project. These critical skills encompass more than just technical and project management parameters. A key element in the success of the project manager is the effective application of non-technical skills (the so-called ‘soft’ skills); including leadership, team building, motivation, communication, conflict management, personnel development and negotiation.

It is essential that the project manager, once appointed, has full control of the project within the limitations defined by the principal or project sponsor.  All parties must be made aware of this single point of authority. The authority delegated to the project manager, and his/her effectiveness in exercising it, is critical. Project management structures, particularly if the project is one within an existing organisation and across functional boundaries, creates a complex web of formal and informal interactions. Lack of clarity in defining the authority of the project manager invariably leads to difficulties.

The appointment of the project manager should ideally be made sufficiently early in the project to include management of the feasibility studies.  The project manager should be appointed in order to undertake the project definition.  If the project manager is not involved in the project definition phase, the outputs of this phase (project plan, control procedures, etc.) must be specifically signed off by the project manager when subsequently appointed to that role.

1.6          Project planning

1.6.1          The project quality plan


The project planning phase is critical to the effective implementation and control of the project and the basis for project success is established during this phase. The planning undertaken at this stage is the responsibility of the project manager.  The primary output from this phase is the Project Quality Plan (PQP). The basic element required to properly define the PQP is the Work Breakdown Structure or WBS.

The PQP comprises the following:

  • The PQP sign-off
  • The statement of project objectives
  • The project charter
  • The project plan
  • Project control procedures

Note: here lies an inconvenience of terminology. The PQP is much more than a plan for incorporating quality into the project. There is a comnponent within the PQP that deals exclusively with quality issues per se.

1.6.2          PQP sign off, project objectives, project charter

PQP sign-off

This is a formal record of the agreement, signed by the Project Manager as well as the PCG of the PQP. It is confirmation of approval of the plan (e.g. what is to be done, when, who, at what cost etc) and the processes involved if the desired outcomes are to be achieved.

Project objectives

This is a statement defining the project objectives. The confirmed Project Success Criteria should be included, together with quantified measures. Unquantified objectives introduce a high degree of risk to the process, by reducing the ability to measure divergences at an early stage.

Project charter

Management’s commitment to internal projects (and hence the willingness to make available the required resources), as well as formal delegation of authorities to the project manager, are recorded here.

1.6.3          The project plan

The Project Plan is the master plan for the execution of the project, and provides the framework from which the implementation will develop in a co-ordinated and controlled manner. The project scope definition, programme and budget are established at this time. These provide the baseline against which performance can be measured, and against which approved changes to the project baseline can be properly evaluated.   The Project Plan comprises the following components:

Scope definition

A written scope statement that defines, in appropriate detail, the scope of every project component and identifies all significant project deliverables. In this context ‘scope’ includes features and functions of products and/or services, and work to be undertaken to deliver a conforming output

Work breakdown structure         

A Work Breakdown Structure (WBS) is the breakdown of the project into the separate activities that can be considered entities for the purpose of task assignment and responsibilities. The WBS is generally presented in a product-oriented hierarchical breakdown. Successive levels include increasingly detailed descriptions of the project elements. The lowest level items are referred to as work packages and these are assignable to individuals within the project team, or to subcontractors.

Orgonization breakdown structure

The Organization Breakdown Structure (OBS) involves the definition of the project structure, setting out the parties and individuals involved in the execution of the project. It also formalizes the lines of communication and control that will be followed. 

Task assignment

This is a list of the assignment tasks and responsibilities.  All tasks and activities previously defined become the responsibility of specified parties.   The WBS and OBS may be extended to define a ‘task assignment matrix’.

Project schedule

The preliminary master schedule for the project identifies the target milestones for the project, and the relative phasing of the components.

Project budget

In some cases a project budget is established during the feasibility study, without the benefit of adequate detail of the concepts evaluated.  At that stage a maximum cost may have been established, because expenditure above that figure would cause the project not to be economically viable. Where such a constraint exists, and if the feasibility study has not reliably established the cost of the project, it will be necessary to further develop the design before committing to the project.

Miscellaneous plans

Additional plans may need to be documented here. These include, inter alia,    consultations and risk management. Alternatively, a strategy for these can be defined in the section dealing with project controls.


All of the above project elements must be documented in the Project Plan.  Figure 1.5 shows the inter-relationships of all these entities.


Figure 1.5

The project plan

1.6.4          Project control procedures

The ultimate success of the project will require that objectives for performance, budget and time, as defined within the Project Plan, are fulfilled.  This will only be possible if the necessary monitoring and control systems are established prior to the commencement of project implementation. 

Monitoring and reporting should include project performance indicators derived from the Project Success Criteria. Planning should take into account the critical success factors, i.e. it should address any potential difficulties that may arise from them.

Control procedures need to be established and documented for the management of the following parameters:


Procedures for the administration of the project should be defined. These should include issues such as:

  • Filing
  • Document management
  • Correspondence controls
  • Administrative requirements of the principal


The definition of scope change control systems which:

  • Define circumstances under which scope changes can arise
  • Control the process invoked when changes do arise
  • Provide for integrated management of the consequences of the changes, i.e. time and cost implications


The definition of project-specific quality policies and standards, together with processes for ensuring that the required quality standards will be achieved. This is best achieved by reference to the application of, and responsibilities for, Inspection and Test Plans.


The definition of control procedures which should include:

  • Budget and commitment approvals for design, procurement and construction functions
  • The issue and control of delegated financial authority, to the project manager controlling consultants and contractors, as well as to consultants controlling contractors          
  • Variation control for changes arising during project implementation
  • Value engineering
  • Cost monitoring, reporting and control systems and procedures


The definition of strategies and procedures for scheduling, monitoring and reporting, likely to include:

  • Programming methods and strategies for master and detail programmes, i.e. definition of programming techniques as well as the frequency of review and updating
  • Progress monitoring and reporting systems and procedures.


The definition of objectives and procedures for putting in place effective risk management.  Note that there may be a Risk Management activity schedule in the PQP.


This specifies all requirements for communications within the project and to the client/sponsor, and is likely to include:

  • Meetings – schedules and processes
  • Reporting requirements
  • Document distribution
  • Handover
  • Close out


This defines strategies and procedures for tendering, as well as for the selection and management of consultants, suppliers and contractors.


This covers documented standardized tendering procedures, tender documentation, and tender evaluation procedures for each contract type (i.e. service, procurement, construction etc).

The tendering process is often a very sensitive one, especially if public funds are involved.  Appropriate attention must be paid to ensure that the legal aspects of the process are properly addressed, and that the process is applied with demonstrable fairness.  Recent changes in the laws applying to tendering should be noted.


This refers to a standardized document dealing with the use of consultants. It should cover issues such as consultants’ briefs and terms of engagement. Consultants’ briefs would typically include the following items:

  • The scope of the work to be undertaken, and any limitations thereon
  • The type of services to be provided and the deliverables required (this will be defined within the WBS for the specific work package)
  • Approvals required from the client
  • Approvals to be exercised on behalf of the client
  • Special requirements of a management, technical or financial nature, for example quality assurance/quality control programmes, variation control procedures etc.
  • Reporting requirements
  • Project schedule requirements, for service delivery as well as implementation phases
  • Budgets for the proposed implementation deliverables or capital items
  • Basis of payment for services to be provided by the consultant


The terms of engagement and conditions of contract should be based on standard documents where these exist.  The level of documentation should be appropriate to the values of contracts let, and usually a number of options are required.

1.6.5          Work breakdown structures

Developing the WBS is fundamental to effective planning and control for the simple reason that the derived work packages are the primary logical blocks for developing the project time lines, cost plans and allocation of responsibilities.

Many people either miss out this key step in the project management process, or undertake the step informally without appreciating how important it is.

                   Definition and terminology

PMI PMBOK 1996 provides the following definition for a WBS:

A deliverable oriented grouping of project elements which organizes and defines the total scope of the project: work not in the WBS is outside the scope of the project.  Each descending level represents an increasingly detailed description of the project elements.

The WBS is created by decomposition of the project, i.e. dividing the project into logical components, and subdividing those until the level of detail necessary to support the subsequent management processes (planning and controlling) is achieved.

Terminology varies in respect of defining project elements. The use of the terms ‘project’, ‘phase’, ‘stage’, ‘work package’, ‘activity’, ‘element’, ‘task’, ‘sub-task’, ‘cost account’, and ‘deliverable’ is common:

PMBOK terminology provides the following definitions:

  • A work package is a deliverable at the lowest level of the WBS
  • A work package can be divided into activities
  • An activity is an element of work performed; with associated resource requirements, durations and costs
  • An activity can be subdivided into tasks

A properly developed WBS provides a basis for:

  • Defining and communicating the project scope
  • Identifying all components of work within the project
  • Identifying the necessary skills and resources required to undertake the project
  • Effective planning of the project (scheduling, resource planning, cost estimating)

The WBS does not identify dependencies between the components, nor does it identify timing for the components. These are, for example shown in the PERT and Gantt charts (see next chapter).

                   Creating the WBS

There are many valid approaches for the decomposition of a project.  In many cases there will be semi-standard WBS templates that can be used or adapted.  The WBS should generally identify both the project management and project deliverables, and should always be defined to reflect the particular way in which the project is to be managed.

The appropriate level of detail will vary between projects, and at different times within the same project.  Future project phases may need less definition than the current phases – so the WBS may be progressively developed as the project develops – but this requires a flexible WBS structure to be selected in the first instance.

In planning the WBS, criteria can be adopted to ensure that the level of detail is appropriate and consistent.  Such criteria might include:

  • Are the packages of work in the WBS sensible?
  • Can any package be broken down further into sensible components?
  • Is each package the responsibility of only one organizational group?
  • Does every package represent a reasonable quantity of work?
  • Does any package constitute more than, say, 5% (or 10%) of the project?
  • Does any package constitute less than, say, 1% (or 2.5%) of the project?
  • Does every package provide the basis for effective cost estimating and scheduling?

The following example shows the WBS of a project with geographical location at the second level (see Figure 1.6).

Figure 1.6

WBS for restaurants project

Alternatively, the various functions (design, build, etc) can be placed at the second level (see Figure 1.7).



Figure 1.7

Alternative WBS for restaurants project


A third alternative shows a subsystem orientation (see Figure 1.8).


Figure 1.8

Alternative WBS for restaurants project

A fourth alternative shows a logistics orientation as follows (see Figure 1.9):


Figure 1.9

Alternative WBS for restaurants project


The WBS could also be drawn to show a timing orientation (see Figure 1.10).

Figure 1.10

Alternative WBS for restaurants project

Note that ‘Design’ and ‘Execution’ in the WBS above are NOT work packages, they are just headings. ‘Start up’, however, is a work package since it is at the lowest level in its branch. The WBS could be broken down even further but the risk here is that the lowest-level packages could be too small. If ‘advertising’, for example, could be accomplished in 100 hours it might be a good idea to stop at that level. It could then be broken up into activities and tasks (and even sub-tasks); the duration and resource requirements would then be aggregated at the ‘advertising’ level, but not individually shown on the WBS. 

It is, of course, not necessary to use a sophisticated WBS package; a spreadsheet will work just fine as the following example shows (see Figure 1.11).


Figure 1.11

WBS using spreadsheet


Engineering Institute of Technology - Latest News