Course Workbook

PMP® PREPARATION COURSE

Workbook

Volume

PMP® Preparation Course

Workbook

2010 Promantia Global Consulting LLP Bangalore, INDIA.

Table of Contents

ORGANIZATION OF THE STUDENT GUIDE ............................................................................... 1

PROJECT FRAMEWORK ........................................................................................................... 1

PROJECT ...................................................................................................................................... 1 PROGRAM .................................................................................................................................... 2 PORTFOLIO .................................................................................................................................. 2 STAKEHOLDER ............................................................................................................................... 2 CONSTRAINTS ............................................................................................................................... 3 ROLE OF A PROJECT MANAGER ........................................................................................................ 3 ORGANIZATION STRUCTURES ........................................................................................................... 4

Functional Organization ........................................................................................................ 4 Projectized Organization ....................................................................................................... 5 Matrix Organization .............................................................................................................. 5

PROCESS GROUPS ......................................................................................................................... 7 PROJECT PHASES ........................................................................................................................... 8 PROJECT LIFE CYCLE ....................................................................................................................... 9 COMMON INPUTS ....................................................................................................................... 10

Organization Process Assets ................................................................................................ 10 Enterprise Environment Factors .......................................................................................... 11

KNOWLEDGE AREAS IN PMBOK® GUIDE......................................................................................... 11 FREQUENTLY ASKED QUESTIONS .................................................................................................... 14 PRACTICE QUESTIONS .................................................................................................................. 15 ANSWERS TO PRACTICE QUESTIONS ................................................................................................ 17

INITIATING PROCESSES ......................................................................................................... 19

DEVELOP PROJECT CHARTER ................................................................................................ 20

PREPARE BUSINESS CASE .............................................................................................................. 20 SIGN CONTRACT .......................................................................................................................... 21 PREPARE PROJECT CHARTER .......................................................................................................... 21

Identify a Project Manager .................................................................................................. 21 Authorize Project Manager ................................................................................................. 21

PROJECT SELECTION ..................................................................................................................... 22 Benefit Measurement Methods........................................................................................... 22 Constrained Optimization Models ....................................................................................... 25

FREQUENTLY ASKED QUESTIONS .................................................................................................... 25 PRACTICE QUESTIONS .................................................................................................................. 27 ANSWERS TO PRACTICE QUESTIONS ................................................................................................ 28

IDENTIFY STAKEHOLDERS ..................................................................................................... 29

WHY IDENTIFY STAKEHOLDERS? ..................................................................................................... 29 COMMON MISTAKES MADE WHILE IDENTIFYING STAKEHOLDERS ........................................................... 31 FREQUENTLY ASKED QUESTIONS .................................................................................................... 32 PRACTICE QUESTIONS .................................................................................................................. 33 ANSWERS TO PRACTICE QUESTIONS ................................................................................................ 34

PLANNING PROCESSES ......................................................................................................... 35

COLLECT REQUIREMENTS ..................................................................................................... 36

GATHER REQUIREMENTS FROM STAKEHOLDERS .................................................................................. 36 MAKE QUICK DECISIONS ................................................................................................................. 37 USE CREATIVE TECHNIQUES ............................................................................................................ 38 OUTPUTS OF COLLECT REQUIREMENTS ............................................................................................. 38

Requirements Document ...................................................................................................... 38 Requirements Management Plan......................................................................................... 40 Requirements Traceability Matrix ........................................................................................ 40

FREQUENTLY ASKED QUESTIONS ..................................................................................................... 41 PRACTICE QUESTIONS ................................................................................................................... 41 ANSWERS TO PRACTICE QUESTIONS ................................................................................................. 43

DEFINE SCOPE ...................................................................................................................... 44

DEVELOPING DETAILED DESCRIPTION OF REQUIREMENTS ..................................................................... 44 CONTENTS OF A SCOPE STATEMENT ................................................................................................. 45 FREQUENTLY ASKED QUESTIONS ..................................................................................................... 46 PRACTICE QUESTIONS ................................................................................................................... 46 ANSWERS TO PRACTICE QUESTIONS ................................................................................................. 48

CREATE WBS ......................................................................................................................... 49

DEFINING WORK PACKAGES ........................................................................................................... 50 DECOMPOSING A DELIVERABLE ....................................................................................................... 50 SIZE OF A WORK PACKAGE .............................................................................................................. 50 OUTPUTS OF CREATING WBS ......................................................................................................... 51 FREQUENTLY ASKED QUESTIONS ..................................................................................................... 51 PRACTICE QUESTIONS ................................................................................................................... 52 ANSWERS TO PRACTICE QUESTIONS ................................................................................................. 54

DEFINE ACTIVITIES ................................................................................................................ 55

CREATING AN ACTIVITY LIST ........................................................................................................... 55 DEFINE ACTIVITY - OUTPUTS .......................................................................................................... 56 FREQUENTLY ASKED QUESTIONS ..................................................................................................... 57 PRACTICE QUESTIONS ................................................................................................................... 58 ANSWERS TO PRACTICE QUESTIONS ................................................................................................. 59

SEQUENCE ACTIVITIES .......................................................................................................... 60

TOOLS & TECHNIQUES TO SEQUENCE ACTIVITIES ................................................................................ 60 SEQUENCE ACTIVITIES - OUTPUTS .................................................................................................... 64 FREQUENTLY ASKED QUESTIONS ..................................................................................................... 64 PRACTICE QUESTIONS ................................................................................................................... 65 ANSWERS TO PRACTICE QUESTIONS ................................................................................................. 66

ESTIMATE ACTIVITY RESOURCES .......................................................................................... 67

DEVELOPING ACTIVITY RESOURCE REQUIREMENTS .............................................................................. 67 DEVELOPING A RESOURCE BREAKDOWN STRUCTURE ........................................................................... 68 FREQUENTLY ASKED QUESTIONS ..................................................................................................... 68 PRACTICE QUESTIONS ................................................................................................................... 69 ANSWERS TO PRACTICE QUESTIONS ................................................................................................. 70

ESTIMATE ACTIVITY DURATION ............................................................................................ 71

DEVELOPING ACTIVITY DURATION ESTIMATES ................................................................................... 72 ACTIVITY DURATION ESTIMATES OUTPUTS ....................................................................................... 74 FREQUENTLY ASKED QUESTIONS .................................................................................................... 74 PRACTICE QUESTIONS .................................................................................................................. 75 ANSWERS TO PRACTICE QUESTIONS ................................................................................................ 76

DEVELOP SCHEDULE ............................................................................................................. 77

DEVELOP SCHEDULE – TOOLS & TECHNIQUES ................................................................................... 77 Determining Critical Path .................................................................................................... 79

DEVELOP SCHEDULE - OUTPUTS ..................................................................................................... 81 FREQUENTLY ASKED QUESTIONS .................................................................................................... 82 PRACTICE QUESTIONS .................................................................................................................. 83 ANSWERS TO PRACTICE QUESTIONS ................................................................................................ 84

ESTIMATE COSTS .................................................................................................................. 85

DEVELOPING ACTIVITY COST ESTIMATES .......................................................................................... 87 OUTPUTS – ESTIMATE COSTS ......................................................................................................... 89 FREQUENTLY ASKED QUESTIONS .................................................................................................... 90 PRACTICE QUESTIONS .................................................................................................................. 92 ANSWERS TO PRACTICE QUESTIONS ................................................................................................ 93

DETERMINE BUDGET ............................................................................................................ 94

DEVELOPING THE PROJECT COST PERFORMANCE ............................................................................... 95 Contingency and Management Reserves ............................................................................ 95

DETERMINE BUDGET - OUTPUTS .................................................................................................... 96 FREQUENTLY ASKED QUESTIONS .................................................................................................... 97 PRACTICE QUESTIONS .................................................................................................................. 97 ANSWERS TO PRACTICE QUESTIONS ................................................................................................ 98

PLAN RISK MANAGEMENT .................................................................................................... 99

PLAN RISK MANAGEMENT – TOOLS & TECHNIQUES ......................................................................... 100 CONTENTS OF A RISK MANAGEMENT PLAN .................................................................................... 100 FREQUENTLY ASKED QUESTIONS .................................................................................................. 101 PRACTICE QUESTIONS ................................................................................................................ 102 ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 103

IDENTIFY RISKS ................................................................................................................... 104

TOOLS AND TECHNIQUES FOR RISK IDENTIFICATION .......................................................................... 104 SWOT Analysis ................................................................................................................... 105 Wide Band Delphi .............................................................................................................. 106 Using Ishikawa Diagrams in Risk Identification ................................................................. 107

OUTPUT FROM RISK IDENTIFICATION ............................................................................................. 109 FREQUENTLY ASKED QUESTIONS .................................................................................................. 110 PRACTICE QUESTIONS ................................................................................................................ 110 ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 112

PERFORM QUALITATIVE RISK ANALYSIS ............................................................................. 113

QUALITATIVE RISK ANALYSIS – TOOLS & TECHNIQUES ...................................................................... 113 Risk Matrix or Risk Probability-Impact Matrix (PIM) ......................................................... 113 Problems with the Risk Matrix .......................................................................................... 114

Suggested ways to use the Risk Matrix ..............................................................................115 KEY OUTPUTS FROM QUALITATIVE RISK ANALYSIS ............................................................................116 FREQUENTLY ASKED QUESTIONS ...................................................................................................117 PRACTICE QUESTIONS .................................................................................................................118 ANSWERS TO PRACTICE QUESTIONS ...............................................................................................119

PERFORM QUANTITATIVE RISK ANALYSIS .......................................................................... 120

QUANTITATIVE RISK ANALYSIS - TOOLS & TECHNIQUES ......................................................................120 Monte Carlo Simulation .....................................................................................................121 Decision Tree Analysis ........................................................................................................125 Interpreting the Decision Tree Correctly ............................................................................127 Sensitivity Analysis .............................................................................................................128 Risk Attitudes and Utility Functions....................................................................................128 Key Outputs from Quantitative Risk Analysis .....................................................................129

FREQUENTLY ASKED QUESTIONS ...................................................................................................130 PRACTICE QUESTIONS .................................................................................................................131 ANSWERS TO PRACTICE QUESTIONS ...............................................................................................132

RISK RESPONSE PLANNING ................................................................................................. 133

FUNDING IMPLICATIONS FOR RISK RESPONSES .................................................................................134 Risk Response Planning – An example ...............................................................................135

KEY OUTPUTS FROM RISK RESPONSE PLANNING ...............................................................................136

HUMAN RESOURCES PLANNING ......................................................................................... 139

TOOLS & TECHNIQUES FOR HR PLANNING.......................................................................................139 HR PLANNING - OUTPUTS ............................................................................................................140 FREQUENTLY ASKED QUESTIONS ...................................................................................................140 PRACTICE QUESTIONS .................................................................................................................142 ANSWERS TO PRACTICE QUESTIONS ...............................................................................................143

QUALITY PLANNING ........................................................................................................... 144

IMPACT OF POOR QUALITY ...........................................................................................................144 INPUTS TO QUALITY PLANNING .....................................................................................................144 QUALITY PLANNING TOOLS & TECHNIQUES .....................................................................................145

Benefit/Cost Analysis ..........................................................................................................145 Benchmarking ....................................................................................................................145 Design of Experiments ........................................................................................................145 Cost of Quality ....................................................................................................................145 Statistical Sampling ............................................................................................................146 Control Charts ....................................................................................................................146 Flow Charting .....................................................................................................................146

OUTPUTS OF QUALITY PLANNING ..................................................................................................147 FREQUENTLY ASKED QUESTIONS ...................................................................................................148 PRACTICE QUESTIONS .................................................................................................................149 ANSWERS TO PRACTICE QUESTIONS ...............................................................................................150

PLAN COMMUNICATIONS .................................................................................................. 151

PLAN COMMUNICATIONS – TOOLS & TECHNIQUES ...........................................................................151 PLAN COMMUNICATIONS – OUTPUTS ............................................................................................152 FREQUENTLY ASKED QUESTIONS ...................................................................................................153 PRACTICE QUESTIONS .................................................................................................................153

ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 155

PLAN PROCUREMENT ......................................................................................................... 156

PLAN PROCUREMENT – TOOLS & TECHNIQUES ............................................................................... 157 PROCUREMENT PLANNING – OUTPUTS .......................................................................................... 158 FREQUENTLY ASKED QUESTIONS .................................................................................................. 159 PRACTICE QUESTIONS ................................................................................................................ 160 ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 161 FREQUENTLY ASKED QUESTIONS .................................................................................................. 162 PRACTICE QUESTIONS ................................................................................................................ 162 ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 162

DEVELOP PROJECT MANAGEMENT PLAN ............................................................................ 164

EXECUTING PROCESSES ...................................................................................................... 167

DIRECT AND MANAGE EXECUTION ..................................................................................... 168

Directing Execution............................................................................................................ 168 Managing Execution .......................................................................................................... 168

DIRECT & MANAGE EXECUTION - TOOLS & TECHNIQUES .................................................................. 169 OUTPUTS OF DIRECT & MANAGE EXECUTION ................................................................................. 169 FREQUENTLY ASKED QUESTIONS .................................................................................................. 171 PRACTICE QUESTIONS ................................................................................................................ 171 ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 173

ACQUIRE PROJECT TEAM .................................................................................................... 174

TOOLS AND TECHNIQUES TO ACQUIRE PROJECT TEAM ...................................................................... 174 OUTPUTS OF ACQUIRE PROJECT TEAM .......................................................................................... 175 FREQUENTLY ASKED QUESTIONS .................................................................................................. 175 PRACTICE QUESTIONS ................................................................................................................ 176 ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 177

DEVELOP PROJECT TEAM .................................................................................................... 178

TOOLS FOR DEVELOPING YOUR PROJECT TEAM ................................................................................. 178 Conflict Resolution ............................................................................................................. 178 Motivating your team ....................................................................................................... 179 Building a team ................................................................................................................. 179

OUTPUTS OF DEVELOP PROJECT TEAM .......................................................................................... 180 FREQUENTLY ASKED QUESTIONS .................................................................................................. 180 PRACTICE QUESTIONS ................................................................................................................ 181 ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 182

MANAGE PROJECT TEAM.................................................................................................... 183

TOOLS AND TECHNIQUES FOR MANAGING TEAM ............................................................................. 183 OUTPUTS OF MANAGE PROJECT TEAM .......................................................................................... 186 FREQUENTLY ASKED QUESTIONS .................................................................................................. 186 PRACTICE QUESTIONS ................................................................................................................ 187 ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 188

DISTRIBUTE INFORMATION ................................................................................................ 189

DISTRIBUTE INFORMATION – TOOLS & TECHNIQUES ........................................................................ 189

DISTRIBUTE INFORMATION - OUTPUTS ...........................................................................................190 FREQUENTLY ASKED QUESTIONS ...................................................................................................190 PRACTICE QUESTIONS .................................................................................................................191 ANSWERS TO PRACTICE QUESTIONS ...............................................................................................192

MANAGE STAKEHOLDER EXPECTATIONS ............................................................................ 193

MANAGE STAKEHOLDER EXPECTATIONS – TOOLS & TECHNIQUES ........................................................194 MANAGE STAKEHOLDER EXPECTATIONS – OUTPUTS .........................................................................194 FREQUENTLY ASKED QUESTIONS ...................................................................................................195 PRACTICE QUESTIONS .................................................................................................................195 ANSWERS TO PRACTICE QUESTIONS ...............................................................................................195

PERFORM QUALITY ASSURANCE ........................................................................................ 197

PERFORM QUALITY ASSURANCE TOOL AND TECHNIQUES ...................................................................197 PERFORM QUALITY ASSURANCE – OUTPUTS ....................................................................................198 FREQUENTLY ASKED QUESTIONS ...................................................................................................198 PRACTICE QUESTIONS .................................................................................................................199 ANSWERS TO PRACTICE QUESTIONS ...............................................................................................200

CONDUCT PROCUREMENTS ................................................................................................ 201

CONDUCT PROCUREMENTS – OUTPUTS ..........................................................................................202

MONITORING & CONTROLLING PROCESSES ....................................................................... 205

MONITORING & CONTROLLING .......................................................................................... 206

MONITOR & CONTROL PROJECT WORK ..........................................................................................206 PERFORM INTEGRATED CHANGE CONTROL ......................................................................................207 REPORT PERFORMANCE ...............................................................................................................208 CONTROLLING SCOPE, SCHEDULE, AND COSTS .................................................................................209 PERFORM QUALITY CONTROL V/S VERIFY SCOPE ..............................................................................211 MONITOR AND CONTROL RISKS ....................................................................................................212

CLOSING PROCESSES .......................................................................................................... 215

Table of Figures

FIGURE 1: RELATION BETWEEN PROJECT, PROGRAM AND PORTFOLIO ..................................... 3 FIGURE 2: FUNCTIONAL ORGANIZATION ..................................................................................... 5 FIGURE 3: PROJECTIZED ORGANIZATION .................................................................................... 5 FIGURE 4: WEAK MATRIX............................................................................................................. 6 FIGURE 5: STRONG MATRIX ......................................................................................................... 7 FIGURE 6: BALANCED MATRIX ..................................................................................................... 7 FIGURE 7: PROCESS GROUP INTERACTIONS ................................................................................ 8 FIGURE 8: PROJECT LIFE CYCLE (BORROWED FROM PMBOK GUIDE 4TH EDITION PAGE 16) ..... 9 FIGURE 9: STAKEHOLDER INFLUENCE & RISKS ON PROJECTS (BORROWED FROM PMBOK

GUIDE 4TH

EDITION PAGE 17) .............................................................................................. 10 FIGURE 10: PROCESS GROUPS DEFINED IN PMBOK .................................................................. 13 FIGURE 11: SCORING MODEL .................................................................................................... 23 FIGURE 12: PRESENT VALUE CALCULATION .............................................................................. 24 FIGURE 13: PROJECT SELECTION USING NPV ............................................................................ 24 FIGURE 14: PORTION OF A STAKEHOLDER REGISTER ................................................................ 31 FIGURE 15: A TYPICAL REQUIREMENTS DOCUMENT ................................................................ 39 FIGURE 16: REQUIREMENTS TRACEABILITY MATRIX ................................................................. 40 FIGURE 17: CONTENTS OF A TYPICAL SCOPE STATEMENT ........................................................ 45 FIGURE 18: PARTIAL WBS FOR PROJECT PERSIST ...................................................................... 49 FIGURE 19: CONTENTS OF WBS DICTIONARY ............................................................................ 51 FIGURE 20: ROLLING WAVE PLANNING ..................................................................................... 56 FIGURE 21: PRECEDENCE NETWORK DIAGRAM ........................................................................ 61 FIGURE 22: FINISH-START PRECEDENCE .................................................................................... 61 FIGURE 23: START-START PRECEDENCE .................................................................................... 62 FIGURE 24: FINISH-FINISH PRECEDENCE ................................................................................... 62 FIGURE 25: START-FINISH PRECEDENCE .................................................................................... 62 FIGURE 26: RANGE OF ACTIVITY DURATION ESTIMATES .......................................................... 73 FIGURE 27: FORWARD PASS - CALCULATE EARLY START AND EARLY FINISH TIMES ................. 80 FIGURE 28: BACKWARD PASS - CALCULATE THE LATE START AND LATE FINISH ....................... 81 FIGURE 29: COST PERFORMANCE BASELINE ............................................................................. 96 FIGURE 30: RISK BREAKDOWN STRUCTURE ............................................................................ 101 FIGURE 31: SWOT ANALYSIS .................................................................................................... 106 FIGURE 32: ISHIKAWA DIAGRAM ............................................................................................. 108 FIGURE 33: PROBABILITY IMPACT MATRIX .............................................................................. 114 FIGURE 34: SAMPLE RISK MATRIX CALIBRATION..................................................................... 116 FIGURE 35: SUGGESTED ALTERNATIVE RISK MATRIX BASED ON ORDINAL SCALES ................ 116 FIGURE 36: MONTE CARLO ANALYSIS - INPUTS ....................................................................... 122 FIGURE 37: MONTE CARLO - SPREADSHEET CALCULATIONS .................................................. 123 FIGURE 38: CUMULATIVE PROBABILITY FROM MONTE CARLO ANALYSIS .............................. 123 FIGURE 39: TRIANGULAR DISTRIBUTION AND ITS USE IN A MONTE CARLO SIMULATION ..... 124 FIGURE 40: SAMPLE DECISION TREE ........................................................................................ 127 FIGURE 41: INTERPRETING DECISION TREE ............................................................................. 127 FIGURE 42: FINAL EXPECTED VALUES ...................................................................................... 129 FIGURE 43: RISK RESPONSE AND PROJECT FUNDING IMPLICATIONS ..................................... 135 FIGURE 44: RAM AND RACI ...................................................................................................... 141 FIGURE 45: COMMUNICATIONS PLAN ..................................................................................... 153

FIGURE 46: WORK PERFORMANCE INFORMATION ..................................................................170 FIGURE 47: SAMPLE CHANGE REQUEST ...................................................................................170 FIGURE 48: CONFLICT RESOLUTION TECHNIQUES ...................................................................185 FIGURE 49: COMMUNICATION METHODS ...............................................................................190 FIGURE 50: SUMMARY - SCOPE, TIME AND COST CONTROL....................................................210

Organization of the student guide

P R O J E C T F R A M E W O R K

Project Framework

Project

A project is a temporary endeavor. It has a definite start date and a definite end date. A project creates a unique product, service or result.

There are two important points you need to understand:

The “temporary” characteristic applies only to the project and not to the output of the project. Outputs of most projects last for long. For example, a project may be undertaken to build an Airport in the outskirts of a city. The project may start, say on the 15th July 2009 and end on the 30th Oct 2011. However, the outcome of the project – the Airport itself – will last for several decades.

Projects may have some repetitive elements. However, it does not change the uniqueness of the project

A project starts when an individual or an organization realizes a need for it– the need can be social, environmental, and economic (for-profit) or could be driven by external factors (such as requested by customer) or factors internal to your organization. The project ends when the need is met. In some cases a project may also end when you realize that the need cannot be met by the outcome of the project.

Examples of projects include:

Developing the transmission system for a new electric vehicle

Acquiring a new MIS system for your company

Effecting a change in the organization structure of your company

Constructing a monument, building or a facility

Running an enhanced marketing campaign for a product

Chapter

Implementing a new business process in your organization

Projects always have an end date. In contrast, operations are repetitive and ongoing; they don’t have an end date.

Program

A program is a collection of interrelated projects such that it makes sense to manage them together rather than individually. Also, failure of one project may result in the failure of the entire program. Let’s say that Indian Space Research Organization (ISRO) is planning to put in orbit the INTELLESAT satellite. This initiative to launch the satellite can be managed individually as several projects – one project to build the satellite, one to setup a ground station to monitor the satellite in orbit once launched one to build & commission a launch vehicle that would place the satellite in orbit. However, since all projects share the same objectives – that of putting in orbit the satellite – it makes sense for us to manage this as a program.

Portfolio

A portfolio is a collection of projects and programs. These projects and programs may be or may not be related in that they may not share the same objectives; however there is a common theme across all the projects and programs. The theme could be that all projects and programs are being carried out for the same customer or the projects and programs may be using the same technology or they may be in the same domain, say, in the financial sector. When otherwise unrelated projects and programs have a common theme they can be managed as a portfolio to obtain benefits of coordination.

FIGURE 1shows the relationship between Project, Program and Portfolio.

Stakeholder

A stakeholder is an individual (like the sponsor or the project manager), a group (like the performing organization, the project team etc.), or an organization (like the Government, the requesting organization etc.) that have a share or interest in the project and are positively or negatively impacted by its outcome.

FIGURE 1: Relation between Project, Program and Portfolio

Constraints

Constraints are hindrances that may impact the objectives of the project. Primary constraints on a project can be in terms of scope (features to be added to a product), time (how soon can you implement these features), cost (can you reduce the costs of implementing these features). These constraints are related to each other in that changing, or acting on one of the three constraints can impact another. For example, adding most features can increase the time and cost which would be undesirable. Quality is yet another constraint which is impacted by changes to scope, time and cost.

Other project constraints that a project manager has to deal with are resources and risk.

Role of a Project Manager

The project manager is responsible for the success or failure of the project. In order to achieve the project outcomes a project manager must have:

Knowledge as well as skills to apply project management practices, tools and techniques

Soft skills – communication skills, interpersonal skills, negotiation, conflict resolution, motivation

Domain skills – It is not sufficient if the project manager have skills in project management. She must have knowledge of the domain or sector of the project. For example, a project manager responsible to build a bridge must have skills in the construction domain.

“Begin with the end in mind” - Stephen Covey.

A project manager must be able to visualize the project’s product at the start of the project. This is possible only if the project manager participates in requirements gathering and understands the big picture of the project. If a project manager cannot visualize it she would not be able to help the project team deliver the product.

To successfully achieve the project’s objectives, a project manager must be able to manage expectations of stakeholders. This can be possible only if the project manager open communication channels with stakeholders and continuously provide them the required information on the progress of the project.

And finally, to be a successful project manager, she must be able to deal with the project constraints. Balancing the project constraints – scope, time, cost, quality, resources and risk – is an absolute must in order to successfully achieve the project objectives.

Organization Structures

Structure of an organization has a major influence on performance of projects. There are 3 types of organizations – Functional, Projectized and Matrix - that you need to be aware of.

Functional Organization

A functional organization is one where employees are grouped by the skills they possess or their specialization. In these organizations each employee clearly has one supervisor and they are fiercely loyal to their department or group. Figure 2 shows a typical structure in a functional organization. In these types of organizations employees are attached to their “home” – or the department they work for – and rarely change their home. Information flow between departments is very weak. Since performing projects require significant exchange of information between departments execution of projects in this type of organization is very difficult. Project co-ordination is, therefore, at the functional manager’s level.

FIGURE 2: Functional Organization

Projectized Organization

A projectized organization is one where employees are grouped by the projects they work on. Employees don’t have a home since by definition a project has to end someday. On completion of a project team members are assigned to a resource pool and await allocation to another project. Team members can change projects unlike in a functional organization where employees rarely change their departments. Figure 3 shows a typical projectized organization structure. Exchange of information between projects is good. Project Managers often refer to lessons learnt database that stores information about historical and ongoing projects to help them understand and execute their current project better.

