program introduction : learning...

Participant Guide:

PM Basics™

PM0158 – IIL-EN-5-v3.0 © 2013 International Institute for Learning, Inc. International Institute for Learning, Inc. 110 East 59th St., 31

st Floor

New York, NY 10022 Phone: 212-758-0177 Fax: 212-755-0777 www.iil.com

The following reference will be used frequently in this workbook, but abbreviated as noted, below the full text of the citation: Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Fifth Edition, Project Management Institute, Inc., 2012. PMBOK

® Guide – Fifth Edition, [table name or glossary if applicable], [page #, if applicable]

http://www.iil.com/

PM Basics Table of Contents

© International Institute for Learning, Inc. ii

Table of Contents

Program Introduction: Learning Objectives ....................................................................... 1

Learning Objectives—Initiating Module .......................................................................... 1

Learning Objectives—Planning Module ......................................................................... 1

Learning Objectives—Monitoring & Controlling Module ................................................. 2

Learning Objectives—Executing Module ....................................................................... 2

Learning Objectives—Closing Module ........................................................................... 2

What's a Project? What's Project Management? ............................................................... 3

A Project is… ................................................................................................................. 3

Project Management is................................................................................................... 3

The People Factor .......................................................................................................... 3

Stakeholders Are... ......................................................................................................... 4

Role of Project Manager (PM) ........................................................................................ 4

A Process Perspective ....................................................................................................... 5

A Story ........................................................................................................................... 5

Questions to Ask Yourself .............................................................................................. 5

Learn From Experience .................................................................................................. 5

Problem Solving/Decision-Making Process Steps .......................................................... 6

Why Project Management? ............................................................................................... 6

Project Management Improves Performance ................................................................. 6

What's a Successful Project? ............................................................................................ 7

Project Success Criteria ................................................................................................. 7

Ending at an Appropriate Time ....................................................................................... 7

Responsibility and Accountability ....................................................................................... 7

Responsibility and Accountability ................................................................................... 7

Project Management Processes and Principles ................................................................. 9

Project Management Principles ...................................................................................... 9

The Project Life Cycle ........................................................................................................ 9

The Project Life Cycle Concept ...................................................................................... 9

Review Checkpoints/Milestones ................................................................................... 11

Product Life Cycle vs. Project Life Cycle ...................................................................... 11

Initiating: Overview ......................................................................................................... 12

Overview ...................................................................................................................... 12

Describing the Project ...................................................................................................... 12

Setting Project Objectives ............................................................................................ 12

Defining Project Scope, Requirements, and Acceptance Criteria ................................ 14

Developing the Project Charter .................................................................................... 15

Who's Who in the Project? ............................................................................................... 17

Identifying the Stakeholders ......................................................................................... 17

Identifying and Notifying the Project Team ................................................................... 19

Organizing the Project ..................................................................................................... 20


© International Institute for Learning, Inc. iii

Organizational Structure .............................................................................................. 20

Three Types of Matrix Organizations ........................................................................... 20

Who Has the Authority on a Project? ........................................................................... 21

Four Sources of Power and Authority .......................................................................... 22

The Kick-Off Meeting ................................................................................................... 22

The Kick-Off Agenda .................................................................................................... 23

Project Organization Structure ..................................................................................... 24

Organization Relationships & Determining Project Organization Structure .................. 24

Authority above the Project Manager ........................................................................... 25

Aligning Expectations ................................................................................................... 26

Keeping Stakeholders "On the Same Page" ................................................................ 26

Making the Go/No-Go Decision ....................................................................................... 26

Making the Go/No-Go Decision .................................................................................... 26

Planning: Overview ..................................................................................................... 28

Planning Basics ............................................................................................................ 28

Negotiating Realistic Estimates .................................................................................... 28

Competing Constraints on the Project Management .................................................... 30

The Project Management Plan ..................................................................................... 30

The Performance Baseline ........................................................................................... 31

Procedural Planning, Project Administration .................................................................... 32

The Communication Plan ............................................................................................. 32

What Should Be Written ............................................................................................... 33

The Procurement Plan ................................................................................................. 33

The Quality Plan ........................................................................................................... 33

Issues Management Procedures .................................................................................. 34

Product Definition ............................................................................................................ 36

Defining the Product ..................................................................................................... 36

Proper Client Involvement ............................................................................................ 36

Managing Scope Change ............................................................................................. 37

Quality Control ............................................................................................................. 38

Task Analysis and Work Breakdown Structure ................................................................ 38

The Work Breakdown Structure ................................................................................... 38

Task Decomposition ..................................................................................................... 38

Task Descriptions ......................................................................................................... 40

Task Deliverables ......................................................................................................... 40

How Much Will This Cost & How Long Will This Take? ................................................... 41

Overview ...................................................................................................................... 41

Top-down and Bottom-up Estimates ............................................................................ 41

Effort & Task Duration .................................................................................................. 42

Estimate Drivers ........................................................................................................... 43

Cost Estimating—the Budget Baseline ........................................................................ 44

Scheduling & Sequencing Tasks ..................................................................................... 44

Overview ...................................................................................................................... 44

An Overview of Task Dependencies ............................................................................ 44

Mandatory vs. Discretionary ......................................................................................... 45

Using the Network Diagram to Help Sequence Tasks ................................................. 46


© International Institute for Learning, Inc. iv

The Gantt Chart ........................................................................................................... 48

Critical Path & Slack/Float ............................................................................................ 48

Calculating Early Start .................................................................................................. 49

Calculating Late Start ................................................................................................... 49

Calculating Slack and the Critical Path ........................................................................ 49

Resource Loading & Leveling; Compressing the Schedule ............................................. 49

Resource Loading and Leveling ................................................................................... 49

Compressing the Schedule .......................................................................................... 50

Risk Assessment & Contingency Planning ...................................................................... 51

Risk Assessment .......................................................................................................... 51

Risk Response Planning .............................................................................................. 52

Contingency Reserves vs. Padding ............................................................................. 53

Assigning Tasks; the RAM ............................................................................................... 54

Executing: Making it Happen — Hard Skills ................................................................... 55

Overview ...................................................................................................................... 55

Key PM Responsibility – Directing and Managing ........................................................ 55

Subcontractor Management ......................................................................................... 55

Managing Risk Events ................................................................................................. 57

Project Management Plan Change Control .................................................................. 59

Managing People — Soft Skills ........................................................................................ 61

Communication: Overview ........................................................................................... 61

The Story of the Blind Men and the Elephant ............................................................... 63

Problem-Solving and Decision-Making ........................................................................ 65

Effective Meetings ........................................................................................................ 66

Team Development: Overview ..................................................................................... 68

Motivation and Morale .................................................................................................. 69

Leadership Styles ......................................................................................................... 72

Monitoring and Controlling: Performance and Monitoring ................................................ 74

Controlling Processes ...................................................................................................... 74

Overview .......................................................................................................................... 74

Performance Monitoring—Capturing Performance Data .............................................. 74

Performance Reporting .................................................................................................... 76

Performance Reporting: Status, Progress and Forecast .............................................. 76

Status Meetings ........................................................................................................... 77

Earned Value Analysis and Percentage Complete Reporting ...................................... 79

Forecasting to Completion ........................................................................................... 80

Performance Report Outline ......................................................................................... 81

Taking Corrective Action .................................................................................................. 83

Corrective Action .......................................................................................................... 83

Trade-off Analysis ........................................................................................................ 84

Changing the Baseline Budget and Schedule .............................................................. 84

Closing ............................................................................................................................. 85

Overview .......................................................................................................................... 85

Transitioning to the Product Life Cycle ............................................................................ 85

Sign-off, Acceptance .................................................................................................... 85

Deferred Action Items, Issues ...................................................................................... 85


© International Institute for Learning, Inc. v

Turning Over the Product ............................................................................................. 87

Learning from Experience ................................................................................................ 87

Post-Project Review ..................................................................................................... 87

Project Archives ........................................................................................................... 87

Team Transition ........................................................................................................... 88

Knowledge Transfer ..................................................................................................... 88

Job Aids

Communications Management Plan

Configuration Management Plan

Deliverable Acceptance Form

Documentation Plan

Issues Management

Plan Change Request Form

Post-Project Review

Problem (Jeopardy) Report

Product Change Request Form

Project Budget and Estimating Checklist

Project Charter

Risk Assessment Questionnaire

Statement of Work (S.O.W.) Outline

Team Leader Cost Status Report

Weights and Scores

PM Basics

© International Institute for Learning, Inc. 1

Program Introduction: Learning Objectives

By the end of this program, you will have learned how to:

Describe the project management process in terms of its major Process Groups—Initiating, Planning, Executing, Controlling and Closing—and the way the steps interrelate in the context of a project life cycle.

Describe the need within your organization(s) for a formal, systematic, disciplined yet flexible, Project Management process.

Identify the characteristics of a successful project and the factors that lead to its success.

Address project initiation and planning issues.

o Negotiate project plans based on a rational set of schedule and budget drivers to avoid the consequences of poorly planned projects with unrealistic time, cost and quality objectives.

o Identify and describe the critical roles of the Project Manager, Product Manager, Sponsor, Steering Group, Client, User, and Performers in projects.

o Describe how to plan a project using techniques of objective setting, scope definition, task analysis (with Work Breakdown Structure (WBS), top-down and bottom-up estimating, scheduling (dependency analysis, critical path analysis, network diagramming, PERT, CPM, Gantt charting, resource allocation and leveling), role and responsibility assignment, risk analysis and organization planning.

Identify the major components of project control, execution and close-out, and be able to create effective project status reports, manage change control procedures, manage quality and communications plans, and organize effective post-project reviews.

Describe the critical need for effective interpersonal relationships and communication.

Identify and describe cultural change issues in implementing systematic project management techniques in your environment(s).

Identify the ten Knowledge Areas (KAs), in the Project Management Institute's PMBOK® Guide and

identify and briefly describe each of the sub-processes of the KAs.

Learning Objectives—Initiating Module

In the Initiating Module, you will learn how to:

Define and briefly describe the process of initiating a project.

Set objectives for a project.

Describe and create a Project Charter.

Identify the project Stakeholders and their roles.

Describe the project Kick-Off process.

Describe project organization options.

Discuss the need for aligning the expectations of project Stakeholders.

Learning Objectives—Planning Module

In the Planning Module, you will learn how to:

Describe the overall project planning process, its performers and its results.

Describe what is meant by iterative plan refinement and why it is necessary.

Describe procedural planning and identify the key points in planning for project communications, procurement, quality management, change management and issues management.

PM Basics


Identify the process and requirements for defining project scope, in terms of the products and services to be delivered by the project.

Define the work to be performed in the project using a Work Breakdown Structure (WBS) approach based on task decomposition with task descriptions.

Describe how to assign tasks for responsibility using the Responsibility Assignment Matrix (RAM).

Estimate and schedule a project.

o Describe and know when to apply top-down and bottom-up estimating and estimate negotiation techniques to realistically estimate effort and duration and project costs.

o Identify the key drivers in estimating effort and duration.

o Sequence tasks using dependency analysis and network diagramming.

o Calculate the critical path and slack, or float.

o Use and read a Gantt chart to depict a project schedule.

o Allocate and level resources to optimize the schedule.

o Identify options for compressing a schedule.

o Describe the importance of risk management and its component parts, including contingency fund management.

o Identify the Competing Demands (formerly called “Triple Constraints”) and see how they fit within the planning process.

Learning Objectives—Monitoring & Controlling Module

In the Monitoring & Controlling Module, you will learn how to:

Describe the project control process and identify its importance and key parts.

Describe how to plan for effective status, progress and forecast reporting for project stakeholders with a variety of needs.

Describe the Earned Value Analysis technique and the use of percentage completion reporting in project control.

Identify the options for corrective action during the project's life.

Learning Objectives—Executing Module

In the Executing Module, you will learn how to:

Describe the project executing process in the context of project management.

Identify the steps and required data for performance monitoring.

Identify the major principles and steps in subcontractor management.

Identify and handle changes in the project scope definition, budget and schedule.

Identify the major principles of team development and describe its importance to project success.

Identify the key principles of project communications regarding conflict resolution, problem solving and negotiation.

Describe the attributes of effective meetings.

Learning Objectives—Closing Module

In the Closing Module, you will learn how to:

Describe the project acceptance process including the handling of conditional acceptance and product turnover.

PM Basics


Describe the importance of post-project review and the process for planning and holding it, and using its results.

Identify the need for and describe project archives.

Describe the team transition process.

What's a Project? What's Project Management?

A Project is…

A project is a temporary endeavor undertaken to create a unique product, service, or result.

- PMBOK® Guide – Fifth Edition, Glossary

It has:

A beginning and an end.

A specific set of objectives.

Measurable quality criteria.

Many interrelated activities.

A defined cost and time.

And it creates a unique product, service, or result.

Risk of failure increases as project duration increases.

Hot Tip: Keep it short

Keep the project fairly short. That way you can provide and measure a concrete outcome in a time frame that shows the client and sponsor that something useful is happening. If the project gets really big, more than six months or so, see how you might break it up into smaller pieces (sub-projects or phases) so that you're working with a program (a collection of projects) or a supra-project.

(For more information see Planning: Project Definition and Project Scope.)

In addition to project duration: Project complexity, integration of functions, and technology are other important risk indicators.

Project Management is...

Project management is a discipline that applies principles, concepts, tools and techniques to improve project performance and organizational effectiveness. Project management adds value.

Discipline without flexibility leads to bureaucracy. Project management is really about applying a set of techniques and principles in a disciplined way while simultaneously being open and ready to adapt the minute something "not in the textbook" comes up. Do what you have to do while sticking to the guidelines.

Hot Tip: Be disciplined, be flexible

Project management is a discipline but . . . You must be flexible, creative, and ready to adapt.

The People Factor

Projects are run by people and worked by people. And projects are performed for people. So we need effective interpersonal relations. Communication is the key to relations. We will address communication planning, negotiation and conflict resolution, among other relationship-related issues, in the planning module.

PM Basics


Projects involve people from different organizations working together: So project management requires good group dynamics. Again, communication is a key factor in assuring project success through exchange of information and by ensuring that misunderstandings, politics and inter-group conflicts are overcome to allow focus on the project and its objectives. In this area, we will address organization structure, reporting and accountability, authority and responsibility.

Stakeholders Are...

A stakeholder is anyone who will be impacted by or has a stake in the project. Who are the interested and involved people? Projects are done by people. The following is a list of the Principal Stakeholders on a project. You will find detailed descriptions of each of these Stakeholders in Initiating: Who's Who in the Project.

Client

Sponsor

Project Manager

Champion

Performers

Users

Functional Manager

Vendors

Steering Group

Support and Operational Staff

Quality Control

Quality Assurance

Others—including the families of the project participants, auditors, regulators, shareholders, the general public, and managers of other projects (depending on the nature of the project).

Role of Project Manager (PM)

To manage is to direct or control use of resources and to administer activities.

A "Project Manager" is...

A Project Manager is a person who is responsible for managing a project. A professional project manager is a person who manages projects in a disciplined manner, using project management principles, concepts, tools and techniques.

Hot Tip:

The Project Manager must have the "hard" skills needed to plan and control the project and the "soft" skills needed to communicate, negotiate, facilitate, motivate and harmonize the Stakeholders who make up the project.

The Project Manager is responsible to ensure that:

Goals and objectives are properly set and accepted.

Requirements are identified and managed.

The project team is identified, organized, and managed.

Resources are available.

Project is planned.

Work is performed according to the plan.

PM Basics


Project schedule and budget are kept on track.

Clients and stakeholders have realistic, balanced expectations.

Project progress and expected completion times are communicated to stakeholders.

Key Intermediate project results are reviewed to make go/no-go decisions.

Harmonious relationships exist among all stakeholders.

The plan is adjusted to provide a guideline for achieving the desired goal.

Revision and change control processes are defined, understood, and followed up.

Risk is anticipated.

Project goals and objectives are achieved.

A Process Perspective

A Story

A woman is in her kitchen, preparing a holiday meal. She is getting ready to cook the roast. She cuts off the two ends of the roast and puts the main part in the pan, putting the two ends in another pan to cook. Her son, who is helping her, says "Mom, why do you cut off the two ends of the roast before you put it in the pan?" The mother answers, "My mother does it." The boy isn't satisfied and calls up his grandmother. "Grandmother," he asks, "why do you cut off the ends of the roast before you put it in the pan?" The grandmother thinks and thinks and responds, "Oh, I remember—your great-grandmother used to have this pan that was too small for the entire roast, so she always had to cut off the two ends and cook them separately."

How many mindless traditions are there in your projects? What happens when you do something just because that's the way you have always done it? What you do requires time and effort. Make sure your purpose is clear and that the expected results are desired.

Questions to Ask Yourself

The cycle below is a variation on the Plan-Do-Check-Act (PDCA) cycle from Total Quality Management. It is applied across multiple projects and within individual projects to make sure there is a continuous improvement of the way things are done.

Adopt a process perspective and ask yourself:

Why do you do what you do?

How do you do it?

Why do you do it that way?

How do you communicate?

How do you improve?

What effect would change have?

Learn From Experience

Past mistakes can prove invaluable to future projects.

Each project contains lessons learned.

Post-Project reviews evaluate performance and pass lessons learned on to avoid pitfalls and promote the use of best practices.

Estimates and actual results may be passed on to improve future estimating.

Evaluate trends to discover opportunities for improvement.

PM Basics


Eliminate the causes of delays, errors and omissions.

Review your process during the project as well as at its end. Apply changes to improve your project’s performance.

(You will learn more about this crucial aspect of project management in Closing: Learning from Experience.)

Problem Solving/Decision-Making Process Steps

When confronted with a challenge or problem, it's tempting to jump straight to step 6: Action (doing what you think will work). But such enthusiasm achieves its best results when it follows a well-thought-out assessment of the situation.

1. Describe the problem and its setting

2. Set objectives

3. Identify causes

4. Identify potential solutions

5. Decide

6. Act—implement the solution/decision

7. Monitor and adjust

o Shoot for consensus (unanimous agreement) within time constraints.

o In the absence of consensus, accept the need for authority decisions.

o Avoid majority rules! (The minority isn’t comfortable with these decisions and this may not be helpful. The result: "It wasn't my idea." or "I told you so.")

Why Project Management?

Project Management Improves Performance

Project management is a value-added activity. Its results show up on the bottom line. It makes sure that projects do not behave like ships without rudders. Instead, through professional project management, you and your organizations can save time and money while getting optimal results.

Through effective project management, you are more likely to do the right things right.

Address Your Project Management Issues

Since Project Management is important to the bottom line, it is critical that you do it in the most effective way. If there are problems and issues that impact your ability to deliver successful projects, they must be addressed. Like any other process in your organization, Project Management should be continuously improved. As a Project Manager you may be solely focused on individual projects, but if you do take a role in the overall way projects are managed, do it effectively.

Overall management challenge: Project team members, including the Sponsor, may find such core problems as accountability, communication, and structure, too big and high-level to deal with. Due to the absence of data and lack of understanding of the issue, they may ignore it.

Solution: Focus on the very specific issues such as lateness or cost overrun. Focusing on the behavioral issues of an organization—"We always deliver our projects late and run over the budget"—gets people's attention. Then you can ask, "Why are these tasks always late?…Because of issues related to accountability, communication and structure." In other words, present a logical argument backed by data if you want to promote change.

Hot Tip:

Get Attention – Focus on Specifics

PM Basics


What's a Successful Project?

Project Success Criteria

A Successful Project:

Balances the Competing Constraints (originally triple constraints)

o Scope

o Schedule

o Budget

o Quality

o Resources

o Risk

- Adapted from PMBOK® Guide – Fifth Edition, p. 47

Satisfies the expectations of Stakeholders, particularly Clients, sponsors and product users.

Results in a product that adds value and is meaningful in meeting the business reasons for the project.

Is one in which the participants in the process find it rewarding and pleasant. In other words, the project experience promotes harmony among the stakeholders.

Results in the participants and the organization(s) learning from the experience.

Ending at an Appropriate Time

Fact:

A successful project needs to end—and end at an appropriate time.

Question:

A project starts off looking like a two-month project for six people. Within two weeks, it becomes clear that the project will actually take six months and require 15 people. You raise this to the Sponsor and Steering Group who decide to cancel the project for being too long and too expensive. Is this success or failure?

A project that ends as soon as it is deemed to be no longer desirable is SUCCESSFUL.

Canceling a project that was suddenly going to take twice as long and require twice as many people probably qualifies as project success. Even though you haven't come out with a product, you haven't wasted a lot of money and time. The indication is that your project management process is sound.

Disappointment doesn't mean failure. In some instances, it may mean success.

Responsibility and Accountability

Responsibility and Accountability

Responsibility:

The state of being charged with the obligation to deliver on something, such as a task.

PM Basics


Accountability:

The obligation to report on one’s actions.

Hot Tip:

Ensure that people take on only those responsibilities on which they can deliver.

PM Basics


Project Management Processes and Principles

Project Management Principles Plan the work, work the plan

o Spend your time planning – this is your opportunity to figure out what you are going to deliver, what the best way to deliver it is, how much time and effort it’s really going to take, and who’s going to do it.

o Then, once you’ve done all this work, it would be only logical to work the plan. That means to follow it and adjust it as needed.

Management by product

o Clients are no longer interested in your project management process. They want a deliverable.

o Every task has to have at least one deliverable associated with it. The deliverable has to be something that’s useful as a building block toward the next steps in the project.

Partnership – don’t “throw things over the wall”

o Collaboration is critical.

o Do your part and then pass it on with regard for the person picking it up and what they might need from you.

o If someone drops the ball, pick it up.

Objectivity

o Don’t make decisions based on emotions and subjective perspective.

o Objectivity achieves better results, cultivates open communication amongst the team, and builds trust.

Definition – roles, responsibilities, objectives

o By carefully defining roles and clarify responsibilities, as well as articulating objectives, you help avoid politics and misunderstandings.

o The Responsibility Assignment Matrix (RAM), covered in Planning, supports this principle

Situational management

o Be flexible.

o Be creative.

o Adapt to the moment.

The Project Life Cycle

The Project Life Cycle Concept

Steps from Beginning to End

The Project Life Cycle (PLC) is the set of steps from the project's beginning to its end. The cycle is expressed as a set of phases—the phases represent the major steps in the project. Phases may be divided into the activities, each with its own set of deliverables, which must be performed to complete the phase. Often the phases are defined to provide control checkpoints in the project, at which significant deliverables (e.g., requirements definition, design specifications, etc.) are available, or the project is getting ready to deploy the product or to commit significant resources.

PM Basics


Project Management throughout Project Life

The five PM Process Groups are Initiating, Planning, Executing, Monitoring & Controlling and Closing.

- Adapted from PMBOK® Guide – Fifth Edition, Figure 3-1, p. 50

These process groups are performed across the PLC. Note that each phase can be seen as a "sub-project" in which the five Process Groups are performed.

Checkpoint Reviews

Checkpoints (also called Gates) are defined to follow the phases to ensure control of the project. (For more information, see Review Checkpoints/Milestones.)

Variations

The number and names of the phases and review points vary depending on the nature of the project—industry, duration, complexity. In addition, there are different approaches to projects that influence the way the PLC is structured. Most notably there are the "Waterfall" and "Iterative" approaches. In the Waterfall approach, there is a step-wise process that is based on the idea that once a phase has been performed and its results validated, there will be relatively little change in the results. In the iterative approach, the idea is to evolve the product definition through an iterative refinement of prototypes or models.

Deliverables

Each phase is associated with one or more major deliverables—for example, a statement of requirements, or a design document.

(For a more detailed and specific example, see The Project Life Cycle Example)

Typical Cost and Staffing Levels Acros a Generic Project Life Cycle Structure

- PMBOK® Guide – Fifth Edition, Table 2-8, p. 39

PM Basics


Review Checkpoints/Milestones

Review Checkpoints (called Quality and Financial Gates in some industries) allow decision-makers (Clients, Sponsors, and others) to ensure that the organization is getting what it needs and is not incurring unnecessary expenses and risks.

The longer the project, the more critical and costly, and the more checkpoints are needed. Decision-makers determine if the project's interim results (e.g., plans, designs, etc.) are acceptable and if continuing the project is in the best interest of the organization. Go/No-go decisions are made. Go allows the Project Manager to continue, possibly with changes in direction or qualifications. No-go stops the project.

The Project Life Cycle: A set of project phases (broken down into task lists with activities and sub-activities and deliverables for each task) with checkpoints or milestones between each phase.

Objectives of Checkpoints and Reviews:

Ensure that a standard set of questions are asked to validate the work done so far.

Ensure deliverables meet requirements and the project can proceed.

Identify issues to resolve and make recommendations.

Reevaluate the reason for the project – avoid runaway projects.

Product Life Cycle vs. Project Life Cycle

The Project Life Cycle is:

A set of phases that represent the work that is done in the project at a high level of detail, usually organized for the purpose of controlling the project.

A set of major review points (sometimes called Quality or Financial Gates) that generally occur after the phases.

The phases broken down into a set of activities each with its respective deliverables (documents and so forth).

Product Life

During the life of a product there may be many projects.

In effect, each phase of a project can have an initiation as if it were a project in itself.

For example, if you build a house, the initial construction project ends with the beginning of the house's product life cycle. Projects that may be performed during that product life could include adding a new wing, replacing the roof or redecorating the interior.

Requirements and Design Decisions and Product Life

Whether your project life is longer or shorter than your product's life, take care that design and requirements decisions reflect the ongoing and future needs of the product during its life and not just project-centered issues, such as "How can we hit the deadline and keep the costs down?" Don't trade off future costs and convenience for short-term project gains unless you do it consciously.

If your project is to implement a new business process (like the Call Center in our case study), don't make decisions about what equipment to use without considering how the equipment choice will influence the number of replacements and upgrades required over the next several years. If you are developing a product like a house, you might consider taking a long-term view of maintenance costs. For example, features that may cost more up front or take more time to install may reduce costs over time.

PM Basics Initiating


Initiating: Overview

Overview

The Initiating Process Group consists of “those processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase”.


In this part of the course on Initiating, we cover some activities that overlap with the Planning activities. The team may not only develop preliminary project scope statement (an initiating activity) but also do some planning (for example scope definition, estimating, and role and responsibility definition) before the Initiating authority(ies) can make the Go/No-Go decision that officially starts the project.

It is important to point out that Initiating, as with all the Process Groups, should be seen as occurring within the major phases of a project, as well as for the project as a whole. In effect, the Go/No-Go decision-making that occurs in many large projects at several Checkpoints is an Initiating activity.

The Kick-Off meeting that is referred to by Fred, our host and project manager, in his overview of this Process Group is viewed by many as being a part of the Planning Process Group. We cover it here because it is something that provides a foundation for the work to be performed. You will find more on this subject under Organizing the Project in the topic on Kick-Off Meetings.

Now, go and explore the Initiating Process Group.

Describing the Project

Setting Project Objectives

Objectives Drive the Process

A team is defined as a group of people with common objectives. That's really what makes "a team a team" — the focus toward a common end.

To be successful, a project team must identify clear, mutually understood objectives to ensure that all Stakeholders have a common understanding and a common motivation to complete each stage of the project. Objectives should be published and used as the baseline for all project evaluation, planning and control.

Clear Objectives:

Motivation

Acceptance Criteria

Objectivity

Team Work

Unclear Objectives:

No Motivation

No Acceptance Criteria

Subjectivity & Politics

More Frustration

Objectives are:

Desired end

The reasons for our actions

The driver of project performance

A necessity for good teamwork

The criteria by which we measure success

Objectives Should Be:

Measurable

Time-bound

Achievable

Written

Prioritized

Relevant to the sponsor and client

PM Basics Initiating


No more than six or seven in all (at high level – each of these can be broken down into sub-objectives

PM Basics


Levels of Objectives

On one level there are the big reasons, or Business Objectives, for doing the project (reduce costs, improve service, etc.) On another level, there are the project outcome and constraints--what needs to be accomplished in order to achieve the Business Objectives. These are Project Objectives. A third level consists of the reasons for the small steps that must be taken along the way (Task Objectives) to accomplish pieces of the project.

A Word about Goals

There is a thin line between goals and objectives. Although the Oxford American Dictionary defines a goal as an objective, in the context of project management we define goals as overriding reasons for performing a project. For example, "improving customer service" or "improving profitability" are goals. Objectives are a refinement of the goals that include a more precise statement of the desired outcome.

Business Objectives: The reasons for performing the project.

o Example: Improve customer service so that 95% of responses to the customer satisfaction survey are "Very Satisfied."

Project Objectives: The product or the physical outcome of the project, by a given date, for a given cost. The project objectives are a means to the end of business objectives.

o Example: Develop, within six months and at a cost of no more than $150,000, an interactive Internet-based computer system to answer 99% of customer inquiries without human intervention. Another objective for the same project could be to create standards and procedures for operations and support of the new system, following the corporate standard format and guidelines for operating procedures.

Task Objectives: The specific outcomes of the performance of tasks within the project. These are associated with specific task deliverables.

o Example: Select a vendor, within four weeks, to construct new facilities for 25 people. A sub-task of the select-the-vendor task might be to prepare a request for proposal. The objective of that task would be to document the basic requirements and constraints imposed by prospective vendors to make their proposals.

Defining Project Scope, Requirements, and Acceptance Criteria

So, How Do You Know When You've Met Your Objectives?

The answer to this question must be established at the Objective Setting stage so that all Stakeholders (sponsors, clients, users, product management, performers, operations, and support people) in the project agree upon what the deliverable, or product, will "look like" and what behavioral changes will result.

In other words, it ensures that when an objective is achieved and a deliverable delivered, no one can say, "You completed this, but it's not what I wanted."

The project team jointly defines mutually agreed upon Project Scope, Requirements, and Acceptance Criteria. Most of the detailed description of Requirements takes place during the Planning process.

Scope

Scope – there are three dimensions to the scope of a project:

Product Scope (the full set of features and functions)

Project Scope (all the work that needs to be done to deliver the product)

Scope of Impact on the organization (the depth and breadth of involvement by, and effect on, the performing and client organizations)

PM Basics


Requirements

Requirements are quality and performance specifications of major project deliverables.

Acceptance Criteria

The basis upon which the product will be deemed suitable for use by the client and other approvers, and upon which the client will decide to pay for the product. (Note, our ability to delegate work to others in a way that sets clear expectations hinges on the clarity of objectives and acceptance criteria.) These must be in writing to avoid conflict and rework later in the project's life. (Reworking—the need to redo things we've already done—is most often caused by misunderstandings about acceptance criteria.)

Just Getting It Done Isn't Enough. It's Got To Be Done RIGHT!

People have different definitions in their own minds of what "right" means. The outset of a project is when you have a chance to define outcomes to everyone's satisfaction. Here are some guidelines for establishing specific acceptance criteria.

Completely Describe Requirements and Acceptance Criteria

Form and Format — What specifically is the deliverable to look like? What structure? What contents? What level of detail? Etc.

Measure of Completeness — What constitutes the full set of attributes, operational criteria (Ex. speed, durability, etc.) and constraints that must be in place for the product to be acceptable to the client, the sponsor, and others who have a stake in the product (Ex. support people, manufacturing people, etc.)?

Standards — What external (Ex. government regulations, industry, etc.) standards must be complied with?

Constraints — When does it have to be delivered? How large? What level of quality? Etc.

Methodology — How will the product be tested or verified?

Objective Setting and Requirements Definition Is an Iterative Process

At the most detailed level, objective setting includes a detailed definition of requirements. In many projects, detailed requirements and acceptance criteria may be known at the very beginning—during the Initiation Process. For example, a client may provide a detailed statement of requirements from the start. In other projects, you may encounter a very high-level definition of the objectives that is used to initiate the project, which you then use to define requirements in detail during the Planning Process.

In the end, objective setting is an iterative refinement of a set of high-level objectives into a set of detailed requirements which become the acceptance criteria for the project deliverables.

(For related information, see Planning: Product Definition.)

Developing the Project Charter

Officially, a Project Charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.


Unofficially, it may be called by other names such as, a Project Brief and occurs in many different formats, depending upon industry, organizations, and projects.

PM Basics


In general, the Project Charter should include:

Business need and justification

Project objectives

High-level requirements

Product description (scope)

Acceptance/approval criteria

Assumptions/constraints

Assigned project manager/authority level

Summary milestones

Stakeholders (especially sponsor)/functional organizations

Risk assessment

Authorization

In the most formal sense the Project Charter, when approved by the appropriate authorities, recognizes the existence of the project. The Project Charter may be used as an internal "contract" regarding the project and various groups' roles and responsibilities. The charter may be presented in narrative form or in a more structured presentation. (See the Job Aids for an example of a Project Charter Form you can print out.)

PM Basics


Who's Who in the Project?

Who Initiates the Project?

A project may be initiated by any member of the organization at any time depending on the organization's policies and procedures and the scope of the project.

Authorization is generally done by an executive or manager (or possibly the Sponsor, who you will learn about in the section entitled Identify the Stakeholders) who is outside of the project, and/or by a client. Often a Steering Group made up of several executives or managers will authorize the Project Initiation.

Authorization to Spend

Initiation results in the authorization of expenditures of resources for work on a project. The process identifies high-level objectives and determines if any work on the project should be funded. However, it is important that no significant effort be expended until appropriate approval has been obtained.

The Project Charter is the formal documentation of the authorization to proceed and expend money and resources.

Notification of Stakeholders

Initiation includes notifying people or organizations affected by the project, especially those requested to do work on the project. Notification and early involvement will help avoid surprises and redundant or interdependent projects that may cause delays later in the project's life.

Identifying the Stakeholders

Stakeholders are People

First and foremost, Stakeholders are people. We might refer to them as "Human Resources" or "Stakeholders" or any number of other terms, but don't forget they are people.

People are the most important (and complex) resources in the project!

What is a Stakeholder?

We're not talking about the type of Stakeholder we find in vampire stories (the guy that drives the stake into the vampire!). Ask yourself: Who are the interested and involved people? The Stakeholders are anybody and everybody with a "stake" in the project—the Clients, the Sponsors, the Performers, the general public, and even the family and friends of direct participants can be considered Stakeholders.

Descriptions of each Stakeholder

Client – The client is the primary beneficiary of the project. Whether the project is being performed by an external vendor or an in-house group, there is at least one client. The client is usually the one who pays the bills. In the in-house situation, the client is often the manager of the organizational unit that is most affected by, and will "own", the product. Many key project decisions, like: what the objectives are; whether the project should continue; whether requirements and design satisfy the objectives; and whether the product is acceptable, are made by the client.

Sponsor – The Sponsor is usually a high-level executive in an organization with enough power to initially authorize the project and to make sure there is sustained interest and support from the various performance groups. In in-house projects, the Sponsor is often the funding source. In Vendor projects, there may be two Sponsors – one in the Client organization and other in the Vendor organization. The Sponsor is usually not involved on a day-to-day basis. The Sponsor is often a key decision-maker.

Project Manager (PM) – The PM is ultimately responsible for project execution and is accountable for project performance. The Project Manager in large projects or programs is often called a

PM Basics


Program Manager and may have subordinate Project Managers. The PM facilitates, coordinates, communicates, delegates, and makes key decisions within his or her scope of authority. The PM makes sure the project is adequately planned and that all parties are accountable for the responsibilities to which they have committed. One of the most challenging aspects of the PM's role is "managing upwards" – managing the Sponsor, Client, and Steering Group in particular.

Functional Manager (FM) – FMs are people who are responsible for Functional Groups (departments) that provide services or people to the project. FMs may be primarily responsible for performing ongoing operational activities, like manufacturing or customer service, or may be primarily responsible for supporting project work, like technical writing. The FM and Functional Group are like "internal Vendors" or Contractors. There is a contract, though not "legally binding", between the FM and PM.

Steering Group – The Steering Group is a set of Stakeholders who act as the board of directors for the project (or a suite of projects). The Sponsor often leads the Steering Group. The PM may act as facilitator or even chairperson. Members are usually managers or executives with a stake in the project outcome. Outside Vendors and other, the Steering Group will make key decisions, particularly the "Go/ No-Go" decisions made at project initiation and at checkpoints.

Champion – The project Champion is a person who is convinced that the project is of real value and convinces others (Clients and Sponsors, most importantly) to fund and provide ongoing support to the project. The Champion may be anyone in the organization and may not take an active role in the project.

Users – These are the folks who will directly use the product. Sometimes the Client is a user. The Sponsor may be User, as might any of the Performers. The User may be part of the firm performing or sponsoring the project or maybe someone who will buy, lease or rent the product being developed. Clearly, satisfying the Users' needs is quite important.

o In the case of our Call Center Project case study, the ultimate User is the person who will call in with a problem.

Support and Operational Staff – These people are the ones who will take responsibility for the maintenance and support of the product once it is finished. In the Call Center Project, the Support and Operational Staff are the people who will be on call at the Call Center and the people who will answer the questions that the Call Center operators can’t. Additional support people have approval power regarding various aspects of product, like procedures, designs, etc. In other projects, manufacturing, sales, customer service, field support and facilities maintenance fall into this category of stakeholders.

Vendors – Vendors are outside contractors or providers of staff, goods and/or services to the project. Vendors make specific commitments to the PM and are accountable to the PM. Vendor commitments take the form of legally binding contracts (explicitly written or implied).

Performers – These are the people and organizations that do the work. They may be internal staff or Vendors. Ultimately, the Performers are people. In many projects, the PM has no direct contact with the individual Performers because he or she delegates work to an organizational unit (functional group) or to an outside Vendor firm. In these cases, contact would be through a Task Performance Manager, Functional Manager, or subordinate PM or Team Leader. PMs must remember not to take the Performers for granted. No work gets done without the Performers; no projects get finished unless work is done.

Quality Control (QC) – Quality Control people test the product to make sure it complies with the requirements and constraints that make up the Acceptance Criteria. Ideally, the QC people should be relatively independent of the PM so they can be objective and have enough power to delay or stop the project when necessary.

Quality Assurance (QA), Auditors and Regulators – These Stakeholders are generally from outside of the Project Team. They make sure the project complies with standards. The QA Stakeholder also facilitates ongoing improvement of standards and procedures.

PM Basics


Identifying and Notifying the Project Team

What is a Team?

A team is a group of people with a common objective. Team members are expected to subordinate their individual needs (within reason) to the needs of the team.

The Project Team

Multiple views of the organization are necessary to formulate useful project plans. People from many different functional organizations, e.g. business operations, sales, marketing, human resources, computer systems (software, hardware, communications, operations), must join forces to get the project done.

The full set of people required to get the project done is the Project Team. The Core Team is the group of people who are usually on the project fulltime and who have the responsibility of making the efforts of all participants are coordinated toward meeting project objectives. The Project Manager, perhaps an administrative assistant and two or three Performers usually make up for the Core Team. (For more information on how the Project Team – and the project itself – is organizes see, Initiating: Organizing the Project.)

The Planning Team

This is the group that is responsible for the planning of the project. Often the Planning Team is a part of the Performance Team, but in some situations the Planners may be entirely different form the Performers.

Note that it is up to the project team to review and accept or revise any plans developed by a planning team that is outside of the project team. The project team is accountable for the project’s performance and must buy into the plan.

Notifying Participants

Notifying all participants or potential participants as early in the project life as possible is essential. Certainly, any person or group that has a defined responsibility should be aware of that responsibility and should have an opportunity to buy into the commitments regarding performance, schedule, quality, and cost.

Notify participants early in the project life to make sure that the assumptions being made about their involvement are valid. People don’t like surprises like, “Oh, by the way, the product will be handed over to your group for testing in a week, and you’re scheduled to turn it around within 10 business days!”

Obtain Written Commitments Before Completing the Plan

As a Project Manager, before completing the plan and committing an end date and cost to the Client and Sponsor, make sure the people and groups who will be doing the work have committed themselves to you. Otherwise, you will be accountable for something you have no capability to do.

Written commitment doesn’t necessarily imply a signed contract. It can be as simple as an email confirming the understanding of the work to be done and the constraints (scope, time, cost, quality, resources, and risk) to be met.

Why Written?

People forget. Putting things in writing makes it less likely that they’ll forget the commitment they’ve made to you. It assures accountability. So, if you want to manage your project effectively, get commitments in writing and then remind people frequently.

However, when Performers are from outside firms, you need a binding contract. It can be simple, but it must be clearly stated and in writing.

PM Basics


Organizing the Project

Organizational Structure

Matrix Organization

Officially, a matrix organization is “any organizational structure in which the project manager shares responsibility with the functional managers for assigning priorities and for directing the work of persons assigned to the project.”


The use of functional resources on the project team or the delegation of work to functional groups creates what we call a Matrix Environment. In a Matrix Environment, an individual may work for two bosses at the same time: one on the project level, and another on the department or function level. Matrix Management is the management of the work within a matrixed environment.

Using Matrix Management, an organization can share people more easily. It may also create some difficulty because one person may report to two or three different bosses—making resource balancing more confusing and creating conflicts between projects and between Project Managers and Functional Managers.

Projectized Organization

A projectized organization is “any organizational structure in which the project manager has full authority to assign priorities, apply resources, and direct the work of persons assigned to the project”

PMBOK® Guide – Fifth Edition, Glossary

The Functional Managers have no role in the project other than providing the resources. This structure is common in organizations, such as consultancies and contracting firms, in which projects are the principal activity and source of income and in situations in which a project is strategically critical.

Three Types of Matrix Organizations

Weak Matrix

In the most tenuous type of Matrix Environment, the Project Manager is merely a coordinator who lacks authority to obtain resources or get people to perform. The best plan of action in a Weak Matrix Environment is to clearly define authority, responsibility, accountability and the various relationships and procedures in the project. By doing so, the Project Manager will greatly improve the chances of success. Under a Weak Matrix, the so-called Project Manager must manage by pleading – not such an effective way to get things done.

Balanced Matrix

In this environment, the Project Manager is recognized and has a clear role. Here, the Project Manager works for one of the Functional Managers and may have some political difficulties being independent and autonomous. For example, he may be unable to push back on the Functional Manager regarding staffing or schedule compliance, especially if the Functional Manager is also his boss. This type of management works best in minimally political environments.

Strong Matrix

In this type of environment, the Project Manager is independent of the Functional Managers involved in the project. As in the Balanced Matrix, the role is clearly defined with respect to authority. This type of

PM Basics


environment works best in a large-scale organization, or one with heavy politics. Here there is often a Functional Group representing project management, or the Project Manager is from the normal hierarchy and reports to the Sponsor or Steering Group directly.

Who Has the Authority on a Project?

Who Has the Authority on a Project?

A project's success or failure can often depend on the Project Manager's level of authority.

Authority: The ability to get other people to act based on your decisions.

Power vs. Authority: Power is the ability to influence the actions of others. Total authority is only one source of power. (You will learn about the Four Sources of Power on the next page.) Authority is generally based on the perception that a person has been officially empowered to issue binding orders.

How Much Authority the Project Manager Needs

Minimally, a Project Manager needs the ability and the power to get commitments from everyone who is going to be working on the project and to manage accountability throughout the project, including:

- The ability to get formal commitments from anybody who is working on the project.

- The ability to accurately and regularly receive progress reports against that set of commitments.

- The authority to candidly produce status reports that summarize and highlight any kind of “slippage” or issues.

The Project Manager can certainly have more authority—ideally the authority to make all key decisions within the project—short of Go/No-Go decisions. In fact, in some situations the Project Manager, having profit and loss responsibility for a project, may have Go/No-Go decision-making authority or a significant say regarding even these critical decisions.

Delegating and Defining Authority

In a project, many people have various levels of authority. For example, the authority to decide on the color of the paint for a new facility might be given to an individual or a group of individuals who will work or live in the facility. While the PM could retain the right to make the decision if the group could not come to an agreement, the decision could be delegated.

Every task needs to be defined in terms of the people who will perform it and their different roles and responsibilities.

Every decision in a project is a task. It is a piece of work (making the decision) requiring effort (researching, dialoguing) and resources (the decision-makers, decision support tools) that has a concrete outcome (the decision—hopefully documented).

To avoid unnecessary conflicts and delays later in the project, the PM should define:

- The decision-makers

- The people who must be informed of the decision

- The authority above the decision-makers

PM Basics


Four Sources of Power and Authority

Total Authority:

This is rare for a Project Manager. Those Project Managers who have it can get things done, but should be careful not to wield it carelessly. The goal is to delegate as much responsibility as possible, and to rely on and promote a consensus process. Total authority should be used only when it is absolutely necessary.

Reference Power:

This means using other sources of power or authority. It is common for a Project Manager to work for a person with authority (for example the Sponsor). In that case, those who don't listen to the Project Manager are going to have to ultimately answer to the authority figure. So the Project Manager is deriving power from her relationship with the Sponsor.

Reward-and-Penalty Power:

If the Project Manager is in a position to make an impact on a performer's performance review, then he has "reward-and-penalty power." The performance review is going to have some impact on salaries, raises, promotions—and that gives the Project Manager a degree of authority.

Content Authority:

A Content Expert is seen as an authority on a subject. This often gains respect and gives her some ability to get people to act on her decisions based on her perceived knowledge.

The Kick-Off Meeting

Kicking-Off the Project

Project Kick-Off is the start-up of the project. The project is kicked-off when the Project Manager is given authorization to proceed.

Kinds of Kick-Off Meetings

In large complex projects there may be several Kick-Off Meetings – for example, a Pre-planning Meeting to address scope definition and major constraints, a Team Development Meeting to get the team oriented and get feedback, an Internal Team Meeting to bring the key functional group and team members up to date on plans and constraints, and an External Meeting to present the plan to the client. Each type of Kick-Off Meeting would involve attendees appropriate to the purpose of the meeting.

Why Have a Kick-Off Meeting?

Kick-Off Meetings are held to:

1. Communicate and ensure mutual understanding of the nature of the project (objectives, constraints, plans, roles and responsibilities, etc.)

2. Have people meet one another to promote team building and interpersonal bonding

3. Communicate the way the project will be carried out (procedures, norms, etc.)

4. Get feedback and commitment from team members (including the client)

PM Basics


Who Should Attend?

Project Manager (PM)

PM’s Manager

Core Team Members

Senior Sponsor (to give “opening pitch” or motivational speech – optional)

Client (depending on the nature of the relationship and purpose of the meeting)

When?

Kick-Off Meetings happen at the outset of the project and possibly each time there is a new phase and/or significant change in the make-up of the team. As we have noted in the overview to the Initiating Process Group, the Kick-Off Meeting implies that some planning has been done, therefore one could say it is a part of the Planning Process Group. Either way, it is something that is associated with the conscious start-up of a project. The more conscious the start-up, the smoother the project is likely to proceed.

Keys to a Successful Kick-Off Meeting

Upfront planning

Establishing a foundation of standards, procedures, and norms for teams to evaluate and critique (and hopefully accept) at the meeting

Ability to gain buy-in for standards, procedures, and norms

Hot Tip: Use "Straight Talk"

Straight Talk essentially means candor. Using it means raising uncomfortable topics and confronting and challenging others. It also means highlighting other people's accountability when necessary.

One of the best things you can do at a Kick-Off Meeting is to raise issues like straight talk and make it clear that the project team is expected to work effectively together within a pre-established framework. When someone thinks things aren't going well, they should feel safe to raise it as an issue.

However, just because you've decided to operate in a particular way doesn't mean there isn't room for improvement or change. Be open to continuous improvement throughout the project's life.

The Kick-Off Agenda

Give the Team its Mission. Describe the project's objectives, including business objectives, justification for the project, product deliverables, and the scope—what's in it and what's not. Present the mission and address questions. Project plans (at varying levels of detail depending on the type of Kick-Off meeting) should be presented and discussed.

Address Roles and Responsibilities. Make sure team members know their roles and the roles of others on the team. Make sure everyone knows what he, and everyone else, is going to be doing to make sure nothing falls through the cracks, and that there is no undesired overlap.

Establish Modus Operandi (M.O.) Bring to the meeting a foundation for how the Project Team will make decisions, manage meetings, resolve conflicts, escalate (bring to higher authority) conflicts when necessary, etc. Include what procedures, tools and techniques will be used and what standards and procedures will be followed for everything from status reporting to testing and change control. Have the team contribute to or change the foundation you've established in the meeting. Establishing norms is an integral part of this process.

Establish Norms. Part of establishing the M.O. is creating group norms. Norms are acceptable behaviors within the team. They may be common across an entire organization or there may be significant differences from team to team. Norms range from how long is it acceptable to wait before responding to voice or email messages to specific dress codes.

PM Basics


Hot Tip: Plan for Process Review Along The Way

Refine the way the team operates along the way. Evaluate performance and change operating procedures as needed.

Project Organization Structure

Project Organization Structure

The Sponsor and the Steering Committee are clearly at the top of the hierarchy on a project. But when it comes to completing the tasks in a project, you need a structure that supports effective project management. Matrix structures that are staffed and performed by people representing several functional organizations or vendors are common.

Most importantly, the Project Manager is clearly recognized as the single point of contact and is accountable for the project. The Project Manager must have a reasonable degree of autonomy from Functional Managers and enough authority to get the job done without pleading and threatening.

Organization Relationships & Determining Project Organization Structure

Organization Relationships

Functional Manager, Product Manager and Project Manager “Team”

The Functional Manager is like a contractor or provider of resources to the project while the Product Manager is responsible for the product throughout its life cycle. Product Managers may be called Business Managers when the project is an in-house one for a particular business area.

Sometimes, the Project Manager and the Product/Business Manager work side-by-side to complete the project. Direct reports to the Product/Business Manager in this case also report to the Project Manager. The Project Manager’s responsibility is to make sure that the product is a success, while the Project Manager is making sure the product is completed according to the competing demands – quality, schedule (time) and budget (cost). Both have the goal of ensuring client satisfaction.

Performers Report to Project Manager

In this case, the Performers are directed and controlled by the Project Manager. They are accountable directly to the Project Manager for the work they are performing on the project.

The performers may be from a Functional Group or from an outside Vendor but, for their work on the project, they take direction from the PM. This type of arrangement is called a Projectized Structure, as we noted when discussing Matrix Organization.

Functional Groups as Subcontractors

If a department is acting as a subcontractor for the project, the staff can report to their own Functional Manager for direction, and the Functional Manager reports into the Project Manager.

Internal functional groups are subcontractors to the project, just as vendors may be.

Determining Project Organization Structure

Questions to ask to determine Project Organization Structure Tip: Use small Sub-groups

Who makes the decisions? At what level of hierarchy?

What are the escalation paths for conflict resolution?

How do we escalate (bring issues to higher authority for resolution)?

PM Basics


How does project organization affect communications with Clients and Users?

What is the Client/User responsible for?

How is the work of external groups controlled?

Who is responsible for the project outcome? For interim outcomes?

Is the organization structure adding value or getting in the way?

If it is getting in the way, what can be done about it?

Authority above the Project Manager

Executive Committee:

Responsibilities:

Exception-driven (business, project exceptions)

Oversight, guidance, barrier removal (beyond scope of Steering Committee)

Active cross-organizational involvement of Executives

Guidance over logically related projects

Deal with:

Cross-functional barriers

Problems

Receive:

High-level status

Escalation requests, if necessary

Steering Committee

Responsibilities:

Oversight, guidance, barrier removal

Active cross-organizational involvement of Executives

Provide approval to proceed by phase

Sponsor

Responsibilities:

Oversight, guidance, barrier removal

Funding

Peer-level relationship with client

Membership in the Steering Committee

Project Team

Responsibilities:

Project-level planning, execution, control and close-out

PM Basics


Aligning Expectations

Keeping Stakeholders "On the Same Page"

Aligning and Managing Expectations

At every stage of a project it is important to make sure that everyone who has a stake in it has the same expectations for scope, schedule, costs, quality, resources and risk – the project’s competing constraints.

That's why, in the early phases of a project (e.g., Initiating, Requirements Definition), it is critical to clearly define the Scope, Requirements, and Acceptance Criteria. Later, as more detailed planning is done, the project team sets specific expectations to meet the project’s three major objectives – Scope, Schedule and Cost. These become the project baselines.

As things move forward, the Project Manager can compare project status with any of these three baselines to see if expectations are being met. At the end, it should be a "no-brainer" to determine if the product is acceptable.

Product Scope: Products and services expected as a result of the project.

Requirements: Quality and performance specifications of project deliverables.

Acceptance Criteria: The basis upon which the product will be deemed suitable for use by the Client and other approvers and upon which the Client and other approvers will decide to pay for the product.

The Importance of Objectives

The project's objectives are the key to keeping everyone aligned within the project. They should be the basis for all decisions. When faced with a tough decision ask: How will this affect our ability to meet our objectives? (For more information, see Initiating: Describing the Project: Setting Objectives.)

Negotiating

Getting everyone on the same wavelength regarding expectations means negotiating. If, during the course of the project, one of the Stakeholders wishes to change one of the agreed upon expectations or constraints (like reducing the budget for a deliverable or getting the project done a week earlier) the Project Manager will need to renegotiate.

Negotiation is covered in more detail in this course under Planning and Executing.

Making the Go/No-Go Decision

Making the Go/No-Go Decision

Decision to Proceed

Projects begin with a decision made by key stakeholders (the Client and the Sponsor among other members of the Management team). The decision is often reevaluated at major milestones, usually at the ends of phases.

The decision, if it is to proceed, results in the authorization for the Project Manager to spend money and use resources to perform the project work. Often the authorization is to proceed only with the first phase of the project and to return for authorization to proceed with the next phase(s). This is often referred to as incremental funding. The initial authorization to proceed is expressed in a Project Charter document that is signed by the appropriate authority or authorities. Subsequent decisions to proceed should be documented.

PM Basics


Decision Criteria

The decision to proceed with a project is made by evaluating the following criteria:

Expected cost vs. expected benefits (financial and other)

Risk and feasibility

Strategic importance

Regulatory compliance

Tasks may be compared with one another to prioritize them regarding the use of limited resources.

Evaluation Requires Effort before the Project is Authorized

Work is necessary to evaluate the project. While this work is part of Initiating it may not be part of the project budget—which doesn't exist until the decision to initiate it has been made. The description of the project may be called a Proposal, Statement of Work or Charter. The critical content is the presentation of the "business case" for the project. This might be prepared by a proposal team, the person who will manage the project or by others with the appropriate time, knowledge and skills.

An orderly, well-defined procedure for initiating projects is critical to ensure that the right tasks are performed.

Incremental Funding—Phase by Phase to the Next Checkpoint

To avoid unnecessary expenditures, large projects should be funded (initiated) incrementally. The initial authorization will be to proceed to a predefined checkpoint or "gate"—for example, a point when detailed requirements definition or design has been done. At this point, based on what is known about the product, performance options, revised cost and time estimates, and the current situation, the initiating authority will make a Go/No-Go decision either to initiate the next phase of the project, to redirect, or to end the project.

In effect, each phase of a project can have an initiation as if it were a project in itself.

Remember, it is better to end a project after a phase or two has been performed, than to take it to the end—if taking it to the end will waste time and money. The Go/No-Go decision is more complex when the project is being performed under contract between a Client and one or more Vendors. Canceling such a project may require agreement by all parties to the contract. Penalties and damages may be incurred. These issues must be considered in making the decision.

Projects to Support Strategic Plans

Projects in organizations should align with strategic plans. Given that projects are trying to accomplish Organizational Objectives, the organization's high-level goals and strategies should be the source of Project Initiations. It is often a waste of time and money to undertake a project that is not clearly defined as a means to the end of achieving a high-level goal within the organization's strategic plan.

PM Basics


Planning: Overview

Planning Basics

The Planning Process Group consists of “Those processes required to establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve”.


Since starting again is rarely an option, here are a few ideas to think about before you get in too deep!

1. Planning creates and maintains a workable approach to accomplishing project objectives.

2. Plan the work in order to model the project and choose the best approach.

3. Work the plan to ensure that the project is under control and being performed effectively.

4. Maintain the plan to ensure that it is the most accurate prediction of the project outcome.

Negotiating Realistic Estimates

Remember: Estimates are not 100% accurate. It is better to express estimates in ranges that recognize the degree of expected variance than to stand by and watch a 'set-in-stone' estimate crumble in the face of a harder reality.

Estimates must be based on reality. Anyone can come up with an estimate that satisfies the Client's desires for a product within some time and cost constraints, as long as they don't have to actualize the estimate. If you want to have an estimate that satisfies the Client's desires and is likely to be actualized, then you have to negotiate based on reality.

To determine how long the project will take and how much it will cost, it is often necessary to negotiate with the Client to come up with a plan that satisfies business requirements and can be successfully adhered to.

PM Basics


Keep These Points In Mind:

It is impossible to do the impossible.

The earlier bad news is known, the better—it is better to know early in the project whether the target date can be met or whether the budget is big enough.

You can negotiate a win/win solution.

Avoid haggling: negotiate instead—haggling is changing your position without a rational basis.

Make your plan on the basis of rational assumptions.

Assumptions and Scenarios

Estimates are based on assumptions about the nature of the product, the workers, the tools and techniques to be used, and the work environment. Make realistic assumptions and vary them to come up with different scenarios. Generally, you want an optimistic, a most likely, and a pessimistic scenario. These scenarios become the starting points for your negotiation.

Do Your Homework

Do your homework—come equipped with your plan, your assumptions and justification for your assumptions, in writing.

Schedule and Budget = f (resources, technique, product, environment)

The schedule and the budget are functions of the four independent variables.

Negotiation

Often the Client, Sponsor or other Stakeholders want your original estimate to be reduced. To reduce the time and cost estimate, something other than the time and cost has to change. If you just change the time and cost, the estimate might look good, but it will be unrealistic. Further, if you go in with an estimate and then change it arbitrarily, your credibility is lost. Your Client starts to think that there's no limit to the amount of time and budget can be trimmed or that you've really got a lot of "fat" in your estimate. So stop haggling and start negotiating.

The Negotiation Process

Go into the negotiation with the idea that by making trade-offs, you may be able to satisfy budget and schedule constraints and still have a rational and realistic estimate. "Rational and realistic" means there is a good chance of actually performing the work as planned.

Document your thinking

State your assumptions

o The task list

o The resource assignments

o The expected environment

o Your approach/technique

o The product definition

Negotiate with your Client and/or management by discussing trade-offs and presenting various scenarios

For more information on negotiating, see the topic on Conflict Resolution, in the Executing section.

Don’t Cave In

Don't cave in. You, the Project Manager, as a negotiator have little or no leverage, so the tendency is to cave in. But that knee-jerk reaction has unintended consequences. For example, if you say, "Okay, we’ll do

PM Basics


it in half the time," the other party has the sense that your initial plan was worthless. How could you possibly say that you're going to be able to do it in less time unless you built in a lot of "fat" in that original plan? So, present your plan and firmly, but flexibly, work together to see how you can make resources, technique, product and/or environment adjustments to reduce the schedule and budget or get the Client to agree to the higher price and longer duration. Your strength is in the documented logical rationale that your plan was based upon.

Competing Constraints on the Project Management

Competing constraints, as described earlier, are the basic objectives and/or limiting factors of the project. In the very beginning, they represent wants: "I, the Client, want this product by this time for this cost, regardless of how many resources it takes or at what risk to give me top quality."

Later, these constraints represent the plan: "This is how long we, the project planners, think it will take to create the product at specified quality, with this many people working on the project, this is how much it will cost, and these are the risks involved." The plan results from assessment and a negotiation that seeks to make sure that the Competing Constraints are "balanced" — that the product can be delivered within the time, cost, and other constraints. The negotiation may trade off product features and functions to meet time and/or cost constraints or vice versa. Quality, risks and resources factor into the equation as well.

When the product is finished, we have the actual results: The product is delivered with these features and we know how much time, people, and money it took to deliver it at the actual quality achieved. And we know which risks we need to plan for next time. The goal in creating the project management plan is to create one that is most likely to be actualized.

The Project Management Plan

What is a Project Management Plan?

Officially, the project management plan is “The document that describes how the project will be executed monitored, and controlled.”

PMBOK® Guide – Fifth Edition, Glossary

Planning creates and maintains a workable approach to accomplishing project objectives. Outcomes of planning include: activity lists and descriptions, schedules, budgets, and associated resource requirements that identify time and cost estimates. The Project Management Plan includes all of the procedures, standards, methodologies and tools to ensure effective project performance.

Developing the Project Management Plan

The following steps are performed to develop the Project Management Plan. The activity is iterative and nonlinear – “what ifs?” are asked to evaluate alternatives for each of the parameters that affect the schedule and budget until an acceptable outcome is found:

Review the Project Charter and other relevant information

Collect Requirements

Prepare the Project Scope Statement

Create the Work Breakdown Structure (use a relevant template, if possible)

Describe specific project activities

Identify roles and responsibilities

Estimate effort and activity durations

Develop the project schedule network diagram

Allocate and level resources

PM Basics


Contents of a Project Management Plan

A typical Project Management Plan consists of the following items:

Objectives and constraints

Product description

Project management approach

Activities (WBS and descriptions including costs, schedules, and responsibilities for each activity to the level of detail at which the project will be controlled)

Role and responsibility assignments

Staffing management plan, and resource calendar

Project schedule – including major milestones

Project Budget

Risk register and the Risk Management Plan

Plans and procedures including:

o Change management

o Issues management

o Communications and reporting

o Procurement

o Documentation management

o Meetings

o Deployment

Baseline Plan

The Baseline Plan (also called the Performance Measurement Baseline) is the version of the plan upon which you base your assessments of how well the project is moving forward. The product scope baseline is a description of the product. It is the requirements definition and design specification. The schedule and budget baselines are the schedules and budget you are using to control the project.

The Baseline Plan should only be changed when it is no longer useful, such as when variances are so dramatic that there is no chance of getting back on the original track. When there is the possibility of getting back on track, retaining the original baseline (while annotating the plan to show slippage and its impact) can act as a motivator for extra performance that allows the target to be hit. When the baseline is changed, retain the old baseline to use for lessons-learned analysis – explaining why the baseline needed to be changed and how that might have been avoided.

The Performance Baseline

The Performance Baseline results from the planning. It is made up of the scope (product) definition, schedule and budget. All three are used in controlling the project and are the baseline plan that will be followed to execute the project.

Summary of Planning Techniques

In planning the project, the principle techniques, which will be described in more detail later in this section, are:

The WBS—for task analysis

The RAM—for role and responsibility assignment

Top-down and bottom-up estimating approaches

Negotiating estimates—the negotiation points

The Network Diagram—for sequencing using dependency analysis

PM Basics


The Bar or Gantt Chart—for scheduling

Resource Loading and Leveling

Fast Tracking—to compress the schedule

Crashing—to compress the schedule

Risk Management—to determine the degree of uncertainty and plan for contingencies

Remember: Plan the work and work the plan.

Make your estimates realistic. The goal is to actualize the estimate, not to give the Client false expectations.

Procedural Planning, Project Administration

The Communication Plan

Plan the way you will communicate to avoid chaos and confusion. Projects involve the transfer, use and retention of information. The more clearly and concisely you communicate and manage the information in your project, the fewer problems you'll have. The solutions to the ones you do have will come much more quickly and more pleasantly.

(For more information, see Job Aids: Communications Plan.)

The Communication Plan

Contains the set of basic rules for the project management team; regarding who decides what, who tells who what, how they file and retrieve information, and how they manage documents.

Establishes the concrete aspects of project management communication.

Sets up rules for notifying others about changes to the Project Management Plan.

Decides which media (e.g., e-mail, written documents) will be used for project plan communication and how they will be used (e.g., one topic per e-mail).

Ensures that people use the same terms for the same tasks and/or product components when they communicate about the project.

Identifies the information requirements and the process by which they are filled.

Identifies the information needs of the Stakeholders and the way they will be fulfilled.

A Communication Plan Should Include:

Media—e-mail, documentation applications and collaboration tools

A filing and retrieval system

Document management

Project language—WBS and product definition

Subject area responsibility—decision makers and people with a need to know

Form and content

A schedule

Responsibility for providing data and reporting progress and status

PM Basics


What Should Be Written

Here is a list of the things that should be written (1) to ensure that project communication stays clear and (2) so you avoid rework, confusion and unnecessary conflict.

What Should Be Written?

Project Management Plan

Project standards and procedures

Change requests, logs and resolutions

Status reports and plan changes

Key issues and decisions with back-up

Specification and design documentation

Role and responsibility agreements

Approvals and contracts

Project Charter

Requirements Documentation

The Procurement Plan

The Procurement Plan addresses the methods for the selection and purchasing of project products and/or services. It must proactively identify possible needs for products and services. It must also establish standards and procedures for:

Performing "Make-or-buy" decisions

Identifying and selecting prospective suppliers (internal and external)

Preparing procurement documents such as Requests for Proposal (RFPs)

Establishing weighted selection criteria

Making purchasing decisions (including authority to commit)

Contracting

Managing the contract

Company Policy and Procedure

Most organizations have definite policies and procedures regarding procurement (or acquisitions, purchasing, etc.). Be sure you are aware of them. Consult with the Purchasing Group. Evaluate the standard processes to see if they serve the purposes required for your project.

If they don't, see how you can get a formal variance (permission to operate in a different way, under different limitations) to make the project more effective, while not violating policies and procedures. Needless to say, all the footwork can be quite a balancing act.

The Quality Plan

The Quality Plan

Describes how the project team will handle:

Quality Assurance (Making sure standards and procedures are complied with and effective.)

Quality Control (Making sure deliverables comply with acceptance criteria. It includes testing and reviews.)

Process Improvement during the project.

PM Basics


Basic Principles:

Do it right the first time, if you can.

Check interim work results frequently, based on preset acceptance criteria.

Find and address errors and omissions as early as possible in project's life.

The later errors are found, the more they cost in time and money.

When you find an error or omission, record the cause and describe it.

The Quality Plan should be comprehensive and contain explicit detail about the following items:

Standards and compliance monitoring and audit.

o We're not suggesting the "quality police"—self monitoring is best. Without some monitoring, the tendency is to lose the disciplines that the standards provide.

o Don't be rigid. Standards and procedures are there to make things easier, faster, better. If they don't, they need to be changed. Avoid bureaucracy.

Major checkpoints / review point requirements.

o Here's where people from outside the project—Steering Group, expert reviewers, etc.—decide whether to continue the project by looking at major interim deliverables, such as the project requirements document and the product design, to see if they're acceptable.

o They also decide whether to continue the project.

Deliverable review and inspection of acceptance criteria, roles and responsibilities and schedules.

o Reviews and inspections validate interim deliverables—or small parts of the product design or plan.

o Can be internal or external to the project team.

Test planning and testing strategy.

o Who will do the testing, what will they test, how will they test it, and how will they record and measure results?

o What authority will they have? Will they report to the PM?

Library and configuration management.

o Keeping track of product components, including documents

o May occur at varying levels of completion and in varying levels of revision.

Measurement.

o How will Stakeholders determine objectively whether the project team met its objectives and whether the process they used was effective?

o What criteria will they use and what data?

Issues Management Procedures

Issues Management Procedures identify the way issues that arise during the project are recorded, assigned, tracked and resolved. Some firms refer to issues as “action items”.

PM Basics


Issues Management Checklist

Issues are Problems that Arise During the Project that Require:

- Project Manager or group leader intervention, and/or,

- More than a few person hours to resolve

Issues May Be:

- Technical problems

- Requirements-related questions pending Client response

- Environmental problems requiring support group response

- Mid-project management plan and estimate revisions

Issues Management Process:

- Identify and define issues

- Document each issue on an outstanding issue form or memo

- Log each in an issues control log to permit easy reference and tracking

- Assign each issue to a responsible individual or consciously postpone addressing it

- Monitor progress

- Close out resolved issues

- Review unresolved issues to determine status and the need for acting upon postponed issues

Issue Documentation:

- Each issue should be described in terms of the following attributes (see the sample form below):

- Identification (number)

- Date identified

- Initiator name(s)

- Title/brief description

- Definition of the issue

- Significance of the issue on the project (priority)

- Target date for resolution

- Responsible individual(s)

- Action plan

- Status (e.g., postponed to a specific date, in-process, resolved)

- Next checkpoint for feedback and review

- Resolution

- Back-up information (e.g., correspondence, decision papers, research materials, etc.)

PM Basics


Product Definition

Defining the Product

Every project produces an outcome or series of outcomes. These outcomes take the form of interim deliverables and final deliverables or products. The product baseline is used to stabilize the project. It is set when the Client is satisfied that the Requirements Definition meets business objectives. Product Scope Change Management is used to identify and control any changes to the product scope baseline.

The description of these deliverables and products, stipulating what they will look like when they are finished, represents what we earlier called the product scope baseline. An accurate and complete description of this is crucial to success.

Do not speed through the requirements definition and design so you can get into the "real" work! Defining the product is as much "real" work as building it.

Statement of Work

The Statement of Work document is a narrative description of both the deliverables of the project and the conditions under which they must be delivered. It is a high-level description of the product definition. Ultimately, the complete description of the product will be made up of the requirements definition and product design documents.

Requirements Definition

The Requirements Definition spells out the functionality, data and performance requirements of the product. It is used during product design to determine what kind of product is needed to fulfill the requirements. The acceptance criteria, those qualities of the product which must be present for the product to be accepted, are also defined.

The question, "What is a quality product?" is answered by referring to the product's requirements and design documentation. It is critical that the requirements are detailed enough to identify and define all quality characteristics and the measures for determining if they are present to the expected degree. A quality product is one that fulfills its requirements.

Product Design

The Product Design describes how the requirements will be met. It consists of drawings, procedures, prototypes, and detailed specifications. The design directs the development, or implementation, of the product.

Proper Client Involvement

If the Client is not integrally involved in setting and approving requirements and designs early in project life, the end product may be rejected or not satisfy objectives, even if it satisfies stated requirements.

In most projects, the Client is responsible for defining and accepting requirement definitions (the expression of project objectives) and making change management decisions. The Client is also responsible for the acceptance of the project result (the product). While the Client might not physically write the requirements, they are responsible for the content.

Other responsibilities of the client may include:

To plan and perform the actual implementation.

To provide resources and information throughout the project's life.

PM Basics


The Client/User Role

Set objectives

Describe requirements

Approve requirements definition

Take part in test and implementation planning

Provide human and other resources for testing

Accept the product

Use, sell and/or enjoy the product

Actively integrate the product in use to achieve business objectives

Food For Thought-Serving Clients

Clients and the ultimate users of the product are generally engaged in other activities. The project is an additional effort. They may not be at all experienced in project work. They may have no technical expertise in the core technology or content area of the project. Some may not even want the product, seeing it as anything from a threat to a waste of time and effort.

Make Clients and users an integral part of the project. Clearly identify their roles and responsibilities. Clarify their accountability and the consequences of not adequately performing their role. Hold their hand and guide them through the project. Take as much work off their shoulders as possible (given cost and time constraints). Don't underestimate their intelligence and ability to learn. Make use of their business wisdom. Facilitate change.

Managing Scope Change

Definition

Product scope is the sum of the products, services, and results that the project is to provide. Scope change is any addition to or subtraction from the initial product scope and it almost always requires that you adjust the project cost or schedule. Remember, the scope of product is the principle driver of cost and schedule.

Causes of Scope Change

Scope change can be caused by:

Business changes

Technical changes

Unknown or undefined requirements

Errors and omissions in requirements and design

Personalities — new people joining the project team and making changes

The Need to Control Scope Change

Scope change is a cause of slippage. "Scope creep" is the slow increase in project scope caused by making many small changes in an uncontrolled way.

However, it only causes a slippage if there's more change than expected. Therefore, part of the planning should be to consider the expected amount of change, given the nature of the product, service or result, the people defining it, the process they are using, and the nature of the environment.

Comprehensive and complete requirements and designs can minimize scope change. A good change management procedure also minimizes scope change's effect on the project.

PM Basics


(For a comprehensive discussion on scope change procedures, see Executing: Making It Happen — Hard Skills: Change Management.)

The scope baseline is used as the point of reference for quality control and change management.

Quality Control

Quality Control (QC) is performed to ensure the product and interim deliverables are acceptable. QC consists of technical reviews, both internal and external, and tests. The scope baseline is used as the point of reference for QC.

Quality Control should be performed incrementally throughout the project life cycle so that defects (errors and omissions) can be identified as early as possible. The earlier in the life cycle a defect is found, the less costly it is to correct.

Task Analysis and Work Breakdown Structure

The Work Breakdown Structure

What the WBS Is

Officially, the WBS is “A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables”.


The Work Breakdown Structure (WBS) is at the center of the Project Management Plan. Estimating, scheduling, resource assignment, quality management and project control all rely on the WBS.

Think of the WBS as a deliverables-oriented hierarchy of project elements that defines the project. Project elements may be deliverables and their components, or the work (tasks) required to create them.

Major Elements of the Project

The major elements of the project may be defined as major deliverables (product components) or major process steps or phases. When we are following a Project Life Cycle standard, the major elements will likely be predefined, usually in terms of phases.

How It Is Created—Task Identification and Breakdown

The WBS is created by identifying the major elements of the project and breaking them down into increasingly detailed levels.

We call this identification task analysis. (For more information on the process used to identify the tasks and construct the WBS, see Task Decomposition. For an outline containing the elements that describe each task, see Task Descriptions.)

Task Decomposition

What is a task?

A task is any effort to achieve an objective. Given that definition, we could say that a project is a task. Everything we do in the project is a task.

To make for easier communications, we create some terminology and definitions that differentiate between tasks at different levels of detail in the WBS.

PM Basics


o If it is a very high-level task – very big and complex – we might call it a project or a phase.

o If it is of moderate size and is the breakdown of a phase, we could call it an activity.

o When we break an activity down, the result is a set of tasks (note that by convention, we use the term task in a more limited way here).

o Tasks break down into sub-tasks. And so on.

o There is no universal standard for the names of the various levels of breakdown. We’ll use phase, activity, task, and sub-task. We will also use “task” in the more generic sense, so watch out.

Task Analysis vs. Task Decomposition

Task Analysis is the process of identifying and describing the tasks required to achieve an objective. It is necessary as a preparation for estimating, scheduling, and responsibility assignment.

Task Decomposition is the activity in which the high-level tasks (phases and major activities) are broken down into more detailed tasks. Task Decomposition results in the Work Breakdown Structure (WBS) and the description of each element in it.

Identifying the major elements of the project and the task

The major elements of the project (the higher levels of the WBS) are identified by analyzing the product and basing the breakdown of the project on product components or by analyzing the process and basing the breakdown on the major steps to be performed. In either case, the resulting tasks must each have one or more deliverables.

For example, in a project to develop a new service, the top-level breakdown could be: Facilities, Procedures, Equipment, Documentation, Training, and Deployment. These phases break down the project in terms of the major deliverables. We’d make sure we added an element to cover project management and administration.

The same project could be broken down into the following phases: Initiation, Requirement Definition, Design, Development, Implementation and Completion. These are the major process steps in the Project Life Cycle.

Task Decomposition

Task Decomposition is breaking a task into its component parts or sub-tasks.

When a task is divided into sub-tasks, the task must be fully defined by the sum of the sub-tasks. The task becomes a label or summary for the work defined by the sub-task.

Note: Don’t leave any tasks out when doing Task Decomposition. If you do, you will still have to do them but you won’t have planned for them. Omitting tasks during this process will make executing the project more difficult.

How low do you go? – Task size

The depth (number of levels of detail) of your WBS depends on the size of your product.

The degree of detail is referred to as granularity.

The lowest level of task detail used for product planning and control is referred to as the Work Packages. It generally (there are no fixed rules here) is about a week or so in duration, associated with a single deliverable, and assigned to single functional area or individual. Estimating, accounting and control are done at the Work Package level.

FAQ: Why a week or so in duration?

A week is the general rule for the Work Package level. The performer might do a finer breakdown or there might be a standard operating procedure that identifies the steps in performing a task.

PM Basics


We say a week or so (up to two weeks) because, in most projects, if you identify a performance problem, within a week or so, you can usually respond to it effectively without losing much ground in the project. Weekly to biweekly evaluation also minimizes reporting effort and interruptions – it is costly to ask people for status and progress information every day, or every hour, or whenever you get anxious.

Of course, there are exceptions. Some projects and some parts of projects call for far more frequent control interventions – for example, during the rollout of a complex new business process or the start-up of manufacturing a new product. Here we might break the work down into tasks that could be an hour or a day in duration.

Sometimes, we can justify tasks that are up to two weeks in duration. However, as the duration of a task increases, the risk increases. Further, estimating smaller tasks is usually easier and more accurate that estimating large complex ones.

Task Decomposition Guide

Name each task: Use verbs and nouns to connote the action and deliverable (e.g., “Design the Product”).

Describe each task.

Number each task to show its level in the WBS (e.g., 3.5.1).

Make sure that each level of detail contains tasks which completely accomplish the higher-order task which being decomposed.

Make sure there are no extra tasks (there’s enough to do).

Make sure tasks are logically organized.

Limit yourself to 2-7 tasks per level of detail.

Define each task to result in a material outcome, or deliverable.

Stop decomposition (for individual/short plans) when sub-tasks can be accomplished by an individual or small group within one week (see Work Package).

Ignore sequence, schedule, and dependency at first (just identify the tasks).

Use a standard task list (Project Life Cycle) to start the analysis.

Make sure responsibility is defined for every task.

Task Descriptions

Once the tasks have been identified, each must be described using the template. The description includes items that result from subsequent steps in the planning process (for example, duration and effort estimate).

Many of the items in the definition come out of the estimating and scheduling process. The current effort estimate to completion and the actuals are filled in as the project is being executed.

Task Deliverables

A deliverable is concrete evidence that work has been done. Every task has to have at least one deliverable associated with it and the deliverable has to be either a final product or something that's useful as a building block towards the next step(s) in the project.

If you do work without having a deliverable, you may be wasting your time.

Types of Deliverables

A deliverable may be a statement of work, a requirements document, a meeting agenda, a design specification, a widget, a test plan, you name it. It just has to be material — not a concept. Someone other than the producer must be able to read it, evaluate it and use it.

PM Basics


Acceptance Criteria

Every deliverable should have a set of consciously defined Acceptance Criteria. The producer should know these before the work on the task begins. Acceptance Criteria might include size, level of detail, media, format, compliance with some standards, and compliance with technical constraints.

If the deliverable is accepted, the task is done.

How Much Will This Cost & How Long Will This Take?

Overview

Once the tasks are identified, they must be estimated. The estimate will tell you how much effort is required and how long each task will take. Task estimates should be added to the task descriptions.

Iterative Refinement

Estimating is an iterative refinement process. This means that estimates must be reassessed at various points during the project's life, to make sure that they correspond to the reality of the project's progress.

Remember that estimates are not actuals. We get the actuals (how long it took and how much it cost), after we've done the work. Until then there is uncertainty. Therefore, we may present estimates in ranges, as opposed to single amounts.

Also, while it seems as if the planning process moves neatly from determining cost and task duration to sequencing and resource loading/leveling, it doesn't. As you schedule, you often need to reallocate resources, which then requires that you reassess the effort and duration of individual tasks (which are based on assumptions about how many resources of what skill-level are assigned). Estimating is really a single, complex process in which you play "what-if" games to test a number of scenarios in order to find the one that is best for your project.

We break the process up into individual steps for ease of learning:

1. Task level effort and duration estimating

2. Sequencing

3. Resource loading/leveling

But remember, estimating, sequencing and resource allocation/leveling are done interactively.

Top-down and Bottom-up Estimates

Top-down estimates look at the project as a whole, at major phases, to decide (on the basis of past experience) how much and how long the project will take. Usually these are done early in the life of a project.

A bottom-up estimate is made by estimating tasks at a relatively detailed level of the WBS and then rolling up the estimates to obtain estimates for the higher levels.

Generally, top-down estimates are made in the early stages of the project and bottom-up estimates are made for the work to be performed in the next phase of the project; what we call short-term estimating.

Top-Down Estimating Approaches

Analogous

The analogous approach uses other similar projects as the basis for estimating the current one. Adjustments are made for differences. You need to keep a history of project outcomes and descriptions of the projects in terms of various factors that influence the estimate.

PM Basics


Factors influencing the estimate might be:

Mode of development

Product quality

Size of product and project

Complexity of product

Resources

Tools and techniques

Parametric

The parametric approach is to find certain attributes of the project that can then be used in an algorithm to actually calculate the outcome. Let's say you're installing a phone network and there are a number of phone sets in the network and a number of features like call waiting or message taking. If you multiply the number of phones by a factor and the number of features by another factor and then add some other factor to the sum of the products to that and multiply by the number of people that are going to work on the project, divide by another factor, you get the project estimate.

In the construction industry, for example, given the number of square feet in a building, the location and the basic materials, you can apply an algorithm to make a fairly accurate estimate. There are estimation databases for use in the estimating.

Estimating algorithms are developed based on many project experiences using databases and correlation analysis. They are unique to a type of project and an industry.

Expert Estimates

Expert estimates are based on the experience of the estimators, generally without significant recorded historical data. While these can be accurate, their accuracy depends on the skill of the estimators and their memory. It is best to do expert estimating in small groups. The interactive dialogue among the estimators improves the accuracy of the estimate.

Bottom-up Estimating

Estimate at a detailed task level: the smaller the task the easier it is to estimate the effort and time required.

Performers or experts should provide task estimates.

Do not overlook indirect costs (overhead).

Detailed estimating requires effort: e.g., task analysis, individual estimates.

Use standard estimates (based on past experience on similar tasks) as much as possible.

Effort & Task Duration

To get ready for scheduling and estimating the costs of the project, you've got to estimate the effort and duration of the tasks. The effort and duration of a task must be estimated in conjunction with one another. The following factors must be taken into account:

Task size

Task complexity

Human resource skill and experience level

The number of resources (human and other) on the task

Resource availability

The relationship between resources

Initial learning curve

Start/stop time (ramp-up/ramp-down)

PM Basics


Effort is the amount of work required to get a task (or project) done. It is measured in resource units (like person days or man hours).

Duration is how long it will take in calendar time (e.g., days, weeks or months).

Generally, we first estimate the effort based on an assumed number of human resources of an assumed level of skill. Then we figure out a preliminary duration by dividing the number of resources into the effort. Finally, the factors above need to be considered.

Note that some tasks will not be completely resource-driven, for example, in construction you may need to account for the time it takes for concrete to set. Adjusting the Duration, Resources and Effort

It starts getting complex when we start trying to reduce the duration. On the surface, it seems that all we've got to do is add more people. If the task requires nine person months of effort and one person can do it in nine months then nine people should be able to do it in one month.

Right? Well no. That's not right.

It depends on the task and the people and the way the people relate. Some tasks can't be done in any less than nine months, no matter how many people you put on them, while others can be shortened by adding more people.

For example, if one person can design a floor plan in a day, it might take two people two days to design the same floor plan. Or, it could take them three-quarters of a day, or three days. Why? Because of the overhead caused by their working together on a task that can't be discretely divided between them. Further, as we add more people the uncertainty of our estimate increases—there are more opportunities for things to go wrong or differently than we anticipated.

Though, if we took a task like blowing up balloons for a party, the more people we have the shorter the duration of the overall task—taking into consideration the learning curves of the people and the coordination of the placement of the balloons. Of course even in this case, we could get a lot of overhead because people might start playing with the balloons and one another, delaying the work.

In addition, adding more resources is also limited by physical constraints like space to work – desks, the number of helium canisters, etc.

Estimate Drivers

What Are We Estimating and What Factors Drive the Estimate?

So what are we estimating when we make our project estimates?

Remember the Competing Constraints that influence the project throughout its life cycle: Product Scope, Schedule, Cost, Quality, Resources and Risk.

We estimate 1) the effort required to perform the tasks needed to produce the product, 2) the duration, and 3) the budget.

