PROJECT MANAGEMENTabeproject.weebly.com/uploads/3/0/8/2/3082433/l6... · project plan. 3.4.1...

i

© ABE

PROJECT MANAGEMENT

QCF Level 6 Unit

Contents

Chapter Title Page

Introduction to the Study Manual iii

Unit Specification (Syllabus) v

Coverage of the Syllabus by the Manual ix

1 Project Initiation 1 Introduction 2 From Business Objectives to Project Description 3 Project Feasibility and Risk Analysis 7 Project Planning – towards a Life Cycle Model 11 The Project Manager Role 18 2 Project Analysis 27 Introduction 28 Hierarchical Division of Work 28 Risk Assessment and Management 35 Cost Planning and Estimation 42 Dealing with Bids, Tenders and Contracts 48 Effects of Location on Project Management 52 3 The Project Plan 57 Introduction 58 Project Overview 58 Project Management Structures 60 Project Activities and Schedules 69 Dealing with Change in Project Schedules 74 Project Communications 78 4 Monitoring and Controlling Project Progress 83 Introduction 84 Progress Monitoring 84 An Approach to Project Control 91 Regaining Project Control 97 5 Dealing with Team Structures and Leadership 103 Introduction 104 Organising Suitable Team Structures 104 Strategic Approach to Effective Leadership 116

ii

© ABE

Chapter Title Page

6 Managing Quality and Change 131 Introduction 132 Understanding Project Quality 132 Dealing with Change 143 Configuration Control 151 7 Project Closure and Review 155 Introduction 156 Project Termination 156 Closing Down a Project 161 Documenting Project Completion 163

iii

© ABE

Introduction to the Study Manual

Welcome to this study manual for Project Management. The manual has been specially written to assist you in your studies for this QCF Level 6 Unit and is designed to meet the learning outcomes listed in the unit specification. As such, it provides thorough coverage of each subject area and guides you through the various topics which you will need to understand. However, it is not intended to "stand alone" as the only source of information in studying the unit, and we set out below some guidance on additional resources which you should use to help in preparing for the examination.

The syllabus from the unit specification is set out on the following pages. This has been approved at level 4 within the UK's Qualifications and Credit Framework. You should read this syllabus carefully so that you are aware of the key elements of the unit – the learning outcomes and the assessment criteria. The indicative content provides more detail to define the scope of the unit.

Following the unit specification is a breakdown of how the manual covers each of the learning outcomes and assessment criteria.

The main study material then follows in the form of a number of chapters as shown in the contents. Each of these chapters is concerned with one topic area and takes you through all the key elements of that area, step by step. You should work carefully through each chapter in turn, tackling any questions or activities as they occur, and ensuring that you fully understand everything that has been covered before moving on to the next chapter. You will also find it very helpful to use the additional resources (see below) to develop your understanding of each topic area when you have completed the chapter.

Additional resources

ABE website – www.abeuk.com. You should ensure that you refer to the Members Area of the website from time to time for advice and guidance on studying and on preparing for the examination. We shall be publishing articles which provide general guidance to all students and, where appropriate, also give specific information about particular units, including recommended reading and updates to the chapters themselves.

Additional reading – It is important you do not rely solely on this manual to gain the information needed for the examination in this unit. You should, therefore, study some other books to help develop your understanding of the topics under consideration. The main books recommended to support this manual are listed on the ABE website and details of other additional reading may also be published there from time to time.

Newspapers – You should get into the habit of reading the business section of a good quality newspaper on a regular basis to ensure that you keep up to date with any developments which may be relevant to the subjects in this unit.

Your college tutor – If you are studying through a college, you should use your tutors to help with any areas of the syllabus with which you are having difficulty. That is what they are there for! Do not be afraid to approach your tutor for this unit to seek clarification on any issue as they will want you to succeed!

Your own personal experience – The ABE examinations are not just about learning lots of facts, concepts and ideas from the study manual and other books. They are also about how these are applied in the real world and you should always think how the topics under consideration relate to your own work and to the situation at your own workplace and others with which you are familiar. Using your own experience in this way should help to develop your understanding by appreciating the practical application and significance of what you read, and make your studies relevant to your

iv

© ABE

personal development at work. It should also provide you with examples which can be used in your examination answers.

And finally …

We hope you enjoy your studies and find them useful not just for preparing for the examination, but also in understanding the modern world of business and in developing in your own job. We wish you every success in your studies and in the examination for this unit.

Published by:

The Association of Business Executives

5th Floor, CI Tower

St Georges Square

New Malden

Surrey KT3 4TE

United Kingdom

All our rights reserved. No part of this publication may be reproduced, stored in a retrieval

system or transmitted, in any form or by any means, electronic, mechanical, photocopying,

recording or otherwise without the prior permission of the Association of Business Executives

(ABE).

ABE would like to thank Magnum Opus Knowledge Transfer Ltd and acknowledge their role

in the development of this study manual.

© The Association of Business Executives (ABE) 2011

v

© ABE

Unit Specification (Syllabus)

The following syllabus – learning objectives, assessment criteria and indicative content – for this Level 6 unit has been approved by the Qualifications and Credit Framework.

Unit Title: Project Management

Guided Learning Hours: 210

Level: Level 6

Number of Credits: 25

Learning Outcome 1

The learner will: Be able to initiate the preliminary stages of a project.

Assessment Criteria

The learner can:

Indicative Content

1.1 Identify an appropriate project from an appraisal of business objectives.

1.1.1 Recognise the need for a specific undertaking (a ‘project’) in order to achieve business goals.

1.1.2 Explain how pursuing the objectives of an organisation can lead to a project definition and a specification of requirements.

1.2 Assess the feasibility of a proposed project, taking risk and uncertainty into account.

1.2.1 Emphasise the importance of conducting a feasibility study into a proposed project.

1.2.2 Identify the various dimensions of feasibility such as financial, technical, social, ethical, ecological and managerial.

1.2.3 Assess the levels of risk and uncertainty in a project and identify critical success factors.

1.3 Devise an outline life cycle plan suitable for the project’s environment.

1.3.1 Describe the basic project life cycle model comprising definition, planning, organising, execution and closure stages.

1.3.2 Appraise the suitability of alternative life cycle models involving phased development and prototyping.

1.4 Define the responsibilities and activities of the project manager.

1.4.1 Explain the diverse activities of a project manager in delivering a successful outcome, such as estimating, planning, administrating, reporting and leading.

1.4.2 Point out the importance of ensuring good communication with all stakeholders, including the project sponsor and the client.

vi

© ABE

Learning Outcome 2

The learner will: Be able to analyse the project work content and associated risks, in order to obtain estimates and tenders.

Assessment Criteria

The learner can:

Indicative Content

2.1 Explain how a project can be sub-divided into work packages and cost estimates.

2.1.1 Describe how a project can be sub-divided hierarchically into a work breakdown structure (WBS).

2.1.2 Explain how the WBS can be expanded into work packages and tasks with an accompanying cost breakdown structure.

2.2 Identify, analyse and manage the risks in a project.

2.2.1 Identify and assess risks in terms of their possible impact on the project outcome.

2.2.2 Manage project risk by appropriate means such as avoidance, reduction, transfer, acceptance and contingency planning.

2.3 Appraise relevant data in order to calculate overall estimates for the project.

2.3.1 Gather information in order to obtain balanced estimates of time and cost.

2.3.2 Consider the likelihood of cost escalation and any ensuing need for contingency allowances in preparing final estimates.

2.4 Evaluate tenders in order to reach a formal contract.

2.4.1 Describe a process by which suppliers’ tenders can be evaluated in order to select one contractor.

2.4.2 Outline the contents and legal basis of a typical contract to supply

2.5 Explain the effect of globalisation, including cultural issues, on project management.

2.5.1 Explain how project management practice may be influenced by geographical and cultural factors

Learning Outcome 3

The learner will: Be able to create a detailed project plan.

Assessment Criteria

The learner can:

Indicative Content

3.1 Devise a structure for the management and administration of the project.

3.1.1 Justify the need for a formal project management structure.

3.1.2 Propose an appropriate structure for the control and administration of a project and indicate the responsibilities of key personnel.

3.2 Identify and schedule the activities in a project by employing appropriate techniques.

3.2.1 Identify the activities in a project and establish their dependencies.

3.2.2 Employ recognised techniques, such as the Gantt Chart and network analysis, in order to devise a project schedule.

3.2.3 Outline the typical functions of project management software packages which can assist the scheduling task.

vii

© ABE

3.3 Adjust schedules as necessary in order to optimise the use of resources.

3.3.1 Explain the need to adjust project schedules when the available resources are subject to constraints.

3.3.2 Reorganise a project schedule in order to smooth resource requirements.

3.4 Construct and justify a detailed project plan.

3.4.1 Recognise the need to communicate the project plan to various interested parties.

3.4.2 Describe the contents of a detailed project plan.

Learning Outcome 4

The learner will: Understand how the progress of a project can be monitored and controlled.

Assessment Criteria

The learner can:

Indicative Content

4.1 Identify factors which frequently disturb the progress of a project.

4.1.1 List typical problems which affect the progress of a project.

4.1.2 Account for such problems and propose remedial actions.

4.2 Suggest techniques by which the project manager can appraise the status of a project.

4.2.1 Identify those sources of information which might indicate deviations from the desired progress of a project.

4.2.2 Explain the importance of corroborating and evaluating status information before taking action.

4.3 Explain methods by which the project manager could resolve the problems detected, with examples.

4.3.1 Explain how cost variances and slippage can be calculated.

4.3.2 Describe the courses of action open to the project manager in managing deviations from a planned schedule.

Learning Outcome 5

The learner will: Know how to organise a suitable team structure for the project personnel and devise strategies for leading them effectively.

Assessment Criteria

The learner can:

Indicative Content

5.1 Compare the commonly employed project team structures.

5.1.1 Emphasise the importance of effective team organisation and management.

5.1.2 Compare and contrast teams organised on functional, project, matrix and contract structures.

5.2 Identify the interpersonal skills required for effective teamworking and project management.

5.2.1 List and discuss key leadership skills which are considered desirable in a project manager.

5.2.2 Discuss the actions and decisions by which a project manager can influence the motivation of team members.

viii

© ABE

Learning Outcome 6

The learner will: Understand the management of quality and change within a project.

Assessment Criteria

The learner can:

Indicative Content

6.1 Explain how quality may be assessed and managed in a project.

6.1.1 Explain the term ‘quality’ viewed from perspectives such as the product, the consumer, the manufacturing specification and value.

6.1.2 Describe standard techniques for assessing and maintaining quality requirements.

6.1.3 Explain how the quality of software products may be assessed and managed.

6.2 Suggest reasons for proposing changes to a project from within.

6.2.1 Using examples, distinguish between internal and external changes.

6.2.2 Recognise the importance of implementing a formal change control procedure and describe its constituent elements.

6.3 Devise an administrative procedure by which change proposals may be justified and processed.

6.3.1 Explain the steps in a typical configuration control procedure.

Learning Outcome 7

The learner will: Know about the recommended activities and required reports in the closure and review of a project.

Assessment Criteria

The learner can:

Indicative Content

7.1 Summarise the difficulties that may be encountered in the closing stages of a project.

7.1.1 Distinguish between the human and technical problems related to project termination.

7.1.2 Consider factors related to the project staff, the client, project handover, maintenance and documentation, contract completion and acceptance, financial matters and closure checklists.

7.2 Describe the administrative actions often required of the project manager as a project is terminated.

7.2.1 Construct a list of actions appropriate for a project manager preparatory to closing down a project.

7.3 Identify the reports which should be prepared and describe their likely contents.

7.3.1 Distinguish between the purposes of the project manager’s final report and the post-implementation report.

7.3.2 Summarise the contents of the project manager’s final report and the post-implementation report.

ix

© ABE

Coverage of the Syllabus by the Manual

Learning Outcomes Assessment Criteria Manual

The learner will: The learner can: Chapter

1. Be able to initiate the preliminary stages of a project

1.1 Identify an appropriate project from an appraisal of business objectives

Chap 1

1.2 Assess the feasibility of a proposed project, taking risk and uncertainty into account

Chap 1

1.3 Devise an outline life cycle plan suitable for the project’s environment

Chap 1

1.4 Define the responsibilities and activities of the project manager

Chap 1

2. Be able to analyse the project work content and associated risks, in order to obtain estimates and tenders

2.1 Explain how a project can be sub-divided into work packages and cost estimates

Chap 2

2.2 Identify, analyse and manage the risks in a project

Chap 2

2.3 Appraise relevant data in order to calculate overall estimates for the project

Chap 2

2.4 Evaluate tenders in order to reach a formal contract

Chap 2

2.5 Explain the effect of globalisation, including cultural issues, on project management

Chap 2

3. Be able to create a detailed project plan

3.1 Devise a structure for the management and administration of the project

Chap 3

3.2 Identify and schedule the activities in a project by employing appropriate techniques

Chap 3

3.3 Adjust schedules as necessary in order to optimise the use of resources

Chap 3

3.4 Construct and justify a detailed project plan

Chap 3

4. Understand how the progress of a project can be monitored and controlled

4.1 Identify factors which frequently disturb the progress of a project

Chap 4

4.2 Suggest techniques by which the project manager can appraise the status of a project

Chap 4

4.2 Explain methods by which the project manager could resolve the problems detected, with examples

Chap 4

x

© ABE

5. Know how to organise a suitable team structure for the project personnel and devise strategies for leading them effectively

5.1 Compare the commonly employed project team structures

Chap 5

5.2 Identify the interpersonal skills required for effective teamworking and project management

Chap 5

6. Understand the management of quality and change within a project

6.1 Explain how quality may be assessed and managed in a project

Chap 6

6.2 Suggest reasons for proposing changes to a project from within

Chap 6

6.3 Devise an administrative procedure by which change proposals may be justified and processed

Chap 6

7. Know about the recommended activities and required reports in the closure and review of a project

7.1 Summarise the difficulties that may be encountered in the closing stages of a project

Chap 7

7.2 Describe the administrative actions often required of the project manager as a project is terminated

Chap 7

7.3 Identify the reports which should be prepared and describe their likely contents

Chap 7

1

© ABE

Chapter 1

Project Initiation

Contents Page

Introduction 2

A. From Business Objectives to Project Description 3

The Need for a Specific Undertaking (Project) to Achieve Business Goals 3

How Pursuing Organisation Objectives can Lead to a Project Definition 5

B. Project Feasibility and Risk Analysis 7

The Importance of Conducting a Feasibility Study 8

The Various Dimensions of Feasibility 9

The Levels of Risk and Uncertainty and Success Factors 11

C. Project Planning – towards a Life Cycle Model 11

The Basic Project Life Cycle Model 12

The Suitability of Alternative Life Cycle Models 15

D. The Project Manager Role 18

The Diverse Activities of a Project Manager 20

The Importance of Ensuring Good Communication 23

Summary 25

Answers to Review Questions 26

2 Project Initiation

© ABE

INTRODUCTION

Like every course on project management, this one begins by setting the scene for the main concepts. In this chapter the project management concept itself is explained in detail, and we then take an overview of the core components of a project.

Each project has a purpose that makes it useful to its sponsors and the people (or organisations) that need the project to succeed (and who are therefore willing to invest time,

effort and money for that purpose). A project is created in order to provide a solution to a

problem that can be clearly defined. The solution to the problem follows the analysis of the needs triggered by the existence of the problem. Projects must be realistic: resources are not endless, and the impact of the solution developed must justify the overall cost of the resources used.

Each project is implemented within a certain context and the main consideration is the available time and space for the development of its activities. The complexity of each project depends on the problem that must be solved and the planning decisions made. Since problems can be demanding, it is often the case for projects to be complex and to require a collective effort to support their activities. For this reason project teams are created, and it is highly likely for work to be delegated, subcontracted and outsourced, which leads to even more complex project structures.

Projects must be unique, creative and innovative because they are solving specific problems of particular scenarios that exist in organisations. The uniqueness of a project and the developed solution does not mean that project managers do not resort to the adaptation of existing solutions and the partial use of existing available methods and approaches. The assessment of a project takes place in a variety of forms, ranging from individual performance criteria and progress indicators for project phases, to overall project evaluation and monitoring of specific actions. For all these reasons projects are usually described in terms of phases that are interrelated and can be identified in terms of tasks, deliverables and resources needed.

Objectives

After studying this chapter, you should be able to:

justify the need for a specific undertaking (a "project") in order to achieve business goals

explain how pursuing the objectives of an organisation can lead to a project definition and a specification of requirements

justify the importance of conducting a feasibility study into a proposed project

identify the various dimensions of feasibility such as financial, technical, social, ethical, ecological and managerial

assess the levels of risk and uncertainty in a project and identify critical success factors

describe the basic project life cycle model comprising definition, planning, organising, execution and closure stages

appraise the suitability of alternative life cycle models involving phased development and prototyping

explain the diverse activities of a project manager in delivering a successful outcome, such as estimating, planning, administrating, reporting and leading

justify the importance of ensuring good communication with all stakeholders, including the project sponsor and the client.

Project Initiation 3

© ABE

A. FROM BUSINESS OBJECTIVES TO PROJECT DESCRIPTION

This chapter discusses the core principles of project management and provides the foundation for further discussion of more specific topics later. A working definition of project management regards the principles, methods, approaches and techniques used to support and lead project teams towards meeting certain requirements by following a schedule, dealing with calculated risks and handling available resources.

The Need for a Specific Undertaking (Project) to Achieve Business Goals

There are so many definitions of what constitutes a project. The main concern is that

projects cannot be adequately defined because they are unique in nature. Potentially, each organisation or individual embarking on a project has unique needs that must be addressed, a unique set of available resources, a set of unique environmental factors and constraints and a unique way to employ existing principles, practices and techniques.

The complexity and interconnectivity of activities means that each project ends up being a maze of tasks that are somehow related to producing the deliverables that correspond to certain needs. These tasks can eventually be used not only to satisfy those needs, but also to work towards jointly solving the organisation's problem.

Usually each project originates from a single goal, perhaps even a single key objective that must be met. The complexity of each project depends on the criticality of the project aim and the planning decisions made. The project life cycle is also affected by a number of factors. The available time and the project environment may allow certain decisions to be made while other options may not be available.

Finally a project can be defined in terms of its budget and scheduling, since these two concepts affect the resources available as well as the way that the project specification is tailored to meet the original requirements. We can therefore identify a number of project parameters that can be used to provide a concise method for describing projects. These are:

Scope – scope means what needs to be done and which problem will be solved with the successful implementation of the project activities.

Quality – if certain success criteria are met they provide performance indicators and standards of acceptable project deliverables as well as project operations. It is necessary to realise that quality may be defined according to what is expected of the project products or the criteria for assessing the project processes.

Cost – budgeting requirements and constraints are very important for the project definition.

Time – deadlines, constraints and availability of resources seriously affect the project progress and overall performance.

Resources – apart from monetary resources, projects require technology, workforce, skills, experience, etc.

Think Point 1

For an organisation of your choice consider a set of needs leading to the creation of a project. Identify the main parameters of your project plan and explain how these parameters are in line with the organisation's mission.


© ABE

Each organisation defines in its mission the main aims and how they must be achieved. You should focus on the scope for the project, the necessary criteria for assessing the quality of the project's deliverables, the costs associated with the project activities, the available time and any resource needs.

We could safely argue that projects can be classified according to some of the characteristics just mentioned. Some straightforward criteria to be used when classifying projects may include:

cost

risk

duration

value

complexity

technology.

We have discussed the way projects are defined. The next step is to explain what project management is. The project management concept is quite often defined in terms of the steps or phases that it includes. Initially it is project management practice to establish a set of definitions. These definitions may include the definition of the problem to be solved, the project aims, the organisation's goal, the objectives of the project team, the success criteria to be used and even the assumptions that can be safely made with respect to cost, resources, time, etc.

Project management is also about planning, a phase that is discussed in detail next. There

are clear benefits for a planning phase as it ensures that adequate understanding of the project tasks is shared by project stakeholders. Proper planning helps to deal with project complexity and improve efficiency as resources are used more wisely.

The planning phase is followed by an execution phase that also forms part of project management responsibilities. The execution of a plan assumes that certain resources are made available for each project task. The execution phase also includes the allocation of tasks and the scheduling and budgeting for these tasks.

While the project tasks are being developed and deliverables are being prepared, the emphasis of project management is on controlling the overall process. A detailed project control action involves an assessment of how project objectives are met and the level of completion for each task. The allocation of responsibilities between team members, the identification of suitable deliverables and the performance measurement for each team

member are also included in the controlling phase.

The last phase of project management relates to project closure. This assesses whether the deliverables meet the requirements identified originally, if the project manager is persuaded that the deliverables are in a state to be handed over to the project sponsor, and which aspects of the project plan have been successfully completed. The handover of a project is usually a good opportunity to share lessons learned, as these can prove useful for consequent projects.

A summary of project management phases includes:

Scoping the project – involves defining the problem, establishing the overall goal, identifying the objectives.

Developing the project plan – involves identifying activities, scheduling activities, establishing resource requirements, preparing proposal.

Launching the plan – involves team selection and recruitment, balancing resources, establishing operations, documenting.


© ABE

Monitoring the project – involves reporting, controlling change, monitoring progress, assessing performances, revising plans.

Closing the project – involves obtaining acceptance of project sponsor, producing documentation, auditing and publishing reports.

How Pursuing Organisation Objectives can Lead to a Project Definition

So far we have discussed the definitions of a project and have explained the meaning of project management. Project management is very important for today's organisations as it offers the connecting link between the understanding of an organisation's vision and mission and its operations and outputs. Projects are defined according to the goals identified at organisational level. The understanding of how the common vision can be implemented in the form of a product or a service is essential in order to establish which projects must be implemented.

Within organisations, project management offers a great opportunity to reduce the time required to develop solutions by providing more effective ways of utilising resources and producing deliverables. Project management allows an efficient way of operation leading to new markets, new customers, the internationalisation of provision and entering global markets. Project management allows us to deal with project complexity by accessing the vast amount of information and volumes of knowledge in diverse fields. The project management scope includes dealing with increasing costs of operations, downsizing, diversification and resource dispersion of modern organisations while maintaining an intense client focus.

A project management team must understand that a project operates within a broad environment. The project management context embraces many aspects such as the project life cycle, stakeholders and organisational influences as well as a required skill set. Since the 1950s systemic approaches have emerged in order to solve organisational problems in a more analytical way. The core of such approaches consisted of:

a systems philosophy that views everything as a system of interacting components aiming to solve a specific problem

a systems analysis attempting to support problem solving

a systems management approach addressing organisational, technological and business issues.

Dealing with stakeholders

Putting project management in context should include discussion of the stakeholder concept. It is important to understand why stakeholders are so important for project management. Predominantly stakeholders can be identified as:

primary – who are in a direct relationship with the project

secondary – who are indirectly affected

tertiary – who have a level of influence to the project.

It is very important to understand the role of stakeholders, as they can affect project management either by being project sponsors who commission the project or end-users who provide the project requirements. They can also be "externals" who may affect the environment in which the project operates.

Managing the relationship between the project manager, the project team and the stakeholders is critical for smooth project operation as well as the provision of necessary information and support. Additionally, the communication protocol followed is likely to affect how the project deliverables are prepared and the extent to which initial requirements are met.


© ABE

Think Point 2

Describe a typical strategy for identifying a project's stakeholders and explain how the identified stakeholders may affect the project's life cycle.

Typically, stakeholders may be classified as internal to the organisation or external. Based on this classification, the stakeholders are likely to affect project decisions in different ways. Internal stakeholders are usually readily available to identify their requirements, whereas external stakeholders are treated as clients and may communicate their requirements in more formal procedures.

It is necessary to identify some typical stakeholders in projects:

clients – people who may be using certain project services and a number of its deliverables

end-users – similar to clients in cases where a product is the main project deliverable

sponsor – the source of the financial support and the person or organisation that provides the scope of the project

manager – may affect the project as he or she assesses the project's value for money and return on investment (ROI)

project manager – the person who controls and manages the project activities

project team – the workforce allocated to the project's activities

project management office – those supporting the project management team, including those working for the sponsor

operations manager – the person in the organisation responsible for integrating the project after its closure

top management – the executives who may affect the project by altering the organisation's direction and goals

resource managers – those who decide whether resources become available

contractors – sometimes work may be outsourced or subcontracted, adding to the complexity, cost and time overheads

suppliers – in certain cases projects may require external supplies which may affect the project timeline if delayed.

Organisational Influences

There are many examples of projects failing to meet their targets and it is quite common to see similar projects being executed in quite different ways. It is essential to understand the factors that affect the way a project is implemented within an organisation.

An important concept that you need to become familiar with is the one of "organisational culture". It implies that an organisation is an entity that possesses certain characteristics that can be described as a culture, affecting how the organisation's behaviour affects its internal structures and operations as well as its stakeholders and affiliated entities (e.g. clients, other companies).

It is important to identify those aspects of the organisation culture that affect projects. These are features that set the organisation's environment. Since our focus is on project management, we can classify the organisational influences according to the impact they have on a project. We can identify at least four categories of environmental influences:


© ABE

values and norms

policies and procedure

authority and responsibility

work ethics and patterns.

It is highly unlikely for a successful organisation to operate without a clear mission statement

that outlines the organisation's vision, its values and norms as well as beliefs and expectations. The organisation aims to create an environment that is based on clear goals that are common between its members and is shared amongst its workforce. Such values and beliefs may affect initiatives that a project manager wishes to introduce and may lead to conflicts between a project's objectives and what is perceived as acceptable in the organisation.

An important aspect of project management is the establishment of clear plans regulating

procedures, the way of doing things and eventually the methods employed for solving

certain problems or even taking decisions. Typically, organisations introduce polices to ensure that their operations are regulated and that stakeholders are aware of their rights and responsibilities as well as what is expected from them.

The authority and responsibility aspects of roles within an organisation are set predominantly either in a formal way through appraisals, performance monitoring and contract clauses, or informally in terms of expectations at the workplace. It is quite important to understand how authority is exercised within an organisation in order to estimate its possible impact upon any project.

Finally the patterns of work and work ethics regulate the way an organisation reaches its targets and produces its outputs. It is necessary to identify any constraints or special features of work and performance as a workforce is unlikely to shift into new ways of doing things in a short period of time.

Review Questions 1

(a) What are the five main project management phases?

(b) There are twelve types of typical project stakeholder. Try and name at least nine of them.

Now check your answers with those given at the end of the chapter.

B. PROJECT FEASIBILITY AND RISK ANALYSIS

It is very important for the success of a project to be absolutely certain about what is to be

delivered. The feasibility study provides an overview that allows a reality check to those involved with the project. Furthermore, it can lead to a more detailed analysis of the project requirements and any associated constraints and special aspects that may affect the success of the project and the provision of the final deliverables. The feasibility study of projects may take various forms, depending on project management styles followed and perhaps the existence of internal procedures and policies that may exist in the organisation. This section discusses how a feasibility study may affect a project's outcome and emphasises the role of risk analysis in the eventual success of the project's objectives.


© ABE

The Importance of Conducting a Feasibility Study

The feasibility study could be incorporated into the initial stages of a project's design as it may lead to significantly altering the project's estimated resources, reshaping its aims and overall scope and perhaps adjusting any identified objectives.

There are several suggested procedures and step-by-step approaches that support the way a feasibility study can be conducted. It is quite frequent for a feasibility study to take the form of a requirements analysis exercise.

We could identify the following stages on such an exercise:

identifying project stakeholders

capturing stakeholder needs

performing a needs assessment

performing a reality check

establishing an agreement.

Think Point 3

Explain why the role of the feasibility study is important for analysing the project's requirements.

A feasibility study assesses whether the project objectives can be achieved in the available time and resources. If the feasibility study identifies certain issues that must be addressed, the project plan may have to be changed.

The five steps we have identified provide good guidance on how to group together certain activities that will help you to identify whether your project is feasible or not. The scope of this analysis of the project's requirements is to establish what needs to be done for the project to succeed in its current form, or alternatively how to reshape what was initially perceived as the project's aim and objectives.

We will discuss the requirements analysis stages in some detail next.

Identifying project stakeholders

The project stakeholders are the key people who may have an impact on the project with their decisions or may be in a position or role that may be affected by the project's outcomes. Key people may be classified as internal or external to the organisation that is in charge of the project.

Capturing stakeholder needs

Obviously key people and roles are important for the project's success and therefore we need to establish a good understanding of how these stakeholders are related to the project. This can be achieved by capturing their needs and establishing that we have sufficient information to prepare a requirements map for the project.

There are several ways of identifying stakeholder needs. It is quite common for stakeholders to be interviewed, participate in focus groups or even take part in surveys. All three techniques provide opportunities for stakeholders to communicate their views and for project managers to understand what the stakeholder needs are. The different techniques provide alternative routes for collecting information, depending on whether it is important for two-way communication to be established as well as the detail of information required.


© ABE

Additional techniques can be employed if the project involves the use of technology. In such cases users may participate in cooperative evaluations of existing systems or the design of prototype systems to explain how the project outcome will affect their roles. More options include the development of user scenarios and even the observation of stakeholders in the workplace performing their activities.

Performing a needs assessment

Once requirements are captured it is essential to use a classification scheme. This will allow us to group together needs of similar nature while establishing a prioritisation for

the project's objectives. The requirements identified may be functional or operational, meaning that they may affect the way the project's functions are performed or they may be operations that must be present to support the project's output.

Requirements may also be classified as technical if they relate to technological

aspects of the project, or transitional when they relate to the changeover from the existing situation to the one following the project's completion. Requirements can be

classified according to their severity and it is not uncommon for some of them to be

referred to as desirable, being implemented only when certain criteria are met (e.g. time availability, budget).

Performing a reality check

The reality check stage is critical for all parties involved as it helps towards a common understanding of the needs identified so far. It is important not only for project managers to understand the stakeholder requirements, but also for each stakeholder to realise how their role and perceived needs may affect the project. The definition of each requirement is a key matter for this stage as the clarification and level of detail must be such to ensure that a project deliverable can be associated with it.

The various requirements can be prioritised in terms of their importance and each project may use a different weighing system to establish how these range from critical to non-essential. It is expected that clashes between requirements originating from different stakeholders will exist and it is necessary to establish how such conflicts are resolved. Finally the impact of each requirement being met, as well as the awareness of change and the appreciation of the new environment created, are three issues that must be addressed.

Establishing an agreement

The final stage finds the involved parties in agreement as to the stakeholder requirements and how the project will work towards satisfying them to an extent which is predefined.

The Various Dimensions of Feasibility

We have discussed the importance of project stakeholders and explained how capturing their requirements may affect our project. It is important to realise that prior to the project initiation,

a feasibility study is essential. The feasibility study can be defined as an assessment of

whether the project should go ahead or not. For some people the feasibility study is part of the project life cycle, while others believe that a feasibility study should be in the form of an assessment of the situation prior to the project imitation. In either case, the feasibility study provides useful information and allows an appreciation of the current climate for business as well as an awareness of how the environment may affect the project.

There are several reasons why the feasibility study is so important. A typical reason for requiring a feasibility study is the launching of new initiatives, especially in uncharted waters, in order to avoid spectacular failures. Such a study would allow an assessment of the likelihood of success and review examples of similar endeavours. Another reason for a feasibility study would be the creation of new products and services when we are not sure


© ABE

whether these would work antagonistically to what is already on offer by the organisation. In addition, the study would allow defining the specification and establishing requirements in line with similar products or services that may be available by competitors. Sometimes when change is required in established operations the impact on the rest of the organisation is unknown until a feasibility study provides estimates of what is required to manage such a change. Projects leading to collaborations and new structures may also need a feasibility study to identify the actual cost of the new structure in the long term.

So what is offered by a feasibility study? The main elements can be identified as:

assessing demand – allowing an understanding of what the actual demand is for the new service or product and therefore justifying the cost and investment

assessing resources – estimating whether the project is likely to succeed with existing resources and identifying whether additional resources may become available and at what cost

assessing impact – identifying the changes introduced with the deployment of the project

assessing timeline – calculating the duration of the project and how this may affect the success of the project deliverables once deployed.

A feasibility study should be based on the following four steps:

An examination of the current situation with the aid of scenarios, to establish an understanding of the background and the environment, and how the project will be affected by any external factors.

Assess the project requirements and perform a reality check to establish that these requirements are realistic and that the plan provides a reasonable way to address them.

Then the method followed to implement the project is put to the test to establish whether it is proven and stable and with a significant chance to succeed against pre-defined quality criteria.

Provide possible contingency plans and alternative routes for a number of scenarios relevant to identified risks.

A number of feasibility study dimensions can help to understand whether the project should go ahead or not. These are:

Competitive landscape – the existence of similar products and services that are well established and quite competitive offerings may lead to a project that delivers something that has no chance against the competition.

Operating needs – the needs of the project deliverable to ensure that it is sustainable after the project completion.

Scope clarity – the project may be based on unclear scope and conflicting aims or a vision that is no longer supported by the organisation.

Financial aspects – the project may be unrealistically budgeted for or may result in deliverables pricey to obtain or operate.

Technical aspects – the technology use may be near its end, resulting in obsolete deliverables.

Social aspects – the project aims at a market that is incapable of appreciating the quality of the project deliverables.

Economic study – the project benefits may not outweigh the costs.


© ABE

Fundraising study – the project may be unlikely to attract the support required to complete it.

The Levels of Risk and Uncertainty and Success Factors

So we can see that a feasibility study allows a project to be assessed in terms of its likelihood of success. An important consideration associated with feasibility study is risk management and that is discussed further in later chapters. However you should note that it is quite important to assess the levels of risk associated with the project soon after the feasibility study provides its findings.

There are some guidelines in terms of how to assess the risk level in our projects and they can prove quite useful when making decisions. First of all risk management should be part of the project throughout its life cycle. It is necessary to establish a risk assessment policy that covers each project activity and links to a specific contingency plan. Another important guideline is to establish a risk assessment procedure that kick starts once the project is initiated. This means that any risks may be identified very early in the process. The next guideline is that the risks should be communicated among stakeholders, as this practice is likely to result in solutions and proactive steps. Another view is to regard risks not only as threats but also as possible opportunities to further benefit from the project's deliverables. Risks should also be classified and prioritised to allow a swift response. Risk analysis should be a part of the risk management process as it breaks down the risk at different levels and identifies whose responsibility it is to address particular threats. Also this practice allows the identification of tasks which are likely to be affected (and when during their timeline). A risk response plan should be in place to support the step-by-step reaction that is likely to succeed and also be monitored so producing an accurate reflection of the actual impact when risks are realised. Establishing a risk log and any responses provides an invaluable tool for future projects. Finally, risk tracking should take place in parallel with task planning, and project monitoring should report on project tasks as well as any associated risks.

Review Question 2

Name the five main requirements of the analysis stage.

Now check your answer with that given at the end of the chapter.

C. PROJECT PLANNING – TOWARDS A LIFE CYCLE MODEL

Quite often project management is discussed in terms of a number of stages that are required for the completion of a specific project. This is frequently helpful but is often confused with the project planning activity. It is critical to understand that although project planning is perhaps the most important stage (since requirements are identified, explained, defined and agreed), it is still one of the steps that one has to follow in order to complete a project.

Project stages can be identified as follows:

definition

planning

organising


© ABE

execution

closure.

In principle, the project overall aim and specific objectives are defined prior to the stage involving a detailed plan. The resources and other operational aspects affecting the project operations and deliverables are then organised prior to the execution and delivery of the project.

The Basic Project Life Cycle Model

According to Harvey Maylor, the project life cycle is viewed as four interrelated phases (Project Management, fourth edition). These phases are identified as:

Defining the project – concerned with the overall organisation goal and the definition of the project aims.

Designing the project processes – concerned with the planning activities that may range from risk analysis and cost estimation to conflict resolution and justification of decisions.

Delivering the project – concerned with the control of the project activities, management of resources, leadership and initiative as well as decision-making and problem solving.

Developing the process – concerned with the evaluation of the process by establishing what must change and a reflection on the project's deliverables.

The project management life cycle suggested by Maylor is illustrated in Figure 1.1. It is commonly referred to as the 4-D structure.

Figure 1.1: The 4-D project life cycle structure suggested by Harvey Maylor

Error!

Figure 1.1 shows the transition between the four phases. This could be described as producing a brief during the "define it" stage that is used for the "design it" stage in order to produce a detailed proposal. The proposal is then used during the "do it" stage that concludes with the project outcomes in the form of specific deliverables. Finally the "develop it" stage summarises the process and product knowledge for evaluation and further development.

Maylor also discusses the 7-S framework that was promoted by management consultants McKinsey and Company. This framework can be used to establish a certain level of detail and quality of work irrespective of the project management stage we are in. This project management framework is based on seven elements identified as follows:

Strategy

Strategy provides a high level perception of the requirements identified for the project and an assessment of how the project aims are going to be achieved. The strategy for the project may be in line with an overall strategy for a specific organisation or may be affected by constraints and special characteristics of the project.

Structure

Develop it

Define it

Do it

Design it


© ABE

Structure creates a mapping of all those elements required for the successful completion of the project. The various project requirements are used to identify what structures must be in place to meet the project's objectives.

Systems

The use of technology may not be required for the introduction of systems as this element is concerned with the methods used to achieve project tasks as well as monitoring and controlling the process.

Staff

Establishing an accurate record of the staff members involved in the project is critical for scheduling as well as resource planning. Staffing involves recruitment and selection and may include training or additional activities to support the skill set needed for the project. The performance profile of existing staff, as well as the transferable skills that must be possessed by role holders, are used to align role responsibilities and job descriptions to individual profiles.

Skills

The required skills for project management may range from managerial and transferable skills to technical skills needed to use project management tools.

Style/culture

The style followed in project management is affected by the organisational culture as discussed earlier in the chapter, and provides a set of guidelines of what is acceptable and expected behaviour during the project.

Stakeholders

Finally the identification of the project stakeholders is an essential part of the framework as it helps to understand the needs of individuals or groups affiliated with the project.

The planning phase

At this point we could focus further on the planning phase and how the elements identified so far may affect the project management decisions. A step-by-step approach to project planning may include the following:

defining goals

identifying deliverables

scheduling

planning infrastructure.

Think Point 4

For a project of your choice identify the main steps you should follow during the planning phase and explain their importance for the project's overall success.

Traditionally, the planning team needs to consider the project's goals, deliverables, schedule and required infrastructure. Failure to address any of these issues could lead to projects aiming towards unrealistic goals, project outputs that are not aligned to stakeholder needs as well as delays and budget overspent.


© ABE

Goal definition step requires a clear and solid understanding of the project. This starts from a reflection on how the project is described by the initiator (it could be a client or the same organisation that is managing the project). A stakeholder analysis must follow as explained previously. Related activities will include the identification of the project sponsor, who is either the source of funds or where other types of resources are drawn from. The recipient of any deliverables as well as others involved in various capacities with the project tasks is also very important. Obviously the analysis of their needs helps to establish the project goals. Such goals are clearly stated in the project plan and are likely to be used in the future as performance indicators and the success criteria for the project's progress. The project's goal is usually described in the form of SMART objectives. This technique is based on the identification of objectives that are:

Specific

Measurable

Achievable

Relevant

Timely.

Project deliverables are sometimes difficult to identify during the planning stage. It is not always possible to know clearly what must be produced by the end of the project. Sometimes the requirements of the project may also change, leading to radically varying outputs. This is why it is a very good practice to provide a working list of project deliverables that is revised at preset time-stamps that coincide with important developments in the project's life cycle. The deliverables may consist of documentation, artefacts, systems, procedures, policies and every conceivable possible result of project activities.

Project scheduling is usually the core of the project plan as it associates the project objectives with specific deliverables and the resources used. The project schedule depends on the duration of the project, and the choice of time units used for scheduling needs to be appropriate for the project duration. For example, for a project that is likely to last for a month it may not be wise to use weeks as the time units as this will not allow sufficient detail in the project plan. The scheduling effort must be based on two factors, namely the effort required and the resource employed. This means that the project activities and tasks are outlined (usually in a tabular format) and then grouped together according to the project phase with specific reference to the required resources.

There are various methods used for the presentation of project schedules but the most common one takes the form of Gantt charts. In these charts each task is represented by a bar of a certain length, signifying its effort in terms of duration (e.g. number of days) in comparison to the project's timeline. (Gantt charts are discussed in Chapter 4.)

Project schedules are used to make decisions critical to the project's success. If the project goes smoothly, then the timeline is followed till the final deadline. If the plan is not in line with the schedule produced and progress differs significantly then it is likely to require:

more resources

more time

less deliverables.

The first two decisions (more resources and more time) lead to additional resources being drafted while the third means that the project sponsor must remain satisfied although certain aspects of the project will not be implemented.

Infrastructure planning is concerned with the provision of sufficient detail to allow the project manager to control aspects such as workforce, risks and communication. The human resource plan of a project provides a detailed overview of who will be responsible for carrying


© ABE

out any activities. Human resources can be classified according to department or even individual roles. On certain occasions it may be the case that a portion of the project is outsourced. The communication plan of the project provides a protocol that is followed to establish that adequate communication takes place for a number of important functions such as making decisions, solving problems, dealing with extensions and delays, assessing performance, checking progress, monitoring deliverables, etc. The risk management plan (further discussed in Chapter 2) is a repository of identified risks, usually followed by some form of likelihood-of-occurrence factor. Typical examples of project risks may relate to budget cuts, lack of skills, discontinued lines, frequent change of requirements and significant alteration of project scope.

Quite often project phases are described in terms of different types of model according to the needs of the project managers. The next section provides an overview of some techniques that are used when developing project life cycles.

The Suitability of Alternative Life Cycle Models

There is a plethora of life cycle models in project management. The main reason for this is the need to provide a customised management approach to projects that sometimes seem quite unique for a certain scenario or a specific organisation. In early project management days it was quite common for such models to be created in order to fulfil the needs of specific projects. These days there are so many approaches to project management life cycle models and it is possible to adapt them to fit the needs of each new project. This section discusses some alternative solutions for project management life cycle models.

Phased development project management views the entire management activity as a series of key phases and sub-phases. A project management approach based on phased development can identify a number of key phases that may be broken down into simple steps.

Figure 1.2: Phased development project management

Planning

Project

Management Monitoring

Creation

Proposal

Resource generation

Development

Adjustment

Assessment

Evaluation

Performance

Progress

Reporting


© ABE

Figure 1.2 illustrates a phased development project management approach that is based on three key phases: planning, management and monitoring. The principle is that the entire project can be controlled through these key phases. Although the illustration does not provide any links to show possible iterations and interrelations between the three key phases, different projects may follow a number of adaptations of the core principle. The underlying idea is that each project initially enters a planning phase that provides the foundation for the project (as discussed in the previous section). A number of sub-phases can be identified and in this particular instance project planning could be perceived as an opportunity to create the project, provide a project proposal and initiate resource generation from funding to staff selection.

The project management phase is mainly concerned with the development of the project deliverables and the necessary activities that make up the project. Assessment of deliverables and work pattern is also part of the project management phase and it may include any adjustments made to the original plan. It should be noted that project management in this instance is viewed as the management of the project activities towards

the generation of the deliverables. Project development is a term that quite often is used to describe this phase.

The monitoring phase is predominantly concerned with the overall project progress, the performance of staff and the completeness of project tasks. It is sometimes referred to as evaluation or testing, although the term "evaluation" only refers to those activities that assess whether the initial requirements are met, and "testing" essentially addresses the evaluation needs for more technical projects, especially when the technology is being assessed against the support provided through tools and techniques developed to meet stakeholder requirements. Monitoring is not really concerned with any evaluation findings. Reporting is an activity that enriches the outputs of the monitoring phase.

Life cycle models may be more specific in their description of project management as they can focus on specific tasks and how the project manager can lead the project team through these. Obviously the project management tasks identified in these life cycle models are related and can be broken down further. There are various forms of such models depending on how information, deliverables and workflow transitions between the tasks. Some of the more frequent models are:

Sequential – these models are in the form of a sequence of tasks leading to the project completion.

Iterative – these are based on a number of iterations or the availability of cyclic implementation of certain tasks until a desirable outcome is achieved. There is no predetermined number of iterations required as certain steps may be repeated several times before the initial requirements are met.

Spiral – these are similar to iterative models but also have certain aspects associated with their spiral nature, meaning that certain project aspects (e.g. risk) may decrease as we move from the initial parts of the spiral (early phases of a project) towards its centre (project completion stage).


© ABE

Figure 1.3 illustrates a sequential model that demonstrates how a project shifts from one task to the next.

Figure 1.3: Task specific project management

As shown in Figure 1.3, the initial task is to identify the organisation's overall aim for the particular project as it sets the background for the project and the foundation for further decisions. The next task is to proceed with specific project objectives that may involve the identification of stakeholders. Next, the project enters the environmental constraints phase which requires the assessment of the organisation's mission and any other filters for the initial project proposal.

The resource gathering stage may include selection of key staff, adding new members to the project, budget decisions and any other activities that are reflected in the project's schedule. The next task includes all activities relating to the project development and the implementation of its deliverables. The testing and deployment of the deliverables are followed by the evaluation task. As we can see from the figure, there is an iterative option in the way the model can be viewed as each step may return to any of the previous ones in case adjustments have to be made. The number of iterations, the possible paths to previous tasks and the criteria used to make a decision for an iteration depend on the project and the organisation's needs.

At this point it should be noted that project managers often include tasks that deal with all issues following the deployment of all the deliverables and the official closure of the project. Such tasks depend on how the project is sustained in the organisation. Projects that are viewed as a one-off delivery of certain services and products usually end with the evaluation task. However some projects that require continuous support may involve tasks such as follow-up activities, support, maintenance, etc.

A different approach to project management, especially when products or specific services are delivered to stakeholders, is through the development of prototypes. Prototyping refers to

Organisation aim

Project objectives

Environment

Project activities

Resource gathering

Deliverables

Evaluation


© ABE

the development of a "bite" out of the project deliverables, taken in order to assess whether the deliverables are likely to meet stakeholder requirements. Prototyping is a great way to give a prompt experience of the project outcomes to the end-users or customers and is quite often the source of revisions and adjustments following a reality check and reflection exercise.

The main benefit of prototyping is the opportunity it provides to evaluate the project against the initial requirements. The process is not particularly lengthy and allows opportunities for communication and evaluation early in the process. The main drawback is that it may trigger a second round of requirements capture and may result in additional costs.

Figure 1.4: Phased development project management

Figure 1.4 provides an illustration of two prototyping techniques, based on evolutionary and throw-away approaches. The evolutionary approach is very iterative and is used when it is quite expensive to discard a prototype that has been already developed. The way this approach operates is by preparing a prototype that is evaluated. After feedback is received by the stakeholders involved in the evaluation, then work commences on the next version of the prototype. Once the final evaluation iteration is entered the prototype is then transformed into the final set of project deliverables.

An alternative to the evolutionary prototyping approach is the throw away version that begins with a sequential series of steps quite similar to the first iteration of the evolutionary approach. Once the evaluation results are received, the prototype is discarded and the information collected is used to start the project development stage. This approach seems the obvious one when time is an issue and the requirements of capture are likely to remain unaltered throughout the project.

D. THE PROJECT MANAGER ROLE

So far we have discussed core project management concepts, and this has led us, in the previous section, to life cycle models. In this introductory chapter it is essential to discuss the role of the project manager. The project manager is the key person in each project: he or she is responsible for the successful completion of the project and the achievement of the targets set.

Before discussing the activities a project manager has to go through, we need to explain that a project manager must be capable of coming up with the right questions as well as making sure that answers are given to all project questions. These questions can be grouped together according to the different tasks that have been identified in the project life cycles as discussed in the previous section.

Prepare prototype

Evaluate prototype

Evolve prototype

Prepare prototype

Evaluate prototype

Throw away prototype

Develop main project


© ABE

The following lists summarise the activities the project manager has to undertake.

Project scope and requirements analysis:

place the project in the organisation context

identify the stakeholder requirements

understand the changes the project will bring to the organisation

prepare for the change management phase

define the project outcome

explain the reasons for the project

describe the stakeholder aspects satisfied by the project deliverables.

Project setting:

map out the project activities

select a project management approach

establish a project proposal

perform a feasibility study.

Project structure:

define the project method

define the project deliverables

schedule the project.

Project implementation:

establish an understanding of the project logistics

address project practical issues.

Project resources:

decide the budget

identify sources of project costs

categorise the resources according to different project phases.

Project partners:

identify needs for outsourcing

establish agreements with partners and collaborators

select tasks for outsourcing

coordinate resources

attract additional resources and support.

Project communication:

establish a protocol for project communications

provide means for communication and collaboration

associate workflow with communication opportunities

arrange etiquette for communication with external stakeholders and collaborators.


© ABE

Project evaluation:

prepare an evaluation plan

evaluate against the requirements

select the project aspects suitable for evaluation

justify evaluation plans and choices

provide a sustainability plan.

We will now discuss how such activities are an integral part of the project management role. At this point you should be able to prepare questions in order to obtain the information necessary for these activities.

The Diverse Activities of a Project Manager

The diverse activities of the project manager role can be best explained by using what are known as the "project management process groups". Since 1987 the Project Management Institute (PMI) has produced the Project Management Body of Knowledge (PMBOK), a guide that identifies project management processes classified under five process groups and nine knowledge areas.

The project management process groups are:

initiating

planning

executing

monitoring and controlling

closing.

The knowledge areas are:

integration management

scope management

time management

cost management

quality management

human resource management

communications management

risk management

procurement management

The process groups provide yet another approach to the project life cycle, based on specific inputs and outputs. The input of the initiating phase is the project proposal or work contract, while the main output is the project scope statement. The next phase which is planning produces the project management plan. This plan is used as input for the project executing group that produces the project deliverables and performance reports. The deliverables are evaluated and approved during the monitoring and controlling phase. The closing stage is completed once the project final approval and handover are agreed between the project sponsor and the project manager.


© ABE

Think Point 5

Consider the various roles a project manager must undertake during the lifespan of a project and discuss how the various aspects of this role may affect the project's outcome.

The project manager should act as a coordinator of project activities, a controller of project progress and a facilitator of team communications and collaboration.

There are numerous specific activities and tasks that fall under the project manager role in a typical project. The following examples give an impression of the variety of the responsibilities the role entails.

Project manager role tasks:

break down the project into phases and identify tasks under each phase

allocate tasks to different team members and ensure the necessary skills are present in the project team

ensure the necessary infrastructure is available throughout the project

keep track of the project tasks and avoid any slippage

deal with personnel management issues as well as appraisals and performance measurement

deal with the project budget and any financial issues

engage in problem solving, conflict resolution and decision-making relevant to any project activities and associated deliverables

report on project progress and individual performances

perform risk assessment and control sources of risk as well as ensuring quality targets are met.

Quite often, leadership is mentioned as a key virtue that should be possessed by successful project managers. Adair has identified three main areas of concern when team leadership skills are defined. In an adaptation of his leadership model, a project manager should be able to cater for:

task needs

team needs

individual needs.

We can classify some project manager responsibilities under each of the categories identified by Adair.

Attending task needs

The first action a project manager must take is to plan the work ahead and allocate resources. It is necessary to identify and define all the necessary tasks as this will allow estimating the resources required and scheduling the project. The allocation of tasks to team members means that responsibilities are assigned and quality assurance can start through regular monitoring of task progress and performance indicators. Inspecting the project progress followed by an ability to reflect are two skills that are advantageous for the role. The continuous assessment of performance is closely related to the tasks.


© ABE

Attending team needs

The delegation of work is a responsibility associated with the task at hand but also helps to foster a team that can deal with crisis. Adopting a hierarchical structure and ensuring that there is a second in command or a coordinating sub-team can prove an important team "hygiene" factor. Ensuring that motivation and commitment levels remain high as well as regulating the team operations are critical activities for the maintenance of an effective team. Teams require training in order to work together, deal with project tasks and overcome coordination, communication and collaboration difficulties. Communication skills as well as people skills help to improve the team spirit and resolve or remove any conflicts.

Attending individual needs

In the end project teams are as good as their members and a successful project manager must be able to consider the development and learning needs of team members. Although this is typically perceived to be a career boosting activity, a well-designed continuous professional development (CPD) programme ensures that the team members acquire the necessary skills for the task. Sometimes project managers must strike a balance between the needs of the individuals, the teams and the task. Being able to set the right priorities and keep the project on track is imperative. Performance measurement, awareness of individual contributions and reward management are important concepts associated with the well-being of individuals involved with the project. It is not rare for project managers to undertake a coaching role, being involved with consultancy, advice and self-improvement initiatives for project team members.

So far we have discussed the responsibilities of a project manager and the way this role evolves depending on the different stages of the project as well as a number of varying perspectives.

We have identified a number of important project manager tasks, but it is also important to mention some key skills a project manager should possess. The following list is indicative and by no means complete and final:

defining project scope

planning project activities

designing the project life cycle

producing a project plan

planning resources

justifying resources needed

scheduling project activities

providing time and cost estimations

dealing with budgeting issues

managing risks

ensuring quality targets are met

producing performance reports

developing timeline charts

performing risk analysis

finalising or draft documentation

leading the team

dealing with personnel issues


© ABE

influencing strategic planning

informing stakeholders

liasing with project sponsors

producing analytical reports (e.g. scalability)

organising outsourcing activities

being aware of legal aspects

grasping external factors (e.g. social, political, economic)

evaluating progress

preparing/deploying contingency plans

negotiating project alternatives

maintaining systems and processes

managing people and processes

reflecting on goal setting.

The Importance of Ensuring Good Communication

In the previous section, the possession of communication skills was mentioned on several occasions since it often proves to be an essential skill for project managers. In Chapter 3 we will discuss how communication skills affect the success of projects as well as the liaison between various project stakeholders.

However, it is imperative to understand how good communication throughout a project depends not only on interpersonal skills of individuals but also on the development of techniques and processes that nurture communication and enable efficient exchange of information.

Think Point 6

Explain why establishing good communication between the project team and stakeholders is critical for the success of the project.

Good communication with stakeholders will help to identify requirements, better understand aspects of the project that are not clear to end-users, sort out any issues, and deal with problems in the early stages.

Project management process mapping is a technique for establishing a common understanding of a project as well as a reference point in communication among stakeholders. The project process map is a graphical representation of the project's tasks and their relationships. Such an illustration of the project's structure, main decision paths and possibly the issues relating to each process, provide a solid foundation for the project's success.

Process mapping can easily provide an understanding of the project's standing. It can be used as a snapshot that allows a reality check at any point with respect to how the project progresses in meeting its requirements. Process mapping provides not only a clear and concise method of identifying which tasks are under way but also of answering questions relating to the "actors" of each process and other features including the location, responsibility and method followed. Scheduling is also a viewpoint on project performance information that shows tasks on targets and possibly delays. The criticality of different tasks


© ABE

can also be shown in relation to any problems or issues arising and obviously a representation of the allocated resources, a reflection on their suitability and an estimation of any additional ones that may be needed.

The process mapping is based on a number of clear steps, including:

identifying processes

assigning responsibilities

defining quality standards

reviewing processes

drawing the map.

There are various techniques that can support the process mapping. A very popular approach providing support to business process mapping is the Business Process Management (BPM) approach that is discussed in more detail next. According to the Association of Business Process Management Professionals (ABPMP):

"Business Process Management (BPM) is a disciplined approach to identify, design, execute, document, monitor, control, and measure both automated and non-automated business processes to achieve consistent, targeted results consistent with an organisation's strategic goals. BPM involves the deliberate, collaborative and increasingly technology-aided definition, improvement, innovation, and management of end-to-end business processes that drive business results, create value, and enable an organisation to meet its business objectives with more agility."

A BPM framework takes under consideration a number of factors, including:

organisation

process definition

process responsibility

process sponsorship

process measures

process awareness

process alignment

information technology

methodology.

The BPM framework can be viewed as a series of phases, including:

process planning and strategy

analysis of business processes

design and modelling of business processes

process implementation

process monitoring and controlling

process refinement.


© ABE

Another established project management approach is PRINCE2 (PRojects IN Controlled Environments), a process-based method for effective project management. The approach is based on a number of key processes that can be identified as:

directing a project (DP) – dealing with initiation, staging boundaries, ad hoc direction and project closure

starting up a project (SU) – dealing with information gathering, setting up the team and creating a plan

initiating a project (IP) – considering project scope justification, establishing a management base, assessing the business case, establishing the project foundation, obtaining resources, dealing with project ownership issues, establishing decision-making practice, maintaining scheduling and resourcing management control

managing stage boundaries (MSB) – assuring project phase completion and assessment of progress, passing knowledge from previous stages to the next to maintain acceptable progress

controlling a stage (CS) – including the authority to delegate work, gathering information, managing change, reviewing and reporting on progress, as well as intervening when required

managing product delivery (MP) – agreeing allocated work, forecasting and ensuring work is done and quality criteria are met

closing a project (CP) – focusing on assessing whether requirements are met, ensuring deliverables are accepted, recommending follow-up actions and preparing end-of-project report documentation

planning (PL) – being very important for other stages such as the initiation stage, planning a project, planning a stage and producing an exception plan.

Review Questions 3

(a) There are nine main tasks that fall within the project manager's role. Try to identify six of them.

(b) List the five main steps of a project process.


SUMMARY

This chapter has introduced the idea of the project and project management concepts. The first section of the chapter discussed the transition from business objectives to project description and emphasised the role of stakeholders and organisational influences. The next section discussed the importance of feasibility studies, requirements analysis and risk management. The third section of the chapter provided an overview of project planning and a detailed description of project life cycle approaches. Finally, it concluded with a detailed review of the project manager role and project management processes.


© ABE

ANSWERS TO REVIEW QUESTIONS

Review Questions 1

(a) The five main project management phases are: scoping the project; developing the project plan; launching the plan; monitoring the project; closing the project.

(b) The 12 types are: clients; end-users; sponsor; manager; project manager; project management office; project team; operations manager; top management; resource managers; contractors; suppliers.

Review Question 2

The five main requirements are:

– identifying project stakeholders;

– capturing stakeholder needs;

– performing a needs assessment;

– performing a reality check;

– establishing an agreement.

Review Questions 3

(a) The nine main project manager tasks are:

– break down the project into phases and identify tasks under each phase;

– allocate tasks to different team members and ensure the necessary skills are present in the project team;

– ensure the necessary infrastructure is available throughout the project;

– keep track of the project tasks and avoid any slippage;

– deal with personnel management issues as well as appraisals and performance measurement;

– deal with the project budget and any financial issues;

– engage in problem solving, conflict resolution and decision-making relevant to any project activities and associated deliverables;

– report on project progress and individual performances;

– perform risk assessment and control sources of risk as well as ensure quality targets are met.

(b) The five main steps are: identifying processes; assigning responsibilities; defining quality standards; reviewing processes; drawing the map.

27

© ABE

Chapter 2

Project Analysis

Contents Page

Introduction 28

A. Hierarchical Division of Work 28

Describing Project Scope with Work Breakdown Structures 30

Dealing with Work Packages and Associated Cost Structures 33

B. Risk Assessment and Management 35

Assessing Risks and their Impacts on Projects 35

Planning Ahead and Responding to Risks 38

C. Cost Planning and Estimation 42

Budgeting for Cost and Time 43

Dealing with Cost Escalation and Contingency Planning 46

D. Dealing with Bids, Tenders and Contracts 48

Evaluating Bids and Selecting Contractors 49

Understanding the Content of Contracts to Supply 50

E. Effects of Location on Project Management 51

Managing Differences 53

Summary 55


28 Project Analysis

© ABE

INTRODUCTION

This chapter provides a detailed view of how the analysis stage of a project takes place. The aim of the chapter is to explain how this work can be divided into manageable units that can be organised according to our perspective of the project and the aim of the project management stakeholders. The analysis of a project should not be based solely on the identification of the work structures needed but also on the assessment of any associated risks. This ensures that a project proposal is based on accurate structures and follows a detailed approach in identifying different aspects affecting the negotiated resources and budget.

Objectives


justify the need for a specific undertaking (a "project") in order to achieve business goals

explain how pursuing the objectives of an organisation can lead to a project definition and a specification of requirements

justify the importance of conducting a feasibility study into a proposed project

identify the various dimensions of feasibility such as financial, technical, social, ethical, ecological and managerial

assess the levels of risk and uncertainty in a project and identify critical success factors

describe the basic project life cycle model comprising definition, planning, organising, execution and closure stages

appraise the suitability of alternative life cycle models involving phased development and prototyping

explain the diverse activities of a project manager in delivering a successful outcome, such as estimating, planning, administrating, reporting and leading

explain the importance of ensuring good communication with all stakeholders, including the project sponsor and the client.

A. HIERARCHICAL DIVISION OF WORK

Before explaining how the work in a project can be divided hierarchically, we need to become

familiar with the concept of new product development (NPD). Quite a few projects involve an element of product development and it is often the case that new products are created as the main outcome of such efforts. The process followed from the initial conceptual stages of NPD, leading all the way to the development of the deliverables which may range from goods and artefacts to services and structural elements, is described next.

Designing the process that must be followed by the project always starts from soon after its

inception. We can therefore identify concept development as the starting point for any project. Obviously this differs according to the way the projects are kick-started. For example, some inceptions are generated during stages of existing projects, while others are based on unique ideas of individual stakeholders. Harvey Maylor, in the fourth edition of his book Project Management, provides a hierarchical approach to planning outline that is illustrated in Figure 2.1. This approach involves four key elements that initiate from the inception of a project. Concept development is perceived as the source of the direction a project is intended to follow.

Project Analysis 29

© ABE

The next element is scope development. This includes the steps necessary to proceed from an initial idea to a more detailed plan of how this idea must be implemented and assessment of whether it can be aligned to the intention of the project stakeholders. The scope development stage can be viewed as an effort to specify what must be created in order to satisfy the vision of the creators of the initial concept.

The next step is to separate the two main pathways following from the detailed description of

the project scope. This means that our efforts are now split between providing the product

overview and the process overview. The product overview element offers an opportunity to obtain a holistic view of the deliverables that will be created and describes the project's output. The objective is to understand how the product satisfies the requirements of the initial concept and whether the implementation of the product is in line with the conceptual model developed in the earlier stages of the overall process. It is this process that lends itself to the final element of the outline planning since it considers the process overview. More specifically, the process followed from the development of the conceptual model and the identification and definition of the project scope to the more detailed steps of process design must be explained. The product and process overview elements help us to put together a plan of what steps must be followed in order to bring the project safely through a pathway leading to the achievement of its objectives.

Figure 2.1: Project outline planning as suggested by Harvey Maylor

The illustration of the four elements in Figure 2.1 shows how the bidirectional arrows between the different elements give us the opportunity to reflect and backtrack so we can make adjustments to earlier steps in the process. A good example is the way the scope of the project may be adjusted after finding out that the product overview has identified problems with the original ideas. The original outline planning as suggested by Harvey Maylor illustrates a hierarchical view of the four elements with concept development being on top of a three-layer structure, followed by the scope development element and eventually leading to the overview elements. The underlying idea is that the project manager may proceed from one layer to the next, eventually ending up using the overview elements to define a more detailed process design.

This suggestion can be adapted to suit those projects where due to lack of time, resources or even an entirely hierarchical structure, some direct exchange of thoughts is possible between the concept development stage and product or process overview. In small and medium enterprises the idea creators are often involved in the management of the project as well as

Concept development

Scope development

Product overview

Process overview

30 Project Analysis

© ABE

some of the implementation steps and more detailed process. In such cases changes in the original concepts or adjustments in the scope of the project are more immediate in the way they manifest in changes to the product and process overview.

Describing Project Scope with Work Breakdown Structures

The scope of the project is formulated through a series of events that involves the maturity of an initial idea and the development of the concept that triggered the project. It is important to understand that a number of factors affect the way a concept is developed. The initial idea is rarely the creation of a single mind, but rather an evolving process that offers the synthesis of several perspectives.

Therefore concept development must take under consideration a number of contributions from different sources such as:

Staff – directors and managers may be the sources of ideas, but the workforce may help formulating ideas. This may be done either through detailed processes in cases of marketing and creative departments or with reflective exercises where the organisation's capacity and resource capabilities are matched to the concept's attributes.

Competitors – usually it is the competition that drives progress, by introducing products or services that an organisation must either match or exceed with even more innovative and cost-effective solutions.

Customers – a pull-driven model means that it is the customer who actually drives change and progress by requesting specific services and products, currently unavailable. The concept creation is driven by the need to satisfy the customer requests.

Suppliers – the suppliers of the organisation who are setting the constraints within the concept must be developed. Usually the diversification of existing products may lead to new ideas and successful product development.

Research and development departments – organisations must invest in R & D departments regardless of their size. R & D departments are capable of generating new ideas, introducing new concepts and engaging in the development of new products.

All these sources of new ideas and input for concept development practice offer the opportunity for an organisation to exploit the new concept and generate new revenue streams. Some examples could include:

introducing a licensing system where the developed product or service can be used by other organisations for a licence fee

franchising models that allow the use of a specific model of operations based on a geographically dispersed business model where local partners can represent the organisation for a commission fee

selling the idea to a larger firm that may develop it to an extent the concept-developing organisation is incapable of achieving

developing a new product or service

introducing a spin-off company, offering new business opportunities.

Project Analysis 31

© ABE

Scope Planning

So far we have discussed how a hierarchical structure may help to achieve a work breakdown that will help us to implement ideas into new products. It is necessary to introduce a method for helping with the identification of what the project scope is as well as assisting with the planning and management of the scope.

In order to manage the scope of the project we must be in control of the following:

Project initiation – by being aware of how the project was created and identifying what triggered the initial idea, we will be able to understand the main aim and the more specific objectives we are trying to achieve. Unless we maintain a constant strong link to the fundamental driver for the project we may be in danger of side tracking, and follow a direction that does not serve our initial concept.

Change of scope – the initial concept may be based on a great idea, but during the development process this idea may lead us to certain obstacles that are impossible to overcome. It is not uncommon for organisations to shift their goals accordingly in order to better achieve them. This does not necessarily mean failure. Often an organisation will realise that the objectives set can be achieved more efficiently if the original scope is changed to fit new requirements.

Scope plan – planning for the project scope starts with the identification of the scope itself. Usually we see organisations and their units adopting a common vision. This is a shared goal that everyone involved with the project should always keep in mind. The vision is likely to affect the creation of their concepts as well as the pathways followed when these concepts are further developed. A mission statement may also be present, providing a set of values, beliefs and perhaps guidance for practice while preparing project deliverables and being involved with project operations.

Think Point 1

Assuming you are in charge of a web development project, describe how you would control the project scope. You should discuss each stage – project initiation, change of scope and scope plan – with specific examples relating to the web development tasks.

Scope planning efforts should be further analysed according to the three main dimensions just described.

Starting from the project initiation, there are a number of issues we need to consider. First,

the identification of a number of constraints is likely to help us setting a realistic project scope, which can be achieved within the available project resources. Second, certain

assumptions must be made for a number of issues relating to the project. Such assumptions could include the way the project deliverables are likely to be used, the real customer requirements, the operations that may be included in the project, or even the stakeholders involved and the form the project deliverables will have. The third issue to be

addressed is the selection process that involves decision-making for a number of areas including workforce deployed, resources needed, structure of operations, management style,

etc. Finally the initiation activities should be concluded with the design of a strategic plan that offers a mapping of available resources to the identified objectives in an effort to work towards the required project deliverables.

Having completed all necessary steps for the project initiation we are now ready to move on with the project operations and assess whether the project is running smoothly or is likely to attract unexpected difficulties. There are two main factors that project managers should be

concerned with at this stage. First, change management is essential to ensure that the

32 Project Analysis

© ABE

project may alter its course of action and so be capable of adaptation to new settings and a changing environment. Being able to control the way the project operations change or how project stakeholders are affected by new requirements or different customer needs is a key

factor for successful project management. Second, performance management provides the means for monitoring how the project performs against a number of indicators. Performance management is commonly used by human resources departments but is also used in operations. On one hand performance monitoring may help us to identify issues such as employees who cannot perform as required, lack of available resources, the need for specialised skills and perhaps additional training and continuous professional development. On the other hand, performance recording could identify certain operations that are inefficient, support the understanding of why certain tasks do not meet the standards set or even help with the restructuring of work to increase the effectiveness of the deployed resources.

Scope planning consists of a number of steps, building on the initiation of the project. The preparation of a scope statement is in line with the provision of mission statements. The main difference is that the scope statement provides a detailed description of what is to be achieved with the project deliverables. Furthermore, the scope must be defined in terms of a checklist that can be used to assess whether the project scope is achieved. We will have a more detailed discussion on scope definition and work breakdown structures (WBS) next. It is necessary for a successful project to have its scope accepted by its stakeholders, as it is necessary for everyone involved to believe in the project deliverables.

Scope Definition

The scope definition process can be described as a number of steps that can form a checklist for project managers. In their book, Project Management: The Managerial Process (2010), Gray and Larson provide such a checklist. The project scope is defined as the expectations of project managers for the project deliverables. In other words, the project scope is what the project manager expects to offer to the project's stakeholders when the project is completed successfully.

The scope definition may have several forms depending on the approach we are using. The following checklist is indicative, but in general a checklist may include additional items depending on the project's structure and the need that triggered the initial concept. The project scope checklist includes:

Objectives – these should offer a full understanding of what is expected and how the project satisfies the needs of stakeholders. The objectives may be described in terms of achieving certain tasks or meeting identified needs. Project objectives may also include aims for the project duration, cost and resources used.

Deliverables – these describe the form of the project outcomes. Deliverables can have different forms ranging from software applications and reports to artefacts and integrated solutions.

Milestones – these help with scheduling the project as they identify significant events in the project life cycle, events that are expected to occur at specific points in time. Usually milestones are used to reflect on project progress or to initiate a project phase or key step.

Technical requirements – these offer a detailed view of how certain goods and services are expected to adhere to existing standards. Examples of technical requirements might be acceptable ranges of voltage and frequency, or indications of what an acceptable performance for services is.

Limitations and exclusions – the constraints for the project can be viewed as limits and exclusions. The project limitations may be associated with the resources available or even acceptable costs and budget items. The project also has a defined set of potential deliverables and aspects that are not part of the project deliverables, and

Project Analysis 33

© ABE

these form the project exclusions. These are features that, while attractive to customers, may not be feasible to achieve, and so they are not included in the project outcomes.

Reviews – these offer a reflection on how the project achieves its interim objectives and quite often involve various stakeholders, including customers. The aim is to have a reality check before the project enters further stages.

Dealing with Work Packages and Associated Cost Structures

A project manager must be able to view a project from several viewpoints. Each project must be defined in terms of three key features:

scope

cost

time.

Scope has already been defined in detail and describes the project performance towards its objectives. The cost and time are two concepts associated with the project budget and schedule. These three issues usually require project managers to juggle and prioritise according to the project's overall performance. Depending on the nature of the project it could be argued that cost and time sacrifices may be perceived as easier to accept as opposed to significant changes of the project's scope. Usually a significant change in the project's scope would imply major concerns and problems associated with the initial concept, as well as the problems of acceptance of the project's deliverables by customers and stakeholders.

Being able to deal with the work included in a project, and more specifically units of work that are usually referred to as work packages, is one of the responsibilities of the project manager. One of the key project management concerns is getting the prioritisation of the project issues right. This is closely related to quality issues for each project. For example, a project that has its scope changed a few times may end up addressing needs that are not exactly what the customers require. This leads to a project of poor quality. Similarly, high quality may not be achieved when cost and time sacrifices affect the project's performance.

Project managers have three options in their prioritisation of the project scope, cost and time. First, these three criteria can be viewed as constraints, meaning that the original decision for each of the criteria must not be changed throughout the project. This means that we have to comply with strict deadlines, rigid budgets and a scope that accepts no changes. Second, the criteria may be open for enhancement, meaning that if opportunity arises each of the three criteria might be adjusted to add value to the project. This could be translated in the reduction of costs, the addition of more resources to certain project tasks or even the revision of the project objectives and deliverables. The third option is acceptance of the three criteria, meaning that the originally identified scope, cost and time parameters can be viewed as rather loose with the possibility of revising them to fit the project's life cycle.

Project managers can use these concepts in their efforts to control the project's performance, budget and schedule. A typical technique is to prioritise the key project criteria of success by

using a project priority matrix. Such a matrix would take the form of a three by three table that can be used to check which criteria can be prioritised as a constraint, an enhancement or an acceptance.

So far we have discussed the project scope and the way the project's deliverables fit in the overall scope. We need to explain further how the project scope and deliverables are associated with the project's operation by explaining the concept of work packages.

Creating a WBS

34 Project Analysis

© ABE

As mentioned earlier, a project manager may use a work breakdown structure (WBS) to assess the project's performance at various stages. Creating a WBS involves a number of concepts:

Project – this is the complete project that starts with the initial concept and ends with the deployment of the project deliverables and the customers' sign off.

Deliverable – this means a major deliverable that may have several forms depending on the project's scope.

Sub-deliverable – this is a supporting deliverable that together with a number of similar sub-deliverables is required for a major project output.

Lowest sub-deliverable – this is the lowest unit of responsibility in the project and can be used for splitting project operations as well as mapping out the responsibilities of each employee involved with the project operations.

Cost account – this is a tool used for performance management, when work packages are grouped together to assign responsibility and measure performance indicators.

Work package – this is an identified unit of work such as a set of tasks that defines what is required and how it can be achieved with the available resources.

For example, suppose we are dealing with a project that will deliver an online shopping website to the customer. We can identify the WBS concepts as follows:

The project is the entire website, including all required functions and usability aspects.

Project deliverables may include the interface used by the customers, a database including the product catalogue and a maintenance manual to be used by the website administrator.

Sub-deliverables could be identified for each of the main functions, such as creating a shopping cart, a registration page and a secure banking function for the online shopping functionality offered to the visitors of the website.

Lowest sub-deliverables could be identified as specific interface items, code for the shopping transactions and the secure mechanism to accept electronic payments.

Cost account can be used to assess the progress achieved for the user interface, by identifying the efforts and results on interface design, ease of use and clarity of navigation.

Work packages can be identified as a number of tasks to be achieved, such as shopping cart, registration form, product catalogue, confirmation page, etc.

The work package can be further defined by the following:

Defining the work required for a specific task. This may include a series of actions, performance of an operation and on certain occasions the development of a sub-deliverable.

Identifying the time needed for each work package and any deadlines for the outputs generated.

Identifying the cost associated with the tasks included in the work package. Such costs may include resources, salaries, equipment, etc.

Identifying the resources required for each work package and justifying their role for the successful completion of the work package.

Identifying of the responsibility of holders for work units, leading to a map of roles for each work package and associated tasks. An example would be the role holder with any supporting roles that may help with specific tasks.

Project Analysis 35

© ABE

Identifying performance criteria and progress monitoring measures for each work package that may be used at certain interim stages or even as an overall set of performance criteria when the work package is delivered.

Think Point 2

For a project that is concerned with the development of a sales department in a new location, identify three work packages and define them in terms of the associated tasks, cost, time, resources, etc.

Review Questions 1

(a) List the five usual sources for ideas leading to the concept initiation for a project as well as the project scope.

(b) Name the six main elements included in a project scope checklist.

(c) Identify the six key concepts involved in the creation of a work breakdown structure.


B. RISK ASSESSMENT AND MANAGEMENT

It is essential for project managers to be aware of the main risks associated with the entire project. It is also very useful for a project manager to be able to associate certain risks with specific work packages and tasks. Assessing a project's risk means that the project manager may adjust certain decisions and ensure that the project quality criteria are prioritised accordingly. The management of risks implies that project managers are capable of dealing with change and how its effects alter the way a project is controlled.

We can appreciate the role of risk in a project's life cycle by using risk event graphs or similar risk illustration methods. Such a graph would show the fluctuation of costs associated with specific risks throughout the project's duration. It is expected that the chances of risks presenting themselves for any project are quite high at early stages of the project. This happens because early stages of each project are usually associated with several unknown factors and unquantifiable sources of risk. Gradually the chance of such risks is reduced proportionally as time passes, and eventually it becomes quite low. It should be noted that the chance of a risk occurring is never eliminated as a project manager cannot guarantee that all risks are catered for. The second variable that may be illustrated in a risk event graph is the way costs for fixing risk occurrences change over time. Initially the cost for fixing a risk presence for a project is quite low. This is understandable, as in the early stage of the project if something goes wrong we do not need to change much. However as we progress along the project's lifeline, risks and their effects may generate more damage and become more expensive to rectify.

Assessing Risks and their Impacts on Projects

A risk associated with a project can be defined as the possibility of something happening that will lead to a loss or damage for the project. The notion of risk is associated with the practice of risk taking. This is a common practice that project managers see as a necessity for each

36 Project Analysis

© ABE

project. There is the need for a trade-off between the increases of the project's risk in order to improve the indicators of some quality criteria discussed previously in this chapter. This means that reducing costs and using fewer resources is likely to increase the risk of the work schedule not being met.

Project Risk Management

The project risk management process can be described as a series of steps that the project manager must go through iteratively. This means that at certain points the project manager may revisit each one of these steps and assess whether the risks initially identified are still causes for concern. Each time a step is revisited more risks are likely to be identified. The steps involved are:

Risk identification – this step involves the analysis of the entire project and a refinement of each work package in such a way that a detailed list of known risks associated with each project stage is generated.

Risk assessment – this step is using the list of known risks from the previous step and assessing the chance of each happening. There are a number of variables that must be taken into consideration during this assessment. First, the likelihood of the risk happening must be estimated for each identified source of risk. This means that we have to prioritise each risk in terms of its likelihood of occurrence. An example of this is injury or death of key personnel, a factor that is directly affected by the nature of work. At this stage it is important to identify any factors that may be affecting the likelihood for each risk. Second, the severity of impact for each risk must be identified and each effect must be explained in detail. How difficult it will be for the project to survive the risk presence must be clear and it should be described in terms of possible pathways and corrective actions. For example, the loss of key personnel who may have decided to leave the project for a better job at another employer is quite critical towards the end phases of the project. Third, the controllability of the risk and its effects is often associated with the existence of a contingency plan. Project managers should be able to cope with the occurrence of identified risks. For example, a significant change in user requirements could be dealt with by a prompt revision of required resources and skills for a number of project work packages. A risk assessment report with a detailed analysis of the three risk assessment factors is produced when this step is completed. It is possible for further risks to be identified while the analysis takes place.

Risk response development – this step is concerned with two possible approaches. One approach is that the project manager must think proactively and establish a preventative risk response methodology. In other words, the project manager must have a clear strategy to reduce the damage of any risk occurrences. The second approach, a rather corrective one in risk response development, finds the project manager dealing with the development of contingency plans and establishing ways for dealing with crisis. Such practices are further discussed in the following section on risk management planning. This step produces a detailed risk management plan and possibly helps in the identification of further risks.

Risk response control – the final step includes the implementation of a risk strategy that supports the way a project manager and project officers deal with occurrences of specific risk events. The risk strategy is structured in such a way that it forms an organised method for selecting which actions are more suitable for different risks and for how decisions should be made in the event of a risk event taking place. The monitoring of the project's performance is a continuous process that is an essential part of the risk response control step. Once a risk event is observed the risk management strategy is implemented and the project plan is adjusted accordingly. The project manager's perspective on change management is an integral part of risk response control. This is because it dictates how much change will be allowed in the project, even in cases where a risk provides a significant cause for concern and alters the

Project Analysis 37

© ABE

project environment dramatically. Even at this late step in the overall process, it is possible to identify further risks for the project.

Risk Management Planning

The risk management plan prepared by the project manager is quite often customised as each project has its own unique characteristics and environment. A risk management plan could be based on the development of realistic scenarios and their analysis. But it could be argued that the establishment of realistic scenarios may prove a hit-and-miss technique, as it is difficult to identify all possible scenarios. There are two main difficulties with this technique. On one hand we are not sure whether the scenarios we have identified and described in detail may prove sufficient to identify and anticipate risks. On the other hand it is unlikely that the project resources will enable us to identify every single scenario for our project.

The project scope definition and the project's description in the form of WBS offer sufficient detail for the creation of a main project description in terms of its deliverables. The way these deliverables are used provides what is needed for the development of several scenarios.

The next step is to analyse each scenario in terms of project risks. Each scenario is broken down into a series of steps. Each step is then reviewed in terms of possible risks and a list of those risks posing a threat for the specific step is identified. Each risk is then assessed in terms of:

a detailed description of the risk, its cause and the way it presents itself in an occurring event

a list of effects caused by the risk event to the project and a specific reference to the task, operation, process, deliverable or output being affected

an estimation of the risk event impact and a possible measurement of the severity to the project in general as well as to specific aspects of the project

an estimation of the likelihood for the risk event happening and a report on those factors affecting this likelihood

an assumption of the timing for a risk event and an analysis of the project's timeline to identify possible time-stamps for risk occurrences

an association of risks with resources used elsewhere and an identification of events that may be caused as a knock-on effect of risk occurring in other projects.

Think Point 3

Assess several risks associated with a project that deals with the expansion of a restaurant chain to a new city with three new restaurants being added to the existing fifteen venues. The risk assessment of the project should include a description of the risks, impact, likelihood, assumptions and links to other projects.

Risk Identification

There are no set ways for identifying project risks, and it is difficult if not impossible to provide specific guidelines of how to identify causes of concern. It is quite often the case that project managers follow ad hoc procedures that have worked in the past, adjusting certain aspects based on the special features of the project at hand. A very helpful technique is to attempt a risk profile by tracking a project one work package at a time. We can then identify aspects of risk profiling and describe each risk in a detailed way. Risk profiling is not based on specific sources of risk as these are not consistent for all identified risks. It is more likely to attempt a risk profile by identifying the possible sources of risk.

38 Project Analysis

© ABE

One of the main areas of project risks relates to costs and budgeting. For example, cost estimation may not be accurate or economic changes or social instability may affect the way the project budget is structured.

Scheduling of the project is almost always an area of concern as the timing, deadline and workloads may be inaccurate. The estimation of work required for each work package may be false and additional requirements or task difficulties may lead to extensive revisions of the project schedule.

Quality standards and performance management may lead the project to an adjusted scope and even a revised plan. The risks associated with quality are very important as a failure to meet standards late in the project may lead to complete failure of the project.

There are certain risks associated with the processes followed in the project's life cycle. For example, training and induction tasks may prove inadequate and skill-building professional development tasks may require more time and resources. The analysis, design and development of deliverables may run into problems that require more time and costs. Testing, evaluation and deployment are always sources of nasty surprises for project managers.

Additional risk causes may include staffing and other resources which may differ from the original estimations. External changes to the project environment may affect the way the project operations are controlled. Customer requirements may change either due to the presence of a competitor, lack of understanding, timing of products and services or even external factors such as industry trends and the economic situation of the local market.

Planning Ahead and Responding to Risks

A successful project manager is one who is capable of following a detailed risk management plan. As mentioned earlier, such a risk management plan is based on the identification of the project risks. Initially the project manager must be aware of all external and internal sources of project risks. The next step is to become familiar with risk indicators and any symptoms that would help the early recognition of a risk event. Another approach is making assumptions for time and cost estimations associated with project operations and work

packages. Furthermore, an analysis of the total cost of quality (TCQ) (the total of costs arising from poor quality or product failure) provides useful information for further sources of risks that may appear after quality trade-offs (and obviously the likelihood of those risks).

Responding to risks implies that a response control strategy is in place. This requires the project manager to identify opportunities and threats for the project. Opportunities should offer themselves for increasing the project's success and reducing the requirements on resources, time and costs. These opportunities are balanced with threats, either due to internal or external factors, to the project outcome. Opportunities and threats analysis as well as identifying the strengths and weakness of the project are likely to help project managers to identify ways to respond when an opportunity or threat appears. Corrective actions are expected when a project reaches a risk event. Such actions are likely to be part of a contingency plan which is often based on the use of back-up resources.

Finally the quantification of risks and their likelihood is very useful for risk management and control. Estimating the likelihood of a risk could be based on either a qualitative or a quantitative risk analysis. Whichever method is followed, the estimation of the risk effects and the effort required to deal with them requires the attention of the project manager.

Qualitative Risk Analysis

A typical approach for risk analysis is to gather information from various project stakeholders. This leads to a qualitative analysis, in order to understand risks and establish a risk management plan.

As mentioned earlier, risks are assessed in terms of their likelihood and impact on the project. A qualitative approach could be based on identifying from project stakeholders a list

http://www.businessdictionary.com/definition/costs.html

http://www.businessdictionary.com/definition/quality.html

http://www.businessdictionary.com/definition/product.html

http://www.businessdictionary.com/definition/failure.html

Project Analysis 39

© ABE

of risks. These are then assigned certain values to their probability of occurrence and their severity for the project's operations. An example of such a technique would be to create a matrix that would help to identify risks and classify them according to their likelihood and impact as shown in Figure 2.2. This illustrates how risks can be classified accordingly and helps identify clusters of risks with similar impact and probability values.

Figure 2.2: Probability-impact graph

Think Point 4

For a project dealing with the change of name and packaging of an energising drink, use the probability-impact graph to identify certain risks. The identified risks should be classified according to the probability and severity as estimated.

A more advanced technique is to provide a failure mode effect analysis (FMEA). This approach takes into consideration the likelihood and severity values of certain risks in a similar way to that just described. However a third notion – "hideability" – is introduced: this describes the possibility for a certain risk that may be present at a project operation, work package, stakeholder group or stage and remain hidden from the project manager. The possibility that a risk might be hidden is a very important factor to take into consideration, as the impact of any risk becomes significantly higher when a project manager cannot prepare for it.

The FMEA method is based on calculating the risk priority number (RPN) for each risk by multiplying the values of the three concepts expressed as integer numbers. Therefore the RPN for each risk is a number that helps us prioritise each risk, calculated as follows:

RPN = severity hideability likelihood

By expressing each concept as a number between 1 and 10, we may have a minimum RPN of 1 and maximum RPN of 1000. It is obvious that the qualitative nature of this method

High

Medium

Low

Probability

Severity

Low Medium High

Retirement

Death

Redeployment

Government change

40 Project Analysis

© ABE

relates to the fact that the values given to the three concepts are based on data gathering taking place between stakeholders, and include a certain level of estimation (based on certain assumptions) from the project manager.

Quantitative Risk Analysis

Quantitative methods in risk analysis are quite useful when we need to provide a mathematical approach in identifying and assessing risks. Some quantitative methods include:

Expected value – an expected value can be assigned to any event, including risk events, providing an estimation of the impact that the event will have on the project in terms of monetary values. It can be calculated by multiplying a percentage representing the probability of an event occurring with the value of this event. For example, the expected value of a project takeover that would cost an additional £50,000 and has a 50 per cent chance of happening is £25,000. This expected value would be the same as the replacement of the managing director which would cost £2,500,000 but has a one per cent chance of happening.

Sensitivity analysis – this technique is based on calculating three values for each entry in the project's budget, in order to take into account possible opportunities and threats. Therefore when calculating the cost of workforce, overheads and raw materials for a project we provide three entries for the budget. The main entry is the expected value for each budget item. This is used as an expected cost as indicated by the project manager. The other two values for each item represent an estimation for worse and best case scenarios. In other words, these two values offer a range for the minimum and maximum values a budget item may fluctuate within before creating a crisis to the project. The two values are calculated based on the expected value with an adjustment of n per cent. The value of n depends on the range of values we aim for. It is quite common for project managers to calculate these values based on (plus or minus) five per cent to (plus or minus) ten per cent.

Monte Carlo simulation – this is a mathematical technique that uses computer processing to calculate risk in decision-making and risk analysis. The simulation is used in order to provide a range of possible outcomes for the project with the probability for each outcome to occur based on certain actions. Monte Carlo simulation

is based on the probability distribution concept that represents a range of values for a known risk. By recalculating each possible combination of the value range (representing the cost/income) for several identified risks we may create several scenarios of how our actions may affect the project's outcome.

Programme evaluation and review technique (PERT) – this provides a useful tool to help in understanding any alterations to a project's original schedule. The technique offers a method for calculating the time required for project activities and is based on providing three time estimates for each activity concerned. Therefore each activity is described in terms of (i) an optimistic time showing how long it would take for an activity if everything runs smoothly, (ii) a most probable time showing the time the activity takes under a normal scenario and (iii) the pessimistic time showing the time required for the activity if a number of risk events occur. The three values help the project manager to identify expected times for each one of the project activities.

Risk Response Planning

As part of the risk response plan, the project manager must be able to identify what is expected by the project and identify the project outcome in terms of certain measurable features. The next step is to identify best and worst case scenarios in order to establish a series of actions that must form the contingency plan if risk events take place.

A risk response plan involves two very important concepts, those of risk transfer and risk

acceptance. Risk transfer is the approach followed by a project manager when the risk

Project Analysis 41

© ABE

management strategy is outsourced to another organisation capable of dealing with the project risks and their impact. However it is possible that an organisation might prefer being in control and avoid transferring the control along with the risks of the project to an external party. In such cases, risk acceptance means that the project manager is prepared for certain risk events to take place, prioritises their impact and likelihood and has in place a series of contingency plan. In addition, there are two approaches that provide a more defensive

approach: risk avoidance and mitigation. With risk avoidance a project manager is prepared to drop a task or an entire work package and associated deliverables in order to avoid even the presence of the source of a specific risk. On the other hand, a less drastic approach (i.e. mitigation) resorts to minimising the probability of a certain risk event taking place.

Risk Monitoring and Control

The two main approaches in risk monitoring and control are establishing a risk register and

a risk log. A risk monitoring approach means that the project manager makes sure that the possible risks are monitored continuously even if certain aspects of the project meant that specific risks may be avoided.

A risk register uses the methods previously discussed to identify each risk and describe it in detail in terms of its likelihood, source, effects, impact, symptoms, etc. The risk register can be used to trigger a response plan that may be in place. On the other hand, the risk log offers a diary for project managers to record possible risk events and their occurrence. Following a risk log entry, the project manager can record the response event and how any corrective actions that followed have performed.

There are several monitoring and control tools, including:

Work breakdown structures – as mentioned earlier a WBS offers a hierarchical view of tasks and helps identify problems with specific work packages.

Estimated and actual project budgets – helps identify risks associated with incorrect budgeting and lack of sufficient resources.

Project schedules – offers a reflection on the project progress and is likely to identify symptoms such as delays, overlapping, under-resourcing and over-resourcing.

Earned value of project activities – provides a detailed overview of the way each project activity adds up to the total project value. Further analysis may offer insights of what happens when corrective actions are not taken immediately, reducing the earned value for certain work packages.

Project resource list – provides a detailed list of all resource items made available to the project.

Project plan – helps establish whether the project scope is maintained at various points of the project timeline.

Change control log – a tool for logging any changes and alterations that have taken place, usually due to the occurrence of a risk event.

A risk control process is likely to benefit the project in a number of ways. It offers awareness of the project's progress and status to the project manager as it provides a progress snapshot at given times. It supports the documentation and monitoring of any corrective actions taken. It helps with the establishment of a risk management plan that deals with risks as they appear.

A risk control process makes sure that any actions are recorded in such a way that their impact on project costs reflects on an updated budget. Similarly, the risk control process ensures that project schedules are updated accordingly once a risk event affects a portion of the project operations and activities. The documentation of the risk log helps to disseminate

42 Project Analysis

© ABE

the impact of any risk, the effects to the project and a reflection on how the response provided ensured project continuity.

Review Questions 2

(a) Identify the four main project risk management steps.

(b) Name the four main quantitative risk analysis methods.

(c) Identify the seven most common monitoring and control tools that can be used in risk assessment.


C. COST PLANNING AND ESTIMATION

A very important aspect of project management is providing cost estimates and planning for the costs of the project activities. Previously in this chapter we briefly discussed a number of techniques used for cost estimation and activity planning. It is important to remember that most times the project plan cannot be based on completely accurate estimates as a number of factors may affect the time and cost of each activity.

It is necessary for project managers to be able to break down projects into tasks and estimate the workload associated with each one of these identified tasks. Each project activity may vary in terms of its duration. There are certain factors affecting activity duration and depending on how these factors are addressed in a project, the original estimations may prove accurate or show a dramatic increase or decrease on required time.

We can identify some causes for varying activity duration as follows:

Skills – the lack of a consistent set of skills in the project's workforce means that the same task may be achieved at different times when different people are in charge of it. The skill variation can be dealt with through continuous training, but individuals will still show different capabilities and adaptation to newly acquired skills.

Events – the risks identified in previous sections may present themselves in a variety of events, affecting the way activities are undertaken and perhaps providing additional time overheads.

Efficiency – the efficiency of an activity can also be measured in terms of the time and cost associated with the way an employee undertakes his or her role. Interruptions, obstacles and external factors affecting one's attention, focus and performance may be part of the reasons for a less than optimal work pattern.

Errors – mistakes that can be caused by individuals, teams or errors on decision-making and problem solving might also cause activities to fall back. Project managers may also cause some delays if they make wrong decisions when dealing with the project work packages as well as managing the overall process.

Random variations – project activities are calculated in terms of cost and time based on assumptions and individual estimations. The mathematical models and techniques that attempt to quantify each activity will never be capable of an exact match. One of the reasons is the lack of a harmonic and homogeneous approach on establishing the exact duration of each project activity. Eventually even minor variations will exist when we attempt to calculate the duration of a project task.

Project Analysis 43

© ABE

Think Point 5

Explain why two teams that deal with similar projects in construction show significant variation in the duration of key activities. You should identify a number of activities and explain how and why their duration may vary significantly. Your discussion should focus on skills, efficiency, errors, etc.

Budgeting for Cost and Time

When budgeting for cost and time, project managers may be affected by a number of factors depending on the setting and environment of the project. One of the most important aspects

we need to take under consideration is the planning horizon as it definitely affects the accuracy of estimates. It is quite different to assess the cost of an activity that is expected to

take place in a week, compared to one that is six months ahead. The duration of the project is also important as sometimes even the technology used may change before the project is completed. This is a factor we need to consider when dealing with long-term projects. The

human element is an essential feature of cost and time estimation, as we are not always sure whether we will allocate roles correctly and if the team put together is capable of providing an optimum solution. A team that falls apart, or dealing with conflict and interpersonal relationships are examples of why cost estimations may be revised after the

project initiation. The structure of the project may lead to several teams working together and a rather complex set of interrelated activities. The domino effect created in such projects may lead to spiralling costs if the estimation for a particular work package is wrong. The

estimate padding phenomenon describes the practice of adjusting estimates to fit the project requirements and perhaps the context of a project activity. In other words a project manager may provide either an average estimate or a more optimistic or pessimistic value

according to what impression must be made. The corporate culture notion is discussed later in this chapter, but it is an important aspect of project management as it dictates how the cost estimation is based on average values or allows a range to be used.

Project Procurement Management

As mentioned in Chapter 1, the Project Management Institute (PMI) has produced the Project Management Body of Knowledge (PMBOK), a collection of processes and knowledge areas accepted widely in the field. It has for years been recognised as a standard and describes five basic process groups and nine knowledge areas in the project management field.

The five project management processes are:

1. initiating

2. planning

3. executing

4. monitoring and controlling

5. closing.

The nine knowledge areas are:

1. project integration management

2. project scope management

3. project time management

4. project cost management

5. project quality management

44 Project Analysis

© ABE

6. project human resource management

7. project communications management

8. project risk management

9. project procurement management.

Each of the project management processes are described in terms of: (i) inputs that may include documents and designs; (ii) tools and techniques that are used to process the inputs; and (iii) outputs that can be in the form of documents and deliverables. Each one of the nine knowledge areas includes several project management processes.

The project procurement management knowledge area includes the following topics that are further discussed next:

procurement planning

solicitation planning

solicitation

source selection

contract administration

contract closeout.

The project procurement management process assists managers in obtaining resources from external suppliers. The process includes tasks such as ordering, receiving, reviewing and approving items from suppliers. The process is used to identify and obtain items required as well as establishing an effective relationship with suppliers. Some of the benefits of the procurement process can be identified as:

identifying goods and services to procure

creating and issuing orders to suppliers

confirming delivery methods and timings

receiving ordered goods and services

reviewing and accepting items ordered

approving payments and settlements with suppliers

constructing supplier contracts

assessing supplier performance and impact

resolving any issues with suppliers

monitoring project procurement status.

In summary, we could define the project procurement management process as a series of steps dealing with: (i) the identification and ordering of resources required by the project; (ii) the creation of supplier contracts and the management of contractual obligations and expectations; (iii) the administration of any contract issues; and (iv) the maintenance of the relationship with suppliers.

Procurement management is also covered by the body of knowledge published by the Association for Project Management (APM).

Plan Purchases and Acquisitions

The process of planning purchases and acquisitions deals with planning the resources that are required for the project and determining how to obtain them. There are specific inputs required for the plan purchases and acquisitions process. These inputs can be identified as follows:

Project Analysis 45

© ABE

Enterprise environmental factors – meaning that the state of the local market is likely to affect the availability and the cost of the required resources

Organisational process assets – meaning the policies and procedures in place that may be constraining the way procurement decisions are made

Project scope statement – meaning that the project scope, boundaries and assumptions may affect the timeframes and budget specified for resources required

Work breakdown structure – meaning the relationship between project tasks and the association between resources used in related tasks

WBS dictionary – meaning the specification of the work required as part of each deliverable and the identification of each deliverable

Project management plan – meaning that the overall project management plan is likely to include details such as a contract management plan and a procurement management plan.

The details included in project management plans help assessing the procurement needs of the project. Planning outputs that may affect the identification of resources to be procured may include: (i) risk register; (ii) risk-related contractual agreements; (iii) activity resource requirements; (iv) project schedule; (v) activity cost estimates; (vi) project schedule; (vii) activity resource requirements; and (viii) cost baseline.

There are a number of tools that may be used in plan purchases and acquisitions. These tools include the following:

The make-or-buy analysis technique allows project managers to make informed decisions about resources required and more specifically whether the project should invest in producing the needed items or seek them externally. A buy decision is likely to trigger a call for proposals, include a selection stage and the definition of contract to supply details.

The expert judgment technique seeks advice from experts when confirming the specification of required resources as well as sourcing the goods and service needed from external source.

Contract types are the tools used for establishing supplier contracts and may lead either to: (i) fixed price contracts that are based on establishing a fixed price for a well-defined product; or (ii) cost reimbursable contracts that deal with the payment of the actual supplier costs with an added profit. The cost reimbursable contracts may be in the form of: (i) cost-plus-fee (CPF), (ii) cost-plus-percentage of cost (CPPC), (iii) cost-plus-fixed-fee (CPFF) and (iv) cost-plus-incentive fee (CPIF).

The output of the entire process is in the form of the following:

The procurement management plan which may include the type of contract to be used, the cost estimation for goods and services, the creation of procurement documentation, selection process, negotiation of contracts, etc.

The contract statement of work in the form of a statement of work (SOW) that describes what must be supplied, including any constrains, rules, timeframes, etc.

Make-or-buy decisions in the form of documentation that includes any identified risks and an estimation of the actual costs of both type of decisions available. The documentation is needed to justify the final decision made.

Requested changes are a set of changes made to the project plan following an estimation of the cost and time required for the supplied goods.

46 Project Analysis

© ABE

Think Point 6

Explain how a contract statement for work on the installation of a lift in a new building development may trigger negotiation between the project manager and suppliers. The discussion should be focused on how the suppliers and the project manager are likely to negotiate the specification of goods, support services and other features of the required resources.

Dealing with Cost Escalation and Contingency Planning

The project manager must be capable of making well-informed decisions on how the project phases are associated with costs and time requirements. The process of creating cost, time and resource estimations is critical for the project as any mistakes made are likely to cause escalation of costs. The project manager must also have a contingency plan in place, ready for deployment if the initial estimation proves false.

A typical approach in providing such estimates is arrived at by reviewing the project work packages with a number of criteria in mind. The estimation of work packages should take under consideration the following:

Assuming responsibility – work package estimations should be made either by the project manager or after consultation with project stakeholders who are knowledgeable in the field and capable of understanding what the work package entails in terms of work and resources required.

Obtaining several perspectives – any estimations should be reached after the work packages are reviewed by several stakeholders having different roles in order to obtain a 360-degree feedback on what is needed for the specific work packages.

Estimating for normal conditions – the estimations provided should be for normal conditions as far as the project setting, its environment and resource availability are concerned.

Defining time units – from the early stages, the project should be structured based on agreed time units that best reflect how the work packages and tasks associated with deliverables can be structured. When using a suitable time unit, the project schedule can be easily structured and revised.

Maintaining project independence – since the project may be associated with other projects and receive input from external sources it is necessary to attempt maintaining a relevant independence of the estimations. By achieving this it may be possible to avoid any future changes due to uncertainties caused by links to external sources.

Preparing contingency plans – the estimation of any costs should take into consideration the effects of change, the possibility of the situation being far from the assumed norm and other project surprises. The cost of any contingency plans should also be considered.

Including risk assessment – the cost of identified risks that may be estimated following the techniques we discussed earlier in the chapter should be included when the overall project cost estimation is prepared.

Determining the Project Budget

The project budget is the estimation of the total costs associated with all the project activities. This estimation of monetary resources is important for project managers – they need to establish whether the project operates within the acceptable financial limitations established by the stakeholders.

Project Analysis 47

© ABE

The determination of the project budget requires the project manager to consolidate all separate estimations into a single document. The aim is to establish a holistic understanding of all identified costs that may be incurred throughout the project. This is achieved by following a number of steps which encompass the following:

WBS decomposition – this will help identify every single task of the project and therefore evaluate all costs associated with the entire project

historical data – this step reviews previous budgets from similar projects and uses the findings as a foundation for establishing the final budget

lessons learned – this is based on key findings from previous experiences and such lessons may be learned by the project manager, the project team, other stakeholders or the organisation at large

resource profiling – this means collecting information for various resource items as well as any procurement details that contribute towards the overall project costs

project policies – this step offers the framework within which the budget calculation may be drawn, including any constraints the project may have.

The determination of the project budget uses the following as input:

activity cost estimates that calculate the cost of every single work package

basis of estimates that clarifies how decisions are made for the inclusion or exclusion of costs

scope baseline that splits the project in specific work packages and associated cost units

project schedule including deadlines, time plan and timeframes for activities

procurement contracts that identify the costs associated with the provision of goods and services from suppliers

resource calendars that specify the timeframe for resource provision as well as the allocation of tasks within each work package.

This budgeting effort provides three main outputs:

a cost performance baseline that offers a budget that can be used to assess the project performance at specific intervals

project funding requirements including the overall funding required as well as all identified costs

project document updates such as schedules and risk registers that may be affected by the finalised budget.

Review Questions 3

(a) List the nine project management knowledge areas described in PMBOK.

(b) Identify the two contract types which can be used for plan purchases and acquisitions.


48 Project Analysis

© ABE

D. DEALING WITH BIDS, TENDERS AND CONTRACTS

Project managers must create a product breakdown structure (PBS) similar to the WBS produced during project planning. The aim for producing the PBS is to identify the requirements for materials, goods and services needed throughout the project. The project manager must be capable of dealing with a number of tasks, such as:

traditional purchasing

materials management

supply chain management.

Certain project phases require a traditional, old-fashioned purchasing order for materials based on what resources the project tasks need. This is relatively straightforward and requires the invitation to tender and the acceptance of bids, followed by selection and preparation of contracts. The way materials are managed implies that the project manager is in control of the timeframe used for the supply of goods in such a manner that the project schedule is not affected and there are no resources remaining idle. It also implies that delays occur due to the inability of suppliers to produce what is needed.

When the resources required are composite a more advanced way of organising suppliers takes place through a supply chain. An example of this could be when computer systems are delivered, where suppliers may include hardware and software developing firms. It is likely that another firm will also be involved, to integrate the hardware and software components into a fully working system. So in this example there are three tiers prior to the organisation receiving the computer systems, with the hardware supplier, software supplier and integration contractor being lined up before the finished goods are dispatched. Similarly the output of a project may reach intermediaries such as distributors or sales departments before reaching the end-users. Being able to manage this supply chain requires a critical set of skills that every project manager should possess.

We can identify a number of steps that can be followed for a typical purchasing process. These steps may vary between projects but are required to establish a solid process that can be used for the main orders of goods and services for each project. These include:

approving purchasing stakeholders – it is necessary to be in control of who may order goods and services, and such permissions may be granted to several members of staff involved with specific project phases and work packages

requesting goods and services – the specific goods and services are requested from the purchasing department

assessing purchasing orders – the purchasing orders are confirmed by assessing possible inventories and internal sources for the required goods

searching for suppliers – a list of potential suppliers is drafted and invitations to tender may be sent out

placing orders – the order is placed to the selected supplier following a negotiation of contracts, unless supplier policy is followed

receiving goods – the goods are provided and received by the organisation

assessing purchased goods and services – the goods are assessed against the order made and the original requirements from the project work packages

paying for the goods – the payment for the services and goods is made.

Project Analysis 49

© ABE

Evaluating Bids and Selecting Contractors

Which suppliers are likely to offer the most in terms of value and quality of service? A number of processes are involved in choosing the most suitable supplier, and working towards a draft contract we can identify the following steps:

determining the requirements for goods and services

issuing an invitation to tender (ITT) based on the legislation that covers the economic area the organisation operates within

accepting tenders or bids by the set deadline (these may be sealed or open depending on the process followed)

assessing the suitability of each proposal received

considering how the bids affect the project budget and existing estimations and assumptions

establishing a contractual arrangement with the selected suppliers.

Plan Contracting

When project managers plan for contracting they must provide a detailed documentation of the resources required and any identified suppliers. The plan must include details of how the procurement process should take place and also aspects of the contractual agreement.

The plan-contracting process is based on a number of inputs including:

a procurement management plan

a contract statement of work

make-or-buy decisions

the project management plan.

The project management plan is likely to provide information included in the:

risk register

risk-related contractual agreement

resource requirements

project schedule

activity cost estimates

cost baseline.

Once the goods required are identified, the project manager must generate a number of documents depending on the process that is to be followed. A request for proposal (RFP) requests the generation of a specific plan explaining how the work will be carried out and how the goods will be produced by the supplier. The invitation for bid (IFB) or request for bid (RFB) is issued when the project manager has a clearer idea of what must be produced. A request for quotation (RFQ) is used when a quotation is needed per item, hour of work or unit of service provided. These documents are likely to produced using standard forms that have been designed for use in similar projects.

Expert judgment should also be applied in the form of structured reports offering further detail and justification to support any purchasing decisions.

The output of the plan-contracting process takes the form of procurement documents including detailed orders with some justifications for the main purchasing decisions. A contract statement of work (SOW) is yet another output, together with any documentation clarifying evaluation criteria and selection processes.

50 Project Analysis

© ABE

Request Seller Responses

The process of requesting seller responses should be based on offering suppliers the chance to submit quotations, bids, and any associated information with their supplier services and detailed proposals.

The seller responses required by the project manager will have been identified as part of the plan-contracting process. The main distinction between the different types of request is whether or not the project manager is capable of specifying the goods to be ordered in detail. A request for proposal is likely to be sent out when the goods required do not have to adhere to a very detailed specification. A request for bids is more suitable when the project manager requires a very specific input and the selection is likely to be based on the ability of suppliers to match the requirements of the invitation to tender.

Think Point 7

For a project that requires the development of several new classrooms in a further education college, explain how you would request supplier responses for a number of required resources. Focus your consideration on furniture and computer equipment, as well as construction services and decorating tasks.

Select Sellers

The process of selecting a seller for a resource item involves reviewing the available proposals and the selection of the most suitable seller. Part of the process is the negotiation of the contract details.

A tender evaluation process can be either in the form of a bid examination and

determination of responsiveness or a detailed bid evaluation. The eligibility of bidders must be assessed and this can be done by taking into consideration such factors as:

prior experience of the sellers

economic standing and stability of finances

skills, experience, knowledge of seller

equipment capability and infrastructure available

arbitration history.

In order to make the selection a project manager must assess the experience of a bidder. A typical test should focus on whether the supplier can operate in the environment provided and on its relationship with its customers. The ability to meet the needs of the customers and deal with legislation, administration and other factors that may affect the supplier's work is an additional criterion. Quality management, service support, management policies, staffing procedures and similar internal operations are certainly helpful to assess the well-being of the organisation.

Understanding the Content of Contracts to Supply

There are two key processes involved with the preparation of the content of supply contracts – contract administration and contract closure. It is essential to understand the importance and the key aspects of each.

Contract Administration

Project Analysis 51

© ABE

The administration of the contract involves any corrective actions that may be required due to the effects of external events. This quite often requires the project manager to maintain and control the relationship with suppliers.

The administration of contracts includes the negotiation of the contract elements and is likely to be based on an initial process going through several drafts of the contract. Renegotiation and revision of the initial contracts may also be part of the process in more complex project structures and supply chains.

Contract Closure

The closure process requires the project manager to hand over a specific portion of the project and its deliverables. This means that each contract should be settled and any issues should be resolved. The contract closure means that the specific part of the project should be regarded as complete.

Once the project is complete the project manager must:

release any resources so they can be used in other projects

settle any financial issues

complete project documentation and update any record keeping and associated archives

hold an end-of-project session and establish the lessons learned by the project stakeholders through brainstorming.

An evaluation report for the project could include:

sign off documents

staffing and skills used

organisational structures

schedule management

cost management

quality management

configuration management

customer expectation management.

Review Question 4

List the eight main steps involved with the purchasing process in a project.


E. EFFECTS OF LOCATION ON PROJECT MANAGEMENT

The ways in which a project may be managed vary considerably, depending on where we conduct our business and whether a project is tied to a specific location. There are several factors that must be taken into account when setting up a project and location is one of the most important ones. The location of a project can be determined in a number of ways. For example, the country which is host to the organisation in charge of the project might be one. Alternatively the project's location may be determined by where suppliers, customers or other

52 Project Analysis

© ABE

stakeholders reside. A different perspective could depend on where key operations take place or how the organisation's presence is defined in terms of buildings and services. Since a significant portion of today's organisations have a multinational presence, it is necessary to understand how location affects the way projects are planned, designed and run. It is also critical to become aware of aspects relating to location issues that may be affecting decision-making and problem solving. Such aspects may relate to geography, political and economic issues, culture, government policies, values and beliefs; many different location issues are of concern for the modern project manager.

Before considering an analysis of such aspects and their role in project management, it is

necessary to discuss the concept of organisational culture as it provides an interesting prism of how location affects projects. As mentioned, depending on location a project may be tackled in different ways. However, it is not uncommon for some organisations to maintain a relative harmony in the way their projects are managed, in an attempt to phase out the effects of location. This is possible when a strong organisational culture exists that may override other cultural effects. Such an organisational culture is evident when employees and managers provide statements such as "this is the way things are done in this company" and "all employees of this organisation are able to". This means that the organisation has become the predominant source of behavioural etiquette and all its members are expected to operate under certain patterns. A simple example could be the way deadlines are viewed by the employees in comparison to the population of the country. It is quite interesting to research what different cultures perceive of a deadline stating that "the report must be ready first thing in the morning". For some first thing might be 9 a.m. while others may take this as an acceptable window of three hours leading to lunch time. There will also be those who will make sure everything is ready before even the working day begins (say between 6 a.m. and 8 a.m.). Therefore the notion of time could be one example of how location may affect project management. We will discuss such examples further.

In their book Project Management, Gray and Larson (2003) identified ten characteristics that can be used to describe the concept of organisational culture. These are:

Member identity – this describes how members of an organisation may seek their identity in their specific role, their job or as an integral part of a wider entity that is the organisation.

Team emphasis – this shows how strong a team spirit culture is within the organisation or whether members show a high degree of individualism.

Management focus – this refers to the organisation's awareness of how management practices may be affecting the well-being and the role of the organisation's employees.

Unit integration – this dimension identifies the extent of integration of the different organisational units as opposed to those working in isolation.

Control – this is a measurement of how strong policies, procedures and practices are in dictating how operations take place.

Risk tolerance – this shows whether the organisation is prepared to deal with risks associated with certain decisions and operations.

Reward criteria – this classifies organisations according to the reward mechanisms used to increase employee motivation and reward the achievement of targets.

Conflict tolerance – this distinguishes organisations according to their tolerance to conflicts being openly discussed and resolved against to those that prefer complete avoidance of conflicts.

Means versus end orientation – this dictates where the focus of management is on achieving its aims rather than the processes followed.

Project Analysis 53

© ABE

Open systems focus – this explains how organisations choose to interact with their environment.

Managing Differences

Different organisations depend on different structures and their unique characteristics usually affect the way their projects are managed. One of the main aspects of project management affected by such organisational differences is the way work is structured. As mentioned in earlier sections of this chapter, a hierarchical approach in work structures facilitates the management of projects. The three approaches to WBS are identified as:

noun type approach

verb type approach

organisational approach.

A noun type approach is recommended by the Project Management Institute (PMI) and is based on the various deliverables of the project. The approach defines deliverables in terms of either the physical or functional components that are created during the project's operations.

A verb type approach was recommended by the PMI before the introduction of the Project Management Body of Knowledge (PMBOK), and is based on the design-build-test-implement series of actions that are required for the creation of a deliverable. This approach is focused on specific actions and the way these are related.

Finally an organisational approach defines deliverables in terms of organisational units that are involved in the process. In this approach we must consider each deliverable in terms of the business processes as well as any departmental units involved. An important aspect is also the geographic location of an organisation's resources.

Geographical Issues

Quite a few organisations are based on complex structures, with their units of operation or the resources they require geographically dispersed. As we have mentioned, the organisational approach provides a number of different views of how projects may be structured. The main drawback with these approaches is that they are based on the organisation's structures rather than on project management disciplines. The obvious problem with such an approach is that it becomes difficult to apply to projects outside the organisation. Furthermore, as the approach is strongly affected by the way the organisation units are integrated, it also depends on how efficient these units are. Therefore a project may be managed according to a geographically oriented, departmental or business process oriented perspective.

By breaking down business processes the organisation is able to provide a series of steps that can be used in a variety of projects, allowing the achievement of aims and the production of deliverables.

A project may be structured according to the departmental units involved. This approach allows a more straightforward allocation of resources as the different deliverables are the responsibility of well-defined departments. However, any inherent problems that may exist in various departments may become a continuous source of concern for the project tasks assigned to the specific unit.

Issues relating to geographic dispersion may be classified in a range of factors that may affect the outcome of a project as well as its smooth operation. Geographic issues could include the following:

Political – where the stability of a nation is indirectly affecting the way projects perform. Organisations may choose to avoid uncertainty and avoid specific territories where corruption and lack of integrity may cause delays or additional costs.

54 Project Analysis

© ABE

Legal – the laws of each country must be respected, meaning that certain functions or actions may be constrained in some locations.

Government – the government influence in the way private organisations perform their operations in a country may be a factor affecting which projects may go ahead and which may not.

Security – establishing a secure environment for the project is critical and it depends on how secure is the environment offered in each country and region.

Social – the social norms of what is acceptable and what not is also a factor affecting the suitability of a social environment for an organisation that operates within certain industries.

Location – the location itself may offer opportunities and threats for a project, including mobility issues, experience in the sector, special skills and prior knowledge.

Economic – the local economy may affect the range of operations that are performed in each country and the extent a project is dependent on local resources.

Infrastructure – the technology that is required for a project as well as the infrastructure available in each location must be aligned to ensure that the project's operations are not affected by inadequate technological infrastructure.

It is evident that a major impact of geographic dispersion is the way resources are allocated. Some projects are dispersed in such a way that physical coexistence of resources is impossible. This means that face-to-face communication is not feasible and on some occasions even synchronous, technology-enabled discussions cannot take place. As a matter of fact the number of projects that include teams residing in different countries with different time zones is quite significant.

There is also the need to understand that geography plays a role even in smaller scale projects. Typically, moving people from the same office to different floors or buildings could provide a dramatic decrease in their efficiency and add unexpected overheads in their communication. The time it takes to coordinate project offices and establish communication between collaborating units is increased dramatically.

Cultural Issues

The concept of cultural differences in a project can be a complicated one to explain. The notion of culture can be described differently, depending on the perception the project team has of the way a project is affected by such differences.

Typically by culture we mean the national culture. This is portrayed in an individual's conduct as a set of norms, values and behaviour patterns that have been formed through experiences in the immediate environment such as family, school and local society.

In several countries a stronger regional culture has developed as a result of past population movements. Such regional cultures may demonstrate differences in language, religion and habits.

As mentioned earlier in the chapter, a corporate culture develops in (often multinational) organisations that are established well enough to introduce their own norms, acceptable behaviour and principles for their employees. It is perceived that corporate culture is sometimes so strong that, when at work, employees tend to suppress any characteristics that reflect their national or regional culture.

A professional culture has been observed in certain professions that require integrity, ethics and a strong view on how discipline is applied through the profession. Professional culture can be so strong that it offers a communication medium for those who share it. Professional culture is expressed in terms of certain expectations and assumptions for professional behaviour.

Project Analysis 55

© ABE

Individuals who share the same roles in different organisations may belong to the same

functional culture that is associated with the role responsibilities and duties. A functional culture is what separates staff members and may be the reason why they have different views on the organisation's operations and decisions.

Finally a team culture is quite often present in teams with members who are strongly related, experienced in working together, share same goals and have a common ethos. The team culture is so strong that may cause difficulties to new members who wish to join an existing team.

Review Questions 5

(a) Name the ten main characteristics identified by Gray and Larson that can be used to describe organisational culture.

(b) Identify the eight main geographic issues affecting a project's performance.


SUMMARY

This chapter introduced the hierarchical division of work and work breakdown structures. The chapter also discussed in detail risk management and assessment as well as the processes of cost planning and estimation. The later parts of the chapter emphasised the importance of dealing with bids, tenders and contracts. The effects of location and culture in project management concluded this chapter.

56 Project Analysis

© ABE


Review Questions 1

(a) The five usual sources are staff, competitors, customers, suppliers and R & D.

(b) The six main elements included in a project scope checklist are objectives, deliverables, milestones, technical requirements, limitations and exclusions and reviews.

(c) The six key concepts or steps involved in the creation of a work breakdown structure involve project, deliverable, sub-deliverable, lowest sub-deliverable, cost account, work package.

Review Questions 2

(a) The four main project risk management steps are risk identification, risk assessment, risk response development and risk response control.

(b) The four main quantitative risk analysis methods are expected value, sensitivity analysis, Monte Carlo simulation and the programme evaluation and review technique (PERT).

(c) The seven most common monitoring and control tools that can be used in risk assessment are work breakdown structures, estimated and actual project budgets, project schedules, earned value of project activities, project resource list, project plan and change control log.

Review Questions 3

(a) The nine project management knowledge areas described in PMBOK are project integration management, project scope management, project time management, project cost management, project quality management, project human resource management, project communications management, project risk management and project procurement management.

(b) The two contract types which can be used for plan purchases and acquisitions are fixed price contracts and cost reimbursable contracts.

Review Question 4

The eight main steps involved with the purchasing process in a project are approving purchasing stakeholders, requesting goods and services, assessing purchasing orders, searching for suppliers, placing orders, receiving goods, assessing purchased goods and services, and paying for the goods

Review Questions 5

(a) The ten main characteristics identified by Gray and Larson are team emphasis, management focus, unit integration, control, risk tolerance, reward criteria, conflict tolerance, means versus end orientation and open systems focus.

(b) The eight main geographic issues affecting a project's performance are political, legal, government, security, social, location, economic and infrastructure.

57

© ABE

Chapter 3

The Project Plan

Contents Page

Introduction 58

A. Project Overview 58

B. Project Management Structures 60

Justifying the Need for Formal Project Management Structures 60

Assigning Responsibility to Personnel 66

C. Project Activities and Schedules 69

Identifying Project Activities and Dependencies 69

Devising Project Schedules 70

Using Scheduling Tools 73

D. Dealing with Change in Project Schedules 74

Adjusting Project Schedules according to Constraints 74

Reorganising Project Schedules to fit available Resources 76

E. Project Communications 78

Communicating Project Details to Stakeholders 78

Describing Project Plans 80

Summary 81


58 The Project Plan

© ABE

INTRODUCTION

Following on from the discussion of project initiation in Chapter 2 we will now look at how project planning works. The project planning process involves a number of steps, and these are needed in order to provide a project overview that can be followed and used as a reference point for the duration of the project. The underlying intention is that following these steps will result in a comprehensive plan which will enable the project to be described in the necessary detail.

Objectives


justify the need for a formal project management structure.

propose an appropriate structure for the control and administration of a project and indicate the responsibilities of key personnel

identify the activities in a project and establish their dependencies

employ recognised techniques, such as the Gantt chart and network analysis, in order to devise a project schedule

outline the typical functions of project management software packages which can assist the scheduling task

explain the need to adjust project schedules when the available resources are subject to constraints

reorganise a project schedule in order to smooth resource requirements

recognise the need to communicate the project plan to various interested parties

describe the contents of a detailed project plan.

A. PROJECT OVERVIEW

An important element of the project plan is to clearly define the scope of the project. After all, the plan should be based on a good understanding of what the project requires. Initially we

need a project overview statement (POS) that provides sufficient detail for five components:

problem/opportunity

project goal

project objectives

success criteria

assumptions, risks and obstacles.

Identifying a problem in need of a solution or an opportunity for a new product or service is quite often the beginning for a project. The identification of such problems or opportunities is important as it sets the scene for the project requirements. A project may also be triggered by specific customer requests or requirements from stakeholders. It could also be the case that the organisation is introducing an initiative, entering a new market or taking further actions that make the project a necessity. The influences behind a project may depend on external factors, such as changes in the local market, dated technology, obsolete products, etc.

The project goal can usually be defined in a single statement that outlines the project scope, and it can be quite descriptive. The project goal can be defined clearly by making sure a

The Project Plan 59

© ABE

number of characteristics are present when describing its primary aim. These features can easily be remembered by using the SMART acronym:

Specific – the goal statement must aim for specific targets

Measurable – the project progress can be measured against certain criteria

Assignable – there is a clear responsibility assigned to the role of those undertaking specific parts of the project

Realistic – the project deliverables are feasible with the available project resources

Timely – there is a reasonable time frame identified for the completion of the project and its deliverables.

The project objectives should follow the SMART characteristics and offer a detailed view of how the project deliverables should meet the identified requirements. A statement that describes a project objective in sufficient detail should include information about:

the outcome of this objective in terms of whether it is a specific deliverable or another form of accomplishment

the duration of the tasks associated with this objective

a way to measure the performance of the project towards this objective

a series of actions required for this objective to be achieved.

The success criteria that can be used to assess a project will vary, depending on the type of project considered, the organisation, the industry sector and various other factors. A typical criterion is whether the project improves the revenue stream for the organisation. A project may increase profits or reduce costs, offering value for the organisation. A project is likely to produce additional goods and services in line with the existing provision of the organisation.

Several other concerns may affect the project overview and these may include certain

assumptions made, identified risks and even obstacles that may cause the project to deviate from its original plan. Typically the immediate project environment and the setting for its activities are causes for concern, especially when these are volatile and subjected to numerous external pressures. The technology used and any infrastructure constraints may also be reasons why a project statement may not be implemented precisely. Further concerns may relate to resources, staffing issues, conflicts, personal relationships, etc.

Review Question 1

What do we mean when we require a project manager to set SMART objectives for a project?


60 The Project Plan

© ABE

B. PROJECT MANAGEMENT STRUCTURES

Each project has a unique set of activities associated with its aims and (identified) deliverables. The project scope can be defined in such a way that a specific project planning process can be followed. Such a process can be identified in terms of the following four steps:

identifying the essential activities required for achieving the project's aims and objectives

determining how these activities are linked and whether they can be organised in a sequence

specifying the requirements of each activity in terms of costs, resources and time needed

mapping the activities and resources in such a way that a project schedule can be created and shared between project stakeholders.

Harvey Maylor (Project Planning, fourth edition) has suggested the acronym ICOM – for the

project inputs, controls, outputs and mechanisms – for describing the project planning process.

Typical inputs for a project take the form of project descriptions, specifications and any other form of requirements. The project is controlled mainly through a set of standards that must be adhered to and procedures that are followed by an organisation. The project controls may include external factors for the project – various aspects of the macro-environment for the project that may include political, social and cultural constraints. The planning process main output takes the form of a project plan that may be used as a proposal for a bidding process. The mechanisms employed in a project can be classified either as the human resources (including the workforce involved along with the project manager and any external stakeholders), or a set of tools and techniques that may be used to coordinate the project activities.

Think Point

Provide an example of a project plan based on the ICOM (inputs, controls, outputs and mechanisms) technique.

Justifying the Need for Formal Project Management Structures

Project management structures are required for both small and large projects. The need for such structures is imperative: they help us to remain aware of the project scope and define it in a clear way, deal with various project work activities and assign roles to members of the workforce allocated to the project. For every project there are three main roles:

project manager

project team

project champion.

As mentioned earlier the role of the project manager is to coordinate the entire project and steer the project team in such a way that it works successfully towards the completion of the

project deliverables. The project champion role is usually introduced in larger projects. It is the project champion's role to advocate the importance of the project and increase interest and support both within the organisation and also externally. Sometimes this role may be part

The Project Plan 61

© ABE

of the project manager's responsibility and a member of the project team could be assigned as the champion, or the task could be undertaken by another stakeholder.

The initial stage in producing a project management structure is to clearly assign roles and establish the human resource structure. We could identify a number of steps for setting up the structure of the project management human resources as follows:

choose a project manager – this is the individual who will be in charge of the entire project

select project team members – these are the staff or even external contractors who possess the required skills and who will undertake the project activities

assemble a project steering group – this is the team of individuals who will be involved in the decision-making and problem-solving tasks throughout the project

identify a project champion – this is the individual who is likely to chair the steering group and who will be able to provide an accurate description of the project's status

prepare a project management plan – this is based on a flow of specific processes and a set of well-defined activities.

We mentioned in Chapter 2 that an important aspect of project management is the preparation of a work breakdown structure (WBS) that will allow us to monitor the project during each of its phases. We must consider that the project plan should take into consideration two important areas of concern, namely processes and products. The aim should be to identify and map those processes required for the production of the project products. The main structures associated with these two processes are:

work breakdown structure – this is an analytical view of the work activities associated with the project processes

functional breakdown structure – this is an outline of the functions that are supported or provided by the project deliverables

physical breakdown structure – this is a representation of the physical representation of the project objectives

product breakdown structure – this provides the structure of the products associated with the project deliverables.

These structures lead into the creation of the project deliverables in the form of specific work packages that are defined in detail. Each work package is specified in terms of the duration it requires for its completion as well as the sequence followed for its production. The sequence is necessary, as some work packages may be dependent on others.

Think Point

With the aid of an example, distinguish between any two of the following types of breakdown structure: work (activities), functional (functionality supported) or product (project outputs).

Creating a WBS

The work breakdown structure concept has been discussed at several points so far, and is illustrated in Figure 3.1. The aim is to provide a graphical representation of a series of activities and emphasise how these activities are related. The activities belong to the project and form a list of requirements and responsibilities that must be fulfilled. The structure allows us to view the activities in different levels (as some of them belong to the same complexity level), before they are broken down to more refined tasks.

62 The Project Plan

© ABE

Figure 3.1: Work breakdown structure

1

Activity Name

1.1

Activity Name

1.2

Activity Name

1.3

Activity Name

1.2.1

Activity Name

1.2.2

Activity Name

The numbering of the activities allows the project manager to group activities that belong to the same role or to identify which sub-activities are at the same level. The same diagram can be used to demonstrate the different types of breakdown structure discussed before. Figure 3.1 could therefore include the following activities, according to what type of breakdown structure it demonstrates:

work breakdown structure:

1 – develop a new website

1.1 – identify the user requirements

1.2 – design the web pages:

1.2.1 – design the interface of each page

1.2.2 – design the back-end and databases

1.3 – test the page with users

functional breakdown structure:


1.1 – deal with implementation issues and skills required

1.2 – assess the website success criteria:

1.2.1 – conduct surveys with users/customers

1.2.2 – monitor competition and evaluate other similar sites

1.3 – acquire the technology required for the site interface

physical breakdown structure:


1.1 – organise the user interface team

1.2 – organise the web development team:

1.2.1 – initiate the database design team tasks

1.2.2 – initiate the server design team tasks

1.3 – organise the testing team.

The Project Plan 63

© ABE

Think Point

Provide an example of a work breakdown structure for a project of your choice.

A number of approaches could be followed when putting together a WBS. Typically project teams often choose a top-down approach, identifying the main project tasks and then attempting to break them down into to simpler activities until very simple tasks are identified. A bottom-up approach on the other hand would involve starting with the identification of simple tasks that must be performed. Either way, it is necessary for all possible tasks to be identified. Once this step is complete the team must group together these tasks in a meaningful way, creating a level of more complex activities. This process is iterative, and continues until the entire project can be viewed as a tree structure that starts from its most analysed branches and finishes with its root.

The creation of a WBS following the top-down approach may have a number of variations. For example, a team approach means that the entire project team is involved in the breakdown of each task till the WBS is completed. Each time a new task must be analysed further, the team is led by a member who is more experienced and knowledgeable of the particular area. On the other hand a sub-team approach means that after the first level of tasks has been created, the team is split according to the number of tasks identified at that level. Each sub-team is then responsible for completing a specific portion of the WBS.

The WBS creation process is based on a number of inputs, including:

any organisational process assets

a project scope statement

a project scope management plan

any approved change requests.

The WBS creation process can be based on templates, and although templates cannot be generic enough to cover all possible projects they can offer a useful set of guidelines. One such is the Project Management Institute Practice Standard for WBS, which helps with the creation, generation, development and application of WBS: the output takes the form of the WBS itself. However there are other breakdown structures that may prove useful for project managers, although it should be noted that such structures are not produced during the WBS

creation process. Such structures include organisation breakdown structure, risk

breakdown structure and resource breakdown structure.

It is important to understand that the WBS creation is based on the breakdown of activities that define the project. The project breakdown is based on specific guidelines for the entire process and involves:

identifying the project deliverables and any work associated with each deliverable

structuring the WBS

breaking down each WBS level to a more analytical lower level

assigning a code to each detailed component of the WBS

verifying that no further breakdown is necessary.

Scope Verification

As mentioned before, an important part of the project planning process is the definition of the project's scope, usually in the form of a clear scope statement. The input for the scope definition process can be identified as:

64 The Project Plan

© ABE

organisational process assets in the form of plans, policies and procedures influencing the project success

a project charter offering a term of reference for the project

a preliminary project scope statement

the project scope management plan

any approved change request.

This input is quite similar to the input for the WBS. The scope definition may be terminated by employing several techniques including product analysis, identification of alternatives, expert judgment and stakeholder analysis. The scope definition output may include:

project objectives

scope description

project requirements

project boundaries

project deliverables

project acceptance criteria

project constraints

project assumptions

initial project organisation

initial defined risks

schedule milestones

fund limitation

cost estimate

project configuration management requirements

project specifications

approval requirements.

Based on the scope definition described before, the process of scope verification follows. It can be defined as the process involving the acceptance of the project deliverables by the project stakeholders. At this stage we must distinguish between the project verification and the quality control process. The former is based on the acceptance of the deliverables while the later focuses on whether the deliverables meet certain standards.

The project verification input includes the:

project scope statement

WBS dictionary

project scope management plan

deliverables.

Following the inspection of the project deliverables the outputs are:

accepted deliverables

requested changes

recommended corrective actions.

Scope Control

The Project Plan 65

© ABE

Scope control is a process that is strongly associated with scope verification since it focuses on ensuring that changes in the control process are invoked in order for recommended changes and corrective actions to take place when required. The inputs of the scope control process include:

the project scope statement

the work breakdown structure

the WBS dictionary

the project scope management plan

any performance reports

approved change requests

work performance information.

It is obvious that the scope control process is primarily concerned with the way changes take place and how they are approved as well as the effects of the requested changes on the project's performance.

The scope control process is based on a number of techniques, including:

Change control system – focusing on how the project's scope may change to accommodate any change requests

Variance analysis – focusing on analysing the magnitude of requested changes and the effects on the project's scope

Replanning – focusing on the changes required on the WBS following the requested changes

Configuration management system – focusing on the project deliverables and their progress as well as the documentation of the changes in the WBS following the requested changes.

Think Point

Focusing on how the WBS is adjusted following requested changes, explain the role of replanning in the scope control process.

The scope control outputs include the following:

updated project scope statement

updated WBS

updated WBS dictionary

updated scope baseline

requested changes

recommended corrective action

updated organisational process assets

updated project management plan.

66 The Project Plan

© ABE

Assigning Responsibility to Personnel

So far we have discussed the way a project deals with change requests. It is necessary to understand that the initial WBS may be affected by the introduced changes. We now need to understand how the project schedule is created and more specifically to become aware of how the project activities are taken into consideration when planning the schedule.

There are four key steps during the planning stages of the project. These steps can be identified as:

activity definition

activity sequencing

duration estimation

schedule development.

There is also another step that is performed throughout the project and it is discussed later:

schedule control.

Activity Definition

The activity definition process identifies all the activities required for the project deliverables to be produced. Certain inputs are required for the activity definition process including:

WBS

project scope statement

historical information

constraints and assumptions.

The historical data is information that may be useful in providing an awareness of how similar projects performed in the past. The constraints are the limitations of the choices available to the project team, while assumptions allow the project team to take for granted that certain factors are real.

The techniques and tools that are used in activity definition are breakdown and the use of templates. As mentioned in our discussion of the WBS, the breaking down of activities is necessary to define each activity and associated sub-activities. Any activities that have been performed in previous projects may be used as templates for the activities of subsequent projects.

The outputs of the activity definition process include:

activity list

supporting details

WBS updates.

The list of all identified activities can be used as additional information to what is included in the WBS, to ensure that all tasks involved in the project have been identified. The supporting detail for each activity may include known constraints or any assumptions that can be made. Obviously any changes to the initial WBS must be documented as they are necessary for the definition of the project's activities.

Activity Sequencing

The activity sequencing process indicates how project activities are related. The aim is to show that certain activities are dependent and that the project performance is affected by these dependencies.

The Project Plan 67

© ABE

Inputs to the activity sequencing include:

Activity list – The activity list is important as it identifies all the activities that must be ordered in a sequence.

Product description – The product description is likely to affect not only the activities involved but also certain ways that the activity sequence can be formulated.

Dependencies – There are several kinds of dependencies, including mandatory, discretionary and external.

Mandatory dependencies are the ones that cannot be negotiated and are dependent on the way the project deliverables must be prepared. Indeed sometimes it is impossible to move to a particular step of the process unless another one is complete. Discretionary dependencies can be decided by the project team and sometimes they are preferred although there may exist another possible sequence of activities. These might cause some conflicts if not properly documented as they are supposed to follow good practice or even deal with unusual events. The external dependencies demonstrate how activities that do not belong to the project may affect project activities.

Milestones – These are important events that, once reached, allow certain activities to commence.

Constraints – which have been discussed earlier in this chapter.

Assumptions – which have also been discussed earlier in this chapter.

There are several sequencing methods that are used to provide an accurate representation of any activity dependencies and how the sequence of activities leads to the end of the project. Some of these methods and techniques are:

Precedence Diagramming Method (PDM)

There are four types of precedence relationships in Figures 3.2 and 3.3, namely: (i) finish-to-start, meaning that the successor activity cannot start till the predecessor activity finishes; (ii) finish-to-finish, meaning that the successor activity cannot finish before the predecessor activity finishes; (iii) start-to-finish, meaning the successor activity cannot finish unless the predecessor activity has started; and (iv) start-to-start, meaning that the successor activity cannot start until the predecessor activity has started. The precedence diagramming method, also called the activity on node (AON) method, is illustrated in Figure 3.2.

Figure 3.2: Activity Network Diagram (Precedence Diagramming Method)

Arrow Diagramming Method (ADM)

End

A

B

C

E

F

Start

D

G

H

I

68 The Project Plan

© ABE

This method shows activities as arrows that are connected in nodes representing dependencies. This is known as the activity on arrow (AOA) technique and is based on finish-to-start dependencies only with an addition of dummy activities to allow a full logical representation of the activity sequence. Figure 3.3 illustrates this technique.

Figure 3.3: Activity Network Diagram (Arrow Diagramming Method)

Conditional Diagramming Methods

The PDM and ADM techniques do not offer if-then-else branches. Such conditional branching can be supported in conditional diagramming methods including the

graphical evaluation and review technique (GERT) and system dynamics models.

Activity sequencing has two main outputs, namely network diagrams and the activity list. The former type of output is in the form of diagrams like the ones illustrated in Figures 3.2 and 3.3. The latter is in the form of an updated WBS which includes the revised list of activities.

Think Point

Draw an activity network diagram for a project example of your choice. Either PDM or ADM diagram types can be used and the example should include no more than 10–12 activities.

Review Questions 2

(a) Identify the five main steps involved in structuring project management human resources.

(b) Identify the five main stages involved in project breakdown.

(c) Identify 14 of the 16 main outputs from the scope definition process.

(d) List the six main inputs for the activity sequencing process.

(e) What are the two types of activity network diagrams and how do they differ?


1 3 6

5

7

9

2

4

8

10 End

A

E B

F

D

C G

J

H K

I

L

The Project Plan 69

© ABE

C. PROJECT ACTIVITIES AND SCHEDULES

In order to understand the activities associated with a project and the way these take place in its various phases we must be able to define the project goals. The project activities are important for a number of people. First are the project sponsors, those stakeholders who have a real interest in the project and have invested in its success. The second group of people who are dependent on the project are the customers who will reap the benefits of the project deliverables. Similarly, the end-users who will be using the project outputs also have a strong interest in the project. Finally there are those involved with the project activities and schedules, the project manager and team.

Identifying Project Activities and Dependencies

So far we have discussed a number of methods that can be used to identify those activities necessary for the success of a project. It is essential to understand that the identification of these activities alone is not sufficient. At this stage, the most important role of project management is to be in control of how these activities are dependent on each other and also ensure that such dependencies can be monitored and adjusted throughout the project's life cycle.

Activity Resource Estimating

The scheduling responsibilities of the project manager and the team will deal with a number of estimations for the project activities. The activity resource estimating process is concerned with the identification of any resources required by each activity. The project activities are defined in terms of the tasks that must be performed as well as a list of resources that must be available to ensure their successful completion. The resources can be classified according to their nature. For example, it could be funds or allowances, or perhaps specific equipment or even software that may be required. A major part of the resource plan deals with the human resource requirements, since each activity must be undertaken by individuals who possess suitable skills, knowledge and experience.

Activity Duration Estimating

Once we have established what resources are needed for an activity we should attempt to estimate how long the activity will last. Since, by providing the necessary resources we can now guarantee that the activity will be completed within the required quality standards, the next step is to assess its duration in a process called activity duration estimating.

The inputs to this process include:

an activity list with all activities to be assessed

any constraints that may affect the progress of each activity at a later stage

any assumptions made in terms of the activity environment and the way that each activity will be carried out

any resource requirements (it should be noted that estimation of resources is sometimes integrated with the activity duration estimation as the provision of resources and any supplies may affect the progress of an activity and introduce delays)

resource capabilities mapping out the range of support offered from the resources and a realistic report on what can feasibly be achieved with the acquired resources

any historical data that may allow a better understanding of each activity time frame.

The historical information can be based on prior knowledge of the team members from similar projects. However a more formalised method would be based on the organisation's record keeping of previous project management endeavours and sometimes on commercial

70 The Project Plan

© ABE

services offered by specialised firms in the field of estimating the duration of specific, well-defined activities.

The activity duration estimation can be primarily based on the following tools:

Expert judgment – This is a technique based on the views of experts in such cases where the estimation of the activity duration is difficult to achieve. These judgments are obviously based on years of experience and historical information.

Analogous estimating – This is a technique which uses a top-down approach of analysing prior activities of similar nature in an attempt to forecast their duration.

Simulation – This is a method based on several techniques, an example of which (Monte Carlo) was mentioned in Chapter 2. The objective is to attempt estimating the duration of each activity based on a number of scenarios, and then measure the duration based on different assumptions each time.

The process outputs of activity duration estimating include:

activity duration estimates

basis of estimates

activity list updates.

The main output of the process is the provision of estimates in the form of an activity list and the associated duration for each activity in preset units. These units could be days, weeks or even hours, depending on the nature of the project. The duration estimate should include some form of allowable range in case the project teams manage to complete them before the expected deadline or certain constraints force the activity to overrun. The assumptions made in order to reach the duration estimate should be reported as they provide the justification supporting the estimation. Finally, the project WBS may be revised and a list of revised, updated activities should be produced.

Devising Project Schedules

Once each activity is defined in detail, it is time to establish a detailed schedule. The project schedule is yet another process available for project managers to control the way a project progresses and monitor how the activities are performed according to plan. The main concern at this point is not just to develop the project schedule, but also control it throughout the project. Project managers are expected to intervene when a project schedule is difficult to follow, making any necessary adjustments so the project activities can be achieved within the time frame and the resources allowed.

Schedule Development

Developing the project schedule is an iterative process, and offers project managers the chance to refine estimations for the duration, cost and resources needed for each activity. The number of iterations required prior to the development of the final project schedule depends on the project nature and involved activities.

The inputs for the schedule development process include the following:

Activity duration estimates – these are provided for each activity (as discussed previously) and are combined to estimate the duration of the entire project

Project network diagrams – the methods described previously are used to offer an illustrative view of the activity duration and dependencies

Resource requirements – the summary of the resources needed for each activity should be provided

The Project Plan 71

© ABE

Resource availability – each resource item should have its availability monitored to ensure that there are no delays to specific activities and to ensure the project overall does not reach a deadlock

Calendars – these offer a useful way to visualise work shifts and disseminate information as to when work and idle periods are expected; calendars are also used for resource availability

Constraints – the list of all constraints and limitations to the project with a reference to possible impacts on duration

Assumptions – the list of all assumptions indicating which are expected for the project schedule to be met, as well as any possible deviations that may be caused if the assumptions are false

Lead and lag times – these times help to fully understand the time frame for activities and resource requests (an example would be the time it takes for suppliers to provide the necessary resources after the order is made)

Risk management plan – the identified risks should be taken into account, since the duration of certain activities is most likely to be affected once the risks are realised

Activity attributes – the special characteristics of each activity, as well as any factors that may affect the way it is carried out, are needed to estimate whether the activity is likely to meet the original estimation.

The main tools used for schedule development are:

Project Management Software

Software applications are used to provide a semi-automated way of setting project time frames and make necessary adjustments to schedules.

Mathematical Analysis

The use of mathematical analysis allows the calculation of start and end times for each activity. Examples of mathematical analysis techniques used are critical path method (CPM) to identify the least flexible activities, graphical evaluation and review technique (GERT) dealing with the logic behind activity dependencies and duration, and program evaluation and review technique (PERT) that can calculate the project duration based on weighted average duration estimate.

Simulation

The use of simulations is based on various scenarios that use different estimates to assess possible options for the final schedule.

Resource Levelling

The resource levelling technique is based on the use of heuristics to create a schedule that views resource allocation and other similar issues more realistically. Therefore the schedule is based on allowing time for critical and more time demanding and less flexible tasks to be achieved in time.

Coding Structure

Coding structure is used to label activities in such a way that their attributes may be used to logically group them together.

Duration Compressions

The duration compression approach is based on a special form of mathematical analysis that aims at reducing the project duration. Compression techniques include:

– crashing, which is based on reducing activity duration as much as possible

72 The Project Plan

© ABE

– fast tracking, allowing for activities to take place simultaneously.

Typical outputs for the schedule development process include:

Project Schedule

This is a planned chart which includes all activities organised according to important milestones. The schedule may be in the form of bar charts (known as Gantt charts), network diagrams and many others.

Supporting Details

Supporting details include all information required for the justification of the plan, including assumptions and constraints.

Schedule Management Plan

This plan dictates the project management style followed and the means that will be employed to ensure the project schedule will be followed.

Resource Requirements Updates

Since the schedule may end up including additional resource requests, any updates must be recorded.

Schedule Control

Once a schedule is in place, it is quite likely for the project to commence based on the kick-starting activities identified. Once the project is initiated, then the project manager needs to control the schedule by ensuring that the project activities take place when they are supposed to and last as long as the plan indicates.

The main purpose of the schedule control process is to deal with any changes that may be imposed for various reasons. The project manager must ensure that prior to an activity a certain set of pre-conditions must be met. These include the acquisition of resources, the availability of human resources, ensuring the environment is set up and ensuring that all permissions are granted. The project manager must also ensure that the progress of each activity is in line with the original estimations. Further concerns should include resource availability, any milestones, conflicting activities and possible antagonistic actions towards the project resources from other projects.

The schedule control process requires a number of inputs including:

project schedule

schedule management plan

performance reports

change requests.

The schedule management plan is based on the initial planning offering the project baseline and is used to establish whether the project progresses well. The performance reports provide a detailed analysis of the schedule performance indicators. Any change requests that are made formally or informally (and in a variety of forms) are likely to be dealt with during the activity life cycle and a schedule management plan should indicate how the manager is dealing with changes.

Some of the tools at the project manager's disposal for controlling the project include:

Schedule Change Control System

These are the procedures that are followed when dealing with schedule changes.

The Project Plan 73

© ABE

Performance Measurement

Performance measurement means the criteria used and factors taken under consideration when the project performance is measured.

Project Management Software

The software applications used to help with project management responsibilities.

Variance Analysis

These are factors affecting the project schedule and the impact of these factors. Identifying project variances from the original plan is important to ensure that all activities are following a realistic plan.

Planning

The planning process used as an iterative procedure, taking into consideration how activities are grouped together and how they are logically grouped.

The schedule control process produces:

Schedule Updates

The schedule updates deal with any modifications to the initial schedule. The main concern is not only to identify the updates needed but also how these may relate to further changes in other aspects of the project that are not directly identifiable.

Corrective Actions

Corrective actions include all steps that must be followed in order to ensure that the updated schedule is feasible and will not jeopardise the chances for successful completion of the project.

Lessons Learned

A detailed documentation of the lessons learned during different stages of the project is important. These could include the reasons for updates, the changes made and the justification behind them.

Using Scheduling Tools

Scheduling tools form a category of project management software that aims to facilitate the project manager's control processes. Software applications can be used for resource allocation, communication, collaboration tasks, etc. Scheduling tools help in those cases where a project's schedule is so complicated that it is almost impossible to control its schedule by following manual processes.

Semi-automation of scheduling tools allows us to visualise and group together events that affect activities and also illustrate the impact of these events in terms of the project schedule and activity duration. The analysis of the activity dependencies is produced in a way that may allow the assessment of whether the current dependencies are logical. Reminders and scheduled tasks could help to allocate resources, deploy certain resources and teams, attend to critical events and deal with problematic activities. Scheduling tools help to provide estimates, identify recurring events and various patterns as well as dealing with uncertainty.

Scheduling tools are also very helpful in providing task lists for members of the project team, activity lists grouped according to importance or deadlines and a number of filters to sort out project tasks and responsibilities. The duration overview for the project activities and a more detailed analysis of task time frames are also provided. These tools can help project managers to adopt a proactive stance by offering advance warnings in terms of workloads, lagging tasks, etc. Retrospectively, scheduling tools can be used as a useful guide based on historical data of similar projects, tasks from previous phases, patterns of work for individuals

74 The Project Plan

© ABE

and teams. They can also serve as a reporting mechanism which allows the project manager to optimise the use of the available resources and maximise the project performance.

Making Better Use of Microsoft Project

There are several commercial applications that can be used as scheduling tools, and these days basic scheduling tools are even provided with many email applications. One widely

available project management software tool is Microsoft Project, which is suitable for everyday projects with a rather limited number of activities as well as more demanding projects based on more complex structures. Microsoft Project was originally developed to help with the management of projects running within Microsoft applications. Its main characteristic is the development of a Gantt chart for the main project activities. Some quite interesting features include progress tracking, resource assignment, managing budgets, etc.

Review Questions 3

(a) Name the six main tools used for schedule development.

(b) Identify the five main tools used in the schedule control of a project.

Now check your answers with that given at the end of the chapter.

D. DEALING WITH CHANGE IN PROJECT SCHEDULES

A major factor for successful projects is their adaptability to ever changing requirements, external factors, environmental influences and schedule estimates. It is necessary for project managers to allow sufficient margins in their planning to accommodate the need for change. Furthermore it is necessary for contingency plans to be in place so any changes will have only moderate effects on the project's progress.

Adjusting Project Schedules according to Constraints

Some typical strategies for ensuring that project schedules can be adjusted according to constraints are based on allowing enough room for change, following a rather proactive approach. Some of the methods used include the following:

Allowing for Reserves

The project manager of any project should foresee that certain phases may lead to overheads that one could not account for. The establishment of available reserves of different resources should allow their use when needed. Obviously these resources should not be underutilised and towards the end of the project they could be redeployed or even support enhancing existing activities, provide further value-adding outcomes and improve the overall project performance.

Introducing Substitution

Usually activities that are delayed may lead to idle resources and the workforce performing below its optimum productivity level. The substitution of activities with alternative ones that are not bound to any lagging task helps to ensure that the project performs according to an acceptable standard.

Preparing for the Occurrence of Risk Events

The preparation of a contingency plan following a risk analysis for the project is a safe way to ensure that there will be minimum impact on project activities following most risk

The Project Plan 75

© ABE

events. Planning for such scenarios may be part of the project planning process already discussed in Chapter 2.

Improving Working Practices

If change is introduced into a project phase, a project manager could choose to adjust the working practices accordingly. Although this is not a practice that should be used in the long run, by doing this it is possible to achieve an immediate effect and help the project performance to stay at an acceptable standard. Usually a significant alteration in work patterns should be followed by sufficient reward mechanisms, to ensure that staff motivation and commitment remains high. Ideally the reasons for such changes should be explained and be supported with sufficient and fair justification.

Investing in the Workforce

Another common approach when change strikes a project's routine is to employ further human resources or redeploy existing staff. The long-term effects should be considered, as any permanent changes such as job offers, position openings and role allocations might be difficult to maintain after the end of the project. There are also short-term implications such as the cost associated with the use of additional human resources. Furthermore, the time required for retraining, induction and harmonisation of existing team members with new recruits may affect the project time overheads as well as create a more complex communication structure.

Overtime

The provision of mechanisms such as paid overtime, productivity bonuses and additional shift work may also offer the means to overcome obstacles due to project changes.

Controlling a Project

So far we have discussed the main issues relating to the project-controlling process. We need to review such steps under a different perspective when considering how project activities can be controlled and how decisions are made in reaction to change.

The process inputs include:

the schedule baseline that provides the project plan elements that help setting up the project main activities and can be used to revise these activities under the light of the introduced changes

performance reports should assess the project progress against certain criteria and the impact of any changes should be reflected in such performance measurements

a schedule management plan that offers a representation of the project schedule and could be used to revise the schedule and reflect any changes needed

approved change requests that document the justification for any changes.

The project-controlling process is based primarily on the following techniques:

Progress Reporting

Progress reporting offers a detailed discussion on how the project performs and identifies any issues affecting its performance.

Variance Analysis

This is an analytical view of how the project direction has been altered from the original baseline. It also includes the causes of these changes and any forecasts for the project's feature.

76 The Project Plan

© ABE

Performance Measurement

Performance measurement means the analysis of any performance assessment results based on the identified criteria. The tools used in this method may include:

schedule comparison bar charts that offer the opportunity to compare between the original Gantt chart and possible project timeline representations

project management software that may provide an analytical view of any changes happening in the project performance

schedule change control systems that allow the project manager to adjust the project schedule accordingly

schedule variance and schedule performance indexes that offer a very detailed repository of any changes, their causes, the impact to the project and the effect to the project resources.

From a project control perspective, each project can be viewed as an effort that has drifted from its original target. A snapshot of the changes that have taken place is used to assess how these have been realised. The project control outputs include:

performance measurements according to a set of predefined criteria

requested changes with supporting evidence and justification

recommended corrective action with any associated changes to project resources including workforce requirements

schedule baseline updates changing the project activities and phases from the original plan

schedule model data updates representing the new project schedule

activity list updates leading to the same, original deliverables

activity attribute updates, discussing activity aspects that have been affected by change

organisational process assets monitoring the effects of change to what is perceived to be an asset for the organisation

a revised project management plan.

Reorganising Project Schedules to fit available Resources

Since we have now discussed the project planning process, the requirements for project scheduling and how to deal with risks and change, we should be able to summarise the features of team performance that differentiate successful projects from failing ones. The key is the ability to adjust project schedules to fit change and, more specifically, available resources. This can be achieved if the project stakeholders are able to work together towards the same goal. It is expected that a project with high-performing teams should be able to adjust to change in a better way. But what makes teams perform better? This is a question that depends on a number of factors.

Keys to Better Project Team Performance

The factors affecting team performance range from those that depend on how the entire team is structured to the ones that relate to the characteristics of individuals. The effectiveness of some team performance factors is also dependent on the strategy followed at organisation level, while others are affected by the project management style.

Some factors affecting team performance are:

The Project Plan 77

© ABE

Cohesiveness

The cohesiveness of any group depends not only on the time team members have spent together but also on the nature of their jobs, the organisational culture and the way collaboration and interpersonal communications take place during a project. A team with high cohesiveness is likely to demonstrate effective team work, supporting members, common goals, efficient procedures and team spirit. However the group cohesiveness is strongly affected by cultural differences, the nature of the team roles and hierarchy.

Communication

The communication mechanisms supported in a team are likely to affect both the way individuals perform in their roles as well as the style followed when reporting to the project manager. The communication style of individuals may affect any team communication protocols and etiquette that may be in place.

Group Thinking

When decision-making and problem solving is based on group thinking and brainstorming there are two positive outcomes. First, the team operates as a single unit with aligned goals and objectives. Second, the commitment and motivation of its members is dramatically increased. However the main drawback is the time it takes for such group thinking to take place.

Homogeneity

Some organisations advocate the need for homogeneity in their project teams. In theory a group with members who are similar to each other should face fewer conflicts that are likely to reduce its performance. However, in today's global economy quite a few organisations choose to celebrate diversity and opt for heterogeneous teams. The main reason for this trend is that the diverse skills and perspectives of the team members may help the team to achieve a wider range of objectives.

Role Identity

An important performance factor is the degree of role identity that team members have. This means that members with a high level of role identity can associate themselves with role responsibility and feel that their role represents them and their contribution to the team. Such members are likely to have significant motivation and commitment levels.

Stability

The stability of the team is also an important factor as frequent changes may affect a team that is always trying to adjust change. Team stability is likely to offer an environment where conflict is rare and the focus is on project activities and deliverables.

Team Size

Finally, the team size plays an important role. For years there have been suggestions for optimum team size, depending on the role of the team and the project requirements. It is impossible to come up with an ideal number of members for a project team. However an increase in team size is likely to introduce communication overheads, increased probability for conflicts and problems, arising as well as a more complex structure.

78 The Project Plan

© ABE

Think Point

Provide two examples of how changes in the team size of a project may affect its performance. You need to consider increases or decreases in team size, the introduction of new team members, the removal of key staff members and the resolution of personal conflicts.

Review Question 4

List seven factors affecting project team performance.


E. PROJECT COMMUNICATIONS

All project decisions from project planning to schedule control and from risk management to activity sequencing are based on effective communication. The ability to generate, record, disseminate and exchange information is critical for the progress of a project. Communicating information throughout a project involves a number of key processes, including:

communications planning

information distribution

performance reporting

administrative closure.

Communicating Project Details to Stakeholders

Communication planning is based on establishing the information needs of the project's stakeholders. The underlying principle is that by establishing what kind of information each stakeholder requires, the necessary communications that must take place during the project are easier to plan and control.

Furthermore, the information distribution process should ensure that the project information is directed towards the stakeholders who require it. The process is concerned with the method that must be followed to ensure that this happens.

The performance reporting process deals with specific types of data and more expressly the information required to assess the project's performance. Such information is constructed in the form of reports that provide an overview of how the project performs in certain areas, reflecting on the project's progress in term of specific criteria.

The project closure is yet another phase that requires a wealth of communicated information for administrative reasons. The closing reports provide detailed reviews of the project's various aspects and a summary of the project life cycle.

Managing Project Communications

The way a project manager deals with the different project communication processes described in this section sets the communication management strategy for the specific project.

The Project Plan 79

© ABE

The communications planning process is based on:

identifying communication requirements

establishing a framework for supporting communication technologies

establishing an understanding of any communication constraints

making certain assumptions for the communication exchanges of the project.

A stakeholder analysis can be used to establish how the communication exchange will take place according to the information needs of each stakeholder. The communications management plan is the main output of the process.

The information distribution process is based on:

identifying a work plan that sets the time frame for any required information for each project activity

using the communications management plan to coordinate the information exchange

assessing the project plan in terms of information requirements for each activity.

The information distribution process is dependent on:

existing communication skills

the support of information retrieval systems

the use of information distribution systems.

The project records are produced as a direct outcome of the information distribution process.

The performance reporting process is based on:

a detailed project plan

work results

available project records.

Performance reporting provides information that is sourced from:

performance reviews

variance analysis

trend analysis

earned value analysis

information distribution tools and techniques.

The main outputs of the process are in the form of performance reports and change requests.

Finally, the administrative closure of the project is based on:

performance measurement documentation

project and deliverables documentation

project records.

The process output is in the form of:

project archives

formal acceptance of the project

lessons learned.

80 The Project Plan

© ABE

Describing Project Plans

So far in this chapter we have discussed how a project schedule offers a clear understanding

of how the project activities are linked. The project schedule is an essential part of the project plan as it offers the means to assess whether the project is in line with the suggested plan. Any deviation from the original plan is likely to trigger certain corrective actions from the project manager. Before we provide a more in-depth analysis of the project plan elements required for successful projects, we must understand the importance of a number of supporting plans that help the project manager to use the information available from different viewpoints during the planning process.

A plan of the human resources required for the project is essential. Such a plan offers a detailed overview of the project needs in terms of the workforce. Different projects show varying needs for a human resource plan and view workforce requirements from different perspectives. For example, more hands-on projects are usually dependent on the number of staff members who are involved in the project as well as on their work capacity. However there are some projects that are not dependent on numbers alone, but also need a quality assessment of what each individual brings to the project in terms of skills, knowledge, experience and capabilities.

Another very useful plan is the communications plan. This offers a detailed overview of the way communications take place in the project as well as the support required for such communications. The plan should identify all types of communication required for the project activities as well as a detailed description of how different communications should be supported. Periodical reports are used to summarise the communication taking place during certain project phases.

Furthermore, following from the discussion on risk assessment in Chapter 2, a risk

management plan is necessary for each project. The risk management report should provide a detailed outline of each risk area identified and a prioritisation of these risks. It should also provide a clear plan on how the project activities will be carried out in such a fashion that the risks will not affect the project progress.

Essential Elements for Any Successful Project

In the previous sections of this chapter the project planning process has been discussed in detail. The success of a project is reliant on a carefully created plan, but it is also dependent on a number of factors, such as:

project aims – these must be specific, feasible and suitable for the magnitude and importance of the project

project outputs – these must be well defined and tailored to the needs of the stakeholders

quality criteria – such criteria should ensure that the project schedule, plan and deliverables adhere to certain quality standards

project resources – these should be estimated according to the needs of the project activities

management structure – a structure should be put together based on a plan that may follow the structure of deliverables, activities, processes, team structures, organisational units, etc.

milestones – the identification of milestones depends on how the project phases and activities are broken up

tolerances – controlling the project resources so they remain within an expected or at least acceptable range means that the project activities will run smoothly

The Project Plan 81

© ABE

dependencies – the dependency between project activities should allow the smooth operation of the project and avoid idle periods for the project resources

risks – the identification of risks following a detailed risk analysis is likely to ensure the reduction of delays and spiralling costs

schedule – schedule management is always one of the primary causes of concern for project managers.

SUMMARY

This chapter has emphasised the importance of project planning and the effects of change in project schedules. It has introduced project management structures and discussed in detail activities in terms of the responsibilities assigned to personnel. We continued with a detailed review of project schedules and how these are affected by changes over time. The chapter concluded with a detailed overview on project communications.

82 The Project Plan

© ABE


Review Question 1

The project objectives (and hence the project goal) must comply with the SMART acronym meaning that the objectives must be specific, measurable, assignable, realistic and timely.

Review Questions 2

(a) The five main steps are: choosing a project manager, selecting project team members, assembling a project steering group, identifying a project champion and preparing a project management plan.

(b) The five main stages are: identifying the project deliverables etc., structuring the WBS, breaking down each WBS level to a more analytical lower level, assigning a code to each detailed component of the WBS and verifying that no further breakdown is necessary.

(c) The 16 main outputs are: project objectives, scope description, project requirements, project boundaries, project deliverables, project acceptance criteria, project constraints, project assumptions, initial project organisation, initial defined risks, schedule milestones, fund limitation, cost estimate, project configuration management requirements, project specifications, approval requirements.

(d) The six main inputs are activity list, product description, dependencies (mandatory, discretionary and external), milestones, constraints and assumptions.

(e) The two types are the precedence diagramming method (PDM) and the arrow diagramming method (ADM). The ADM can demonstrate four types of precedence relationships/dependency, i.e. finish-to-start, finish-to-finish, start-to-finish, start-to-start whereas the PDM can only deal with finish-to-start.

Review Questions 3

(a) The six main tools are project management software, mathematical analysis, simulation, resource levelling, coding structure, duration compressions.

(b) The five main tools are the schedule change control system, performance measurement, project management software, variance analysis and the iterative use of planning.

Review Question 4

The seven factors are cohesiveness, communication, group thinking, homogeneity, role identity, stability and team size.

83

© ABE

Chapter 4

Monitoring and Controlling Project Progress

Contents Page

Introduction 84

A. Progress Monitoring 84

Typical Problems Affecting Project Progress 85

Remedial Actions for Project Problems 88

B. An Approach to Project Control 91

Identifying Information Sources Indicating Deviations from the Desired Progress 91

Evaluating Status Information before Taking Action 95

C. Regaining Project Control 97

Calculating Variances and Slippage 97

Managing Deviations from a Planned Schedule 99

Summary 101


84 Monitoring and Controlling Project Progress

© ABE

INTRODUCTION

In previous chapters we discussed how projects are initiated, how their strategy is defined and how more detailed plans are formed. This chapter focuses on the project manager's efforts to monitor and control project progress. Each project requires continuous monitoring in order to assess whether the progress achieved matches the initial specification and the plan that was put together before project activities commenced. By monitoring a project we attempt to detect any issues arising while their impact is still relatively manageable. Furthermore, a successful project monitoring procedure should allow the project manager to identify the factors affecting the progress of the project as well as the effort needed to deal with the effects of these factors. We could view the monitoring of a project as a proactive approach that enables the detection and sometimes the prevention of events that may cause the project not to meet its requirements or follow its schedule.

On the other hand, controlling a project is a rather reactive approach to project management. The objective of controlling a project is to deal with any issues that require the attention of the project manager and typically some form of action. The reactive nature of the procedure means that a certain level of decision-making and problem solving is involved. It is necessary to fully appreciate that projects are rarely in line with original plans for various reasons. Therefore the role of the project manager is not limited to the development of a project plan and its documentation, but spans a number of areas that can be grouped together under project control. Such areas of concern could include measuring performance, assessing whether project requirements are met, dealing with problems, identifying risks, etc.

Objectives


list typical problems which affect the progress of a project

account for such problems and propose remedial actions

identify those sources of information which might indicate deviations from the desired progress of a project

explain the importance of corroborating and evaluating status information before taking action

explain how cost variances and slippage can be calculated

describe the courses of action open to the project manager in managing deviations from a planned schedule.

A. PROGRESS MONITORING

It could be argued that progress monitoring depends on the project's success and performance against certain criteria. One could say that the more successful a project plan, then the less monitoring is required. However this is not an attitude that can be realistically adopted, as there are several causes of problems arising in the project life cycle.

It becomes obvious that progress monitoring is necessary as it offers the means to identify project shortcomings. Issues affecting project performance are usually related to uncertainty in terms of what conditions the project stakeholders will meet once the project begins and during the production of its deliverables. We should try to identify some reasons for project problems and assess their effects on the project progress.

Monitoring and Controlling Project Progress 85

© ABE

Typical Problems Affecting Project Progress

It is not uncommon for people to have a genuine dislike of change, and we often find ourselves worrying about the unknowns that the future might bring. Projects and their managers are not strangers to such feelings, and it is quite common for projects to struggle to keep up with change or even deal with slight deviations from original plans. Even large projects may be affected, since smaller changes that accumulate over different stages may lead to a significant alteration of the project setting. Changes in the project environment may lead to catastrophic effects if the necessary adjustments are not made.

Configuration management is a field that deals with the specification of project requirements, the definition of project activities and the establishment of a project setting that offers the necessary foundation for the project deliverables to be achieved. However even the most thorough configuration management technique and visionary approach in project management may fail to foresee possible changes! Additionally, project managers may resort to altering management techniques to deal with change. Such a strategy requires the identification of factors that may affect the current situation. Furthermore, a number of different possible states may be identified following a potential change that may affect the project. The aim is to be prepared and put together a plan with well-defined and carefully designed actions that should help the project manager to deal with the changes identified in the scenarios.

Unfortunately there is no guarantee that the project manager can cope with significant changes or whether contingency plans will be implemented as intended. The project environment, stakeholders, resources and work plan are some of the reasons why change may prove too much to handle and may even lead to complete failure and the termination of a project.

Think Point 1

Provide an example of how external influences may introduce change to a project and discuss how you should prepare for its effects. You should be able to identify events from the immediate environment that may affect the project and illustrate how a clear strategy with well-defined actions should be in place.

Another reason for a project failing is the credibility of the project outcomes. This relates to people behaviour and may be influenced by external factors. More specifically, the project stakeholders may stop sharing the common vision and goals. This could manifest itself in failure to effectively use systems employed or delivered by the project. It may lead to users not following the exact procedures or project stakeholders showing less motivation and commitment. Such a scenario is quite frequent when pressure increases, leaving stakeholders in need of reassurance and morale boosting. Failing to keep high motivation levels is likely to affect the effectiveness of the workforce, so leading to disappointing performance. By monitoring certain indicators it is possible to identify which areas of the project are failing and identify the real causes. This should allow the project manager to react to low performance and ensure that project stakeholders remain advocates of the project scope and aligned to the mission of the project. However, we should reflect whether the mission statement that describes the original project scope was significantly affected by change.

Projects commonly suffer from prolonged periods of increased pressure on stakeholders and project workers and personnel usually find themselves operating under pressure for significant periods of time. During these periods it is expected that prioritisation of activities, goals and deliverables is the key to the project's performance, at least in the short run. In


© ABE

other words, it is possible for project personnel to focus too much on tasks that have an immediate impact on the project performance at the expense of performance in the longer

term. This is often the cause of project slippage (not meeting project deadlines) and may lead to significant deviations from original plans. Monitoring the project plan should be based on both short-term and long-term plans. By identifying early signs of the project missing long-term targets, it is possible to control the processes affected (for example by offering more training or increasing resources) and reflect on how short-terms tasks affect long term deliverables. This is an activity that needs the participation of both the project manager and the project members involved.

Projects should be subject to frequent periods of review and reflection, usually triggered by carefully planned milestones. This allows the identification of reasons for failure and possibly the cause for any deficiencies. An obvious choice would be to plan such reflective sessions and reviews after key deliverables are implemented, but this does not guarantee prompt identification of any problems or immediate corrective action. The project manager should decide the best way for introducing review tasks in the overall plan. Reviews should be performed in such a way that all parties involved participate.

Finally the size of the project may itself be the cause of problems as larger projects are more prone to changes. A sizeable project is likely to be broken up in various work units, involve several work packages, produce numerous deliverables and have a significant number of stakeholders. This means that the effects of change are likely to be great and the monitoring of the project rather difficult. The challenge is for the project manager to balance the size of the project to the available resources in such a way that change can be handled in manageable areas. While maintaining control of the overall project, it is possible to segment monitoring and the way any issues are dealt with.

What Happens in Reality

The progress of the project is likely to differ from what was assumed to be its expected life cycle. One of the most used techniques in establishing an estimation of the project's duration and timeline is based on identifying a critical path of activities. This offers an understanding of how many activities are required for the production of the project deliverables as well as the way activities are interrelated. Regardless of which technique is used to provide an estimation of the project's duration, there are various reasons for a project not meeting its original plan. It is necessary to understand causes for project shortcomings and their effects.

A typical effect observed with project monitoring is that project activities fail to meet original targets in terms of duration and use of resources. This means that project activities may run late, thereby delaying the overall project completion and changing the way resources are scheduled for specific tasks and deliverables. This does not necessarily mean that mistakes were made in making original estimations, since quite often delays occur due to unseen events and unknown circumstances.

It is necessary to monitor a project in order to ensure that all activities are completed within the time frame allowed by the project manager and serious consideration should focus on how these time frames are estimated. Usually, contingency plans are in place to help the project manager deal with uncertainties and unforeseen events. It is likely that when activities are planned, a safety margin is provided to allow enough slack time in case an activity requires more resources and time from that originally allowed. Unfortunately the safety margins are often insufficient, leading to further delays. The main concern is that project managers are highly unlikely to be prepared for such delays, since the provision of a significant safety margin should eliminate the possibility of delays in the first place.


© ABE

Think Point 2

The main issue relating to the monitoring and control of project activities relates to the feasibility of a contingency plan that is based on establishing safety margins.

Explain why contingency plans are necessary to deal with changes that may affect the duration of project activities.

In chapter three we have discussed WBS as well as a couple of activity network diagram techniques that are used to create work plans and describe the way activities relate to each other. Typically, such techniques allow for some slack time for each activity. When activities begin at the latest times allowed due to resources being used elsewhere, the project enters a phase where certain activities become critical. The fact that some resources remain idle while other resources are being used elsewhere (forcing an activity to start at the latest allowed time), means that it is likely for certain project activities to fail meeting deadlines.

A similar effect is observed when parallel activities are taking place, producing outputs that may be required for subsequent activities. In such cases, the most delayed activity will affect subsequent activities. The problem is that if several paths are leading to the same synchronising activity, the project may not proceed unless all activities are completed.

Projects must be monitored in such a way that any findings are informed within a time frame that makes immediate action feasible. Quite often monitoring provides findings at a point where any remedies are possible soon after the effects of any errors are visible. Sometimes monitoring results may show that the majority of activities are making good progress and only a small number of them are facing delay. It is important to avoid ignoring any early signs of any activities facing problems.

Another cause for delays is time wasted at planning stages or even the lack of efficient use of extra time given. Starting a project activity in time is crucial to the success of the overall project. Project workers should aim to start each activity at the earliest allowed time instead of using slack time to remain idle. If resources are available, there should be no reason for using the slack time at the early part of an activity rather than saving towards the end so it can be used as a potential safety margin.

Sometimes it is considered a virtue to be able to multitask any project activities that take place in parallel, and the ability to engage in a number of activities simultaneously is a desired skill among project personnel. It means that the project may operate in more ways and follow different pathways rather than those implied by a strict sequential approach. However there is a danger relating to multitasking: resources may sometimes spread too thinly, making it impossible to complete tasks in the specified time. Failure to design multitasking in a way that allocates the necessary effort to each activity means that there is a chance for the project to be delayed even more than would be the case otherwise (compared to the traditional sequential model where each activity follows its preceding one). One of the main reasons that multitasking fails is that several activities are associated with steep learning curves. This requires the people who undertake specific roles to invest time and effort becoming familiar with the new task while performing another task. Losing focus means that tasks that have been interrupted for a brief period may require additional time for personnel to re-familiarise with them, leading to wasted time.

Finally, project problems are frequently caused by incorrect estimates. It is quite common for project managers to request a rather vague estimate for the duration of a task. The reason this estimate is requested is for the project manager to get a rough idea of the project requirements and adjust any resources that must be safeguarded for certain activities. However, the initial estimation that has been given as an indication of an average period required for similar tasks may then become a formal deadline. In such cases the work plan is


© ABE

not based on justified deadlines and estimates that have been carefully calculated, but on speculations. In Chapter 3 we discussed the use of historical data by project managers for making decisions. Resorting solely on historical data and previous experiences from similar projects are not always good methods for estimating how long an activity will take.

Remedial Actions for Project Problems

It is certain that projects will face problems, some of which will be more challenging to address. There is almost no guarantee that a thorough risk management approach will ensure that problems and their causes are eliminated. Focusing on problems relating to project tasks, it is relatively safe to assume that a major remedy could take the form of following a more detailed approach in producing estimations with respect to the time and resources required.

So how should a project manager justify the time estimate that has been assigned for a specific activity?

The time required for the activity should be broken down into a number of elements that can be justified according to the work involved in them or the effects they have on the activity duration. These elements can be identified as follows:

Activity time

This is the time required for a specific activity to take place. It may take into consideration the number of tasks involved, any time required for preparation, supporting activities and prerequisites including resources made available.

Other activities

This is the time invested for other activities leading to the activity under consideration. It may be the case that certain outputs and interim deliverables are required that may affect when the activity can begin. This might be in the form of resources remaining idle, waiting for specific resources to become available or even for certain outputs to be produced.

Interruptions

This is the aggregation of all the occurrences leading to additional delays and leading to activity interruptions. There may be internal or external reasons for such delays and the extent to which the delay may affect a specific activity depends on when it takes place, which resource is being affected and whether an intervention is needed to resolve a deadlock or similar situation.

Safety margin

This is the time project managers should allow for each activity in order to have a feasible contingency plan prepared. The safety margin for each activity should not be viewed as an opportunity to remain idle, taking advantage of slack time. It is a period of time that should be used only when project activities are delayed for genuine reasons and for the purpose of ensuring that reasonable delays affecting particular activities do not cause the failure of the entire project.

One could argue that if projects are delayed even after activity duration is calculated with the foregoing elements in mind, then the project manager should reconsider the estimations they provided. All project managers know that activities are going to be delayed no matter what happens! However, there is no easy way to provide a schedule that includes overinflated time estimates. Such a schedule is likely to result in a rather lengthy project timeline and put project stakeholders off.

Even in those cases where a project activity is completed on time or early, the project may not gain any actual benefits. After all subsequent activities must take place, and these are usually affected by the safety margin accounted for. It is rather disappointing, but even when


© ABE

certain activities are completed earlier than the original estimation, the project is likely to continue according to the original schedule. The only time the project would gain from early completion of activities would be when these activities are rather late in the project life cycle and possibly when they are producing the final deliverables.

A very interesting observation is that the predominant method for measuring activity performance takes the form of the percentage of the activity that has been completed (the "completion percentage"). In other words, a project manager is not aware of how long the activity takes until it finishes, but only knows the percentage of completed tasks. This statistic may seem useful at first but can be very misleading. For example, a project that has 90 per cent of its key activity complete could lead to the assumption that only 10 per cent of specific tasks are left. However, there is no indication whether the remaining tasks will last proportionately longer than the ones already completed, e.g. 10 per cent of the tasks might take 25 per cent of the overall activity time allocation.

Measuring Against a Baseline

One way of addressing problems such as the ones discussed in earlier sections is to identify possible solutions that deal with the provision of more accurate or realistic estimations. The

theory of constraints offers a possible solution that takes under consideration the various factors affecting projects in manufacturing environments. A typical scenario is bottleneck situations, where the project resources or work plan proves insufficient to process the required tasks. The bottleneck effect means that tasks remain unattended while resources are scarce. The theory of constraints approach involves the following:

identifying the constraint

exploiting the system constraint

subordinating everything to the constraint

elevating the constraint

identifying further constraints.

These five stages of the theory of constraints approach can be applied to project management, regardless of the domain in which the project operates.

The identification of the constraint is important as it controls the way the project operates. A constraint can be determined by the critical path of the project, meaning the series of activities vital for the project success that must be completed as planned. However a constraint may take the form of resources that must become available during the project's critical path. It could be the case that the project constraint takes the form of unavailable resources, or ones that other projects are competing for. Furthermore, project constraints may take the form of important milestones and key dates that may impose deadlines that cannot be negotiated.

Although project managers should seek suitable dates for project milestones so that some flexibility is allowed, scheduling a project may need to adhere to given timelines and be affected by external influences. In addition, resources contention is a problem that may be caused when limited resources are distributed across projects that take place in parallel. When something goes wrong to one project then it is likely for the others to be affected.

The exploitation of the constraint means that the project manager emphasises the importance of ensuring the smooth operation of this part of the project. More specifically, the aim is to support the project area affected by the constraint as it is identified as the weak point. It is necessary to support any related activities to perform to their maximum capability. This can be achieved by eliminating any factors that may cause inefficiencies. For example, additional resources may be brought in to help the


© ABE

existing workforce, or equipment may be put on standby to avoid wasting time while machinery is being fixed or is needed for another project.

The subordination of everything else to the constraint means that the project manager's full attention is geared to ensure that the constraint area operates at its maximum. This means that the project manager and any stakeholders may even change the way they do things in order to avoid the constraint affecting the whole project. For example, if a member of staff is key to all projects (e.g. involved in final reporting or evaluation tasks) it is important to ensure that all necessary resources are available and that this individual's involvement remains uninterrupted. Furthermore, if an activity is critical for the success of the project, leading to a specific deliverable, no competing activities should be scheduled at the same time.

By elevating the constraint the project manager may succeed in removing it from the project identified constraints altogether. In order to achieve this, the project manager must be able to identify how the constraint may benefit from an increased flow. For example a team that deals with the assessment of project deliverables may be allocated more members or receive additional training. The more the invested resources and the higher the received support, the easier it is to remove a project constrain.

Think Point 3

Using an example, explain how each step of the theory of constraints approach can be used in sequence to allow constraints to be identified and addressed, and how this facilitates measuring a project's performance against its baseline.

Review Questions 1

(a) How does the size of the project affect the way both internal and external changes are handled?

(b) How should project managers monitor activities that take place simultaneously leading to project milestones which require their outputs?

(c) What is the benefit of including a safety margin when calculating the duration of a project activity?



© ABE

B. AN APPROACH TO PROJECT CONTROL

So far, this chapter has emphasised the importance of monitoring projects and identifying what might go wrong with them. By identifying the project problems and their causes, it is likely that the project manager can deal with them and support the project towards its completion.

A successful implementation of a project monitoring plan is likely to lead to an effective project control approach. The aim should be to ensure that each activity is controlled in such a way that the project requirements are met and the transition from the activity's input towards its output is smooth. The most primitive form of a control mechanism should view each activity as a process that requires certain input and produces the corresponding output. In order to control this process we need to produce sufficient feedback that is then used for any subsequent activities or for further iterations that may be required for the particular activity. Such feedback may be in various forms as far as it provides adequate information of what has gone wrong with the activity, and it may possibly offer suggestions for remedial actions.

So it is necessary to introduce control systems that allow project managers to assess how the project performs against certain criteria. The path followed by the project is determined during the initial planning stages, while control systems are used during the implementation of the original plan. Corrective actions may be possible following the feedback received by the monitoring systems.

We can identify a number of important requirements for controls systems, including:

identifying key characteristics

determining an acceptable range for such characteristics

measuring control characteristics

supporting progress visibility

providing performance related feedback

supporting corrective actions.

Identifying Information Sources Indicating Deviations from the Desired

Progress

Assuming that a project has a control system in place that is in line with the project plan and closely monitored by the project manager, we should be able to identify the different requirements of such a system. The key characteristics of a control system may change slightly due to the nature of the project, but in most cases they fall under three main categories:

cost

time

quality.

Some projects may require additional characteristics to be included in the core of their control processes, but it is unlikely that these will not somehow be related to the ones already identified.

Being able to control the project cost means that the project manager is in control of the budget, and any identified resources and supplies are obtained according to the proposed budget entry. This is imperative as spiralling costs and erroneous estimations of project-related costs may lead to the project cancellation or eventual trade-offs. It is important to ensure that all activities remain within budget, and any justified extra expenditure is either


© ABE

compensated with additional output or rectified through the optimisation of other aspects of the project. There is always the danger of external forces affecting the project, as various industries may be affected by petrol prices, food prices, manufacturing costs, etc.

The project time depends on what the project priorities are. The attitude towards any missed deadlines reflects not only the abilities of the project manager, but also the project environment, its nature and the performance and behaviour of its stakeholders. Time is an important factor for projects, as project managers try to control the time spent on each project activity, as well as the way time is estimated during planning stages. The time required for project activities is likely to affect their costs and the availability of any associated resources.

As mentioned before, it is common for projects to undergo certain trade-offs following miscalculation of either time or cost aspects of the project requirements. Unfortunately the

easy option quite often takes the form of reducing the quality of any deliverables, and a detailed discussion of the quality concept follows in Chapter 6. For now note that quality can be determined in terms of a number of different aspects of the project including its deliverables, the way activities are performed, support towards the work of stakeholders, etc. A rather harmonised approach in controlling project quality is by using widely accepted standards, dictating the expectations for various project aspects. Using a known standard ensures that the project manager can measure the performance of the team and the progress of the project by using existing benchmarks to assess the quality of project outputs and deliverables.

The project characteristics described so far (cost, time, quality) offer a way to control the project, but sometimes the trade-offs required are difficult to determine. The project characteristics may vary depending on what is feasible, but there should be certain limitations to the extent to these variations. These limitations provide a range of acceptable margins for issues such as time and cost. For example, the maximum allowed underspend in a project phase, or the time elapsed after a deadline before the project is cancelled.

An important aspect associated with the definition of limitations to the variation of project characteristics is the measurement of such characteristics. There needs to be a method of measuring project characteristics for the purposes of both monitoring and controlling the project. The measurement is likely to take place in the form of input, processes and output. Each measurement may require input that may be provided by project activities or observation of project performance. The input is likely to be in the form of raw data that can be used to assess whether performance deviates from the expected criteria. There is also the possibility for certain processes to be required in order to check whether work patterns and activities are performed as planned. Finally, the output should be in such a format that would allow the project manager to determine which performance indicators are outside an acceptable range and whether immediate corrective action is required.

To maintain the motivation and commitment of the project team, controlling processes must be transparent. By establishing a visible process of measurement and control we enable stakeholders to become aware of what is going on as part of the project control mechanisms. This also means that project workers can understand why the project needs the corrective actions taken. Project workers who are unable to comprehend what is going on and perceive the project manager's actions as ones based on unjustified decisions are unlikely to show high levels of commitment. The role of feedback is very important here, as it offers the means for a project manager to narrow down any problematic areas and provide information to those involved with specific activities of what is required to rectify problems.


© ABE

Think Point 4

Explain why the transparency of project control procedures is so important for maintaining high levels of motivation and commitment. How does transparency affect stakeholders and project workers? What implications does it have for stakeholders?

The corrective actions taken by a project manager are typically dictated by the performance indicators and monitoring results. It is not uncommon for (project management) flow charts to offer suggestions for the most suitable actions to be taken once monitored activities have slipped from optimum performance. However the experience of a project manager is an aspect that we should always take under consideration when corrective actions are decided. More experienced managers are likely to have seen similar problems in the past, and so even at early monitoring stages when measurements are not available they are able to make corrective decisions based on knowledge and intuition.

Using Documentation Wisely

In order for project documentation to be useful, it has to include some key characteristics. Project documentation should allow a prompt identification of important events and project performance patterns to support an accurate and speedy monitoring process. Furthermore, the level of detail in project documentation is essential as there is a need for adequate information in order to identify the actual causes of any deviations from project plans. This is crucial for a successful controlling procedure.

Therefore we may identify the main features of a project-reporting mechanism as follows:

Information should be timely and reported within a reasonable period following the implementation of each project activity.

Information should be accurate and detailed in terms of what has actually happened and how it relates to the planned activity outputs and project deliverables.

Information should be complete in terms of the project phase involved as project managers must be able to make decisions without being misled due to partial information that does not show all related aspects.

The process followed should not be time consuming and add unreasonable time and cost overheads to the existing project workload.

Resulting documentation should be in a form that may be easily used by project managers and other project stakeholders in order to make decisions and take corrective actions.

Resulting documentation should be trusted and acceptable by anyone who is likely to use it. This requires ensuring that the procedure followed is such that the recipients of any reports regard them as accurate and from a trustworthy source.

Resulting documentation should be conclusive and relevant in terms of determining any problems and their causes as well as the time frame for their creation, as they must help towards fast recovery of any project activities.

Resulting documentation should have sufficient clarity in order for the intended users to use it effectively. There should be no unnecessary complicated structures and extensive documentation usually created by bureaucratic procedures and excessive analysis.

There are several types of project report that are created during a project life cycle. It is likely for project managers to identify the nature of information included in each report as well


© ABE

as its description, structure and title when they identify work packages and project deliverables. The main types of reports may include:

current reports

cumulative reports

exception reports

stoplight reports

variance reports.

Current reports may be used as snapshots of project performance as they offer an accurate representation of the current project situation. The aim is to provide project managers with information relevant to project activities at given times. The main aim of such reports is to gain awareness of project status with some assessment of performance indicators. It is likely for such reports to include some suggestions regarding the areas of the project that are not performing according to the plan. A current report should also identify possible causes for the identified issues and problems and provide suggestions for any corrective actions that may be required in order to get the project back on track.

Cumulative reports are required because they offer a historical view of the project. Such a report uses archived information and historical data to provide a view of how the project has performed over a significantly long period. The report may be focused on specific activities, project phases, or any other project aspects that may be tracked back to the beginning. The underlying principle is to offer a historical perspective and demonstrate any changes that may have taken place over different periods. This kind of report is used frequently as a reflective mechanism for project managers in those projects that extend over longer periods and may be affected by external events or perhaps key decisions.

Exceptional reports are different in their scope as they do not focus on a thorough analysis of a vast array of project features. The aim is to summarise issues relating to project exceptions such as deviations from original plans. The reason for such reports is for project stakeholders to become aware of any issues. It is quite common for such reports to be used by managers to consider critical situations and make decisions that could affect the future of the project.

Stoplight reports are usually associated with specific stages in the project schedule and are used to offer a summary view of the project performance. There are numerous variations of such reports where each activity, resource, deliverable, phase or any other project structural unit is assessed in terms of performance and progress. The intention is that the report does not offer a detailed overview of what is wrong, but can be used to acquire an accurate and summarised view of any project aspects of concern.

Finally, variance reports are used to compare the performance indicators for a number of identified criteria. These criteria may be selected by the project manager or be part of pre-selected ones that are used for all projects within the organisation. Such reports are usually the means of comparison between different projects or even used for assessing performance of project managers and the projects they are responsible for. The report is constructed around the list of performance indicators and three entries that represent the

planned performance

actual performance

difference

between the two performance measurements. The formatting of this report may be textual or visual depending, on the use of the report. A summarised table of variances is more useful for a detailed calculation of time slippage, any additional resource requirements and costs


© ABE

associated with the identified variances. A visual representation of the report is more useful when an illustration of the project performance is needed.

Evaluating Status Information before Taking Action

There are several reasons why project managers must be capable of evaluating the status of the project before taking any further action. When evaluating a project, it is necessary to identify a number of aspects that should be reviewed including quality, cost and time.

Once certain quality criteria are determined for the deliverables of a project as well as the way these deliverables are achieved, it is necessary for the project procedures to conform to the quality requirements. It is evident that quality requirements must be met in order for the project to be in line with its prerequisites. An additional viewpoint on quality is the fact that once a project fails to meet certain quality criteria, it is open to criticism. Its deliverables may not be acceptable and the processes followed for the project outcomes may be characterised by negligence and lack of conformity to standards.

An interesting perception of project evaluation is that certain expectations are created following the project's initial planning phase. It is critical for projects to deliver on promises and expectations made, as such performance measures may be perceived as a measure or indication of quality.

Controlling project costs is another aspect of project evaluation. It is quite often the core of project management scope, as spiralling costs are usually the reason for failing projects. The project manager may control costs by:

classifying costs according to the identified budget needs and any financial functions relating to project activities

analysing financial data to identify any problem areas or surplus of funds

allocating financial responsibilities to role holders and stakeholders who are involved with specific project activities

allocating costs and resources to different project phases and activities

evaluating whether project costs are spiralling without proper justification

authorising payments and controlling budget and expense claims

competing for budgets and resources with other projects.

Think Point 5

By reference to some of the techniques for controlling project costs explain how controlling project costs may affect the key activities of a project, for example by the introduction of further resources, rescheduling, etc.

Project Monitoring and Control: Bodies of Knowledge

Project management bodies of knowledge with respect to project monitoring and control include the Association for Project Management (APM) and the Project Management Institute (PMI).

APM body of knowledge areas:

Change control (section 34) – recognising that projects are subject to change and the need for stakeholders to be involved in dealing with change. The existence of a documented change system means that any possible changes are identified as well as the impact of changes to the project progress.


© ABE

Earned value management (section 35) – requiring the measurement of the value against cost of various project activities and stages.

Configuration management (section 46) – offering an assurance function for each project deliverable.

PMI body of knowledge areas

Integrated change control (section 4.3) – dealing with the control of changes, the evaluation of their impact and the assessment of the project performance following radical changes.

Scope change control (section 5.5) – determining the impact to the project of any changes to the original project scope.

Schedule control (section 6.5) – offering the means to cater for changes while maintaining the original project scope following revised project schedule of any activities.

Cost control (section 7.4) – introducing systems that control and track costs associated with project activities.

Quality control (section 8.3) – ensuring that quality control takes place in project procedures and processes.

Performance reporting (section 10.3) – reporting on project performance based on the collection of performance data and the evaluation of project performance indicators against initial plans.

Risk monitoring and control (section 11.6) – identifying, quantifying and mitigating risks in various stages of the project life cycle.

Being Objective about Threats

The estimation of threats varies significantly, depending on how a project is managed. The way threats are perceived may depend on the organisation's perception of risks. There are organisations that cannot afford any tolerance towards failure and risks. Such organisations are likely to introduce high control strategies that do not allow slippage and delays. This means that project activities may include significant overheads in the form of reporting mechanisms and progress-monitoring techniques. In addition, possible deviations may trigger corrective mechanisms that may affect the way personnel perceive the activity and introduce stress at the workplace. The main danger would be for staff members to focus on deadlines and performance indicators rather than project goals and quality criteria.

On the other hand, organisations that may have delegated project control entirely to the project manager are likely to have in place a low control policy that avoids regular monitoring and detailed reporting. In such cases there are likely to be certain cut-off dates that are used once the project is delayed beyond a reasonable period or spiralling costs exceed an affordable budget.

The individual style of a project manager may also affect the way a project is controlled. There is always a dilemma that project managers must find an answer for, since risk is directly linked to the level of control. Managers must decide whether they prefer to operate in a project environment where limited control allows more flexible work patterns. However, such practices are likely to lead to higher risks and possible failures and deviations from the original plan. A key factor affecting such a decision is the associated costs as there is an additional price tag for each controlling procedure that is implemented. Obviously there is an associated cost for rectifying any failures and dealing with risks. It is therefore important for project managers to assess whether it is more realistic and less costly to manage a project in a more controlling manner, or allow for higher level of risks in anticipation of dealing with any problems rising as they appear.


© ABE

Review Questions 2

(a) What are the main aspects of a project control system?

(b) What are the five different types of project reporting that may be used for monitoring?

(c) What are the main concerns for projects that have low levels of control with respect to associated risks?


C. REGAINING PROJECT CONTROL

The previous section emphasised the importance of documentation in project monitoring and control. The preparation of such project reports is necessary to provide the information

required for control activities. These activities are needed when project managers become aware of project characteristics that are not in line with what was expected.

Project reports are regarded as the necessary form of documentation to be used as the reference for any actions undertaken as part of the project phases. Furthermore, project reports can be used to provide information regarding the project implementation stages and to associate the deliverables implemented with those in the initial plans. Project reporting may be used primarily for:

tracking project progress

detecting variations from plans

taking corrective actions.

A project report should be structured around project phases and any associated activities and tasks. The aim should be to offer an accurate view of how the project performs and whether the project performs according to certain performance indicators. A project report should also be a trusted source of information, one which can be used to estimate how the current project performance relates to the optimum performance indicated in the planning stages. This should allow an appreciation of how difficult it will prove to make necessary adjustments and bring the project back to the required performance track. Finally, a project report should provide sufficient indication of any sources of inefficiencies, delays, spiralling costs and similar aspects of poor performance. In order to use project reporting in an effective way, it is necessary to follow certain techniques available for the calculation of deviations.

Calculating Variances and Slippage

The main types of variances measured in projects relate to cost and time slippage. There is

also the measurement of effort variations that indirectly relate to the additional costs

associated with extra effort required, as well as the duration slippage associated with lack of effort in the form of idle resources.

In order to calculate such variances we need to establish a strategy that is in line with the project scope. The project scope is likely to be described as a number of objectives and clearly determined goals. These objectives must be achieved through the optimisation of the resources available for project activities. There are several reasons why the measurement of variances from such optimum performance is critical for the project's success:


© ABE

Identifying deviations at early stages – the sooner we identify the deviations from the planned and expected project costs and duration, the easier it becomes to put together a plan of how to ensure the project returns to the required state.

Reducing fluctuation – it should be expected for changes to occur in projects and for certain fluctuations to take place in a number of performance indicators. Project managers should be able to control such fluctuations and ensure that any contingency plans and allowed margins are used to ensure the project operates as required. It is necessary to be aware that fluctuations from planned measurements will exist. As far as these fluctuations are reduced to acceptable levels, the project will continue its life cycle without any critical obstacles and the need for major adjustments.

Nurturing early corrective actions – there are no reasons for delaying any corrective actions, allowing the accumulation of deviations. By failing to address any identified issues as early as possible, project managers may not be able to deal with the detected problems at later stages. There is always a critical point which, once reached, means it is unlikely that existing resources will be able to cope with the extent of deviation (from the required costs and duration).

Determining schedule variances – it is necessary to establish a regular evaluation of the schedule measurements and assess how each activity and project stage progresses in relation to the initial project plan.

Determining effort variances – it is also necessary to monitor activities in terms of workforce effort and resources used. This should provide not only an indication of progress, but it also supports the determination of any additional costs associated with resources required by project activities.

It is necessary to build on these objectives for measuring variances and establish a plan of how to determine problems and introduce their solutions promptly.

Optimising Project Excellence

In working towards project excellence by optimising performance, project managers always attempt to improve the output of projects by improving planning and procedures. Of course, once the project begins and changes start to occur, the only action possible is to monitor and control the project performance. This means addressing project issues as they begin to appear.

Project managers may focus on following an iterative approach in evaluating the project output and updating the information stored for project progress. There are several areas where regular updates should enhance control, and the following list is indicative:

Timing any project updates – it is necessary to follow a consistent pattern when updating project information as this allows project stakeholders to work on the same set of data and be aware of the actual progress of the project.

Reporting on tasks completed – the ability to monitor a project is dependent on regular updates of how the work of the project progresses throughout its stages. It is important to monitor every project activity and provide information on their completion.

Recording historical information – based on previous projects of similar nature it is possible to use historical data to make decisions and establish an understanding of certain patterns shown with respect to project activities and overall performance.

Estimating remaining work – the evaluation of each project activity that is not completed should be done in such a way that its rescheduling and the estimation of the remaining resources required are possible.

Reporting on start and finish milestones – a progress report should always be based on the start and end dates for each project stage and all associated activities.


© ABE

Reflecting on duration and progress – the project progress should be measured in terms of activity performance, meaning that each activity is measured for its duration so far and the estimated time required for its completion.

Reviewing effort and resources – offering the means to measure the effort invested so far on project activities is critical for the assessment of the project requirements and progress. This should be followed by an estimation of the resources necessary for the project's completion.

Providing completion rates – the overall project completion measurement should be based on reports for the project's duration, resources and costs.

Managing Deviations from a Planned Schedule

In earlier sections and chapters we discussed project plans and how important they are for the project's success. We explained a number of methods used for the estimation of work required towards work packages and project activities.

So far we have expressed concerns about variances to the project plan. The reason is that most deviations are viewed from a negative perspective. This means that projects are delayed, incur more costs and require more resources. These negative variances mean that the project manager must act fast, based on any provisions made when putting together the project plan.

However, there is also a chance for positive deviations to take place following the efficient use of resources and leading to activities being completed in time or before their deadline, with less than planned costs and fewer resources. This seems an idyllic scenario, as the project will benefit from the extra resources and funds that become available to the remaining project activities. There is a downside of positive deviations relating to the project schedule: project activities completed quite early may lead to idle resources.

Recognising Multiple Success Metrics

There are several methods for assessing project progress and ensuring that the project manager is aware of any issues affecting performance. Typically, some of these methods are computer supported and are based on the use of software tools. The existence of graphical reporting tools helps project managers to obtain a visual representation of the project's standing and an indication for any required corrective action or sources of concern.

The use of Gantt charts is very important as they can represent the project life cycle in a series of tasks that are described based on the overall schedule with their start and end dates being clear. The resources needed and the responsible stakeholders are identified in Gantt charts for each project task.

The use of Gantt charts may help to identify:

missed milestones

failing tasks

slippages

successive slippages

significant changes

shifting schedules.

These are some of the issues that may affect a project drifting out of control, it being affected by external factors or influenced by lack of resources. The project manager should try to evaluate the Gantt chart findings and decide the most suitable actions.

A Gantt chart may have several forms depending on the detail required in the specific project, the style adopted by the project manager and any existing software tools used by the


© ABE

organisation. In its simplest form, a Gantt chart will include a list of activities in a hierarchy based on the chronological order of the start dates for each activity. Each activity is associated with a bar that spans across a number of time units, indicating the duration of the activity. Figure 4.1 shows a very simple example.

Figure 4.1: A Gantt Chart

Activities Weeks

1 2 3 4 5 6 7

Activity 1

Activity 1.1

Activity 2

Activity 2.1

Activity 2.2

Activity 3

Another method of assessing project progress is cost schedule control, which utilises the project financial data. This method allows mapping the planned activities to the actual work undertaken. As the initial plan includes the budgeted funds for each activity, the cost schedule control provides an understanding of how much the project costs at each given time and relates it to the planned costs for the exact same period.

The work breakdown structure may also be used as a method for reporting on project progress. As the WBS offers a breakdown of work packages and deliverables, it offers the means to assign a completion tag for each element of the structure, helping the project manager to evaluate the project performance in general.

Review Question 3

List eight ways of evaluating the output of specific project activities.



© ABE

SUMMARY

This chapter has discussed the main principles associated with project monitoring and control. We started by focusing on typical problems affecting a project and a reality check of project performance. The first section of the chapter concluded with an overview of remedial actions supporting the project to return to its optimum performance. The next section described how a project baseline may be used to reflect on the impact of change and any problems rising and emphasised on the importance of project control. A detailed review of information sources for data indicating progress deviation explained how project managers may stay in control of project activities. We discussed how documentation and project reporting support the project control efforts. Associating the project evaluation findings with corrective actions leads to considering threats and risks. The last section concluded with the calculation of variances and slippage and the ways to manage their impact to the project activities.


© ABE


Review Questions 1

(a) Larger projects are more susceptible to changes. There are likely to be several work packages, many deliverables and a significant number of stakeholders. So the effects of change are likely to be great and monitoring difficult. The project manager needs to balance the size of the project against the available resources in such a way that change can be handled in manageable areas, by segmenting the monitoring process and the way any issues are handled.

(b) Simultaneous activities need to be monitored in such a way as to ensure that any findings are informed within a time frame where immediate action is feasible.

(c) To ensure that reasonable delays affecting particular activities do not cause the failure of the entire project.

Review Questions 2

(a) A project control system must be able to: identify key characteristics; determine an acceptable range for such characteristics; measure control characteristics; support progress visibility; provide performance related feedback; support corrective actions.

(b) The main types of reports may include: current reports, cumulative reports, exception reports, stoplight reports and variance reports.

(c) Compliance with cut-off dates and ensuring that costs remain within budget.

Review Question 3

By: timing any project updates; reporting on tasks completed; recording historical information; estimating remaining work; reporting on start and finish milestones; reflecting on duration and progress; reviewing effort and resources; providing completion rates.

103

© ABE

Chapter 5

Dealing with Team Structures and Leadership

Contents Page

Introduction 104

A. Organising Suitable Team Structures 104

Criteria Affecting the Team Role 105

Effective Team Organisation and Management 106

Comparing and Contrasting Teams Organised on Functional, Project, Matrix and Contract Structures 112

B. Strategic Approach to Effective Leadership 116

Key Leadership Skills Desirable in a Project Manager 118

Influencing the Motivation of Team Members 124

Summary 128


104 Dealing with Team Structures and Leadership

© ABE

INTRODUCTION

When dealing with the management of an organisation's resources, it is essential to establish a strategy for supporting the project structures (discussed in detail during the earlier chapters) with appropriate team structures and leadership style. A necessary consideration is to identify how human resources may affect the progress of the project and whether a specific plan must be in place.

There are three very important aspects of project management that relate to the way the human resources are structured and organised in a project, and we will discuss them in this chapter. It is critical to be in control of the way a project addresses issues relating to:

team formation

role allocation

leadership.

Before introducing methods and techniques that may be used when putting project teams together, we must be aware of the fact that each project may have certain constraints that will affect the way teams are structured. For example, a project team may be inherited from a previous project, or certain roles may belong to individuals who possess specific skills, knowledge and experience. There may be other influences on the team structure, depending on the nature of the project, the available budget for personnel costs, scheduling, availability of skills and other limitations imposed at organisational or even at project level.

Objectives


explain the importance of effective team organisation and management

compare and contrast teams organised on functional, project, matrix and contract structures

list and discuss key leadership skills which are considered desirable in a project manager

discuss the actions and decisions by which a project manager can influence the motivation of team members.

A. ORGANISING SUITABLE TEAM STRUCTURES

When putting together a project team, we must be absolutely clear of the role that this team

must fulfil. We need to determine the strategic decisions that must be made for the teams to be structured in such a way that ensures:

achieving the project objectives

working efficiently towards the project deliverables

dealing with any project tasks and team-related problems

communicating effectively

performing according to the project plan

engaging in decision-making and problem solving

supporting the project stages and allocated activities.

These are only some of the benefits to a project that may be achieved by putting together the right team. However this is not a simple task, and making sure that the requirements for team structure are identified is a necessary first step.

Dealing with Team Structures and Leadership 105

© ABE

Criteria Affecting the Team Role

The process of creating a project team should begin by identifying the role of the team. For certain project types, the team role can be defined by determining the scope of the project deliverables for which the team will be responsible. This means that the project team must be created in order to fulfil a functional need. A number of functional specialisations can be

defined in order to classify the type of team structure. Some examples of team

specialisation may include:

research and development

sales

marketing

engineering

human resources.

These are functional areas where most team members should be able to operate, possess relating skills, qualifications and prior experience.

Apart from the function performed by teams, there are several additional criteria that may

affect the method chosen for structuring the team. Some of these criteria may include:

Products

An organisation's scope may be to create and deliver specific products, and teams may be structured in such a way that their focus is on specific product ranges. Examples could include manufacturing companies producing cars or computers. The production teams must be specialised in certain product ranges in order to demonstrate optimum performance, and be experienced enough to troubleshoot any defective components and deal with rapid shifts in requirements and other product related issues. The focus is on product development specialisation and specific skills.

Customers

An organisation may include a customer-centred department where after-sales support or pre-sales services are provided. Teams may be structured to deal with customer needs of different natures and sometimes such needs may span across different levels of specialisation. The customer demands and the level of attention required may also affect who becomes part of the team. Such teams may include teams dealing with specific customer problems (e.g. product-related queries, customer account enquiries), and may differ according to the customer prioritisation. Customers may be classified depending on their importance for the organisation, the severity of their case or additional factors that may depend on the business model. An example might be health services projects and how different customers (i.e. patients) have different requirements and are supported by teams with different focuses (e.g. accident and emergencies teams, planned admissions teams). The focus is on determining customer groupings and classifying teams and their members accordingly.

Services

An organisation may provide services to customers, other organisations or as part of its internal operations. In such cases, team structures correspond to the way services are organised. An example is an organisation offering mobile telephony services. A range of sub-services are included in the overall service that is perceived as the provision of a mobile phone service. Such services may support the customer in: (i) creating an account; (ii) selecting the most suitable service; (iii) ordering related products and additional services; (iv) dealing with any problems; (v) troubleshooting services and products; (vi) operating the phone network; (vii) billing; (viii) updating records, etc.


© ABE

Focus is on the kind of support different services require and how different teams may handle queries relating to each service.

Location

Organisations are quite often constrained by their physical structures. So if an organisation operates in different countries, and/or is dispersed over a number of remote locations (e.g. different cities) and includes complex building structures, the teams that are created may follow the same model. It is not uncommon for organisations to have remote structures where individuals or entire teams work from home, travel between locations and may involve various time zones and different cultures. There are several examples of such models in today's workplace, where multinational organisations utilise various work styles imposed by location. Here the focus is on how the location constraints will not be allowed to affect the performance of a team by introducing availability conflicts and bringing together team members that satisfy the location criteria but fail to meet requirements relating to their abilities.

Function

Larger organisations include several departments that have a predominant specialisation. These organisations require the support of cohesive functional teams. Examples of such teams may include finance and sales departments, and marketing and creative divisions as well as IT and warehouse teams. These structures are primarily organised with respect to the function (quite often mapped to specific operations) they perform for the organisation. Focus is on the functional skills that team members bring to the team and how they relate to the organisation's operations they support.

Think Point 1

Choose a number of criteria that may affect your decisions when structuring a team and propose a strategy for putting together a project team.

You should focus on three or four criteria such as product ranges or services and consider how these criteria would change the way your team is structured as well as the way it performs. You should also assess how your team would change if further criteria were to be added at later stages.

Effective Team Organisation and Management

So far we have discussed a number of criteria that may be taken into consideration when structuring a team. Organisations are usually based on hierarchical structures when they group together their personnel. It is easier to deal with the organisation and management of an organisation's workforce by establishing a method that reflects the nature of work.

For example, a hierarchical structure may be used to demonstrate how the organisation roles begin from lower levels that may include individual employees and team managers, lead to middle and line managers, before reaching the higher level of head of departments and directors. Such a hierarchy is based on the job title and the classification of roles in the organisation.

However, other examples of workforce hierarchy may be based on additional criteria. Such criteria may include responsibility, management overheads, corporate culture, line management, etc. The organisation's workforce may be organised according to the responsibility associated with specific roles. In such a hierarchy the structure takes under consideration the authority associated with the role rather than the job title used to describe


© ABE

the role. The line management approach establishes a clear link between roles, and uses reporting responsibility as the criterion to allocate individuals to specific groupings. Management overheads may also be used to assign members to teams and create structures that correspond to the organisation's available resources. Obviously the underlying corporate culture is essential in determining how the proposed hierarchies are implemented at operational level.

It is essential to understand the importance of team structures in organisations. Putting together a team should be based on an identified need to group together individuals, their skills, knowledge, experience and even personalities. There are several characteristics associated with the nature of teamwork that manifest themselves once the transition from being an individual member of the organisation's workforce to a team member takes place. Some of these characteristics are:

the benefit of creating a pool of skills and expertise by grouping together team members

the ability to engage all team members in decision-making and problem solving

the involvement of team members in operations by sharing their different perspectives and capabilities

the alignment of skills and capabilities of team members to meet the needs of project tasks

the harmonisation of team operations and activities

the improvement of team effectiveness and exploitation of team member capabilities

the reaction to identified risks and performance obstacles

the development of an environment-fostering commitment and motivation among team members.

There are several models that can be used to describe how these characteristics change with time. Teams evolve from their original structure and they can be viewed as organisation units that have a life cycle consisting of several stages. The team performance and the behaviour of its members differ, depending on the life cycle stage.

In 1965, Bruce Tuckman introduced a four-stage model that describes the way a team's performance evolves over time. The four stages are:

Forming

At this stage, the team is unable to operate without a clear leadership style. The team leader must maintain control as it is difficult for the team to agree the aims and objectives for key operations as well as the way team members should work towards their responsibilities. The forming stage is concerned primarily with the formation of the unit from its members rather than focusing on the project tasks.

Storming

At this stage, the team has become an entity that shares common goals and decides on how these goals can be achieved. However, during this stage the need for brainstorming and decision-making provides challenging experiences for team members with different viewpoints, personalities and agendas. The storming stage is concerned mainly with the coaching of team members in order to maintain smooth working relationships and acceptable performance.

Norming


© ABE

At this stage the team becomes a more cohesive structure where members are engaged, and team roles and responsibilities are clear and widely accepted. Each team member demonstrates evidence of wider participation, sharing and an ability to deal with delegated tasks. Decision-making and problem solving are more effective, while leadership becomes a shared responsibility with respect to certain tasks. The norming stage is focused mainly on establishing a leadership style that is based mainly on facilitation of team member initiatives.

Performing

At this stage the team is capable of dealing with its project tasks without any major assistance through clear and specific procedures. Any decision-making and problem solving requires no more than simple facilitation support. There are no major conflicts to resolve and team members operate as a unit. There is companionship and evidence of joint responsibility of project tasks. The stage is focused on achieving performance targets with minimum intervention.

In 1975, the Tuckman model was revisited and revised to include a fifth stage:

Adjourning

This stage focuses on how the break-up of a team must take place. The aim is to ensure that the team should end its operations in a way that does not detrimentally affect team members. This is necessary when a team has been together for a long time and team members have shared common work patterns.

Think Point 2

Consider Tuckman's model by using it in a hypothetical scenario of a project team that must operate on a project of your choice.

Depending on the scenario you choose you should identify each of the five stages for the project team and identify the main issues relating to the way its members will operate. Your focus should be on distinguishing how the team increases its effectiveness while shifting from one stage to the next.

Similar models provide a detailed representation of a project team's life cycle. Depending on the organisation's scope for putting together project teams, team life cycle stages are identified accordingly. For example typical team life cycle stages may include:

Team formation

At early stages the objective is to bring team members together and establish a plan of which skills and capabilities are required for the project tasks to be achieved. The team formation should take under consideration existing team member profiles and the avoidance of personality conflicts.

Role allocation

The next stage is to allocate roles to each team member based on individual skills and the project needs. The role allocation should take under consideration the role attributes and the characteristics of the individual member.

Harmonisation

Once roles are assigned and project tasks and their responsibilities are allocated, it is necessary to perform housekeeping tasks such as resolving conflicts, prioritising tasks, dealing with deliverables, supporting decision-making and problem solving.


© ABE

Cooperation/collaboration

There are clear cooperation and collaboration tasks associated with each project task. The scope for putting together a team is for its members to establish synergies that should increase the performance capabilities for the project. The principle is that the performance of the whole (the team) is greater than the sum of its components (individual team members).

Phasing out

While certain teams may be more permanent structures that will remain in place for specific organisation project tasks, it is not uncommon for teams to cease to exist once the project is finished. A successful organisation plan should take under consideration the deployment of the human resources after the project ends.

Termination

Once the project is over, the team may need support in order to shift to new projects, or deal with any major changes. This stage becomes critical when a project ends before its expected completion date and prompt changes are required.

Rewarding Excellent Team Performance

Teams may be put together either for dealing with a specific project or to undertake certain responsibilities that recur at regular intervals during an organisation's operations. Team behaviour and performance is likely to vary significantly for a number of reasons. Different teams may deal with similar projects so differently that it is important to assess their team structure as well as their performance throughout their life cycle. However even the same team may demonstrate varying performance during a project life cycle. This may depend on tasks, external factors, unexpected events and several other factors. In either case, it is necessary to follow a clear plan that ensures effective team performance.

There are some useful practices that, by improving the effectiveness of team work, may encourage optimum performance and fewer team problems. For example:

Define a clear goal that team members can associate with. This goal must be well defined and should be shared between team members, offering a specific mission for the entire team.

Establish a result-driven strategy for organising the team structure. The aim of this strategy is to ensure that each task has the necessary resources allocated for achieving its deliverables.

Involve team members with a suitable profile in undertaking the project roles and responsibilities.

Ensure that team members share their common objectives and support each other when required.

Nurture collaboration and communication between team members as required by project deliverables.

Define specific performance indicators and criteria for both the team and individual team members.

Establish performance rewards for the team and its members in order to increase motivation and commitment.

Attract external support and the necessary organisational infrastructure.

Think Point 3


© ABE

Consider possible reward mechanisms that you could introduce for a team that is not performing up to the required standard. Think about the different measures which would be appropriate if the lack of required performance relates to the entire team, certain roles or individual team members.

Also, consider how you could define certain standards as a benchmark against which you could structure a hierarchy of rewards.

The introduction of reward mechanisms should support the engagement of team members and lead to increased team performance. These rewards may take various forms, depending on the organisation's human resources policy. Rewards may include additional benefits, increased salaries and bonuses, promotions, etc.

Recruiting the Project Team

Clearly the success of a project team depends on the team members as they affect a number of project tasks performed during the project phases. The performance of a team depends on how the team will deal with a number of tasks including:

holding successful and productive project meetings

establishing a team culture that is shared between members

identifying a common goal and shared mission

introducing reward mechanisms and performance rewards

supporting decision-making and problem solving

dealing with differences and conflicts

motivating team members.

The membership of the project team is critical for the success of these tasks. Any project team recruitment decisions must take under consideration a number of factors, including:

abilities

availability

expertise

credibility

personality

social standing.

This list is not exhaustive and sometimes a project manager will need to take other factors into consideration. Often the main consideration will be whether the individual possesses the

skills, knowledge and capabilities to perform a specific vacant role. Such capabilities may include transferable skills that may be used in a different setting, such as making decisions, operating under pressure, dealing with change, managing unknown and vague scenarios,

etc. The availability of team members is critical, especially when a project is operating in a very short time frame. This means that team recruitment may be based on the availability of an individual, providing certain standards are satisfied in terms of the person's skills and

knowledge. The experience of team members in similar settings and with previous projects of the same nature is an additional factor that guarantees team members being able to address the project requirements. Certain individuals enjoy organisation-wide respect and acknowledgement because of their efforts and prior success.

The credibility of team members may affect the way their opinions are perceived during decision-making. Such members may undertake responsibilities including facilitation of


© ABE

meetings, mentoring and coaching. The team member's personality is an additional factor that should be taken under consideration when deciding team membership. Team members

must be compatible and there must be no major conflicts created due to a personality clash or differences in working habits. Team members with increased motivation, commitment, integrity, ambition, personal drive and ambition are likely to become drivers for improved

team performance. Finally team members may offer additional benefits to the team by personal links and connections, either within the organisation or externally.

Managing People

The management of teams includes a very important task: to manage the people involved in the project tasks as team members. Sometimes the team performance may be affected by personality and task issues associated with individual team members.

People management will involve various tasks that may include daily tasks or focus on the introduction of policies that regulate how personnel are organised. A very important aspect of people management is managing project meetings. A project meeting is perhaps the main method for communicating ideas, dealing with any collaboration issues, making decisions and resolving conflicts. The management of meetings includes a number of issues, such as:

deciding on who should participate in the meeting

determining the agenda of the meeting, including the main topics for discussion

preparing for the meeting, especially if any actions are required or whether project documentation must be presented

following up with any actions resulting from the meeting decisions.

The management of project teams should be based on the adoption of certain practices that may already exist in the organisation, may be common practice in the field or introduced for

the specific setting. The project manager should be able to set certain ground rules for what is considered as acceptable behaviour and performance for team members. The planning and scheduling of project meetings following the guidelines described previously should offer an opportunity for team members to exchange ideas. The project manager must have a clear strategy of how decisions should be planned ahead and for the procedure that should be followed for making such decisions. The aim is to foster engagement from team members, while smoothing any major differences and allowing brainstorming and debate.

The key success factor is for decisions to be well informed and based on sufficient justification. The manager must be in control of the project decisions, meaning that each decision must be supported by the entire team and be in line with the overall project mission. Each decision should be traceable back to those members who are responsible for the information and outputs used for its justification. The project manager should ensure that team member relationships are such that they do not pose a concern for the project performance. The manager must also support team members during times when change takes place.

The management of human resources is also affected by the geographic dispersion of the locations that are part of the project infrastructure. There are so many considerations for project managers associated with the remote nature of geographically dispersed project resources. If people reside in different locations then communication must have additional support to compensate for the absence of face-to-face contact. The use of technology may influence the effectiveness of project communications, as it may not communicate the richness of mannerisms and human behaviour. When technology must be used for communication, there may be cost or time overheads involved as team members must be familiar with the tools used and the necessary equipment must be in place.

The existence of geographically dispersed resources may lead to the involvement of team

members that reside in different time zones. This means that careful scheduling is needed to ensure that meetings are held at convenient times. The fact that meetings may be held


© ABE

between people in different location means that participants must make an effort to reduce misunderstandings and noise from external influences. A worse-case scenario might be different time zones preventing team members communicating at the same time on every occasion (asynchronous communication).

In addition, there are cultural issues that may affect the management of dispersed resources. An understanding of national culture is essential for establishing project management practices that are suitable for the specific human resources involved, i.e. there needs to be an awareness of how culture affects the behaviour of team members. Cultural norms may also constrain the way a team performs and its team members communicate and collaborate.

Think Point 4

For a project team that is in the middle of a project (you may choose a fictitious one) identify the steps you should take for organising a series of project meetings.

After determining the scenario you wish to explore, you should identify the reasons for each meeting and provide a set-by-step approach from putting together the meeting membership to disseminating its minutes.

Comparing and Contrasting Teams Organised on Functional, Project, Matrix

and Contract Structures

There are several approaches in organising projects but organisations usually follow generic ways that have proven useful in the past. There are three main methods that organisations may follow in organising project structures and resources:

divisional or projectised

functional

matrix.

The divisional or projectised approach means that each project becomes a separate entity within the organisation with its own dedicated resources and structures. The nature of this type of organisation is such that projects are self-contained. Each project has its own budget and work plan and should not affect the organisation's other projects.

The functional method is based on the classification of human resources in a manner that is derived from a specific function. There are several possible functions or divisions that may be used for such a classification. For example, individuals may be grouped together based on their skills or their role in the organisation. An alternative method could use the products or services of the organisation to group together individuals who are undertaking tasks for specific product ranges or services. Furthermore, the location of the workforce may be one of the criteria used to provide the functional groupings of the organisation.

Finally, the matrix approach attempts to combine the main features of the previous two methods. The matrix organisation uses the functional groupings that have been put together based on the skills and capabilities of individuals. These functional groupings are the pools of individuals that the project manager may use to select team members. Once a project is defined, the project manager may draft certain members from each functional grouping and establish a project team that has sufficient skills, experience, background, etc.

Project Manager or Functional Manager?


© ABE

It is rather difficult to decide the best approach when putting together project teams. The way a project is managed depends on how the organisation perceives the project management methods presented here. While it is not possible to identify which is the best method, there are clear advantages for each.

A divisional or projectised approach is the most simple to use as it is based on organising everything around the project. The project becomes the core of the organisation and the project manager does not have to consider additional factors apart from the project budget, requirements, resources and team.

However there is a significant drawback with this approach: it is rather rigid, since it is based on individual projects. The resources dedicated to the project are not flexible in terms of being capable of allocation to additional projects and external tasks. The project scope is usually so central to the focus of team members that it may blur the organisation's mission. Furthermore this approach may prove a rather expensive method, as it does not support the reuse of resources and mobility between projects. Eventually, when the project terminates, team members may find it more difficult to cope with their next tasks.

The functional approach is the best one for keeping individuals together according their background and expertise. This practice allows them to maintain a high level of cohesiveness and alignment with any corporate goals. The method is quite cost-effective as it allows the use of skills as they are needed and projects can borrow human resources from each division according to their work plan.

But there are several drawbacks with the functional approach, as the process is focused on workforce rather than project needs. By not having dedicated resources, each project may become a logistical nightmare. The project delivery is a very difficult task to achieve as project managers do not have the same control on the allocated resources. The main problem is that team members do not show any evidence of a team culture, but seem to belong mainly to their functional cast. This means that their performance is almost impossible to appraise, as their individual goals are aligned to their functional role within the organisation instead of matching the needs of their project tasks.

Think Point 5

Compare and contrast the divisional and functional approaches.

You should focus on the advantages and disadvantages of following these two different approaches. Your answer should be based on a clear understanding of the way project members are selected for each of the two approaches.

Many feel that the matrix approach is perhaps the most effective way of managing project teams. By using resources from various functional groupings there is always an availability of skills for each project. By allocating resources to specific projects, team members become focused and have a clear identity for their role and the tasks they undertake. The method offers maximum flexibility, allows for frequent changes, supports project termination and creation of additional project tasks and helps project managers to multitask different projects with dedicated resources and budgets.

The main drawback of the matrix approach is that it requires a lot of communication to succeed. The project manager must be in control of the resources dedicated to each project while negotiating objectives, tasks and individual agendas. The prioritisation of different projects and the determination of how resources are allocated must be agreed between several stakeholders.

Project and Team Contracts


© ABE

Following our discussion of the different organisational approaches we will now consider how negotiations take place in order to make project resources available. There are several contractual agreements involved with each project. Depending on the organisation, the management approach, the project scope and several other factors, the project manager may have to consider numerous contractual arrangements.

Some of these arrangements may include contracts with:

organisation employees

project managers

external employees

suppliers

other organisations and service providers.

One of the key factors affecting the contractual agreements of a project is the nature of the work undertaken and any associated structures. In the case of the matrix organisation we have seen there is a more ad hoc approach in bringing together project resources. The aim of the project manager is to produce the project deliverables in the most effective way. Therefore the agreements that must be in place should cover:

project requirements

project deliverables

project resources.

In the matrix organisation human resources are drawn from existing organisational divisions, meaning that agreements are in place to govern:

individual roles

job specification

project participation.

It is evident that the arrangements made by an organisation will depend on the management approach followed when putting together the management team. Being able to determine the project team structure is likely to affect the establishment of clear contracts and agreements that are easy to follow, leading to less conflicts and misunderstandings.

Project Team Structure

The project team structure depends on how human resources are organised, as we discussed earlier in this section. There are several steps that must be followed before the creation of the team. Such steps may include:

Assigning a project manager – this step is concerned with the identification of the individual who will be in control of the project and carry the main responsibility for the project's success or failure.

Defining roles – this step focuses on defining each role within the project team and describing the tasks that are associated with project roles as well as ideal profiles for candidates.

Identifying responsibilities – this step provides a detailed specification of those responsibilities associated with every project task. Ideally the role responsibility should provide sufficient detail for the determination of the skills, knowledge and experience required for the successful fulfilment of the role.

Setting up a staffing process – this step provides a detailed process for staffing the organisation (if no individuals with the required skills already exist within the workforce), becoming a member of the team and being assigned a project task.


© ABE

Setting up a performance management process – this step offers alternatives (from letters of commendation and bonuses to additional benefits and incentives) for a reward management system as well as the mechanisms used for monitoring performance and raising awareness of project progress.

Establishing a communication plan – this step describes the means and methods used for enabling or supporting project communication. Communication may relate to project tasks or be associated to project roles. Project communication may also be formal or informal, periodical or sporadic, detailed or brief.

Obtaining support – this step identifies those stakeholders who should provide their support to the project. Sometimes support may be required by external entities such as government, agencies, intermediaries, suppliers, etc.

Modern organisations are increasingly using the matrix organisation approach as it offers a cost-effective way of allocating resources to projects. However, there are some variations to the way the matrix method is implemented. The different models of the matrix approach are:

lightweight

balanced

heavyweight.

In the lightweight model, the project manager acts as the coordinator of project resources and the line managers of individual project team members are mainly responsible for their performance and disciplinary actions. The lightweight model is used when a project does not have a dedicated budget or a more permanent nature.

The balanced model provides a balance between line management and project management. The project manager must identify those project tasks that require resources that must be spared by the line manager from the corresponding division. The balance is between the management of project resources and availability of resources at an organisational level.

The heavyweight model is based on creating secondment opportunities for individuals in the organisation's divisions. Once the project is completed, the individual returns to their division. The project benefits in this model with skilled members that are required for specific periods and cannot be afforded after certain project phases are completed.

Quite often project managers may choose their project membership from various organisational functions as mentioned in the functional model. The scope for such an approach is to establish:

The provision of the required output at an acceptable cost.

The production of project deliverables of an acceptable quality.

The presentation of deliverables in the acceptable time frame.

It is quite common for a mixed approach to be the preferred choice as modern projects are usually so specialised that many may require specific skills and for very short periods. The project manager must be able to coordinate resources that may become available through the following channels:

organisation divisions (divisional approach)

organisation functional groupings (functional approach)

external contractors

partner organisations.


© ABE

The project manager must be able to coordinate the various resources in such a way that their working patterns and management style are harmonised and aligned with the organisation's mission and policies.

Review Questions 1

(a) What are the seven main considerations for structuring a project team?

(b) List five examples of functional specialisms that can be used to classify team structure.

(c) What are the eight main characteristics associated with the nature of teamwork?

(d) What are the main stages of a project team's life cycle?

(e) What are the seven tasks that a high performing team must succeed at?

(f) What are the main advantages from each of the three project formation approaches?


B. STRATEGIC APPROACH TO EFFECTIVE LEADERSHIP

One of the key factors for an organisation's success is leadership and the way it is achieved, both at a strategic level and on daily operations. The concepts of leadership and management are closely related. It is argued that although project managers must possess management skills for the fulfilment of their role, leadership skills are difficult to acquire.

We could define the management concept as the application of authority over team members, according to a structure imposed by the organisation. In some cases this structure may be a specific project or a more permanent structure, such as a department or division.

We could also define leadership as the ability to drive others towards the leader's vision. This could be in the form of persuading team members to perform certain tasks, succeeding to align individual goals with the leader's scope, establishing a certain attitude towards work, motivating members, increasing commitment, etc.

One could argue that it is difficult to put together a recipe of known ingredients for a successful manager and an inspirational leader. This section concentrates on identifying several aspects affecting both management and leadership in a project. Some of these aspects are:

Background

An individual's background may reflect on the way he/she was brought up, including influences from family, school, national culture, etc. The opportunities for education and training are likely to affect one's abilities, knowledge and attitude.

Roles and tasks

Managing and leadership skills are likely to manifest themselves in different ways depending on the role of the individual. The attempts to motivate and inspire team members should be proportionate to the specific task.

Skills and abilities

A mosaic of a person's experiences, knowledge, skills, personality and behaviour affects the way both management and leadership skills are put into practice.

Project specific


© ABE

The project management role is dependent on the way the organisation perceives the project's scope and the importance of the role. The underlying corporate culture is quite likely to affect the perceived value of leadership skills.

Style

The management style adopted is a combination of an individual's view of project management and the organisation's framework for what is perceived as acceptable and possibly required management behaviour.

Effectiveness

Management skills are assessed in terms of how successful the manager is with respect to specific indicators.

Influence

Leadership skills are tested against the intended outcomes for the project.

Leadership is demonstrated in several ways during a project but also in everyday life. It is almost impossible to provide a leadership model covering all possible perceptions of leadership. On the other hand there are certain types of managerial leadership that are more common in projects. Some examples may include:

Leadership as a trait

There is always the view that leaders are born and not made. Possessing leadership qualities is therefore a differentiating characteristic of certain individuals who should be awarded certain roles in the organisation.

Leadership as a responsibility

Some organisations perceive leadership as a responsibility that comes with the role, so if someone holds a certain job title they should be able to lead. Sometimes this notion of leadership may lead to group leadership models and the introduction of leadership training programmes.

Leadership as a behaviour

There is an approach to leadership that views how individuals alter their behaviour once they are allocated a position of responsibility. Leadership becomes part of the individual's behaviour and is likely to affect decisions and the way a project or a team is managed.

Leadership as a style

The personality of an individual also affects the way leadership is exercised, and more specifically how leading roles affect communication and coordination of peer and subordinates.

Leadership as a condition

There are certain project phases that may require initiative and key actions. The demonstration of leadership skills may be triggered by an event or a project crisis. This approach considers leadership as a behaviour that varies with time and adapts to different conditions.

Leadership as a transformation tool

One of the effects of leadership should be to enable the transformation of an organisation and its structures, the human capital and individual members, in order to achieve set targets and work towards the common mission.

Leadership as inspiration


© ABE

Eventually leadership is perceived as a virtue that once possessed can help the management of individuals and teams. Regardless of the leadership style, a good leader should be able to inspire others.

Think Point 6

Reflect on your leadership skills and, based on previous experience, identify your current leadership style.

You should consider examples of leadership roles you might have had in the past and justify, with evidence, why you believe yours is the specific leadership style you claim.

Key Leadership Skills Desirable in a Project Manager

There are several skills required for a successful project manager. Quite often these skills are identified as the traits a leader must possess. The skills of a project manager may relate to:

the project task

the project manager role

character

relationships

personality.

These groupings may be used to describe the various skills a project manager must have in order to deal with project difficulties.

A good leader should be in control of the project tasks and ensure that they are fulfilled as required. The project manager must be able to allocate project resources and deal with any issues rising from missing resources including finances, skills, etc. The manager should be able to help out team members and be proactive in dealing with situations where existing infrastructure and resources cannot cope with the workload. The cooperation with others and the coordination of the team are essential for a high-performing project. The project manager should be able to acquire knowledge, and disseminate information necessary for problem solving and decision-making.

With respect to the project manager role, leadership skills are frequently associated with respect from subordinates and peers as well as recognition for skills and knowledge. The visibility of the role holder and his or her advancement and progress in the organisation's hierarchy are also indicators of the project manager's status. This is likely to result in a number of strong working relationships that are very useful throughout the project life cycle.

The character of the project manager is such that their vision is likely to lead to ambitious plans and a drive towards achieving the organisation's mission. The project manager is likely to have a drive towards excellence and performance. Integrity and an ethical view of the project's scope are also part of a visionary approach to project management.

The project manager who is able to demonstrate leadership skills is likely to have a very

good relationship with the project team members. The project manager role does not require a continuous coordination effort that focuses only on deliverables and performance indicators. A leader is expected to understand other people's needs and become aware of any personal problems. The successful project manager can shift from being a coordinator to a more nurturing role, offering coaching skills to the team. The manager should be able to accept the weaknesses and appreciate the strengths of individual team members. The ability


© ABE

to provide personal support when needed seems to be a key factor in establishing high motivation and commitment within the group.

Finally, the personality of a leader should be such that any challenges are regarded as opportunities. A project manager should thrive during difficult situations and be proactive in dealing with problems. When such scenarios arrive a leader is more likely to be involved and participate in finding a solution.

Leadership and Management Style

Both management and leadership styles depend on a number of factors that affect the way decisions are justified and interpreted by the project stakeholders. The factors affecting the preferred style of leadership will differ according to the organisation involved, the project environment, the individual managing a project, the cultural background, etc. The different approaches describing how the leadership style may be classified take into consideration the following criteria:

Addressing project requirements – the project requirements may range from more basic ones that relate to the completion of deliverables, or may include more complex ones associated with quality assurance.

Considering stakeholder needs – those people who are actively involved with a project may be viewed as workers who undertake certain roles, or as individuals with their own needs that must be satisfied in order for the project to succeed.

Assessing individual roles – each team member that undertakes a role may be constrained in terms of the specified work packages and deliverables, or may be a more autonomous unit that is allowed to make decisions and provide a more personal touch to the way the work in undertaken.

Determining management approach – the way a project is managed may follow a more controlling approach that allows no flexibility to team members, or be based on the manager having a more relaxed role that usually concentrates on the facilitation of certain processes and monitoring the performance of the project tasks.

Deciding on a work pattern – the project tasks may be implemented following well-defined instructions and adhere to rules and organisation policies, or may allow a more challenging approach based on risk taking and the exploration of ambitious alternatives.

Allocating responsibility – the responsibility of individual tasks and the overall project may lay with the project manager, or alternatively it may be shared between all participating team members.

So it is possible to follow several paths in the way a project is managed, and this is a decision that is usually made by the project manager. While an organisation may dictate a preferred management style for its projects, it is quite unlikely that it will attempt to impose certain leadership styles. Although an organisation may attempt to draw the values of the individual who should become an aspirational leader, it is usually a gamble whether the project manager is able to lead in a style that is in line with the organisation's idealised leadership profile. One of the conflict areas between the theoretical background offered by leadership models and the practical aspects of personal leadership styles is the way chosen to motivate team members.

Team Motivators

In smaller teams, after a significant period a project manager will be able to understand the behaviour of each team member, and so can lead the team with a style that is tailored to the individuals involved. In contrast, in modern organisations with more complex staffing procedures, several simultaneous projects and tight time frames are likely to be based on different theoretical models in order to maintain a highly motivated project team.


© ABE

There are several models that describe how team motivation may be supported and most of these models are identifying factors affecting motivations as well as motivation levels that can be achieved once certain factors are satisfied.

The work of Frederick Taylor is presented as a set of scientific management principles that are concerned with the motivation of individuals who are involved in repetitive work. These principles are identified with the following actions:

Investigate how the project is structured in order to divide each project activity into manageable tasks and introduce a quantitative way for estimating the actual work needed for the task and how it should be performed.

Follow a scientific approach in order to assign roles and allocate individuals to project tasks. Therefore a matching process is needed to ensure that team members are responsible for suitable tasks.

Depending on the task's requirements, sufficient support should be provided to the individual undertaking the responsibility for the task, including training and any other means that are necessary for its successful completion.

Introduce reward mechanisms that would act as both the motivation towards the task completion and evidence for the organisation's appreciation for the team member's performance.

There are several motivational strategies that can be implemented at an organisational level. The principle is that job performance is perceived as a function of ability and motivation. In other words, a project's success depends directly on the performance of the workforce assigned to it. Indirectly the project performance is dependent on both the skills and motivation of each team member. Some strategies that can be adopted to increase motivation may include:

Reinforcement – by following a positive attitude the project manager could convey to team members that his/her high expectations are analogous to their capabilities and potential.

Discipline – poor performance may be addressed with effective penalties that make it clear that while current performance in unacceptable, it is still possible to establish a smooth working relationship.

Fairness – both rewards and punishments must be proportionate to performance and follow a policy that ensures all team members are valued and treated equally.

Goal setting – by setting clear goals it is possible to align the organisation's mission to the vision of individuals, the scope of each role, project goals and departmental objectives.

Addressing needs – the needs of each individual must be assessed and an effort should be made to ensure that team members feel valued and that their needs are taken under consideration.

Dynamic roles – each role should be dynamic to such an extent that it reduces repetitive and mundane tasks, allowing team members some variety in their work pattern.

Align performance and reward mechanisms – each reward should be proportionate to the performance as well as the difficulty of the specific role and associated project tasks.

The theory of motivation proposed by Abraham Maslow is a long-standing model that has been used since 1943. This theory views individual needs in a hierarchical fashion and argues that unless more basic needs are satisfied, the higher level ones are difficult to address. The theory (see Figure 5.1) introduces the following levels of individual needs:


© ABE

Physiological needs – these needs are essential to sustain life, such as air, water, food and sleep.

Safety needs – these relate to the safety and security of the individual in order to avoid threats to such things as job security, living environment, financial and medical stability.

Social needs – these are higher needs that are associated with the social nature of people, including friendship, love, belonging to a group/team/society.

Esteem needs – these are needs that are associated with the importance of oneself and can be identified as: (i) internal motivators including accomplishment and self-respect, or (ii) external motivators including recognition, attention and social status.

Self-actualisation needs – these needs, once satisfied, ensure that the individual's potential has been reached and include motivators such as truth, justice, wisdom and meaning.

Figure 5.1: Maslow's hierarchy of needs

Self-actualisation

Esteem needs

Social needs

Safety and security needs

Physiological needs

Ultimate satisfaction

Basic need


© ABE

Think Point 7

Consider Maslow's theory and provide examples of how you would address the needs of your team members, at all five levels.

You should structure your answer in such a way that each level is dealt with before the next one. You should explain not only how you would meet the needs of the team members, but also how you would assess whether certain needs are not satisfied.

Several methods were created by adapting Maslow's theory and restructuring its five-level

hierarchical model. Alderfer has proposed the ERG theory that is based on three levels of need identified as:

existence, including physiological and safety needs

relatedness, including social and external esteem needs

growth, including internal esteem and self-actualisation needs.

This approach groups together Maslow's levels while splitting the esteem needs into internal and external ones. The principle is that the basic level of needs that relates to existence if neglected will lead to failure, while there are needs that relate to the project and the scope of a team member's role. Finally the needs associated with growth are the ones that, if addressed fully, will dramatically increase performance.

Yet another approach is offered by McClelland, who has identified three needs as the core of his theory. These needs are identified as:

The need for achievement – this set of needs is focused on the challenging nature of tasks that involves an element of reward by being allocated an interesting role.

The need for power – this set of needs is geared towards the individual's tendency to lead others and be assigned roles with additional responsibilities.

The need for affiliation – this is perhaps the only set of needs that takes under consideration the social belonging of an individual at the workplace, in the form of friendships, relationships and cooperation.

Another approach is provided by Vroom, Porter and Lawler, and is called expectancy

theory or VIE theory. The three variables affecting individual motivation are identified as:

Valence – this relates to the individual's belief that an expected outcome (personal benefit) will result by achieving a task.

Instrumentality – this is associated with the individual's needs to believe that the task was achieved due to personal abilities and skills.

Expectancy – this is focused on confidence that individual performance is up to the allocated task.

An alternative approach is provided by Adam's equity theory on job motivation, where a scale is used as the metaphor to balance the inputs and outputs as perceived by an individual who is assigned to a specific job. The input represents:

time effort ability loyalty tolerance flexibility integrity commitment reliability sacrifices, etc.

The output represents:

salary bonuses benefits security recognition interest development reputation praise responsibility enjoyment, etc.


© ABE

Hygiene Factors

We have discussed several theories that focus on identifying issues relating to the motivation of individuals, thereby introducing strategies for increasing motivation and subsequently

performance. Frederick Herzberg introduced the concept of motivators and hygiene

factors in order to assess whether people are happy in their job.

This theory can be used by project managers and leaders in order to maximise the motivation of their team members. It is based on the identification of the following factors:

factors for satisfaction

achievement

recognition

the work itself

responsibility

advancement

growth

factors for dissatisfaction

company policies

supervision

relationship with supervisor and peers

work conditions

salary

status

security.

A very interesting argument made by Herzberg in his motivation-hygiene theory is that satisfaction and dissatisfaction are not precisely opposite concepts. More specifically, he realised that although dissatisfaction is the opposite of satisfaction, the opposite of dissatisfaction is no dissatisfaction. In other words, if an individual is not dissatisfied it does not necessarily mean that he or she is satisfied. So if our team members are not dissatisfied, they are not necessary as high performing as they may be lacking motivation and demonstrate indifference.

Following this approach two steps are identified as necessary to remove the "hygiene factors". These are the factors that are causing dissatisfaction. This two-step approach may be outlined as follows:

Step one – get rid of hygiene factors and therefore any causes for job dissatisfaction:

Fix poor and obstructive company policies.

Provide effective, supportive and non-intrusive supervision.

Create and support a culture of respect and dignity for all team members.

Ensure that wages are competitive.

Build job status by providing meaningful work for all positions.

Provide job security.


© ABE

Step two – create conditions for job satisfaction:

Provide opportunities for achievement.

Recognise workers' contributions.

Create work that is rewarding and that matches the skills and abilities of the worker.

Give as much responsibility to each team member as possible.

Provide opportunities to advance in the company through internal promotions.

Offer training and development opportunities, so that people can pursue the positions they want within the company.

Think Point 8

Identify the ways in which the working environment may affect project teams.

Hopefully in looking at the ways in which the working environment might affect teams, you will have identified issues such as the effects on team morale, whether the team meets its objectives, how team members collaborate and communicate, individual performance and commitment, and relationships between members.

Influencing the Motivation of Team Members

In the previous section we discussed a number of methods and theories that focus on how to increase the motivation of individuals within an organisation. A project manager must be capable of assessing the motivation of each team member, and ensure that their performance is not affected by failing to address their individual needs.

Team member motivation depends on understanding the factors that influence the well-being of each individual at the workplace and their team membership. In order to influence team member motivation and enhance the performance of the team as a whole, managers must adopt one of the proposed theories to ensure that they are aware of any problems in their teams.

The project leader should also be in control of a number of additional factors that may affect the performance of the team and motivation of its members. The way communication takes place in the team and between its members must eliminate frustration, reduce misunderstanding and ensure that members are capable of performing their roles without any obstacles. The team should also have clear rules and procedures regulating its operations and be organised in an effective way.

Managing Team Communication

We have mentioned before that holding successful meetings is part of a strategy for managing a project effectively. A meeting is an important event that may be used to address specific issues or to bring everyone together in an effort to disseminate important decisions or project information. The project manager should be in control of several issues relating to project meetings, including:

the frequency of team meetings

meeting membership

the preparation of the meeting agenda

the coordination and facilitation of the meeting


© ABE

the note keeping, preparation and distribution of minutes as well as the enforcement of any actions.

Although meetings offer opportunities for communication, a project team engages in far more communication exchanges during each work package. As part of their project tasks, team members may be in continuous communication with others and some of this communication may not even be formal.

The project manager must be aware of the communication needs within the team, and one of the key aspects of communication is its timing. The primary reason for team communication is to share information that is usually needed for project tasks, either as input or output. The timing of such communication is critical: information must not be delayed in order to avoid delaying any tasks. Sometimes when information is provided too early it may become dated and irrelevant by the time it is needed.

The way communication takes place is also important as the project may impose certain constraints. Typically a face-to-face communication should be preferred as the optimum method to exchange information and ideas, clarify any pending issues and reach a common agreement. The problem is that meeting at the same place and same time may not be feasible due to the location, other work commitments and even time zone differences between the team members. Video conferencing, phone calls and other synchronous tools can be used to overcome the distance obstacle. However, the mannerisms and closeness of a face-to-face meeting are lost during a phone call and video calls may introduce additional overheads, complexity and lose focus. The exchange of emails, reports and workflow messages, and the use of collaborative technologies for share editing of documents are some methods that allow the asynchronous communication between team members. These are ideal alternatives when time is an issue, but they have additional problems such as versioning, maintaining control, obtaining sufficient detail and reaching an agreement in reasonable time.

Communication may also be informal and sometimes such communication is invaluable for the success of the project. However the main concern here is that such communication is not documented and it is difficult to use for auditing, once a decision must be justified, and as the basis for further actions. The lack of an etiquette means that informal communication may lead to misunderstandings and possible conflicts.

Of course communication is not constrained to within the team. Project communication is also taking place with other stakeholders such as project sponsors, and with other teams and members of the organisation. Establishing a clear communication protocol means that the project manager is aware of how communication is taking place, controls the information being exchanged and understands any communication expectations with respect to the project.

Team Operating Rules

Apart from the communication protocol and etiquette, there are several other project areas that need rules and procedures to ensure a smooth operation. These areas are:

Problem solving

Usually problems arise when the project plan fails to foresee an event or the initial estimation is not followed with respect to work. The problems may be identified by the project manager or be informed by team members. The problem-solving process should not be the sole responsibility of the project manager but should involve team members also.


© ABE

Decision-making

The decisions that must be made for the project involve the project manager when they are at a critical stage for the project success or when they affect specific team members and their role. However, decision-making should be delegated when possible to individuals, if such decisions do not require the involvement of other members.

Cooperation

The cooperation and collaboration of the team members who are allocated roles that are interrelated should be governed by clear communication protocols and procedures. These must dictate how the exchange of information and control of the project tasks should take place.

Performance

Monitoring performance indicators and recording how the project performs against certain standards should be the responsibilities of the project manager. However, it is necessary for this information to be disseminated among team members who should also be aware of the overall project performance as well as the progress of their individual project responsibilities.

Ethics

Everyone involved in the project should share the same ethical views, especially when certain dilemmas may affect any compromises that must be made (e.g. quality) in order to achieve project targets (e.g. deadlines).

Trust

The lack of trust between project stakeholders cannot be tolerated as it seriously damages the project's stability and the potential to reach its goals.

Prioritisation

It is necessary to jointly reach any decisions affecting the prioritisation of project requirements and individual needs. This process affects not only the project performance but also hygiene factors we have previously identified.

Organising the Project Team

The project manager must demonstrate his or her leadership skills when organising the project team. It is necessary to demonstrate certain qualities that support the effective management of the project resources. Such leadership skills are necessary for the project's success and the well-being of the project team.

Some examples of the qualities a project manager must demonstrate include the ability to do the following:

Maintain stability – this means the project manager's ability to control any crisis, maintain certain performance standards and deal with problems.

Be creative and innovative – this is relevant to certain projects that require a forward-thinking approach in problem solving and using the available resources.

Get involved – this means the project manager's involvement with more basic tasks and daily responsibilities (without losing power distance with any subordinates).

Lead the way – this relates to the fact that a project manager should be able to foresee the direction of the project and look ahead to the sector for any directions set by the industry. Sharing these ideas with the team is likely to strengthen the respect and trust of team members for the project manager's decision-making abilities.


© ABE

Encourage team members – this is relevant to the measures taken to ensure that team members remain motivated and committed to their tasks. The project manager may follow a different strategy depending on priorities, individuals and project phase.

Support the team – this emphasises the value of the team and includes any steps required to ensure that all team members collaborate and communicate effectively, while remaining focused on the common goal.

Solve problems – this means the ability to solve problems, avoid critical situations and ensure that a fair and ethical approach is used to deal with any project problems.

Show flexibility – this allows the project manager to be firm on decisions while considering alternative approaches and allowing team members to take initiatives and work individually on delegated tasks.

Deal with loyalty – this relates to both the ability to appreciate the loyalty of team members but also to share the team identity and be supportive of the team and its members when decisions are made at an organisational level.

The project manager should also possess certain skills and values, including:

holistic approach – viewing the project as a whole

integrity – managing others in the same way they manage themselves

proactive behaviour – dealing with any issues before they lead to a crisis

stress tolerant – coping with stress and deal with crisis

business oriented – understanding the organisation's perspective on issues

communication skills – being able to communicate with clarity and firmness

time management – controlling time in both personal life and project role

political acumen – balancing different personalities, goals, agendas and priorities

optimism – showing a positive attitude and sharing it with others.

Review Questions 2

(a) How would you define the concepts of management and leadership?

(b) List five key leadership aspects or groupings to which the skills of a project leader may relate.

(c) What are the main theories associated with motivational factors?

(d) What are the two steps proposed by Herzberg's motivational approach?

(e) What are the drawbacks of informal communication in a project?



© ABE

SUMMARY

This chapter consisted of two main parts, focusing on management and then leadership of a project team. In the first part of the chapter we discussed team structures and criteria for assigning team roles. The team formation and role allocation discussion focused on team organisation and management responsibilities. The section also described reward mechanisms and procedure followed when staffing and recruitment decisions are made. We continued with more discussion on managing people and different management styles. The sections dedicated to leadership discussed the necessary skills of a successful leader and various leadership styles, and emphasised motivational and hygiene factors. Following the introduction of several motivational theories, we described communication and operational techniques as well as organisational issues relating to the qualities necessary for a leader.


© ABE


Review Questions 1

(a) Teams must be structured in a way that ensures: achieving the project objectives; working efficiently towards the project deliverables; dealing with any project tasks and team-related problems; communicating effectively; performing according to the project plan; engaging in decision-making and problem solving; supporting the project stages and allocated activities.

(b) Five examples of functional specialisms are: research and development, sales, marketing, engineering, human resources.

(c) The main characteristics are: the benefit of creating a pool of skills and expertise by grouping together team members; the ability to engage all team members in decision-making and problem solving; the involvement of team members in operations by sharing their different perspectives and capabilities; the alignment of skills and capabilities of team members to meet the needs of project tasks; the harmonisation of team operations and activities; the improvement of team effectiveness and exploitation of team member capabilities; the reaction to identified risks and performance obstacles; the development of an environment-fostering commitment and motivation among team members.

(d) You could have cited either the Tuckman model (forming, storming, norming, performing and adjourning) or the "typical" model (formation, allocation, harmonisation, cooperation/collaboration, phasing out, termination). There is of course much overlap between them.

(e) The team must succeed at: holding successful and productive project meetings; establishing a team culture that is shared between members; identifying a common goal and shared mission; introducing reward mechanisms and performance rewards; supporting decision-making and problem solving; dealing with differences and conflicts; motivating team members.

(f) Divisional/projectised: self-contained and the most simple method to use; good team identity.

Functional: good for keeping together personnel according to their expertise; cost-effective; team cohesive and good alignment with corporate goals.

Matrix: maximum flexibility; good skill availability; team members focused and have a clear role identity; copes well with change and supports multitasking by project managers.

Review Questions 2

(a) The answer given in the text is:

Management is the application of authority over team members, according to a structure imposed by the organisation.

Leadership is the ability to drive others towards the leader's vision. This could be in the form of persuading team members to perform certain tasks, succeeding to align individual goals with the leader's scope, establishing a certain attitude towards work, motivating members, increasing commitment, etc.

You may think of other responses to this question.

(b) The five aspects are: the project task, the project manager role, character, relationships, personality.


© ABE

(c) Those of Frederick Taylor and Abraham Maslow.

(d) Step one – get rid of hygiene factors and any causes for job dissatisfaction.

Step two – create conditions for job satisfaction.

(e) Such communication is not documented and it is difficult to use for auditing, once a decision must be justified, and as the basis for further actions. The lack of an etiquette means that informal communication may lead to misunderstandings and possible conflicts.

131

© ABE

Chapter 6

Managing Quality and Change

Contents Page

Introduction 132

A. Understanding Project Quality 132

Defining Quality – Product, Consumer, Manufacturing Specification and Value 133

Techniques for Assessing and Maintaining Quality Requirements 138

Assessing and Managing Quality – Software Products 139

B. Dealing with Change 143

Distinguishing between Internal and External Changes 143

Implementing a Formal Change Control Procedure 146

C. Configuration Control 151

Configuration Control Procedures 151

Summary 153


132 Managing Quality and Change

© ABE

INTRODUCTION

Once a project is structured according to a well-documented work plan and the project resources are allocated, it is necessary for the project manager to control the production of the deliverables. The project is expected to follow a life cycle that includes a number of stages, and during this life cycle the project manager must cope with two main considerations. Initially, the project manager must monitor and maintain an acceptable level of quality. In this chapter we will define the concept of quality and discuss in detail how quality can be assessed and maintained. The second concern is how the project manager copes with changes introduced at various stages of the project life cycle.

Objectives


explain the term "quality" viewed from perspectives such as the product, the consumer, the manufacturing specification and value

describe standard techniques for assessing and maintaining quality requirements

explain how the quality of software products may be assessed and managed

using examples, distinguish between internal and external changes

discuss the importance of implementing a formal change control procedure and describe its constituent elements

explain the steps in a typical configuration control procedure.

A. UNDERSTANDING PROJECT QUALITY

In order to understand the concept of quality we must understand that discussing quality depends on the perspective of how it is defined, measured and managed. For example, the quality considerations when designing a computer system are different from the quality issues relating to the construction of a building. It is therefore impossible to discuss quality in such a manner that will cover all types of potential project.

There are also several perspectives for determining how quality can be managed. Project management quality can be viewed from a number of viewpoints:

Mathematical

The mathematical approach is focused on assessing whether the project deliverables adhere to a given specification. This approach is more suitable for projects that include deliverables that are in the form of products and processes as they can be described based on mathematical and statistical formulas.

Structural

This approach is focused on the project conforming to procedures. This perspective is used for the establishment of quality assurance through a quality management standard provided by the ISO (International Organization for Standardization). A project of high quality conforms to the hierarchical production of certain procedural documents.

Organisational

The organisational approach describes the way most organisations view quality as it emphasises the importance of meeting customer and stakeholder requirements. This perspective requires constant communication with project stakeholders as they provide the necessary input used for assessing project quality.

Managing Quality and Change 133

© ABE

Economic

This approach takes under consideration the cost of achieving the required quality. The focus is on assessing the perceived value of the achieved quality as well as the awareness of any costs associated with project failure.

Strategic

The strategic approach is followed by organisations that aim for niche markets (e.g. luxurious products, high-end technological products) or the ones with quality being an integral part of their mission. In such cases cost and procedures are irrelevant as the aim of the organisation is to be perceived as one that guarantees projects with quality in their core.

Defining Quality – Product, Consumer, Manufacturing Specification and Value

It could be argued that quality may have different meanings to organisations, stakeholders and project managers according to their respective mission, goals and objectives. For example, a manufacturing organisation is bound to focus on product specification, while a project that supports a service is more likely to consider the level of support as a more suitable quality measure. A consumer-centred approach is likely to consider value for money as an indication for quality.

There are quite a few proposed models that attempt to determine quality by using a number of dimensions. These efforts aim at facilitating the management of quality and the assessment of project deliverables in terms of such quality measures.

A customer-centred definition of quality management could be based on the following eight dimensions:

performance – assessing whether the project produces a product or a service that performs according to certain specifications

features – assessing whether the deliverables that may be in the form of specific products include the required features

reliability – assessing the project deliverables with respect to consistently meeting the requirements and not demonstrating a higher than acceptable failure rate

conformance – assessing whether the project deliverable conforms to the given specification

durability – assessing the duration the project deliverables will last performing according to the specification following their deployment

serviceability – assessing whether the project deliverables are easy to maintain

aesthetics – assessing aspects of the project deliverables relating to the way they look to their end-users

perception – assessing how the project deliverables are perceived by the project stakeholders.

Think Point 1

Using a project of your choice (real or hypothetical), consider how these different dimensions of customer-centred quality management can be applied in assessing the quality of its project management.


© ABE

The different dimensions provide a useful means to estimate a project's management quality. Depending on the project's scope, different dimensions can be used to establish an understanding of the main strengths and weakness of the project management approach followed.

Such approaches to defining quality can be used by project managers to measure quality when the project deliverables are produced. However it is necessary to have a clear understanding of quality during the project life cycle and before the deployment of the project's deliverables. Quality is a very important concept as it offers a reality check for project managers and team members.

Project managers should always reflect on how their quality objectives are realised at different project stages. There are several reasons for this. Quality is important for the success of most projects as it determines whether the project deliverables will meet the requirements of end-users. Quality is also an indicator of an organisation's strategy to be associated with high-quality services. Quality may also be used as an indicator for the project's success, and the performance of individual team members.

Quality can be assessed from a couple of perspectives:

quality of design – focusing on the stakeholders whose requirements are used for the specification of the project deliverables

quality of conformance – focusing on the project management and whether the project deliverables are developed according to the design.

Quality should also be considered in terms of any associated costs. Such costs may be summarised as:

costs associated with quality control, including any measures that must be taken in order to achieve the quality standards identified for the project deliverables and any associated processes

costs associated with the failure of the project when quality is not controlled, which may include the costs associated with the delivery of products or services that do not meet quality standards.

Defining Quality

So far we have visited a number of perspectives concerning how quality can be managed. But how is quality defined? Quality is a concept that can be associated with the satisfaction of certain needs. For example, a high-quality system must satisfy certain requirements. The main issue is how to determine which requirements dictate whether the project has produced deliverables of high or low quality.

We could identify three primary perspectives that provide requirements that can be used as quality criteria. These perspectives are:

internal organisation stakeholders

external stakeholders

quality assurance associations.

By focusing on internal and external stakeholders we can prioritise requirements that are concerned with either internal quality issues or external aspects of the project. Quality assurance associations offer another perspective that can be used to identify requirements from a more objective point of view.

The internal organisation stakeholders include those who are involved with the management and running of the project. The aim is to identify issues relating to these stakeholders as their perception of the project deliverables is important in terms of assessing the quality of the project. Some examples may include internal procedures that must be


© ABE

followed in order to produce deliverables, perform project activities and deal with project actions. Another example of internal quality mechanisms may include monitoring how the project may improve an operation's effectiveness and whether any errors are introduced to specific operations as part of the project deployment.

Quality may also be viewed with respect to whether the project deliverables are 'fit for purpose', meaning that they may address requirements that are different from the ones that are identified by the stakeholders. Sometimes the project deliverables may involve procedures that are too complex or have associated costs that are unreasonable for what was expected. Alternatively the project outcomes may not have the technical quality required or level of detail needed.

The external stakeholders may belong to other organisational divisions, as in the case of affiliated projects or supervising departments. Their managers may monitor the project outputs and assess them in a way that depends on their expectations. Being able to cope with the expectations of external stakeholders is a major concern for project managers as their perceived quality of the project may depend on false expectations. The perceived quality of the project deliverables may also be affected by the views of external stakeholders on the costs incurred.

It becomes obvious that there is the need for an impartial third party that operates independently in order to establish whether the project's activities and outputs satisfy certain quality criteria. Such third parties are usually in the form of associations (that may be international or local) that focus on establishing certain standards against which the quality of projects can be evaluated. These standards are quite often specific to industry sectors and may only be used for project of certain types.

The involvement of an independent quality assurance party means that the project elements are assessed against objective criteria. The principle is that certain standards are used to examine the project deliverables as well as any processes, operations and activities that have taken place while these deliverables were produced. Sometimes projects, by achieving such quality standards, are able to influence the subjective views of stakeholders.

It should be clear that the satisfaction of the project stakeholders is perhaps the most important aim of the project. The satisfaction of any stakeholder could be viewed as the difference between any expectations for its performance and the perceived value of the project. A project is considered to be successful if it manages to maintain relatively high levels of satisfaction among its stakeholders. This is a more subjective aspect of quality management. Furthermore, an increase in the stakeholder satisfaction means that the project manager has succeeded in achieving an increase between their project value perception and their expectations. This can be achieved in a number of ways, the following included:

Ensure that the stakeholder needs are accurately identified and described.

Check whether the identified requirements have been satisfied.

Assess whether the manager's perception of the requirements is different in comparison to the actual requirements.

Ensure that the formal project specification accurately reflects the project manager's perceived requirements.

Align the produced deliverables to the actual requirements they are supposed to address.

Avoid misleading project stakeholders to expectations that are unlikely to be satisfied.

Reduce the differences between the quality of the project outputs and their perceived value that stakeholders may have been led to expect.


© ABE

Performance Criteria

Following the definition of the quality concept, it is necessary to consider how quality relates to project performance. There are two concepts we should take under consideration, including quality performance and quality conformance. The main difference is in the way these concepts affect the project life cycle. More specifically:

The project's quality conformance indicates whether certain quality criteria are addressed in order to produce project outputs of successful quality.

The project's quality performance indicates whether the effort required to achieve certain quality criteria affects certain performance indicators.

The project manager must ensure that the project processes are planned in such a way that certain project quality objectives are achieved. The issues that should be taken under consideration include:

Organisational strategy

The organisation's mission is likely to affect how the project quality aims are achieved. The strategic planning of the organisation's structure and resources affects the perceived quality standards for its projects. For example, the quality of the project could be dependent on the availability of resources and the procedures followed throughout the project life cycle.

Stakeholder requirements

The needs of those who are actively involved in the project should be taken under consideration as they are likely to affect the way they participate in the project activities. In addition end-users and customers have certain requirements that must be met by the project outcomes.

Project outputs

The project deliverables have a perceived quality relating to the expectations and perceptions of the end-users. In those cases where the project deliverables are in the form of products, certain characteristics are used to measure the quality of the delivered product. Similarly services are evaluated against certain features that are associated with high levels of quality.

Conformance criteria

There are several criteria demonstrating that the project conforms to certain quality measures that are imposed by the organisation or external stakeholders and independent parties.

Performance criteria

There are also certain criteria used to assess whether the project's performance adheres to specific acceptable standards.

Measuring Progress

Establishing an understanding of how to measure the progress of a project with respect to quality is very important. The project manager must be able to determine certain standards against which the project's progress can be evaluated. These standards should be widely accepted and therefore formed in a way that they are:

Realistic – the identified quality standards should be realistic to achieve without exceeding the project's resources.

Reliable – any quality standards should be consistent in providing an accurate reflection of progress for different projects and their stages.


© ABE

Valid – in order for the quality standards to be acceptable they must be justified by scientific or similar means.

Clear – the quality standards must be easy to understand by everyone who is involved in the production of the project deliverables or their use.

Measurable – similar to the project's objectives, acceptable standards must be quantifiable to facilitate the project manager when assessing the project's progress.

The development of quality standards is based on a step-by-step iterative process. These steps include:

defining the quality standards

agreeing the quality standards with the project stakeholders

identifying stakeholders who should be involved with the determination of these standards

collecting information required to define the standards

testing the standards

communicating the standards.

Following this process, a number of steps can be identified to assist project managers in quality design. Such steps may include:

identifying the project deliverable that must be designed

defining the objectives for the project deliverable

determining those stakeholders who are affected by the project deliverable

gathering the project requirements and stakeholder needs

prioritising the identified requirements

associating project activities to the project requirements

linking project deliverable features to each project activity

introducing the new process in the project

testing the process against identified standards

deploying and monitoring the new process.

Think Point 2

How can project managers plan and design for project quality?

When the focus is on establishing a project plan of high quality, project managers must ensure that a series of steps is followed to address the quality requirements identified. The design of a project management approach should focus on both supporting the project plan and schedule as well as ensuring that project support is in line with the identified requirements.

These steps ensure that the project quality control is such that any new process is thoroughly checked against quality criteria and is sufficiently planned to reduce the possibility of failure.


© ABE

Techniques for Assessing and Maintaining Quality Requirements

There are specific areas of the APM and the PMI body of knowledge relating to the management of quality. More specifically, the relevant areas are as follows.

Section 24 of the Association for Project Management (APM) body of knowledge, ("Quality management") outlines the basics of quality planning and control.

Section 8.1 of the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) ("Project quality management – quality planning") discusses several issues including the role of the organisational quality policy, conformance to requirements, the role of prevention versus inspection, etc.

Section 8.2 of the PMI Project Management Body of Knowledge ("Project quality management – quality assurance") focuses on quality planning and audit.

Quality Requirements Defined

Depending on the nature of the project, several quality factors and criteria can be identified. These may be used as guidelines for defining qualities and assessing the project's quality performance. The following list is indicative:

Accessibility – this relates to the accessibility of information to project stakeholders. It may include (i) penetration to user groups and communities, and (ii) transparency of the project outputs without the need for the intended users to possess special skills and capabilities.

Correctness – determines whether the project specification is in line with the project requirements. It may include (i) completeness in terms of deploying all required functions, (ii) consistency of project output between all deliverables and (iii) accuracy of project outputs according to precise requirements.

Effectiveness – means using resources in an optimum way.

Efficiency – meeting the requirements with an optimum use of available resources.

Expandability – means supporting the scalability of the project to deal with an additional volume of information, activities and tasks. It may include (i) augmentation of project functions and information, (ii) modularity of project components and (iii) simplicity of project deliverables.

Feasibility – means offering the expected outcomes within the estimated financial budget.

Integrity – granting access to project resources and tasks only to authorised stakeholders. It may include (i) security mechanisms for accessing project resources and (ii) auditability of actions including modifications.

Interoperability – exchanging information and resources with other projects. It may include (i) commonality of tasks and outputs between projects and (ii) independence of the project deliverables from the environment.

Maintainability – allowing the maintenance of the project systems and outputs after their deployment. It may include (i) conciseness of project functions, (ii) consistency of project deliverables, (iii) modularity of project outputs and (iv) simplicity of project functions.

Portability – supporting the deployment of project deliverables to other environments. It may include (i) independence of the project deliverables from the environment, (ii) modularity of project outputs and (iii) standardisation of project processes.

Potential – extending the organisation's scope and provision.

Presentation – meeting the aesthetic requirements of stakeholders and end-users.


© ABE

Profitability – increasing the productivity and performance of the organisation with the use of the project deliverables. It may include (i) productivity of stakeholders, (ii) affordability of project operations and (iii) the cost-benefit balance/ratio.

Reliability – coping with a variety of situations and conditions during the project life cycle. It may include (i) recovery from irregularities and (ii) accuracy of project output.

Reusability – sharing project tasks, outputs, processes, procedures and deliverables.

Timeliness – adhering to the estimated time frame.

Usability – offering usable and understandable project outputs to end-users and stakeholders.

Assessing Quality

Apart from the perceived value of deliverables, the quality of a project may be assessed in terms of the evaluation of its performance. Project stakeholders may consider several aspects that can be used as a measurement for quality. For example, the project may be assessed in terms of its progress and costs with respect to its original plan. The fact that some projects may exceed the original budget and time frame may be perceived as a sign of not meeting quality standards.

A control process may be introduced in order to assess the quality of a project. This process may involve the following steps:

Creating a baseline plan – this is used to establish the original targets of the project and monitor whether the project progress fails to meet any of them. If any deviation from the initial plan is monitored, the effects of these changes on the project quality must be estimated.

Measuring the progress and performance of the project – meaning that the project life cycle is monitored to ensure that the project progress is recorded and any performance issues are identified and addressed.

Comparing planned and actual progress – the project actual progress should be used to assess whether the stakeholder expectations are likely to be satisfied or the project will be perceived as a possible failure.

Deciding corrective action – this step involves a reaction from the project manager to ensure that the project can be realigned to meet the expectations of its stakeholders.

Assessing and Managing Quality – Software Products

The management of quality takes another turn when a project involves the use of computer technology. In such cases the project manager must be capable of controlling quality issues relating to the use of the technology as well as any software products that may be delivered during the project life cycle. The effective use of the technology is critical for the success of projects that are dependent on it for the facilitation or even the completion of specific tasks.

Technology may be part of the communication and information exchange taking place during the project or be integrated in the development activities of certain project roles. Any failures in the first scenario are likely to affect the effectiveness of collaboration between team members and may lead, indirectly, to a performance decrease. In projects where technology is integrated in project roles and tasks, the effects of any technological problems may lead to the cancellation of project activities, significant delays and even failure.

Quality concerns are therefore associated with the way technology is used and whether there are any mechanisms in place ensuring that technology is a driver for project performance rather than an obstacle to progress. Quality assurance mechanisms may include organisation policies for the proper use of technology, and procedures and guidelines


© ABE

that aim for the education and training of individuals as well as rules that should be applied in project settings, by team members and in management practices.

There is a more intense use of technology in those projects that include the development of software as part of their objectives. Here the entire project deliverables may take the form of software applications. There is a dedicated specialism focusing on software quality and the criteria used for measuring the success of organisations in developing high-quality software.

Software Quality Explained

Software quality can be evaluated in a number of ways including more formal approaches using measurable criteria. These criteria can be used to assess the quality levels of software products, and may be based on more objective data collection methods that monitor performance indicators of the software applications.

As software quality relates to the experience of its intended end-users, it may also be evaluated in a more subjective way by using surveys and observation techniques in order to gather subjective data relating to the users' perspectives in terms of their experiences and expectations.

Some of the criteria relating to the evaluation of software quality can be identified as:

Requirements conformance – associated with the user and stakeholder requirements with respect to the purpose of the software.

Specification conformance – relates to the software functionality which must be in line with the specification created from the requirements gathered and dictates the functions that are necessary for the project to achieve its intended scope.

Reliability – addresses any issues relevant to any problems arising when using the software, and the performance of the software in different environments and scenarios.

Scalability – indicates whether the software application can be extended to more users, computers, locations and other departments. The concept relates to the ability of the software to serve additional users and withstand further exploitation of its offered functionality.

Completeness – this reflects on the extent of functionality supported by the software by assessing its initial scope as dictated by the identified requirements.

Stability – provides an estimation of the software limitations and a benchmark to use for establishing the borderline between failing and performing software.

Fault tolerance – indicates software that allows a degree of failure by partially reducing functionality rather than collapsing completely.

Documentation – provides an overview of any supporting documentation that can be intended either for end-users (e.g. how to use the software) or developers (e.g. how to enhance or fix the software).

Extensibility – allows any future expansion and the development of additional software features.

Maintainability – relates to the ability to maintain the software and ensure that troubleshooting is feasible without any unrealistic associated costs.

Usability – assesses the end-users' perception of the software in terms of ease of use, look, feel and other similar non-functional requirements.

Why Systems Fail

There are several statistics that claim significant failure rates among software systems, and there are estimates that as much as 50 per cent of software systems fail for a variety of reasons. We must put these estimations in perspective though, as a system failure may not


© ABE

necessarily be catastrophic. Obviously a safety-critical system should be robust, as its failure may lead to unthinkable situations as in hospital, airline and railway systems. However software failure may also be associated with the ability to support only certain limited functionalities, the delivery of a portion of software that does not meet all requirements, or overruns in the estimated time and budgeted costs.

It is important to identify the real causes of system failure in order to attempt to shift the scope of project management and introduce practices that are more suitable for the development of software deliverables. A possible cause of failure is not necessarily associated with a specific type of failure.

Some possible reasons for the failure of software projects, and subsequently the developed software products, can be identified as:

Development practice

It is not unusual for software to be developed in unstructured or ad hoc ways that are likely to be prone to errors. Lacking a proper quality assurance procedure that spans across several stages of the project life cycle is likely to lead to project failure. By not ensuring the project deliverables and working practices are subject to quality evaluation, a project manager fails to address any problems associated with the way software is developed by the project team.

Incorrect assumptions

Typically, user requirements and software specification information are gathered during early stages of the project life cycle. When the project manager fails to revisit these requirements regularly, it is quite possible for the final software to be deployed in a changed setting. Quite often, project managers make certain assumptions when interpreting user requirements. This practice is likely to lead the project in a different path and result in software that is based on inaccurate requirements.

User experience

The quality of software applications is subject to user evaluation that is not always focused on the functionality provided. It may be the case that software fails to engage its users by introducing an interface that is difficult to use and frustrating to the end-user. User experience in a number of function and usability scenarios should be monitored, as it may trigger a subjective perception of the software. This may lead to disappointment, failure to persuade users to use the system and therefore the eventual failure of the project.

Hardware

Sometimes software is deployed in systems that are not capable of offering a supporting environment for its smooth operation. The lack of suitable hardware or any possible faults with the hardware infrastructure may be some of the reasons for software failure.

Software

Software does not exist in isolation: it resides on operating systems and in system tools and usually interacts with other software applications. Software failure may be caused by errors in the integration of several software deliverables, or even due to the failure of entirely different software applications.

User support

The quality of software is also related to the support received by users, including any documentation, training for the use of the software functions and guidelines for avoiding user errors.


© ABE

Deployment

The deployment and the installation of software is also another aspect associated with quality, especially since systems must fit with the organisation's need for software applications.

Think Point 3

What are the main causes for software project failure likely to be?

Software projects fail for several reasons but the primary causes relate to the lack of available resources and errors in estimating the project requirements, as well as issues relating to effectiveness of processes and efficient use of resources.

The possible causes of system failure we have identified should be considered as the main reasons for classifying a system or software application as a low-quality one. These are failures that are caused either by poor project management, user-related issues and infrastructure aspects. It is therefore necessary to manage software projects in such a way that different causes of failure are taken under consideration. Project managers should ensure that the likelihood of these causes of failure being present is minimised.

Managing Software Projects

The management of software projects needs to focus on classifying the failure causes and address related issues accordingly. The project manager should be able to deal with the software development life cycle and ensure that each stage is supported according to its needs.

Software development is a process that has clear stages based on different activities. Initially, a software project is based on a feasibility study that aims at identifying whether there are any project aspects that may affect its chances of being implemented. Early stages of the software development process include the requirements capture that involves the potential end-users of the software as well as various other stakeholders. The project then moves on to two stages that are closely related and focus on the analysis of the main software components in line with the identified requirements and a more specific design of the required software functions. Based on the design of the software system the team then moves to the development or implementation of the actual software. The implemented system is then tested to ensure that the required functions perform as expected. The evaluation of the deployed software based on the initial requirements follows, in order to assess whether the end product corresponds to its user needs.

Some of the main causes of failure can be identified as reasons for triggering project management actions. We could identify possible project management areas of concern in software-related projects and classify them according to:

poor development practices

end-user problems

development errors.

With respect to poor processes and practices, a project manager must be aware that team members involved with the development of software may be the main reason for failure. For example, the testing of software may be inadequate, especially when key functions are not tested against the requirements of the end-users. The development of software may also fail by lack of supporting documentation as the project team may focus primarily on the development of the software functions and neglect the provision of supporting manuals.


© ABE

As far as the end-users are concerned, the project manager should take under consideration the fact that their perception of the software under development may be misinterpreted and the entire process may be based on wrong assumptions. It is necessary for both end-users and the software developing team to have a common understanding of the system requirements and the main design aspects. Eventually users may not accept and support the use of the new system, leading to a complete failure. The deployment of software should be supported by training activities and detailed guidelines.

Finally, the actual development process may cause problems that may relate to the software being developed, any applications that may be needed, the operating system and other system tools that should be integrated, and any hardware infrastructure.

So far we have discussed the concept of quality and examined why systems may fail and the effect of a low-quality project. Sometimes the lack of quality may relate to the fact that the project fails to deal with changing needs and the evolution of its environment.

Review Questions 1

(a) List the five main perspectives for determining project management quality.

(b) Which criteria would you use to define project management quality?

(c) What is the role of an independent quality assurance party in establishing the quality of a project?

(d) What are the six steps involved in the development of quality standards?

(e) Suggest three general instances of non-catastrophic software system failure.


B. DEALING WITH CHANGE

Most projects face continuous changes throughout their development stages. It is quite likely, even with shorter projects, for the requirements to change: their stakeholders come up with additional needs and the immediate environment may be altered. Common changes may also include organisational changes, staffing, project scope and the availability of resources.

Distinguishing between Internal and External Changes

The project manager must be capable of identifying the main aspects of project change and manage the changes taking place. Changes may be internal to the project, or be part of a wider change taking place at the project's environment.

The project manager's concerns could focus on a number of issues, such as:

the tools and skills required for managing change

the processes followed when change takes place

the underlying principles for change at an organisational level

the human aspects relating to project changes

the effects of change on project initiatives and scope.

The main interest of the project manager should be to identify whether any changes are within the project's scope or are external to the core of the project, and therefore to be


© ABE

ignored or dealt with as issues of lower priority. In order to deal with change, the project manager must ensure that appropriate project aspects are organised in such a way that they can cope with the new situation. For example, the project will be based on clearly divided tasks and a well-defined allocation of roles and responsibilities. Any relationships between existing procedures, techniques and approaches and any proposed changes should be clearly stated and described in detail. Furthermore any required skills, resources and support should be identified and determined in association with project tasks.

The management of change relates to the overall management of the project. It should take place by means of a parallel set of steps including:

the recognition that change is needed

the design of a possible solution

the implementation of the proposed design

the realisation of the benefits from the implemented solution

the reflection of how change affects the project's output.

The need for change can be identified by listening to input from the project's stakeholders. Change may also be triggered by external events, such as new entrants in a market, competitors introducing new products, financial aspects of the organisation, the need to react to certain performance indicators, a strategic plan for shifting focus, etc.

The design of a solution should be based on the introduction of new project structures, a revised view of how technology is used, introduction of new services and products, redesign of existing processes, etc.

The implementation of a solution for change should be based on the introduction of pilot studies that focus on investigating how change affects certain aspects of the project, the introduction of new processes, restructure of the organisation and the project resources, deployment of new systems, etc.

Scope for Change

It is very important to have a clear scope for change in any project. The scope for change can be viewed as an exercise to assess the readiness of the project manager to cope with any changes introduced during the project life cycle.

The changes introduced in a project can be classified according to what is changed or who is involved.

"What" changes:

– What is the scope for change, meaning the reasons why this change is important for the organisation in general or the project in particular?

– What is the extent of the change, meaning the effort and additional resources required for implementing the change (and this is largely determined by the underlying reason for it)?

– What is the complexity of change, meaning any additional skills and expertise required for its implementation?

"Who" changes:

– Who are the people involved, meaning the number of people, their roles in the project and their agenda for change?

– Who are the people resisting changes, meaning the different obstacles for change both at individual and organisation levels?


© ABE

Think Point 4

In what ways is the "what" and "who" classification of project change useful to project managers?

Such a classification aims at providing a clear understanding of what needs to be changed (i.e. the requirements) and at identifying those stakeholders who are involved with these changes (i.e. responsibilities).

The project manager must be able to merge these "what" and "who" changes in order to establish a balance between the scope for change and the way it can be implemented. At

this stage it is essential to identify the real drivers behind any changes. Some of the key drivers for change might be:

Changing organisational needs – the organisation's mission and strategy are changing and therefore they may lead the project in a different direction.

Changing organisational structure – the organisation may change following a merger, an acquisition or other events at an organisational level, leading to restructuring of project resources and management.

Changing technology – the evolution of technology may offer more choices for supporting tools and processes that could be introduced at later stages of the project.

Changing priorities – the priorities of the organisation, stakeholders, project manager, team members and users may change, therefore requiring a revised project scope.

Changing relationships – new partners, competitors, suppliers, customers and intermediaries may affect the way the project is managed.

Changing politics – the project may be subject to new legislation, governmental influence, political and social changes.

Changing environment – the global nature of a project may change the locations involved, resource availability and operations.

Changing projects – the project objectives and associated initiatives are changed.

Changing to address failure – user errors, project problems and mistakes from the team members and the project manager make it necessary to change the project's current structure, resources, plan and development.

Managing Change

The change management process consists of two main steps, namely:

a project change request

a project impact statement.

The project change request provides the formal documentation of any changes requested for the project. Such documentation can be used while auditing changes and the effects to

the project performance and outcome. The project impact statement, on the other hand, identifies possible alternative routes for the project and the associated impact of each option. The project manager may choose to proceed with one of the identified options after consulting the possible outcomes of this decision.

When the project manager is persuaded that a change is preferred from the current pathway of the project, a project change request must be initiated. There are a number of considerations relating to a project change request. These may include whether:


© ABE

the change may be implemented within the current time frame

the change is feasible with the existing project resources

the change will affect the project schedule

the change will require additional resources

the change will need the prioritisation of the project deliverables and their deployment schedule

the change will lead to significant shift of project scope

the change effects will span outside the project's boundaries.

The process followed for project changes is structured in a number of steps including:

A change request is submitted following the identification of additional needs or the occurrence of a specific event.

The change request is reviewed and depending on its feasibility the project manager may be (i) allowed to proceed, (ii) prompted to further review the change request or (iii) denied any changes.

The change request may be reviewed and resubmitted depending on the comments received by the project manager.

An impact study should take place in order to assess the effects of any implemented changes to the immediate environment of the project, the project stakeholders and the organisation as a whole.

The impact study offers a second opportunity for iteration as it also allows the project manager to rework and resubmit the study depending on the views of the stakeholders.

Once the change is approved, the implementation plan is deployed and the change begins from the planning stage to its realisation.

These steps are quite formal in the sense that the project manager must submit proper documentation with full justification for the requested changes. Such documentation is likely to include information relating to the project, the specific activities and tasks that may be affected by the proposed change, and any resources that are also involved. The owner of the change request is specified as well as the date of the request. The justification for the requested change should include evidence of support relating to the impact of the change to the project performance as well as the benefits for the entire organisation and any positive impact on stakeholders. Finally the project manager must identify any immediate actions that are associated with the change, and a possible plan for the implementation of such actions following a possible approval for this change.

Implementing a Formal Change Control Procedure

In order to introduce a change control management process, the project manager must be capable of identifying the real drivers for project change, which we have already mentioned.

There are typically three main reasons for change, namely:

the introduction of major changes due to a number of reasons that require a significant alteration to the project

the development of a contingency plan that may be used as a fallback when schedule and budget can no longer support the project

the changes leading to improvement of the initial project plan.


© ABE

A change control system should have a number of clear goals that include:

identification of proposed changes and their drivers

determination of any effects the proposed changes are likely to introduce

evaluation of any proposed changes and their formal approval

resolution of any conflicts associated with the introduced changes

communication of changes to all stakeholders involved

allocation of responsibilities associated with the implementation of change

tracking ad monitoring of any changes.

A change control system may provide a number of benefits to the project as it allows the project manager to be in control of the change implementation. The objective is for changes to take place smoothly and reduce any negative impact on the project's performance. Some of the main benefits of change to a project can be identified as:

controlling the sequence of changes in such a way that the project remains on track

maintaining a control of how changes affect the financial aspects of the project

ensuring that the project performance remains unaffected

maintaining the integrity of the project's WBS

allocating the resources required for the implementation of change

allocating responsibilities for change

disseminating the effects of any project changes

monitoring the implementation of change.

Controlling Major Constraints (Quality, Time and Cost)

The major constraints for change are the available time frame, the associated costs and the effects on project quality. Sometimes project managers may consider avoiding change due to the impact of those changes to the project.

In order to control how these constraints may affect the introduction of change, a project manager must follow a number of steps to ensure the successful introduction of change. These steps are:

Requesting changes

The project manager must investigate the need for change and establish a good understanding of changes relating to different stakeholder needs. Once the required changes are identified a request is made to obtain support for these changes.

Assessing the impact of changes

The proposed changes should be considered with respect to the impact they may have on the project and the organisation at large. The aim is to establish that the benefits of the introduced changes are significant and that there are no major drawbacks.

Planning changes

A clear plan must be put together in order to schedule any actions leading to the proposed changes, allocating responsibilities and establishing the availability of the necessary resources.


© ABE

Testing the change plan

The plan for change must be agreed with all involved stakeholders and a test is necessary to ensure its feasibility. Any activities associated with the project changes must be carefully scheduled.

Implementing changes

Any proposed changes should be implemented taking under consideration the revised schedule and resources allocated to support the implementation of change.

Accepting changes

Once the changes are implemented the stakeholders must agree that they are acceptable and that they correspond to the scope for change.

Scope verification is a process associated with the management of change and more specifically with the efforts to address project constraints affecting change implementation. Scope verification focuses on whether the scope for change has been achieved by the implemented changes. There are three main elements in scope verification:

assessment of requested changes

recommendations for corrective actions

acceptance of deliverables.

The requested changes are assessed in terms of several aspects including their feasibility, the magnitude of change on the initial project scope, the impact on resources, etc. In principle, once a change is identified as a preferred approach for the future of a project it must be filtered carefully to establish whether it will benefit the project. Sometimes poor project performance may trigger change requests that have not been carefully prepared.

Once a change request is submitted the project manager must identify all those actions that may be required for the change to be implemented. Such actions may be part of the change, or could be triggered from certain aspects of the change, or be supportive ones that are indirectly related to the change.

Any accepted changes are likely to affect the initial form of the planned project deliverables. Additional deliverables may be produced and existing ones may be transformed. It is important to review, evaluate and reflect on how these deliverables are associated with the project's scope before accepting them.

Change Control Procedures

So far we have discussed the need for change in most projects and the various considerations of project managers that result from requested changes. It is necessary for project managers to remain in control of the implemented changes, and this requires the introduction of well-planned change control procedures.

There are several views on how a change control process can be managed. In previous chapters we have discussed various aspects of project management methods and approaches. Similarly, the way change is introduced and controlled in a project is subject to a number of viewpoints. The project manager should balance the need for change and prompt reaction to performance indicators and external events with the importance of staying in control of the project and its activities.

A number of steps that can be followed while managing the change control process are:

Using authorisation

By controlling who is allowed to introduce changes and how performed changes are delegated to certain team members, the project manager is likely to avoid losing


© ABE

control of extensive changes that may otherwise lead to overlapping, repetition, conflicts and misalignment.

Demanding justification

Each change should be fully justified and supporting documentation should offer the much-needed clarification of why change is important for the project. By identifying relevant actions for each change it is possible to increase awareness of the actual impact of the change and reflect whether it was required, as well as whether its nature is imminent.

Assessing risk

Any change to the project plan, schedule, resources and structure is likely to have an impact. It is unrealistic to expect that changes will be implemented without affecting the initial project plans. It is therefore necessary to identify how change will be experienced by the project stakeholders and provide an accurate representation of how the project tasks and deliverables will be affected. This will help to assess any risks associated with the overall change plan and more specifically the risk imposed by each single element of change that is accepted.

Preparing for audit

Record keeping is a very important activity that allows project managers to gather information with respect to any accepted changes. Such information may include the nature of the change, the way it was implemented and deployed, the effects on the project, any members involved in related actions, stakeholders who are affected by the change, etc. The preparation of such detailed records will help to improve the chances of reversing certain actions and return to previous stages if change leads to failure, and identify reasons for such failure.

Testing impact

It could be argued that change is good when it is introduced for addressing existing problems and project failures. However there could be certain aspects of a project that may not easily accommodate change. For example, the staffing of a project team, the workload of individuals, the scheduling of project tasks and the allocation of responsibility may be just some of the project aspects that may struggle to keep up with a changed project scope. It is therefore essential to test the impact change would have on the project and reflect on whether the benefits of the introduced change justify the extra strain on resources and structures.

Planning change

The proposed change is quite often in the form of new requirements, associated resource needs, supporting actions and an overall scope that puts all these change components in perspective. In simpler words, a requested change may be a project of its own. The same reasoning we used in early chapters when dealing with project planning applies to change. Change must be planned and such a plan should be integrated with the existing current project plan.

Implementing change

The planning of project change must be followed by a well-structured implementation phase which focuses on addressing the identified requirements and follows the design of the change plan. A thorough testing phase is necessary to ensure that the impact of change is in line with the initial expectations and in agreement with the scope for change, and that the change benefits have been achieved.


© ABE

Preparing contingency plans

It is not uncommon for the implementation of change to fail meeting its targets. This could lead to the existing problems remaining while the project deliverables are shifted from the original plans. A contingency plan should either allow the project manager to introduce further changes and react to the continuing problems, or return to a previous state and follow a different change plan.

Maintaining awareness

While change is implemented it is essential for the project manager to be in control of the entire process but also disseminate any important outcomes to the project stakeholders. The scope for change, the change management plan and certain evidence for the impact of change should be known by others involved in the project and the change activities. Such a practice puts individual actions in perspective, improves communication within the project team and also with others, and is likely to have a positive effect on morale and commitment.

Reflecting on change

At the end of the change process it is necessary to perform a number of tasks. Initially the implemented changes should be tested against the scope for change in order to ensure that the change has been implemented properly. The introduced changes should be evaluated by stakeholders in order to assess whether its actual impact is in line with the initial estimation and assumptions. Finally, the project manager should reflect on feedback received from both end-users (of changed deliverables) and the team members to assess whether the change was worthwhile.

Organisations may introduce customised documentation to support and formally coordinate the introduction of changes in a project. A typical example involves a change submission form that describes in detail the proposed change, its justification, the potential impact and any additional requirements relating to project resources. Additional forms can be used to provide the risk assessment for the proposed changes, the request for additional resources and preliminary plans for necessary actions and deviations from original project schedules. The customisation of change forms is necessary to fit the special requirements of different projects.

Review Questions 2

(a) What is the main criterion affecting a project manager's decision to request specific project changes?

(b) What are the seven key considerations for assessing whether a project request should be made?

(c) What are the three main activities associated with scope verification?

(d) Give an example of the documentation used to support the request for changes in a project and the implementation of these changes once approved.



© ABE

C. CONFIGURATION CONTROL

The previous section discussed in detail the scope for change in a project and the ways such changes are implemented and introduced. When introducing changes in a project the configuration of its structure, plan and schedule is altered. The project manager is responsible for control any configuration changes taking place. The main benefit of configuration control is that it offers a justification for project change and a mechanism to monitor changes and observe their impact.

Configuration control allows project managers to impose certain quality criteria on the way change is implemented. Some examples are:

justifying change requests with knowledge and awareness of the change impact

prioritising any changes with respect to their impact, benefit and related actions

filtering change requests according to specific criteria (e.g. benefits)

evaluating the actual cost of change according to a number of factors such as cost, resources and trade-offs

obtaining support from stakeholders and management

communicating change procedures, actions and outcomes

controlling change processes and the way implemented changes are introduced

maintaining the project's existing configuration baseline

documenting any changes taking place in the project

supporting the project after the introduction of the implemented changes.

Configuration control is an essential process for project managers for controlling the project life cycle. It allows managers to perform changes in a fashion that takes under consideration the project scope, any associated actions and relating costs. The configuration control of a project allows the project manager to follow a more flexible approach in the way changes are implemented. With configuration control the project manager is always aware of how changes affect the project and whether any significant deviations from the project's scope have taken place. The information provided from configuration control processes allows project managers to adjust any project operations and actions to ensure the optimum use of project resources. The fact that the configuration control process is the responsibility of the project manager ensures that any changes are authorised and are in line with the project plan.

Configuration Control Procedures

There are several ways for the configuration control of a project to take place. A number of configuration control procedure steps include changes that may take place in the project and the associated documentation. Such changes may be in the form of additional functionality that alters the project specification, alters different project processes, and varies characteristics and features of project deliverables, etc.

Reasons for introducing changes may include:

providing additional functionality as requested by stakeholders

enhancing product support

making use of new technology

improving project deliverables

addressing project problems


© ABE

dealing with safety and security concerns

improving effective use of resources

increasing project efficiency

controlling project schedule slippage.

Change may be introduced in the project once the project manager's request for change is reviewed and approved. Change review boards and configuration control boards are organisational structures that are involved in this process. In principle such entities are responsible for reviewing the change requests and make a justified decision to approve or reject any changes. It is possible for changes to receive conditional approval where specific constraints are imposed (e.g. change is approved subject to a limited budget).

Review Question 3

What is the aim of configuration control in projects?



© ABE

SUMMARY

This chapter has discussed the concepts of quality, change and configuration control. The initial section focused on the understanding of quality and its effects on project management. We looked at a number of different perspectives on quality and attempted to define quality in relation to products, services, stakeholders and value. Emphasis was given to the assessment of quality and maintenance of acceptable quality standards. The section concluded with a more detailed description of quality issues associated with software projects and the development of systems. The next section covered aspects associated with change and its effects on projects. The different types of change were classified and a detailed description of change control procedures was provided. The section also discussed how change is implemented and managed. The chapter concluded with an overview of configuration control and supporting procedures.


© ABE


Review Questions 1

(a) The five perspectives are mathematical, structural, organisational, economic and strategic.

(b) The eight dimensions of: performance, features, reliability, conformance, durability, serviceability, aesthetics, perception.

(c) The role of an independent quality assurance party is to offer a set of objective standards against which project deliverables, processes, operations and activities can be measured.

(d) The steps are: defining the quality standards; agreeing the quality standards with the project stakeholders; identifying stakeholders who should be involved with the determination of these standards; collecting information required to define the standards; testing the standards; communicating the standards.

(e) Software failure may be associated with the ability to support only certain limited functionalities, the delivery of a portion of software that does not meet all requirements, or overruns in the estimated time and budgeted costs. You may have thought of others.

Review Questions 2

(a) To identify whether any changes are within the project's scope or are external to the core of the project (and therefore to be ignored or dealt with as issues of lower priority).

(b) The key considerations are: whether the change may be implemented within the current time frame; whether the change is feasible with the existing project resources; whether the change will affect the project schedule; whether the change will require additional resources; whether the change will need the prioritisation of the project deliverables and their deployment schedule; whether the change will lead to significant shift of project scope; whether the change effects will span outside the project's boundaries.

(c) The main activities are: assessment of requested changes; recommendations for corrective actions; acceptance of deliverables.

(d) The example given in the text is a change submission form that describes in detail the proposed change, its justification, the potential impact and any additional requirements relating to project resources. Additional forms can be used to provide the risk assessment for the proposed changes, the request for additional resources and preliminary plans for necessary actions and deviations from original project schedules.

You might have thought of other examples.

Review Question 3

The main benefit of configuration control is that it offers a justification for project change and a mechanism to monitor changes and observe their impact. It allows project managers to impose certain quality criteria on the way change is implemented.

155

© ABE

Chapter 7

Project Closure and Review

Contents Page

Introduction 156

A. Project Termination 156

Human and Technical Problems Leading to Project Termination 157

Factors Affecting Project Completion 158

B. Closing Down a Project 161

Preparing for Project Closure 161

C. Documenting Project Completion 163

Final Report v. Post-implementation Report 164

Project Reporting 168

Summary 169


156 Project Closure and Review

© ABE

INTRODUCTION

A well-known anecdote refers to the fact that most projects spend 90 per cent of their duration being 90 per cent complete. This can be interpreted in a number of ways as it is likely that both the evaluation and testing stages may require more time. However, quite often projects take time to be finalised while their resources are being freed for other projects, and the project closure process depends on the project performance at earlier life cycle stages. A project should enter its closure stage once it is confirmed that it is likely to fail its objectives or when it is complete and has achieved the stakeholder needs and is ready to deploy its deliverables.

Objectives


distinguish between the human and technical problems related to project termination

identify project termination factors related to the project staff, the client, project handover, maintenance and documentation, contract completion and acceptance, financial matters and closure checklists

construct a list of actions appropriate for a project manager preparatory to closing down a project

distinguish between the purposes of the project manager's final report and the post-implementation report

summarise the contents of the project manager's final report and the post-implementation report.

A. PROJECT TERMINATION

The way a project is terminated depends not only on its success but also the parent organisation. You must appreciate that a failing project is likely to be terminated more abruptly than a successful one. A failing project is unlikely to have a graceful closure, and any resources will be expected to be dispersed amongst other projects with pending needs. A failing project is unlikely to require a lengthy reporting stage as there is a chance that no usable deliverables are produced. In some cases changes in an organisation's scope or environmental influences may lead to the abandonment of a project. Again, a project that falls under this category is not expected to have a lengthy termination procedure and lengthy documentation.

On the other hand the termination of a successfully completed project requires the production of detailed documentation that will support the sustainability of the project output. The project enters its final stage by wrapping up any activities that are not yet finalised, and ensuring a post-implementation audit provides the necessary information for its stakeholders as well as any information that may be useful for similar projects in the future.

The way a project is terminated is also affected by the organisation's policies and procedures. The way a project audit is performed and the phasing out of its final activities and dedicated resources are both dependent on the organisation's strategy.

Project Closure and Review 157

© ABE

Human and Technical Problems Leading to Project Termination

Project termination involves the completion of certain tasks and handing over control and responsibility of the project output to those stakeholders responsible for the post-implementation phase. There are certain criteria that affect the way the project termination takes place.

Achieving goals

Initially the project manager must ensure that the common goal is for the project to be completed successfully and for the project resources to be deployed elsewhere with minimum disruption and delay. Sometimes personal agendas of team members and certain stakeholders may require the continuation of the project and the extension of its activities along with the associated financial rewards. The project should have clear targets and sometimes additional benefits may act as drivers for early completion.

Preparing documentation

The project completion must involve the preparation of any documentation that can be used to support end-users and also offer an opportunity to understand how the project was managed throughout its life cycle. The prepared documentation may be used for a project review or to reflect on how the project deliverables were created.

Terminating tasks

Project termination also involves tasks associated with the closing down of any systems being used specifically for the project's scope. Such systems may include accounting systems or IT support and any additional technology that project tasks were dependent on. Sometimes project communication is supported by tools and procedures that are no longer required in the organisation.

Reviewing output

The project termination should also allow for a post-implementation review of certain activities, tasks and project outputs. The opportunity to reflect could offer a prompt response to possible omissions and could also act as an audit for the project's performance.

Redeploying resources

The project's human resources should also be deployed elsewhere within the organisation following its completion. It is necessary for staff members to be reassessed with respect to their performance, the achievement of certain objectives and the acquisition of additional skills, knowledge and experience. It is essential to review the individual profiles of team members in order to make informed decisions for their next project or roles.

Monitoring stakeholder satisfaction

The final step required for project termination relates to the stakeholders and their satisfaction levels. A project evaluation is not complete unless it takes under consideration the stakeholder perception of certain key performance indicators.

Think Point 1

Project termination may be unexpected and follow poor performance or failure. Alternatively the project could be terminated according to its initial plan. Detaching human resources from a project and its tasks, and/or the reassignment of staff members to specific tasks, depends on the reasons for the project termination.


© ABE

What factors would you need to consider in developing a strategy for the redeployment of human resources following the termination of a project?

Project Completion and Handover

The project completion and handover includes a number of tasks which ensure there are no issues that have not been addressed. Quite often these tasks require the preparation of dedicated documentation.

One of the key tasks before the formal handover of the project is to ensure that certain quality criteria are met. The reason is that quality aspects are always part of the performance indicators used for assessing project output. By establishing a commonly acceptable quality assessment, it is possible to reach a shared understanding about the project's actual performance. Failing to reach such an agreement, the project manager faces the danger of entering a lengthy negotiation process before the project deliverables are accepted.

The project handover also requires the project manager and any team members involved in the operation of certain project systems and deliverables to produce guidelines for their use. One of the key concerns in projects includes their sustainability and their operation following the project's completion. Any project outputs should be usable with minimum support that is offered by the project documentation.

The project handover should also include guidelines and suggestions for further work on the project's output. Perhaps additional projects advancing the original deliverables may be in the pipeline, requiring specific recommendations.

Factors Affecting Project Completion

Project completion is a process that must deal with several loose ends and it requires the project manager to make certain decisions. It is affected by several factors that quite often are not dependent on the project's immediate environment.

One of the key factors affecting the time frame for the project's completion is staffing. Quite often organisations must redeploy their staff members according to project needs. This is likely to trigger reallocation of team members, rethinking of the project deliverables and working practices within a project team. The lack of certain skills or availability of some team members are also some of the issues affecting the completion of the project.

The project stakeholders, end-users and clients are quite often responsible for the way the project is completed. Sometimes their needs change, leading to additional project activities and output. Alternatively clients may rethink their priorities leading to project changes.

Furthermore, the financial aspects of a project are likely to cut the project activities short and reduce the project output. A reduction in the project's budget and perhaps a restructuring of the available resources may affect the way a project is completed. It is possible that the support offered to the project may be reduced by lack of time and involvement. In such cases the project may suffer, as there is not enough input from clients to ensure that their requirements are accurately understood and fully met.

Think Point 2

Identify issues relating to the financial aspects of a project and how they may affect its termination.


© ABE

The financial issues relating to project performance may be associated with resources and staffing used by the project, any performance expectations and the assessment of whether the project is viable to continue.

Audit and Review

The post-implementation audit of a project is a process that is followed quite often by project managers who wish to offer additional information to the project stakeholders. It is also a step that may prove useful if further work is needed following up the project handover.

The audit process is required for a number of reasons, including:

Reflecting on activities

The project manager is well placed to reflect on each project activity and identify any problems. If the post-implementation audit takes place soon after the project's completion, it is likely that any immediate issues will be easy to identify and will relate to specific causes. The aim of this audit is to assess whether certain activities were problematic, and possibly to identify the reasons for any problems and the reduced efficiency of these activities.

Assessing task performance

A project audit is likely to review the project in phases and activities and eventually assess each individual task. This practice allows an assessment of whether task holders had problems meeting specific performance targets. The evaluation of team members' performance helps to identify whether additional support is needed by team members and the capability of individuals to perform particular tasks.

Triggering further actions

The audit of certain project phases may focus on specific deliverables and project outputs. It is quite possible for corrective actions to be triggered by the audit results. Although an audit takes place after the implementation of the project deliverables, it may not be too late to make any necessary adjustments to ensure that the project deliverables are fit for purpose.

Reviewing project management

A project audit may also return some findings that relate to the way the project was managed. This is likely to help project managers in their future responsibilities, as they can reflect on how their management style and decisions affected the project's performance and outcome. Similar projects may also be affected by having a baseline to compare with in future scenarios.

Changing strategy

The audit may also provide significant results that could eventually change organisation policies or even the entire strategy if certain directions seem to lead to failure. The initial requirements identified from the organisation's mission may be such that they cannot be satisfied by similar projects, and in such cases the organisation should reconsider its strategy.

Adjusting procedures

The project audit also offers an opportunity for the classification of project techniques, tools and procedures. In principle any means used by the project manager and the team are evaluated, and the findings can be used to review whether they have proven effective.


© ABE

Think Point 3

Explain why an audit would be required before or after the completion of a project.

There are several reasons why an audit may be required for a project. The focus may either be on assessing the viability of the project, or reflecting on the project performance following its termination.

There are clear benefits for an organisation that decides to perform a project audit and review. Some of these benefits can be identified as:

Increasing performance

The project manager is capable of identifying the most successful aspects of the project as well as any issues that were difficult to resolve. By prioritising those project activities and tasks in terms of their performance, the project manager is able to organise future project work plans accordingly. The organisation is also able to evaluate its workforce with respect to a number of performance criteria.

Supporting development

The appraisal of individuals can be based on the results obtained from the project audit. The findings may specify areas for further development and opportunities for training and additional learning. By specifying skills, knowledge and experience needed by team members, the audit report provides a detailed overview of training needs in the project team.

Ensuring sustainability

A project audit allows the organisation to develop a plan of how future projects of a similar nature should be managed. Furthermore, the project output can be supported with audit documentation. Finally, the organisation may use the audit findings to increase the effectiveness of team formation and role allocation within project teams.

Review Questions 1

(a) How do the organisation mission and any associated policies affect the way that the project is terminated?

(b) What are the six main steps associated with the project termination and how are these documented in a project termination report?

(c) Name three main benefits for a project to follow an audit process.



© ABE

B. CLOSING DOWN A PROJECT

When a project is closed down after the successful implementation of its deliverables a detailed procedure takes place. The way the closure of the project happens depends on how the project customer (client, end-user) wishes the handover of project deliverables to occur. Quite often project deliverables are accepted in a rather informal way.

The informal acceptance of project deliverables follows a procedure which depends on the nature of the deliverables. Some examples are:

Focusing on deadlines

The project deliverables are handed over on a specified deadline without any delay, despite the fact that part of the deliverables may not be complete. It is more important to meet the deadline rather than focus on the state of the deliverables.

Focusing on deliverable state

The project deliverables are not accepted unless they meet certain quality criteria. The focus is on addressing certain issues and meeting specific needs even if this results in delays.

Focusing on delivery

The project deliverables must be produced without any major evaluation. Usually deliverables of such a nature are outputs of interim tasks that serve as inputs of subsequent project activities. The objective is to achieve the implementation of the deliverables and to avoid project delays.

A more formal approach may be necessary depending on the organisation that has commissioned the project. In such cases, the organisation may require certain steps to be followed in order to formally sign off deliverables. These steps may include testing and evaluation tasks that assess the project deliverables against certain quality criteria. At this stage the project deliverables may be assessed against a baseline or a benchmark scenario. Usually the stakeholders will follow a checklist including certain items that are grouped together depending on particular deliverable aspects being assessed and prioritised according to specific criteria. It is possible for the project deliverables to be partially accepted, leading to further work and continuation of a portion of the project activities. The possibility for total project rejection is rather unlikely at such a late stage, but not impossible.

Preparing for Project Closure

The project manager must prepare for the closure of the project by following a carefully planned process. It is the project manager's responsibility to ensure that the project closure finds the organisation ready for the deployment of any deliverables, while post-implementation activities are already planned.

An initial concern relates to the fact that the project output may need to be installed, deployed and perhaps used by a variety of stakeholders. It is not uncommon for project closure to require training and support activities. A number of responsibilities associated with project closure are:

preparing the infrastructure necessary for any installation tasks required

introducing the project deliverables to the affected organisational units

disseminating the deployment plan to stakeholders involved

producing the documentation required for the installation and use of deliverables

training users for the use of project deliverables

troubleshooting the installation process and preliminary operation of deliverables


© ABE

addressing any issues rising from low acceptance of project outcomes from end-users

supporting end-users at early stages of operation

providing a sustainability plan to reduce future involvement in the operation of the deliverables

introducing a maintenance strategy for any deliverables that may require support in the future

safeguarding any resources that may be needed for future support of the project output.

Think Point 4

Project termination can be based on a number of steps depending on the circumstances. The preparation for project termination depends on how the different stakeholders are likely to be affected by it.

For a project example of your choice, identify the steps involved with the project closure and explain the need for each.

Reviews and Learning

A very important aspect of a project's closure relates to the fact that the project manager and the associated project team acquire new knowledge and learning from the project experience. Such knowledge and learning may be very useful for any subsequent projects as they can improve the way the project tasks are implemented and managed.

We can classify the project learning into two different types depending on how it is achieved. Learning can be acquired by:

The provision of learning opportunities before the commencement of the project.

The assimilation of learning experiences following the completion of the project.

The first type of learning is associated with knowledge that can be obtained from the various sources of information that may be used for project tasks. On the other hand, the learning obtained following the project completion can be associated with findings from the project audit and review phases.

The former type of learning is usually achieved from external sources, including training, education, consultations and similar learning opportunities. The objective is to ensure that the project team members have the skills that are needed to perform the project aims. The learning provided should be linked to specific project tasks. Different types of learning could support a number of tasks. Specific tasks that are based on certain skills could be supported by customised training of those team members who are responsible for them. The involvement of external consultants is necessary for the achievement of certain project objectives. Sometimes the learning associated with the project activities may have taken place in the past as an education programme fulfilled by the project members.

The latter type of learning is dependent on the project audit findings that may be associated with the need for such learning, the resources required and the need for information. This kind of learning is a more immediate response to project findings resulting from the project's audit and review.

The main difference between the two types of learning is that when learning follows a project task, it is rarely useful for the same project and should be directed to future projects with


© ABE

similar tasks. On the other hand when learning is provided in advance of the project tasks, its outcomes are likely to affect the performance of the project.

Review Questions 2

(a) Identify three key perspectives that might be followed when putting together a procedure for accepting project deliverables.

(b) What are the key differences between "learning from doing" and "learning before doing"?


C. DOCUMENTING PROJECT COMPLETION

The completion of a project is itself a very important project stage. Project success depends not only on how its deliverables are produced, but also on the way they are deployed and handed over to the intended users.

Project completion is affected not only by the documentation of the process, but also by any documentation that is associated with the final deliverables as well as any activities that may follow the project completion.

The project documentation is a critical aspect of the project management process for a number of reasons such as:

Project documentation provides a consistent point of reference for any future work that may be undertaken on the project deliverables. The documentation clarifying the scope, design and implementation of each deliverable allows future work to be more informed and reduces the time required for familiarisation with the project deliverables.

Project documentation can be used as an archive of diary entries that may help in understanding the main issues relating to the development of the project deliverables. Such an archive increases the awareness of what was involved in their development.

Project documentation offers a detailed project record that describes project activities and tasks that are associated with the development of the project deliverables. The project deliverables can be described with respect to the required resources, their duration, any associated costs, the necessary skills and structures.

Project documentation provides a supporting mechanism for project managers who are likely to undertake similar responsibilities in the future. The existence of such documentation ensures that project managers may reflect on previous experiences prior to any decisions.

Project documentation is also used as a training tool for end-users during the deployment of project deliverables and during the introduction of the project output to new stakeholders.

Project documentation may also offer the mechanism used for the continuous development of the project team and reference points for reflecting on previous responsibilities and evaluating the way project members fulfilled their roles and performed their responsibilities.

Project documentation is sometimes used for monitoring the project progress and team performance. It may offer an opportunity to increase awareness of pending issues, as


© ABE

well as reaching consensus with respect to the actual project performance and the way it should be rated against the project plan.

Final Report v. Post-implementation Report

The documentation associated with a project depends on how thorough the documentation process is for the organisation concerned. The structure and detail of the produced documentation also relates to the project scope, its activities, the supporting structures and the implemented deliverables.

A range of associated documents may be required at the project completion stage. These include:

overview statement – provides a project overview in a concise way, focusing on the project's scope

proposal – discusses in detail the project scope and overall aims as well as more detailed objectives

schedule – describes the schedule of any project activities including any revisions made following project changes

meeting minutes – offers a detailed archive with an outline of issues discussed during each meeting, any decisions made on the day and possible actions that were delegated to members and were followed up after the meeting; may also include the outcomes of any actions resulting from previous meetings

status report – a thorough analysis of the project progress, the team performance and the status of each project activity and associated tasks

design – a variety of forms can be used in documenting project designs as these may include a detailed list of actions, a more formal specification or even illustrations

change requests – the detailed justification of each change request offers a rationale for any project revisions

change notification – the description of the implemented changes may be used to understand any deviations from initial project plans and the way changes are implemented

communication – a diary of communications that are likely to be in written format are stored for future references, auditing and tracing decisions and actions to their source

outstanding issues (to-do lists) – a report on issues that are still in need of attention provides an estimation of work requirements and any pending actions

deliverables – a detailed document that describes each deliverable in terms of its objectives, the way it was designed and implemented, the requirements it satisfies and any aspects necessary for its deployment and use

acceptance document – a detailed form that is used to confirm the formal acceptance of the project deliverables by the client

final report – the final report on the project's life cycle, reflecting on its achievements, the completion results and any produced deliverable

post-implementation audit report – a report that provides an evaluation of the project outcomes against its requirements.


© ABE

Improvement Activities

Following the completion of a project we must be able to identify not only those project elements that contributed to its success but also any issues that affected its optimum performance. Certain improvement activities may include the identification of key issues that may relate to future projects, reflection on lessons learned and decisions made and reporting on how the project evolved and progressed through its life cycle. The creation of a post-implementation audit is necessary for contributing to the development of a management strategy for similar projects.

The post-implementation audit is a process that is extremely useful for everyone involved in the project. The project manager should be able to reflect on the project's performance throughout its life cycle. Certain lessons are learnt during certain project phases and it is necessary to provide such information to stakeholders, any project members that are likely to be involved with similar projects in the future and the organisation, in order to identify and assess similar issues in other projects.

The post-implementation audit has a single scope: to examine how the project progressed and whether its performance was in line with the initial plan. Issues such as goals, specific objectives, budget, resources, specification of output, deliverables, deadlines and even human resource concerns should be taken into account. The post-implementation report should not be viewed as the manager's diary reflecting on an individual's experience of the project. Documenting this audit should be based on a clear structure providing sufficient detail about any major observations. Although the perspective of those involved in the audit is likely to be subjective when certain areas are covered, the aim should be to produce a discussion that is as objective as possible.

The post-implementation audit should be based on a detailed log of project activities and tasks. The main reason for this is that the audit needs to be based on facts and any actions or events that have affected the project and those responsible for it. Although the project deliverables provide an indication of quality and performance indicators they are likely to only provide a snapshot of the final stages leading to their deployment after they are finalised. A more dynamic review of the project life cycle should therefore be based on what did actually take place while the project deliverables were being prepared.

Project managers who have kept a project log of major events, reasons for decisions, key actions, changes that may have been introduced and outcomes from meetings are likely to be more prepared for such an audit. Six necessary steps can be identified as a baseline for organising the project's post-implementation audit and these are identified next.

The first step should focus on assessing whether the project goals have been

achieved. The aim is to examine whether the project delivered what was required. This step may consider examining both the project team's perspective as well as the client or end-user perspective. For example, the project scope may be perceived from a different viewpoint even at the final stages of the project. This step should first examine whether the promises made by the project team were kept. In other words, whether the project team produced deliverables that achieve what they claimed when producing the original plan and supporting designs. Furthermore this step should investigate whether the requirements for each deliverable and project outcomes have been satisfied.

The second step should emphasise the way the project deliverables were produced. This step could assess whether the project met certain quality criteria associated with the budget, deadlines and specification. As discussed in the sections relating to quality, the project's success depends on how the original budget and time frame were treated and is affected by any delays and excessive costs. This step should also concentrate on whether the project deliverables are in line with the project specification.

The third step should focus on the stakeholders involved in the project and more

specifically with their perception of the project deliverables. In other words the end-


© ABE

users should be consulted to ensure that their original requirements were met. This step should also consider how project changes may have affected the way the original needs were altered. The aim should be to identify whether the final deliverables are in line with the end-user needs.

The fourth step should provide a more generic and bigger picture for the project by

assessing whether the project outcomes offered real value to the organisation. The project's scope should exceed the production of specific deliverables and focus on how the projection completion is likely to affect the organisation as a whole. The value of the project to the entire organisation should be assessed in terms of how it further supports the organisation in achieving its mission.

The fifth step should be geared towards reflection on project management

techniques and the procedures followed. The project audit is necessary to consider the way the project was managed and whether certain actions should be identified as helpful in solving known problems or as being ineffective.

The sixth step should provide a classification of the project experiences in the form

of guidelines for future similar actions. The scope of this step would be to identify those aspects of the project that worked but also cases of failure and the reasons for different types of failure.

Justifying Project Decisions

By reading through the documentation supporting a post-implementation audit we can assess how the project was managed and whether certain actions were triggered by certain events, external influences or project management decisions.

The justification of a project management approach, the methodology and techniques used to produce the project outputs, the methodology for implementing the plan project activities as well as the involvement of stakeholders must be documented in detail. The preparation of

a final project report addresses such issues while providing a detailed description of how the project progressed from its initiation stage to its completion.

The final report could be structured in a number of sections addressing certain themes. Organisations usually follow set guidelines when drafting project reports, and it is quite common for prearranged templates and section headings to be used. In this section, a few suggestions are provided for the required final report structure.

The project performance should be discussed clearly in the core of a final report. A reflective approach is recommended providing a detailed analysis of how certain performance indicators were used to assess whether the project met its objectives. The success of a project could be measured in a variety of ways, as far as it provides an accurate representation of how the project outcome is perceived by all associated parties.

The organisation of the project should be clearly described as it would put the progress performance within the required context. The structure of the project resources and their association with specific project requirements and objectives is necessary. The identification of any planning deviations and the grouping of project activities and tasks are necessary in order to provide a hierarchical view of any actions and events that have taken place.

The project report should also include a detailed discussion on the methodology imposed by the organisation and the style of the project manager in charge, as well as any specific techniques and tools used in order to achieve its targets.

Typically a project macro-analysis and a micro-analysis are likely to be included in a final report. The scope of such analysis is to place the project outputs within the project environment and explain how the project deliverables are likely to affect the organisation's success in the future. Such analysis is likely to take place before the commencement of the project and a review could be performed prior to the deployment of any deliverables. The macro-analysis should focus on external and environmental factors affecting the project


© ABE

output including political, social, economic and other factors that are present in the relevant field. A more focused analysis should concentrate on the specific project and provide an overview of the project's main strengths and weaknesses.

A project's final report provides an excellent opportunity to collect useful information relating to a number of issues relating to the project team and the way its members have undertaken their roles. For example, the report may state how roles are allocated, the steps taken to form the team and the way the project communication has taken place.

Think Point 5

Compare and contrast post-implementation reporting and final reporting.

The focus of post-implementation reporting and final reporting is based on the project manager's objective. Post-implementation reporting considers the auditing of the project's performance while the final project reporting offers a reflection on project actions.

Evaluation of Quality Costs

Project closure depends on a final decision that must take under consideration a number of factors. This decision should assess whether the project performance is such that it requires an early ending, or whether the project performance justifies the completion of its expected life cycle.

Project performance can be assessed in a number of ways, each contributing to the final decision on the project's completion. Some of these performance-related considerations include:

planning – relating to the way the project phases are planned in line with the project objectives and whether the original plan is followed

scheduling – relating to the problems the project faces with respect to the original time frame and any deadlines associated with project deliverables

organising – relating to the way the project manager organises the project and ensures that the project heads in the right direction

staffing – relating to human resource issues that may affect the viability of certain tasks and the project as a whole

controlling – relating to the way specific tasks are coordinated, the monitoring of team performance and the collaboration between team members.

The performance evaluation of the project is likely to provide an overview of key quality issues and associated costs. It is important to reflect on the fact that unless the quality requirements are met within an acceptable range of resources and costs, there is no reason for the continuation of the project.


© ABE

Project Reporting

The project completion is followed by the project documentation that is produced during the closure stages of the project. The creation of any project reports should take under consideration a number of views that are important for reflecting on the project's success. Initially the project report should aim at addressing any project issues relating to stakeholder needs and their interests. The project report should also focus on how the project is perceived according to:

the organisation's perspective

the project team's perspective.

An organisation perspective of the project's success should focus on the way the organisation's resources have been used for the purposes of the project deliverables. The project report should provide an overview of how the organisation has supported the project tasks by assigning resources, allocating the most suitable team members and dealing with risks and costs.

The team perspective should be reported with respect to the way tasks have been allocated and implemented. The perspective of team members might also focus on how the project plan was followed, how certain skills have been exploited and the way team members collaborated and coordinated throughout the project life cycle.

Project Completion Documentation

The documentation that is produced following the project's completion should be structured in a way that provides the necessary information for reflecting on the project's success, but also supporting the deployment of the project deliverables.

The project documentation should be initiated with an overview that classifies the project with respect to its size, complexity, objectives, staffing, resources, support, scheduling and planning.

The project documentation should also include an analysis of how the project progresses towards the achievement of its objectives and overall aim. The project report should also consider how resources have been used and how staffing was allocated.

Additionally the project completion report should include sections on the project decisions, justification and any lessons learned as discussed earlier in this chapter.

Review Question 3

Name as many of the 14 main types of documentation that are required at the project completion stage as you can.



© ABE

SUMMARY

This chapter concluded our study of project management by providing an overview of project closure and review. We discussed the main considerations relating to project termination, the process of closing down a project and the documentation of the project completion.

Project termination was discussed in terms of both human and technical factors affecting the termination decisions. The first section was also concerned with the audit and review processes as well as any associated documentation.

The second section described in detail the process involved in the closure of a project.

The chapter concluded with a discussion of the differences between the final report and the post-implementation report. More specific issues relate to improvement activities, the justification of project decisions, the evaluation of quality costs and any project completion documentation.


© ABE


Review Questions 1

(a) A change in an organisation's policies or mission may lead to a project being abandoned, e.g. if the project is no longer relevant to the organisation's purpose or simply a lot less important than it was previously. The way a project audit is performed and the phasing out of its final activities and dedicated resources are both dependent on the organisation's strategy.

(b) The main steps are:

The project manager must ensure that the common goal is for the project to be completed successfully and for the project resources to be deployed elsewhere with minimum disruption and delay.

The project completion must involve the preparation of any documentation that can be used to support end-users and also offer an opportunity to understand how the project was managed throughout its life cycle.

Project termination also involves tasks associated with the closing down of any systems being used specifically for the project's scope.

Project termination should also allow for a post-implementation review of certain activities, tasks and project outputs.

The project's human resources should also be deployed elsewhere within the organisation following its completion.

A project evaluation is not complete unless it takes under consideration the stakeholder perception of certain key performance indicators (satisfaction levels).

(c) The text suggests increasing performance in the future, supporting development of team members and project teams, and ensuring sustainability for future projects. You might have thought of other benefits.

Review Questions 2

(a) The text identifies three alternative project acceptance procedures focusing on: deadlines, deliverable state and delivery with evaluation.

(b) The main difference between the two types of learning is that when learning follows a project task, it is rarely useful for the same project and should be directed for future projects with similar tasks. On the other hand when learning is provided in advance of the project tasks, its outcomes are likely to affect the performance of the project.

Review Question 3

Those given in the text are: overview statement; proposal; schedule; meeting minutes; status report; design; change requests; change notification; communication; outstanding issues; deliverables; acceptance document; final report; post-implementation audit report.

PROJECT MANAGEMENTabeproject.weebly.com/uploads/3/0/8/2/3082433/l6... · project plan. 3.4.1...

Documents

Transcript of PROJECT MANAGEMENTabeproject.weebly.com/uploads/3/0/8/2/3082433/l6... · project plan. 3.4.1...