FIGURE 3: Projectized Organization

Matrix Organization

Both functional and projectized organizations have their share of good and bad things. It is a known fact that most organizations world-wide are fast adapting a matrix structure. Matrix organization is a mix of functional and projectized organizations

bringing together the good attributes of functional and projectized organization together. Typically, an employee reports to more than one manager – usually a functional manager and a project manager should the employee be working on a project. There are 3 types of matrix organization based on powers of the project/functional manager. These are Weak Matrix, Balanced Matrix and Strong Matrix.

Weak Matrix is one where the attributes of the organization are similar to a functional organization. Let’s look at how projects are executed in weak matrix organizations. Figure 4 shows an organization structure of an engineering company – a weak matrix organization - that wants to find out the cost and technical efficiency of a new welding technology. A team is put together to execute this project and the team members as shown in the figure are Accountant 3, Analyst 3 and Welder 1. Please note that these three employees report to their respective functional managers but for the project one of the three, say the Accountant, is chosen the project manager.

FIGURE 4: Weak Matrix

A project manager in a weak matrix is primarily responsible for communications and can be an expediter or a coordinator depending on the level of her reporting relationship. An expediter is one that reports to a lower level manager while a project coordinator is one who reports into a slightly more senior level manager. Project managers in weak matrix do not make any decisions; they only enforce the decisions made by functional managers.

A strong matrix is one whose attributes are similar to a projectized organization. In a strong matrix, project managers have relatively more power than their counterparts in a weak matrix. They are responsible for the success and failure of the projects. Project managers in this organization report into a functional manager who oversees execution of all projects in the organization e.g. Head of the Project Management Office (PMO) as shown in FIGURE 5.

FIGURE 5: Strong Matrix

Project managers in balanced matrix organizations share responsibilities with their functional counterparts. Decisions are made jointly by the functional and project manager. A typical structure of a balanced matrix is shown in FIGURE 6.

FIGURE 6: Balanced Matrix

Process Groups

PMBOK® Guide 4th edition defines 5 categories of processes. These are referred to as Process Groups. They are:

Initiating process group

Planning process group

Executing process group

Monitoring & controlling process group, and

Closing process group

Processes in the Initiating process group help you start a project or a phase of a project. Process required to define the boundary of the project and establish as well as refine objectives are part of the Planning process group. Executing process group processes helps your teams perform the work for the project and attain the planned objectives. Monitoring and controlling process group processes help you and stakeholders track the progress of the project and take corrective or preventive actions should there be a need to put the project on a desirable track. Closing group processes help you perform the closure activities including documenting the lessons learnt as well as providing feedback to the organizations’ process manager.

Project Phases

When the project is very large and you need extremely good control over deliverables then you break the project into two or more phases. Each phase can be carried out sequentially, or where possible with some overlapping elements. For each phase you can perform the applicable processes in the 5 process groups. If a project is divided into two or more phases the process groups would interact within each phase. FIGURE 7 shows how the process groups interact in a phase or a project.

FIGURE 7: Process Group interactions

Project Life Cycle

The work that you do on a project is a collection of sequential and or overlapping phases. The life cycle of a project can be decided based on the nature of the project as well as your organizations’ policies on managing projects. Irrespective of the domain or effort involved the project life cycle provides a basic framework for managing the project.

At the beginning of the project the staffing levels are low. On an IT project, for example, it is possible that the project is staffed with the just a project manager, an architect and couple of developers. Therefore, the cost expended during the initial stages of the project is low. But as the project gets into the execution phase more developers are added to the team and the costs incurred start increasing. As the project approaches closure the costs start going down. This is shown in Figure 8.

FIGURE 8: Project Life Cycle (Borrowed from PMBOK Guide 4th Edition Page 16)

At the beginning of the project the uncertainty – and therefore the risk to the project - is the greatest. However, as the project progresses this uncertainty reduces. Similarly, the ability of stakeholders to influence changes to the project is the greatest at the beginning and reduces as time progresses. These characteristics of the stakeholder ability to influence and risks on the project over time are shown in FIGURE 9.

FIGURE 9: Stakeholder influence & Risks on projects (borrowed from PMBOK Guide 4th edition Page 17)

Common Inputs

The Organization Process Assets and Enterprise Environmental Factors are inputs to a number of project management processes in the PMBOK® Guide. These are described briefly here:

Organization Process Assets

Organization Process Assets includes assets of the requesting organization and/or the performing organization that influence the success of the project. Assets include:

Organizations’ Processes and Procedures –Mature organizations have documented policies, standards, guidelines, work practices, templates as well as communication requirements for any project that is performed for internal purposes or for clients. These influence the success of projects executed in the organization.

Corporate Knowledge Base – This is a repository of data and information of past projects that were executed by the organization. The data and information may be in the form of project documents (requirements documents, design documents, test cases etc.), records and measurements (defect data, issues log, minutes of meeting etc.), financial data (business case document, project selection methods used, profitability etc.) as well as registers (risk register showing movement of risk over the period of execution of the project etc.). This information can be quite handy when project managers embark on new projects.

Enterprise Environment Factors

These are internal or external factors that influence the success of the project. These include:

Regulatory Requirement or Government Standards: E.g. the ISI standards for products in India

Organization Structure – We saw how an organization’s structure influences the performance of a project

Commercial Databases: These include commercially availability data and information that could help project team estimate the size or effort on a new project, database of risks etc.

Risk Tolerances – Stakeholders have varying levels of risk thresholds. A risk-averse stakeholder may have an opposite influence on a project that a risk taker.

Personnel Policies – These are guidelines for staffing, training, retaining and exiting staff from an organization. These guidelines definitely have a influence on the project staffing, and hence on the project success.

Project Management Software – Availability of tools for scheduling, monitoring progress, reporting is a big factor in managing projects successfully. These tools can help project managers keep their stakeholders up-to-date with the status of the projects.

Knowledge Areas in PMBOK® Guide

PMBOK® Guide 4th edition has 5 process groups and 9 knowledge areas. We have already seen the 5 process groups earlier in this chapter. The 9 knowledge areas are:

Project Integration Management

Project Scope Management

Project Time Management

Project Cost Management

Project Quality Management

Project Human Resources Management

Project Communications Management

Project Risk Management, and

Project Procurement Management

PMBOK® Guide 4th edition also defines project management 42 processes that are categorized into 5 process groups and 9 knowledge areas. FIGURE 10 shows the organization of project management processes.

As mentioned earlier in this book, while PMBOK® Guide 4th edition is organized by knowledge areas, this student guide is organized along the lines of process groups i.e., we will discuss the initiating process group processes first followed by planning process group processes and so on.

FIGURE 10: Process Groups defined in PMBOK

Frequently Asked Questions

1. In what type of organization does the project manager have complete authority over resources?

A project manager has complete authority to commit resources in a projectized organization.

2. In what stage of the do stakeholders have maximum influence over the project?

Stakeholders have maximum influence during the initial stages. See FIGURE 9.

3. State 2 differences between projects and operations

Projects are temporary initiatives and will always have an end date. Operations are ongoing

Projects result in a unique outcome (result or service or product) while operations are repetitive work

4. How is a project coordinator different from an expediter?

A project expediter does not have any authority to make decisions. She only enforces a decision made by the project manager. A project coordinator is someone similar except that this person reports to a higher level manager and so may have some inherent potential to influence decisions.

Practice Questions

1. Which of the following is a common characteristic of most project life-cycle descriptions?

a) Staffing levels & costs are low at the start. Costs increases as project gets into execution and then drops as the project nears completion.

b) More staff is required at the initiation of the project, and then gradually decreases as the project approaches execution and completion.

c) Stakeholders have maximum influence during the final stages of the product development

d) Project risks are peaking as the project approaches completion.

2. All of the following are characteristics of a project EXCEPT:

a) Has a definite start date

b) Is temporary in nature

c) Is repetitive

d) The product of the project is more permanent

3. An example of a project is

a) Constructing a 3-storied building

b) Paying your electricity bill on the 3rdof each month

c) Fixing a bug in a software program

d) Providing technical support to your customer over phone

4. Acquiring team is part of which process group?

a) Initiating

b) Planning

c) Execution

d) Monitoring & controlling

5. Defining and setting quality standards for your project is part of which process group?

a) Initiating

b) Planning

c) Execution

d) Monitoring & controlling

6. You have taken up a full-time role in a newly formed projectized organization and you have been asked to lead a project. What BEST describes your current role?

a) Co-ordinator

b) Process Manager

c) Expeditor

d) Full-time project manager

Answers to Practice Questions

Question Answer Justification

1 a See FIGURE 9

2 c Repetitive is a characteristics of operations

3 a All other options are operations

4 c Acquiring team is an execution process. We will discuss this later in the course.

5 b Setting quality standards is a planning process. We will discuss this later in the course.

6 d Note the keyword “projectized”

Initiating Processes

L E A R N I N G O B J E C T I V E S

D E V E L O P P R O J E C T C H A R T E R

Develop Project Charter

You are a Senior Manager with Financial Software Private Ltd, a small company that provides IT application development services to clients. The mission statement of your company is “to be a leading provider of IT application development services to

Banks and financial institutions”.

A prospective client approaches you with a request for development of a customized accounting application. The high-level features of the proposed accounting package are documented in a Statement of Work (SOW). As a Senior Manager you need to quickly analyze and determine if Financial Software Private Ltd. can, or cannot, take up this work. All you have is an SOW that describes the high level customer requirements.

Prepare Business Case

In order to make a decision you must perform an in-depth analysis using the SOW. As part of your analysis you would ask several questions, some of which are:

Do we have required skills or capacity to undertake the proposed work?

What benefits – financial as well as others - do we stand to gain if we take up the work?

What costs would be incurred?

What opportunity would be lost?

You would then formally put down answers to these questions in a Business Case document. In general, a business case document is prepared in response to a customer request. It may also be created as a result of a market demand, or to analyze an organizational, legal or social need. As a Senior Manager you would have prepared business case documents in the past. However, if you have never prepared a business case earlier you may have to refer to sample business case documents in your organization’s process database. The organization process database is a repository which contains process and procedure documents, templates as well as sample documents. This process database is referred to as Organization Process Asset.

Chapter

Additionally, you may have to consult experts in your organization to make sure you have included all the costs and benefits of executing the proposed work. Getting experts – internal or external - to review your business case is not a bad idea.

Enterprise Environment Factors that influence development of a project charter like your organization’s infrastructure, regulatory requirements etc. must be considered.

Sign Contract

Once completed, the business case document would help you decide if you can take up the work or not. If you decide not to take up the work the process ends here and you do not need to initiate any project.

Let’s assume that you decide to take up the work. You would then approach the client and let her know of your decision. Once you and the client agree on the terms and conditions, including financials, you would then sign a Contract. A contract is a formal document signed by the seller (the party that is agreeing to undertake the work) and the buyer (the party that is agreeing to pay the seller for the work performed).

Prepare Project Charter

After signing the contract you may start the Project Initiation activities at Financial Software. You need to

1. Identify a Project Manager, and

2. Authorize the project manager to commit resources

Identify a Project Manager

You may think identifying a project manager is an easy task but please remember this is one of the most important decisions. You will have to look at several factors such as competency, availability, knowledge of domain etc.

Authorize Project Manager

This can be achieved by issuing a Project Charter to the project manager. A project charter is a document that contains:

a) Description of the project

b) Name of the project manager and level of authority

c) Why is this project being executed

d) Pre-assignments (resources that are pre-assigned to the project)

e) High-level requirements of the project work

f) Description of the project’s output/deliverables

g) High-level schedule (key milestones)

h) Budget and funding authority

i) High-level project risks (threats and opportunities)

A project charter is a key document for any project, more so in a matrix organization. In a matrix organization, a project charter will allow a project manager to “procure” resources from different functional departments to work on the project.

The previous scenario had just one customer approaching your organization for a service. In reality there could be situations when you would have multiple customers approaching you with a request for service. Your organization would have constraints in providing services to customers. Constraints could be in terms of resource capacity, knowledge of domain etc. Also, your organization’s mission statement to be a leading provider of software development services to Banks & Financial Institutions. Given this mission statement, your organization may not want to take up any work in the domain of Media and Entertainment.

Project Selection

When you have multiple customers approaching you with a request for service, one of your objectives is to determine which of the customer requests you would service. You can use Project Selection Methods to help you decide. There are two broad categories of project selection methods – Benefit Measurement Methods and Constrained Optimization Methods.

Benefit Measurement Methods

Benefit measurement methods are comparative methods in that you compare a customer request with another customer request, and take up the one that would meet your organizations goals and strategic plans. Murder Board, Scoring Models and Economic Models are all type of benefit measurement methods.

Murder Board is a method where a selection committee is setup to go through high level objectives of customer requests/proposals. So if your organization’s mission statement is to be a leading provider of services for Banking and Financial Institutions, then there is very little chance that a proposal for software development for a client in the Media and Entertainment domain would get past this selection committee.

Scoring Models are more objective than murder board. Scoring models involve identifying and objectively rating the needs and wants of each of the options. Let’s assume that your organization has received requests for service from 3 potential clients

but your organization has capacity to execute only one. You would need to compare the benefits of executing the projects against each other and select the one that gives your organization the maximum benefit. FIGURE 11 shows an application of a scoring model. In this example the proposal from Customer C is selected. Proposal from Customer B is not evaluated as it does not meet mandatory criteria (or needs).

FIGURE 11: Scoring Model

You may use Economic Models to select a project amongst many projects. Several economic models are available of which the following are more popularly used:

Net Present Value: A sum of money offered now is more valuable than the same sum of money offered later. Economists describe this as time value of money i.e., $ 1000 one year from today would be lesser than $1000. FIGURE 12 shows a sample calculation of present value where the interest rate is known.

FIGURE 12: Present value calculation

While executing a project you may have to commit and expend resources (cash outflows) through the duration of the project while you start getting benefits (inflows) of the project usually after the project’s product/service is implemented. While analyzing the benefits of a project you would have to use Net Present Value (NPV) i.e., the present value of all cash inflows minus the present values of all cash outflows. While selecting projects you would select the one that has a higher net present value.

FIGURE 13: Project selection using NPV

Internal Rate of Return (IRR): IRR is a measure of profitability of investment made on a project. The higher a project's internal rate of return, the more desirable it is to undertake the project

Payback Period: Payback period is the duration or length of time required to recover the investment made in a project. Shorter the duration of payback, better are the chances of that project being selected. If a project costs $10,000 and the annual return is $2,500 then the payback period is 4 years ($10,000/$2,500)

Benefit Cost Ratio (BCR): BCR provides a numeric relationship between costs of a project to its benefits. A ratio of 1 or more means the benefits are more that the costs. When you have options select a project that has a higher BCR. A BCR of 3.0 means the revenues from the project are 3 times its costs.

Depreciation: Assets are used to produce goods and hey indirectly bring in revenue. Assets lose value over time due to usage, wear and tear, technological obsolescence etc. This loss of value of an asset is called depreciation. There are several methods of calculating depreciation.

Straight-line method: This method assumes that an asset loses equal value each year. For example if an asset costs $1000 and the useful life of the asset is 3 years, the asset will lose $1000/3 = $333 each year. At the end of 3 years the asset loses its complete value.

Accelerated Depreciation: This is more realistic method of calculating depreciation. An asset is assumed to lose more value initially and slightly lower values as each year passes by. Sum-of-digits-of-year is a method of calculating accelerated depreciation.

Constrained Optimization Models

Constrained Optimization Models includes Operations Research techniques such as Linear Programming, Goal Programming and Dynamic Programming.

1. Who prepares the Project Charter?

Anyone who has knowledge of the proposed work can prepare a project charter. In the scenario in this chapter we saw the project charter was created by the Senior Manager. The Senior Manager may delegate the creation of the project charter to a sub-ordinate. In some cases even a customer can prepare a charter. However, the Senior Manager is accountable to sign-off the project charter.

2. Who issues a Project Charter?

A senior person external to the project is responsible for issuing a charter. This could be the senior manager of the performing organization, the sponsor, the project initiator, the Head of the PMO or any other person at a senior level of authority.

3. What are the common inputs to developing a project charter?

In the scenario we discussed the following input documents were used to develop a charter:

Statement of work, which describes the high level requirements.

A business case document, which describes why a project must be executed.

A Contract, that lays out the terms and conditions as well as the financial reward for executing the project.

Organization Process Assets, a repository of processes, procedures, sample documents, templates etc. if the person creating a project charter is doing so for the first time.

The culture of the organization is also a key input that needs to be considered while developing a project charter. This is called the Enterprise Environment Factor.

4. Does every project need a project charter?

Project charter is required for any project performed for an external organization. For projects that are sponsored internally, an email from the senior manager/sponsor describing the project, its objectives and authorizing the project manager would fill in the need of a charter. No separate charter would be required in this case.

5. What is the significance of a project charter?

The primary objective of a charter is to authorize the project manager to commit organizational resources

6. What tools and techniques would you need to develop a project charter?

You may have to get inputs from experts (people that have developed project charters earlier) while developing a project charter. You may also have to get the charter reviewed by experts once complete. Expert judgment is an important tool/technique for developing a project charter.

7. You have been asked to select one of two projects – Project A which has a BCR of 2.5 and another Project B that has a BCR of 1.8. Which one would you select?

You would select the project which has a higher BCR (Project A in this case)

Practice Questions

1. Your manager wants to authorize a new project in your organization. What should she do FIRST?

a) Create a Project Management Plan

b) Identify all the risks that may impact he project adversely

c) Understand the detailed requirements of the project

d) Develop a project charter

2. What does a BCR of 3.1 mean?

a) Project investment is 3.1 times the benefits

b) Internal Rate of Return is 3.1 times the current interest

c) Project revenue is 3.1 times the costs

d) Net profit is 3.1times the costs

3. Double declining is an example of

a) Normal Depreciation

b) Accelerated Depreciation

c) Payback Period calculation

d) Straight line Depreciation

4. A project charter contains all of the following except

a) Name of the project manager

b) High level project risks

c) Pre-assignments

d) Traceability matrix

1 d Development of the project charter is the first thing to be done on any project

2 c BCR is benefit cost ratio (so its benefits or revenues v/s costs)

3 b Double declining is an example of accelerated depreciation

4 d Traceability matrix is an output of collect requirements process. Others are part of a charter.

I D E N T I F Y S T A K E H O L D E R S

Identify Stakeholders

Your senior manager just walked up to you and asked you to be a project manager on the new project to which you readily agreed. She also issued a project charter to you authorizing you to commit the organization resources on your project. What do you do next? Your next step is to identify ALL the stakeholders.

Identify Stakeholders is part of the Project Communications Management knowledge area. Stakeholder identification is done as part of Initiating processes. Let’s revisit the definition of a stakeholder. A stakeholder

“is an individual (like the sponsor or the project manager), a group (like the performing organization, the project team etc.), or an organization (like the Government, the requesting organization etc.) that have a share or interest in the project…”

Why Identify Stakeholders?

It is important that you identify all the stakeholders of the project. This is because some stakeholders like end-users (of the project’s product), their heads of department and others like them are responsible for specifying the requirements for the project. If you miss even one the requirements what you and your team would be working on would not be complete. You must also remember that implementing new requirements at a later stage in the project is more expensive. Therefore it is best for you to spend a good proportion of your time in identifying the stakeholders. The list of stakeholders will vary with Project characteristics such as size, scope (impact on Business), Complexity. A small departmental IT project for example may have just 2-3 stakeholders (End-users, Middle Management, and Project Team) while a large IT project that has dependencies on external organizations may have many stakeholders such as Legal Team, Multi-departmental business users, Heads of Departments, Vendors, Company Shareholders, Regulatory Authorities etc.

It is important when developing the list of stakeholders to focus on both “who” they are and what their “agenda” is with respect to the project.

Chapter

In order to identify the stakeholders you would need to review the Project Charter. You would also need to review the high level requirements that were specified in the statement-of-work. Documents like the SOW, Request for Proposal (RFP) and the like are referred to as Procurement Documents and is another input to the identify stakeholder process.

Enterprise Environment Factors and Organization Process Assets are also inputs to this process. In order to identify all stakeholders you will have to consider answers to the following questions1:

Who are the people (or organizations) that may be affected by the project activities?

Who are the people (or organizations) that would be contributing to the project activities by providing resources, people, money etc.?

Who are the people (or organizations) that would be using the project’s product?

Identification of stakeholders involves writing down the names of your project stakeholders along with their goals, interests, expectations and concerns. This will require you to interview the stakeholders and this in turn will help you identify more stakeholders. Once you are done interviewing and gathering information on the expectations of the stakeholders you would need to analyze each one of them. This involves studying the impact or support each of the identified stakeholders could provide to your project. This will help you categorize the stakeholders into homogeneous groups. The idea of categorizing the stakeholders into groups is to develop strategies of managing these groups of homogeneous stakeholders rather that developing a strategy for each stakeholder that will be very time consuming. Power-Interest or Power-Influence grids2 are some of the models you may use to categorize and develop strategies for the stakeholders.

As mentioned earlier you must identify ALL the stakeholders. It is best for you to review the list of stakeholders with experts. Experts Judgment could be sought from individuals like your senior manager, experienced project managers, key stakeholders you have already listed in your stakeholder register and subject matter experts. This review will help you assure that the stakeholder list is complete.

You document the names of stakeholders in a Stakeholder Register. A small portion of a stakeholder register is shown in FIGURE 14.

1 Managing Projects: Expert Solutions to Everyday Challenges, Harvard Business School Press, 2006.

2 PMBOK Guide 4th edition Pg. 249

FIGURE 14: Portion of a Stakeholder Register

The stakeholder management strategy document you developed must at the minimum have for each stakeholder the following information:

Name of the stakeholder

Interest and influence on the project

Possible impact to the project

Category / Group

Likely strategy you need to adopt

Be careful not to share the strategy document with other stakeholders because more often than not you the document would contain some sensitive information.

Common Mistakes made while Identifying

Stakeholders

Some common issues and confusion that arises in the process of identifying stakeholders that should be avoided are:

1. Making the “System-owner” the primary stakeholder rather than the

“User-owner”. The User-owner is the person with direct P&L (Financial) responsibility for the project outcomes (e.g., line managers) and they would be primary stakeholders. System-owners on the other hand bring the

needed expertise to execute the project e.g., Technical, Managerial, Sourcing. In projects “System-owners” who have long experience working with the business and existing systems take over roles of “user-owners” not always to the benefit of the project and should be flagged as a potential source of increased risk.

2. Not considering stakeholders that have an “Indirect” influence on the

project. In projects that are executed for public use, Press\Media has an indirect strong influence on other stakeholders such as shareholders when it highlights repeated delays and infighting within the project team. This in turn can affect project funding. Large projects with uncertainties need to employ suitable Media management experts to manage this risk.

3. Incorrectly assuming “agents of a Client” such as Contractors to be

fully controllable by a Client. For example a major Government weapons development project was considered to have low risk because it had stringent contracts with its Prime Contractor (who was the agent of the Client). When the prime contractor failed it was found they could pass on their liability to their sub-contractors – one of whom was owned by the Government. As a result ownership of part of the liability came back to rest with the Government.

4. Not breaking down “composite groups” to understand roles of their

individual constituents. The assumption that all constituents of a composite group have aligned interests is often not true. In an organization where multiple departments are involved in a project – each will bring a different agenda – Marketing may focus on speed and agility; Legal\Audit on Compliance and Security; Finance on costs and revenues. Any composite group consisting of people from different functions needs to be assessed in terms of their individual functions.

5. Wrongly assuming mapping of stakeholders is a one-time activity. Stakeholders, their interest, influence is a function of time and stakeholder mapping needs to be a continuous dynamic activity. In some cases primary stakeholders leave and are replaced with new stakeholders that can possibly have a different agenda and interest in the project.

1. Some of your stakeholder changed in the middle of your project. What would you do in this situation?

This scenario is quite possible. It is important that you categorized the new stakeholder into the groups you have formed and start managing their expectations including responding to their queries and ensuring your keep them informed about the status of the project. If the new stakeholder

expects you to change the direction of the project make sure that you include all other stakeholder in such discussions and decisions.

2. Why do you need a stakeholder management strategy?

It is important for you to understand the influences of a stakeholder on your project. Not all stakeholders will have positive influence on your project. Your strategy must be to minimize the negative influences and impact of your stakeholders.

Practice Questions

1. Identify stakeholders is part of which process group?

a) Initiation Process Group

b) Planning Process Group

c) Execution Process Group

d) Monitoring Process Group

2. Identify Stakeholders is part of which knowledge area?

a) Integration Management

b) Scope Management

c) Communications Management

d) Time Management

3. A key output of Identify Stakeholders is

a) Project Charter

b) Stakeholder Management Strategy

c) Stakeholder Analysis Document

d) Power-Influence grid

1 a Identify Stakeholders is part of the Initiating Process Group

2 c Communications Management

3 b Others are either tools or inputs

Planning Processes

C O L L E C T R E Q U I R E M E N T S

Collect Requirements

You must now be familiar with the process of identifying stakeholders on your project. You must also be comfortable classifying your stakeholders into well-defined groups.

Next, you must figure out your stakeholders’ needs. This process is called Collect

Requirements. This is the first step in the Planning Process and is part of the Scope

Management Knowledge Area. The primary purpose of this process is to define and document the needs of the stakeholders as they relate to meeting project objectives. This process is critical because most of the other planning processes are directly dependent on the outcome of this process. At the end of this process you must have a document that contains all your stakeholder’s requirements as well as a document that tells you how you would manage a change to these requirements.

This process involves understanding high level requirements of the project, speaking to the right people and gathering detailed requirements from them. You must gather not just the functional requirements (such as what features must the product contain) but also the non-functional requirements (such as technical performance of the product, reliability etc.).

As a project manager you can study the Project Charter to understand the high level requirements. You need to speak to stakeholders to obtain detailed requirements. The Stakeholder Register will help you identify the stakeholders you need to speak with. The Project Charter and the Stakeholder Register are, therefore, key inputs to the Collect Requirements process.