Effort estimates are driven by:

The nature of the task (size, complexity, etc.)

Productivity of the performer(s)

Duration estimates are driven by:

Effort

Assignment of performers and other resources

The calendar

PM Basics


Budget estimates are driven by:

Effort (measured in resource units like person days)

The cost per unit of effort - human resource rates

Other costs (hardware, facilities, etc.)

You start with targets (what the Client would like to have happen), then you estimate to see what will probably happen. You negotiate until you have come up with a plan to satisfy the Client. Then, you do the work and see what actually happened.

Each of the areas of estimation (effort, duration, and budget) is in itself, constrained by what we call estimate drivers, respectively.

Cost Estimating—the Budget Baseline

The total effort required to perform the project is determined in the estimating and scheduling process. Until the final schedule has been decided upon, you haven’t completed the estimating because as you schedule, you will reassign resources and that may change effort estimates for individual tasks. The effort is multiplied by the rate(s) for the resources to obtain the human resource costs. These are allocated over the project duration based on where in the schedule the resources are expected to expend their effort.

Then, capital costs or costs that are associated with non-human resource elements, like equipment purchase, software license costs, etc., are added. And costs of supplies and facilities directly charged to the project are added.

Add overhead (any kind of indirect costs of management, facilities and administration) to get the total cost estimate.