Gather requirements from stakeholders

If the number of people you need to talk to is small (i.e., 1 to 10 people) you may have a 1-on-1 interview with each of those people and document the detailed requirements. You can prepare the questions well before the interview. This allows you to be structured and gather a lot of information in a short time. Interviews work well when you have to get answers from subject matter experts and end users.

Doing a 1-on-1 interview would be very time consuming if the number of people you need to speak to is a big (i.e., between 10 and 25 people). In this situation you are better

Chapter

off getting all the stakeholders into one room and conducting either a requirements gathering facilitated workshop or a focus group session. In a Focus Group, as a facilitator, you may ask questions that relate to the project requirements. Stakeholders, that are primarily subject matter experts, can interact with each other, debate on key issues relating the project requirements and provide feedback.

When you have to collect requirements from stakeholders that belong to different departments you may want to conduct a Facilitated Workshop. This is a forum which provides cross-functional stakeholders to discuss and define requirements for the project.

If the number of people you need to speak with is very big (i.e., more than 25 people) then you can design questionnaires, send it to the respondents and solicit their inputs. Don’t expect all of those you sent the questionnaires to, to respond. Another way to gather information would be to conduct surveys.

On some projects you may be in a situation where key stakeholders are just not capable of specifying requirements clearly. In such situations, you will have to help by developing prototypes with whatever initial information you have. Stakeholders will be able to provide better feedback and more clear requirements after reviewing the prototypes. You can also gather information by observing the end-users perform their work and documenting those activities.

Make quick decisions

There is always a high probability of conflict when several stakeholders are involved in providing requirements. As a project manager you need to ensure quick resolution to such conflicts. There are many ways to make decisions in a group setting. Some of these are:

Unanimity: All members of the group may agree to a decision. This is called Unanimity.

Majority: As a Project Manager you can decide to choose an option that has the support of more than half the number (more than 50%) of participants.

Plurality: If there is no clear majority, you may decide on an option that has the support of the largest number of participants

Dictatorship: One person (preferably you) makes a decision on behalf of the entire group.

Use creative techniques

Creative techniques can be used to collect and document requirements. Some of the creative techniques you can use are:

Brainstorming: Get together a group of people, put a theme (e.g., “What should the logo for the team look like?”) on the table and get them to generate ideas.

Delphi: This technique utilizes expert opinion. Responses to questions on requirements are sought from experts. Experts provide feedback on the requirements anonymously.

Mind-mapping: Mind-map is a diagramming technique used to generate and record ideas.

Nominal Group: This is a sort of brainstorming exercise where ideas are generated. Further it is put to vote and ranked. Ideas that have low ranks are eliminated.

Affinity Diagram: This technique sorts ideas into groups that are analyzed further

Outputs of Collect Requirements

Outputs of collect requirements process include Requirements Document, the Requirements Management Plan and the Requirements Traceability Matrix. These are discussed in detail.

Requirements Document

As discussed earlier in this chapter, all the requirements must be documented. Documenting the detailed requirements is very important because this way you will know what to build or deliver. This can also help you measure & track your team’s progress. The requirements document must be reviewed and signed-off by the key stakeholders. This document, therefore, becomes the basis for planning the project. FIGURE 15 shows the tables of contents of a typical requirements document for a software development project.

FIGURE 15: A typical requirements document

There is a strong possibility that some of the requirements would be conflicting with each other. As a Project Manager it is important that you manage and balance these conflicting requirements. In most cases you will have to also prioritize requirements. The Business Case and the Project Charter are two key documents that you can fall-back on to make quick decisions on conflicting and competing requirements.

Requirements Management Plan

Requirements management plan is a document that specifies how changes to requirements will be managed throughout the project. This document also states how requirements would be analyzed, prioritized and tracked. Some of the benefits of requirements management plan are:

It serves as a document that documents a common understanding of requirements related activities

It communicates what requirements related activities will be completed, when and by whom.

The requirements management plan is a subsidiary of the Project Management Plan – we would be discussing the Project Management Plan in more detail in Chapter XXX.

Requirements Traceability Matrix

A traceability matrix is a document that tracks the attributes of a requirement throughout the project. It specifies how a requirement has been implemented in the project’s product. This is useful tool to help you verify that all agreed requirements have been implemented and that no additional features are provided. A template for a requirements traceability matrix is shown in FIGURE 16.

FIGURE 16: Requirements Traceability Matrix

1. What is Job Shadowing?

Observation is also referred to as Job Shadowing. This is a technique to gather requirements when stakeholders can’t articulate the requirements clearly.

2. What are Joint Application Development sessions?

Joint Application Development is a facilitated workshop. It is quite common in rapid software application development projects where a customer/user representative participates full-time in requirements collection exercise with the project team.

3. What is the difference between Product Requirement and Project Requirement?

Project requirements include business requirements, delivery requirements etc. while product requirements include performance requirements, security requirements etc.

Practice Questions

1. Document that specifies how requirements will be analyzed, prioritized and managed is:

a) Requirements Traceability Matrix

b) Requirements Document

c) Requirements Management Plan

d) Project Charter

2. Which document helps the project team track a requirement from specification through implementation?

d) Project Charter

3. All of the following are group decisions making techniques EXCEPT

a) Unanimity

b) Majority

c) Creativity

d) Dictatorship

4. All of the following are outputs of Collect Requirements process EXCEPT

d) Work breakdown structure

5. When stakeholders are unable to articulate their requirements you would use this technique to collect requirements:

a) Interview

b) Job Shadowing

c) Brainstorm

d) Delphi

1 c Primary contents of a Requirements management plan

2 a Function of a Requirements Traceability Matrix

3 c Creativity is not a decision making technique

4 d WBS is not an output of Collect Requirements process

5 b Observation is also called Job Shadowing

D E F I N E S C O P E

Define Scope

You have now completed gathering and documenting the project requirements. You now need to get a clear picture of all the work that needs to be done by the project as well as work that will not be done by the project. You will do this as part of Define Scope process. This process follows the Collect Requirements process and is also part of the Scope Management Knowledge Area. The Requirements Document you created in the previous process can be considered to be a wish list of ALL the features that stakeholders would want in the final product. You need to review the requirements you have just gathered along with the Project Charter and identify and prioritize only those that are specified in the charter.

In some cases you would find it difficult to understand if a particular requirement is specified in the charter or not. In such instances you will need to build upon and develop detailed description of the requirements/deliverables. You would also need to analyze the project constraints and assumptions.

Once you are done reviewing the requirements, you need to separate out those requirements that will be done (inclusions) and those that will not be done (exclusions). The inclusions and exclusions are documented in the Scope Statement

In addition to the Project Charter and Requirements Document that are key inputs to the Define Scope process as seen above, you will also need to refer to your Organization’s Process Assets such as standard templates for preparing scope statement, scope statements of previous projects and any other documents that would help you in completing the scope statement for your project.

Developing Detailed Description of Requirements

The tools required to develop scope definition include:

Facilitated Workshops: This is a moderated forum provided to cross-functional stakeholders to discuss and define requirements for the project.

Product Analysis: Product Analysis involves designing methods for translating project objectives into tangible deliverables and requirements.

Chapter

Alternatives Identification: Stakeholders may have different approaches to solving a given problem. Alternatives Identification is a used to identify different methods of accomplishing project work, or part of a project. Techniques such as brainstorming and lateral thinking (or thinking outside the box) can be used to identify alternative solutions.

Expert Judgment: Expert judgment means using someone – an individual or an organization - who has been through this earlier. This person (or organization) could be internal to the performing organization or could be external like a consultant or a professional body. Experts can help you analyze the scope of the project and their participation in the review of scope statement will help you eliminate grey areas.

Contents of a Scope Statement

A Scope Statement documents the project objectives, the project deliverables and the work required to achieve the objectives. It is important that all the objectives of the project be quantified and when deliverables would be considered complete, as much as listing what work will not be done as part of the project. A well-written, clear scope statement is an effective tool in managing project scope creep and be used effectively in managing changes as well as disputes related to the scope of the project. You may have to update project documents such as the Requirements Document and the Requirements Traceability Matrix.

FIGURE 17: Contents of a typical scope statement

1. What is the difference between Product Scope and Project Scope?

Product scope means the features of the product or service that your team would be building while project scope means figuring out what all the work that needs to be performed to build the product or service.

2. What does the term scope creep mean?

Scope creep means uncontrolled changes that require the team to work extra. You can avoid scope creep by completing planning approved changes

3. What is the difference between Requirements Document and a Scope Statement?

Requirements document contains functional as well as non-functional requirements.

Scope Statement states all the work that will be done as part of the project. It states what would be done and what would not be done.

Practice Questions

1. One of the inputs to define scope process is

a) Requirements Document

b) Requirements Traceability Matrix

c) Scope Statement

d) Facilitated Workshop

2. Project Scope is

a) The same as product scope

b) The work that needs to be done to complete the product or service

c) Features that characterize the product or service

d) Subset of the product scope

3. A project scope statement contains

a) Alternative approaches to creating the product or service

b) Detailed description of the project’s deliverables & work to be performed

c) Work packages complete with the code of accounts

d) Estimates for each component in the WBS

4. General management techniques that can be used for identifying alternatives include all of the following EXCEPT:

a) Brainstorming

b) Lateral Thinking

c) Pair-wise comparisons

d) Organization process assets

5. A project scope statement has been created jointly by all stakeholders. However project requirements have been changing after the start of execution. What is the cause of the problem? BEST answer is that the

a) Customer did not approve the scope statement

b) Customer requirements were not properly gathered

c) Project Scope statement was created before the requirements

d) Project Manager should have been more assertive when framing scope statement

1 a Other options are not inputs

2 b Project Scope is the work to be accomplished, and is different from Product Scope

3 b See contents of a scope statement

4 d Organization process assets are not general management techniques

5 b Requirements were not collected completely resulting in changing requirements Customer does not have to approve the scope statement. Option C and D are not something that can be concluded based on the given information

C R E A T E W B S

Create WBS

The Scope Statement developed in the previous process states what deliverables the project will need to produce. You now need to define all the work you and your team would need to perform in order to produce the deliverables. The Create WBS process helps you define all the work that the project will need to perform by hierarchically breaking down the project deliverables into smaller, manageable components with each descending level of WBS representing an increasingly detailed definition of work specified in the scope statement3. The idea is if any work is not part of the WBS then it is not part of your project work.

FIGURE 18 shows the WBS for Project Persist. You must note that some of the nodes (eg. 3.0 Sub-project X and 4.0 Phase 2) of the WBS are yet to be broken down into more detailed components. They would need to be analyzed and broken down further to get a complete picture of the project. Also, the connection between the nodes does not mean the WBS shows dependencies and constraints. We will learn more about dependencies in the later lessons.

FIGURE 18: Partial WBS for Project Persist

3 PMBOK® 4th Edition, Pg. 116

Chapter

C R E A T E W B S

Defining Work Packages

The lowest level of WBS components is called work packages. Work packages are units of work that you and your team can use to organize your project. In other words, work packages are components at a level of detail that the project team can associate time and cost estimates independently. The higher levels of the WBS are used to organize the work packages. Once the WBS for your project is complete you would be able to visualize the work that would need to be performed by you and your team. The WBS can also be used as an effective aid for communications amongst all stakeholders.

The inputs to the Create WBS process are the Scope Statement and the Requirements Document.

In addition, you would also need to refer to your Organization’s Process Assets such as standard templates for WBS, sample WBS created by previous projects, lessons learnt etc.

Decomposing a Deliverable

The tool to create the WBS is called Decomposition. Decomposition involves4

1. Identifying and analyzing the deliverables and related work

2. Structuring & organizing the WBS

3. Breaking down the upper WBS levels into lower level detailed components

4. Developing and assigning identification codes to the WBS components, and

5. Verifying that the degree of decomposition of work is sufficient

Size of a work package

How small or big can a work package be? There is no definitive answer to this question. A general thumb rule is that a task should not be more than 5 days duration (or 40 work hours) and not smaller than 8 hours. (Remember, in this process we are only talking about work packages and not tasks – tasks and activities will be defined in the next chapter).

How many levels can a work break down structure have? Again, there is no specific and definitive answer to this question. The WBS of a simple project could

4 PMBOK® 4th Edition, Pg. 118

C R E A T E W B S

have between 3 to 5 levels while that for a complex, large project would need between 15 and 20 levels of decomposition to help you get the detail.

Outputs of Creating WBS

The WBS, shown in FIGURE 18, is the primary output of the Create WBS process. However, the WBS alone will not meet your needs because it only show the names of the nodes and work packages. You and your team will need much more information about what each of the work packages mean. This is where the WBS Dictionary comes into play. The WBS Dictionary (see FIGURE 19) contains all the information you and you team need to perform work on each of the work packages.

FIGURE 19: Contents of WBS dictionary

1. What is the 100% rule?

The work breakdown structure represents all the work to be performed on the project including project management work. The total of the work at

C R E A T E W B S

the lowest levels must roll-up to the higher levels so that nothing is left out and no extra work is performed. This is called the 100% rule5.

2. What is Decomposition?

Decomposition is a tool/technique used to create the WBS. It involves hierarchically breaking down a project’s product into lower level components up to the level of work packages.

3. What is a work package?

Work package is the lowest level of components in a WBS. This is the level at which a project team can associate realistic cost and effort estimates.

4. What is a Scope Baseline, and what does it consist of?

Generally speaking, baselines are snapshots that you can measure your project’s performance against. Scope baseline is a snapshot of approved work that needs to be performed by a team. The scope statement, the work breakdown structure and the work breakdown structure dictionary put together is referred to as scope baseline.

5. Why should we assign identification codes to components in the WBS?

Assigning identification codes help stakeholders identify not just the level at which a given component of project work is at but also its category.

Practice Questions

1. Decomposition is:

a) An input to the define scope process

b) A tool to create the work breakdown structure

c) Part of the scope baseline

d) The lowest level of component in the WBS

2. You have been asked to sell the concept of WBS in your organization. What amongst the following is the BEST selling points:

5 PMBOK® Guide, PMI, USA, 4th Edition. Pg 121

C R E A T E W B S

a) WBS will help PMs and stakeholders identify what is required and what is not

b) WBS is a great graphical tool that can be used to collect requirements

c) WBS represents what cannot be illustrated in a project charter

d) WBS can be used to help induct staff into your project

3. Scope baseline consist of all of the following EXCEPT:

a) Requirements Document

b) Scope Statement

c) WBS Dictionary

d) Work breakdown structure

4. You have been appointed the project manager of a project that is in its execution phase. You realize that the project does not have a WBS. What is the BEST thing for you to do?

a) Call for a team meeting to discuss the crisis and then document the actions

b) Let your senior manager know and continue with the project

c) Stop the project, document the WBS first and then re-start the project

d) Do nothing different, let the project continue as it was

C R E A T E W B S

1 b PMBOK Guide, 4th Edition, Pg. 118

2 a Generally, the idea is if it is not in the WBS it must not be done.

3 a PMBOK Guide, 4th Edition, Pg. 122

4 c If you have not defined and baseline the scope and started execution then this is a recipe for disaster. Best is to stop the project, get the WBS done and then re-start the project.

D E F I N E A C T I V I T I E S

Define Activities

You must now know the importance of a WBS and must be familiar with creating WBS. While creating WBS we broke the project deliverables down into work packages. The next step is to break these work packages further into activities. You can break a work package into smaller components by identifying specific actions required to be carried out to complete the work package. These actions, listed with an identifier and description, are called activities.

The Scope Baseline is a key input to identifying and defining activities. The project deliverables, the constraints and assumptions will need to be reviewed while defining activities. Other inputs are:

Enterprise Environment Factors - an example would be the Project Management Information System (PMIS) which is a computer-based application that helps you define, store, manage and report the activities

Organization Process Assets – You might want to refer to an activity list of a historical project just to get some ideas on definition of activities.

Creating an Activity List

An activity list can be developed using different techniques or tools. Following are a few of them.

In order to define activities you need to analyze and break down the work packages into smaller components. You also need to refer to the scope statement, constraints and assumptions and analyze any actions required to meet them. Team members that would be partaking in the delivery of the work package can also be consulted to determine actions required to complete the work package. Team member’s contribution will improve accuracy of the definition of activities. The technique of identifying activities by breaking down a work package is called as Decomposition.

It is generally understood that if each activity in the work package can be estimated independently then the work package decomposition is complete. The sum of effort of all activities determines the effort required to create the work package.

Chapter

S C O P E

B A S E L I N E

Scope Statement

WBS Dictionary

In situations where the team members are not very experienced decomposition of the work packages can be carried out in consultation with experts or people in other project teams. This technique of utilizing experienced, skilled resources to define activities is called Expert Judgment.

Reviewing the activity list – a complete list or a list of a section- of historical projects is also quite useful. This would help you identify activities for your project quickly. Organizations that have a mature process may have standard templates for defining activities. Templates are tools that help improve productivity while executing repetitive work. For example, templates can be used to define activities for construction of multi-storied buildings where multiple floors are similar to each other.

Not all project requirements are clearly defined on day 1. In most projects requirements evolve gradually. As such you may have complete and clear information only on some of the deliverables, not all. Work packages for which you have the required information are decomposed into activities. The work packages that you do not currently have complete & clear information are represented by milestones. They are decomposed at a later point in the project when you have more information. This form of activity planning is termed as progressive elaboration or iterative planning or agile planning or rolling wave planning (shown in FIGURE 20). This type of planning is most suited to risky IT projects or R&D type of projects.

FIGURE 20: Rolling Wave Planning

Define Activity - Outputs

The activity list obtained by decomposing the work packages is the key output of the define activity process. It is the basis for all the cost and effort estimates. An activity list

includes an identifier and a description that reflect the scope of work to be performed as part of that activity.

An activity list alone cannot provide complete information. Activity attributes is the metadata of an activity. It provide information about the activity such as the person responsible for completing the activity, the predecessor and successors of the activity, constraints such as start or finish date etc.

As you start executing your project and performing activities you would need to continuously check if your project is on track. Milestones are planned review points – they have no effort and are used to indicate the start or completion of significant activities. A general thumb rule is to plan one or two milestones every week. Milestone can also be used to indicate work that is still not very clear. As discussed earlier, there is a high degree of probability that information about project requirements would evolve at a later date. However, the unavailability of clear requirements must not distract you. You must schedule deliverables that you do not have much clarity on currently as milestones. These can be expanded into activities later when you have sufficient information to progress with their decomposition. The milestone list is therefore an important output of the define activities progress.

1. How do we know that decomposition of a work package into activity is complete?

It is generally understood that if each activity in the work package can be estimated independently then the work package decomposition is complete.

2. How do you improve the accuracy of the activities defined?

You can improve the accuracy of the definition of activities by:

Reviewing activity lists of historical projects, and including those that you may have missed out.

Consulting with experts or persons that have executed similar work earlier

Consulting with project team members that are responsible for executing those activities

3. How do you improve the productivity of activity definition?

Reviewing and using templates meant for activity definition

Reviewing the organization’s knowledge base regarding activities used by previous projects

Practice Questions

1. Some of the work packages in a big project involving construction of national highways can be for now reduced to a milestone level and later decomposed into activities. This technique is best known as

a) Rolling Wave Planning

b) Decomposition

c) Define Activities

d) Develop Schedule

2. Milestones are:

a) Activities with large duration

b) Activities with small duration

c) Activities with no duration

d) Two activities added together

3. Milestone charts are used

a) To discuss progress of project with team members

b) To discuss progress of project with senior management

c) To analyze project risks

d) To perform detailed planning

1 a Decomposition means breaking down deliverables into components while rolling wave is planning when more information becomes available

2 c Milestone has no effort or duration

3 b Milestone charts do not have much details – so best used for discussing status with senior managers

S E Q U E N C E A C T I V I T I E S

Sequence Activities

Once you have an activity list, an attribute list and a milestone list you can start sequencing the activities. Sequencing means arranging the activities in an order based on relationships and dependencies between each other. For example, the activity Prepare the System Test Plan will be followed by a Review of the System Test Plan. The review cannot precede the preparation of the system test plan. It is important that you arrange all the activities in the required sequence. All activities and milestones except the first and last must be connected. Activities that do not have a successor or a predecessor are called hammocks and are not recommended. Hammocks are only used in representing higher level summary without showing the detailed relationships. Note that a single activity can be linked to multiple activities (i.e. two or more successors or predecessors) or milestones (dependencies)

To perform sequencing of the activities you can use any of the commercially available project management software applications such as MS Project or Primavera.

The Activity List, Activity Attributes and Milestone List are inputs to the sequencing process. The Scope Statement, that includes product description, may contain details that may dictate sequencing of activities to some extent and is, therefore, also an input to the sequencing process. Organization Process Assets such as project scheduling templates, procedure for preparing scheduled etc. will also be helpful in the sequencing process.

Tools & Techniques to Sequence Activities

Sequencing the activities can be done in 3 stages. The 1st stage is to examine and determine the precedence between activities. Precedence Diagramming Method (PDM) is one of the techniques to determine the precedence. It involves creating a diagram which shows activities in rectangles and relationships as arrows. . This method is also known as Activity on Node (AON) and is an extension of scheduling methodology for projects known as Critical Path Methodology (CPM). A sample diagram drawn using PDM is shown in FIGURE 21.

Chapter

FIGURE 21: Precedence Network Diagram

PDM includes 4 types of precedence relationships between activities:

Finish-Start: The start of the successor activities depends on the completion of the predecessor activity. For example, you can decorate a cake only after the cake has been baked. This type of dependency is shown in FIGURE 22.

FIGURE 22: Finish-Start precedence

Start-Start: Start of the successor activity depends on the start of the predecessor activity. For example, icing required for decoration of the cake can be start simultaneously as baking the cake. This type of dependency is shown in FIGURE 23.

FIGURE 23: Start-Start precedence

Finish-Finish: The completion of the successor activities depends on the completion of the predecessor activity. For example, while delivering cakes to customers over-the-counter you can consider delivery of a cake to be complete the moment you have completed decorating it to the specification of the customer as shown in FIGURE 24.

FIGURE 24: Finish-Finish precedence

Start-Finish: The completion of the successor activities depends on the start of the predecessor activity. This is not a very common dependency. For example, you can consider delivery of a cake to be complete the moment you have issued the bill to the customer. This type of dependency is shown in FIGURE 25.

FIGURE 25: Start-Finish precedence

The 2nd stage of sequencing involves determining dependencies. 3 types of dependencies commonly used in sequencing activities are described below.

Mandatory Dependency: These are referred to as hard-logic and are inherent in the nature of work. These can be determined by:

Looking at the basic nature, standard processes of the product or service or result to be delivered at the end of the project.

Asking the people who will work on each of the activities or experts in the industry, as to what they need to complete their work on time.

Looking at the proposals, contracts and requirements documents agreed with the customers who require your product, service or result.

Discretionary Dependency: These are referred to as soft-logic. These can be determined by:

Looking at the best practices followed in your organization for development of the product or service or result to be delivered at the end of your project. The order of these best practices could be changed during the project based on the unique needs of the project. For example, the reports are generally tested after the online display of a module, but this is just a best practice and not a standard rule.

Asking the people who will work on each of the activities or internal experts in your organization, as to what is the best way to complete the project with a balance of speed, quality, cost efficiency.

External Dependencies: These are relationships between project activities and activities outside your project. External type of dependencies are found out by

Looking at the links between activities identified so far on the project and activities outside the project. For example, to perform system testing on a banking application we are dependent on the delivery of specialized pass book printing hardware which is to be supplied by the customer prior to start of system testing.

Looking at external demand factors or external time factors for availability of material or common external infrastructure, suppliers or human resources.

The 3rd stage of sequencing involves performing some fine-tuning on the relationships between activities determined so far. The most common way is to start the successor activity after the predecessor activity is completed. This is also known as the Finish-Start (FS) relationship. However, you can adjust the relationships of the successor activities to start a few days earlier (accelerate) or few days later (delay) to the completion of the first activity. Accelerating the start of a successor activity is called

lead and delaying the start of the successor activity by a few days later is known as lag. Please note that applying leads and lags must not replace the schedule logic.

Applying of leads technique helps in development of realistic project schedule. In some cases you can apply leads to compress the schedule by overlapping sequence of activities

In order to expedite the development of a schedule network for your project you may use a schedule network diagram templates. Parts of schedule network diagrams are referred to as sub-network or fragment network.

Sequence Activities - Outputs

The output of this process is the Project Schedule Network Diagram. The schedule network diagram is a graphical display of all project activities with the logical relationships.

In this process you may also have to update activity list and activity list attributes because you may discover new activities as you work through the project relationships. You may also have to create new activities to mitigate or avoid risks that you and your team would have identified while determining the sequence of activities.

1. How do we know that the sequencing of the activities is complete?

Ideally, it is recommended that every activity and milestone should be connected to two other activities (Successor and Predecessor) except for the start and end activities. This provides a good indication of the completion of the process of sequencing activities.

2. How do you improve the productivity of the process of activity sequencing?

You can improve the productivity by using standardized scheduled network templates.

3. What are hammocks?

Hammocks are activities that do not have any relationships defined in the schedule network. Hammocks are not recommended.

Practice Questions

E S T I M A T E A C T I V I T Y R E S O U R C E S

Estimate Activity Resources

You have now completed sequencing the activities for your project. Next, you need to estimate the type and quantity of people, material, equipment required for each of the activities. This activity is close coordinated with the estimate costs processes explained later in this book.

The Activity List and Activity Attributes are key inputs to this process. Yet another key input is Resource Calendar. Resource Calendars provide information on potential availability of physical raw material, equipment and human resources including their grade, capacity and skill. This serves as a reference for the timing of booking of critical resources in the project. For human resources this may reflect the planned leave and trainings during the course of the project. For equipment this may reflect the maintenance shutdown timings. For raw materials this may reflect the seasonal timings when material is easily available. The Resource Calendar may or may not be fully complete during planning and is continuously updated during the executing process group. It is commonly updated as soon as the process of acquiring the team and conducting the procurement is complete. Other inputs to this process are:

Enterprise Environmental Factors – An example of these factors would be the easy access to skilled resources near cities that have lot of educational institutions. Another example is the availability of commercial estimating and risk databases in certain industries.

Organization Process Assets –These would include access to your organizations knowledge repository for procedures and policies related to renting, procuring materials and human resources. It may also involve access to past projects that used a particular skill of resources, type of equipment.

Developing Activity Resource Requirements

As stated earlier the primary intention of this process is to document the type and quantities of resources required for each of the activities we defined in the earlier processes. You can use any of the several tools or techniques to make this happen. A common technique is to obtain Expert Judgment. This is a technique where you consult experts in a domain, technology, industry for their inputs to estimate resources.

Chapter

You may also analyzing alternatives in order to find the optimal resourcing for the activities. Alternatives Analysis is a technique for evaluating different options for resource usage which include using experienced or inexperienced people, using manual or automated tools, deciding to in-source or out-source.

You can review Published Estimating Data. Commercially available data or data internal to your organization can help you handle new equipment or manage a new resource skill at a new location. It is better to use or factor in the locally published data when available, rather than use the global available data.

In case of complex activities you may use Bottom-up Estimating technique that helps in decomposing an activity. The purpose of decomposing further is to estimate the resources at a more detailed level. The decomposition is done till the resource estimates can be done with a degree of confidence.

The basis of estimates is documented along with the activity resource requirements so that any assumptions made during this process of preparing estimates are captured.

Developing a Resource Breakdown Structure

You may also prepare a resource breakdown structure (RBS). The RBS is a hierarchical view of the names, quantity of resources deployed in the project by category (labor, material, equipment) and type (skill, grade, capacity). The RBS can be consolidated at an organization level and is useful for optimizing and allocating resources to different projects. Commercially available project management software is useful in managing the resource utilization through the defining, managing and generating views of the RBS.

Activity Resource Requirements and the Resource Breakdown Structure you produced using project management software are the key outputs of this process. You will need to update the resource calendars based on refinements made during estimation and additional new bookings of critical resources. You would learn more about resource calendars n the Develop Human Resources Plan section of this guide.

1. When will you deploy a higher percentage of experienced resources, typically?

The experienced resources are deployed at the beginning and the end of the project during the high level design and test support.

2. What documents are you likely to update during this process?

Resources calendars would possibly be updated. As part of bottom-up estimating you may decompose complex activities further. If you do you will have to update the activity list and activity attributes.

3. Resources Calendar was never produced during planning processes but this is used as an input to this process?

Resource Calendar is generated during the Acquire Project Team & Conduct Procurement processes. These are part of executing process group. At this stage of planning you will have some basic information about availability of resources. You will have to use that information. You will have to continuously update the resource calendar as more information becomes available.

Practice Questions

E S T I M A T E A C T I V I T Y D U R A T I O N

Estimate Activity Duration

At this stage of your project you now have with you the following:

An Activity List

Activity Attributes, and

Activity Resource Requirements

You now need to estimate the duration or work periods required for each activity. For each of the activities you have identified, given the resources, you will have to estimate the duration required to complete each of the activities. You will need to use available information on project/activity scope (from the Scope Statement), required type of resources and the quantity (available from Activity Resources Requirements) and resource availability (from Resource Calendars). Other inputs are:

Enterprise Environmental Factors- For example, the presence of skilled resources in the organization or with accessible vendors, and the productivity of latest computing equipment may significantly impact the duration of the activity.

Organization Process Assets – You may need to refer the corporate knowledge repository for a policy, procedure documents related to calculating duration based on average productivity. It may also involve access to past projects for lessons learnt and buffers to apply.

Remember that Activity Duration Estimates are contributing to the duration of each activity in the Project Schedule and Schedule Baseline that will be prepared at the end of planning activities related to Time or Schedule. Remember also that the Activity Duration Estimates are progressively elaborated using better input data of work effort and number of resources available.

Chapter

Developing Activity Duration Estimates

Activity duration estimates can be developed using different techniques or tools in different means:

Getting Expert Opinion – The Expert Judgment is a technique by which a project manager consults the experts in a domain, technology, and industry for their inputs to estimate duration. Also judgments can be made on which technique to use for which activities.

Reviewing historical information – The Analogous Estimating technique is used for estimating the duration of current activities based on past project activities due to similarities in functionality or feature or complexity. For example, we review the effort expended on similar activities on historical projects. Also, it is to be noted that we are exercising expert judgment when deciding that an activity is similar to a past activity. This type of estimating technique is quick but not accurate.

Considering parametric information – The Parametric Estimating technique is used for estimating the duration of current activities based on a historical statistical relationship between duration in working days (or hours) and a unique productivity parameter or variable. For example, based on past experience if 2 user interface screens with an average 50 screen fields can be captured into user manuals in 1 working day(8 hours) by 1 person, then 100 such user interface screens can be done in 5 working days(40 hours) by 10 person working as a user manual team. This type of estimating

is more accurate and is based on the data captured in the parametric estimating

model.

Considering best case, most likely, worst case scenarios – The Three-point

Estimating technique helps to improve the accuracy of estimates. This is done by finding out the three estimates (optimistic, most likely, pessimistic) for the same activity and then taking the weighted average of the three points. The most likely point is given a weight of 4, compared to 1 for optimistic and 1 for pessimistic. This type of estimating is also known as the PERT estimate. This is given by the PERT activity estimate formula

.4 cPessimistiMostLikelyOptimisticEstimate

If a simple average is used then the three point estimate is given by the formula

cPessimistiMostLikelyOptimisticEstimate

The PERT activity estimates are summed up at the project level to give the Project PERT estimate.

The range of possible variation in activity estimates are calculated and documented along with the activity duration estimates. The standard deviation σ can be calculated using the simplified formula

OptimisticcPessimisti

These are then used to calculate the activity variance

The activity variances for all the activities are summed up and then the square root of the total sum is taken to give the project standard deviation.

Based on statistical probability relationship for a close to normal bell shaped curve variations or Beta Distribution curve around the mean (project PERT estimate), we can provide a probability of,

99.73% confidence in the estimate with a range of ±3σ

FIGURE 26: Range of Activity Duration Estimates

Considering project schedule uncertainty – The reserve analysis technique helps to calculate time buffers or time contingency reserves and then added to the project duration estimate. The EMV (Expected Monetary Value) analysis is a quantitative technique for calculating the cost contingency reserve by multiplying the probability of a risks and their cost impact for a given scenario. Here a variation of the same analysis

can be used replacing the cost impact with the time duration impact for a given activity. The value for the duration impact is taken based on type of risk as positive (opportunity) or negative (threat). The net value of all such values is used as the duration contingency reserve. A simple way to calculate the activity duration contingency reserve for those activities that have uncertainty is to calculate it as a fixed percentage of the activity duration estimates.

Activity Duration Estimates Outputs

Outputs of this process are:

Activity Duration Estimates – These could be ranges of activity durations (between 63 and 78 days as shown in FIGURE 26 or a value based on confidence levels (such as 15% chance that the duration will not exceed 2 weeks).

Project Document Updates – Includes updating assumptions you may have made regarding some of the activities, or updating any other document that is impacted by the duration estimates

Practice Questions

1. Activity Duration estimates include one of the following

A. Lag

B. Resources assigned

C. External Dependencies

D. Range or Confidence level

D E V E L O P S C H E D U L E

Develop Schedule

In the previous sections you learnt how to identify and define activities, sequence them, estimate activity resources requirements and durations. Next, you need to analyze these inputs to develop a project schedule. In a project schedule network diagram an activity is used as the basic building block of the project schedule. The resources and duration are then assigned to each activity. If a start date is given to the first activity in the project schedule network diagram, then it is possible to generate a schedule using a scheduling tool, which will assign a start and an end date to each activity, and an event date for each of the milestones. This will also help you determine a project end date.

Inputs to this process are Activity List, Activity Attributes, Project Schedule

Network Diagram, Resource Calendar, Activity Resource Requirements; and Activity Duration Estimates. We have discussed these in the previous chapters.

Other inputs you would need to develop a schedule are:

Project Scope Statement – To Refer to Assumptions and Constraints – Assumptions on the capability of resources, approvals of external authorities are again validated during the simulations and changes in project schedule.

Enterprise Environment Factors - an example would be the availability and use of scheduling tool. This software application will help you to define activities, resources, activity relationships between activities and display the final project schedule for sponsor approval.

Organization Process Assets – A key guideline document in the repository will advise on the recommended scheduling methodology to be used under different circumstances. Another key document would be the project files in which project calendars are defined. The project calendar will define the working hours in a working day, the holidays applicable during the project.

Develop Schedule – Tools & Techniques

The schedule could be prepared using different techniques or tools in different stages,

Chapter

Automation stage – You can use the Scheduling tool to set the start date of the first activity or starting milestone in the project. The duration of all activities and the resources that will perform the activity are entered. Then all other activities are linked to each other using the project schedule network diagram. Remember not to use any hammock activity (free hanging activity). Now the Automatic Schedule option in the tool can be triggered to determine the end date of the project.

Balancing stage – You can apply different scheduling network analysis techniques to different parts of the default project schedule generated by the Scheduling tool. You can then analyze or integrate, or balance both the resource utilization and to develop the schedule. This analysis is based on the applicability of following scheduling network analysis techniques - Critical path method, Critical chain method, Resource leveling, What-if-scenario analysis and Schedule Compression

Critical path method (CPM) is a technique with a focus on float availability so that activities can be assigned schedule start dates with flexibility. The aim is to have only one critical path with zero float (or flexibility) at any point of time and manage its speedy completion. This will ensure that majority of the activities in other network paths in the network diagram will have some float (or slack). This will enable those activities to be delayed purposefully or to be allowed to start later than planned, without delaying the project end date. This method is useful in drawing attention of the Project Manager to what is critical in achieving the timely project completion.

Critical chain method (CCM) is a technique with focus on buffer placements following the identification of a bottleneck activity with critical resources. The activities on the path of the network which includes the resource constrained bottleneck activity form the critical chain. This bottleneck activity is the weak link that has to be strengthened. Normally this critical chain lies on the critical path that is identified using the CPM method. The duration of the time buffers added before (feeding buffers) and after (end buffers) the bottleneck activity are monitored. This is done to prevent over-loading or under-loading of the critical resource assigned to the bottleneck activity while at the same time completing the project on schedule. This method is useful in achieving maximum throughput with maximum utilization of critical resources (hence minimum cost) along with achieving project schedule. This technique is based on the Theory of Constraints proposed by Dr. Eliyahu M Goldratt who has contributed significantly in the last 25 years towards its development and application.

Another analogy from the healthcare industry where heart surgeries performed in a given day is looked at as a project with a deliverables of maximum successful surgeries and minimum time spent by patient at hospital. The resource constrained bottleneck activity becomes the operation theatre in a critical chain. The physical feeding buffers similar to the time buffers are the critical care units and the physical end buffers are the critical care units or intensive care units. This will ensure that the operation theatre is used efficiently to increase the throughput of surgeries. The

hospital also saves cost by using the high cost surgeons for more surgeries compared to another hospital which uses high cost surgeons for fewer surgeries.

Resource leveling is a technique with a focus on balanced loading of the resources assigned to a project. The resource loading is viewed using the resource histogram view after allocating the resources to the project activities in Scheduling tool. The resources that are overloaded can be seen as peaks above or valleys below the average level of loading of say 8 hours. Thus the resource allocation can be modified to spread out or flatten the resource loading. This may result in an increase in the project duration.

What-if-scenario-analysis is a technique with a focus on simulating and finding out the probability distribution of the most likely project schedule end date. This is also known as the Monte-Carlo analysis

Schedule compression can be achieved in two ways:

Crashing – Here we balance the feasibility of a decrease in project duration with an increase in cost. In reality, this is achieved by allocating more resources in shifts, in overtime to achieve a tight deadline. However it carries the risk of introducing burnout, low productivity and hence increased cost in the project. Some standard or routine activities in a project like construction of a road, installation of standard software on computers are suitable to put a lot of people, where as other activities like design are not suitable. In general, the law of diminishing return applies when adding more people to IT projects due to overheads of training, communication.

Fast tracking – Here we balance the feasibility of a decrease in project duration with an increase in risk of re-work. In reality, this is achieved by performing as many activities as possible, in parallel with a lead. This leads to overlapping of activities and hence increases the risk of re-work due to changes in preceding activities.

Fine tuning stage – The fine-tuned and realistic view of the project schedule can be obtained by applying the following techniques:

applying leads and lags to reflect opportunity or threat scenarios in real life projects,

the reality of being able to start an activity ahead of time(lead) or

the reality of having to wait for an input before starting an activity(lag)

Determining Critical Path

Determining the critical path involves determining the Early Start and Early Finish (as well as the Late Start and Late Finish) for each of the activities in the network. A

Forward Pass (FIGURE 27) helps you determine these early start and early finish times as you work your way from the start towards the finish points. The early start for a task that depends on completion of two tasks (i.e., that has two or more predecessor tasks) is the maximum of the early finish of the predecessor tasks.

FIGURE 27: Forward Pass - Calculate Early Start and Early Finish times

A Backward Pass (FIGURE 28) helps you determine these late start and late finish times as you work your way back from the finish towards the start point. The late start for a task that depends on completion of two tasks (i.e., that has two or more successor tasks) is the minimum of the late finish of the predecessor tasks.

FIGURE 28: Backward Pass - Calculate the Late Start and Late Finish

The critical path – which is the longest time required to complete all tasks - for this network diagram is 18 weeks. The slack (or float) is the difference between the Early Start and Late Start (or Early Finish and Late Finish). For example, the slack for task T3 is the above example is 8 – 3 (or 14-9) = 5 weeks.

Develop Schedule - Outputs

The outputs of this process are the Project Schedule and Schedule Baseline

The Project Schedule includes the activities, milestones with a specific start or completion dates. It is represented in multiple formats as below

It is a graphically represented view of the sequence of activities in a project shown on the y-axis against a time line on the x-axis called as “Gantt” chart or a Horizontal bar chart format. This format is useful in reporting the progress or status of the project but is not effective in planning.

It could also be shown in a table format with activity name, start date, end date, predecessor, and successor columns. This is useful when a simple view of

the open or closed activities in a project is required for a span of one week. This is useful in monitoring or tracking the activities.

It could also be represented graphically as a network diagram format that shows the various connections and paths between activities. This view is useful in displaying the various dependencies of a set of activities and importantly the “critical path” of the project at any point in time. This format is very effective in planning.

The Schedule Baseline is the version of the Project Schedule that is accepted and approved by the Sponsor or Senior Management.

The other outputs of this process are

Schedule data – This includes additional supporting detail for the Project Schedule such as Resource Histogram, Schedule Templates, Activity and Milestone Notes based on assumptions and constraints

Project Document updates – This may include Activity List, Activity List Attributes updates due to addition of a newly identified activity, Project Calendar updates due to change in calendar units from default days to hours or weeks, Risk Register updates due to scheduling changes.

1. What is the key feature of preparing a Schedule Baseline using Critical path method?

Determining the early start date, early finish date, latest finish date, latest start date for each activity and hence the float of the activity.

Discovering the critical path (path with zero float) among the all the network paths in the project schedule network diagram.

Ensuring that only one critical path exists in the project schedule network diagram.

2. What is the key use of identifying the critical path?

The senior experienced resources can be allocated on the critical path and the junior resources can be allocated on the non-critical path or near critical path (close to zero float).

The identification of the critical path will ensure that the path is in the close scrutiny or burning attention of the Project Manager and the

Sponsor. This will ensure that the required resources for activities on the critical path are protected.

3. How do you compress the duration of the project schedule?

We can achieve schedule compression by:

Crashing – Assign more resources to get the activities completed faster. This will increase cost. At times it may simply not be able to assign more resources to an activity

Fast Tracking – Do work in parallel. This increases risk

Practice Questions

E S T I M A T E C O S T S

Estimate Costs

After completing the first draft of the project schedule you must estimate the likely cost for each of the activities. Let us try and estimate the cost for one of the activities using this process. Let us further assume that the activity involves “Preparing a System Test Cases” for a large IT application that you are building. In the Estimate Activity Resource Requirements process you would have estimated the type of resource required for this activity – say, a Business Analyst. Next, in the Estimate Activity Durations process you would have estimated the likely effort – say, 5 days – to complete the “Prepare System Test Cases” activity. This piece of information (1 Business Analysts for 5 days) would then be documented in the project schedule and used to developing the project schedule.

In this process we are interested in estimating the cost of the activity. The cost would be the daily rate of 1 business analyst for 5 days, and if the daily charge out rate is $500 then the cost for this activity is 5 * $500 = $2,500.

This way the costs for each of the activities are estimated. You must include the cost for all resources used on the project and not just the human resources.

At this point in planning, you are ready with the Project Schedule which will form the key input to this process. You would also have with you a Cost Management Plan which is a subsidiary of the project management plan.

The Cost Management Plan will contain:

Procedures on how to identify the direct, indirect costs of the project,

Procedures on which techniques to use during the cost planning, monitoring & controlling processes.

Criteria to specify the variance limits beyond which a formal escalation and controlling action is required.

Standard format of reporting the cost estimates, budgets and reports.

Chapter

Stakeholder requirements for recognizing the costs based on cost accounting principles. For example, costs can be recognized when orders are booked or when actual payments are made based on default performing organization standards or customer requirements.

The Project Schedule will contain

Information on the quantity of resources, type of resources assigned to an activity.

Unit cost resource rates for each resource required for an activity.

A view of the time period or season for resource requirements. For example, the project schedule will provide details of the timing of the requirement of raw materials or human resources. The costs of steel, raw materials for food industries, hospitality and travel industries are highly seasonal and knowing the timing is important to estimate the costs.

Inputs to estimating the costs are:

Scope Baseline - The scope statement is useful in determining the direct

costs (primarily customized product, service, result related like product testing costs) and indirect costs (primarily generic product, service, result related like organization administration costs) of the activity. It may also include constraints like the cost or expense limits imposed on the project by the customer, project sponsor. The scope statement may also identify the non-functional requirements related to health, safety, security, environment, legal which will help us to calculate the costs related to those areas for some activities in the project.

Human Resource Plan - These are information regarding the human resources cost rate or resource daily charge out rate unit based on designation level or experience level (say $300 per day for a Web Designer with 5 years of experience). This plan may additionally be the source of cost information related to internal funds required for rewarding, recognizing high performers during the course of the project. For example, the human resource costs may include fixed costs (fixed part) and variable costs (variable part based on performance).

Risk Register – The risks that have been identified in the risk register are analyzed to estimate the mitigation costs. The estimating process is closely linked with the risk planning processes.

Enterprise Environmental Factors- For example, the availability of large number of skilled human resources in the location of the project can reduce the project costs because of demand-supply factors.

Organization Process Assets – This repository can be reference to the lessons learnt from past experience of estimating on similar projects. This will help in considering all the cost components associated to each activity in a project. For example, this will help us link travel cost components to any implementation activity at the customer site.

Developing Activity Cost Estimates

This key output of Activity Cost Estimates could be prepared using different techniques or tools in different circumstances. These are similar to the tools and techniques used in Estimate Activity Resource Requirements and Activity Duration Requirements.

Considering experts – The Expert Judgment is a technique by which a project manager consults the experts in a domain, technology, industry environment for their inputs to estimate costs. The project manager could also consult his own team members who are experts in their domain o come up with cost estimates for the activities assigned to them. The experts can directly prepare the estimates or provide advice on which estimation techniques to use for individual project activities given the situation of the project, the urgency of the estimates and the cost limits for preparing estimates itself.

Considering data of historical, similar projects – The Analogous Estimating technique that helps a project manager to estimate current project activities based on past project activities. The keywords here are comparing and similarities. The basis of comparison is using a measure of scale like the overall size, magnitude, complexity of the project. This type of estimating technique is quick but not accurate.

This technique depends on two factors which are the capture of historical information of projects as part of the organizational process assets and the expertise of the team members making the estimate. For example, the system testing activity for a past project on a similar product of roughly the similar size in terms of number of user interface screens (100 in numbers), took about 3 months with 10 people. So the same team lead who performed the last project estimates that the system testing activity for the current project of 90 user interface screens will take about 3 months with 10 people.

This technique of estimating is used to develop high-level, ROM type of estimates at the initial phases of the project. This kind of estimating technique is also known as top-down estimating.

Considering relationship between project activity parameters and cost – The Parametric Estimating technique helps a Project Manager’s to estimate project activities by developing a mathematical model that builds a relationship between a project parameter (like size) and cost. The keywords here are parameters and relationship between costs and parameters. This technique can be used to estimate the

whole project or a project activity. This type of estimating is more accurate and the

accuracy is based on the past data captured in the parametric estimating model.

For example, in function point estimation technique used in IT projects, the size of the project is given in function points. Knowing the relationship between 1 function point and the cost of 1 function point based on the past project records can help in estimating costs for the current project.

In a highway construction project, the relationship between 1 kilometer of road and the cost of constructing a road over 1 kilometer is determined based on past project records. This helps in estimating the cost of a new highway.

Considering best case, most likely, worst case scenarios in likely costs – The Three-point Estimating technique helps to improve the accuracy of estimates. This is done by finding out the three cost estimates (optimistic, most likely, pessimistic) for the same activity and then taking the weighted average of the three points. The most likely point is given a weight of 4, compared to 1 for optimistic and 1 for pessimistic. This type of estimating is also known as the PERT estimate. This is given by the PERT activity estimate formula

.4 cPessimistiMostLikelyOptimisticEstimate

If a simple average is used then the three point estimate is given by the formula

. cPessimistiMostLikelyOptimisticEstimate

The PERT activity estimates are summed up at the project level to give the Project PERT estimate.

Considering complexity of activities – The Bottom-up Estimating technique helps to decompose an activity to further details with a purpose of estimating the costs at a more detailed level. The decomposition is done till the cost estimates can be done with a degree of confidence.

Considering project schedule uncertainty – The reserve analysis technique helps to calculate cost buffers or cost contingency reserves at the project level or at the project activity level. If the cost contingency reserves are calculated at the project activity level, then they are summed up at the project level and used in the next process while preparing the project budget. The EMV (Expected Monetary Value) analysis is a quantitative technique for calculating the cost contingency reserve by multiplying the probability of a risks and their cost impact for a given scenario. The value for the cost impact is taken based on type of risk as positive (opportunity) or negative (threat). The net value of all such values is used as the cost contingency reserve. A simple way to calculate the project activity cost contingency reserve for those activities that have uncertainty is to calculate it as a fixed percentage of the project activity cost estimates.

Considering the cost associated with increasing quality or reducing defects – The cost of quality technique helps to calculate 2 types of costs associated with improving quality at the project level or at the project activity level. The 2 types of costs are cost of conformance (preventing defects by planned reviews, audits, tests) and cost of non-conformance (correcting defects by re-work or replacement).

Considering software tools that can calculate cost estimates – The project

management estimating software tool helps to calculate the costs of a project by the pre-definition of soft parameters and entry of actual values for the soft parameters. For Example, the soft parameter for data storage size, vendor could be defined. When the actual storage size in Giga bytes and a selected specific vendor like IBM is provided, it calculates the number of servers required and the costs associated with building a server cluster for data storage.

Considering the cost estimates provided by external parties – The vendor bid

analysis technique helps to analyze, validate the cost estimates or cost bids by external parties like vendors. The bids are provided as part of the RFP or RFQ updated and sent by the vendor. This may be internally validated by the organization experts or by third party consultants. This may involve modifying the scope handled by the vendor, comparing the details of one quote with another quote, comparing the details of the quote with the overall project costs.

Outputs – Estimate Costs

Activity Cost Estimates - Activity Cost Estimates can be documented in detail as a list with the related components as shown below:

Activity Level (Activity id, Activity Description, Activity Cost)

Direct/Indirect component level(direct, indirect components)

Fixed/Variable component level(fixed, variable components)

Lifecycle component level (Includes the cost of maintenance or support till the end of the deliverable or product’s useful life). Many times this component is ignored because these costs are not seen upfront. For example, while looking at the coding activity, we may use less experienced resources to save costs but do not foresee the support expenses by experienced resources due to the bug fixes during the lifecycle of the product.

All the component levels are not mandatory, but are identified as applicable.

Other outputs of this process are

Basis of estimates – This can be a separate section in the activity cost estimates documentation or a separate documentation. This will give the details

of how the estimates were done, highlighting the methodology used, the assumptions made, the constraints introduced by any cost limits, the range of cost estimate figures with a specific confidence level.

Project Document updates - An example update would be the update required to risk register based on identification of new cost components and their dependencies.

Remember that the activity cost estimates are contributing to the detailed Cost

Baseline that will be prepared at the end of planning activities of cost.

Also note that cost estimates are progressively elaborated and integrated with other processes like Time, Risk, HR, Procurement, and Integration Management. For example, the estimation of cost contingency reserves needs integration with Risk Management. Also exploring human resource options needs interaction with the Human Resource Management and Procurement Management. The evaluation of change requests will require the Perform Integrated Change Control process in Integration Management to interact with the Estimate Cost process to estimate the cost impact of changes. The cost estimate at the initial stages of the project, like in initial phases may have low accuracy but increases as the project progresses in the detailed planning phase. The type of estimate provided at the initial stages is known as Rough Order of Magnitude (ROM) estimate which are given typically with a range of ±50%. The type of estimate provided at the detailed planning phases is known as Definitive estimates which are given typically with a range of ±10%.

1. What is the use of identifying the cost of activities as direct or indirect costs?

It is used to determine the sharing ratio when indirect costs (say organization administration support costs) are identified and take only the part of the total indirect costs towards your project costs. This will help the project manager in planning and tracking the project costs accurately.

2. Identify the following project activity costs as direct and indirect costs

a) Costs incurred towards providing security for the premises where your IT project to deliver a customized product to your customer, along with other IT projects.

b) Costs incurred towards travel of your team members for implementing the customized product at the customer location.

The first one is an indirect cost because the security costs are normally shared among all the IT projects in your organization. Hence the security

costs are to be equitably distributed among all the IT projects based on some criteria like the number of staff working.

The second one is a direct cost because the travel costs are directly or uniquely towards the final implementation of the deliverable of your project.