This total cost estimate is spread across the project duration, based on when the expenditures are expected to be made, to form the Budget Baseline for the project.

Remember that the project's Baseline Plan is composed of three parts: the Product Scope Baseline, the Schedule Baseline and the Budget Baseline.

The Budget Baseline is used during the project's life to assess whether the budget estimates are on track for a realistic completion of the project.

Like the other baselines, it must be reassessed from time to time and changed if variances (differences between the budget and actual expenditures) are significant enough to warrant it.

Scheduling & Sequencing Tasks

Overview

Once the effort and duration of the tasks have been estimated, the schedule has to be developed. The scheduling process consists of 1) sequencing the tasks and 2) making sure that the resources are allocated so that they are not overburdened. (We don’t want to allocate more resources in a period than are available).

In this topic we focus on the sequencing and calculation of the “initial” schedule. In the topic on resource loading and leveling, we focus on the adjustment of the schedule to ensure a realistic allocation of resources. As the resource assignments are adjusted, there may be a need to go back and adjust task effort and duration estimates that may change the schedule.

An Overview of Task Dependencies

Dependency Analysis

Task dependencies are determined to sequence the tasks. By identifying the dependency relationships between tasks, you can see which tasks must or should be done one after the other, and which can be

PM Basics


done in parallel. The process of determining the relationships between the tasks is called dependency analysis. It is a critical part of the planning process. It is the part where the planners define the logical flow of the work. The Project Stakeholders are able to see how each task impacts the project as a whole. Dependency analysis must be done to determine how long the project will take.