3. What is the use of identifying the cost of activities as fixed and variable cost components?

Let us look at an example related to manufacturing industries, for renting the latest textile machinery which have a high fixed cost but low variable cost due to better machine quality and efficiency. But it may require a minimum quantity of fabric materials to be produced to be profitable. For lower fabric quantities it may be cost effective to continue with the old textile machinery. Here the fixed costs are the machinery costs and the variable costs are daily operating cost per unit of fabric (which includes basic raw material costs, re-work costs, and daily power consumption costs).

Thus identifying the fixed and variable cost components will help us to operate the project at optimum efficiency based on the volume of deliverables, service or result of each activity.

4. What is the main purpose of the basis of estimates?

The basis of estimates is documented along with the activity cost estimates so that any assumptions, ranges, confidence levels are captured for justifying estimates to project sponsor, customer or explaining estimates to stakeholders. In short, the basis of estimates is a supporting document to the activity cost estimates.

5. What is the advantage of estimating at the project activity level?

This type of estimating is also known widely as activity based costing method. This will help identifying costs at a granular level, so that unnecessary activities and hence costs can be easily eliminated from the project costs. It will also help us in identifying the key high cost activities to be monitored closely from a cost control perspective. Remember that many projects are stopped after starting, because the rising costs of the project offset the benefit margins of the project.

This type of estimating also helps the customer in reviewing, removing, changing the project scope, at the planning phase before proceeding to the executing phase. Many times, customers select the work packages with high benefit cost ratio and hence the need for identifying the low cost

activities. Remember that the activity costs can be summed at the work package level.

Practice Questions

1. Rough Order of Magnitude estimates are in the range

a) –5 to + 5percent

b) -10 to +10 percent

c) -20 to +20 percent

d) -50 to +50 percent

2. Your project has just been initiated and you are discussing project estimates with your senior manager. What type of estimate would you have at this stage of planning?

a) Accurate Estimate

b) Parametric Estimate

c) ROM Estimate

d) Definitive Estimate

3. Supporting detail for cost estimates may include all of the following except:

a) Basis of Estimates

b) Indication of range of cost estimates

c) Confidence Level of estimates

d) Push, Pull and Interactive Estimates

4. Tools and techniques for estimating costs include all of the following except:

a) Cost of Quality

b) Reserve Analysis

c) Vendor Bid Analysis

d) ROM estimates

1 d PMBOK® Guide Page 168

2 c At the beginning you may only have a ROM estimate. Estimates are refined and are more definitive after you complete the WBS.

3 d All others are part of supporting detail.

4 d ROM estimates are not part of tools and techniques

D E T E R M I N E B U D G E T

Determine Budget

At this stage you have the Activity Cost Estimates and Resource Calendar for your project. You now need to determine the project budget. You can do this by rolling-up or aggregating the estimated costs of each of the defined activities to the next higher level (work package level) and finally to the project level. But that is just the amount of work we would definitely be doing. There could be activities we may be required to do that are uncertain at this point in planning. These costs also need to be added up to the cost of performing the activities to obtain the cost performance baseline.

The Activity Cost Estimates and Resource Calendar are the key inputs to this process. As mentioned earlier, Resource Calendars are reference information regarding the number and timing of resource availability (physical raw material, equipment and human resources). This information is required at this stage to determine the timing of the total cost funding requirements.

Other inputs to this process are

Scope Baseline - The Scope statement has references to funding constraints that are mandated by the sponsoring organization. The Work Breakdown Structure is also used to aggregate the costs at Work Package levels, Control Account levels, and Project levels.

Project Schedule – Reference is made to aggregate the costs by project schedule periods, so that project funding requirements can be shown against time periods.

Contracts – The costs related to procurement of resources, deliverables, services and results are confirmed using the contract documents.

Organization Process Assets – An example reference is to access the corporate knowledge repository for a policy, procedure documents related to calculating cost budgets based on access to past projects for lessons learnt and reserves to apply.

Chapter

Developing the Project Cost Performance

Cost Performance Baseline for a project could be prepared using different techniques or tools based on the information source,

The information from the Work Breakdown structure can be used to sum up Costs upto the project level. This is also known as the Cost Aggregation. The cost estimates are summed up (aggregated) starting from the work package level using the WBS as an aggregation template or container. The aggregation then continues to the control account level and finishes with the project level.

The information analyzed from the risk perspective is used to keeping aside cost buffers for known and unknown risks and is also termed as the Reserve Analysis. Two types of reserves – Contingency Reserves and Management Reserves - are determined. The contingency reserves cater to the known-unknown risks and are added to the project costs to obtain the cost performance baseline. The management reserves are not part of the cost performance baseline but are kept aside for unknown-unknown risks. However the management reserves are added to the cost performance baseline to obtain the project cost budget. (See FIGURE 29)

Contingency and Management Reserves

Contingency reserves are cost buffers kept aside for risks of the type “known unknowns”. These risks are identified in the risk register and attempts to mitigate them have been taken. However the cost impact of the risks, when they happen is unknown or uncertain. These buffers are to be utilized when these kind of risks actually happen. The utilization of these reserves is contingent (dependent) on the future happening of the risk. For example, if a product is newly developed and released in to the market, we would expect that some products would be returned back. The “unknown” in this case is the number of products that are returned back. We would plan for a contingency reserve to provide funds for the replacement of the products.

Management reserves are cost buffers that are kept aside for risks of the type “unknown unknowns”. These are risks not identified in the risk register that include situations that are almost impossible to foresee or predict. These would include default or bankruptcy of vendors the performing organization deals with. These buffers are to be utilized when these risks happen with the approval of the senior management.

The information from experts in the organization or the industry is shared in preparing the cost budgets and is also known as Expert Judgment. This is usually done by constituting a budget preparation committee involving the project managers in an organization.

The information from previous projects is utilized in validating the cost estimates while preparing the cost budgets for current projects. This technique is also known as Historical Relationships.

FIGURE 29: Cost Performance Baseline

The information from the finance department needs to be obtained for reconciliation of expenses and income. This technique is also known as funding limit reconciliation. The project expenses that need to be funded are to be balanced with the project funding commitments by the customer or the project sponsor. This will mean that the timing of the completion of work and the timing of the funding commitments have to be synchronized. The plotting of the project funding or income against time period resembles ascending steps. Each horizontal level of the step indicates the funding limit for a given period.

Determine Budget - Outputs

The outputs of this process are Cost Performance Baseline and Project Funding

Requirements.

The cost performance baseline is a plotting of the cumulative value of the project budgets on the y axis and the time period on the x axis. The shape of the project budgets is S shaped indicating that the project costs initially are flat or low and rise

steeply after the initial phases. The project costs then flatten toward the closing phases of the project. This curve is used in monitoring the “performance” of the costs in project using the earned value management technique. Hence the name cost performance baseline.

The project funding requirements is shown as plotting of the cumulative project income required on the y-axis and the period (weeks, months, and quarters) on the x-axis. The shape of these requirements is stepped indicating that the funds are required in steps based on the procurement of a sub deliverable or the completion of a deliverable.

The other output of this process is Project Document updates. An example would be the update required to activity cost estimates during the preparation of the project budget.

Practice Questions

P L A N R I S K M A N A G E M E N T

Plan Risk Management

This is the first process in Risk Management and is where you decide how to approach, plan and execute the risk management activities for the project. This process meets the following objectives:

Ensures there is a common understanding of the Risk Tolerances of key stakeholders – which includes identifying the stakeholders contributing to the risk, their risk tolerances, and resolving any differences they have by communicating the common conclusions to the project teams

Defines common terms such as of probability and impact such as “medium”, “low”, used later in the qualitative analysis, to provide a consistent framework for assessment.

Defines potential sources of risk for the project also known as Risk

Categories often represented as a Risk Breakdown Structure (RBS). These are only broad indicative sources – the Risk Identification process is where the list is expanded further.

The major inputs for the Plan Risk Management process include:

Scope Statement – used to understand project boundaries and assumptions. For example what is not in scope if not well defined and agreed often becomes a major bone of contention with stakeholders at a later stage of the project.

Cost Management Plan, Schedule Management Plan and Communications

Management Plan – These are sections of the project management plan you are creating as part of planning your project. These plans states how the schedule reserves and contingency reserves would be accessed, utilized and reported should risk events occur. The WBS needs to be assessed to determine possible areas where risks can occur. For example project plans that have time allocated for testing but none for fixing and rework that follows. Testing and rework is a loop process – which is not possible to implement in most project planning tools (e.g., MS Project) – so project managers get around this by padding other task estimates. This would be a planning risk.

Chapter

Organization process assets – These are the standards and policies around risk including risk categories, roles and responsibilities, and definitions of the decision making process. For example the RBS shown in FIGURE 30 is a typical process asset used by risk planning teams.

Enterprise Environmental Factors – This defines the organization’s tolerance for risk. Risk tolerance translates into 3 types of risk attitudes within an organization or project groups:

1. Risk Averse – this group is uncomfortable with uncertainty, has low tolerance for ambiguity. Such a group tends to focus mostly on how to minimize or avoid risks and looks for ways to reduce threats and in the process they tend to ignore opportunities.

2. Risk Neutral – see risk-taking as a price for future payoffs and is neither risk averse nor risk seeking. They take action on a risk only if they know it is likely to lead to significant benefit and therefore have a balanced approach to threats and opportunities.

3. Risk Seeking – they will pursue opportunities aggressively and take big risks to achieve these. They are often likely to underestimate the probability and\or impact of a risk and will tend to accept the risk as a response.

Plan Risk Management – Tools & Techniques

You and the project management team would need to conduct planning meetings to discuss and develop a risk management plan. Invitees to this meeting could include key stakeholders, key team members and risk management team members of your organization.

Contents of a Risk Management Plan

The output from this step is the Risk Management Plan which forms an integral part of the Project management plan and should be reviewed and updated during the course of the project if a risk process is modified. The final Risk Management plan should describe the 5W + H – Who, What, When, Where, Why and How and includes:

Roles and Responsibilities – defines who does what activity in the Risk activities

Budget provisions for risk management activities – approved funds available for risk management activities to be tracked against actual

Schedules for risk management – revised schedules (to the project plan) to include risk management activities

Categories of risk to be addressed – either an RBS or a list used to categorize and prioritize risks. FIGURE 30 shows a typical RBS.

Probability-Impact scale definition – definition of what is considered low and what is considered high etc.

FIGURE 30: Risk Breakdown Structure

1. Stakeholders & Project Complexity are two major sources of project risk. Discuss.

Many popular published reports6 testify to senior management support and customer involvement being the single largest contributor to a project’s success. Interpreting this in converse we can conclude that stakeholders are a major source of project risk resulting in its success or failure that needs to be identified and managed as a risk.

Earlier in Chapter 1 we described how complexity is a source of uncertainty and can be caused by multiplicity of stakeholder interactions – sometimes leading to unexpected risks. Not understanding the nature of

6 CHAOS Report, 2009

different stakeholders and how they impact a project can often lead to spectacular project failures

Practice Questions

1. The Plan Risk Management Process should be completed

a) Late during project planning

b) Early during project planning

c) Early during project execution

d) Late during project initiation

2. The Risk Management Plan may be developed by which of the following BEST option?

a) Project Manager

b) Project Manager, Selected project team members

c) Project Manager, Selected project team members and Stakeholders

d) Project Manager and Project Management team

3. The following provides a structure that ensures a comprehensive process of systematically identifying risks using categories?

a) Probability and Impact Risk

b) Risk Identification checklist

c) Risk Register

d) Risk Breakdown Structure

1 b Risk planning is to be must be done as early as possible in planning

2 c Stakeholders – select project team members, PM and other key stakeholders must participate

3 d RBS

I D E N T I F Y R I S K S

Identify Risks

In this step you and your project team explicitly identify risks that have the potential to affect the project and document their characteristics. This step follows after the risk management plan is constructed and continues iteratively through planning. In some cases an identified risk can have an immediate “candidate” response which should be captured and implemented provided it is cost-effective and feasible.

The key input to this step is the Risk Management Plan which provides the details of roles\responsibilities of managing different risk activities, budgets and schedules for risks management related tasks, risk categories such as the RBS. Other inputs are as follows and we have seen all of these in the previous chapters:

Activity Cost Estimates

Activity Duration Estimates

Scope Baseline

Stakeholder Register

Cost Management Plan

Schedule Management Plan

Quality Management Plan

Other Project Documents

Enterprise Environment Factors

Tools and Techniques for Risk Identification

Tools and techniques used for Risk Identification are based on:

Chapter

Review of Documents

Information gathering

Analysis of Checklists, and

Diagramming techniques.

A structured review of project documents including plans, assumptions, contract and other information can help uncover potential project risks.

Information gathering is done through Interviewing and Brainstorming whereby specific risks can be identified using SWOT (Strengths, Weaknesses, Opportunities, Threats), Wide Band Delphi method to name two (a number of other methods exist such as Risk Checklists, Brainstorming, Nominal Group Technique (NGT), Crawford slip). (INCOMPLETE STATEMENT xxxxxxxxxxxxxxxxxxxx)

Diagramming methods include the Ishikawa cause-and-effect diagram which can be used to determine risks.

For each of these techniques it is important to have SMEs (Subject Matter Experts) involved from diverse groups. It is also important to combine different methods where possible – for example using a Risk checklist developed from previous projects as a starting point for a Brainstorming session or using a Brainstorming session to complete the SWOT analysis or using an RBS with a Cause-Effect Diagram is a good practice.

SWOT Analysis

SWOT is an acronym for Strengths, Weaknesses, Threats and Opportunities - considers risk from both the internal and external environment. This technique is useful specially when considering both Risks (Threats) and Opportunities. Users of the SWOT analysis identify and list risks under the SWOT headings.

Strengths – Internal factors related to the project or organization that helps to achieve objectives.

Weaknesses - Internal factors that obstruct achieving objectives and can be improved.

Opportunities – Factors that are not currently present in the project or organization, but could reflect positively on achieving our objectives.

Threats – Factors that are not currently present in the project or organization, but could reflect negatively on achieving our objectives if they occur.

A typical SWOT analysis is shown in FIGURE 31 for a software project involving changes to an existing application

FIGURE 31: SWOT Analysis

The process of completing the 4 quadrants can be done by brainstorming, using risk checklists or an existing RBS. It can be done one quadrant at a time – which works well with first time users or all at the same time for more experienced teams.

Wide Band Delphi

This is based on the standard Delphi method (called “wide band” as the modified version allows for interaction of greater number of participants) and is a technique that involves

Interviewing SME’s

Interviews are anonymous – reduces the effect of individual and group bias in responses

Can be used when there may be conflicts or confrontation or when brainstorming is not recommended

Can be used to get comments even from “competitors”

It uses an iterative, refinement method to reach a statistical group response where the opinion of each SME is represented in the final response.

Some limitations of the Delphi method are that it is slow and time consuming – sufficient time and effort need to be devoted to it. In some cases extreme views may be dropped in a drive to get to a consensus thereby losing its value in Risk identification (where extreme views are important), and a final consensus can sometimes be manipulated by a large group\facilitator (“groupthink”).

The process steps involved in the exercise are:

1. Define the Scope of the Activity – in this case Identification of Risks

2. Identify a Facilitator or Moderator – the moderator in turn determines the stakeholders (SMEs) for this project that need to participate in this exercise

3. The moderator develops a series of questions based on the Risk Management plan, Project Scope, Plan and other documents existing at this point

4. The questions are sent to the stakeholders participating individually to answer

5. The facilitator collects the responses and consolidates the answers to create a summary which includes most common as also divergent themes – while retaining anonymity of contributors

6. The facilitator distributes this summary back to the stakeholders for another round of answers

7. The facilitator iterates through Steps 4 to 6 till a consensus is reached when the final list of risks is documented

Using Ishikawa Diagrams in Risk Identification

Also called the Fishbone or a Cause-and-Effect diagram (CAED), the Ishikawa diagram is a tool with its origins in quality management but can be used for identifying risks with a caution on watching out for potential confusion in interpreting it.

The tool is easy to use, allows for different opinions from a team and goes beyond risk identification to provide causes to which responses can be formulated. Limitations of the tool include the inability to handle complex problems, inability to handle interactions and chronological dependency (i.e. time dependency) between different causes.

The term fishbone arises from the fact that the diagram connects a series of causes depicted as branches of the fishbone with a resulting effect in the form of the “head” of the fish. The tool visually depicts causes and their resulting effects, but it must be understood that risks are not explicitly visible in this diagram – they need to be

derived from the uncertainties introduced by a cause - this is explained in detail a little later.

FIGURE 32 shows an Ishikawa diagram for a typical project problem i.e. low productivity during the development cycle (the effect) due to multiple causes often addressed as the 4M +E i.e. Materials, Manpower, Methods, Machine PLUS Environment.

FIGURE 32: Ishikawa Diagram

Poor Productivity

Envrionment

Machine

Manpower(Staff)

MaterialsMethods

Lack of

Standardization

Lack of

Skills

Hardware Contracted

Distributed

Facilities

Whilst identifying risks a common mistake is confusing causes and effects as potential risks. This obscures genuine risks and diverts management attention to non-risk events. Therefore it is useful to define causes and effects in the context of risk

Effects – are unplanned variations from a stated objective that arise as result of risks. Being late for a milestone, exceeding an authorized budget, not meeting system performance targets are all examples of effects. An effect is a Contingent event i.e. they occur only if a risk occurs and therefore they “cannot be managed by a Risk Management process since they do not exist till a Risk exists”.

Cause – is a definite set of events or circumstances which already exists in a project or environment and can cause uncertainties and risks. The need to use new technology for a project, having inexperienced staff, working in a new organization culture – are all possible causes of risks. Causes themselves are not uncertain and are not the main focus of risk management. However knowing about and tackling the cause can avoid or mitigate a threat or allow an opportunity to flourish.

In interpreting the Ishikawa diagram for identifying risks a useful technique to avoid this confusion is to use the following risk-meta language7 to describe each branch of the fishbone

As a result of a <CAUSE> an <UNCERTAIN EVENT\RISK> may occur which would lead to an <EFFECT – positive or negative> on some performance objective.

We can now interpret FIGURE 32 by constructing the following sentences to isolate the risks as opposed to Causes and Effects.

1. “ ..As a result of using new Hardware(the cause), unexpected system performance issues may occur (Performance Risk) leading to spending time fixing the issues and lowering productivity (the effect on an objective)”

2. “..As a result of a lack of skills amongst Staff (the cause), the time allocated in our plans for Testing many not be sufficient (Planning Risk) leading to poor productivity(the effect)”

3. “..As a result of using contracted staff from a partner (the cause), more effort and time may need to be spent on communicating our standards and procedures (Resourcing, Communications, Planning Risk) leading to overall poor productivity(the effect)”

Output from Risk Identification

The Risk Register is the primary output of this step. The Risk register is created in this step and traces its flow throughout all the PRM processes and will ultimately contain all identified risks, including description, category, and cause, probability of occurrence and impact on objectives, proposed responses, owners, and current status.

However at the conclusion of risk identification it will contain only the following details

Lists of identified risks

List of potential responses – this is optional and relevant only for immediate known responses for some risks

7 Hillson David Risk Management in Practice, The AMA Handbook of Project Management / book auth. AMA. - 2nd Edition, Jan 2006. - Vols. Chapter 14, Page 184.

Root causes for the risk – which are the fundamental conditions which cause the risk

Updates to the Risk Categories – The process of identifying risks can often lead to new risk categories being added.

Practice Questions

P E R F O R M Q U A L I T A T I V E R I S K A N A L Y S I S

Perform Qualitative Risk Analysis

The Identify Risks process may produce a long list of risks that cannot all be addressed due to time and cost constraints. Therefore, there is a need to identify the risks and opportunities deserving the highest priority for further attention – this is the objective of the qualitative risk analysis. The work done in this process step provides a “narrowed down” list for quantitative risk analysis (if needed) and risk response planning.

Key inputs to this process include the Organization Process Assets (can provide an insight on how some risks were handled in the past), Project Scope Statement (e.g., may indicate a technology or process may be new to the project raising risk), Risk

Management Plan and the Risk Register.

Qualitative Risk Analysis – Tools & Techniques

Key tools and techniques used in this process are the Risk Probability-Impact

Assessment, and the Probability-Impact Matrix (PIM) or Risk Matrix.

The risk probability is a value assigned to the likelihood that a specific risk will occur and is expressed in a range from 0 %( will not occur) to 100% (certain to occur). Risk impact assessment is a value that defines the effect of the risk on a project objective usually time, cost, quality, regulatory compliance, performance and many others. For threats the impacts are negative e.g., lost time, extra cost and for opportunities they are positive e.g., saved time or cost.

As an example if the current attrition in the company is high there is an equally high probability that people from the project may leave and its impact on the project could be high. On the other hand if there is adequate cover for these resources (say through contracted staff) the probability of the risk is still high but its impact may be moderate or low as it can be managed, the overall risk will also be lower.

Risk Matrix or Risk Probability-Impact Matrix (PIM)

A sample Probability-Impact matrix from the PMBOK® Guide is shown in FIGURE

33. Each risk is rated on its probability of occurrence (0.10 – low to 0.90 – high along

Chapter

the Y-Axis) and impact upon an objective such as cost, time etc. – also expressed as a number between 0 and 1 along the X-Axis. The resultant product of Probability-Impact called the Risk Index is stored in the cells of the matrix.

For example a high probability risk with a value of 0.9 and posing a high threat with a value 0.8 will have a Risk Index value of 0.72 – marked red indicating high risk for the project. The same holds for other cells in red. Cells with amber can represent moderate risks and green – low risks that need only to be kept in a watch list.

FIGURE 33: Probability Impact Matrix

A recent innovation to the PIM has been to divide the matrix into 2 mirror images covering Threats and Opportunities with similar scales – both are assessed and captured at the same time.

Problems with the Risk Matrix

The Risk matrix presented above has some shortcomings that need to be understood especially when using numeric values and performing mathematical operations. Among the issues to watch out for are8:

Range Compression – By using the matrix original unambiguous data is compressed into a narrow range of numbers resulting in a loss of key information. This means we could get two risks that are quantitatively different being assessed as the same. For example in FIGURE 33:

8 Anthony Cox Louis Jr What's wrong with Risk Matrices?, Society for Risk Analysis , 2008. - No 2, Vol 28.

A 1% and a 29% probability will fit into a single probability of 0.10 i.e. low

If the X-axis is a cost objective and if $ 100 million is assumed to be the maximum i.e. value of 0.8, then a $250 million impact will also have the same value of 0.8 since there is no higher number for impact

A 1% chance of losing $ 100 million and a $29% chance of losing $ 250 million will both translate to a Risk Index = 0.1 x 0.8 = 0.08 (amber) i.e. a moderate risk.

However a simple EV (Expected Value) comparison would indicate that 29% x 250 mill = $ 72.5 million is far greater than 1% x 100 million = $ 1 million risk!

Presumption of Regular Intervals – The matrix uses an ordinal scale (High, Moderate and Low) which is translated into cardinal values (0 to 1) and gives rise to an impression that numbers used roughly approximate the relative importance of the factors. An impact value of 0.8 is considered 2 times higher than one of 0.4 or a Probability of 0.6 is considered 3 times more likely than one with 0.2.

In reality the actual values for Probability -Impact may be much closer or farther away relative to each other than these numbers indicate giving rise to wrong assessment of risk priorities.

Presumption of Independence – The risk matrix given above when used to plot multiple risks ignores the effect of the “correlation” between different risks since it assumes they are independent leading to an over or under assessment of risk priorities. It is possible for two different risks both in green cells (i.e. low to moderate likelihood and impact) to become a high risk if they occur together.

As an example we consider “loss of an office working facility due to bad weather” as a moderate risk and “unavailability of some staff due to bad weather” also as a moderate risk. If both events happened at the same time (quite likely if the weather affects the facility and people located in the same geography) then the overall risk is “cessation of all work since there is no place to work even if some staff is available” – which would be high risk.

Suggested ways to use the Risk Matrix

Though there are issues with the Risk Matrix and many leading texts on risk management advocate doing away with them completely9, they are easy and intuitive to use and still widely employed and will continue to be used. A suggested way of developing and using this matrix is to convert all numbers to an ordinal scale by

9 Chapman Chris and Ward Stephen, Project Risk Management, Process Techniques and Insights, John Wiley & Sons,

2003, 2nd Edition.

calibrating the real Probability-Impact values to this ordinal scale. To do the conversion each organization needs to calibrate its Probability-Impact values into ordinal scales such as VHI – Very High, HI-High etc. as shown in FIGURE 34. This is part of the Organization Process Assets and is specific to each organization.

FIGURE 34: Sample Risk Matrix Calibration

Time Cost Quality

VHI 61-99% > 40 days >$ 200K Very significant impact on overall functionality

HI 41-60% 21-40 days $101K-$200K Significant impact on overall functionality

MOD 21-40% 11-20 days $51K-$100K Some impact on key functional areas

LOW 11-20% 6-10 days $11K-$50K Minor impact on key functional areas

VLOW 1-10% 1-5 day $1K-$10K Minor impact on secondary functions

NIL <1% No change No change No change in functionality

Impact on Project Objectives(±)Scale Probability

Once this is done a risk matrix can be developed where the Risk Index cells are now risks with a High, Moderate and Low values where H > M > L as shown in FIGURE

FIGURE 35: Suggested alternative Risk Matrix based on Ordinal Scales

Probability

VHI L M H HI H H HI H M L

HI L M M HI H H HI M M L

MOD L L M HI H H HI M L L

LOW L L M M H H M M L L

VLOW L L L L M M L L L L

VLOW LOW MOD HI VHI VHI HI MOD LOW VLOW

Threats Opportunities

Impact (Oridnal Scale)

Probability and Impact Matrix

Caveat Emptor (“buyer beware”) - in spite of the improved method of using the Risk matrix, it is best used for coarse, distinct (no overlapping of risk boundaries), well identified risks keeping the shortcomings mentioned in the previous section in mind.

Key Outputs from Qualitative Risk Analysis

The key output from this step is the updated Risk Register which would now contain

Relative ranking or priority of risks – based on the color coding and scales

Risk categories – this is where the individual risks are grouped into categories such as those in the RBS which helps determine hot spots of exposure. This can be further mapped to the WBS to identify project areas that could be affected by the risk.

Risks requiring immediate or near term responses - i.e. the time dependency of the risk.

Practice Questions

Which of the following is NOT a tool and technique of Perform Qualitative Risk Analysis A. Risk Categorization B. Expected Monetary Value analysis C. Risk urgency assessment D. Probability and impact matrix

Risks which have low priority A. are not addressed in detail but kept in a watch list B. are addressed in triggers C. are addressed as part of contingency plans D. are same as residual risks

P E R F O R M Q U A N T I T A T I V E R I S K A N A L Y S I S

Perform Quantitative Risk Analysis

The qualitative risk analysis step deals with one risk at a time which may occur over different times in a project’s duration. Many risks are correlated i.e. they may move together/opposite at the same time and their combined effect on project outcomes such as Cost and time is difficult to understand. In such cases a qualitative analysis in itself may not be sufficient.

This is where the use of a quantitative model which uses probability distributions (continuous and discrete) and techniques such as Monte Carlo simulation, Decision

Trees and Sensitivity Analysis is done to quantify the risks from multiple factors. Because this method requires data collection & verification, skilled staff, expensive tools it is often not justified for use if the qualitative analysis step reveals simple risks with sufficient detail. Quantitative risk analysis is often used in highly complex projects, where quantitative decisions such as a bid price, milestone, delivery dates have to be given under uncertainty.

The key input for this step is the updated Risk Register. However, Organization

Process Assets, Risk Management Plan, Cost Management Plan and the Schedule

Management Plan are also inputs to this process.

Quantitative Risk analysis - Tools & Techniques

The primary tools used in this process step are:

Data Gathering & Representation Techniques – These include data gathering techniques such as interviewing and modeling datasets using discrete and continuous probability distributions.

Quantitative Risk Analysis Tools such as Monte Carlo Simulation and Decision Trees

Expert Judgment.

Monte Carlo Simulation and Decisions Tress are explained in detail later in this section.

Chapter

Irrespective of the tool or technique used these have the following prerequisites:

The data quality and integrity must be ensured to avoid a GIGO (Garbage In-Garbage Out) situation

It is necessary to interpret the outputs produced from the models since the quantitative analysis in itself will not tell the manager what decision to take

Monte Carlo Simulation

Consider the following scenarios:

A new product is to be released to market – will it succeed? Sales could be low to high – an unknown; unit price to produce the product (i.e. the cost to make plus a fixed margin) could vary between low to high – another unknown; rivals can enter with a competing product that may impact sales by a certain negative factor – could be high or low – again unknown. How do we determine our overall strategy when faced with multiple unknowns that are possibly related?

There are three parallel critical tasks in a project plan all due to end at the same time i.e. to merge. These are 3unknowns with values initially decided through expert judgment with varying levels of confidence. So how do we find out the probability that the 3 tasks will finish at the same time?

Your project Risk Matrix has defined over 10 critical risks for the project each with its Probability-Impact ratings. You are unsure of the actual probability ratings for each risk believing that it may vary by 20%. Additionally you want to evaluate the overall Probability-Impact of the project for all risks combined. How can this be done?

In each of these cases the Monte Carlo simulation technique can be used. The way a Monte Carlo simulation works is that it generates a large number of scenarios based on varying probabilities as inputs. For each scenario a specific value will be generated randomly for each unknown probability value. These values then go into the formula to compute the output for a single scenario; the output can be revenues, cost, time, resources or any other numerical factor. The same process is repeated for all scenarios producing a distribution of the output values from which decisions can be made using statistical analysis.

Consider the sample Risk Matrix (FIGURE 36), it consists of the top 3 risks identified and each risk has the effect of causing project delays. Experts from the project have been asked to provide an Optimistic, Most likely and a Pessimistic value for the delay in days for each risk. The last column contains the PERT estimate for each risk.

FIGURE 36: Monte Carlo Analysis - Inputs

Based on this if the 3 risks occurred at the same time there is a chance according to the PERT estimates that the schedule will be pushed back by 15 days, the maximum delay due to project dependencies. Of course it will be worse if the events happened in sequence.

Since there are 3 unknowns we can double check the PERT estimate using a Monte Carlo simulation. The steps for the simulation are:

1. Determine the probability distribution that will be used for the range of delay values. In this case the Triangular distribution formula (refer FIGURE 39) is an appropriate one as it is often used when sufficient data points are not available. Other popular distributions include Normal, Uniform, Bernoulli and Poisson.

2. Use an MS-Excel random number generator to produce probability values that are fed into the formula (for the Triangular distribution refer FIGURE

39) to produce an expected value of delay for each risk. The maximum value is the overall project delay. A set of generated values is shown in FIGURE 37, normally this table will have over 10,000 rows for the number of scenarios tested.

3. The cumulative probability values for the overall delays is derived from the table and shown in a graphical form – this is the main output from the MC analysis.

FIGURE 37: Monte Carlo - Spreadsheet Calculations

Project

Dependency

Screep

Resource

Availability

Overall

0.00 9 6 8 9

0.39 15 9 12 15

0.63 17 11 14 17

0.76 19 12 15 19

0.06 11 7 10 11

0.51 16 10 13 16

0.46 15 9 13 15

Delays due toProbability

(Random

Number)

FIGURE 38: Cumulative Probability from Monte Carlo Analysis

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Looking at this graph it becomes evident that

There is a 40% probability or confidence value (oval number 1) that the overall delay will be 15 days, in other words our PERT estimate has a confidence level of 40% or P40.

There is a 50% chance that the overall delay will be 16 days (oval 2)

To reach an 80% confidence level of the impact of the risks the actual delay could be 19 to 20 days – oval number 3

At a P90 or 90% confidence level the delay will be 21 days, a 140% negative variance from our PERT estimates.

It is evident that in spite of the best knowledge and trusted sources for information at our service, presence of multiple unknowns greatly alters our risk assessment and the Monte Carlo simulation technique provides much greater insight into the real risks.

FIGURE 39: Triangular Distribution and its use in a Monte Carlo Simulation

Decision Tree Analysis

This is a useful tool for determining Expected Values of a decision where multiple outcomes are possible. A decision tree is built around each possibility or an uncertainty following a separate path leading to an overall expected outcome. By comparing the final Expected outcomes of the different paths a decision can be made on choosing a path depending on the Expected Value objective e.g., lowest costs, highest revenues, least time and so on.

Decision trees are useful since:

They identify contingent actions as a response to Risk occurrence by providing a less risky alternative (or one with greatest opportunity)

They help identify the value of preventive and mitigating action – useful when deciding the appropriate Risk response(refer section on Risk Response planning later)

They show the dependence among the risks, for example if the first one occurs it shows that future ones as well as contingent actions may become irrelevant.

Decision trees are typically used for projects with small number of risks or to focus on a particular set of important risks – they become impossible to use when number of risks are very large.

A decision tree is shown in FIGURE 40. The following terms are used with decision trees and are useful to know:

Expected Monetary Value (EMV) – this is defined as the sum of the products of the Probability of an event with the value of this event. For example an event having a probability of occurrence of 50% and a value of the outcome of $ 1000 cost has an Expected value of = 50% x 1000 = $ 500.

Decision Nodes and Event (Probability) nodes – There are two types of nodes created in decision trees. Decision nodes are used to present different alternatives of which only one can be chosen finally for e.g., if there are 2 alternatives given of (a) Buying a product and (b) Building a product – this is a decision node since choosing one means abandoning the other. Event or probability nodes are used to present uncertainties contained within the event using probabilities for each path i.e. the different paths are all possible.

The example below illustrates the use of a decision tree

You are responsible for presenting and implementing a new ERP system which if approved has a total value (in terms of net of costs saved, productivity benefits etc.) of $ 100 million if fully successful. The chance

of this occurring is estimated at 60%. On the other hand it could have a limited success and produce a net value of $ 30 million. The other possibility is that the project can fail implementation and result in a loss of $20 million with a 50% probability.

We draw the decision tree in FIGURE 40 starting from left to right

1. The Decision node titled “ERP Project” has two alternative paths – either the project is approved and we build the ERP system or it is abandoned by Upper Management. Decision nodes are often shown as squares.

2. The path to abandon the project leads to a net cost of 0 and this is the end of this path. Note that the EMV for this path is actually = 100% x $ 0 = $ 0 (since if this path is chosen it has a probability of 100% and a Value of $0)

3. On the other hand if the project goes ahead then we reach an Event\Probability node titled “Project Decision” where 2 alternative paths exist i.e. a 50% chance of “Moving Forward” and a 50% chance of failure. Event nodes are indicated by circles.

4. At this point if the project fails then we lose $20 million and this is the end of this path

5. If the project is successful we reach another Event\Probability node titled “Project Success” that has two paths – one for a fully successful ERP implementation with a 60% probability and a partly successful result with a 40% chance. For both these paths we note the final values of success i.e. $ 100 million and $ 30 million which is the end of the tree traversal.

6. To evaluate the decision tree we use a technique called Folding Back

where we work backwards from the rightmost ends of the tree as follows

For the node “Project Success” we determine the EMV for this node as the sum of the Product of Probability and Value for its 2 legs i.e EMV2 = 60% x $ 100 + 40% x $ 30= $ 72 mill

For the node “Project Decision” applying the same logic as in point (a) we determine the EMV as EMV1 = 50% x EMV2 + 50% x (-20 million) = $ 36 million - $ 10 million = $26mil

7. Finally for the node “ERP Project” (the starting point) – since it is a Decision node we compare the EMV’s of each leg i.e. Build ERP system has a value of $26 million and Abandon has $0, the final decision would be to go ahead and build the ERP system.

FIGURE 40: Sample Decision Tree

ERP Project

Project DecisionBuild the

ERP System

Do not build

the ERP system

Project Success

Project moves forward

50% Probability

Project Fails

50% Probability

$0 mill Project

Abandoned

-$20 mill Project

Failure

Partly Successful

40% Probability

Fully Successful

60% Probability

$30 mill Part

Success

$ 100 mill Full

Success

Decision Node

Event or Probability

EMV2 = 60% x 100 + 40% x 30 = $ 72 mill

EMV1 = 50% x 72 - 50% x

20 = $ 26 mill

EMV0 = $ 26 mill

EMV0 = $ 0 mill

Legends

Interpreting the Decision Tree Correctly

Decision trees provide us a method to choose one path when presented with multiple alternatives having uncertainties. However, the real value of a decision tree does not end here for the manager looking to quantify risk. For the sample decision tree we used earlier the build a table shown in Error! Reference source not found.. Note the conditional probability for full and partial success. They are conditional because the 60% or 40% success probability depends on a 50% prior probability that the project goes forward.

FIGURE 41: Interpreting Decision Tree

What the table indicates in simple terms is that there is a 20% chance of making $ 30 million or less, a 50% chance of making $ 100 million or less and a 50% chance of making a loss of $ 20 million if we decide to build the ERP system. Thus the tree provides us with a range of impact values with different levels of confidence; it also indicates that risk is not a single number but a range of possibilities.

Sensitivity Analysis

Using the data in Error! Reference source not found. it is possible to determine what value, for some or all of the uncertain variables such as probability of success\failure, probability of full\partial success or amount lost on failure in the tree, can change our decision in the ERP project to abandoning it instead of building. This is a case where the EMV for the “Build ERP system” becomes negative.

This can be done through Sensitivity Analysis where we choose one uncertain variable keeping others constant and try different values to determine at what point we get an overall EMV less than 0.

For illustration let us choose the variable of interest to be p=Probability of Project Success (so 1-p = Probability of Failure). We can solve for p by specifying that the following equation must be less than 0

(1-p) x -20 million + p x 60% x 100 million + 40% x p x 30 million < 0

Solving this we get p < 22% i.e. at 22% or less chances of success the ERP project should be abandoned. The PM now has a lower limit on the chances of full success i.e. 22% and can either take appropriate action to increase these chances or avoid\mitigate risks that reduce the impact value.

Risk Attitudes and Utility Functions

A decision tree normally leads to a path with an optimized EMV or EV, one that signifies least risk or the maximum opportunity. However the final decision is often taken by an individual, a group or even an organization that has certain “risk attitudes” that may alter the final decision. We discussed risk attitudes in Risk Management Planning, and here we look at quantifying their effect on project decisions.

To understand the effect of risk attitudes we relook at the ERP system example from the perspective of a risk-averse organization. Such an organization would avoid project decisions that had the possibility of failure leading to a large loss even if such a decision had a chance of substantial gain. In other words they would seek a much higher gain for a given chance of loss when compared to a Risk-Neutral group. Remember a Risk-Neutral group is balanced and looks to maximize its value or minimize its cost – to them the ERP build would make sense.

A risk-seeking organization on the other hand would seek relatively small gains compared to a Risk Neutral group in order to take the project decision to go ahead.

One method to express these different risk attitudes is through the use of Utility

Functions which is applied to all monetary values in the decision tree when it is built. What the utility function does is to decrease (for Risk Averse) or increase (for Risk seeking) or leave unchanged (for Risk Neutral) the “real value” of money (or any other unit of uniform measure) per unit increase in risk.

The Square Root - √x function for example is a simple utility function that can be used to express “Risk Aversion” – using this we can redo the risk table for our example as shown in FIGURE 42.

FIGURE 42: Final Expected Values

The final expected value is now reduced to $1.9 million, still greater than abandoning the project, so the earlier decision to build the system remains unchanged. Clearly for this type of risk-averse group any changes to either the chance of success\failure or the quantum of loss can quickly change the final decision.

For example for this Risk Averse group doing a Sensitivity analysis on p=Probability of Success shows

(1-p) x -4.47 mill + p x 60% x 10 mill + 40% x p x 5.5 mill < 0

And we find that p needs to be 35% or more, higher than the 22% for a Risk Neutral group. PMs in such organizations need to go to greater lengths to ensure risk avoidance and mitigation steps are in place.

Key Outputs from Quantitative Risk Analysis

The key outputs from this process step is the Updated Risk Register which should contain the following

A probabilistic analysis of the project using the tools mentioned – includes ranges of schedule and cost estimates with associated confidence levels. The example output showing potential impact values and associated confidence levels from the Monte Carlo and decision tree methods is an example of this data.

Contingency reserves calculations based on the Probabilistic analysis. This is a way to quantify and justify to management the need and amount of contingency reserves to cover shortfall. For example the Monte Carlo simulation shows that the maximum potential delay at 90% confidence is 21 days compared to a most likely PERT estimate of 15 days – a wise PM would then add a contingency buffer of an extra 3 to 6 days to their 15 day estimate.

Prioritized list of quantified risks which builds on earlier risk prioritization to identify the risks that pose the greatest threats or opportunity to the project by giving them a “quantifiable measure” and allowing finer comparison between them.

Trends in quantitative risk analysis – when this step is done regularly as new information comes the PM can spot trends in the values that indicate if some risks are growing or diminishing over time.

Practice Questions

R I S K R E S P O N S E P L A N N I N G

Risk Response Planning

This is the step taken to develop options and scenarios to mitigate or eliminate risks and threats to the project. The risk response should be in line with the significance of the risk, be cost-effective, and realistic. Normally a collaborative discussion needs to occur to assure the best option is the response.

The key input for this step includes the Risk Management plan and the Risk Register.

The Risk Management plan provides definitions of roles and responsibilities for who owns a risk and who owns the budgets, and thresholds to decide on risks while the Risk Register contains the resulting risks from the qualitative and quantitative analysis to which responses need to be determined.

The key to a Risk Response is to approach it strategically by focusing on both threats and opportunities. Typically the responses to a Threat\Opportunity are

Avoid\Exploit – For threats the aim of avoidance is to make the risk impossible or irrelevant. For example choosing not to use a new development tool with an associated risk of time lost due to steep learning curves is a case of Avoidance. For opportunities exploit means making sure this opportunity happens benefiting the project.

Transfer\Share – Transfer involves another person or a 3rd party whereby part of the risk, both the impact and the responsibility for managing any downside, is transferred to this other group. Buying Insurance is an example of how risk can be transferred to an Insurer, the “risk premium” charged by the Insurer is a function of the risk characteristics (probability, impact), whether the insurer has a “portfolio of similar risks” they can use to reduce their overall risk.

A notable feature of the transfer strategy of risk is that

“Worst case” scenarios will become better e.g., insurance against fire will ensure recovery in case of a serious damage

"Best or Expected” case scenarios will become slightly worse i.e. the value will decrease since a risk premium (i.e. extra cost) has to be paid to the 3rd party

Chapter

So the transfer option should be chosen only when the improvement in the “worst case” scenario is greater than the reduction in the “best or expected case”.

The case of share is when an organization wishes to share the risks with others while seeking a big opportunity that it could not have attained on its own. Very large scale project opportunities are often sought by companies forming consortiums (partnerships), sharing the risk in return for a large slice of the opportunity pie.

Mitigate\Enhance – Mitigation of a threat aims to reduce its probability and\or impact, enhancing an opportunity seeks to increase it. This often needs to be justified with a cost-benefit analysis exercise.

Accept – For residual threats and opportunities (i.e. the threat or opportunity remaining after controls are in place) where cost of proactive action is more than the risk impact i.e. risk response is not cost-effective, accepting the risk is the best option.

Acceptance of risks can be of two types:

Accept Passively – when impact of a Risk is well below the organization threshold, no prior plans are put in place

Accept Actively - when impact, if the event occurs has to be reduced. In this case a contingency plan is required to reduce the overall impact. Plans are made but not executed unless the event occurs.

Funding Implications for Risk Responses

Any process of responding to risks may have a funding\cost and time implication which needs to be understood since an efficient solution implies that it is less expensive to implement than the risk it is trying to solve. Typically an organization has different types of budgets that it maintains to execute projects

Operating or Performance budget – amount of money (or time) estimated for all normal activities planned for in a project. This is normally within the control of the Project Manager and is the one tracked for performance assessment.

Contingency Reserves – is the money (or time) that is set aside for risks and unplanned activities (for the “known Unknowns”). When a risk takes place this fund is used to transfer money to the Operating budget. Sometimes a Project Manager may require approvals from higher authorities (e.g., a Project Steering Committee) to do this transfer accompanied with justifications.

Management Reserves – this is a set of funds that are available only to the senior management and are meant to tackle the “unknown unknowns” i.e. extreme risk conditions for activities not identified. This is the last line of defense against risk.

FIGURE 43 captures the different budget implications for each type of Risk response strategy chosen

FIGURE 43: Risk Response and Project Funding Implications

Risk Response Planning – An example

The following example demonstrates the different risk responses that can be chosen for a given situation:

Below are some suggested risk response actions:

1. Threat (a) can be Accepted Passively and nothing may be done about this – need for security outweighs the issue of staff dissatisfaction.

2. Threat (b) falls into the unacceptable or Avoid response, we need to reduce the impact. We can implement an alternative security access mechanism working at all times to double up in case of any failures. If the “bio-metric” device fails we switch over to the alternative – this is a Contingent action i.e it is invoked after a Risk event has occurred.

3. Threat (c) falls into the Mitigate\Avoid category where we need to focus on both preventing the Risk (i.e reduce the probability of the event) and Impact (financial reputation loss).

We can install a parallel security access system independent to the bio-metric system. Both need to pass for any access permission to be given. This reduces probability of the risk.

We can also use a Transfer strategy by insuring the contents of the research facility against information or material loss to counter Threat (c) – reduces the impact of this Threat.

Note that by taking these Risk Response actions there is either an impact on other risks or secondary risks arise

Risk due to threat (a) may now increase since staff dissatisfaction is likely to be higher. They are expected to use 2 access systems instead of one. This could require a Response to move from “Accept Passively” to “Accept Actively”, for example prepare training programs explaining why this is being done and provide these as needed.

There is a risk the insurance company does not pay in the instance of loss or there are protracted legal issues – we could consider this to be low and “Accept Passively”

At this point since no other risk remain that are not contained our risk responses are complete.

Key Outputs from Risk Response Planning

The key outputs from Risk Response planning include:

Risk Register updates – with the appropriate risk response

Project Management plan updates occur as response actions are added through change control

Risk related contractual agreements such as ones for Insurance, Contractors, Suppliers specifying each party’s responsibilities and risk ownership.

H U M A N R E S O U R C E S P L A N N I N G

Human Resources Planning

In the Estimate Activity Resources process you looked at the Activity List and Activity Attributes to come up with resource requirements for performing each of those activities. You documented this in the Activity Resources Requirements. In the Develop Human Resources plan process you would be reviewing these resource requirements and would document a plan on how you would go about acquiring the skills required and optimally staffing your project. You would also be documenting the roles, responsibilities and reporting relationships. The activity resource requirement is therefore a key input to the Develop Human Resources Plan process.

Your organization may have policies on how to acquire people and what roles are appropriate for your organization. These policies would greatly influence your plan. Your experience on previous projects and historical information available from your organizations process asset repository – which provides lesson on successful project organization structures – will help you plan your human resources requirements better. Your organizations process assets is also an input to the development of the Human resources plan for your project.

Enterprise environment factors also influence development of human resources plan. For example, the market conditions may be fluid with high attrition rates. You would need to build in redundancies in your organization structure to mitigate the impact of resources leaving in the middle of the project. Enterprise Environment Factors are also key inputs to developing the human resources plan.

Tools & techniques for HR Planning

Several tools and techniques exist to determine the optimal staffing levels for a project team. One method is to develop an organization chart - at this time you will have just the boxes and the relationships between the boxes. The idea is to come up with a structure such that each and every work package defined in the WBS has a clear owner. It is also important to develop descriptions for each of the position in your team. Other formats of doing the same thing include:

RACI chart: This chart is a matrix that has work packages or activities on one dimension and role assignment on another. Role assignments could be “Responsible”,

Chapter

H U M A N R E S O U R C E P L A N N I N G

“Accountable”, “Information” and “Consultative”. You need to ensure you hold only one person accountable for an activity. Responsibility-Assignment Matrix (RAM) is a similar matrix that states that references team members and work-packages.

Text-oriented: This is a textual representation of the roles and responsibilities along with positional description.

Networking is a very good way of keeping yourself abreast of what is happening in the market with regards to resourcing. Networking with peer project managers in your organization, social or informal meetings with project managers and experts from the industry and well as formal meetings and conferences will help you increase your awareness and understanding of staffing management options.

Knowledge of Organization Theory will help you understand how teams work together and this in turn will help you define an optimal structure for your project. You will learn more about Organization Theory in the Develop Project Team process.

HR Planning - Outputs

A human resources plan is the main and only output of this process. It must, at the minimum, contain the project organization chart as well as the roles and responsibilities for each category of staff. Staffing Management Plan is a key constituent of the HR plan. A typical Staffing Management Plan contains:

Staff acquisition plan

Training needs for staff

Criteria for rewards and recognition, and

Staff release plan

1. What is the difference between a RACI chart and a RAM?

Both RACI and RAM are used to reference work packages and responsibility. RAM is a matrix that shows primary and secondary responsibilities. RACI describes the role assignment a bit more clearly that the RAM. FIGURE 44 shows a sample RAM and RACI matrix. Please note that at the time of HR planning you will not have names of your team members – so the RAM and RACI matrix will have only roles or designations.

FIGURE 44: RAM and RACI

H U M A N R E S O U R C E P L A N N I N G

Practice Questions

Q U A L I T Y P L A N N I N G

Quality Planning

Quality is defined as conformance to requirements. Quality is achieved when a product or a service completely meets – not exceeds - a customer’s requirements. Exceeding the customer expectations is commonly referred to as Gold Plating and is undesirable in projects. Quality has also been defined as fitness to use. An product or service is fit for use if

It meets all the end-users’ functional and non-functional requirements (scope

baseline)

It is affordable i.e. within the cost expectation of the end-users (cost baseline)

It is available on time (schedule baseline)

Impact of Poor Quality

Poor quality always results in lower customer satisfaction, higher rework, lower productivity and increased costs. It may also result in low morale of staff producing as well as using the product.

Benefits of meeting quality requirements include increased customer satisfaction, lower costs and lower probability of cost increases, increased productivity.

Inputs to Quality Planning

You and your project team would need to perform the planned activities in order to meet the requirements; however, uncertain events may impact quality of the product or service. You would therefore need to review the risk register to understand the impact of risks on quality of the product or service. Stakeholder Register is also to be reviewed because it may contain information of stakeholders that may have a particular interest on quality of the projects product. The project manager has the ultimate responsibility for the quality of the product or service. However, each team member is responsible for quality of his/her work.

Chapter

The key inputs for quality planning are the Scope Baseline, Cost Baseline, Schedule Baseline, Stakeholder Register and Risk Register. Other inputs are Organization

Process Assets (such as your organizations quality policies, processes and procedures) and enterprise environment factors.

Quality Planning Tools & Techniques

Tools and techniques described below will help you define quality standards for your project.

Benefit/Cost Analysis

Cost benefit analysis is a powerful tool for planning. Project Managers use this to make rational decisions on implementing change to an existing system. This tool involves measuring the value of the benefits of implementing a change, and subtracting the costs of implementing the change.

Benchmarking

It is a process of comparing previous similar activities to the current project activities and to provide a measure of quality performance.

Design of Experiments

This is a statistical technique that identifies the variables that will have the greatest effect on the project outcomes.

Cost of Quality

The cost of quality is the total cost to produce the product or service according to the quality standards. It includes:

Prevention costs – these are costs associated with satisfying customer requirements by producing a product or service without defects. Costs expended on activities such as Quality planning, Design reviews, Education and training of stakeholders are examples of prevention costs.

Appraisal costs – these are costs associated with examination of the product or process and making sure that the customer requirements are being met. Costs expended on activities such as inspection or testing are examples of appraisal costs.

Failure Costs – these are costs associated with fixing issues in the product or process. These are of two types – internal and external.

Internal failure costs occur when customer requirements are not satisfied while the product is still in the control of the organization. Costs resulting due to rework and scrapping are result of internal failures. External failure costs

result when the product reaches the customer and the customer then determines that the product does not meet their requirements. Product returns, inspection and repair at customer site are results of external failure costs.