How the Tasks Relate

In order for a Project Manager to determine the cost and duration of a project, a detailed and accurate schedule must be created. One of the key steps in creating an accurate schedule is determining how the many tasks in a project are related to one another. In other words, which tasks are dependent upon other tasks, and which are not.

Two Major Kinds of Relationships

There are two major kinds of task dependency relationships; Logical and Resource. To illustrate this, take a look below at these types of dependencies that can exist within a project.

Successor Tasks Use Deliverables from Predecessors

Remember, tasks always have deliverables. When we talk about task dependencies, we are talking about the way the deliverables of the predecessor, tasks drive the scheduling of the successor tasks.

Logical Dependencies and Network Analysis

It is the Logical Dependencies that we will work with when doing a Network Analysis and when creating a Network, or Logic, Diagram.

Logical Dependencies:

The relationship between the tasks is based on the need for one task to be performed before another can be performed.

Resource Dependencies:

The relationship between the tasks is based on two or more tasks sharing the same resources.

Mandatory vs. Discretionary

Mandatory: This relationship describes two tasks that MUST be done in a specific order. For example, you can't bury a box until you dig a hole. It is not up to your discretion which task you do first. Logic and physical necessity dictate one sequence.

Discretionary: Discretionary dependencies are based on best practices. This relationship describes two tasks that need not, but should, be done in a specific order. An example of this dependency might be: Training a new employee in your company's "Code of Conduct" before you send them out to their first client. Of course, logic might dictate that you perform one task before another (train first, and send later). But if you truly needed to, you could use your discretion and "fast track" this process, thereby increasing the risk, and send your employee out on a client engagement simultaneously asking them to complete an online training for the code of conduct while on their first assignment.

Fast tracking is suspending discretionary dependencies to perform tasks in parallel that would normally be done in sequence to compress the schedule.

Internal vs. External

Internal: An internal task dependency is defined as a task which is being worked on within the Project Manager's project team. The Project Manager would have control over this kind of task. The way in which a Project Manager would manage internal dependencies is different than the way he or she would manage external task dependencies. External dependencies generally mean less direct control and more risk of budget or schedule variance. External dependencies may require expediting and a different reporting period.

PM Basics


External: In contrast, an external task is beyond the direct reach and control of the Project Manager. For example, the Project Manager orders equipment from an outside source who, in turn, sub-contracts to a small distributor who has no knowledge of the original intent or purpose of the equipment.

The way in which a Project Manager would manage internal dependencies is different than the way she would manage external task dependencies. External dependencies generally mean less direct control and more risk of budget or schedule variance. External dependencies may require expediting and a different reporting period.

The 4 Basic Styles of Task Dependencies:

1. Finish to Start: This is the most common kind of relationship in a project. Task A has to be completed before Task B can begin. See the burying a box example above.

2. Start to Start: Task A must be started (but does not need to be completed) before Task B can begin. For example, you have to begin training new employees before you can evaluate their progress. The training, however, need not be complete before evaluation begins.

3. Finish to Finish: Task A must be completed before Task B can be completed. In this case, we might have the logging of inventory off a truck and the unloading of the same inventory. We can't finish logging until everything has been unloaded from the truck. In some cases both tasks may be required to finish at the same time.

4. Start to Finish: Task A has to be started before Task B can be finished. For example, we need to begin painting the house before someone can evaluate the color for a proper match. But the painting need not be finished before the evaluation is completed.

Using the Network Diagram to Help Sequence Tasks

A Network Diagram-or Logic Diagram-is a graphic representation of the logical sequence of project tasks. One very common type of Network Diagram is called a Precedence Diagram.

PM Basics


To illustrate how a Network Diagram works you will need data. For this example, we will use a prototype project task list for assembling a machine. To begin, take a look at this excerpt from a typical Work Breakdown Structure (WBS):

Now, before you can build your Network Diagram, take a look at the WBS excerpt again and think about these important questions:

Which relationships are mandatory and which are discretionary?

Which tasks are the predecessors/successors of other tasks?

Would you recommend fast tracking to shorten the schedule?

What are the advantages and risks of each option?

The diagram below displays the tasks from the sample project and indicates the dependencies between those tasks. Notice how large tasks like 6.3 and 6.4 are subdivided into smaller tasks. Can you think of a reason why this might be necessary? If you thought about avoiding "percentage-itis" ("I have done 55% of the job!" -where no two people can agree on what exactly "55%" is), and the need for keeping tasks linked to specific deliverables, then you are on the right track!

PM Basics


Things to think about while reviewing Network Diagrams:

How do these Network Diagrams make understanding Task Dependencies easier?

How do these concepts apply to your company?

How can these concepts be applied to your current projects?

The Gantt Chart

The Gantt Chart is a type of bar graph. It lists activities or other project elements down the left side, shows dates across the top, and displays activity durations as date-placed horizontal bars. This is a helpful tool for tracking a project's overall progress and status against the calendar. The Gantt Chart shows the relationship between the tasks in terms of their scheduled performance. If we look at the schedule and take resource and logical dependencies into consideration, we can get a sense of how changes in the schedule of one task can affect others.

Dependency relationships can be shown on the Gantt Chart and are commonly included in Gantt Charts produced by automated project management tools.

Gantt Charts are commonly used to display the project schedule. They are used in monitoring the project by highlighting which tasks are completed to graphically show progress against the schedule.

Critical Path & Slack/Float

Slack Time (or Float Time)

The time available to delay the completion of an activity without impacting the project end date. Slack is used to prioritize tasks for resource allocation (the less slack, the higher the task’s priority because it is more critical). Slack is also useful to help to determine the impact if slippage on the overall project schedule. The Slack is calculated by subtracting the Early Start Date from the Late Start Date.

Critical Path

A set of activities that determines the earliest completion of the project, in which a delay in any activity will delay the project by an equivalent amount. The Critical Path is the path with the longest duration. There can be more than one Critical Path in a project.

Duration

The length of the calendar tome the task will take to be completed.

Early Start

The Early Start Date of each task is determined by finding the path with the longest duration of the task. The Early Start Date is the date at which the task’s predecessors have all been completed.

PM Basics


Late Start

The Late Start Date is the date after which the task causes slippage of the project end date. It is determined by starting at the end of the project and working backward.

Early Finish

The Early Start Date plus the duration of the task.

Late Finish

The Late Start Date plus the duration of the task.

Calculating Early Start

Remember, the early start date of each task is determined by finding the path with the longest duration to the task. The early start date is the date at which the task's predecessors have all been completed. The early end date for a task is the early start date plus the task duration.

Calculating Late Start

Remember, the late start date is the date after which the task causes slippage of the project end date. It is determined by starting at the end of the project and working backward.

Calculating Slack and the Critical Path

Remember, slack, or float, is the time available to delay the completion of an activity without impacting the project end date. The critical path is the longest path—the path with no slack.

Resource Loading & Leveling; Compressing the Schedule

Resource Loading and Leveling

When first discussing Sequencing, we said to ignore resource dependencies (conflicting needs of tasks for shared resources). Here is where we consider them.

In scheduling, it is important that resources are not overburdened. Overburdened means that more hours are allocated than are available. Note that we are including both human and other resources. Other resources might be machines, testing environments, pieces of heavy equipment, or facilities.

The Leveling Process

Resource Leveling is an iterative process. You play "what-if" games; What if I move this resource from here to there? How will that affect the overall schedule?

The basic principles are:

Monitor resource loading to ensure that no resource is overburdened.

Prioritize Critical path activities.

Use the float to determine how to adjust resource assignments.

Adjust effort and duration when resources are changed.

Here's How It Works:

You've sequenced the tasks and computed the critical path and slack. You've laid out a first-cut schedule. Based on your task effort and duration estimates, you know the type and number of resources that are required for each task.

PM Basics


Now you (or your PM tool) compute the number of resources required in each period. You simply add up the resource requirement for each task in a period to get the total resource requirement for that period for each kind of resource or each individual performer.

If you have allocated more resources than you have available in a period, you need to make adjustments to remove the overburdened conditions. Your options are to:

Get more resources-but be careful, there may be learning curves, hiring lead times and/or facilities issues that might affect your schedule.

Have human resources work overtime-but beware of burn-out and reduced productivity and their impact on the project.

Use non-human resources on multiple shifts.

Assign people part-time tasks-this allows you to start tasks on their early start dates but will extend the duration and probably increase the effort (lower productivity because of frequent ramp-up and -down as people move between tasks).

Assign fewer people to tasks-usually the project duration increases.

Delay the start of some tasks-this extends project duration, depending on whether you use up slack and move critical tasks out in time.

Change resource assignments to maximize the use of the most effective resources on the most critical tasks.

Sometimes it can be a frustrating process-there are lots of combinations that must be tried.

Remember: Sometimes it is just not possible to deliver the product within the time and cost constraints, given the resources you have available. It is better to identify these limitations up front than to work under the delusion that you will be able to do the impossible.

FAQ – Don't the PM tools do resource leveling automatically?

They do some of it automatically, but they usually work off assumptions that are not realistic. For example, if you add additional resources to a task, you get a proportional reduction in duration and no change in effort. The tools provide assistance, but you have to do the re-estimating and shuffling of resources yourself.

FAQ – Don't you have to know how many people you have before you can sequence the tasks?

No. You sequence the tasks, based on the logical dependencies, to identify the best case schedule (assuming you will have all the resources you need to do the tasks that can be overlapped simultaneously). Afterwards, you do resource leveling and loading, which may cause you to change your estimates and your critical path.

Compressing the Schedule

There are two approaches to compressing the schedule: fast tracking and crashing.

Fast Tracking means decreasing the project duration by overlapping tasks that would not normally be overlapped.

o Fast tracking usually means an increase in risk. As a result, you might not get the savings in the time you expected, or it might mean paying higher costs later in the project life or product life.

o When fast tracking, we reassess the decisions we made about discretionary dependencies. For example, if we wanted to speed up a project to build a house, we could let people deliver the appliances while the concrete driveway was being poured, instead of having the delivery take place only after the driveway is done. The risk is that the delivery people will mess up the driveway, requiring it to be redone, thereby increasing cost and taking more time in the end.

PM Basics


o A classic (and not recommended) attempt at fast tracking, that very often misfires, is putting a product into use before it has been adequately tested.

Crashing is another means of decreasing the project duration. This means adding additional resources to the project, usually at an increase in cost and risk. Generally, cost and risk increase when we add resources to reduce duration.

We discussed the effects of adding resources to change the project duration in the topic Estimating Effort and Duration. There we show how the schedule can be adjusted by adding resources.

Allocating Resources

Different kinds of tasks will benefit from the allocation of different kinds of resources. For example, the task of interviewing applicants for a job will not become shorter if more money is thrown at it; however, more interviewers working on the task will certainly reduce its duration.

Risk Assessment & Contingency Planning

Risk Assessment

Risk Assessment is done throughout the planning process. It consists of Risk Identification and Risk Analysis.

Be Realistic

The future is always uncertain. The question answered by risk assessment is, "just how uncertain is it?"

Don't avoid looking at the dark side of your project. It will help you to avoid some of the pitfalls and reduce the impact of the ones you can't avoid. It will give you the ability to set realistic expectations with Clients and other Stakeholders.

Many people want things to be certain and unambiguous, which is a very unlikely expectation on projects. But we can provide a realistic assessment of risk and uncertainty.

Risk identification involves reviewing the project to identify areas of risk and uncertainty. What assumptions have been made? What alternative assumptions can be made? What can go wrong? What can change? What can go right?

The review can be done by any combination of the following:

Analyzing each item in the WBS

Brainstorming

Evaluating the product and its components

Evaluating the various tools and techniques to be used

Evaluating causes of slippage in past projects

Risk analysis looks at the risk events to determine the probability of their occurrence and their impact on the project (in terms of cost and time) if they occur. If numerical scales are used, we can multiply probability by impact to get the value of each risk event. The result of risk assessment is the basis for establishing contingency reserves.

Risk assessment can be qualitative, particularly in smaller projects. Qualitative risk evaluation examines the project based on a set of factors that are associated with uncertainty. The analysis can be done by assigning points to the risk factors to develop a score. Depending on the method used, the score can be used to determine whether the project is high, medium or low risk. Or, it can be used to develop the range of the estimate, by adding a factor derived from the score, to the most likely estimate to obtain a pessimistic estimate.

PM Basics


The following risk factors are common in projects. To what degree are they present in your projects? How will they affect your ability to successfully deliver your product within time and cost constraints?

New technology

Product complexity

New process, tools or methods

New staff

Large number of team members

Multiple clients

New clients

Unavailable clients

The number of approvers and their availability and accountability for delay

Part-time staff

New vendors

Uncertainty about requirements

Critical, tight target date

Long project duration

Availability of relevant historical data for estimating

Using the Results

Risk assessment results are used along with risk response planning to adjust the budget and schedule so they are more realistic.

The assessments are commonly used during project initiation as one of the major criteria in deciding whether to do a project or not. Here, risk is compared to expected reward to see if it is worth taking. It will depend on the organization's ability and propensity to take risks.

Risk Response Planning

Risk response planning is the process of determining what to do (or not to do) about the risks you have identified. Here are some choices:

Strategies for negative risks or threats:

Avoid (eliminate the cause of negative events or find another solution that eliminates the task in the plan associated with the risk).

Mitigate impact (add tasks to the plan to reduce impact, probability or both).

Transfer the risk (obtain insurance to eliminate the cost burden of negative events, or use a vendor with a fixed-price contract to transfer the risk of cost overrun to the vendor).

Strategies for both threats and opportunities:

Accept the risk actively or passively

Active – create a contingency reserve if a positive or negative event occurs

Passive – do nothing during planning, let the team address during project execution if the risk occurs. An appropriate approach for low probability or low impact risks.

Create a contingent response strategy – “if/then” strategies created during planning and only used if the risk presents during execution.

Strategies for positive risks or opportunities:

Exploit – take steps to assure the opportunity is realized (assign most talented resources).

PM Basics


Share – allocate ownership to a third party who is best able to capture the opportunity (form joint ventures).

Enhance – modify the “size” of an opportunity by increasing probability and/or positive impacts.

- Adapted from PMBOK® Guide – Fifth Edition, pp. 344 - 346

Risk response planning may result in any combination of responses, e.g., contingency plans, additional tasks, changes in the sequence of the tasks, changes to contractual relationships. As risk responses are developed, the estimates and schedules are changed accordingly.

Generally, the "value" (probability x impact) of a risk event is used to justify the response. The higher the probability and impact, the more you might be willing to spend on addressing the risk.

Contingency Reserves vs. Padding

Contingency reserves are funds, resources, or time for the expected costs, schedule, quality or scope impacts associated with the known unknowns identified and quantified for the project.

The Pessimistic Budget and Schedule Estimates

The sum of the most likely task estimates plus the reserves represents the pessimistic end date and budget estimates. Reserves can be assigned by phase, major activities, or to the project as a whole.

The allocated project budget should include the reserves. Key Stakeholders should be made aware of both the most likely and the pessimistic end date and the probability of hitting one or the other. You may be asked for an optimistic plan (budget and schedule). If so, it should be published, along with the probability of hitting it.

Change and Issues Reserves

Change and issues reserves take into consideration the relative certainty that requests for change, actual changes and issues will arise as the project progresses. Plan for them. Establish a reserve for change management that includes an estimate for the time and effort that project staff will spend creating, evaluating and responding to change requests and issues, and an estimate of the time and effort that will be spent on making authorized changes.

Like all estimates, these should be based on past experience and a set of realistic assumptions about your project.

Managing the Reserves

The reserves are managed throughout the project. They are recorded as tasks and/or budget line items. As slippage occurs in tasks, assessment of the causes and impacts of the slippage are used to determine how much of which fund will be allocated to the slippage. This accounting makes it easier to see if the project is on schedule and/or budget and whether the pessimistic estimates are being approached.

Avoid Padding

Reserve funding is recommended over padding (inflating the project by a contingency factor by inflating each task). Padding leads to the unfortunate result expressed in Parkinson's Law: effort expands to fill the time and resources available.

Further, padding tends to be based on a flat pad rate (say, 20%). Knowing that Clients and management often reduce the pad, some estimators may inflate the pad rate. This inflation can lead to haggling and a spiraling of increases, padding and cutting.

FAQ – Show and Tell?

Should contingency reserves and other reserves be shown as separate line items to Clients and upper management? Yes, if these individuals are rational enough to understand that these are not "extras" that

PM Basics


can be arbitrarily eliminated from the plan. The decision regarding whether to show these line items becomes a sales/ Client relationship issue, for external projects. Internally, it is a matter of knowing your organizational culture.

Assigning Tasks; the RAM

Every project task (remember the task can be at any level of the breakdown) in the WBS must be explicitly assigned to one or more people or groups. This way we assure that nothing will "fall through the cracks" and that we can manage by accountability.

The Responsibility Assignment Matrix (RAM)

The RAM is a representation of the accountability at various levels.

Each task is associated with performers with defined responsibilities.

The RAM is the outcome of the task assignments based on the WBS.

It is essential to ensure that every task is clearly assigned.

Ultimately, each task in the most detailed level of the WBS should have a single responsible person.

Types of Responsibility

Projects and the tasks within them are often complex. When assigning responsibility, we want to make sure that everyone has a good idea about what is expected of them.

There are many models for identifying the types of responsibility. Here's one:

Principal – is the party (or group) responsible for the task. Accountability for task completion rests here. Sometimes called the owner of the task.

Approval – has the authority to approve or reject the task deliverable(s) based on acceptance criteria.

Support – is responsible for performing work on the task, as delegated by the principle.

Information – is expected to receive and review information about the task and/or its result.

Consulting – is responsible for providing input regarding task performance, interim results, or the deliverables. The input is not binding on the Principal.

Another very common model is RACI:

R = Responsible

A = Accountable or Approves

C = Must be Consulted

I = Must be Informed

S = Some add an S for Support and shuffle the acronym to make it RASIC – Responsible, Approves, Supports, Informed, Consulted.

As you can see, there is a multitude of possible ways to create the RAM. The critical point is to make sure that every task is assigned and that the assignments are clear and explicit.

PM Basics


Executing: Making it Happen — Hard Skills

Overview

The Executing Process Group includes those processes performed to complete the work defined in the project management plan to satisfy the project specifications.


It includes all the performance work.

Among the activities covered in Executing the project are:

Performing the project tasks

Collecting project performance information

Handling procurement of goods and services

Team development

Quality assurance

Note that many of these activities are performed while planning is still going on. Remember, planning is an iterative refinement process that continues through most of the project's life (hopefully with a lot more of it being done early on.) The Monitoring & Controlling processes (addressed in the Monitoring & Controlling Process Group) are performed as the project is being executed.

Key PM Responsibility – Directing and Managing

Now that all the planning is done, we are ready for action! The project manager must now direct the various technical and organizational resources and activities to execute the work defined in the project management plan. The activities of these individuals and teams will produce the planned deliverables. As the work is in progress, changes may be requested, corrective action may be required based on production and observed outputs, defects must be repaired and previously determined systematic quality activities are performed to ensure customer satisfaction at product turnover.

Subcontractor Management

Subcontractors are firms or people performing parts of your project. Generally, we think of subcontractors as outside vendors, but in effect, an internal group that takes on an activity and agrees to provide a deliverable required by the project can also be seen as a subcontractor. For example, an in-house technical writing group that commits to the development of a manual for your product is a subcontractor to your project.

Of course, the relationship with in-house subcontractors and with outside vendor subcontractors is different. Vendors have legally binding contracts, whereas in-house groups do not. Accounting is different. But in many respects, the way you must manage these groups is quite similar.

The Project Manager's Role

Selection

The Project Manager should have a significant say, if not full authority, in selecting subcontractors to work on the project. In many respects, it is good practice to require in-house subcontractors to compete with vendors for roles on the project—monopolies tend to reduce productivity, responsiveness and quality. This, of course, is a sensitive issue—so be careful.