Statistical Sampling

Statistical sampling involves performing some checks on randomly selected items produced by the project. While the actual execution is carried out as quality control processes, as far as quality planning is concerned you would determine sampling parameters such as sample size, variable of measurement and frequency of measurement.

Control Charts

A control chart is a time-phased representation of a process. It helps you determine if the project’s process is in control or if it requires attention. You must note that every process has variation – some variations require attention, some do not. A control chart has the following components:

It has a horizontal line – the X Axis - that identifies the time scale

It has a vertical line – the Y Axis - that identifies the scale of measurement for the variable of interest.

It has a horizontal center line (“centerline”) that corresponds to the mean of the process

In addition to these, a control chart also has two horizontal lines called the upper control limit and the lower control limit. These horizontal lines are equidistant from the centerline – the upper control limit being above the centerline and the lower control limit below the centerline. The control limits are 3 standard deviations away from the centerline

In quality planning you will not have the data to determine the mean, upper and lower control limits. You would need to specify how you would use control charts to plan quality.

Flow Charting

Flow charts, or process flow diagrams, are used to understand a process by documenting its steps. Understanding a process is essential for quality improvement since you must understand a process before you can control it. By documenting the entire process, flow charts can help teams identify areas in the process in which improvements can be made.

Proprietary quality management methodologies such as the Six Sigma, Quality

Function Deployment and CMMi can also be used for planning. Other quality planning tools include Brainstorming, Affinity Diagram, Force Field Analysis and Nominal

Group Techniques.

Outputs of Quality Planning

The quality management plan is a key output of the quality plan process. It describes what standards your project would implement, what quality tools and techniques would be used and how.

Quality metrics that define the attributes of the project’s product is also an output of the quality plan process. Metrics can also describe the overall project quality.

In order to ensure your project implements the defined standards you would need to prepare checklists. Checklists are structured tools used to verify that a set of planned steps/procedures have been carried out and would be used in the quality control process.

Practice Questions

P L A N C O M M U N I C A T I O N S

Plan Communications

Plan Communications is part of the Planning Process Group and the Project Communications Management Knowledge Area

Large projects have many stakeholders and it is important you keep all of them informed about the status of the project. A clear communications plan is vital in successfully managing a project. The primary purpose of this process is to plan communications related activities and document it.

In the Identify Stakeholder process you developed a Stakeholder Register and a Stakeholder Management Strategy. In the Plan Communications process you will use these documents to decide on who to send what information, in what detail and how frequently. This process helps you keep your stakeholders informed and also helps you communicate a consistent message to your target audience.

The Stakeholder Register, Stakeholder Management Strategy, Organization

Process Assets and Enterprise Environment Factors are inputs to planning communications for your project. These inputs have been discussed in detail in the earlier chapters.

Plan Communications – Tools & Techniques

You need to analyze your stakeholders’ communication requirements. You can review the organization charts of the requesting organization, key stakeholder responsibilities and relationships and the stakeholder management strategy document you prepared in the Identify Stakeholders process to analyze your stakeholder’s communications requirements.

Global locations, distributed teams and distributed stakeholders mean that you would have to rely to communication technology to keep in constant touch with your stakeholders. Sophistication and investment in technology would depend on several factors such as urgency (if you don’t communicate immediate you run the risk of project failure), availability (the customer organization does not have a video conferencing facility and though you have it in your office you can’t use it) and project

Chapter

environment (does your type of project require online demonstration of the product every time you meet?)

Face-to-face meeting is an excellent means of communicating information to your stakeholders. However when your stakeholders are located in different parts of the world it is impossible to have face-to-face meeting every now and then. In such situations you would have to rely on communication technology. Holding electronic meetings (i.e. telephone, chats etc.) have its own advantages (i.e. costs) and challenges /limitations (i.e. inability to elicit information through body language etc.). As a project manager you need to understand the basics of communications models. You as a sender are responsible for making sure your stakeholders (receivers) have understood the information. Receivers (your stakeholders) are responsible for understanding and acknowledging the receipt of information. You must also be aware of the noise in the communication processes. Noise is a term that is used to describe barriers in communication that may destroy information.

There are several communication methods that you may use to share information with your stakeholders. These are:

Push Communications: This is a method that you use to send required information to stakeholders. This includes emails, memos, voice mails, faxes etc.

Pull Communications: This method is used for large volumes of information or for large amount of recipients. This includes intranet sites such as your project SharePoint portal, knowledge repositories etc.

Interactive Communications: While the above two methods are one-way, these types of communication involve parties performing multi-directional exchange of information. This includes tele-conferencing, video conferencing, meeting etc.

Plan Communications – Outputs

A Communications Plan is an output of the Plan Communications process. The Communications Plan outlines who should communicate with whom and how often. A communication matrix, which is part of a typical Communications Plan, is as shown in FIGURE 45. Other inputs are project document updates.

FIGURE 45: Communications Plan

1. What amount of time does a project manager spend in communications?

Roughly about 80% of the project manager’s time is spent in communications. This includes reading and compiling emails, collecting data, preparing status reports, conducting meetings, managing relationships with stakeholders etc.

2. What is a communication channel?

Communication channel is a means of communication. The channels increase exponentially as the number of stakeholders. The number of communication channels (c) in a project can be determined by the following formula.

Where n is the number of stakeholders.

3. Your team has 5 members. Two new members are added to your team. What is the change in number of communication channels?

Using the formula above, we can find the number of communications channels in a team of 5 which is 10.

The team size becomes 7 when 2 new members get added. The number of communication channels, using the formula above, is 21. The difference in number of communication channels is 21-10 = + 11

Practice Questions

P L A N P R O C U R E M E N T

Plan Procurement

Plan Procurement is part of the Planning Process Group and the Project Procurement Management Knowledge Area

The term procurement refers to obtaining products, services, materials or any other resources from outside the performing organization. The Plan Procurement process deals with documenting procurement related decisions of acquiring outside support for your project including identifying potential sellers.

Inputs to this process are:

Scope Baseline – This includes a detailed description of the product or service that needs to be procured along with acceptance criteria

Requirements Documentation – The requirements document contains functional as well as non-functional requirements that need to be mapped on to the product or service that is to be procured.

Teaming Agreements – When two or more parties are working together on a project (say a joint venture) the contract between the parties defines the roles of a seller and buyer. The contract significantly impacts the planning process and therefore is a key input to this process.

Risk Register – The risk register contains risks identified with the procurement work.

Risk-related Contract Decisions – These are in response to the identified risks and include things such as procuring insurance, hedging funds to mitigate risk of currency fluctuations etc.

Activity Resource Requirements – This identifies people, type of people and numbers required on the procurement work

Project Schedule – Contains information on dates by which the required deliverables are needed.

Activity Cost Estimates -

Chapter

Cost Performance Baseline – Planned budget for procurement related work

Enterprise Environment Factors and Organization Process Assets are also inputs to this process.

Plan Procurement – Tools & Techniques

Make or Buy Analysis is a technique that is used to decide if a product or service can be built internally or it is best to procure it from external sources. Factors that influence a make-or-buy decision include budget, availability of skills and time constraints.

In a situation where you decide to procure the product or service from external sources you will need to decide on the type of contract to award. Decision on type of contract is driven by several factors such as clarity of the requirements, availability of vendor options and of course time and schedule constraints.

Fixed Price Contract: This type of contract is one in which the buyer agrees to pay the seller a fixed amount of money on completion of the agreed work. This type of contract is preferred when the work is not very specialized, requirements are very well defined and many vendors have the capability to provide the required service. Since the amount is fixed the seller has to bear the risk of costs exceeding the contract amount.

Variants of this type of contract are:

Fixed-price Plus Incentive Fee: While the contract has a fixed amount the buyer may provide financial incentives over the fixed amount in order to get the work done faster and better. Criteria or a formula to calculate the incentive amount is worked out and the incentive amount is actually calculated at the end of the project based on criteria.

Firm Fixed Price: This is the most common type of contract preferred by the buyers. The price of contract is set and is not subject to changes unless the scope changes.

Fixed Price with Economic Price Adjustment: These contracts are appropriate for projects that span several years. This is a fixed price contract; however, the final price is determined by changes to economic conditions such as increase in inflation, interest rates, changes to foreign currency exchange rates etc.

Cost Reimbursable Contract: This type of a contract involves the buyer paying the seller costs at actuals for the amount of work completed. In addition a fee (representing seller profit) is also given on completion of the project. In these types of contracts the buyer has more risk since the price of the project is not known upfront. Variants of this type of contract are:

Cost plus Fixed Fee: Actual costs are paid to the seller for the amount of work completed. A fixed fee is paid on completion of the project.

Cost plus Incentive Fee: Actual costs are paid to the seller for the amount of work completed. A predetermined incentive fee is also given to the seller and is determined based on how much lower the final costs are from the original project estimates.

Cost plus Award Fee: While all legitimate costs are paid to the seller on actuals, a higher proportion of amount if awarded to the seller based on the project performance and meeting established project criteria.

Time & Material Contract: This is a hybrid arrangement that has characteristics of fixed price as well as cost reimbursable contracts. These are used usually when the statement of work cannot be clearly defined. This type of contract is used to hire consultants and outsourcing of lower end work. In these types of contracts the unit labor costs and material costs are preset.

Expert Judgment is also one of the tools to assess the inputs and outputs of the procurement planning process. Legal, technical and other specialist are often used to develop proposal evaluation criteria and for other services related to the procurement planning area.

Procurement Planning – Outputs

Procurement Management Plan is one of the key outputs of this process. A procurement management plan, amongst others, contains:

Types of contracts that would be awarded

Process of make-buy decision making

Issues related to risks with procurement of the service in question

Scope and brief of the project management team

Process of managing multiple suppliers

Constraints and assumptions

Procurement Statement of Work is a procurement document that is prepared using the scope baseline of the entire project. This document must clearly state the portion of work to be done by the contractor. Any other collateral service required such as support for post project delivery etc. must also be stated in this document.

Key decisions leading to procuring the services from an outside agency must be documented. This document must clearly provide details of the make-buy decision.

Procurement documents required to solicit information from prospective vendors/suppliers is also a key output of this process. Documents such as Request for Proposal (RFP), Request for Bid (RFB) etc. may be used to solicit information from suppliers.

Source Selection Criteria is a key constituent of procurement documents. These criteria are used to evaluate proposals sent in by prospective vendors. A scoring model such as the one we saw in FIGURE 11 (Page 23) can be used to evaluate the proposals. Some criteria for evaluation of vendors could be

1. Technical capability and proof of work done for other customers

2. Management approach

3. Size of vendor’s business in terms of revenue and number of staff

4. Number of years in existence

5. Past performance

6. References provided by vendor

Any changes to the procurement process must be documented and raised as a change

request that must be put forward to the CCB for approval, and actioned based on recommendations of the CCB.

Practice Questions

D E V E L O P P R O J E C T M A N A G E M E N T P L A N

Develop Project Management Plan

In the previous section you planned your project work and documented your ideas in the project

Chapter

D E V E L O P P R O J E C T M A N A G E M E N T P L A N

Executing Processes

D I R E C T A N D M A N A G E E X E C U T I O N

Direct and Manage Execution

In the previous section you planned your project work and documented your ideas in the project management plan. In this section you will need to start putting those ideas to work i.e., get your team to perform the work defined in the project management plan. In addition to this you would also get change requests. This process helps you integrating the work involving approved change requests to the project.

Directing Execution

Direct and Manage Project Execution can be considered to be the master process for all other execution processes. In this process you transform the plan by executing activities, and generate the final output/deliverable. As a project manager you start execution by acquiring resources, training them if required, committing and authorizing them to work on activities and tasks defined in your Project Management Plan. You will need to interact with suppliers and vendors and procure resources for your project. You will need to oversee implementation of standards and establish communication channels with your stakeholders.

As you and your team perform the defined work you start expending money and generating output. Your stakeholders, more so the sponsor would want to know the status of accomplishment of the project. As the project manager it is your responsibility to keep track of not just utilization of resources but also the amount of money you are spending to accomplish the defined work. In this phase of the project your job as a project manager will involve more of overseeing progress of the project, collecting project performance data and reporting progress to stakeholders.

Managing Execution

Not many projects are executed as per plan. Things go wrong during execution – some of the resources may not join your project on time, or the vendor may not supply the required material as planned, or an activity planned for completion may be delayed for some reason. As the project manager you are responsible for taking corrective actions and getting the project back on track. Corrective actions may involve making changes to the project scope, schedule, budget, resourcing or any other factor that will put the project back on track. You may also have to take some preventive actions to avoid recurrence of undesirable events on the project. Preventive actions usually involve making changes to the project policies, processes or procedures. In some cases the

Chapter

output generated by your team may not fully meet the functional requirements as requested by the customer. In such cases you will need to get your team to rework on the defective output and fix it.

Executing corrective actions, preventive actions and defect repair activities may, in most cases, require a Change Request and must, therefore, be done post its approval.

As seen from the discussion above, the Project Management Plan and Approved Change Requests are key inputs to the Direct and Manage Execution process. Other inputs are Enterprise Environment Factors and Organization Process Assets.

Direct & Manage Execution - Tools & Techniques

Expert Judgment or opinion must be sought if you want to assess the inputs needed to execute the project plan. Expert advice can be sought from peer project managers, consultants, professional bodies etc.

During execution you would rely a lot on automated project management / scheduling software – referred to in the PMBOK® Guide as Project Management Information

System (PMIS). This is part of the Enterprise Environmental Factors and is also one of the tools to direct and manage project execution.

Outputs of Direct & Manage Execution

As discussed earlier, in the Direct and Manage Project Execution process you execute the project management plan and produce deliverables. By definition of project, a deliverable is a unique product or service. Once all deliverables of a phase or project are approved by stakeholders the phase or project is considered complete.

Final deliverables are not the only things that would be of interest to stakeholders. During execution you will need to retrieve data from the project management information system, process it and distribute it to stakeholders. The information you send to stakeholders may include status of deliverables and the overall project, costs incurred and progress on schedule. You may also need to send information, with a certain degree of confidence, forecasting the expected completion date of the project/deliverables and expected costs at completion. You may also need to send information that key stakeholders demand during the execution of the project. This package of information is referred to as work performance information. A sample report (without forecast information) is shown in FIGURE 46.

FIGURE 46: Work Performance Information

Changes or change requests are inevitable on any project. As your team executes the work you will come across changes that have been requested by stakeholders as well as sources external to the project (government regulations etc.). Changes can be dictated because of advancement in technology as well. It is incorrect to accept a change and ask your team to implement it. FIGURE 47 shows a sample change request.

FIGURE 47: Sample Change Request

The right thing to do is to analyze each and every change, study its impact on the project (impact on schedule, cost and quality at a minimum) and present it to a group that is responsible for making a decision on implementing the change in the project. This group is referred to commonly as the Change Control Board (CCB) and its members consist of key stakeholders including you, the project manager. The project can implement only those changes that are approved by the CCB.

Acceptance of a change request by the CCB will require you to update the project

management plan and/or other project document such as requirements document, risk register, issue log etc. The updates to the project management plan and the project documents are also output of this process

1. What is a deliverable?

A deliverable is a unique verifiable product, result or outcome that must be developed to consider a project or its phase complete.

2. Do I need to raise a change request to repair a defect?

A change request must be raised to change or update any component of the project that is baselined. If a defect is documented in a delivered component of the project you must raise a change request. If the work is in process you need not raise a change request

3. What are some of the documents that help you and your key stakeholders have a common understanding of the project

Common understanding means that all key stakeholders of the project are on the same page as far as the project objectives are concerned. Some of the documents produced that reinforce this common understanding are the Scope Statement, WBS & WBS Dictionary, Project Schedule and the Project Management Plan.

Practice Questions

1. You are a project manager on Project X that is currently in execution. Your customer asks you to add a small new feature to the projects product. You know that the addition will not change the schedule but will increase the cost. What is the correct thing to do?

a) Inform the team and get the new feature added in the scope

b) Discuss with your senior manager

c) Ask the customer to submit a change request that will be looked into by the CCB

d) Tell the customer that the new feature can be added in the next phase of the project.

2. Inputs to the Direct and Manage Execution process are all of the following EXCEPT:

a) Approved change requests

b) Change requests

c) Organization process assets

d) Enterprise environment factors

3. Outputs of the Direct and Manage Execution process are all of the following EXCEPT:

a) Approved change requests

b) Change requests

c) Project Management Plan updates

d) Project Document updates

1 c Any changes to the project scope that has an impact on the cost or schedule must be reviewed by the CCB

2 b Change requests must be approved before being implemented on a project.

3 a Approved change requests are inputs

A C Q U I R E P R O J E C T T E A M

Acquire Project Team

In the Develop Human Resources Plan process you created a human resources plan (part of the Project Management Plan) in which you documented your project’s staffing needs. The Acquire Project Team process deals with obtaining the human resources necessary for your project and in this process you would be executing this plan. You must note that this process is part of the executing process group. This, however, does not mean that you obtain resources after the completion of the planning process group. You would have already got critical resources on your project much earlier to work on planning the project. In this process we deal with acquiring people that we would need to execute the project work. For example, on an IT project you would acquire developers and testers. The project management plan is a key input to this process. Other inputs are:

Enterprise Environment Factors: You will need information about who is available to work on your project, what skills they possess, their costs etc.

Organization Process Assets: These are staffing policies in your organization that you need to work with while acquiring people for your project.

Tools and Techniques to Acquire Project Team

In a matrix organization it would be relatively difficult to obtain internal resources. You would need to negotiate with, and influence functional managers, peer project managers and senior managers that are in a position of authority to provide the resources for your project.

In situations where resources are to be obtained from outside the organization you must be able to negotiate effectively with vendors and suppliers of human resources. This is called Acquisition. You may hire full-time staff or contractors depending on your plan.

In some cases your senior manager would have proposed staffing a prospective project with “named” people. If a project is initiated as a result of that competitive bid then those “named” people must be made available to the project. The names of such

Chapter

people are already indicated in the Project Charter. This is called Pre-Assignment and is one of the techniques of acquiring human resources to a project.

Traditionally projects have been executed with all team members co-located. However, the advent of technology and an increasingly global nature of projects have created possibilities of a global project team. Virtual teams are groups of people that are located in different parts of the globe. While the team members share the goals and responsibilities of the project they spend very little time face-to-face. Most interactions happen electronically (emails/chats) or over the phone or via video conference. Communications becomes even more important in situations where virtual teams exist. Availability of technology makes it possible for you to acquire virtual team members.

Outputs of Acquire Project Team

Staffing is considered complete when all identified roles on your project are assigned to the people you just acquired using tools and techniques that we just described. It is quite important that you document these project staff assignments. The organization structure in the project management plan is the best place for such documentation. You must also provide a team member an Assignment Brief which is a document that contains all mutually agreed goals and objectives to be achieved during the course of the project. Later in the Manage Project Team process you would be using this assignment brief as a basis to perform and document the appraisal or the actual performance of the individual team member.

It is also important that you document the availability of your resources. In other words some of your team members may have planned their holidays, some others may be shared between your team and another. Once you have determined the resources that would be working on your project you need to quickly develop a project resource

calendar indicating the availability of your resources for an appreciable period of your project duration.

In some case you may not get the required resources as planned. You may get resources that may not be an exact fit on your project but nevertheless they would be suitable for your project with a bit of training. You must update the project plan with this information.

1. As a Project Manager what would you do immediately after you have identified the resources for your project?

Once you have identified the resources for your project you need to confirm their availability and develop a resource calendar.

2. What does the term “Acquisition” mean?

The term “Acquisition” in the context of Acquire Human Resources process means acquiring people from outside the organization.

3. 10% of your team members work out of another building that is about 2 kms from where you and the rest of the team work. Do you consider that part of the team to be a virtual team?

Teams are virtual teams when they are not co-located. Instead of meeting in person they use the phone or electronic means such as chats, video conferences etc. If the team collaborates online and not face-to-face it could be considered a virtual team. Team members working in different shifts are also considered virtual team members.

Practice Questions

1. You are a project manager in a matrix organization. Who would negotiate with for additional resources?

a) Peer Project Manager

b) Functional Manager

c) Senior Manager

d) Customer

2. The following are outputs of the Acquire Project Team process, EXCEPT

a) Project Management Plan updates

b) Resource Calendars

c) Virtual Teams

d) Project Staff Assignments

3. The first document where Pre-assignments are listed is

a) Project Charter

b) Scope Statement

c) Resource Calendars

d) Project Management Plan

1 b In a matrix organization you would share responsibilities and power with a functional manager

2 c Virtual Teams is an not output

3 a Pre-assignments are first listed in a project charter.

D E V E L O P P R O J E C T T E A M

Develop Project Team

Develop project team process deals with improving the team interaction, increasing staff competencies and improving the overall performance of the team. This process will require you to use your soft skills in motivating, leading and inspiring your staff.

The success of a project depends on how well your team works in cohesion, and getting the team working together is one of your primary responsibilities as a project manager. As your team performs work you must continuously motivate them, provide instantaneous feedback and recognize and reward great performance.

Inputs required to develop your team include project staff assignments, resource

calendars and the project management plan. We discussed these in detail in the previous processes.

Tools for developing your project team

As discussed earlier this process requires you to use soft skills or interpersonal skills to help develop the project team. Key tools amongst these are:

Conflict Resolution

Motivation

Team Building

Leadership

Ability to influence

Conflict Resolution

Conflict is a clash of interest between two parties (eg. team members) and can significantly reduce team productivity. Conflicts can occur because of scarce resources, priorities between competing activities or schedules. It can also occur because of personalities or disagreement on technical solutions. There are techniques to resolve conflicts and you must be aware of these techniques.

Chapter

Motivating your team

It is important that you create a team environment that is conducive to all team members to perform and give their best. There are different theories to motivate your team and create a good working environment

Maslow’s Theory of Needs: The philosophy is all people have needs. These needs can be categorized into 5 levels. People start thinking of upper levels when the need at the level they are currently is completely met.

Herzberg’s Hygiene Theory: This theory states that there are two factors – hygiene factors and motivating factors. Hygiene factors are like good working environment, good working relationship with team members and boss etc. Absence of these factors in a workplace could, however, be de-motivating. Motivating factors include things like promotions, rewards etc. People will not care about motivating factors if hygiene factors are not satisfied in their workplace.

McGregor’s X & Y theory: McGregor’s theory states that there are two types of supervisors – one that believes that team members are responsible and are mature enough to get their work completed on time (Theory Y), and another that believes team members are lazy and cannot be trusted and that they need to be driven to complete their work on time.

Building a team

You acquire individuals to staff your team. Success of the project depends to a great extent on how you get these individuals to work together in a team environment. Getting to a stage where a team that is working together efficiently does not happen by chance and requires you to do a lot of work referred to as team building. Each team undergoes 4 stages of development as described below:

Forming: This is the first stage. Resources, on joining your team will try and find out their exact roles in the team. At this stage they will tend to work almost independently at times trying to work with a few of their colleagues.

Storming: This is the second stage. Team members would still work individually and will try and form opinions on team members. This is a stage where team members would have dis-agreements would each other on how to execute the project.

Norming: This is a stage where individuals being to trust team members and start working with others by making small adjustments to their work habits. They are still not performing at their peak.

Performing: This is the best stage to be in. All team members are working together to meet the project objectives. Each team member understands the others’ strength and weaknesses as well as their own roles clearly.

Adjourning: The project team completes the assigned work and moves on to the resource pool awaiting re-assignment to another project.

Ground Rules are project level “policies” or expectations established to maintain acceptable level of behavior by project team members. The objectives of establishing such ground rules are to prevent misunderstandings amongst team members and prevent conflicts which in turn results in enhancing team productivity.

Face-to-face interaction between team members is best when it comes to enhancing communications. These interactions are possible only when the entire team is co-

located. Interactions between team members on the corridor or around the coffee table can increase communications and prevent misunderstandings.

While compiling the Human Resources plan you documented the criteria for rewarding project team members. In this process you will be implementing the plan. While instantaneous (or on-the-spot) rewards are the best recognizing and rewarding team members during a town hall will have a greater impact on your team’s productivity.

Outputs of Develop Project Team

One of the outputs of this process is the Team Performance Assessment. The project management team (or the steering committee) evaluates the effectiveness of the team that has been put together for the project and also the probability of achieving the project objectives. The formal evaluation report will help you put together a plan for training your team members and putting in place changes that would increase the effectiveness of your team in general.

Employee training records and formal reports on evaluation of skills, that are part of the Enterprise Environmental Factors, are updated during this process

1. Would you reward a project team member for working overtime?

It is a good practice to reward a team member who works overtime in order to meet an aggressive schedule. However, it would not be a great idea to reward a team member who is working overtime due to inefficiencies in work practice and lack of self-management.

2. You know about the different team building stages. Do they occur in the order of Forming-Storming-Norming-Performing?

Usually, yes. These stages of team building do occur in order. However, in it not uncommon for a team to be at, say the Storming stage, for a long

period of time. It is also possible that a team behavior regresses. A team can slip from say a norming stage to a storming stage.

Practice Questions

1. Two developers are in a verbal duel over project estimates. One of the developers walks out of the meeting angrily. What conflict management technique has just been observed?

a) Smoothing

b) Avoidance

c) Forcing

d) Confronting

2. Which of the following is NOT a motivating agent?

a) Recognition

b) Professional Growth

c) Working Conditions

d) Additional Responsibilities

3. A team member is not performing well on your project. You would like to communicate one of the following messages to him. Which of the following is the worst choice?

a) I will nominate you to attend the next conference at Agra

b) I will not invite you to the lunch meeting with the customer

c) I will give additional responsibilities

d) I will approve your leave that you asked me for this morning

1 b Not opening a communication channel for conflict resolution is a bad thing. Avoidance is also known as Withdrawal.

2 c Working conditions is a hygiene factor. Others are motivating agents.

3 b This is a penalty. Penalty power is the worst of the lot and must be used only in exceptional circumstances. You will learn more about powers in the “Manage Team” chapter.

M A N A G E P R O J E C T T E A M

Manage Project Team

Manage Project Team is part of the Execution Process Group and the Project Human Resources Management Knowledge Area