(We will not get into the procurement process in this course. For further information see the Contracts and Procurement section in Project Management: A Systems Approach to Planning, Scheduling and Controlling, 11

th Edition by Dr. Harold Kerzner, John Wiley & Sons, 2013)

PM Basics


The Project Manager has to work with and rely on the subcontractor. Having selection authority tends to make the relationship healthier.

Project Control

The subcontractor is accountable to the Project Manager. The Project Manager needs regular status reports that compare progress to a pre-established plan. Subcontractors like to have plenty of flexibility to juggle their resources among the various projects to which they are committed. (Remember, in most cases you are not the subcontractor's only client.)

Get the subcontractor to commit to interim milestones so you can check progress at weekly, or at least, bi-weekly intervals. Pin the costs down, too; otherwise you might experience budget overruns. Manage your subcontractors as you would manage anyone—not too tight, not too loose.

Approval of Deliverables

Deliverables, final or interim, should be subject to acceptance by testing or reviewing them against pre-established acceptance criteria. The acceptance criteria, the method for acceptance, and the method for handling non-acceptance, should all be part of the subcontracting agreement.

Setting Scope and Acceptance Criteria

The subcontractor is performing work on the project. Like everyone else, the subcontractor must have a clear set of objectives with acceptance criteria. These form the core of the agreement with the subcontractor and provide the objective criteria to be used in evaluating results.

Work Authorization

In many projects, the timing of the start and completion of subcontractor tasks is critical. In a construction project, for example, you wouldn't want the electricians or plumbers to start traipsing through the site until the cement has dried. To assure that subcontractors start their work no sooner than appropriate, a formal work authorization can be used. A form (electronic or hard copy) is signed to authorize work. No authorization means no payment—maybe even a penalty. There is usually formal work authorization in large projects with multiple vendors. In smaller projects, the Project Manager coordinates the subcontractor tasks in a less formal way, but should invest some time and effort in establishing minimal processes to ensure a successful relationship.

Performance Review

Performance review should be an agreed-upon part of the relationship. You want to review the subcontractor's performance and have the subcontractor review yours. The feedback should be candid. (For more information see the topic on Closing: Post-Project Review.)

Vendor/Subcontractor Relations

Remember, vendors and in-house subcontractors are part of the project team. They should have a clear definition of the project scope and agree to their roles and responsibilities. Harmonious relationships among the stakeholders are a critical success factor on projects. From the point of view of the vendor, harmony and satisfaction is critical for getting repeat business and enthusiastic references. From the buyer's perspective, the importance of effective relations is the ability to work with the best vendors on future projects—and the best vendors can be selective.

Some typical conflicts with subcontractors are:

Changes in Scope

Slipped Deadlines

Expediting Deliveries

Authority/Reporting Issues

Unexpected Cost Increases

PM Basics


The best way to avoid these is to have explicit agreements or contracts. Every aspect of the relationship, particularly the scope and acceptance criteria, reporting requirements and change management should be fully agreed upon and documented. Treating vendor representatives with respect as valued partners goes a long way to motivate performance that goes beyond the contractual obligation.

Hot Tips for Managing Subcontractors (Internal or External)

Get a timeline with milestones that are within one to two weeks apart

Pin down the costs. Fixed price is usually best to keep costs under control and promote self-management

Get an up-front agreement about progress reporting

Follow up regularly

Don't micro-manage

Don't allow too much "leeway"

Manage by accountability and positive motivation

Document all agreements

Treat people with respect

Managing Risk Events

Managing Risk Events

In the planning process, you identified Risk Events—acknowledging what can go wrong on a project so that you're ready to respond when, as Murphy's Law dictates, it actually does go wrong. Also in the planning process, you have devised contingency plans—we called them risk responses—to put into effect when and if the risk event should occur. Based on the risk analysis, you have created reserves to make your schedule and budget realistic (For a review see Planning: Risk Assessment and Contingency Planning.)

During the execution of the project, the events we thought could happen might happen. Other, unanticipated, events that impact our project might also happen. If they do, you need to recognize the event, acknowledge its occurrence, evaluate it with regard to previously set contingency plans, decide what action to take and then take it, to try to keep the project on track, if possible. If it is not possible to keep the project on schedule and budget in the face of a negative event, then it is necessary to make plan changes and notify the appropriate Stakeholders of the event's impact.

Green, Yellow and Red Light Reporting

During project execution, it is necessary to recognize a risk event, then to evaluate it and make Stakeholders aware of the impact it is having or might have.

It is common to classify risk events and the tasks they relate to by giving them a color code. A green light indicates that everything is all right and there is no need for concern. Yellow means that there is some action here but the project team has it under control and there is no need for external intervention (e.g., by the Sponsor). Red indicates a serious issue requiring external intervention. Be aware that if you are distributing hard copy reports the color coding can be lost. Therefore, use the words red, yellow and green as well as the colors.

(For more information, see Monitoring and Controlling: Taking Corrective Action and Reporting.)

Risk Categories

Schedule Risk (Potential causes of schedule slippage.)

Financial Risk (Potential causes of budget overrun.)

PM Basics


Resource Risk (Potential causes of people, equipment and facilities not being available as expected.)

Technology Risk (Introduction of new technology)

Business Risk (How will the business affect the project and the project affect the business?)

Scope Risk (How stable are requirements?)

Potential Risk Events

Risk events may include any of the following:

Late deliveries

Natural disasters and other uncontrollable events ("Acts of God")

Late (or early) completion of critical tasks

Price increases

Scope change

Technology changes

Business changes

Technical and performance errors

Loss of resources—people, machines, facilities

Change of human resources

Cost or effort overruns

Longer learning curves than expected

Be Vigilant

Being Vigilant is the bottom line. Keep your eyes open and let your awareness be expansive so you can see Risk Events as they begin to occur. The more you can anticipate the occurrence, the more likely it is that you can act to minimize its impact on your project.

If another project using some of "your" resources begins to slip, you can reasonably expect some impact on your project. What can you do to protect your project from slippage? Can you arrange in advance for alternative resources? Delay the start of your project? Lobby to get your resources freed up before the other project ends?

Keep Up with the News

If you become aware that a strike may be brewing at a company you are relying on for some aspect of your project, can you arrange for alternatives? For example, the airline your team has reservations with is having a dispute with its flight attendants and they are threatening to walk off the job.

Keep up with the news, particularly as it may impact your project. You can often get notice well in advance of events that can affect your project.

Positive Events

Keep aware of the occurrence of Positive Events as well as negative ones. A potential price decrease could be an opportunity to reduce your project's costs. Another project that is ending early can make that superior person you originally wanted on your project available. Or it may free up others so you can get some of your tasks started early.

PM Basics


Project Management Plan Change Control

Change

The one thing we can be sure of in projects (and everything else) is change. In project management, we refer to changes in budget and schedule as variances – variances from the plan baseline.

The primary cause of schedule and budget variance is change in scope. Project scope change boils down to changes in objectives and the nature of the product – more, fewer or different features, higher or lower quality, and changes caused by errors and omissions.

Other causes of change include:

Staff changes

Late delivery (of anything from goods and services from vendors, to approvals by key Stakeholders)

Inaccurate assumptions

Incorrect estimates

For more information, see topics Planning: Identifying Risk Events and Monitoring and Controlling: Corrective Action.

Types of Change Control

There are three principal types of Change Control:

Scope Change Control

Project Management Plan (including Schedule and Budget) Change Control

Document Control

In this course, we focus mostly on Scope Change Control, after a brief look at change control procedures in general, and specific changes to the Project Management Plan and Document.

Change Control Procedures

1. Identify the way changes (either to the project management plan or the product) are defined, requested, authorized or rejected, and then acted upon.

2. Clearly state roles and responsibilities, including authorization levels.

3. Maintain compliance to the procedure throughout the execution of the project.

Project Management Plan Change Control

The project management plan should be adjusted throughout the life of the project to keep it in sync with what is really happening. The project management plan must be kept useful as a means of predicting the project’s outcome.

Project Management Plan changes that affect the baseline must be noted to stakeholders. When budget and schedule overruns are anticipated, the change must be authorized before it can be officially included in the project management plan.

Project Management Plan changes must be requested.

Document Control

During the execution of any project, there are numerous documents created, distributed and revised. The management of Scope and Project Management Plan Change includes the management of the documents that state the project management plan and scope, and are used by project Performers to guide their work.

Document Control is a part of document management (which also includes standards, development, and distribution.) Document Control is the process of making sure that any time a document changes, the people using that document are made aware if the changes in a timely manner. This means:

PM Basics


1. Making sure there is clear responsibility and accountability for distribution of documents and changes to them, and for the proper updating of documents by their users.

2. Identifying the tools and methods by which documents will be distributed and managed.

3. Creating and using a version-control notation system to clearly show, on each page of a document, what version is represented.

4. Maintaining an up-to-date list of people with copies of controlled documents – for hard copy control – or a way of electronically distributing changes and holding recipients responsible for updating their own copies.

5. Making the changes when they arise and distributing them quickly.

Scope Change Management

Scope change is inevitable! It can happen at any stage of a project. The best remedy is to be prepared for it and to identify it as quickly as possible. Early warning helps to minimize the negative effects of change by permitting postponement, corrective action and/or plan adjustment.

Rule number one is to have a system for capturing Change Requests so they do not go unnoticed and undermine the project plan. Every change in the scope – regardless of how minor – must be formally requested.

Scope Baseline

The Scope Baseline is the statement of requirements and design that has been agreed upon by the project performers and the Client. This is the definition of the product to be delivered by the project.

Once the baseline us set, any variance from it must be requested, evaluated, approved and executed under the Change Management procedure.

Scope Change Request

Scope Change Requests are written descriptions of desired changes. They are used to control the change process and to provide a history of changes that can be used to explain project variances and to analyze project performance.

Trouble or incident reports are a special type of Scope Change Requests. Some projects choose to separate the two while others use the same form for both. Either way, remember that it is not necessary to fix every error found in a system. Impact analysis and degree of importance are the primary criteria for deciding which changes/incidents to act upon, postpone or reject.

Scope Change Review Priority

The following is an example of scope change that may be used within a change management procedure to decide which changes should be made and which postponed.

High: Must be acted upon immediately. The product’s operational; environment us to change, therefore the product must be changed in order to be operable or useful. Legal requirements must be met. Errors or omissions exist that would render the product inoperable or unusable. Without the change, the product may be dangerous to use. Product software or hardware is to change; therefore applications must be changed in order to be operable or useful.

Medium: Discretionary, depending on impact on current activities. Changes to the environment require changes or additions to the product. Significant performance improvement can be obtained. The cost of postponement is high (e.g., redesign would be costly after the product has been developed.)

Low: Easily postponed. Cosmetic improvements/corrections. Enhancements to add new features and functions. Enhancements to automate new functions.

PM Basics


Scope Change Review Criteria

Criteria used by the review group in deciding whether to implement a change or postpone it are:

1. Postpone all but high-priority requests, where high-priority is defined as those changes without which the product would be unusable.

2. Attempt to group changes to be implemented, rather than have a continuous flow; these groups of changes can them be performed to create subsequent versions of the product.

3. Evaluate priority to changes based on cost vs. benefits – the cost of postponing the change and the cost to the project of making it now vs. the benefits to be derived from making the change. Factor in risk of reduced product quality.

Scope Management Procedure

1. Establish change review criteria and a change control board to authorize changes. The first level of change authority to authorize changes. The first level of change authority is often the Project Manager who can authorize changes up to a limited impact on the cost and schedule. When changes are outside of the Project Manager’s (PM) limits, the PM will escalate to a change control board, the Sponsor or the Client, depending on the nature of the project.

2. Establish a change reserve that identifies likely schedule and cost impacts of expected changes.

3. As soon as a formal requirement or design document is published, changes or additions to the product should be requested in writing (using a Scope or Product Change Request From), logged, and approved by the project’s change control group. In those situations that don’t allow for the prior request for a change, every change must be documented. Usually, as the project progresses, it becomes more difficult to get authorization for changes. This is on recognition of the increased work required to implement changes once detailed requirements, definition, design or construction has been done.

4. Estimate and track all changes in terms of cost and schedule impact.

5. When changes are approved, the project management plan should be changed to reflect the additional work to be performed.

6. When changes are postponed, re-review all previously requested changes before making them, to determine if they are still desired.

The Scope Management Authorization Group

Many projects should have Change Control Board or Management Authorization Group, which may be made up of involved Senior Manager(s), Functional Manager(s), The Sponsor, Client Representative(s), and the Project Manager. The group’s function is to decide on the disposition of change requests, based on pre-set change review criteria, and an impact analysis that has been performed by the Project Team. As noted earlier, the Project Manager is often given authority to decide on the disposition of changes within pre-established constraints.

Managing People — Soft Skills

Communication: Overview

Communication: the transfer of information between people.

Effective communications, both interpersonal and "official," are necessary on a project. Effective communication has the following characteristics: mutual understanding of content by all participants—evidenced by feedback, people getting what they need to know when they need to know it and written records that are easily accessible by subject and chronology.

PM Basics


Effective communication

Dialogue (not debate) – Dialogue is the process of exchanging views, including the underlying reasons for one’s views, to achieve a meeting of the minds. For more information on Dialogue, see next topic, Conflict Resolution and Negotiation

Process Review – Process review (particularly in the review of communication) is the process by which to periodically assess the policies, procedures, tools and standards that have been set up for the project; and by which to make improvements during the project life. Process review during the project allows us to immediately make use of lessons learned.

Formal Communication Management Planning – Barriers to effective communication can be reduced or even eliminated by establishing a Communication Management Plan that clearly addresses who is to provide what information to whom, when and how. The Communication Management Plan is part of the Project Management Plan. Also, see Job Aids: Communications Management Plan Outline

Straight Talk – Straight talk is essential to project success. It means being candid and addressing even the issues that may be negative or difficult to deal with. Most problems and issues can be resolved if they can be clearly identified and discussed. Candor is critical to all aspects of project management. Remember, it is possible to be candid and diplomatic. Sensitivity to others’ feelings will prevent unnecessary conflict.

Barriers to Effective Communication

Effective communication is often difficult because project Stakeholders may not be motivated or trained to communicate candidly.

The principle barriers to effective communication are:

Differences in Technical or Academic Discipline:

Use common language and educate others regarding your specialty area (if they need it) to promote better understanding. Don’t consider others to be less than clever if they are not as knowledgeable in theirs. Mutual respect, patience and appreciation of the power diversity in project teams will help to break down this barrier.

Prejudices & Attitudes

This barrier can be broken by taking an objective view of all your beliefs and attitudes. Objectivity requires questioning your beliefs and holding them open to critical analysis. Engage in dialogue. Respect others’ opinions.

Personality Differences

Sensitivity training and open discussions of differences and how to honor them, when practiced early in project life, will help to avoid unnecessary conflict.

Hidden Agendas

Clearly and explicitly identify criteria for decision-making and promote dialogue and straight talk.

Emotions

Keep your emotions in check – don’t bury them but don’t act them out. Avoid making decisions or sending out written salvos (e.g., flame mail and memo wars) while in an emotional state – calm down and reflect on the situation. Address the causes of your emotions.

Fear of Blame & Retribution

Promote a participative environment by avoiding finger pointing and blaming. Remember the old rule of thumb from Total Quality Management – 85% of problem causes are caused by systems and procedures; only 15% are caused by individual performance issues. Motivate, coach and learn from errors.

PM Basics


Cultural Differences

Sensitivity training and open discussions of differences and how to honor them, when practiced early in project life, will help to avoid unnecessary conflict.

No Communication Plan

Plan the way you’ll communicate

Imprecise Language

Be specific and explicit. Use a project glossary to define the language of the project.

Hot Tip—Good Communication Requires Listening

Listening is being open to what another person has to say. It is the root of communication. It is so simple, yet so difficult.

Suspend judgment and analysis.

Turn off your own mental chatter.

Ask questions to clarify.

Verify your understanding.

Listening precedes evaluating and judging.

Good Communication Requires a Feedback Loop

Because each person is an individual with a unique conditioning, personality, etc., it is quite possible to miscommunicate, particularly when dealing with complex and/or controversial topics. In the feedback loop diagram, the screens represent the distortions caused by our uniqueness.

Communication is a two-way street. Both the source (sender) and receiver of a message must understand the message in the way that the sender means it. Effective communication requires a feedback loop—the receiver listens and then expresses his or her understanding of the message in his or her own words back to the sender.

The sender sees if the message was understood as intended and, if not, adjusts until satisfied. While this can be time consuming and sometimes frustrating, it is well worth the effort. Without a mutual understanding, we risk sending people off to take action with the wrong idea of what to do and how to do it. Inevitably, that leads to rework. It can also lead to interpersonal conflict, which can be more far more costly and disruptive than rework.

The Story of the Blind Men and the Elephant

Once upon a time, there was a village populated entirely by blind people. The villagers had heard that an elephant was going to be passing through their vicinity. They had never encountered an elephant before, so the villagers sent out a small delegation. The delegation members experienced the elephant using their senses of touch and smell. When they returned to the village, everyone was gathered in the village center to learn about the elephant.

The first delegate, having felt the truck said, “An elephant is like a snake.” He was immediately interrupted by another person who explored a leg and proclaimed, “That’s ridiculous. An elephant is like a tree trunk.” Another experienced the tail and shouted, “No, an elephant is like a rope with a tuft at the end.” And someone else who had placed his hands against the massive body said, “No, an elephant is like a wall.”

Soon all of the delegation members were arguing.

Most of the listening villagers became frustrated with the argument and left the gathering. Some people, liking a good argument, stayed to listen. Some of them began to create logical constructs based on what they had heard, adding a few statements of their own based on their opinions. “An elephant should be this,” or “logically an elephant would be that,” they said.

PM Basics


Another group of people was interested on a political level. They knew that if their brother-in-law said that an elephant was one thing, it couldn’t possibly be the case – and they would take a contradictory stance no matter what. What was right didn’t matter to them, just who was right.

In the end, there is no end to this story. It continues to this day. It is a good illustration of what happens when people debate instead of having a constructive dialogue with one another.

Conflict Resolution

Conflict is a disagreement between people with different ideas or beliefs. Conflict is inevitable in project work and a project team should have a well-defined process for dealing with it.

The aim is to use the conflict as a means to refine ideas and beliefs so that the project team uses only the best ones in their work. The best ones are the ones that most effectively contribute to the meeting of project objectives within constraints.

Conflict resolution requires an effective communication process, as well as an effective problem-solving and decision-making process.

Conflict Resolution Process

A well-defined Conflict Resolution Process includes the following:

Agreement that conflict should not be avoided when it is about any critical issue.

Up-front discussion and agreement about the use of dialogue vs. debate.

Agreement to raise conflicting ideas and beliefs so that they can be addressed.

Agreement that conflicts should be resolved based on objective criteria-like the degree to which solution or decision satisfies project objectives.

Agreement about the use of authority for resolving conflict that cannot be resolved by reaching a consensus.

Agreement about when and how conflicts will be escalated for authority decisions (see topic Problem Solving: Escalation).

Healthy Conflict

Dialogue, as opposed to debate, is the foundation for effective conflict resolution.

The goal of the dialogue is a common understanding, through the investigation of each person’s position, on a subject. Dialogue is collaborative and allows people to have differences of opinion that can be brought together to gain a better understanding of the whole.

Debate, on the other hand, has a winner and a loser, and often leads to unresolved conflict – not particularly useful in that project.

In debate, the debaters promote their positions and attempt to shoot holes in their opponents’ positions.

In a dialogue there are no opponents. The participants present their positions along with the underlying reasons for them. They actively try to reconcile differences and even merge their positions to create an outcome that is superior to any one position.

Unfortunately, many education systems and organization cultures value and promote debate as opposed to dialogue. Have you ever heard of a “dialoguing team”?

Therefore, we have to consciously promote dialogue and re-train people. The use of facilitators in large, complex conflict resolution situations – and the use of peer moderation in smaller ones – can help to remind people that their aim should be to get to a resolution that is best for the project, as opposed to getting their way.

PM Basics


Negotiating

Negotiating is the process of finding a way to resolve conflicting positions between people. The PM must be a negotiator as well as a facilitator, problem-solver, decision-maker, communicator, and mediator.

In Planning, we discussed the need to negotiate rational estimates. There are many other opportunities to exercise negotiation skills: negotiating agreements with vendors and Functional Managers, negotiating Requirements issues, Change Management issues, and resolutions to the vast array of issues that come up during a project life.

The Basics of Negotiating are:

Know your objectives, including the full range of acceptable outcomes you can live with.

Determine the objectives of the other party.

There is a tendency to view the other party as an opponent – this is not recommended.

Instead, consider the other party a partner or potential partner and seek a win-win solution.

Go in with a strategy that gives you the ability to postpone decision-making, if you choose to, so you are not forced to decide under pressure.

Present your position and be ready to support it with facts and reasonable assumptions.

Listen to the other party’s position.

Be flexible – within the acceptable range of parameters you’ve established.

Don’t compromise so much that the end result no longer satisfies you.

Don’t push the other person so far into a corner that they must either accept a disadvantageous agreement or leave, particularly if you really want to work with a person or a group.

Don’t be afraid to walk away without an agreement, but know what that means before you get there.

Problem-Solving and Decision-Making

Problem-Solving and Decision Making

The aim of this topic is to give you a brief introduction to Problem-Solving and Decision-Making and to highlight the need for clarity and objectivity rather than subjectivity, emotionality and politics. Problem-Solving/Decision-Making is an ideal means for conflict resolution. It is based on candid communications and dialogue. It is also a basic tool in negotiating win-win outcomes.

Problems (also known as opportunities, issues or conflicts) abound in projects. In fact, projects are usually performed to address a problem. For example, how can we make more money by creating a new product? Or, how can we stop wasting so much time and effort by implementing a new or changed process?

Problem (Issue) Solving/Decision-Making Process Steps

1. Describe the issue and its setting. What’s happening, where, what impact?

2. Set objectives. What do we want to do about it?

3. Identify causes. Why is it occurring?

4. Identify potential solutions. How can we meet objectives?

5. Decide. How will we meet objectives?

6. Act. Implement the solution/decision. Do it.

7. Monitor and adjust. (The humility step.) Acknowledge that whenever you decide to do will probably need refinement as you do it.

PM Basics


The Decision-Making Approach

It is critical to decide how you will make decisions. If you don’t, you are doomed to waste emotional energy, time and effort arguing.

Shoot for Consensus within Time Constraints

Consensus is unanimous agreement among decision-makers in which everyone can at least live with the decision or solution. To live with the decision, one has to be convinced that the decision will adequately achieve objectives. As long as someone believes that the decision will not achieve the objectives, he should not come into consensus until his or her objections are overcome.

Dialogue among the decision-makers is the means to reaching consensus.

Each time an objection is overcome; the effectiveness of the decision is improved or proven to be correct. Consensus-building tends to lend to better outcomes. But it takes time – sometimes more time than you have. So what happens when you run out of time and still haven’t reached a consensus?

Accept the Need for Authority Decisions

For each decision there should be a person (or a small group) with the authority to make the decision if the working-level decision-makers can’t make the decision within the pre-defined time constraint. Escalation to the next higher authority takes place.

Escalation (bringing an issue to a higher authority) can be a political issue. To avoid the politics, set clear escalation paths and agree upon the criteria that must be met before an issue is escalated.

Hopefully, the authority will be wise enough to use the results (pros and cons for each of the alternative solutions) of the consensus process as a basis for his or her decision.

Avoid Majority Rule

Binding votes are often a “cop-out.” No one wants to take responsibility for an authority-based decision or spend time and effort to reach consensus.

Projects do not work on the basis of democracy. Regarding business and technical decisions, there is no correlation between the number of people in favor of something and the “goodness” of the solution. Often a small minority or an individual will have the best right answer. The consensus process will more likely make sure that the best answer is considered and accepted by the group. Further, when we allow the majority to rule, the minority has not “bought into” the solution. When it comes to applying it, they might subtly sabotage the effort and be there to say, “I told you so” if and when the solution fails.

Objectivity: The Weight and Scores Approach

The goal in project decision-making is to make decisions based on objective criteria. The criteria should be based on the degree to which objectives are met.

The Weights and Scores Approach is a great way to make decisions in which alternatives are compared. It cuts out the subjectivity, allows for a focused and formal approach and helps groups come to consensus by requiring them to break down the decision-making into its component parts – establish decision criteria, rank them with regard to importance, evaluate alternatives with respect to the criteria, and decide based on how well an alternative meets criteria.

Simple decision matrices can support this approach.

Effective Meetings

Effective Meetings

A critical factor in project performance is the ability to successfully hold and take part in meetings. Much of the critical decision-making, communicating and planning takes place in meetings. Multiply the number of hours of meeting time by the number of people attending and you get the resource cost of meetings for your project. Generally, it’s a big number. You’re spending significant time at meetings, so they better be effective.

PM Basics


Effective meetings are ones that accomplish an explicitly stated set of objectives, in the minimal amount of time, with the fewest people. Effective meetings leave a written record (minutes) and either an action plan, a set of decisions and/or a group of informed people. Successfully completing a meeting means accomplishing meeting objectives within a finite time, and for all parties to come away with a common understanding of the outcome.

Kinds of Meetings

In the “old” days, meetings were events where a group of people got together in a conference room, face-to-face. Today we have face-to-face meetings, teleconferences, videoconferences, or a wide range of software applications to support facilitated meetings.

Regardless of the kind of meeting, the meeting must be facilitated (either by a designated facilitator or the group itself).

Meeting Facilitation

The meeting facilitator(s) have the responsibility to ensure success by:

Making sure there is an agenda.

Making sure the right people are in attendance.

Keeping the group on the right track, at the right level of detail.

Promoting appropriate interaction.

Highlighting agreement, disagreement and open issues.

Ensuring that meeting results are documented.

Ensuring that open items are assigned for future action.

Ensuring that the meeting process is reviewed to identify opportunities for improvement.

In the most formal sense, the facilitator is someone who stands apart from the participants and who is accepted as a neutral party with respect to issues being addresses at the meeting. As groups become more familiar with facilitation and with effective meetings, the participants themselves can perform the facilitation function.

In electronic communications the facilitator may also act as session administrator. However, in today’s online meeting environments, a best practice is to have a designated session moderator to keep track of chats or instant message traffic, supported by the application. This person may also be responsible for resolving technical issues encountered by attendees.

Meeting Process Model

A model for typical meetings is made up of the following steps:

Preparation

o Pre-plan objectives and agenda.

o Determine attendees.

o Assign responsibilities (e.g., facilitator, chairperson, scribe, administrator).

o Schedule (set time, place, duration).

o Arrange for space, refreshments, facilities and A/V equipment, if applicable

o Distribute and read documents.

Gathering

o Time for arrival, socializing, refreshments.

o Read minutes of previous meeting (if appropriate).

o State purpose and agenda with time estimates.

o Revise/accept agenda (start with old business).

Address Agenda Items (Body of the Meeting)

PM Basics


o Presentations.

o Discussion.

o Determine open issues.

o Assign responsibilities.

o Recap and record (meeting minutes).

o Re-state and reaffirm agreements.

Review

o Have all agenda items been addressed?

o Identify action items and responsibilities.

o Accept the minutes – this is best done right at the meeting.

o How was the meeting process, atmosphere?

o Could process be improved?

Close

o Schedule next session.

o Re-state purpose, key decisions, open items.

Follow-up

o Distribute minutes

o Complete assigned action items

o Gather status on action items

o Return to top of the list to prepare for next meeting or document the successful completion of all related action items

Team Development: Overview

Team

A group of people working together to accomplish a common purpose.

Teamwork

A joint work effort between two or more people to create a product or perform a service – often resulting in improved performance of the individual members and higher quality results overall.

Team Building

Team building is the process of creating a team by bringing people together and having them agree on objectives, roles and responsibilities, and their way of working together. Included in team building is promoting a bond between team members so that they can work together in a more effective and enjoyable way than if they perceived one another as impersonal cogs in a machine.

Team Building Activities

There is a variety of team building activities out there to help you build a team with a strong bond. A little extra research to find appropriate activities for your group will go a long way toward the success of your project.

Generally, the more critical and complex the project, the more diverse the team members, and the less they’ve worked together in the past, the more important it is to have a formal team building activity.

During the course of a project, it is important to reinforce the team’s bonding through continuous process awareness and review. You should regularly ask, “How are we getting along? How is the way we are getting along affecting the project?”

PM Basics


Hot Tip: Build Teams Consciously

Make sure everyone agrees on objectives.

Clearly establish roles and responsibilities.

Make sure you’ve got the right people and skills.

Organize for success.

Manage vendors effectively.

Consciously engineer your work process for success.

Review your work process and relationships regularly to identify opportunities for improvement.

Manage conflict for a win-win resolution.

Forming, Storming, Norming, and Performing

Forming, Storming, Norming, and Performing is a classic team building model that still applies today. The model is was originally presented in an article “Development Sequence in Small Groups” in the Psychological Bulletin, v.LXIII, no. 6, 1965 by B. Tuckman and M.A.C. Jensen.

Tuckman added a fifth stage, Adjourning, in the 1970’s. Adjourning, is the break-up of the group, hopefully after the task has been successfully completed. Recognition of, and sensitivity to, people’s departure in Tuckman’s fifth stage is helpful, particularly if member of the group have been closely bonded and feel a sense of loss from the project completion.

Forming

When a team of people come together, Forming, they begin by establishing common understandings of the objectives, modes of operation and procedure, etc. See the Kick-Off topic in Initiating. The goal is to do the forming as consciously as possible. Spreading it out over the course of the project is a recipe for failure, so form your team with intensive up-front planning.

Storming

The Storming may start during the forming or soon afterwards, as people get to work and begin to deal with conflicts, including differences about content issues (how to design the product?), process issues (“I don’t like the change control procedure”) and personal issues (“Charlie is making too much noise in his cubicle,” or “I’m allergic to Sue’s perfume!”). Things are coming to a head. If you resolve those conflicts properly, the resolution helps to bond the team members and as a result they start to work together in a much more effective way. Conflict and its resolution early in the project life cycle will avoid having a continuous set of problems. The point here is to recognize that storming is a natural part of the team formation process.

Norming

Norming is coming to resolutions, or establishing a set of norms for the group. It’s not only saying, “This is the way the team will operate” in a set of procedures, but it is the outward manifestation of the team members’ behaviors as they work together using the procedures.

Performing

The Performing (work, action) stage is when it all comes together as a result of having taken the time and effort to engineer an effective way of working that is tailored to the team and the situation.

Motivation and Morale

Motivation: A Means of Promoting Action

A goal of the Project Manager is to create an environment in which people are motivated to attain project objectives. Motivation requires the Project Manger to be aware enough to determine why his/her people do what they do. By finding out what “turns people on,” it becomes possible to tailor rewards to each performer to maximize the effect on motivation.

PM Basics


The study of motivation is well beyond the scope of this course. But we want to make sure that every Project Manager is aware that motivation is a critical part of the job.

There are Three Dimensions to Motivation

1. Motivate yourself to clearly understand why you do what you do, make conscious choices, and generally recognize that it is better to be positive than to be negative.

2. Positively motivate others by giving then the respect they deserve.

3. Avoid behaviors that de-motivate others.

Maslow’s Hierarchy of Needs

Probably the most well-known theory of motivation is Maslow’s Hierarchy of Needs. He postulated that people all have the same basic motivators – physiological needs, security, social need, recognition, and self-actualization. As the lower needs are met, the individual is increasingly motivated by the fulfillment of the higher-level needs.

In project work, we try to understand how we can offer something of value – something that will satisfy our own or other people’s needs.

One of the basic motivators is acknowledging the work done by others. Even negative acknowledgement (e.g., pointing out that someone’s work result is lacking) if done correctly (e.g., privately, with acceptance of the other person’s intrinsic importance as an individual and with an eye toward helping the other person improve their performance as well as the product) can be motivational.

But be careful. Don’t be overly simplistic. Exhorting people to give their all for the sake of the company or project may have a short term effect but probably won’t go very far in the face of chronic overtime and exploitive behavior.

Each person is an individual with unique needs. Manage based on situational circumstances. For example, the need for socialization is quite strong, but many people have it satisfied outside of work. For them it may not be particularly motivating to attend social events like project parties and picnics. For others these may have a very positive effect in motivating higher performance and greater dedication.

Morale

Keeping your team’s morale high is another important skill linked to motivation. Morale is a person’s or group’s spirit or confidence level. High morale motivates better performance. Low morale saps the team’s energy and results in decreased effectiveness. Following are some morale enhancers and detractors to think about as you lead projects and people.

Morale Detractors

Public criticism of individuals. This is de-motivating to the person being criticized (it embarrasses them) and to the others, who expect to be next.

Failure to confront and address problems. The people on your team expect you to take action and resolve problems, particularly the difficult ones. If you fail to address them, they’ll see you as weak and ineffectual. It will have a detrimental effect on their morale.

Allowing a team member to slack off. Once you’ve established an understanding about what level of effort is expected by team members, failure to address below-par performance may make the people who are performing well feel as if there is no reason to go out of their way to perform. Further, the person who is under performing will continue to do so, putting more pressure on others to pick up the slack.

Lack of performance feedback. This is the other side of acknowledging positive performance and giving critical feedback mentioned as motivators.

Lack of sensitivity or tact. Diplomacy goes a long way to give people the sense that you respect them as people. Each person is different, and some think nothing of a gruff response while others might take it to heart. Learn more about the people on your team and give them what they need (within reason).

PM Basics


More Morale Detractors

Taking individual credit instead of crediting the team. This is the flip side of the positive motivator of reporting achievement upward.

Inadequate rewards and recognitions. People feel taken advantage of when the rewards and recognition they have earned are not expressed.

Instability or constant change. Most people in organizations work better when their environment is stable. Instability is often viewed as a failure by management, and failures by management de-motivate people.

Chronic overwork. This tires people out and makes them feel exploited. It is a further sign of management failure. It strikes at the needed for socialization and self-actualization.

Insufficient training, tools and/or resources. Many people feel anxious and overburdened when they are thrown into situations where they are not sufficiently supported. They lose respect and confidence in their management.

Unclear goals. As we’ve said, common goals and objectives are the foundation of teamwork. If these are not clear, frustration is sure to follow and frustration de-motivates people.

PM Basics


Morale Enhancers

Be supportive. You’re more of a facilitator than a task maker.

Protect your staff from unrealistic demands. Think about how you feel when your boss dumps an impossible task on you because he or she didn’t have the courage or intelligence to push back.

Communicate reasons along with objectives. Many self-motivated people like to know why they are doing what they’re doing.

Be equitable in making job assignments, but practical too. As a Project Manager you need to address the needs of the project. Not everyone has the skills to do the jobs they’d like to do. But, you can’t continuously assign the same person to task they excel at, if it means not giving them opportunities to grow. It’s a balancing act.

Listen emphatically. Listening to another person makes them feel as if you think they are important and what they have to say is important. Listening is the foundation of all communication.

Be a facilitator, coach and ally – not just an authority figure. The use of authority to get people to act is a last resort. It generally demeans the other person. Promote a collaborative relationship with minimal hierarchy to motivate people to think for themselves and see themselves as an integral part of the team, not just a cog in the machine.

Provide constructive criticism and positive feedback when warranted. This is an aspect of effective coaching and managing that works on the need for acknowledgement and self-actualization.

Recognize and reward achievement. This works on the need for recognition.

Report significant achievement upward. Give credit where credit is due. Avoid taking credit for the work done by your subordinates. If you give them the credit, you earn their respect and, probably, the respect of the people you report to.

Leadership Styles

Hierarchy can create a gap between staff and management. While management usually sets a direction and puts activities in motion to achieve objectives, it is the staff that acts on those decisions.

In the past, many managers and theorists believed that there was another distinction between staff and management: their motivations. They believed that management was motivated primarily by organizational interest and staff by personal interest.

Modern managers believe that management and staff are motivated by both organizational and personal interests. Although, in most projects, there are exceptions, there is no significant difference in the work ethics and motivation of managers and non-managers.

Theory X and Theory Y

McGregor's Theory of management styles highlights the difference between Theory X: highly directive managers who believe that their subordinates are incapable of self-direction and self-motivation, and Theory Y: managers who take a more participative approach.

Participative Management

Pushes management functions down to the lowest possible level in the hierarchy. This leads to fewer management levels — which tends to make communication more effective and can improve productivity because performers are more in control of their own work process. Further, fewer managers are needed.

The downside is less management control. This is not a problem in environments with well-designed standards and procedures and a mature and self-motivated staff. In a setting where the staff sits and waits to be told what to do and how to do it, a Participative Management approach will not work unless there is a change in staff attitudes and perception of their roles and responsibilities.

PM Basics


Directive Management

A Directive Management approach is one in which there is a tendency to micromanage by telling people exactly what to do and how to do it, rather than giving them more responsibility in deciding how to accomplish objectives. With both Directive and Participative Management styles it is necessary for the manager to provide direction; the difference is in the degree to which the performer is given autonomy.

The bottom line: Manage the situation. When you must be highly directive, then do it in a way that helps to transition people toward taking greater responsibility, within clearly defined constraints and accountability. But don't assume that everyone will do what needs to be done without direction. As you probably know, there is a wide range of work ethics out there, so be ready to work with unmotivated people when necessary.

Delegation and Management by Accountability

In projects, management by accountability is the method that works best. It means that as a manager you:

Clearly describe the work you are delegating, including acceptance criteria.

Get feedback from the performer to ensure a meeting of minds (written feedback is best).

Get a commitment for time and cost.

Allow for negotiation of constraints like time frames and costs.

Monitor performance - but don't micromanage.

Evaluate and accept results.

Review performance and give candid feedback as appropriate.

PM Basics


Monitoring and Controlling: Performance and Monitoring

Controlling Processes

Overview

The Monitoring and Controlling Process Group consist of those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes.


In this section, we will address:

- Performance Monitoring

- Performance Reporting

- Corrective Action

Performance Monitoring—Capturing Performance Data

Collecting Performance Data

Projects can take months to complete and must be monitored along the way to make sure things are going smoothly, producing desirable results, and not costing too much time or money.

Monitoring performance requires that you collect four types of Performance Data that help you gauge the project's progress:

Effort Data

Progress Data

Change Data

Expense Data

The same data will be used to both control the project and evaluate project performance. Performance data is the basis for planning future projects and improving the project management and performance process.

If you don't collect performance data, you will not be able to keep key Stakeholders abreast of the project.

Four Types of Data

1. Effort Date

Part 1

How much resource time has been spent? Here we want to capture the number of hours (or days) worked by performers on a task-by-task basis. This can be converted into the cost of labor on your project by multiplying the effort by the labor rate for each Performer.

The level of detail (granularity) of data that we capture is an important issue. The idea is to capture the data at the work package level so we can evaluate estimates and get an understanding of how effort has been expended. Generally, the lower the level of detail, the more useful the data is for use in monitoring, estimate evaluation and refining future estimates of similar tasks.

Part 2

Make it clear to everyone on the project that they are expected to record and report their effort at a given level of detail, following the procedures established at the beginning of the project.

PM Basics


It is most convenient for Performers to record their time directly into an automated project time-keeping system which then makes it available to the Project Manager/Administrator. Hardcopy timesheets are unwieldy and imply a data entry process - a potential source of error and extra work.

It should be noted that in many projects, time accounting and the use of effort data is not very sophisticated. The project environment hasn't matured to the level at which Project Managers can use effort data. Of course, if you are in such an environment, you still have to monitor your project. And you can, by relying on progress data alone. But you are limited in what you can tell about progress against the plan and the cost of parts of the project. You cannot effectively improve your estimating for future projects because you won't be able to see what it actually costs (in effort) to do the work.

Hot Tips

For best results, tracking should be added to each project team member's job description. (Otherwise they might not do it!)

Motivate: Help team members understand that a true progress assessment is based on their tracking of data and that future estimates can be made better if actual effort is accurately recorded.

Make sure it's recognized that data is not used for disciplinary reasons - to point out too much or too little time spent on a task, for example.

2. Progress Data

The basis for schedule tracking: The tasks that have been started and completed.

Here, we are interested in finding out what has been accomplished. You want to know what tasks have been started so you can monitor performance. More critically, you want to know what tasks have been completed – what deliverables have been delivered and accepted. This will tell you if you are making progress.

Remember that you can expend a lot of effort over a long time and spend lots of money while getting nothing accomplished. Also, a task is not done until its deliverable meets Acceptance Criteria and is approved.

Capturing Progress Data is much easier than capturing Effort Data. Most people are eager to report when they accomplish something.

Using this data you can monitor your project against the schedule and report to interested Stakeholders about what you have delivered.

3. Change Data

Type of change, cause and impact.

This data is used to identify causes of slippage and to evaluate project performance. The topics on Change Management and Issues Management discuss the need for - and procedure for - identifying, handling and recording changes to the project scope and the project plan.

This requires a discipline on the part of all Stakeholders. Capture Change Data in an orderly and regular way to avoid scope creep (the slow incremental expansion of the project), to be able to tell Stakeholders why and how the project got to the state it is in, and to be able to improve the project performance process to avoid changes in the future.

4. Expense Data

Projects cost money. Invariably someone will want to know how much it costs and why it costs that much. To be ready to answer, you've got to capture Expense Data. In many projects, the primary - and sometimes only -expense is the human resource effort. Capturing the Effort Data we previously discussed, gives you the ability to compute the cost by multiplying effort by a resource rate.

In addition to human resource costs, there are the costs of facilities, product components, equipment, overhead and supplies. These should be tracked and directly accounted for in the project. The more expenses can be allocated to specific tasks, the easier it will be to evaluate project performance with regard to budget compliance.

PM Basics


Data Capture Forms

Capturing Effort and Progress Data is best done by having performers enter their effort hours and completion data directly into an automated project management tool (if you have one that is accessible and properly secured). If you can't get direct data entry, then you'll need a reporting form that Performers will fill out and submit to the Project Administrator (or you if you are unlucky enough not to have an administrator).

As illustrated below, the form can be as simple as a list of tasks with a place for actual hours and check boxes for started and completed. This should be combined with status information regarding schedule compliance (cause and impact of late or overrun tasks) to get a full picture of individual performance. (For more information about using progress data for project reporting, see Controlling: Performance Reporting.)

Performance Reporting

Performance Reporting: Status, Progress and Forecast

Performance Data

Performance Report Data comes from the project’s Performers. It includes Task Completions, Actual Effort, and Cost Data & Issues.

Progress Reporting

Progress Reporting lets people know what has been accomplished.

Status Reporting

Status Reporting keeps people abreast of where the project stands with respect to the baseline plan. Status reports compare where the project is to where it is expected to be, based on the project management plan.

Forecast

Forecasting predicts the outcome of the project, based on what has happened up to the report’s “as of” date. Forecasting is really a planning activity, which takes place during the project’s life cycle. We address forecasting in a subsequent section.

Frequency of Reporting

The standard frequency of working-level status reports is weekly. But, the frequency is a function of the criticality and duration of the project or part of the project being controlled. For example, in the late stages of some projects, the implementation of a product – such as a new business system – into a busy working environment might call for daily reporting and monitoring. This tight control would help to quickly identify problems and resolve them before they became crises. The frequency for high-level reports is most often monthly, but bi-weekly and quarterly reporting are not uncommon.

Tailoring Reports to Recipients

In most projects, there are several levels of Performance Reports designed to address the needs of different Stakeholders. Generally, the higher the Stakeholders are in the organizational hierarchy, and the further they are from the day-to-day action, the higher the level of information (in terms of the WBS) in the report.

Senior executives are not particularly interested in the individual tasks. They want a big picture view that gives the status for the project as a whole (what proportion of the work has been done, what major issues are being addressed, whether the project is on budget and schedule), and the individual status of phases or major activities. The frequency of reporting to Senior Executives would likely be monthly, on most projects.

PM Basics


Team Leaders and Project Managers on small scale projects want status reports that reflect the work package and the task levels, so they can closely monitor completions and issues at that level of detail. The frequency of these reports is usually weekly.

In between, there may be weekly, bi-weekly, or monthly reports at various levels of the WBS for Middle Managers, Program Managers, Managers of large projects, and Client/User Group Managers. The level of task detail and the frequency must be determined based on the desires and needs of the recipients, which is documented in the Communication Management Plan.

Terminology

Note that in the “real world”, people often use the terms Status Reporting and Progress Reporting interchangeably, and use these terms to refer to a project performance report. We want to be clear that whatever you call your performance reports; they should compare the current state of the project to the baseline plan, and describe accomplishments.

Reports from Vendors and Functional Groups

As part of the planning process, the Project Manager should work out and gain consensus on a method of status reporting. The method should allow Vendors and Functional Groups to present formats that are consistent and acceptable to the Project Manager and other Stakeholders – including the Client – but don’t require too much extra work these reporting groups (each of which may have their own reporting standards).

The PM should also be careful to ask for the appropriate level of detail – not too much or too little. People should be given enough room to be relatively autonomous, but not so much room that the PM loses control and the ability to recover from – or respond to – issues and problems.

Status Meetings

Regular Status Meeting times should be established throughout the course of the project. The goal is to bring team members together, for a defined period of time, to identify and briefly discuss issues, and then assign action for those issues.

Project team members should provide their reports to the Project Manager prior to the status meeting. This is a time-saver. It allows the Project Manager time to integrate the results prior to the meeting.

To avoid open-ended status meetings, a Project Manager should avoid delving too deeply into issues, or trying to resolve issues at the meeting. It becomes a waste of people's time. It is far better to assign detailed discussion and resolution to a small number of people and expect a report back regarding the resolution and status. (For more information on Issues Management Plan, see Planning: Procedural Planning, Project Administration.)

It's a good idea to keep the number of people at meetings to the smallest number possible while making sure that you are communicating efficiently and effectively with all those who need to be involved in status and issues. In large projects, it is desirable to have status meetings attended by the project team representatives from all functional areas including subcontractors. This is often a large number of people. Keep these kinds of meetings particularly to the point. Don't waste people's time.

Often it is possible to have functional group and vendor teams meet separately so that their representatives can bring issues to the full status meeting and bring back issues and resolutions to their constituents. This, of course, adds overhead and increases the risk of misinformation caused by less than accurate communication. The issue of how many meetings, who will attend and how the content of each will be recorded and distributed should be worked out as part of the Communication Management Plan.

Higher-Level Meetings

In addition to working-level status meetings, many projects will include higher-level meetings at which presentations are given to senior managers and clients. These are more formal presentations and require more preparation than the working level meetings. Higher-level meetings are generally held on a monthly

PM Basics


basis (depending on project duration, criticality, the needs of Stakeholders, among other factors). Set the frequency, attendees and agenda up front as part of the Communication Management Plan.

There should be no surprises at these meetings. They are an opportunity to get some face-to-face time with the Sponsor, Steering Group and Client, address high level issues and questions, and request these Stakeholders facilitate key decisions and action items.

Remember, part of your job as Project Manager is managing upward, and getting the higher-level Stakeholders to perform in a timely manner is not always easy. High-level meetings are useful forums for not only keeping people abreast of what goes on in the project, but to remind these busy Stakeholders of their roles and responsibilities.

You can learn about how to hold effective meetings in Executing: Effective Meetings.

PM Basics


Earned Value Analysis and Percentage Complete Reporting

Overview

Many Stakeholders want to see very concise high-level information to get a quick understanding of the state of the project, before they go into detail. Some, in fact, never want to go into detail. Others want detail only when the high-level indicators flag an exception, such as over budget, behind schedule, or ahead of schedule.

We’ll address two of these high-level indicators:

Earned Value Analysis

Percentage Complete Reporting

Earned Value Analysis and simple Percentage Complete Reporting are means to get a high-level view without going into individual tasks on any level of the WBS.

Earned Value Analysis

An advanced technique appropriate for giving a high-level picture of where the project is, from a schedule and cost compliance perspective.

First used by the United States Department of Defense called Cost/Schedule Control Systems Criteria (C/SCSC). In 1996 the Department of Defense (DOD) accepted the private industry rewrite of the criteria which also renamed it Earned Value Management Systems (EVMS).

Earned Value Reporting

Earned Value is most often reported based on three key values for each activity:

1. Planned Value (PV).

2. Earned Value (EV).

3. Actual Cost (AC).

PV

Planned Value is what we typically think of as the Budget. That’s the amount of effort or money that we were expecting to spend if we accomplished all of the work that we expected to do in this period

EV

Earned Value is calculated by determining what we’ve budgeted for the work that’s actually been accomplished to any given point in the project. We’ve done a certain amount of work and we had expected to spend X amount of dollars (or hours of effort) to do that work. So this is the value that’s been given to the work that’s actually been performed.

AC

Actual Cost is what it has actually cost for the work that’s been done up to any given point in the project. It is what we capture from the internal team members as they execute the project plan and from funds paid for other goods and services used by the project.

Schedule Variance

If you subtract PV from EV you get what we call Schedule Variance (SV). That’s the difference between what you expected to get done by a specific point in time in the project and what you actually got done. If the result is positive, you are ahead of schedule. If it is negative, you are behind.

You can turn this into a percentage by dividing the SV by the Planned Value. You can calculate a Schedule Performance Index (SPI) by dividing Earned Value by Planned Value.

1. SV = EV-PV

2. SV% = SV/PV

PM Basics


3. SPI = EV/PV

Budget or Cost Variance

Subtracting AC from EV tells you whether you are on budget. This is referred to as Cost Variance or CV. If the CV is negative then you’ve got a budget overrun.

You can turn this into a percentage by dividing the CV by the EV. You can calculate a Cost Performance Index (CPI) by dividing EV by AC.

1. CV = EV-AC

2. CV% = CV/EV

3. CPI = EV/AC

Forecasting Project Completion

The Cost Performance Index can be used to predict the project’s outcome. We extrapolate to the end of the project based on performance to date. But be careful. Extrapolation based on performance up to a point can be misleading. It is preferable to predict the outcome based on periodic reevaluation of the work left to be done.

The Budget at Completion (BAC) is the estimated budget amount for the project. If it is divided by the CPI, we get the Estimate at Completion (EAC). That is the amount we expect the overall cost to be at the end of the project, based on performance to date.

Variance at Completion (VAC) is the difference between BAC and EAC.

Estimate to Complete (ETC) is the estimate from the current point in the project (or any activity) to the completion. It is calculated as the EAC – ACWP or it is estimated based on reevaluation of the work left to be performed.

For more on Earned Value

This course does not go into any more detail about Earned Value Analysis and Reporting. If you want more information, see the book: Project Management: A Systems Approach to Planning, Scheduling and Controlling – 11

th Edition by Harold Kerzner (John Wiley & Sons, 2012) Chapter 15, Section 15.5.. You can

also see Earned Value Project Management by Quentin W. Fleming and Joel M. Koppelman (Project Management Institute, 2000).

Percentage Complete Reporting

This metric is a single number measure that indicates what proportion of the project or a part of the project has been done; the percentage of current budget expended is an example of Percentage Complete Reporting, but not necessarily a good one.

Be careful here. When talking about how much work was accomplished, many people in projects pull a percentage out if the air or figure that if a task was supposed to take ten days and five have gone by then the task is 50% completed. These kinds of Percentage Complete Reporting lead to misunderstandings and missed expectations.

If you are going to report a percentage of the work complete, then use an effective, consistent system.

Forecasting to Completion

Throughout project life there is a need to reassess the project plan to forecast the project completion. As we perform the project, we learn more about the product, the resources, tasks and other assumptions we've made in the planning phase. Thus, we are in a better position to predict the project outcome.

Forecasting to completion is looking at the rest of the work to be done and estimating its duration and cost, in light of what has occurred to this point.

PM Basics


There are two principle approaches:

Extrapolation based on statistical analysis of the work performed

Re-estimating the work remaining

Extrapolation

In large projects, extrapolation using Earned Value data can be used to predict the project outcome, based on performance to date. But this type of forecasting can be misleading. Ultimately, it is necessary to know the cause of budget or schedule variance to determine how it will impact the budget and schedule, and how likely proportional variance will continue for the remainder of the project. (For more information see the book: Earned Value Project Management by Quentin W. Fleming and Joel M. Koppelman)

It is also possible to assume that the impact of slippage can be predicted by seeing how the critical path changes as a result of the slippage. If a critical path task slips by five days, by definition, the project end date slips by five days. Any PM tool can easily compute the resulting end date. But the result of assuming a slippage in a critical path task will cause an equivalent slippage in the project end date is often misleading. Often you can do something to change the impact of the slippage.

Re-estimating

Re-estimating is much more labor- and mind-intensive, and ultimately more accurate. To re-estimate, you:

1. Look at what has occurred.

2. Determine its cause.

3. Evaluate to see if the cause implies similar variance in tasks yet to be performed.

4. Reassess staffing, methods, estimates and task sequencing to see how the rest of the project might be changed to avoid problems, and/or make up for any negative variance to date.

5. Update the project plan accordingly to forecast the outcome.

(For more information see the topic on Corrective Action.)

Don't be Afraid to Give Really Bad News

It is not a good practice to frequently change the project end date or budget. If there is substantial variance or if you expect variance, it is better to step back and assess the remainder of the project.

If you find that the project is likely to be very late, (for example, if a six month project is likely to take a year, based on your current estimate), it is better to give that news to management and the Client sooner rather than later. They should have the opportunity to consider canceling the project—an opportunity they would not have if the project slipped a week at a time until it was a year late.

Performance Report Outline

The following outline can be used at any level of the Work Breakdown Structure. It contains the basic information required by a manager to determine what has happened during the reporting period and how that might impact the project's future. A key feature is to highlight exceptions and require that reporting include enough information to permit evaluation of problem cause and impact.

Project ID

Performer/Group

Prepared

Dates Covered

Work Plan for Report Period (week)—What Was Expected to be Done.

Tasks Accomplished

Planned

PM Basics


Unplanned (exception)—Why, What Impact?

Tasks Planned, Not Accomplished (exception)

Why?

When is Completion Expected?

Impact

New Tasks Discovered (exception)

Why?

When Scheduled?

Impact

Review Project Status

Summary Information— Percent Complete or Earned Value

Graphic Representations— Annotated Gantt Chart, Budget Tracking Chart

The Review Project Status part of the report can cover any or all of the following:

Financials (current expenditures vs. budget)

Time (schedule-tracking based on accomplishments vs. the baseline schedule)

Resource Utilization (actual vs. expected availability, actual effort vs. planned)

Risk Management Issues (highlighted risk areas with indication of criticality)

Quality Management Data (e.g., number of defects in various stages of repair)

Audit Issues (audit results and open issues)

Status Reporting Sample Techniques:

Annotated Gantt

Effort Tracking vs. Baseline Plan

Status as of a Specific Date

Gantt Showing Actual vs. Scheduled

Budget Curve

PM Basics


Taking Corrective Action

Corrective Action

Corrective Action means making a move or adjustment to reduce or eliminate the cause or the impact of slippage—like working overtime or adding more resources to keep the project going in the right direction.

The type of action you take depends directly on the nature of the cause of the slippage and current project conditions. For example, in one instance you might have slippage in an activity that lends itself to correction by adding more resources, while in another instance, adding more resources might make things worse because of learning curves.

Corrective Action: What Can You Do About Slippage?

Identify slippage (use status reports).

Determine the cause.

Evaluate alternatives (accept, change the baseline, take action to reduce or eliminate).

Act.

For Schedule Slippage

The following alternatives are possible to recover from schedule slippage:

Get more resources, but be careful, there may be learning curves, hiring lead times and/or facilities issues that might affect your schedule.

Have human resources work overtime, but beware of burn-out and reduced productivity and their impact on the project.

Use human resources on multiple shifts.

Change resource assignments to maximize the use of the most effective resources on the most critical tasks and to eliminate "dead wood."

Eliminate barriers to progress; like interpersonal issues, miscommunication, procedural log jams, geographical distances, etc.

Co-locate dispersed staff.

Expedite certain deliverables and approvals.

Reduce the scope by putting off some features or functions of the product to a future project to enhance the product.

Fast track. Change the sequence of tasks, but be careful of the risks.

For Budget Overruns

Seek cheaper supplies or suppliers, but beware of quality trade-offs.

Reduce scope, with client approval.

Work with fewer people to improve productivity (but this is often at the cost of schedule slippage).

Work smarter.

Reduce logistical barriers.

Planning

Assessing and determining corrective action is a planning activity taking place during project life. Refer to the topics on estimating and scheduling and plan negotiation for principles that apply here.

PM Basics


Trade-off Analysis

Trade-off analysis is the process of weighing the pros and cons of different corrective action options. What are the trade-offs? Do the potential gains outweigh the risks and costs associated with the action?

The topic on Corrective Action lists a set of possibilities and things to be aware of when considering taking action.

The Key Principles Here Are:

You pay a price (cost, increased risk, product quality reduction, etc.) for every expected gain.

Don't react. Think first, then respond.

Example: If the project is slipping and hitting the target date is critical to success, the PM might consider doing less testing to speed up the process. The trade-off for the gain in time is the risk of finding errors in the product after it has been delivered. The cost of fixing those errors will be much greater, and the impact on the Client and the Client's opinion of the PM and her firm will surely be negative.

Are the risks worth the rewards? It's hard to tell without more information. If the earlier delivery is done to beat the competition to the market and the errors in the product are not expected to be too serious, then the reduction in testing may well be worth considering.

Most often, we don't recommend trading-off quality for schedule, but in the end it is a business decision.

Changing the Baseline Budget and Schedule

Sometimes we have such a significant change in schedule and budget that it requires changing the baseline. For example, when you hit a major phase endpoint and have found out that the project is very different than you thought it would be—that's a good time to change the baseline.

There are three baselines: the schedule, the budget and the scope. We can change any or all of them at any time, given appropriate authorization.

Authorization Required

If you change the baseline, you're shifting the end dates of the project, the nature of the product and the budget. That requires going to the Steering Committee and/or the Client for authorization.

Be Careful

Be very careful about changing the baseline. If you do it more than once or twice in the life of a project, people lose confidence in the plan. In effect, they don't know when to expect the project to end, how much to expect it will cost, and what the product will be.

When it is necessary to change the baseline, don't simply adjust a little bit at a time. Step back and completely reassess the project, as if you were starting it from where you are. If it seems that things are worse than you thought, you are probably right. Own up to it. Give Senior Management and the Client the full bad news and what you think should be done about it. They then have the information they need to make the decision as to what to do next—cancel the project, accept the overrun, or do whatever it takes.

When to Change the Baseline Plan

At checkpoints (usually after major phases).

When the variance is so severe that there is no chance of recovering.

When changes in project scope require re-planning.

Archive Old Baselines

Whenever the baseline is changed, you should archive a copy of the original baseline for use when reviewing the lessons learned for the project.

PM Basics


Closing

Overview

The Closing Process Group consists of those processes performed to finalize all activities

across all Process Groups to formally close a project or phase. In this section, we will address:

Transitioning to the Product Life Cycle

Learning from the Experience

Transitioning to the Product Life Cycle

Sign-off, Acceptance

Projects end for one of two reasons: either the objectives have been met, or the project is canceled before the objectives are met.

Acknowledgement That Objectives are Met

When the objectives have been met, we need to get acknowledgement from the Customer and others to officially end the project. This acknowledgement may be formal acceptance, usually the signing of an acceptance document (sign-off). Or, acknowledgement may come in a more informal manner, shown by the Client paying for the product and using it for a period of time.

Generally, we recommend getting formal, explicit acceptance. There is nothing like clarity.

Who Accepts the Product?

Acceptance is generally viewed as being the prerogative of the customer. However, there are others, depending on the type of project and product, who may need to sign-off on the product before it is accepted. These others include people who will support or operate the new product, people who will sell it, and people in regulatory agencies who must approve it.

How is the Product Accepted?

Acceptance should be based on an evaluation of the product using Acceptance Criteria set during the early phases of the project. When the project began, we set requirements and these have to be met for the product to be accepted. Testing the product against the acceptance criteria validates it.

Testing is a significant part of the work (time-, effort- and cost-intensive) and is done in many projects.

Deferred Action Items, Issues

Remember Change Management and Issues Management? When we use these techniques to stabilize and control the project, we often postpone acting upon requested changes and issues that have been raised during the course of the project. These action items have not been put off forever—they've only been deferred. At the end of the project, it is necessary to take a look at these deferred items and decide what to do about them.

The Options Are:

1. To not act upon them.

2. To act upon them before closing the project.

3. To act upon them in a subsequent project.

PM Basics


In certain situations, the project budget and schedule will include a Post-Implementation Phase, which includes making enhancements and corrections of defects to the product. In some situations, a project—or series of projects—is planned for the future to make the enhancements and corrections. In other situations, price adjustments may be made.

In all cases, the customer and others evaluate each of the deferred items and make decisions as to how to handle them.

PM Basics


Turning Over the Product

The project results in a product and the product must be turned over to the customer and/or to the people who will take ownership and control of it.

Projects are Temporary. The Product May Live On

Those products that have a long life may require manufacturing, ongoing maintenance, ongoing support, and/or ongoing operational use.

Turning the product over requires that training, documentation, and initial support activities be part of the project deliverables. The turnover process often requires special skills.

It is important to plan for the turnover, particularly to make the people with the right skills available, and to ensure that the people who will take responsibility for the product are also available.

There are many examples of projects that develop wonderful products that are never used because their turnover is not properly executed.

Learning from Experience

Post-Project Review

In some projects, the Post-Project Review is called the Post-Implementation Review (PIR). The purpose of the review is to assess:

Product performance: Is the product useful? Cost-effective? Marketable?

Project performance. Were objectives met on schedule and budget? How did performers and vendors perform? Were tools and techniques effective? Were vendors cost-effective?

Product Performance evaluations are usually conducted after a product has been in use for enough time to obtain measurable results. Process and vendor evaluation should be performed close to the project's completion, or close to a major phase completion in large projects.

Who are the Evaluators?

The evaluation itself can be conducted by a high-level group of individuals independent of the original project team and the user organization. The evaluation group should contain or have access to people with the technical and business expertise needed for evaluation of the various aspects of the project and the product. If external review is not conducted, the project team itself can perform the review.

Project Archives

Project results are not limited to the product and its documentation. Throughout the project, Project Management Documentation has been created which includes:

The project management plan, including estimates and schedules.

Progress data (actual effort, costs, etc.).

Status reports.

Change requests and responses.

Issues and resolutions.

Checkpoint review results.

The data in this documentation may be useful in the future. Actual results, causes of changes and issues, causes of slippage, and the plan itself can be used to evaluate performance and help to improve the overall project management process. The documentation can also be used as a basis for planning and estimating future projects that are similar in nature. That's why archives should be organized by type of project.

PM Basics


Team Transition

The project team disperses after most projects, though there are many examples of Project Teams that work together across many projects.

The transition of the team members from one project to the next project, or back to operational activities, may take place throughout the project's life. As a person's role is completed, that person moves on.

Like everything else, the transition must be planned. Having staff idle is not good for business, nor is it good for the individual (unless, of course, it's a paid vacation!).

The transition process should include:

Acknowledgement and recognition of the work of the project team.

Reassignment of the performers, usually by their functional managers.

Performance evaluation of the performer by the project manager, and of the project by the performer.

Knowledge Transfer

We seek to learn lessons from each project. The Post-Project Review, archiving of project records and performance evaluations are all means for learning. This learning should not be limited to the project team members.

The overall project management process should include procedures for transferring knowledge to people throughout the organization. These include:

Coaching

Creation of a "Knowledge Database," with access by type of project, specific topics, or issues

Peer support groups

Of these, the "Knowledge Database" creates the foundation for both coaching and peer group activities. The database takes the lessons out of individual minds and records them in a way that makes them easily accessible to anyone with a need to learn.

PM Basics


program introduction : learning...

Documents