Manage Project Team process follows the Acquire Project Team & Develop Project Team processes. This process involves reviewing individual performances of team members, providing them constructive feedback and resolving outstanding issues. The following are inputs to this process:

Staff Assignments - provides list of staff assigned to your project

Project Management Plan

Organization Process Assets -provides templates for performance appraisals as well as contains policies and procedures

Performance Reports-provides a comparison of plan versus actuals for all project deliverables

Yet another input to this process is the Team Performance Assessment, an assessment of the project performance carried out by the Project Steering Committee containing the project manager, sponsor and other key stakeholders. We saw this in the previous chapter.

Tools and Techniques for Managing Team

As part of this process you would prepare, document and deliver performance appraisals for your team members. You would have observed the behavior of your team members during the course of the project. These observations are recorded in an individual’s appraisal or performance document (also called Assignment Brief in some organizations). It is important you obtain feedback of the performance of the individual in question from a random cross section of stakeholders. Conversation is a common way to obtain such feedback. The feedback obtained must also be recorded in the appraisal document. The consolidated feedback is delivered to individual team members. It is a normal practice for project managers to schedule delivery of

Chapter

performance appraisals (also called Assignment De-brief in some organizations). The objective of documenting and delivering performance appraisal is to help team members identify their strengths and areas of development. The team member gets an opportunity to document future training needs and growth plans while the project manager gets an opportunity to clearly understand ongoing conflicts and confirm roles and responsibilities.

During the course of project execution several conflicts arise – most of those would be over schedules or resources. Some of the conflict management techniques that you must be aware of are:

Confronting: This is also referred to as collaborating or win-win. This involves dealing with the conflict head-on and works out a solution that completely fixes the problems of everyone involved in the conflict. This is the best conflict resolution technique.

Compromise: In this technique the conflict is resolved with each party giving up something. This means that both the parties are not fully satisfied with the outcome while the conflict is temporarily resolved.

Forcing: This is also referred to as win-lose situation. One party forces (or puts her foot down!) a decision and gets the conflict resolved in her favor, the other party loses out. This situation is likely when there is a conflict between people at different levels in the organization or project team.

Smoothing: This occurs when one party in conflict has low concern for self and high concern for the other party. This technique may not really solve the conflict but nevertheless may keep tempers down allowing people to step back and figure out the real cause for the conflict giving them time to think about alternative solutions.

Withdrawal: This is the worst of all techniques. Both parties neither have concern for self nor for the other party. If one party withdraws from the resolution discussions then the resolution is simply not arrived at.

FIGURE 48: Conflict Resolution Techniques

During execution you and your team members would identify issues that may impact your project objectives. You must document the issues in an Issues Log and assign an owner to resolve it. Note that only project related issues must be recorded. Behavioral issues and personal issues must be kept out of it.

A Project Manager has 5 types of power and would need to use it effectively to manage the team. These are:

Formal Power – This power comes with the title/designation of “Project Manager”

Expert Power – A Project Manager is expected to be experienced and knowledgeable in managing people related issues and can be considered an expert when it comes to solving these issues.

Reward Power – A PM can reward team member for performing well on a project. This is the best power that a PM can use to motivate team members.

Referent Power – The PM can use the relationships with his superiors and customers to effectively manage his team members.

Penalty Power – The PM has the power to penalize his staff for not performing well on the project. This is the worst type of power and must be used only if other ideas have not worked.

Interpersonal skills – leadership, ability to influence, decisiveness – will help you manage the skills of your team effectively and thus ensure your team delivers as planned.

Outputs of Manage Project Team

As you resolve conflicts in your team you will identify need to change a few processes that may prevent recurrence of undesirable events. This will need to be raised as change requests which need to be approved by the CCB. Changes can also occur due to movement of your staff. This can result in you having to change your baseline schedule – again something that you can implement only after your change request is approved by the CCB.

Conducting performance appraisals of your staff may help you give more insights into the process. Process or procedural changes to the system of performance appraisal could be considered as your Organization’s Process Asset updates.

Performance appraisals also give you an opportunity to update the skills database – this is an update to the Enterprise Environmental Factors.

The Project Management Plan may also need to be updated should there be any staff movements from your project during the course of project execution.

1. What are the common causes of project conflict?

The common reasons for conflict on project teams are:

Project Schedules

Priorities

Resources, including availability of human resources

Technical approach to solving a given problem

Ego and personality

2. Two of your team members have differences in opinion. As their project manager what should you do?

Initially you must encourage your team members to resolve the issues themselves. However, if the issue escalates, you must get involved and facilitate a satisfactory resolution.

Practice Questions

1. Team members always listen to the Team Lead because he has the ability to solve any technical problems. Which type of power is being observed?

a) Referent

b) Expert

c) Formal

d) Reward

2. A conflict has divided a project team into two groups, one that says code review must follow coding and another that says these activities must be done in parallel. The PM advises that while code reviews are mandatory he would not bother if it is done in parallel or after coding. What conflict resolution technique has been observed?

a) Forcing

b) Confronting

c) Compromising

d) Smoothing

3. A new recruit just out of college is not performing to expectations. What should you do as his manager?

a) Consult with customer and see if he can be exited

b) Consult with Senior Manager and see if he can be shifted to a non-priority project

c) Arrange for more training

d) Replace him with a more experienced developer

1 b Expert power gained due to experience and knowledge

2 c This is compromising behavior

3 c This is the best thing to do. Don’t always consult with senior manager and customers on problems you can solve

D I S T R I B U T E I N F O R M A T I O N

Distribute Information

Distribute Information is part of the Execution Process Group and the Project Communications Management Knowledge Area

Distributing Information is a process that deals with getting the required information to your stakeholders in a regular and timely manner. The Communications Management Plan (which is now part of the Project Management Plan) you developed in the Planning processes states the information you planned to make available to your stakeholder. As the project progresses you will need to execute the activities stated in the communications management plan.

Information you need to distribute relates to the project performance. It should not just include current information such as percentage of project deliverables complete till date but also include forecasts such as Estimates to Complete and Budget at Completion. Inputs you need to get this information are available from the Performance Reports.

Organization Process Assets are also inputs to this process. These include templates required to prepare status reports, lessons learnt on distribution of information from previous projects etc.

Distribute Information – Tools & Techniques

While planning communications for your project you identified the methods you would be using to distribute the information. We discussed different communication

methods – Push Communication, Pull Communication and Interactive Communication - in the Plan Communications process. You would have to use one of these communication methods to distribute information to your stakeholders. There are different ways of getting your message across to your stakeholders. FIGURE 49 shows examples of a few methods of formal-informal & verbal-written communications.

Chapter

FIGURE 49: Communication Methods

You can distribute the information to your stakeholders using variety of distribution

formats (referred to in PMBOK® as Distribution Tools) such as hard-copy, soft-copy/electronic format etc.

Distribute Information - Outputs

While executing the project you and your team would have acquired more knowledge – both of processes as well as in the product/domain. It is important that you and your team members update the organization’s process repository. This could be in form of notifications you may have sent to your customers as well as their response, if any. The submissions to the repository could also be in form of project reports and presentations and any other documents that could be of value to future project managers.

Practice Questions

M A N A G E S T A K H O L D E R E X P E C T A T I O N S

Manage Stakeholder Expectations

Manage Stakeholder Expectations is part of the Execution Process Group and the Project Communications Management Knowledge Area

Manage Stakeholder Expectation process is concerned about working with stakeholders to understand and meet their needs and addressing their issues as and when they occur. This process heavily relies on communication activities as well as the interpersonal skills of the project manager. This process requires the project manager to:

help increase the probability of acceptance of the project deliverables by the requesting organization

anticipate concerns that could become issues, and addressing those well in time

You as the project manager would be overall responsible for managing stakeholder expectations. Inputs to this process are:

Stakeholder Register

Stakeholder Management Strategy

Issues Log

Change Log

Each of these inputs has been discussed earlier in this book.

Chapter

M A N A G E S T A K E H O L D E R E X P E C T A T I O N S

Manage Stakeholder Expectations – Tools &

Techniques

As discussed earlier this process heavily relies on the communication as well as the interpersonal skills of the project manager. Interpersonal skills include:

Active listening: This is a communication technique in which you listen and make notes on whatever the speaker is talking about, and then providing feedback – or responding – to the speaker.

Resolving conflicts – Standard techniques are available that could help you resolve conflicts with stakeholders. Best amongst the techniques is confronting or collaborating with stakeholders to resolve outstanding issues.

Overcoming resistance to change – This is the most difficult part. People that are emotionally involved in any work would not want to change. The best method is to communicate why the current processes need to change and getting those people themselves involved in the change process.

You would also need to use her General Management Skills in order to manage the stakeholder’s expectations. This includes:

Negotiations

Presentation Skills

Public Speaking skills

Communications Methods – push, pull and interactive – are also used to manage stakeholder expectations.

Manage Stakeholder Expectations – Outputs

As you interact with your stakeholders and implement the communications plan and strategy you may discover new methods of managing stakeholder expectations. You would need to update the stakeholder strategy document with this new information. The communication management plan, which is part of the project

management plan, would also need to be updated.

Organization process updates (update the lessons learnt from managing stakeholder expectations) and Change request are other outputs of this process.

M A N A G E S T A K H O L D E R E X P E C T A T I O N S

1. What are communication blockers?

Projects involve people from several nationalities and cultures. During conversations, project managers and team members often (unknowingly) use statements (slangs) that can cause miscommunication between team members. These can hamper effective communication and are referred to as “blockers”. Conflicts are the most common cause of communication blockers.

2. What project documents are updated as part of this process?

Some of the project documents that may be updated are:

Stakeholder strategy document – you may discover new methods of managing expectations of stakeholders

Stakeholder register – new stakeholders may join and some may leave.

Issues Log – Issues may get resolved, new issues may be raised.

Practice Questions

M A N A G E S T A K E H O L D E R E X P E C T A T I O N S

P E R F O R M Q U A L I T Y A S S U R A N C E

Perform Quality Assurance

Perform Quality Assurance is part of the Execution Process Group and the Project Quality Management Knowledge Area.

In the Plan Quality chapter you saw how you can use quality tools and techniques to identify and set standards for your project. In the Perform Quality Assurance process you and your team would be executing the planned activities in order to meet the set standards. The Perform Quality Assurance process is concerned about improving your project processes. You would not only be applying the tools and techniques you defined in your quality plan but also be auditing your project processes and see if your project has been implementing the defined standards. Inputs you need for this process are:

Project Management Plan – You documented the standards and stated how your project would implement these standards

Work Performance Information – As you project progresses you are your team will collect data that includes such as status of project deliverables, schedule performance, cost performance and any other data that is useful for the project.

Quality Metrics – These are product and project attributes

Quality Control Measurements – These are results of quality control activities such as testing and reviews. Example of measurements could be 15 defects found in the requirement review, 5 in the design review etc.

Perform Quality Assurance Tool and Techniques

Audits are independent reviews performed by people outside your project. They could be internal to the performing organization or external. The purpose of the audit is to:

Measure the degree of compliance or non-compliance to the defined processes

Chapter

Identify best practices in your project and hare them across the performing organization

Provide feedback to the managers of the organization’s process assets

Audits are usually planned and scheduled activities and are important in assuring quality of project outcome.

The quality management plan for your project contains not just what standards your project would follow but also how you and your team would improve the project processes. This is documented as part of the process improvement plan. Process

Analysis is a Quality Assurance tool that you would use to help improve your current process.

In addition to audits and Process Analysis, all the quality planning tools and techniques (and quality control tools & techniques that you would visit in the next section of this book) would be used in this process.

Perform Quality Assurance – Outputs

An outcome of an audit may be that the current defined processes are unable to help you meet the quality standards. Or, your team members would have found an easier method of implementing a standard. This will require you to provide feedback to your organization’s process manager – usually in form of a Change Request - and may result in updating the organization process assets.

Project Management Plan and Other project documents would also need to be updated as part of this process.

1. QA managers in my organization use the word Kaizen. What does this mean?

Kaizen is a Japanese word and it means Improvement. The Kaizen philosophy is to make small improvements and study its impact on the product.

2. Is Audit an Assurance Tool or a Quality Control Tool?

Audits are systematic examination of the quality system. The focus is not just to find if the project is adhering to defined standards but to find out how effective the organization’s quality system is, and if it is not how the organization goes about improving it and making it more effective. In this sense it is an assurance tool.

Practice Questions

1. A tool used to study the effectiveness of the organization’s quality system is:

a) Inspection

b) Audit

c) Review

d) Control

2. All are outputs of the Perform Quality Assurance process EXCEPT:

a) Updates to Schedule Management Plan

b) Updates to Cost Management Plan

c) Updates to Organization Process Assets

d) Updates to HR database on the new skills acquired by team members

3. An objective of a quality audit is:

a) To design and determine process variables that gives the best output.

b) To review changes to projects requirements

c) To inspect the project deliverables and accept those that meet the requirements

d) To identify best practices implemented in a project

1 b Audit is a tool used to study the effectiveness of the QMS

2 d Updating HR database in not part of QA process – this is more applicable to project closure or when a team member leave the team.

3 d This is just one of the objectives. This is the best answer.

C O N D U C T P R O C U R E M E N T S

Conduct Procurements

Conduct Procurements is part of the Execution Process Group and the Project Procurements Management Knowledge Area.

Conduct procurements is the process of obtaining responses from prospective sellers, evaluating the seller proposals, selecting one or more sellers and awarding the contract. You can use this process to conduct several rounds of evaluations till you find the suitable seller and award the contract.

Inputs to this project include:

Procurements Documents

Source Selection Criteria

Qualified Seller List

Seller Proposals

Project Documents

Make-Buy Decisions

Teaming agreements

Organization process assets

These inputs have been discussed in the earlier chapters. Qualified seller list is a list of sellers you may have shortlisted after the first round of evaluation. You may need more evaluations to determine the final seller.

Once the procurements documents are released to the prospective sellers they may review those documents. Some of the prospective sellers may have a few questions to ask and may direct those questions to you. The best option is to ask all prospective vendors to attend a bidder conference where you and your team can address any

Chapter

questions the vendors may have. This is called a bidder conference and helps a great deal in ensuring all vendors understand the requirements completely before they bid.

Your organization may have defined procurement policies that need to be followed in awarding contracts. As a project manager you may be able to shortlist 3 tops vendors for the award while the award itself may be made by a committee comprising of senior managers. It is important you consider such procurement evaluation techniques and

policies.

As a requesting organization you may get an independent estimate for the proposed work done by consultants. These estimates serve as a benchmark for you while evaluating the proposals from prospective sellers.

Other tools and techniques for conducting procurements are:

Advertising: Government rules may require placing advertisements for procurements items beyond a particular value. This can also help you expand the list of preferred suppliers.

Internet Search: If items to be procured are available off-the-shelf, you may search the internet for vendors offering this product or service.

Expert Judgment: Can be used in evaluating seller responses.

Negotiation is a key skill in procuring items for your project or organization. This skill can help you decide on all terms and conditions that need to be put into the contract. This culminates in a contract being prepared and signed.

Conduct Procurements – Outputs

Outputs of this process are:

Selected Sellers: As part of this one or more sellers is selected and a contract is awarded to them. Complex project may require your senior management to approve the award of contract.

Procurement Contract Award: The contract awarded to the selected seller(s) can be in form of a purchase order if it is a standard procurement. Complex procurements will need to include items such as a brief statement of work, schedule baseline, reporting criteria, roles and responsibilities of buyer and seller as well as the pricing details and payment terms. Post project support, warranty etc. may also be part of the contract.

Resource Calendars, Change Requests, Project Management Plan Updates and Project Document Updates are other outputs.

Monitoring & Controlling Processes

M O N I N O R I N G & C O N T R O L L I N G P R O C E S S E S

Monitoring & Controlling

In this chapter we will review all the Monitoring & Controlling Group processes. Monitoring and Controlling Process Group consists of the following processes. The primary objective of these processes is to track the progress of the project, identify changes to the plan and initiate those changes.

Monitoring and Controlling Project Work (Integration Management Knowledge Area)

Perform Integrated Change Control (Integration Management Knowledge Area)

Report Performance (Communications Management Knowledge Area)

Control Scope (Scope Management Knowledge Area)

Control Schedule (Time Management Knowledge Area)

Control Costs (Cost Management Knowledge Area)

Control Quality (Quality Management Knowledge Area)

Verify Scope (Scope Management Knowledge Area)

Monitor & control risks (Risk Management Knowledge Area)

Administer Procurements (Procurements Management Knowledge Area)

Monitor & Control Project Work

Monitoring and Controlling Project Work process involves tracking the progress of the project, reviewing the status of the project at regular intervals and, if the project is lagging behind, taking corrective actions to put it back on track. Inputs to this process are the Project Management Plan, Performance Reports, Enterprise Environment

Chapter

M O N I T O R I N G & C O N T R O L L I N G P R O C E S S E S

Factors and Organization Process Assets. Each of these inputs has been discussed earlier in this book.

As a Project Manager you need to interpret and apply your Expert Judgment to the information provided by this process and must determine the actions in order to bring the project work back on track should there be a need.

The outputs of this process are:

Change Requests – These are the outcome of comparing the plan against the actual performance. These could be corrective actions meant to bring project performance on track or Preventive actions meant to reduce the probability of negative consequences. It could also be due to need for repairing defects.

Approved changes may have an impact to the Project Schedule, Project Costs/Budget or the Project Scope. The project baselines and the Project Management Plan will need to be reviewed and updated should there be a change. Other project documents such as issues log and performance reports may need to be updated.

Perform Integrated Change Control

Changes are inevitable on any project. As discussed earlier Change Request is an outcome of comparing the actual performance of the project with the plan. Changes can lead to 3 types of responses in situations detailed as below:

Reactive response - if the change is handled without any planning then this would result in issues needing workarounds and fixes.

Uncontrolled response - Alternatively, if the change is handled without any control it will lead to scope creep and chaos.

Controlled and Proactive response – if the changes are evaluated, analyzed and smoothly accepted, rejected or delayed, then it is termed as change management

The last mentioned is desirable on any project i.e., the response to every change request must be managed and controlled. The process that helps you manage and control changes to your project is Perform Integrated Change Control.

Changes can be requested by any of the stakeholders; however it is important that all change requests are documented, reviewed, analyzed, approved (by the CCB) and then implemented. Inputs to this process are the Project Management Plan, Work

Performance Information, Change Requests, Enterprise Environment Factors and Organization Process Assets. Each of these inputs has been discussed earlier in this book.

Expert Judgment and Change Control Meetings are tools and techniques to this process. All change requests raised on the project must be discussed by the members of the change control board that meets regularly. Discussions primarily revolve over the necessity of the change, the impact of the change in terms of additional costs and time etc. are discussed and decisions made collectively.

Changes may be Accepted or Rejected. It is important that only those that have been reviewed and approved by the CCB be implemented. When a decision is made to implement a change request you must update the status of the Change Request in the CR log. Project Plan and other project documents may also need to be updated to keep it in synch with approved changes.

The remaining processes in the Monitoring and Controlling process group can be categorized into the following:

Processes that require collecting data, creating reports and distributing it to stakeholders (Report Performance)

Processes that require you to manage changes to the performance baselines (Control Scope, Control Schedule, Control Costs)

Process that require you to XXXXX

We discuss these processes in some detail.

Report Performance

One of your responsibility as a Project Manager is to communicate the status of the project to stakeholders. This involves the following actions:

Collect information about the project

Analyze the information and use it to forecast

Distribute it to stakeholders so that they can make informed decisions quickly

Each type of Stakeholder requires different levels of information. The Project

Management Plan states the type of information by each of the stakeholders. It also states the format and the detail required and is therefore the key input to this process.

The Work Performance Information, also one of the inputs to this process, tells you the status of your project deliverables. Using this information you can determine what the project team has accomplished and what remains to be accomplished. Stakeholders can also use this to make decisions. Econometric Methods and Time Series Methods (Earned Value Management) can help you forecast the project budget and the estimate at completion.

Work Performance Measurements can help you measure the project performance against planned performance. This also forms the basis to stakeholders to make informed decisions.

Variance Analysis is one of the most popular tools to help compare planned performance against actuals. Forecasting methods such as Econometric models and Time Series methods, as well as Communications Methods are other tools of this process.

Performance Reports summarizes the results of project performance compared to the project baseline. Typically, a project performance report would contain information on the milestones achieved during the reporting period, milestones missed and why we these milestones were missed, outstanding issues, status of project deliverables, status on risks and forecasts of time/schedule and costs. These reports are distributed regularly to stakeholders using communication methods that were determined in Communications Planning process.

Analysis of project performance and comparison against plan can require the project manager make changes to the plan. These will result in the project manager raising new change requests that will need to be taken to the Change Control Board for approval and if approved, executing these changes through the Integrated Change Control process.

Controlling Scope, Schedule, and Costs

These processes are meant to help you monitor the status of your project and manage changes to the baselines. These processes involve the following steps:

Determining the status of the project in terms of Scope, Schedule and Costs as the case may be

Influencing the factors that create changes to the Scope, Schedule and Cost as the case may be

Ensuring that all change requests that impact the project are reviewed and only those that are approved are implemented.

Managing the changes to the Scope, Schedule and Cost as the case may be

The inputs, tools and outputs for these processes are as shown in FIGURE 50.

FIGURE 50: Summary - Scope, Time and Cost Control

The Project Management Plan is a common input to all the 3 processes. This document contains the Scope baseline, Schedule baseline, Cost Performance baseline and hence all the 3 processes use this as a basis for measurement, comparison, reports, and decisions. The Work Performance Information and Organization Process Assets are other common inputs. In this section we will discuss only specific tools; most of the other common tools have been discussed elsewhere in this book. Specifically, if there is a change to:

Requirements -you would have to review the requirements document and the requirements traceability matrix

Schedule – you would need to review the current schedule baseline and see how the change impacts the schedule. Change to schedule usually would require addition of new tasks and re-arranging current tasks and resource assignments. There is a possibility that resources may get over allocated while re-planning. You can use scheduling tool (such as MS Project or Clarity) to level resource allocation. The scheduling tool can also help you perform simulation or what-if analysis.

Changes to schedule will most likely cause the end-date of your project to shift. Your objective must be to see that the dates are not very different from the originally planned. Schedule compression techniques (such as fast-tracking – such as

manipulating the lads and lags - or crashing) that you initially used during scheduling will have to be used to minimize the impact of this change.

Costs – You would need to review the funding requirements. Earned Value Management can be used to not just review and report current performance but can be used to forecast and predict costs and cost indices such as T-CPI. Please read the Chapter on Earned Value Management to understand the concept and process of calculating the cost indices.

Common outputs of these 3 processes are:

Work Performance Measurements

Change Requests

Project Management Plan Updates

Organization Process Assets Updates, and

Project Document Updates

A specific output of Cost Control is Budget Forecasts. As part of this a new value for EAC is calculated, documented and communicated to the customer.

Perform Quality Control v/s Verify Scope

Your team would be able to record results of executing quality activities. This is part of Perform Quality Control process. This process deals with recording results of quality activities and assessing the performance and recommending change, if any.

Inputs to this process are:

Quality metrics

Work Performance Information

Quality Checklists

Approved Change Requests

Deliverables, and

Quality Control Tools include:

Pareto Chart: Also called the 80-20 rule. This involves rearranging a histogram on the basis of frequency of occurrence. Pareto principle states that relatively a small number of causes result in majority of problems.

Run Chart: These charts are similar to the control charts except that the observation horizon is large and is often used for trend analysis.

Scatter Diagram: This is a diagram that shows relationships between two variables under study

Other tools are Flow charting, Ishikawa Diagram, Control Charts, Histograms, Inspection and Statistical sampling. Each of these has been discussed in the earlier chapters.

Outputs of the Perform Quality Control process are:

Quality Control Measurements, Organization Process Assets Updates, Project

Management Plan updates and other project Document Updates.

On completion of a quality control activity, deliverable are inspected by the internal team and are passed (Accepted) or failed (Rejected) for release to customer for acceptance testing. Other outputs of this process are Validated Changes and Validated Deliverables. In situations where a deliverables is not passed for release it is sent back to the development team for correction. This may require raising a change

request and is therefore yet another output of the Perform Quality Control process.

Verify Scope is part of the Scope Management Knowledge Area. This process involves finalizing and accepting the deliverables of the project. This process involves reviewing the project deliverables with the customer and obtaining a sign-off from the customer for the work performed.

The Project Management Plan, the Requirements Document and the Requirements Traceability Matrix are key inputs to this process. Yet another input is the validated deliverables. Validated deliverables are outputs of Quality Control process.

Physical inspection is the tool used to verify the deliverables. If the deliverables are found to be acceptable the customer you must obtain a sign-off on the accepted deliverables from the customer. There is a possibility that the customer may find some gaps between the requirements and functions actually implemented. These identified gaps are documented and change requests are raised that need to be put through the Integrated Change Control process. Project Documents would also need to be updated

Monitor and Control Risks

Closing Processes

C L O S I N G P R O C E S S E S

Course Workbook

Documents

English Workbook Basic Course

ACCA F9 - Financial Management - Mapit Revision Course Q.pdf · F9 ACCA Revision Course Workbook Q ACCA F9 - Financial Management Revision Course Workbook

Nh english course beginner workbook

Fundamental Theology Course Workbook Part 1

Course Rep Workbook

Specialized Investigators’ Basic Course Workbook Series

ITIL Intermediate Course: OSA Workbook (Japanese)

Effortless Success - Course 2 Workbook

Career Course Workbook

SENIOR INSTRUCTOR WORKBOOK SENIOR … INSTRUCTOR WORKBOOK ... day practical course which will involve course management ... along with the content and exercises within this workbook

Wildlife / Dangerous Tree Assessor’s Course Workbook

Quran Short Course Workbook Eng

The Volatility Course Workbook

Effortless Success - Course 3 Workbook

Anger Management Course Workbook - Newcastle Psychological

Language and Conversation Course (Workbook)

Negotiation Skills Course (Workbook).pdf

Course Student Workbook

Service-Learning Course Design Workbook

2_ a Course in Miracles, Workbook