Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  



BulgaraCeha slovacaCroataEnglezaEstonaFinlandezaFranceza


Define the project team


+ Font mai mare | - Font mai mic


Trimite pe Messenger
Project Documentation: Procedures, Forms, Memos, and Such
Fundamentals of Information Management the Internet, and
Techniques for Estimating Work Times
Organization and Teamwork
The Qualities of Good Leadership
Define the project team
Presentations - Planning and preparation
Telephoning - Telephoning across cultures
Management - What is management?

Define the project team

Project management supports three basic levels of projects: projects, subprojects, and programs.

What Is Project Management?

People sometimes use the terms project management, project, subproject, and program without understanding their meaning. So letís first define these terms and compare their meaning. Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder objectives and expectations from a project (from PMI).

Project management supports three basic levels of projects: projects, subprojects, and programs.

A project is a temporary endeavor undertaken to produce a unique product or service.

A project is a unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective that conforms to specific requirements, including the constraints of time, cost, and resources (from ISO 10006).

Projects differ from operations, such as manufacturing, in that operations are ongoing and repetitive, while projects are temporary and unique (from PMI). Projects can range from simple efforts to large, complex undertakings that require much time, effort, and money.

Like a project, a subproject is:

  • A temporary endeavor undertaken to produce a unique product or service
  • A set of work units assigned to a single project organizational unit to divide the project into more manageable components

The Worldwide Project Management Method (WWPMM) defines a program as a group of related projects and other activities managed in a coordinated way to achieve a common long-term objective.

What Are the Main Differences between a Program and a Project?

The main differences between a program and a project are that a program achieves a strategy or mission, is realized through multiple projects and ongoing activity, and has a scope that might be either broadly defined or specific. A project, on the other hand, has a start and a finish, achieves a single set of defined objectives, and is a tactical initiative.

What Is Project Management?

WWPMM defines project management as the application of knowledge, skills, tools, and techniques to project activities to meet or exceed stakeholder objectives and expectations from a project (from PMI). WWPMM also defines project management as the planning, organizing, monitoring, and controlling of all aspects of the project in a continuous process to achieve its objectives (from ISO 10006).

  • Domains. These are related sets of project management processes (such as supplier management) that generally focus on the same set of project management data (such as supplier agreement). The content of the project management domains constitutes the reference view of WWPMM, which is a view that is intended to be a complete guide to all aspects of project management for the practicing project manager, similar to an encyclopedia.

  • Work patterns. These are related sets of activities the project manager should do or think about in order to meet a project management goal or to respond to a typical situation.

  • Work products. These are the verifiable outcomes that are used to manage the project (as opposed to technical work products, which are items produced by the project, such as hardware, software, and services). Some examples of project management work products are the work breakdown structure, the risk management plan, and the communications plan.

WWPMM defines work units as portions of the work to be done that have certain common properties and therefore are appropriate to group and assign to one subproject or project organizational unit. Work units are used in early definition stages to help organize and construct the work breakdown structure (WBS).

WWPMM defines the project management system as the management system for a project. It includes processes, resources, roles, and responsibilities. It is documented as a collection of plans, procedures, and records that define and support the way the management of the project operates.

The Project Management System (continued)

The project management system of a project comprises the following items:

  • Project management resources and tools
  • Plans that describe the work to be performed and how the project will operate
  • Procedures to ensure that key tasks are performed in a systematic and visible manner
  • Records that the project manager uses to control status and events
  • Project management activities that are used to plan, control, and react to day-to-day situations

The Project Management Knowledge Network

You would not manage a project 10 years from now the same way you would manage a project today. Just as you develop in your personal life, you should always be looking for ways to manage your projects more efficiently. One way to do this is to reuse the lessons learned from other project managers.

The Project Management Knowledge Network (PMKN) can be a useful tool for you as a project manager. It can help you in many ways, including:

  • Using the PMKN to leverage the knowledge and experiences gained by other project managers. Research has shown that up to 15% of a projectís cost can be avoided with proper use of intellectual capital.
  • Exploiting this knowledge to help reduce project risk, complete deliverables on or ahead of schedule, and increase the productivity of the project team.

You can also help other project managers learn from your experience by giving the PMKN the knowledge acquired in your projects. This supports current and future projects and also establishes your project management credentials.

Use the following steps to access ICM AssetWeb through the Knowledge portal.

  1. Click IBM Global Services Knowledge Portal.
  2. Click Intellectual Capital and Assets.
  3. Click Project Management to access the PMKN.

More information about the PMKN is available in Module 12, 'Project Closeout.'

Managing Projects in Different Environments

Every project has a definite start and finish. Projects are usually divided into phases; the phases comprise the life cycle of the project.

Phases help you to reduce the risk on your project.

Managing Projects in Different Environments

Every project has a definite start and finish. Projects are usually divided into phases; the phases comprise the life cycle of the project.

Phases help you to reduce the risk on your project.

A customer is the recipient of a product or service provided by the delivery organization.  The customer might be the ultimate consumer, user, beneficiary, or purchaser  (ISO 8402).  The customer might also be the sponsor.

IPD funding is approved on a phase-by-phase basis, based on a number of considerations, such as the business case and risk assessment.  The key decision point is at the end of the plan phase, when the DCP contract is signed.

WWPMM.  In this methodology, the IBM delivery organization can have relationships in either the IPD or the CRM business model.  The cost and staffing level curve in the figure shows how resources are used in the various phases of a project.  The curve shows that resource usage normally starts at a low level during the initial phase, increases quickly during the intermediate phases and then decreases during the final phase.  The specific rate of increase or decrease, and the peak usage varies from project to project.  However, most projects follow this curve.

The graphic shows the phases in the life cycle of a project in the environments in which we are most interested: Integrated Product Development (IPD), Customer Relationship Management (CRM), WWPMM, and Project Management Body of Knowledge (PMBOK).

The following table will explain part of the graphic:

Initial Phase

Intermediate Phase

Final Phase







Solution Design

Solution Design

Solution Delivery

Solution Delivery




Develop Qualify Launch

Life Cycle Close






Note: The cost and staffing level is lower at the beginning and final part of the project. And it is higher in the intermediate phase.

IPD business model.  In this model, the IBM delivery organization might have a relationship with the Integrated Portfolio Management Team (IPMT), as the project sponsor, or with an external customer. 

CRM business model.  In this model, the IBM delivery organization has relationships with both an opportunity owner within IBM and an external customer.

Major Process Groups in PMBOK.  The major process groups in PMBOK are Initiating, Planning, Executing/Controlling, and Closing.  These are the groups used by PMI.  The activities within these groups are similar to those in WWPMM.  Both are oriented to establishing and enforcing a disciplined approach to project management that will help IBM succeed on projects.

A customer is the recipient of a product or service provided by the delivery organization.  The customer might be the ultimate consumer, user, beneficiary, or purchaser  (ISO 8402).  The customer might also be the sponsor.

Major Phases in IPD  

  • Concept and Plan.  During these phases, a selected opportunity is developed into an offering proposal that is presented to the Integrated Portfolio Management Team (IPMT) as the project sponsor.  A Decision Checkpoint (DCP) contract must be signed to proceed to the develop/qualify/launch phase.  Product development applies to asset-based projects targeted for multiple customers (mass production).  There are always more ideas and product marketing opportunities than IBM can effectively manufacture.
  • Develop/Qualify/Launch.  During this phase, the product or offering is developed and launched in the marketplace.
  • Life Cycle/Close.  During this phase, the product or offering runs its course in the marketplace and is finally withdrawn.

Major Phases in CRM  

The two major phases of the CRM framework are solution design and solution delivery.  

  • Solution design.  During this phase, the selected opportunity is developed into a proposal, which is presented to the customer.
  • Solution delivery.  This phase starts when a contract is signed by the customer.

Major Process Groups in WWPMM 

In WWPMM, phases are referred to as process groups.  The major process groups are Defining, Planning, Executing/Controlling, and Closing the project.  Depending on the project, it might be appropriate to apply all the WWPMM process groups within one individual project  phase.  An example would be using the Defining, Planning, Executing/Controlling, and Closing process groups were all used for one of the IPD phases.

  • Defining.  In this process group, the objectives of the project are agreed upon, the scope of the project is established, the initial organization is defined, responsibilities are assigned, and the assessment of situational factors is documented.
  • Planning.  In this process group, detailed work and risk management plans are developed, the organization is confirmed, staff assignments are made, and the budget and time frame are agreed upon.  No significant amount of resources is expended on the project (in other words, execution does not begin) until clear plans are in place and authorization to proceed has been received at the end of this phase.
  • Executing/Controlling.  In this process group, the plans and controls are used to execute and manage the project as project development and delivery work is performed.  As work proceeds, plans are expanded or refined as necessary.
  • Closing.  In this process group, the sponsor agrees to close the project, the project is closed, and the project evaluation report is produced.  This report includes lessons learned that can be applied to future projects to increase their probability of success.

Behaviors of a Successful Project Manager

Think about successful project mangers you have worked for in the past.  What did they do that made them successful?  More than likely, they possessed the following behaviors in four areas.

Team Building.  A successful project manager should be sensitive to people and situations.  A project manager should be able to facilitate, coach, provide constructive criticism when required, have the ability to build a team, delegate well, be sensitive to wants and needs, and offer praise when appropriate.

Roll your mouse over each team-building behavior to read its definition:

  • Delegation
  • Team development
  • Team member facilitation
  • Feedback to team members
  • Recognizing performance

Communication.  A successful project manager should be able to communicate well, be organized, have the ability to listen, think systematically, and maintain contact with all stakeholders and team members on a project.

Roll your mouse over each team-building behavior to read its definition:

  • Systematic thinking and planning
  • Political awareness
  • Relations with functional managers

Project goal setting.  A successful project manager should be proactive, willing to try new ideas, able to persevere, be goal oriented, able to prioritize, be innovative, and have the ability to plan.

Roll your mouse over each team-building behavior to read its definition:

  • Clarification of goals
  • Innovation and creativity
  • Participative problem solving
  • Standards of performance
  • Goal pressure

Leadership.  A successful project manager should be honest; able to motivate; and be realistic, assertive, decisive, self-confident, enthusiastic, energetic, supportive, and always in pursuit of excellence.

Roll your mouse over each team-building behavior to read its definition:

  • Long-range perspective
  • Risk-taking
  • Strategic inquiry
  • Assertiveness
  • Drive

The purpose of the Project Charter is to document the:

  • Reasons for undertaking the project
  • Objectives and constraints of the project
  • Directions concerning the solution
  • Identities of the main stakeholders

A Project Charter is a document that formalizes the request from a sponsor for responding to a business need.  It is a clear statement of project intent, and it provides a preliminary delineation of roles and responsibilities.  The Project Charter is issued by the sponsor, and it outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority for the future of the project.

The Project Charter is an important tool for establishing the authority assigned to the project manager, especially in a matrix environment.  It is considered industry best practice, and it is a defined WWPMM work product.

Project Stakeholders  

You will learn later on that one of the key reasons for project failure is that stakeholders lose their commitment to the project.  But who are the stakeholders, and why is it difficult to manage them?

A stakeholder in a project is any individual or organization that is actively involved in the project or whose interests might be affected, either positively or negatively, as a result of project execution or successful project completion.  Identifying and communicating with the stakeholders is an important responsibility of the project manager. 

There is an inherent difficulty in being caught between the sponsor and IBM.  Spending all the money in the budget for a fixed-price contract might result in a happy sponsor, but might not meet IBM goals.  The opposite can occur with a time-and-materials contract.

Most projects have a number of stakeholders, and they each have their own objectives to meet on the project.  The project manager must be aware of each of these stakeholders and their respective objectives.  Using this information, the project manager must ensure that what is done on the project is consistent first with the project requirements and then with the stakeholders' objectives.  Ideally, the objectives of the different stakeholders are closely aligned.  If not, a series of negotiations might be required to align the objectives.

An IBM project manager must be many things to many people.  The role of the project manager is to serve as the single point of contact for all matters relating to the project and to continuously balance project scope, cost, and schedule.  This must be done while interfacing with a number of people and organizations within IBM, with the customer, and with external or internal suppliers. 

The Project Charter 

The Project Charter is usually the first piece of documentation produced for a project.  Its purpose is to make the project ďofficialĒ and should be written by the sponsor.  If a Project Charter is missing or poorly written, it can lead to ambiguity about the project objectives, scope, or solution.  This could lead to project cancellation or cost and time overruns.  If the Project Charter is not well-written, it is your responsibility as the Project Manager to go back to the project sponsor and help them create an adequate charter.

A Project Charter is a document that formalizes the request from a sponsor for responding to a business need.  It is a clear statement of project intent, and it provides a preliminary delineation of roles and responsibilities.  The Project Charter is issued by the sponsor, and it outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority for the future of the project.
The Project Charter sets boundaries for the scope of the project.  It formally recognizes the existence of a project.  It should be issued by the project sponsor, and at a level appropriate to the needs of the project.  It provides the project manager with the authority to apply organizational resources to project activities. 

The Project Charter is usually a short document that refers to some other more detailed documents, such as a New Offering Request or a Request for Proposal. 

Some project managers have never had a Project Charter, or if they did, they might have known it by some other name.  Though in IPD, this document is known as the Project Charter, in CRM, it is known as the Project Definition Report.  Both IPD and CRM require this document as part of the project management process.  If the sponsor does not follow either process, it is good project management practice to insist upon the creation of a Project Charter.  As a last resort, if you as the project manager cannot get someone in authority to write the Project Charter, it might be advantageous for you to write it and submit it to the sponsor for approval.

The Project Charter is an important tool for establishing the authority assigned to the project manager, especially in a matrix environment.  It is considered industry best practice, and it is a defined WWPMM work product.

Who Creates a Project Charter 

Project Charters are becoming more common in all kinds of project environments.  Many organizations generate these documents in letter form.  Within IPD, for example, the Project Charter is issued by the Integrated Portfolio Management Team (IPMT), which is the project sponsor.  Within CRM, the Project Charter is written by the project sponsor.  You need to understand the process for creating Project Charters within your business unit.

What Is the Project Definition?  

A Project Definition document is a WWPMM work product that helps the project manager determine the boundaries of the project.  In other words, it defines what the project will and will not encompass.  WWPMM defines the Project Definition as the document that describes the shape of the project. 

The Project Definition document includes the objectives and scope, the stakeholders and the proposed organization, the responsibilities, and the major risks associated with the project.

The purpose of Project Definition is to:

  • Formalize the understanding of the Project Charter by the delivery organization
  • Provide the plan elements in order to control the planning and defining activities
  • Give an initial description of the project framework for the planning activities
  • Gather the fundamental characteristics of the project in a unique document.

Framework for the WWPMM Project Definition

The following framework is for the Project Definition as defined by the WWPMM Project Definition work product.  For assistance with creating a Project Definition, refer to the WWPMM Project Definition work product.  This can be found, along with descriptions and templates for all WWPMM work products, at the WWPMM Portal.

Creating the Project Definition 

You should create an initial version of the Project Definition after assessing the project goals and objectives.  Do this before refining the solution to the level that is appropriate for planning.  The initial version of the Project Definition contains the objectives and the plan for the defining activities. 
To do this, you must review all existing project documentation including documents and correspondence that have accumulated.  Pay special attention to the Project Charter as one of the primary inputs.  You must also meet with the main stakeholders identified in the charter and obtain their view of the target solution and project scope, paying special attention to their needs, and the risks they identify.  Then, based on what you have learned, use the WWPMM template for the Project Definition and fill in the required information.

Worldwide Project Management Method (WWPMM) describes the way we manage projects in IBM.  WWPMM is sponsored by the Project Management Center of Excellence, to support a corporate action directing us to design and implement a single, common project management method for IBM projects worldwide.

It is the project manager's responsibility to tailor the project management (PM) methods, within the constraints of the PM policy, to suit each particular project. 

  • PM Domains provide detailed guidance on how specific types of project management activities are carried out.
  • PM Work Patternsare a series of steps designed to meet project management goals or in response to project management situations.
  • PM Work Products are the templates that are used to manage projects

The WWPMM PM work product contain definitions of the 'verifiable outcomes' of implementing the processes within the method.  They are organized into PM work product groups.  Each work product is part of a Domain. 

There are templates associated with most of the work products.

List of the templates:

Communications management plan
Deliverable definition
Financial plan
Human resource plan
Milestone list
Operational schedule
Organizational breakdown structure
Product breakdown structure
Project decision structure
Project definition
Project management schedule
Project management system summary
Project procedures description
Project quality plan
Risk definition
Risk management plan
Staff schedule
Technical environment plan
Work breakdown structure
Work product list

Action control document
Action log
Asset inventory
Change log
Change order
Change request
Compliance incident document
Compliance incident log
Contact list
Correspondence log
Delivery control documentation
Event log
Expenditure log
Findings log
Individual status report
Issue document
Issue log
Meeting documentation
Project evaluation report
Project status report
Quality review documentation
Risk occurrence document
Situation analysis documentation
Staff list
Subcontractor status report
Subproject/team status report
Supplier selection report
Team charter
Technical environment assessment

Other documents
Project charter

Projects Are Like Small Businesses

One thing that I have learned is that running a project is like running a small business. 
In both projects and small businesses, there is a fine line between being successful and profitable,
and being unsuccessful and bankrupt.  If a business fails, people will be out of work.  A business manager must ensure the business turns a profit so it can continue serving its clients.  Similarly, a project manager must take ownership of the financial side of a project to make the project a financial success.
Both projects and small businesses consume resources, such as staff, equipment, and facilities. 

Projects, like small businesses, have stakeholders, or people who have an interest in the outcome of the effort.  These people might have financial interests, like the allocation of equity capital, or they might have a stake in defining the objectives of the business or project.  Most importantly, they demand returns on capital investment or specific results.
A small business carefully tracks its costs, schedules, and quality.  Small businesses must always watch the bottom line when it comes to financial targets.  The small business owner must work within a budget and control costs.  It is imperative to a small business that it generate revenue and profit to ensure a positive cash flow.  The same tracking is a necessary part of project management.

Benefits of a Project Charter
I always have a Project Charter, the major benefits of a Project Charter are that it:

  • Describes the problem to be solved
  • Provides a vision of how the business need will be resolved
  • Describes the elements of the solution expected by the sponsor from the delivery organization
  • Identifies the main stakeholders in the various organizations involved in the project

Impact of Not Having a Project Charter

Lack of a Project Charter or a poorly written Project Charter often leads to an unclear need that is likely to give unstable direction to the project; possible ambiguity about the project objectives and scope; possible ambiguity concerning the solution; and possible lack of identifying an important stakeholder for the project.

These are serious concerns that you as the project manager must ensure are properly addressed by insisting that a sound Project Charter is established at the start of your project. 

Benefits of a Project Definition 

Using the Project Definition enables the project manager to identify the project requirements from a broader perspective, instead of focusing solely on deliverables.  This ensures a clarity of scope before detailed planning begins.

What Is a Team?

A team is a group of individuals working toward a common goal.  Your team will include people from your organization, suppliers, clients, and the project sponsor, each of whom bring their own skills to the team. 
As the project manager, you must ensure that the team members recognize the skills of the other team members and the ways in which team members depend on each other.

When a group of individuals truly becomes a team, they are committed to the team's values and objectives.  They learn to work well together, they enjoy working together, and most importantly they produce the high-quality results that are key to a successful project.


Organization Types

The type of organization you work in affects the project managerís ability to deliver a project successfully.  The project manager must understand the challenges involved in managing a project within various organizational structures and must anticipate that over the life of a project the organizational structure might change.  There are three types of organizational structures:  functional, projectized, and matrix.  These are described on the following page.

The matrix organizational structure is the one that occurs most often in IBM.  Because the emphasis of this structure is project-based, it must be understood by IBM project managers.
Matrix organizations evolved from the traditional management structure.  Its multi-disciplinary team members are drawn from various line or functional units in a hierarchical organization. 
Less anxiety exists about project termination because the project has been temporarily superimposed on the functional organization.  At project completion, the functional organization remains intact.


Matrix organizations are complex, and present certain challenges to the project manager.  These challenges include the:

  • Authority and responsibilities of the project manager versus the functional manager
  • Communication flows within the team, as well as to and from other groups

Matrix organizational structures affect the authority and responsibility of both the project manager and functional manager, the degree of communication within the project, and the communication flow.

Managing the Matrix  

'.matrix management is a charming form of management, full of variety and disorder.'
From Project Management:  A Managerial Approach by Jack Meredith and Samuel J. Mantel, Jr.

For you, the project manager, successful operation within the matrix structure depends on the attitudes, actions, and activities of the people involved.  Having the following elements in the project can help ensure a more successful project:

  • A Project Charter that assigns responsibility and authority to the project manager from the project sponsor.
  • A good working relationship between the project manager and functional managers
  • An understanding that a project manager's job is accomplished primarily through the process of negotiation and leadership
  • Project team members who must overcome confusion and split loyalties, and adapt to a two-boss situation
  • Negotiation and leadership skills are essential for making the matrix work.  In addition, communication is critical to success.

Tips for Making the Matrix Organization Work

The following list describes a few of the project management techniques that will help you, the project manager, in a matrix organization.

  • Have a Project Charter.  This gives authority to the project team.
  • Anticipate and channel conflict.  You need to use appropriate leadership skills.
  • Establish a clear project scope.  You should define and enforce the scope of the project.
  • Promote teamwork.  You should use appropriate management practices.
  • Document approvals.  Documentation becomes essential to managing all aspects of the project.
  • Engage in careful and continual project management planning.
  • Plan globally and think locally.  You need to keep the entire scope of the project in mind while being ready to act decisively on a day-to-day basis.
  • Develop political awareness.  This involves knowing which individuals are the influencers who can affect the project.  It also involves knowing the goals of the stakeholders, both obvious and hidden.  You should be aware of your own capabilities and those of your project team.
  • Think about the projects you are assigned to. How well is each of these points practiced?  If any of them are not being practiced, write a note to yourself on how you can improve your project in that area.

How Organizational Structure Influences Projects 

You have been introduced to three types of organizational structures and how authority and responsibilities generally flow through each.  The organizational structure has a significant impact on the project.

It is important to remember that the organizational structure often changes during the life of the project.  The key issue is that the project manager needs sufficient authority to successfully execute the project.  You cannot make the project commitments if you do not have the authority to make it happen.  In all of your organizational planning ensure that you have all the authority you need, whether it comes from the organizational structure in the projectized organization or from the functional managers in the functional organization.

The following table illustrates how the levels of authority and responsibility differ between organizational structures.  Note that in this table, moving from left to right, the authority of the project manager increases, as does the percentage of time dedicated to project management functions.  In a weak matrix organization, the functional managers have more responsibility.  In a strong matrix organization, the project manager has more responsibility.  The functional  managers are the providers of resources for the project and the project manager is the customer of the resource.

Project Characteristics

Functional Organization

Matrix Organization

Projectized Organization




Project Manager's authority

Little or none


Low to moderate

Moderate to high

High to almost total

Percent of performing organization's personnel assigned full-time to project work

Virtually none





Project Manager's role






Common titles for project manager's role

Project coordinator
Project leader

Project coordinator
Project leader

Project manager
Project officer

Project manager
Program manager

Project manager
Program manager

Project management administrative staff






Organize the Project Team  

Every team needs to agree on the team goals and how the team will work together to achieve those goals.  One way to do this is to document the team guidelines and project ground rules.  In WWPMM, these guidelines and ground rules are recorded in a document called the team charter. 

The exercise of developing the team charter moves the team through the forming stage of group development into the storming, norming, and performing stages.  Team members who join the team after the charter has been written must also understand and support it.

Team Charter 

As the project manager, you must ensure that your team members are working together on the items that are important to you.  The team charter helps you to do that by documenting the broad performance objectives, roles, responsibilities, and ground rules for the team, and the expectations for the project.

The team charter is divided into several sections:

Team performance objectives

The team objectives and the expectations for the project are documented in this section.

Building a Team

Building a successful project team requires you to take the following steps.

1. Select the right team members.

First, you must identify the specific project skills that are needed, and then bring in people with those skills.  As the project continues, you must continue to validate the team's skills and resources to ensure that no critical skill areas are missing or misrepresented.

2. Organize the team.

As team members begin to work together, the team establishes a set of values.  You, the project manager, must help team members commit to the team and its values.  Each team meeting is an opportunity for team building and team development.

Another part of organizing a team is preparing an organizational breakdown structure (OBS).  This WWPMM work product, which is presented in Module 3, defines the relationships between projects and subprojects, the reporting relationships, and the team structure of the project organization.  All team members should have a copy of this chart, which clearly identifies their roles and responsibilities.

In order to support the team's goals, team members need to understand the background information about the project and team's mission.

3. Ensure open communication.

Communication should be easy and frequent, and team members must feel that they are part of the group.  A variety of communication methods can be used to share information, including meetings, informal discussions, e-mail, and bulletin boards.  All of these should be documented in the communication management plan.

4. Maintain the Team  

After the team is formed, your time, effort, and attention are required to maintain it.  In addition to making necessary adjustments in team personnel, organization, and communication, you must consistently:
5. Motivate the team.

Once the team is assembled, the team members must be motivated to work.   The team members' degree of motivation determines how much they give to the project and how supportive they are of the project goals.  As a project manager, you might not have the same leverage as a functional manager, who controls motivators such as pay and promotion.  As a result, you must choose your motivators carefully.
All motivators can be classified as appealing to either logic or emotion.  Logical motivators can be positive, for example, benefits or quality; negative, for example, loss of benefits and poor quality; or educational, for example, objectives, conditions, explanations, demonstrations, and good judgment.  Emotional motivators include generating trust and confidence, stimulating thought, and avoiding hidden agendas.
6. Recognize and reward team behavior.
You must recognize and reward team behavior and support team-based incentives.  In doing this, you should emphasize the team's collective performance rather than singling out individuals for their specific achievements.
7. Respond to team change.
Throughout the life of a project, individuals will be added to the team and members will leave the team.  Fluctuating team membership is a challenge for every project manager and must be recognized and dealt with in a direct and timely way.

Considerations for the Multicultural Team

When managing a multicultural team, always consider variations in social customs, time zones, protocol practices, and language proficiency.  Failure to recognize differences often leads to hurt feelings and misunderstandings that might affect the smooth functioning of the team.  Some rules are:

  • Conduct conference calls during times that are waking hours for all participants.
  • Be considerate of holidays and work hours, both of which differ across cultures.
  • Avoid using slang, colloquialisms, and nuances when communicating with people for whom the language in use is not a first language.
  • Avoid humorous remarks; they are not always funny in other cultures.
  • Be considerate of other cultures' protocols.  These might include showing respect for management, avoiding public appraisals, and deferring to senior members.

What Is Communication Management? 

Many new project managers do not realize the importance of communication to project success.  The Project Management Institute (PMI) says that project managers spend about 90% of their time communicating.  That means you need to have a plan so that communication on your project is timely, is directed to the right audience, and get the message across.  But remember, the project manager does not have to do all the communicating.  Team leaders and project staff can support the communication.  Letís examine the process for developing a communications management plan.

A good project team must have effective communication within the team and between the team and the project stakeholders.  A hazard in project management is the belief that communication links are functioning effectively as long as people are communicating with one another.  The truth is that communication must be well planned to be effective.  As the project manager, you are responsible for planning, building, and maintaining effective communication.

To do this, you must first recognize the variety of communication that a project needs.  Different communication channels have different requirements.  For example, communication from the project manager to the project sponsor and the client has one set of requirements.  These differ greatly from the requirements of communication between project managers and their teams and subprojects, or between the overall project manager and the project managers of subprojects or related projects.

Suppose you want to convince a key stakeholder of the merits of the solution you are building.  What medium do you think will be most effective?  Will sending an e-mail be enough to convince her?  Probably not.  E-mail and other written forms are best used to transmit information.  To gain commitment from a stakeholder, you usually need to personally connect with him or her one to one or in a group meeting, and secondarily over the telephone.

The medium for each communication link must also be defined.  Some communication takes place in weekly status meetings, including face-to-face meetings, electronic meetings, and conference calls.  Alternatively, communication could occur as written reports, electronic memos, or e-mailed documents.  Internet or intranet posting is another potential communication medium.  Project information can be updated and posted online where people who need it can access it at all times.

Your decisions regarding communication will be affected by the geographic location of the team members, the frequency of communication required, and the technology that is available. 

If all the team members are in the same location, you might want to consider a team room approach.  

Developing a Communication Management Plan

The various communication requirements and your decisions about them are documented in the communication management plan.  The plan includes what is being communicated, how it is communicated, who is communicating, to whom is it being communicated, and how often this must happen.  You should create the plan during the project planning activities.  As you start execution, it might be necessary to expand the plan or adjust it.

There is a WWPMM work product description and a template to assist you in creating a communications management plan.  These, like all WWPMM work product descriptions and templates, can be found at the WWPMM Web site.


Determining Project Communication Requirements 

The purpose of communication planning is to be proactive, anticipating what type of information stakeholders will need and when they will need it.  If you are not proactive, you will end up spending lots of time responding to ad-hoc information requests, or worse, lose commitment from key stakeholders.

Before you can create a communication management plan, you need to determine the project's communication requirements.  To do this, you must first review:

  • Memos from the sponsor
  • The agreement
  • The project definition
  • The project decision structure
  • The organizational breakdown structure (OBS)
  • Any supplier agreements
  • The project procedures description

Next, the information needs of the various stakeholders should be carefully analyzed to determine the information that will be provided and the sources of that information.  Include the requirements of the project team, the sponsor, the suppliers, the delivery and performing organizations' management, and others who might need information regarding the project.  Information for this analysis can be gathered by :

  • Reviewing sponsor, supplier, and IBM organizational charts to determine official communication channels.
  • Interviewing stakeholders to understand informal communication channels.
  • Interviewing other IBM constituencies that might have a history with or knowledge of the sponsor or the delivery organization's management.

Once that is done, you must document the information requirements of each stakeholder group.  Be aware that policies of the delivery organization often define the format and procedures for status meetings and project reporting.

Creating a Meeting Matrix  

Creating a meeting matrix can make it easier to understand the communications that are required for the project.  The matrix should outline the purpose, content, and frequency of all periodic meetings. 





Author or Owner


Team Leads

Deliverable Status and Action Item Reporting

Ad hoc


Ron Brown

Project Team Leaders

Team Announcement

Review Status and Actions on the Request for Announcements


Face to Face

Ron Brown

RFA owners


PDT for a major e-announcement and delivery


Conference Call

Rosemary Lopez

Product Owners, RFA Owners, Finance, Manufacturing, Engineering


Announce and Ship Readiness with all IBM Divisions and Corporate Staff

Quarterly or Weekly at Announcement

Conference Call

Vijay Kadayam

Corporate and Division Representatives


Developing the Communication Management Plan 

Document the scheduled meetings, reports, and other communications in a communication management plan using the meeting matrix as one of the inputs to the plan.

A WWPMM work product description and a template are available to assist you in creating the communication management plan work product.  For information about this and for descriptions and templates for all WWPMM work products, go to the  WWPMM Web site.

Introduction to the Seven Keys To SuccessTM

This module discusses the Seven Keys To SuccessTM and how this framework is being used within IBM.  It is being deployed throughout IBM and is key to the success of IBM's projects.  Throughout this course, you will find material that answers the following questions:

  • What is the Seven Keys To SuccessTM?
  • How can the Seven Keys To SuccessTM help projects be successful?
  • How do the project manager and project staff apply the Seven Keys to assess and communicate the health of the project?

Project Success Depends on Executive Commitment

Project success is directly tied to effective involvement of business executives and to the speed at which decisions and actions are made.  According to the Gartner Group, the Project Management Institute, and other observers of project management performance, the number one reason why projects fail is related to executive commitment and leadership.

Gaining executive commitment and leadership requires communication both to and from executives.
The Seven Keys To SuccessTM is a means to ensure successful projects.  It is a framework for assessing and communicating project health.  This framework can be used as an effective communication vehicle with executives and other stakeholders on projects.

The Seven Keys To SuccessTM is complementary to the other project management methods, tools and techniques used in IBM.

The Seven Keys to SuccessTM system was created by and for project managers to provide PMs with a systematic approach for dealing with their unique personal challenges in managing projects.

The original research and design team knew there were many methods and tools for planning and controlling projects and the various disciplines, but none solely addressed the PMís unique situation and mindset. The team created a consistent and cohesive approach applicable for all types and sizes of projects regardless of the project phase or circumstance. The resulting Seven Keys to SuccessTM is a simple but highly effective system for all PMs to use in pursuing project management excellence and emulating world class project management. 

Many studies validate that appropriate engagement of appropriate stakeholders is the primary driver of project success.  The Seven Keys to Success provides an excellent but simple means for engaging and communicating with not only all key project players but also the executives who must understand the health of the project and take appropriate actions to ensure success.

Some of the highest performing and most successful Project Managers and Team Leaders are invariably doing the essence of the Seven Keys to Success.  This IBM PM approach simply provides a convenient framework and language for leveraging these best practices across all players. The Seven Keys to Success is included as part of WWPMM and is complementary to the other tools and methodologies used in IBM.

How are the Seven Keys to Success used? 

  1. As a common language for communicating about project health with the team, sponsor, and stakeholders
  2. To set consistent Steering Group agendas for effective project governance
  3. To balance and prioritize corrective actions across all project dimensions
  4. A structure and approach for Quality and Risk Reviews
  5. To identify and highlight underlying root causes of unhealthy project situations
  6. As a checklist for decision making, e.g., scope changes
  7. Effective throughout the Project Life Cycle from Opportunity through Defining, Planning, Executing and Closing

Whatís the Story Behind the Seven Keys to SuccessTM?

The Seven Keys to SuccessTM system was created by and for project managers to provide PMs with a systematic approach for dealing with their unique personal challenges in managing projects.

The original research and design team knew there were many methods and tools for planning and controlling projects and the various disciplines, but none solely addressed the PMís unique situation and mindset. The team created a consistent and cohesive approach applicable for all types and sizes of projects regardless of the project phase or circumstance. The resulting Seven Keys to SuccessTM is a simple but highly effective system for all PMs to use in pursuing project management excellence and emulating world class project management. 

Many studies validate that appropriate engagement of appropriate stakeholders is the primary driver of project success.  The Seven Keys to Success provides an excellent but simple means for engaging and communicating with not only all key project players but also the executives who must understand the health of the project and take appropriate actions to ensure success.

Some of the highest performing and most successful Project Managers and Team Leaders are invariably doing the essence of the Seven Keys to Success.  This IBM PM approach simply provides a convenient framework and language for leveraging these best practices across all players. The Seven Keys to Success is included as part of WWPMM and is complementary to the other tools and methodologies used in IBM.

How are the Seven Keys to Success used? 

  1. As a common language for communicating about project health with the team, sponsor, and stakeholders
  2. To set consistent Steering Group agendas for effective project governance
  3. To balance and prioritize corrective actions across all project dimensions
  4. A structure and approach for Quality and Risk Reviews
  5. To identify and highlight underlying root causes of unhealthy project situations
  6. As a checklist for decision making, e.g., scope changes
  7. Effective throughout the Project Life Cycle from Opportunity through Defining, Planning, Executing and Closing

What Is the Meaning of the Three Colors?

The Seven Keys To Success are used to assess the health of projects.  Based on criteria agreed upon by the project sponsor and project manager for a project, the status indicator of each key reflects one of the following three colors: 

  • Red means urgent; corrective action is required immediately.
  • Yellow means warning; corrective action is required in the near term.
  • Green means that the criteria indicate it is okay to proceed; no corrective action is required.

Traditional project management status indicators tend to indicate the severity of the problem but the Seven Keys indicate both the severity of the problem and how quickly corrective action is needed.

No project team will have all the keys green all the time. 
The status indicators focus the project sponsor and project team members on the issues most critical to the success of the project.

Defining the Technical Environment  

The last few sections dealt with managing the people on the project. Now letís examine managing the environment in which the work is conducted in.  Have you ever worked on a project where the work conditions were poor?  Did this affect the project team?   You know from your own experience that adverse working conditions can affect team morale and efficiency and the quality of the project deliverables.  As you might have guessed, it is the project managerís responsibility to ensure the working environment will promote teamwork and the successful completion of the project.

The technical environment is the collection of physical space, hardware, software, netware, and equipment that is shared by the project team and used to support a project or a subproject.  The technical environment includes the following items:

An office software suite, including word processing, spreadsheet, presentation, and drawing tools

Office communications, including e-mail and access to shared files

Project management tools

Tools that support technical activities in all project phases

Surveying the Technical Environment

The technical environment might or might not be in place before the project starts or additional tools might be needed.  Project needs, costs, expected benefits, and risks must be analyzed before deciding whether to build a technical environment or adapt one that already exists.

On some projects, part or all of the technical environment is provided by the sponsor.  On other projects, the technical environment is a deliverable, to be left behind or transferred to the sponsor at the end of the project.  In any case, in planning the project, the requirements for the technical environment must be defined.

Managing the Technical Environment  

Managing the technical environment includes understanding, planning, acquiring, installing, and removing the technical environment.  It is important to have a plan that provides a clear description of what must be done.

Activities for managing the technical environment include performing a needs analysis, developing an architecture, planning for implementation and maintenance of the environment, and planning for the eventual de-install of the environment.

As part of your technical environment, you should have project management tools that provide:

Project management and operational scheduling

Time tracking

Cost tracking

Risk management

A project control book (PCB)

Access to business systťme

Team is High Performing Key

The project manager has the responsibility of ensuring that the project team is high performing.  This means that the team has high morale, and is getting the job done.  It is important to remember that the project team might include client staff in addition to IBM staff.  It can be easy to tell whether a team is high performing: team members have open communication, they share expertise and issues, and the staff volunteers to take on new tasks. 

Here are some criteria for assessing the Team is High Performing key.

          • The breadth, depth, and caliber of project manager and team skills are appropriate for all phases.
          • Morale, motivation, energy, and collaboration across teams are high.
          • Environment and facilities support productive and effective teamwork.
          • Roles and responsibilities are clear.

Healthy Signs

       Morale is good.

       The team is diverse.

Unhealthy Signs

       Tension can be felt.

       Turnover is high.

       Working conditions are poor.

This indicator, often overlooked, is about talent and experience. It is also about morale, trust, physical environment, reward, and recognition.

What happens if a team is not high performing?

Have you ever worked on a project and the team was not high performing?   

Was their frequent miscommunication between team members, a lack of information sharing, and distrust? 

And how did this impact the project?

More than likely, it impacted the Work & Schedule are Predictable key.  When a team is not working at its best, deadlines are missed, and the quality of the work is not up to an acceptable standard.  The Delivery Organization Benefits are Being Realized key is also affected because of the additional time and cost incurred to make up for the teamís poor performance.

As the project manager, it is your responsibility to proactively ensure the team is high performing.  So make it a point to review the teamís overall performance and plan actions to improve the team environment, moral and productivity.

The following are the WWPMM domains, work patterns, work products, and templates associated with the topics in this module.  For information on all of these resources, see the WWPMM Web site.

WWPMM Domains

  • Human Resource Management Domain
  • Communication Management Domain
  • Technical Environment Management Domain

WWPMM Work Patterns

  • Finalize Project Plan
  • Establish Technical Environment

WWPMM Work Products

  • Team Charter
  • Communication Management Plan
  • Technical Environment Assessment
  • Technical Environment Plan

WWPMM Templates

  • Team Charter
  • Communication Management Plan
  • Technical Environment Assessment
  • Technical Environment Plan
  • Organization Breakdown Structure

The Importance of Planning  

Think back.  Have you ever worked on a project in which the team was not well organized? What happened to the project?

Effective teams don't just happen because the project manager was lucky or had highly-placed friends.  I have seen great project managers with great teams fail because they didn't spend the time defining and documenting how their team would work together.  I have also seen other cases where a team with mediocre skills was able to miraculously fulfill their commitments because of the up-front planning that was done and because the team worked well together and communicated with each other.
'I have a team charter.  Why have  a communication management plan too?' 

I believe a communication management plan is key to a successful project for the following reasons.
The plan facilitates efficient communications and quicker responses, because everyone knows who is supposed to get the information, as well as how the information is delivered and how often.  We all have a story about the stakeholder who surprises everyone and stops the project saying, 'I didn't know' or 'Nobody told me.'  A stakeholder analysis ensures the PM considers all stakeholders and their information needs.  The communication management plan is the plan that ensures that the stakeholders receive the documentation and communication they need, and answers their questions.

Remember that project managers are not the only ones responsible for project outcome.  Communication between the project manager, team, and stakeholders is crucial.  I remember early in my career, I was a project manager on two very different projects.  One was my best project, and the other was my worst project.  These two projects occurred one right after another in the same year.  One project had a Chief Information Officer who appeared to me to actively work to see the project fail.  And he succeeded; it failed.  The other project was the best project I had ever managed.  In this project, it was the client who made the difference.  This client took responsibility, made difficult decisions, took political heat, and truly owned the result.  Could it be that I completely failed in one project and was a success in the other?  Did I change tactics or become a different person?  No, in fact my best project happened immediately prior to my worst project.  This was my first lesson that we, as project managers, are not the only people responsible for project outcomes, whether the outcomes are good or bad.  So itís important to understand your stakeholders and have a plan for keeping them committed to the project.

Finally, one of the most frustrating things that I have experienced as a project manager is when team members are spending time talking to the clients or sponsors.  First of all, they don't have time to do the work I need for them to do and talk to those people.  Also, they only see a small part of the whole project.  Often times, their opinions of the other parts of the project are not based on facts, and then I have to spend hours of my time doing damage control.

I have found that if I create a communication management plan and get the team to agree to it, it really does save me and my team time and money.

'Why is a team charter important?' 

In my opinion, the real value of a team charter is the exercise that you go through to create it.  It forces you, as the project manager, and your team to discuss how you're going to work together.  It forces you to agree on the project goals and the roles and responsibilities of each of the team members.  Unfortunately, if you don't create the team charter, most of the time you also don't go through the thought process to figure out how the team should function.

'Why do I need to have a technical environment plan?' 

I think the technical environment plan is critical.  We're all communicating and working using technology.  Unfortunately, even within IBM, we're using different software programs and tools or we're on different levels of those programs.  When we're not on the same levels or using the same programs, we have communication problems.  The purpose of writing a technical environment plan is to find those areas where we're not on the same software and fix them before we get to a critical point in the project.  This is really just common sense. 

The place we really see problems is with our suppliers and customers.  Many of them aren't running our standard products, and some of them don't want to be.  In those cases, we need to decide early in the project how to best communicate with them.

Team advice

Let me give you a bit of advice about the Team is High Performing key.  When I was managing the integration project for Coppets-Close Hotels in the UK, I learned first hand how powerful it can be to have a truly diverse team: diverse in style, in nationality, in gender, and in life experience.  And I also learned how hard it can be to bring such a team together, how easy it is to convince oneself to take shortcuts in these efforts, and how tiresome it can be to continually display the leadership that binds the team together.  Do not let these challenges discourage you.  Fight for diversity on your teams, and fight for the time and resources you need to build trust and communications in your teams.  I guarantee your project's performance will benefit.

The main idea of collecting requirements involves a staged process.  Remember the following sequence:

  1. Gather requirements
    - Ask questions by interview sessions (one to one; surveys or questionnaires; and focus groups)
  2. Categorize requirements
    - Organize and document findings by creating categories for the project requirements
  3. Validate requirements
    - Report the findings to the customer

After the requirements are collected, the project manager closes this loop by returning back to the original gathering requirements phase. 

Communicate the business results by examining:

  • Business case (what were the requirements?)
  • Business results (what happened?)
  • Change to the business (what is different now as a result of project completion?)

The Process for Defining Requirements

After the project charter is created, you will probably spend time talking to the sponsor and other stakeholders about
what they expect from the project.  They will have many ideas about what they need, some of which will conflict with one another.  As the project manager, your responsibility is to determine which of these needs the project will actually fulfill Ė the requirements.  Requirements define what the project will deliver.  The requirements document is a formally documented description of the sponsor's needs that must be addressed by the project.  Requirements state what the sponsor wants and what the project staff has agreed to deliver. 
Requirements also serve as the basis for developing project plans.  Your project team needs requirements in sufficient detail to begin work.

The process of defining requirements includes the following steps:

  1. Gather customer and stakeholder needs.
  2. Categorize these needs into either requirements or exclusions.
  3. Validate the requirements.
  4. Use the validated requirements as the established requirements baseline for the project.  


The information you gather about what the sponsor and stakeholders want translates into needs.  Needs are activities, services, products, and deliverables that are useful, required, or desired.  Your job is to turn needs into either requirements or exclusions.  Exclusions are statements of what you will not provide; that is, 'not-included' requests.  They are ideas or requirements for a future project, needs that you will not be meeting or providing in the current project.

Needs are initially identified when a proposal is developed.  These needs are documented in the request for proposal, marketing letters, project charter, contract, and internal document of understanding.  These needs are usually too general to be useful to your project team.  An example of a general or high-level need is 'Train employees to operate a system that does XYZ on ABC's platform.'  Sometimes, details are included; but, usually the details that you and your team require to make this project successful are missing.

Asking Questions

As the project manager, you have many questions to ask about general needs. Examples of these questions are:

  • Must we train each employee or can they train each other?
  • Can we train the night crew during the day, or do we have to provide training for this crew at night?
  • Do we train employees during their work shift, or can we ask them to come in early or stay late?
  • What union rules do we have to be aware of?
  • Describe what success on this project means to you?
  • What would be your 'must have' requirements on this project?

These questions should solicit the detailed requirements that are meaningful to you and your team.  

Always gather needs at the beginning of a project.  Also, when you take over a project that has already started, you must gather needs again to ensure that the original needs are still valid.  They might have changed.

Finding Needs

Needs are documented in several places in project documents, including sections of the request for proposal (RFP), the statement of work (SOW), and descriptions of deliverables and evaluation criteria.  Carefully review all the project documents to look for obvious and hidden needs.
Another important source of needs is the project sponsor.  The sponsor can clarify what you have read in the project documentation.  In some cases, you might find that not many needs have been documented, so the sponsor must provide them.  The sponsor will also tell you who else you should talk to, such as stakeholders or customers of the sponsor, to enable you to clarify the needs of the project.


To gather needs:

  1. Read all project documentation, such as the contract, documents of understanding (DOU), statements of work, and any other documents that might also contain requirements.
  2. Interview the sponsor. 
  3. Prioritize or quantify the answers the sponsor gives you to your questions.  This analysis should help you determine the real needs for your project.

Interviewing the Sponsor

The sponsor will give you his or her interpretation of the needs.  The sponsor might also give you the names of other people to interview.  You can interview the sponsor and other people, or you can use requirements-gathering tools, such as brainstorming, the nominal group technique, focus groups, workshops, and affinity diagrams.
Use structured, unstructured, or semi-structured interviews to identify needs.  The interview process involves identifying each participant, and asking a series of questions based on that person's role in the project.

First, you might need to explain to the sponsor and project staff what you are doing, such as gathering needs, categorizing them, and establishing the requirements baseline.  You might also need to explain how that baseline is the basis for the project plans that you will develop.

Interviewing the Sponsor

In your interviews, always cover the following basic questions:  when, where, why, what, and how.  The following are some sample questions:

  • Why do you think we are doing this project?
  • What is your role in the business and the project? 
  • How will this project affect your role? 
  • What functionality and deliverable do you need?
  • Who are your stakeholders?
  • What kind of financial impact will this project have on your organization?
  • Can the existing infrastructure support your needs?
  • What outside support is required?
  • How do you define success?
  • What is your completion criteria? 

The next step in the requirements-gathering process is to categorize needs into either requirements or exclusions.

Transform Needs into Requirements and Exclusions

Examine each identified need and determine whether it should be included in your project.  To make this decision, ask these questions:

  • Is the need part of the original intent of the project?
  • Is the need a new function or feature that was not included in the original intent of the project?
  • Was the cost of delivering the need included in the original cost estimate?


As you think about the needs, remember what the sponsors told you.  In the end, the sponsor must agree with your plans, so involving the sponsor early in the requirements-gathering process will save you time and headaches later.

Each need that is not a requirement is an exclusion.  Document the exclusions so that the sponsor and other stakeholders know what you and your team will not provide in the project.

Deciding: Requirement or Exclusion

After you have gathered needs, categorize them as either requirements or exclusions.  In effect, you are deciding to:

  • Implement all the needs as requirements, because there are no new requirements that have been identified and all needs were in the original Project Definition.
  • Implement some of the needs now and wait to implement the others in a follow-on project.  For example, if a need is really for new functionality, the cost and schedule for providing that new functionality will be defined for the follow-on project.  This approach gives you a graceful way to implement all the needs in an orderly manner without jeopardizing the original project.
  • Not implement any of the needs now.  This approach might be appropriate if the needs are not technically feasible, or the customer is not willing to pay for them.

Documenting Requirements

Documented requirements must be clear and concise, because they form the basis of your project plans.  As you write requirements, determine whether they can be misinterpreted.  Writing requirements that can't be misinterpreted is a difficult task.  To help ensure that requirements are clear, include graphics, models, and other visual representations, where appropriate.
After you have written the requirements document, ask your team to review it to be sure they have the detail they need to get started.

Validate Requirements

       Executive incentives are tied to project results.

       The client makes investments in change management and training.

       Subject matter experts are dedicated full-time.

Unhealthy Signs

       No executive sponsor is visible.

       Key stakeholders miss meetings.

       People are sabotaging efforts.

       Resistance to new ideas is evident.

       No experts are available.

Business Benefits are Being Realized Key

This key is closely related to the Stakeholder key.  Clients want solutions to their business problems not just a strategy or system.  The project team and the customer must understand why the project is being undertaken, and they both need to understand how the project benefits the customer.  If stakeholders do not perceive any business benefit, they will probably lose commitment to the project.

Here are some criteria for assessing the Business Benefits are Being Realized key:

  • The business case is clearly and convincingly articulated.
  • The solution will appropriately support the desired outcomes and costs.
  • The quality of the work products is appropriate.
  • The benefits of tracking are ongoing and meaningful.

And here are the healthy and unhealthy signs to look for.

Healthy Signs

o     A compelling reason to implement is evident.

o     The difference to the business can be measured

Unhealthy Signs

o     Members of the team keep asking, 'Why are we doing this?'

o     People are sabotaging efforts.

o     Time is not important.

o     Cost is too important.

Some projects start out without a sound business case.  Such projects are doomed to failure.  Some projects have sound business cases but, somewhere into the project, they lose that focus and never regain it.  Ensure that your stakeholders stay focused on the business benefits;  otherwise they will focus on how much the project costs.

Understanding All Requirements

I cannot overstress the importance of understanding all of the customer's requirements for a
project.  A thorough understanding of all requirements is critical to project success. 

Why It Is Important to Establish a Requirements Baseline

I've also learned how important the requirements baseline is to delivering a project on time and on budget.  At the beginning of a project, everyone has to agree on what is being delivered.  Everyone has to understand that future changes must be agreed to by the sponsor, stakeholders, and you before the changes are made.

To create the requirements baseline, the stakeholders and project team need to understand the business benefits of the project.

Some Common Pitfalls of Requirements Gathering

I've seen the requirements definition process go awry in many ways.  Some problems are so subtle that they do not become apparent until the project is almost finished.  The primary source of cost and schedule overruns is problems relating to requirements.  These problems can lead a customer to reject a deliverable or a major rework of the project.  Poorly defined requirements can also lead to project failure.

Some of the common problems I've encountered or heard about include:

  • Unclear requirements.  This is the most common source of difficulty.  The more unique a project, the greater the risk of unclear or imprecise requirements.  Requirements are dynamic and ever-changing because they are defined in relation to their environment.  Unclear requirements can result from changes in budgets, stakeholders, technology, or the business environment.  They might also result from uncertainty about who will ultimately use the product or service or from the sponsor's inability to recognize what is needed.  You must guide the process and work closely with the sponsor to identify clear requirements.
  • Premature solutions.  Coming up with answers before asking all the right questions can result in a premature and incorrect solution offering.
  • Lack of clarity about who the sponsor is. You might find yourself on a project that has conflicting needs.  In this instance, your first job is to find out who the sponsor is.
  • Biases.  When analyzing requirements, avoid inadvertently altering requirements to reflect one person's biases, rather than the needs of the sponsor.

To help avoid these pitfalls, work closely with the sponsor, avoid shortcuts in the requirements-gathering process, clearly identify the sponsor, and try to avoid imposing your biases, or those of anyone else, on the sponsor's needs.

The requirements-gathering process is iterative.  It is important to redo the process and ask a lot of questions.

After you have identified the project requirements for your project or subproject, the next step is to determine how you are going to deliver those requirements.

To do this, remember to define the project deliverables, develop a WBS baseline, and describe the criteria for determining if the scope is realistic and managed.  Also remember that although the product breakdown structure (PBS), work breakdown structure (WBS), and organizational breakdown structure (OBS) are all different, they complement one another; they are different ways of viewing and decomposing the project.

What does it mean to decompose a project?

Decomposition is the subdividing of the major project deliverables into smaller, more manageable components.  You identify the top-level elements of the project and then divide the elements into manageable pieces for scheduling and tracking.

What Is Decomposition?  

Decomposition is the subdividing of the major project deliverables into smaller, more manageable components.
The purpose of decomposition is to identify the top-level elements of the project and then divide the elements into manageable pieces for scheduling and tracking.  This process is used to develop the PBS and the WBS.

The OBS shows the project organizational unit responsible for each of the deliverables and components.

Types of Breakdown Structures 

There are three types of breakdown structures.  Move your  mouse pointer over the name of each breakdown structure to

What Is the PBS? 

The PBS is a hierarchical decomposition of work products into components.  The PBS focuses on what must be produced and is required to create the WBS, which focuses on how to produce the work product.  Each level of the PBS represents an increasingly detailed view of the components.

There is a Worldwide Project Management Method (WWPMM) work product description and a template that assists you with the creation of the PBS work product.  You can find this information and descriptions and templates for all WWPMM work products at the following Web address:

Worldwide Project Management Method

What Are the Benefits of the PBS? 

The PBS helps you to: 

  • Identify all work products and to designate which work products are deliverables (some work products, such as project management plans and status, are not deliverables)
  • Identify reusable work products and components, which supports make-or-buy decisions
  • Identify logical relationships, which assists with building the sequence
  • Create the WBS
  • Clarify the information you need to formulate estimates

Creating the PBS  

Create the PBS using the following steps.

Gather the data as follows:

  • Gather all the project-related materials that define the solution, approach, deliverables, and scope.

A WWPMM work pattern (Build Project Organizational Unit Work Plans) and two WWPMM work products (the Deliverable Definition and the Work Product List) contain descriptions and templates to assist you with the PBS content.  These can be found, along with descriptions and templates for all WWPMM work products, at:

Worldwide Project Management Method

  • Review the PBSs from similar projects.


Create the PBS using the data that you gathered as follows:

  • Prepare a high-level PBS that consists of two or three levels.
  • Involve your team members in the development of the PBS because you will not be able to provide all of the information yourself.
  • Keep in mind that each element must be a noun, have definitive, verifiable acceptance criteria, and be assigned as the sole responsibility of a project organizational unit or individual, as shown in the OBS.
  • Include project support work products from project management and quality assurance (QA).
  • Add elements to manage risks.
  • Refine the structure iteratively on each level.  Try several different alternatives for each level.
  • Refine each part of the PBS to the level of manageable work products.


Review the PBS with others to obtain their agreement, and then complete the following tasks:

  • Review the PBS with the appropriate stakeholders.
  • Receive support from the personnel who are responsible for work products.

What Is the WBS?  

The WBS is a hierarchical decomposition of all the activities the project team must complete.  The WBS defines the total scope of the project and provides the basis upon which work can be scheduled. 

Each level of the decomposition increases the detailed view of the tasks to be completed to create work products.  Verbs are used to describe each activity.  The hierarchy has as many levels as required to define the work.  The number of levels usually varies from one major element to another.  The WBS focuses on how to produce the work products that are defined in the PBS, which focuses on what to produce.

This figure illustrates two ways to show the same WBS decomposition.  One is a tree diagram, and the other is an indented list or outline.

When Is the WBS Created?

The WBS is generated after the team understands the work products to be developed.  Development begins when deliverables are identified and agreed to by the sponsor.  From this point in project planning, the project scope can be described in measurable and discrete work efforts. 

The Levels of the WBS  

The WBS has as many levels as are required to define the activities to the level of detail needed to successfully plan, monitor, and manage the work effort.
An activity is an element of work at a particular level.  Each activity results in a work product that is distinct and has verifiable completion criteria.  Work products that are given to the sponsor are called deliverables (for example, a software program with the functionality requested).  Not all work products are given to the customer (for example, those that are necessary to manage and control the project, such as software that generates monthly project status reports, are not given to the customer but do require work effort to develop).  The elements of the WBS often have common work activities for similar projects.  These common elements are called work patterns.

The lowest level of the WBS is the work package.  A work package is a group of work items assigned to a single person or small group to be done over a short period of time.  An example is a software application that is being developed in-house while the hardware is being developed by an external supplier.  The WBS for the software might be decomposed into two-week activities, which results in work packages at the sixth, eighth, and tenth levels of the WBS.  Alternatively, the hardware might be decomposed to the subcontract level of 50 weeks of activity at the third level in the WBS.  The subcontractor needs to decompose the hardware work into smaller activities to enable effective planning and scheduling.

When creating the WBS, the project manager must examine each level of the structure to ensure that the project is effectively planned, executed, controlled, and closed.  Each level must be examined for dependencies among components, acceptance criteria, risks, ownership, milestone schedule, progress reporting, and relationship to the solution architecture.  As a project manager, you must consider each of these aspects.  You must also look at alternative decompositions to reduce dependencies, tie acceptance criteria more closely to the contract, avoid or reduce risks, permit measurable milestones, allow clear progress reporting, and maintain a relationship to the target solution.

The Levels of the WBS  

The following examples depict two-, three-, and four-level WBSs.  These are partial examples because only one item at each level has been expanded to the next level.  A complete WBS expands to the level needed to define and manage each item. Normally, different items are expanded to different levels.

Click each button to read the examples:

The second level is a decomposition from the first level.  The entire project test plan includes the unit test, a system test, and an acceptance test.

The third level is a decomposition of the system test second-level element.  For a complete third level, all elements from the second level must be expanded.  To execute the system test, you must write test cases, prepare the test environment, conduct the test, and analyze the results.

The fourth level is a decomposition of the third-level element, which is to write test cases.  For a complete fourth level, all elements from the third level must be expanded.  Obviously the WBS example becomes unwieldy for a normal project.  For this reason, the WBS can also be depicted as an indented list.

The WBS Dictionary  

The WBS dictionary is a repository for descriptions of work elements and other key information such as budgets, basis of estimate, and staffing.  The dictionary contains detailed background information about each work element.  It might also include acceptance and completion criteria.  Using the dictionary, team members can capture information about each activity. 
After an activity is defined, that definition remains throughout the project.  The definition is used to explain activities to employees and to clarify where work begins and ends on an activity. 

The dictionary helps determine whether the project manager has identified the skills needed to do the work. 
It should contain the following information for each element:

  • Identification of the element
  • Title of the element
  • Description of the work product or the deliverable
  • Acceptance criteria (for example, how to know when you are finished and who needs the output)
  • Staff estimates
  • Cost estimates
  • Ownership or participation (for example, who is responsible or who is involved)
  • Dependencies

What Is the OBS?
Now that you have decomposed the product (PBS) and the activities (WBS), it is time to think about how the people working on the project will be organized.  The OBS shows how the project is organized by displaying the names of staffing resources for a project.  It indicates who is responsible for the activities in the WBS.  The OBS describes the:

Relationships between the subprojects and the project organizational units

Reporting relationships between the project organizational units

Team structure of the project organizational units

Reporting relationships between the delivery and performing organizations, including the subcontractors

The OBS contains the subproject definitions, the project organizational chart, and the team structure.

The Importance of the OBS

Have you ever worked on a project that did not have an Organizational Breakdown Structure?  What happened?  More than likely, project staff did not know who else was working on the different parts of the project, and did not know who to ask when questions arose.  The OBS helps project staff understand how they fit into the overall project and how information flows between the units delivering the project.

Creating the OBS

To create the OBS, complete the following steps:

  • Decide whether each subproject is to be performed directly by the delivery organization, another IBM performing organization, the sponsor or customer, or the subcontractor.  Ensure that the selected performing organization has the skills and experience necessary to complete the subproject.
  • For each project unit, identify and assign the subprojects.
  • If one project unit has responsibility to manage other project organizational units, clearly assign this responsibility in the OBS.
  • If a sponsor or customer is responsible for completing one or more subprojects, document the sponsor's or customer's responsibilities as part of the agreement.
  • If third-party performing organizations are required, start the process of choosing a subcontractor.

Example of a PBS 

In the following example, there are four deliverables:  cooked pasta, canned sauce, dinner salad, and garlic bread.  Shown following the deliverables are the work products that are needed to create the deliverables.  For example:

  • To create the cooked pasta, you need pasta and water.
  • To make the dinner salad, you need lettuce and salad dressing.
  • To prepare the garlic bread, you need garlic and bread.

How to Get Started Creating the WBS  (continued)

The questions to ask yourself as you start to create a WBS are: 

  • What needs to be done?  Make a list.  For example, to create the garlic bread, you need to buy the bread, butter and garlic; put the garlic and butter on the bread; and bake the bread.
  • Which activities are at the lowest level?  Figure out which activities have dependencies on each other and which ones should be done first.  For example, you must buy the butter and garlic before you can mix them together.
  • Where do the activities fit in the WBS?  The last activity is on the top and all the predecessor activities are below.  The first tasks would be at the bottom of the list.  When you read this in chronological order you will be reading up from the bottom.  Thus the first activities in the example are to buy the garlic,  butter, and bread and the last activity is to bake the bread.

Creating the WBS

Follow these guidelines to create the WBS:

Gather all the data as follows:

  • Gather all project-related materials that define the solution, approach, and scope, including the PBS.
  • Review WBSs that were created for similar projects.

Create the WBS by using the gathered data and following these guidelines:

  • Prepare the WBS showing high-level activities for the major subprojects and major work products.  One of the most common ways to do this is to write each of the activities on small sheets of note paper and attach the sheet of paper to the wall.  The advantage of doing this is that you can easily move the notes as needed.
  • Refine the structure using iterative decomposition.
  • Decompose to the level of manageable and trackable work packages.
  • Include project support work products such as project management status reports and QA reports.
  • Add activities for risk reduction and risk management.
  • Ensure that the WBS contains all the work for the entire project.  Include all the activities that will add costs to the project.
  • Involve your team members in the development of the WBS because you will not be able to provide all of the information yourself.
  • Refine the structure iteratively on each level.  Try several alternatives for each level.
  • Ensure that the work packages that are the lowest level of the WBS are assigned as the responsibility of one project organizational unit or individual.

Review the WBS with others to get their agreement as follows:

  • Review the WBS with appropriate stakeholders.
  • Receive support from the personnel who are responsible for work packages.

Questions to Consider  

Ask the following questions as you are developing or reviewing the WBS:

  •   As changes occur, how will the WBS be revised?
  •   How will the WBS be stored and distributed?
  •   What numbering system will be used?
  •   How will any software used affect the WBS?
  •   How will overhead be handled?
  •   How will risk and risk management be handled?
  •   How will subcontracting be handled?
  •   Are project management elements complete?
  •   Can you assign responsibility to an organization or individual?
  •   Do you have support from the personnel who are responsible?
  •   Can elements be verified?
  •   Can acceptance criteria be defined?
  •   Can performance be monitored?
  •   Can you capture cost information?

Example of an OBS

The OBS shows how the project is organized by displaying the names of staffing resources for a project.  It indicates who is responsible for the activities in the WBS. 

The OBS contains the subproject definitions, the project organizational chart, and the team structure.

The diagram shows an example of an OBS structure.

Scope is Realistic and Managed Key

It is unusual for a project to finish without at least one change request to the scope from either the project sponsor or the project team.  Therefore, the team must expect scope changes and manage them effectively.

However, if there are many change requests right after the start of the project, the scope has not been not well defined. Make sure that the team spends enough time in the planning phase to have a detailed understanding of the project scope.

Here are some criteria for assessing the Scope Is Realistic and Managed key.

  • Scope management is implemented.
  • Proposed and agreed changes to terms are appropriately reflected in costs, schedules, and responsibilities.
  • Organization, system, and geographic boundaries are appropriately defined.
  • Scope exclusions and assumptions are clear.

As the project manager, look for these signs.

Healthy Signs

  • Healthy negotiation is evident.
  • Lengthy issues log and issues are being resolved.
  • Written agreements are in place.

Unhealthy Signs

  • Issue is a bad word.
  • Nothing is in writing.

Scope is Realistic and Managed Key  (continued)

As you saw in the previous modules, the stakeholder and business benefits keys are closely related. 

To which other key do you think the Scope key is related?

Benefits of the PBS, WBS, and OBS 

Think about projects you have worked on that did a good job creating the PBS, WBS and OBS. 
How did these structures help the project manager execute and control the project?

I believe that creating the WBS and the PBS are the most important things I do as a project
manager.  When I create the PBS, I identify all the deliverables and work products (what) first.
After I understand the work products, I can start to create the WBS.

The WBS helps me to identify all the (how) activities, including dependencies and hidden issues. 
As I go through the process, I define the completion criteria for each activity.  When I am done, I have a great road map that I can use to help me finish planning the project.  I find that I use the WBS through the entire project as a reference point to ensure that I haven't forgotten anything.

The OBS is critical for helping me to plan my resources.  By creating an OBS, I have a picture of the entire project organization, which I find very helpful.

Example of Uses of WBS, PBS, and OBS 

I really like the following chart, which depicts the uses of the WBS, PBS, and OBS.

At the upper left of this chart, you can see the requirements for the project as inputs to the WBS, OBS, and PBS.  The requirements are the Supplier Management Plan, the Integration Strategy, and the system solution. 

The project management outputs from the WBS, PBS, and OBS are the Status Reporting, the Cost Estimation Development, and the Project Schedule at the bottom of the chart. At the upper right is the two-way Communications Management that occurs during the entire project.

Risk management is proactive decision making.  The Risk Management process provides for an iterative means to plan, track, and react to risk.  As a part of this process, you create a risk management plan to identify risks you might encounter on your project.  When creating a risk management plan:

  1. Identify the risks.  
    - Ask what risks could be a potential loss or lead to negative consequences to the project.
  2. Analyze the risks.
    - Look at each risk and determine the probability and impact of each one.
  3. Create a risk response plan.
    - Decide, what, if anything, should be done with each risk.
  4. Track and control the risks.
    - Continually collect and analyze data about the risks to determine what actions, if any, must be taken.
  5. React to the risks.
    - Implement the identified action plan in response to an actual risk.

The Risk mitigation is what you do to ensure that the risk event does not happen.  Risk response is what you do when it does happen.  So the risk management plan is the whole response process.

What Is Risk Management? 

Risk management provides an environment for proactive decision making.  As a framework for the iterative process of planning, tracking, and reacting to risk, the risk management process includes:

  • Continuously assessing risks
  • Determining which risks are important enough to address
  • Defining and implementing strategies and plans to address risks, if they occur

To address changing conditions and project priorities, you must analyze risks throughout the life of the project, beginning in the project selection phase.  As new risks are identified, you must develop strategies and plans to address them.

Risk Management Steps 

The chart on the following page shows the steps that you follow when performing risk management.  Remember, risk management is an iterative process.  You must go through this entire process regularly to ensure that any new risks are identified and addressed. 

Note: Step 4 (risk tracking and control) and step 5 (risk reaction) are covered in Module 10, 'Project Control and Execution.'

Step 1:  Risk Identification

In Step 1, search for and identify the risks.  Determine risks that could be a potential loss or lead to negative consequences for the project.  Also, look for risks that represent opportunities that might be exploited. 
Step 2:  Risk Analysis
In this step, define the probability and impact of each risk to determine the exposure.  You can then prioritize the risks to determine how the project team is going to address each one. 

Step 3:  Risk Response Planning

In this step, you decide what, if anything, should be done with the risk.  To help you decide, consider the responses to the following questions:  Who owns the risk?  What should be the response to the risk?  What actions and plans should be put in place to address the risk?

Step 4:  Risk Tracking and Control

In Step 4,  you continually collect and analyze data about the identified risks to determine whether action must be taken. 

Step 5:  Risk Reaction

In this final step, implement the identified action plan in response to actual risk occurrence.  You also close the risk, if appropriate.

Your Role in the Risk Management Process 

You, as project manager, are responsible for managing risk.  Your role includes the following:

  • Facilitating the risk management process
  • Incorporating risk management into project management planning
  • Maintaining the visibility of risk management throughout the project plan
  • Identifying and analyzing risks
  • Monitoring risk on a regular basis
  • Responding to risks
  • Reviewing and assessing risks after each event
  • Calling for independent reviews, when needed

Considering the Objectives of Stakeholders in Risk Management 

Because perceptions of risk might be affected by a stakeholder's objectives, try to involve all stakeholders in the risk management process early in the project life cycle. 

Involving as many stakeholders as possible in the risk management process helps to ensure that the greatest number of potential risk factors and risk events are found and that resulting strategies more closely meet stakeholder objectives. 

Identifying Risks 

When you identify risks, your goal is to list all of the significant potential risk events that could affect the outcome of the project. 

Components of risk

  • All project risks share some common components.
  • A risk is something that can negatively affect the project. 
  • The probability that the risk will occur is greater than 0 and less than 1.  A probability of 1 means it will happen.  If you know it will happen, it is not a risk but a certainty that you must contend with.   
  • A risk is tied to a future event, typically a project milestone or project phase. 

For managing risk, there is one more component to consider:

  • A risk must have conditions around it that can be managed.
  • A risk event is when a risk occurs, or might occur.

A risk factor is a situational factor that has been identified as leading to a risk.  Risk factors should be identified early and projects should be reviewed regularly to ensure that no significant risk events are overlooked.  Repeat the risk identification process on a regular basis, as part of your key checkpoints or key milestones.  When developing the list of risks, be thorough, but realistic.

To begin, first look for risk factors such as poor estimates, requirement changes, or design errors.  You can then determine possible events from these factors.

When you identify the timing when a risk event can occur consider whether it is a one-time risk or if the risk can occur more than once.  Most risks identified early in a project are one-time risks, but consider a risk of not being able to complete a step in the project because a client does not provide you with data that they are obligated to provide monthly.  Every month there is a chance of missing a delivery to your project so that the frequency of this risk is monthly.

Using Inputs to Identify Risk Events 

A variety of inputs should be used to help identify risk factors and risk events.  For example, when using the WBS, look at each work product and consider what can go wrong.  In this instance, the WBS is the input.  Examples of other inputs include:

  •   Contractual requirements or statements of work (SOWs)
  •   Supplier contracts or customer agreements
  •   Field and marketing information
  •   Project plan assumptions
  •   Earned value (EV) data
  •   Offerings portfolio
  •   Lessons learned files from previous projects
  •   Company objectives and plans
  •   Other project-related plans
  •   Project schedule
  •   Review reports
  •   Project plan dependencies
  •   Resource sourcing
  •   Sponsor or other stakeholder feedback

As you progress on the project, some other areas to look at are:

  •   Change requests
  •   Issue documents
  •   Event log
  •   Project status reports

Questions That Help Identify Risks 

Following is a list of questions related to key project areas that might help you to identify risks:  

  •   History.  Has the risk event occurred before?
  •   Familiarity with the operation.  Has the work been done before?
  •   Skills.  Does the staff have the ability to do the work?
  •   Resources.  Are there adequate materials to complete the work?
  •   Time.  Does adequate time exist to complete the work?
  •   Quality.  Is the team confident about the quality of work required?
  •   Cost.  Is funding sufficient to complete the work?  

Techniques for Identifying Risks 

Some of the many techniques and tools to identify risks using input from other people include:

  • Expert interviews
  • Idea-generation techniques, such as brainstorming, affinity diagram, and nominal group technique
  • Lessons learned from other project managers and the 'lessons learned' files from other projects
  • Knowledge Management Network (PMKN).  To access the Intellectual Capital Management (ICM) database through the Knowledge Portal:
    1.   Go to the Knowledge Portal.
    2.   Click the category Intellectual Capital and Assets
    3.   Click the subcategory Project Management.

The Purpose of Risk Analysis 

The purpose of risk analysis is to gather data about risk events.  You can then use this data to decide which risk events to mitigate. 
Risk analysis is a continual process conducted throughout the life of the project.  As the project progresses, the analysis for a risk event might change due to changes in the environment. 
Risk analysis includes:

  • Evaluating.  In this phase of the process, you estimate the probability that a risk event will occur and the resulting impact.  You then use these estimates to determine the severity of the risk to the project.  
  • Prioritizing.  After determining risk exposure, you decide the order in which the risks require attention.

Defining Probability and Impact 

To evaluate a risk event, you examine the probability of the risk occurring and the impact it will cause if it does occur.  You can use either a qualitative or quantitative approach to estimating.  

Qualitative Analysis  

Estimating Probability Using a Qualitative Analysis
Using a qualitative analysis to estimate probability, you assign a low, medium, or high category to the probability that the event will occur as follows:

  •   Low.  The event has little chance of occurring.
  •   Medium.  The event has some chance of occurring.
  •   High.  The event is likely to occur.  

Because low, medium, and high are relative terms, ensure that everyone on your team involved in the process of estimating probability uses these terms similarly. 

To illustrate, consider an example of a person skydiving.  When a person is skydiving, a parachute malfunction is a risk with a low probability.

Defining the Impact Using a Qualitative Analysis

After you define the probability for each risk event, you define the impact.  To do so, ask yourself,  what the impact to the project will be if this risk occurs.  In a qualitative analysis, impact can be categorized as low, medium, or high, as follows:  

  • Low.  The event has little potential to disrupt the schedule, increase the cost, or degrade performance. 
  • Medium.  The event has some potential to disrupt the schedule, increase the cost, or degrade performance. 

The following graphic shows the relationship between impact and probability.  The vertical axis represents impact, and the horizontal axis represents probability.  Each 'X' represents a specific risk, by placing the 'X' in the diagram you can see their impact, probability and global qualitative value.

Estimating Probability Using a Quantitative Analysis

Another approach to estimating probability and impact is a quantitative analysis.  A quantitative method uses a numeric scale, usually from 0 to 1, to measure the probability of an event occurring, where 0 means an event would not occur and 1 means it will occur.  The impact is measured in the same way, where 0 means no impact and 1 means the maximum impact possible.
Using the parachute example, the risk of an FAA licensed dual-parachute (a back-up chute is required) failure as determined from US FAA data collected in 2005 is .000016 (35 incidents from over 2,000,000 jumps), but since death is the result, the impact of a dual-parachutes failure is 1.0.

Assessing Risk Exposure

Risk exposure is a combination of the probability and the impact of the risk.  The project manager is responsible for determining the risk exposure, using probability and impact estimates and the following matrix tool.  Risk exposure has more than one dimension, such as cost, schedule, quality, and customer satisfaction, that should be considered.

In this matrix, the risk decreases as you move from right to left, or top to bottom.  To illustrate, in the parachute example, low probability and high impact results in a medium risk exposure.

Prioritizing Risks  

Prioritizing risks involves deciding whether risk events are worthy of attention.  Placing one risk next to another risk enables you to achieve clarity and understanding beyond risk analysis.  For example, you might have to decide between losing $1 million on a $40 million project or coming in a month late on a critical project with a $40 million client.  Although neither risk is good, it might not be possible to respond to both.
Prioritizing risks also highlights when you are using too fine a level of detail in your risk analysis.  The process of prioritizing risks also allows you to develop a sense of your project's and organization's level of risk tolerance.  Prioritization is effective only when you use defined selection criteria.

To prioritize risks, confer with team members and use the following practical approach:

  • Rank evaluated risks from highest to lowest
  • Use quantitative rankings when possible; otherwise, use qualitative rankings
  • Separately rank risks with similar ratings
  • Prioritize risks as a team

When prioritizing risks, working as a team is an important, although challenging, task.  Team members might often have different opinions about the impact or probability of a risk because the risk might not have an amount of money  associated with it.  For many risks, the impact and probability can be expressed only in relative terms. 

Avoid planning response strategies during this step.

What Is Risk Response Planning? 

Risk response planning is deciding what, if anything, should be done with a risk.  It is the assignment of actions to contain, reduce, or eliminate risks.  Risk response includes: 

  • Assigning owners to individual risks
  • Selecting options for addressing individual risks or groups of related risks
  • Defining mitigation, contingency, and reserve plans
  • Reviewing a risk management plan

According to WWPMM, these are the strategies that you can use to respond to risks are:

  • Transfer risk.  Using a transfer strategy, you transfer all or a portion of a risk to another party.
  • Insurance.  When you have insurance coverage, you can use it to cover the cost of a risk event.
  • Contingency.  In this strategy, you set aside funds to be used when the risk occurs or when later containment is deemed to be appropriate.
  • Mitigate.  When mitigating risk, you take specific action to minimize or avoid the occurrence and effect of a risk. 

The PMBOK has a similar definition of risk response strategies, but calls them Avoid, Transfer, Mitigate and Accept.  Accept means you are willing to accept the consequences of the risk.

Risk Triggers 

An important part of defining the risk containment plans is risk triggers.  Risk triggers are indicators that specify when an action must be taken.  If the trigger event happens, then initiate the action plan.

Examples of triggers and action plans include:

  • If the power is out for more than 30 minutes, start using the generator.
  • If the product delivery from the OEM vendor is n days late, then contact the other vendors to move their shipments back.

Effective triggers:

  • Provide an early warning, which gives the team enough time to take appropriate action or focus extra attention on the risk
  • Do not initiate actions unnecessarily
  • Are easy to calculate and report

Risk Response Options 

Starting with the prioritized list of risk events, you must select the best risk response option.  Following is a list of the options you might use for the identified risks:    

Transfer risk.  Determine if the accountability, responsibility, and authority for the risk belongs to the project or to another organization.  Transfer implies ultimate accountability, responsibility, and the authority to expend required resources to mitigate the risk that exists outside of the delivery organization.  Transfer requires the acceptance of risk by the other party.  In risk transfers the risk is not removed from the project, it should still be tracked as a project risk.

Options for transfer include transferring the risk to a sponsor or supplier through terms in an agreement, to an IBM organization in a business unit not connected with the project through formal written documentation, or to an IBM organization in the same business unit as the delivery team through informal written documentation.

For risks not transferred, determine who will own them within the project.

Insurance. When you have coverage, use it to cover the cost of the risk event.

Contingency.  In this type of response, you make the decision to use monies set aside for risk management reserve or risk contingency reserve.  Using management reserves is an alternative to increasing the price of the project to the sponsoring organization.  Generally, establishing and using management reserves is controlled by the delivery organization policy. 

Contingency is a reserve held outside of the project cost baseline for future situations affecting project cost or schedule.  It is not held for specific risks but at an aggregate level.  The risk contingency reserve is held inside of the project cost baseline and used to address future situations affecting project cost or schedule.

.  In risk mitigation, you take steps to lessen risk by lowering the probability of a risk occurrence or by reducing its effect on the project.  In risk contingency planning, you develop a plan for defining actions to be taken if the risk occurs.

Factors to Consider When Planning Risk Response 

Many factors influence the selection of a risk mitigation strategy, including:

  •   Project phase and application
  •   Size
  •   Priority
  •   Complexity
  •   Expense
  •   Time available
  •   Required level of detail
  •   Ease of use
  •   Resource availability
  •   Contract type
  •   Terms and conditions
  •   The project manager's authority, accountability, and ability
  •   Commitment from the project manager and upper management
  •   Customer satisfaction


Impact of Different Risk Options

Some project elements can be affected by different risk options.  For example:

  • The transfer of a risk affects the project scope or the contract.  For example, a high-risk deliverable might be transferred to a subcontractor.  The scope might then change because the requirement for research and design might be decreased by the transfer, or the scope of the deliverable might not change but the project length might.  If the subcontractor specializes in the particular deliverable and its support, this transfer of risk might be acceptable to the sponsor as a response for the high technical risk.
  • To use an insurance policy, the policy must be accounted for in the budget, as well as the person who will find, arrange, administer, or pay for the insurance.
  • Risk might not change any of the project elements.  In most cases, an accepted risk indicates that no more money or time will be allocated to the risk.  The consequences are accepted.  What if the risk occurs?  Does anything change?

What Is a Risk Management Plan?

In the risk management plan, you document the risks you have identified, the response plans for each of those risks, and the actions required.  This document changes during the project as risks change, as you execute the response plans, and as conditions change.

As the project manager, you should look at this document regularly to determine whether any new risks should be added or old risks removed.  You should also determine whether any of the response plans require change.

Your risk management plan is one of the key documents that a project reviewer checks for content and for evidence of updated activity.

Completing a Risk Management Plan

Various pieces of information exist for each risk event.  In addition, a variety of formats are used to create the risk management plan.  The following page shows a completed risk management plan in table form.  To fill out this simple example, you would list the risks in the following columns:

You should use the more comprehensive plan format that WPMM provides.  This plan is available at the WWPMM Web site.

Rank. Enter the priority rating for the risks in this column.  The most severe risk (that is, the risk that poses the greatest danger to the project) is ranked number 1.

RIN. To help track the risks, assign each risk a risk identification number (RIN).  As the project proceeds and new risks are identified, the priority ratings change but the RIN number remains the same.

Source of Risk. Enter when and where the risk was identified.

Risk Event. Provide a description of the risk in this column.

Response Strategies. Use this column to document the response strategies that you have defined to reduce the severity of the risk to the project.  After completing the column, consider whether these strategies could be used together or if they are mutually exclusive.

Sample Risk Management Plan Rank RIN Source of Risk Risk Event Response Strategies Action Required 1 2 Architect Review Insufficient time to perform product verification test

  • Have available personnel work overtime
  • Plan activities
  • Negotiate with client or project sponsor for more time
  • PM to contact team and inform them to start working overtime
  • PM to plan activities
  • PM to negotiate with client or project sponsor for more time

2 4 WBS review by lead tester No test suites available for required open systems standards

  • Hire testing firm to validate open systems standards
  • PM to hire testing firm to validate open systems standards

3 1 WBS Incomplete UCD analysis results in user interface problems

  • Use Joint Application Design (JAD) to determine initial requirements
  • Use task analysis to better understand potential client or project sponsor's environment
  • Build prototype
  • PM to use JAD to determine initial requirements
  • PM to use task analysis to better understand potential client or project sponsor's environment
  • PM to add a step to the project plan for build protoype

4 5 Contractual requirements/product plan assumptions Use of new IPD methodology will delay schedule

  • Cancel annual leave, send staff to training
  • Hire outside expert to act as coach
  • Use on-the-job training approach-give everyone the material and tell them they must know it by a certain date
  • PM to cancel annual leave and make arrangements to send staff to training
  • PM to hire outside expert to act as a coach
  • PM to gather the material and give it to each member of the staff and tell them they must know this material by a date

5 3 Company objectives and plans Elements not fully integrated into OS public build

  • Create OS development SWAT team to complete all necessary items quickly
  • Negotiate with senior management for more time
  • PM to create OS swat team
  • PM to negotiate with senior management for more time

After Completing the Risk Management Plan

After the risk management plan is prepared, complete the following tasks:

  • Review the plan with the project team and obtain their buy-in.
  • Conduct an independent review to identify items you might have missed, to validate selected strategies, and to suggest possible alternatives for selected strategies.
  • Update all related documentation.
  • Ensure that the risk management plan is visible in the initial project review, in the concept decision checkpoint (DCP), and to the sponsor and management.

Risks are Being Mitigated Key

This key is often misunderstood.  It is not about whether a project has risks;  every project has risks.  Rather, this key is about determining whether a risk management plan exists, whether the plan has been communicated to team members, and whether it is being actively used.  Here are some criteria for assessing the Risks are Being Mitigated key.

  • The risk management plan is fully implemented, maintained, and supported.
  • Risks are appropriately sought in meetings and discussions are dutifully identified.
  • Risk tracking and reporting are timely.
  • Mitigations are effective.

So the Risk key is about whether the risk management is working properly.  While other keys could be red, this key could still be green because risk management is working as it should be working.  On the other hand all other keys could be green and this key could be red if this is the only key needing corrective action.

Here are the signs to look for:

Healthy Signs

      The risk plan is documented.

      Test-it-first tactics are used.

Unhealthy Signs

      The sponsor or team members ask, 'What risks?'

      All-or-nothing tactics are used.

On some projects and with some companies, the idea is to go the quickest way, which is almost always the riskiest way.  Do not take a risk lightly, and be prepared to mitigate your risks.

It is recommended to proactively be looking for risks in the areas of the other 6 keys using their Risk Management Process to support this.

How does the risk key impact the other keys?

Risk management is about being proactive and dealing with issues before they become problems.  Without risk management, all of the other keys will be affected.  When creating your risk management plan, it is important to identify and analyze risks that may impact all of the keys.  Use the Seven Keys as a checklist when creating and updating your risk management plan.

Why Is Risk Management Important?  

I believe there are risks associated with every project.  Using risk management helps me to
prevent problems from occurring or to reduce their impact on my project when they do occur. 
Risk management helps to prevent surprises and the need for crisis management.  

The chart on the page represents
the triple constraints for projects. 

If one element changes due to a risk event, the other two elements are affected.  Risk management helps me to reduce the impact of those risk events on each of the three constraints, helping to make my projects more successful.  
The risk management plan enables me to define what needs to be done to reduce the risk of the project and to track each of those actions.  Because risk management is an iterative process, it is important to look at the risk management plan at each of the major milestones or checkpoints.  If you never look at the risk management plan after you initially create it, the plan will not help you.

Estimating a project involves predicting the amount and cost of resources required to execute the project.  Using an estimate enables you to develop an idea of the final, required budget.

When estimating, follow these guidelines:

  1. Establish objectives.
    Ask why the estimate is being prepared.  What is the required accuracy? Who is the intended audience? When is the estimate needed?
  2. Determine details.
    Gather the information needed to prepare the estimate and understand how the sponsorís environment might have an impact on the estimate.
  3. Select the appropriate tool.
  4. Develop a strategy.
    Identify the estimators, develop a detailed plan for gathering estimates, determine the type of estimating validation to be used, and review the history of similar projects.
  5. Prepare the estimate.
  6. Include contingencies associated with risk response planning.
  7. Validate and finalize.

Ask if this is an independent estimate or if it will be developed with detailed scrutiny of every aspect of planning and estimating work.

What Is an Estimate?

WWPMM defines an estimate as an assessment of the likely quantitative result based on experience or historical data from previous projects, if any.

You will usually estimate the number of labor hours, labor costs, and other costs (material, travel, and so on.) for the project.  The following terms are a key part of estimating and are used throughout this module:

  • Effort is the number of labor units required to complete a task.  It is usually measured in staff hours, or person-hours.  When you think of effort, think of how much labor has to be used on the project.  This is normally the first thing that you will estimate on a project.
  • Duration is the number of work periods, excluding holidays or other nonworking periods, required to complete an activity or other project element.  When you think of duration, think of how much time elapses.  Later you will learn how to convert effort into duration.
  • Levels of effort (LOE) activities support projects but are not specifically put into the schedule.  For example, you might determine that you will need a half-time administrative person to support the project.  You will not list every activity this person will do in the schedule, but you know you need this personís time throughout the project.

An estimate should ideally include some indication of accuracy.  Early in the project planning, you wonít know all the details about the project, and so your estimates will have a wide accuracy range around them, perhaps as much as 50% under to 100% over.  But as you plan the project in detail, you should be able to produce estimates with a narrower range of accuracy, say 5% under to 10% over.

What Is an Estimate?  (continued)

To summarize, an estimate is:

  • An assessment of the likely quantitative result
  • Usually applied to project cost factors and the schedule
  • Used with an indication of accuracy (for example,  + n%)
  • Usually used with a modifier (for example, preliminary, conceptual, feasibility, or final)
  • Completed at a level that is appropriate for the decisions being made with the data (for example, close-in estimates are more detailed than estimates for periods three to six months in the future)


However, an estimate is not:

  • An accounting or marketing strategy
  • A pricing approach, because the price might or might not accurately reflect the estimate
  • An investment approach, because it is not worth taking a risk today to get business later
  • A way to ensure sponsor satisfaction, such as arbitrarily reducing your estimate to meet some implied number (You must present reality)
  • Software or tools
  • Finding the fastest way.  (The schedule should not unduly influence the estimate be realistic and honest.)

Items to Include in an Estimate 

An estimate should include all of the following items:

  • The scope of the work that is included in the estimate
  • The assumptions that were used, such as whether the tasks should be done contiguously  or whether they are interruptible at an additional cost
  • Resources, such as staff, facilities, and material.  Consider the duration.  How quickly can the task be done with the skills available?  What skill level is required to do the job?  Project management should be included.
  • Expenses, both direct and indirect.  Direct expenses are labor, material, equipment, services, and fees.  Indirect expenses are overhead and administrative costs.  
  • Risk and the cost of managing it to acceptable levels.
  • Documentation, which is critically important.  If an estimate is not documented, it exists only in the head of one person.  The written estimate must contain the assumptions made when the estimate was developed.

An estimate must include all of the items in the previous list.  If you are asked to lower your estimate because the price is too high, what are your options?  To lower the price, you can reduce the scope, reduce risk and associated contingency, or possibly reduce resource at the expense of schedule.  Or, management can decide to lower the profit margin.
An estimate is just that--an estimate.  The only perfect estimate is the one done after the work is completed.
The degree of accuracy of an estimate depends on the phase of the development cycle that you are in.  In the concept phase, the estimate has a lower degree of accuracy than in the planning phase.

Reasons for Estimating  

There are many  reasons for estimating, including:

  • To determine and evaluate the estimated costs of a project before authorizing implementation
  • To provide a basis for tracking and managing expenditures
  • To establish a managerial baseline against which to measure actual expenditures during the execution of the project 
  • To provide a tool for evaluating routine project decisions
  • To provide factual information to support investment analysis
  • To establish resources required and the resulting schedule
  • To provide a basis for tracking progress

Many cost and schedule overruns can be traced back to a poorly developed estimate.  Even when the overrun is the result of poor execution, a good estimate should have included allowances for this.  For example suppose you estimate the project at a low cost by using fewer resources and shorter durations than required, and then the project is authorized and you are the project manager.  You find yourself committed to the project with insufficient resources and insufficient time.  The probability of completing a successful project is very low.  However, if you had done the estimate had been done correctly, it would have included sufficient resources and an appropriate schedule.

Characteristics of an Estimate 

The characteristics of a good estimate are the approximate judgments of  the effort, cost, and time to perform a task or a project.  Specifically, an estimate:

  • Is not a budget.  Cost budgeting allocates the cost estimates to individual project components so that they can be measured and managed.  Cost estimating determines the approximate costs of resources needed to complete the project activities.  You must have your resources planned and costs assessed before you can build a budget.
  • Is not a price but a cost factor.  An estimate contains all the elements related to the cost of the project. It is not just effort in hours or pricing.  You must estimate all cost items and factors such as staff, materials, facilities, and duration of tasks.  Cost is internal; pricing is what the sponsor is charged.
  • Must be documented.  The documentation must contain the assumptions made while developing the estimate.
  • Is affected by the duration of the project in terms of how quickly and in what sequence tasks are to be done, and whether they are contiguous or interruptible.  Some tasks can be interrupted and have breaks as needed.  Ask whether a task is dependent on a fixed completion time, regardless of the number of resources applied, or whether it is effort-based so that with additional effort, it can be completed much faster.  Make sure you know what information is needed to determine both the effort and the duration.

When Should an Estimate be Completed? 

As noted previously, there are different points in a project when an estimate should be prepared, reviewed, or revised.  These include:

  • When building the project organizational work plans for the project  (at this point you create the estimate)
  • When finalizing the project plan with updated work plans  (at this point you update the estimate)
  • When you take over a project
  • When you move to the next phase of the project
  • When evaluating change requests
  • When there are authorized changes in resources, materials, and services

You must develop the WBS before preparing an estimate, even if it is only the preliminary version. 
If you take over a project, you should prepare a new estimate or validate an existing estimate.  Review staffing and skill levels stipulated in the project proposal and assumptions.  Questions you should ask include:  Are the skill levels correct?  Are the hours assigned for tasks realistic?  Do the hours include time for holidays, vacation, and any other downtime?
The estimate should also be reviewed or reworked if an assumption becomes invalid.  Always document your assumptions as part of the estimate.  This helps explain an incomplete set of data and also helps make your estimate more credible and complete.

Steps in the Estimating Process 

The steps in the estimating process are the following:

Click each step to read a description of it.

Estimating Considerations 

When you prepare estimates, be sure you know the language used in estimating (for example, if you are talking about elapsed time, ensure that the sponsor is not talking about work time).  This can make a major difference in the resulting costs.  Estimates vary, depending on whether the task is based on effort or duration.
Most tasks that have work to be done as a criterion for completion are considered effort-based. 
The task has a total amount of effort that must be completed in order to finish the task.  This might also be referred to as staff effort and is generally expressed in person hours.  As a rule, the more resources assigned to the task, the shorter its duration. 
Some tasks are duration-based.  The duration is constant regardless of how many resources are assigned to the task.  (For example, the duration required for a slab of concrete to dry is the same regardless of the number of people watching it happen).
Another key difference is elapsed time as opposed to working time.  Elapsed time is the total number of days over which the task occurs.  This is also called calendar time, and is usually expressed in calendar days, weeks, or months.  Working time is the actual amount of time available for work.  Working time takes into account the working hours or time available for project team members.  It does not include time away from the job such as vacation or holidays.  Working time is usually measured in working hours divided by days or weeks.
Availability is the time a staff person is available and willing to work.  This is usually measured in work hours per day or working days.
Productivity is a relative measure of work in a time unit.  Different skill levels have different productivity rates.  You must determine which productivity should be used for the estimate.  The safest approach is to use an average productivity of 80%.
Keep in mind that the time it takes to complete a task depends on both availability and productivity.

Estimating Terms 

The following terms are used in estimating and productivity measurement.

Click each button to read the definition of that term.


This is the numer of labour units requiered to komplete a task. I tis usually measured in stakk hours or person-hours. When the numer of stuff and thein working time or availability is taken into accounut, an average produktivity should be assumed.

Level of feffort (LOE)

This describes the activities that are necessary to support a project that cannot be Schedule.LOE activities are usually measured in start hours dor the duration of the aktivity.


This is the numer of work periods, excluding holidays or other nonworking periods, requiered to komplete an aktivity or other project element. Duration is usually expresed in work days or work weeks. There are 2 tyoes of duration: contiguous (work time that is not interrupted) and interruptible (work time that might be interrupted). Duration is determined by first establishing the estimated effort requiered for a task, then diving by a utilisation factor.

Estimating Terms  (continued)

It is very important that you, as the project manager, estimate your time and share with your team the LOE estimates you have made concerning their work.  This work should consist of items such as preparing procedures, meeting attendance, preparing status, obtaining equipment, and so on.  Most project managers add 10% to the total effort for administrative items that team members must accomplish in addition to their WBS tasks.  If you show the team your estimates for LOE and assure them that time has been added to the estimate for these items, you are in a better position to defend the estimate to management and to explain why 10% is a required amount of time in addition to the WBS items.  You can also request help from team members and assure them that they have time to do this task because 10% LOE was built into the schedule.

The difference between effort and duration is that effort relates to the number of labor units required to complete a project activity, whereas duration relates to the number of work periods required to complete it.  When you are preparing a schedule, specific resource availability and productivity might affect actual duration.

If the work you are estimating is repeatable and historical data is available to support the productivity of the various groups you are using on your project, then you can use the historical data to project reliable and accurate productivity factors for your current project.

What Is Utilization?  

Utilization is the amount of time a full-time equivalent (FTE) can be used on a project.  An FTE is not necessarily a specific  individual but can be the combining of two or more individuals whose efforts equal one work day (for example, eight hours) or a portion of a work day.  In reality, personnel are not available full time, eight hours per day, 40 hours per week, 52 weeks per year.
Utilization rates are affected by the time required for education, vacation, holidays, administration, personal time off, travel, and sick leave.  Utilization is usually expressed as hours per day, but can be expressed as a percentage of duration: for example, 50% of the time during a two-week task.
Availability indicates whether the resource can be used during a particular period on your project.  Remember, good people are usually in high demand.  When creating an estimate, you need to determine the impact that vacation time has on a task to which key personnel are assigned.


What Are Utilization Factors? 

Utilization factor describes the amount of time a full-time equivalent (FTE) can be used for the length of the project.  An FTE can be a specific person or a combination of different people's hours to equal a work day.  You should rely on utilization factors to arrive at high-level planning estimates.  Estimates should constantly be refined based on assumption validations, changes to requirements, and use of actuals.
The following is an example of how the utilization factor is calculated and the effect it has on your project.

  • Duration is determined by estimated effort divided by a utilization factor of 80%.
  • In the U.S., eight hours per day is standard for determining utilization rate.
  • The working hours available for a year = 2080 (52 weeks x 5 days x 8 hours).
  • Education = 80 hours.
  • Vacation and holidays = 160 hours.
  • Administration = 80 hours.
  • Personal time off = 90 hours.
  • Other (travel, sickness) = 70 hours.
  • Total nonproject hours = 480 hours.
  • Total project hours (2080 minus 480) = 1600 hours.
  • 1600 divided by 2080 = 77% utilization.
  • 1600 divided by 12 = 134 hours per month.

Therefore, for this example, the effective utilization factor is 77%, or 134 hours per month.

Example of Utilization Guidelines 

The following table shows the approximate percentage of time that an FTE is available, based on project length and hours per month.  Generally, the shorter the project, the higher the utilization level.

Project Length


(Approx. Percentage)

3-6 months



6-12 months



>12 months



Example of a Duration Formula  

If you have a task that is estimated to take 120 hours and you are paying $10 per hour, you need to budget $1200.  However, the person is available only 75% of the time.  Over a 6- to 12-month project, the project manager must allow for vacation, holidays, sickness, training, and so on.  Assuming an average productivity of 80%, the duration is calculated as follows:

  Duration =  Effort/Productivity
    =  120/.80  =  150  = 200 hours
            .75          .75
    =  200 hours
        8 hours/day
    =  25 days (versus the original 15 days (120/8))


* Note: The formula to calculate the duration is the following: Duration equals effort divided by the average productivity and then divided by the availability of the person.

Methods of Estimating 

Estimates are developed with a number of methods or a combination of methods as follows:

     Top-down.  A top-down estimate (defined in detail later in this section) is used in the initial stages of a project.  A top-down estimate compares historical data with experience.  This is sometimes called a guesstimate.

     Bottom-up.  A bottom-up cost estimate (defined in detail later in this section) involves receiving estimates from all estimators and then summarizing them into a cost estimate for the project.  This method could involve inflated pricing as estimators add contingency to their estimate.  Ask the estimators what contingency they used to prepare the estimate.  If any estimator used utilization or availability factors, then you do not apply these techniques again.

     Parametric.  This measures the effort of a task.  Parametric is defined in detail later in this section.

     Analogy or comparison.  This describes the comparison of similar projects.

     Expert judgment.  This is the information provided by a group or a person with specialized knowledge and training.

It is important to know the type of estimate and its level of precision so that you are not overconfident or underconfident when you present your estimate to management.  As stated earlier, estimating for a project is not done just once.  It is done throughout the life of the project.  You must determine the level of accuracy needed for your estimate.  A plus-or-minus precision indicator is required to best ensure that the recipient knows the level of validity (for example, that the project will cost U.S. $1 million, plus or minus 25%).  Each estimating method and type of estimate is used at different times in your organization.

Parametric estimate

The parametric estimate, wich was described, uses specic measures to estimate the effort requiered to komplete a task or to produce a work produkt. Examples are dollars per square foot.

The estimating unit (EU) is the unit defined by the team that can be measured and estimated. THe EU can apply to more that one task, but these tasks should be similar. Different factors can affect the task and can increase or decrease the effort and therefore, the EU. Too manu EUs can result in a methid that estimates individua items Tater than a large group of similar items. Examples of estimating units are lones of code, pages in a chapter, or numer of lessons in a vlase.

Analogy or Comparison Estimating

Analogy or comparison estimating is also called analogous estimating. It uses the actual cost of a previous, similar project as the basis for estimatinf the cost of the current project. Adjustments must be made to account for differences in performance, design, technology and opertaional characteristics.

I tis very important to consider the source and duality of analogous data.

Estimate Characteristics  

The following chart illustrates the characteristics of the types of estimates and the various methods of estimating.





Order of Magnitude

-25% / +75%

Initial Concept entry

Analogy / Comparison
Expert judgement


-10% / +25%

Concept DCP, CRM-RFI,
preliminary response to RFP

Analogy / Comparison
Expert judgement


-5% / +10%

Plan DCP

Analogy / Comparison
Expert judgement

Key points to remember about estimate characteristics are:
Order of magnitude is a top-down estimate.  It is used during the formation of the project for initial evaluation and during the IPD concept phase.  It is also called concept, preliminary, or feasibility estimate.  Order of magnitude should provide estimating accuracy of minus 25% to plus 75%.  It usually errs on the plus side.
Budget is a more detailed analysis.  It is a mixture of firm and unit costs for labor, materials, and equipment.  Budget is developed from more detailed project analyses and is used in the concept Decision Checkpoint (DCP).   Budget is also called the design, control, or appropriation estimate.  Budget should provide estimating accuracy of minus 10% to plus 25%.
Definitive is a detailed, bottom-up estimate used for proposals and evaluations.  It is prepared from well-defined data and specifications, and is used in the IPD plan and DCP exit phases.  Definitive should provide an estimating accuracy of minus 5% to plus 10%.
DCPs are structured project reviews with specific entry and exit criteria, used to measure the progress of a project.

Validating Estimates

Validate all estimates before you consider them complete.  Use the following checklist to validate an estimate:

  • Review the definition of the project to understand what is being estimated.  Be aware that you might be given separate targets for cost and expense.
  • Study the ground rules, constraints, and assumptions of the project, and understand the project environment.
  • Focus on data sources.  Determine the source of the estimates and statistics, determine whether the data has resulted from guesses, and look for omissions.  The best estimates are those that are provided by people responsible for the work and approved by people with accountability.  Challenge assumptions, such as asking why one technical solution is to be used instead of another, or why a supplier is to be used instead of an internal organization.
  • Compare the estimate with established standards.  Ask if standards exist.  If they do, what are they and what drives them?  Be cautious with standards because they might be out of date (for example, software development standards).
  • Determine whether the methodology is acceptable.  Ask if cost-estimating relationships apply and whether you have accounted for all costs.  An example is whether it is appropriate to use a top-down estimate based on the project phase.  If your project is in an execution phase, you should be preparing a bottom-up estimate.  However, if you are in a concept phase, then you could use a top-down or range estimate.
  • Look for cost drivers, which are major factors, and determine whether they are reasonable.  An example is that, if you have three programmers, you need to determine whether they each need one computer or two for coding and testing.  You would also need to ask if they each need their own telephone or if they could share one.  Other questions to ask are whether, when the programmersí tasks are complete, they should be retained, rented equipment should be returned, or offices should be moved to eliminate overhead for office space.  Determine the costs of project elements and pay close attention to keeping those costs down.
  • Determine whether the estimate meets the objective.  In review and validation, there are often changes to the estimate, and you must allow time to rework the estimate.
  • Use a different approach to validate the estimate.  If possible, use an independent reviewer and provide him or her with all of the necessary data.
  • Ensure that all risk response contingency and assumptions are included in the estimate.

Rules of Estimating 

The rules of estimating focus on honesty.  If you want an honest estimate, each element of this list has to be honest. 
The rules of estimating are:

  • Use the most appropriate approach and the most accurate method.  When building an estimate, even if it is high-level, you must follow the rules.  Each rule is crucial to successful estimating.
  • Communicate the level of accuracy.  The level of precision is the level of accuracy and trust that a project manager puts in an estimate (for example, if it is a broad estimate, don't claim total accuracy).
  • Involve the on-board project team members that are on board in the estimating process so that they can provide insight and can become vested in the process.
  • Base estimates on history.  Determine whether the team members have a history of developing poor estimates.  If the software estimators are usually correct, then their estimates should have greater credence.
  • Use standards, if available.  
  • When developing estimates, avoid starting with a presumed result and then working backward to justify this result.  Making estimates fit the available dollars does not generate an honest estimate.  If your estimates are not aligned with the targeted cost or schedule, address the problem and resolve it through trade-offs of scope, schedule, and cost.
  • Do not undervalue estimates.  Undervalued estimates that might win business usually result in cost overruns that might be invisible at the time of contracting.  As the project manager, you will be held accountable for that overrun.
  • Recognize that estimating takes time.  On average, it can take up to 2% of the total technical time to determine an estimate.
  • Document your assumptions.  This is a mandatory step in the process.  An estimate is not an estimate unless it is written down, including both assumptions and approach, in addition to numerical values.

Remember that these rules are fundamental to estimating.  You must follow them if you want to develop a valid estimate.

Cost Estimating and Budgeting

Estimating a project involves predicting the amount and cost of resources required to successfully execute the project.  Many approaches can be used to estimate.  Because each approach has advantages and disadvantages, you might need to combine approaches to obtain the best estimate for the project.  By using the estimate, you can develop a better understanding of the budget required.
Estimating is done as early in the project life cycle as possible and is normally repeated a number of times throughout the life of the project as changes in the project dictate.  Estimating is initially done during the planning process after which a budget is agreed to as the baseline for the project plan.  Estimates can be redone or refined throughout the project based on performance or on the need for redefining and replanning that results from project change requests.
Estimating is the process of identifying the 'should cost' for each project task and activity.  If estimating is performed at the higher levels in the WBS, this higher-level estimate must eventually be broken down to the task and activity level to effectively manage the project execution.  These tasks and activities then combine to form the 'should cost'  for the project's life cycle.  Although the estimate is not the project management schedule, it is used as input to the project management schedule when finalizing the project plan.

Budgeting is the allocation of the 'should cost' over the time period required to do the work.  The estimate provides the 'should cost' for the task or activity, but further analysis is necessary to determine the specific time period needed to perform.  Time periods can be hours, days, weeks, or months depending upon the complexity of the task, activity, or work product.  After the 'should costs' have been spread out over time according to when the work is to be performed, the project manager must develop a time-phased cost baseline that becomes the plan-of-record cost to a work package.  It uses the estimate to determine how much money is allocated to each work package.  This enables project managers to develop a financial measurement baseline that is then used to track and control the execution of the project.
Documenting your estimates and assumptions about the estimates is a very critical and mandatory part of the project.  It is the sole responsibility of the project manager to ensure that it is done.
This module shows you how to use estimating within project management and provides the terms and formulas used within estimating.  After you complete this module, you should be able to define what an estimate is, determine what should be estimated, recognize the difference between effort and duration, describe specific types and methods of estimating, discuss the estimating process, and describe what is involved in generating and validating an estimate.

Cost Estimating and Cost Budgeting Defined 

As stated earlier, estimating is determining the resources (labor, equipment, and facilities) needed to complete the project.  One reason for creating a project budget estimate is to provide a basis for tracking and managing project costs.  Specific tasks within the estimating process are cost estimating and cost budgeting.
When approved, the budget is placed under change control and is the basis for establishing the financial measurement baseline of the project.

  • Cost estimating consists of determining the cost of all of the elements needed to complete the project. 
  • Cost budgeting is the allocation of the determined cost estimates to individual project components so that those costs can be measured and managed as the project is executed.

When all of your costs have been defined and the project budget has been approved, all of the costs should be input into the WWPMM Financial Plan work product.  The description and template for the work product can be found along with descriptions and templates for all work products at the WWPMM Web site.

Terms Used within Cost Estimating and Cost Budgeting  

Become familiar with the following terms, which are used within the cost estimating and cost budgeting processes: 

  • Costs are the funds that a company spends to produce products or establish an infrastructure to provide services.  Examples are labor, raw materials, third-party software or hardware, and subcontracted work.
  • Direct costs are incurred for the benefit of a specific project.  Project managers can usually control direct costs.  
  • Indirect costs are incurred for the joint benefit of multiple projects and are applied through an allocation process.  Project managers usually have less control over indirect costs and frequently overlook them.
  • Fixed costs occur regardless of the complexity of the project.  An example of a fixed cost is plant maintenance.
  • Variable costs vary in relationship to related activities within the project.  An example of a variable cost is the price of a piece of copper.
  • Brand costs are the expenditures made to manufacture, distribute, and support a product or offering.  Examples are warranty, software manufacturing, direct labor, and factory overhead.

Questions to Ask When Cost Estimating  

When you are preparing a cost estimate, ask the following questions:  

  • What are the differences between fixed and variable costs?
  • How do fixed and variable costs affect your project?
  • What is the difference between direct and indirect cost?
  • What are examples of costs that you incur on projects?
  • What are the types of these incurred costs?

Not taking the time to make good estimates can affect several of the keys.  First, work and schedule will not be predictable, as deadlines will be missed.  The delivery organization benefits key will likely go red as spending increases and the project goes over budget.  How do the sponsor and key stakeholders react when the project is late and over budget?  Now your stakeholders lose their commitment.  And at the end, the project will not be successful and deliver the business benefits that were expected. Why Are Estimates Important?  

Think about your own project experiences.  Have you worked on a project where the estimates were not prepared properly?  Can you recall what effect poor estimates had on stakeholders and the project staff?

Estimates are important because they establish the basis for planning and establishing a baseline for tracking.  I have learned that almost every overrun of cost and schedule can be traced back to the failure of an estimate.  Without a good estimate, it is almost impossible for you to have a good project.
Estimating is more than determining a magic number.  Estimates combine all of the elements of the puzzle that comprise the total project, as shown in the following graphic.  If any one of these elements is not considered, the resulting estimate is invalid, and an invalid estimate leads to a difficult or, potentially, a failed project.

Project Schedule:

A schedule is any plan structured on a time dimension, including a project management schedule, financial plan, operating schedule, and staff schedule.

Schedules are key management tools for tracking and communicating the progress of a project.

You can use a project schedule to:

  • Track the planned versus actual progress of your project and show your team and your sponsor how the project is progressing.
  • Evaluate the planned versus actual progress of your project, and determine whether to revise the project to meet major milestones and completion tasks.
  • Communicate task interdependencies to the project team, project sponsor, and other stakeholders.
  • Determine whether to accept or reject a change based on how it affects the sequence of tasks, resources needed, staff responsibilities, major milestones, and project completion date.

What Is a Schedule? 

A schedule is any plan structured on a time dimension, including a project management schedule, financial plan, operational schedule, and staff schedule.  Schedules are key management tools for tracking and communicating the progress of a project.
A project management schedule is a road map of a project that states the duration and sequence of events and activities; more specifically, it states what will be done, when it will be done, and who is responsible.  It is composed of estimates, work products, activities, and tasks from the WBS, and resource information.  A schedule also contains the planned dates for performing activities and meeting milestones and defines how the current project interlocks with other projects.
A project management schedule can be represented in a variety of ways.  Three of the most common are precedence diagrams, Gantt chart, and milestone chart.  These are detailed later in this lesson.

As the project manager, you use a project schedule to:

  • Track the planned versus actual progress of your project and show your team and your sponsor how the project is progressing
  • Evaluate the planned versus actual progress of your project, and determine whether to revise the project to meet major milestones and  completion dates
  • Communicate task interdependencies to the project team, project sponsor, and other stakeholders
  • Determine whether to accept or reject a change based on how it affects the sequence of tasks, resources needed, staff responsibilities, major milestones and project completion date

Scheduling Terminology  

This section lists terms and definitions used in project scheduling:

  • A task is a subdivision or portion of an activity; it describes the lowest level of the WBS. 
  • An activity is an element of work performed over a period of time within the project.  It is a specific piece of work in the WBS.  An activity has a measured beginning and a measured end.
  • Starting points and ending points of activities are known as events.  An example of an event might be Begin Code Development.
  • A milestone is an achievement or a significant event in the project or subproject, such as a major decision or completion of an important activity.  It is an activity that has zero duration and zero resources.
  • A precedence relationship is a dependency between two activities, or between a project activity and a milestone.  For example, when creating a driveway, the concrete must be mixed before it is poured; therefore, the task 'Pour Concrete' has a precedence  relationship with the task 'Mix Concrete.'
  • The precedence diagramming method (PDM) is a means of constructing a project network diagram using nodes to represent activities and connecting them with arrows to show the dependencies.  This method is also referred to as an activity-on-node (AON).  It is the method used by most project management software, and it can be done manually or on a computer. 
  • A project network diagram is any schematic display of the dependencies among project activities.

Including Level-of-Effort Tasks in the Schedule  

You must include all project management and technical tasks in the schedule.  Some of these are level-of-effort (LOE) tasks, which are activities that are not easily measured in terms of discrete accomplishments.  LOE tasks that should be listed in the project schedule include, but are not limited to:

  •   Change management
  •   Risk management
  •   Communication management
  •   Vendor or customer liaison
  •   Progress management
  •   Contract management  
  •   Project management
  •   Supplier agreement management
  •   Technical environment management
  •   Engineering management

As you schedule these LOE tasks, you must validate your estimates to ensure that you have included enough time.  In doing this, you might find that you need additional time; if so, you must include it.  If you do not, and the contract is a fixed-price contract, the cost will be higher in the end.

Displaying the Schedule

Precedence diagrams, Gantt charts, and milestone charts are ways of displaying the project schedule.  They can be created with most project management software tools.

Click the buttons to view each type of diagram:

Precedence diagram

A precedence diagram, is one type of project network diagram.  It shows the relationships between activities.

Grantt Charts

A Gantt chart, is useful for viewing planned project activity versus actual activity.

Milestone Charts

A milestone chart, is often used for communicating with upper management. 
Note that, until resources are actually assigned, these views are only estimates, not actual schedules.  The project manager must use the right view for the right purpose.

Description of a Project Network Diagram

A project network diagram consists of a series of project activities arranged in a logical flow.  It is the basis for a project schedule and provides a consistent framework for planning, monitoring, and controlling the project.  Every work element from the WBS is represented in the network diagram, and only WBS work elements are represented there.

The precedence diagram includes only the elements from the lowest level of the WBS.  It does not include rollup activities (1.0, 2.0, and so on.).

From WBS to Project Network Diagram

The WBS contains all of the activities necessary to complete the project, but it is not a scheduling tool.  The project network diagram is a scheduling tool that shows the predecessor and successor relationships between activities from the WBS. 
One difference between a project network diagram and a WBS is that a project  network diagram contains start and finish nodes.  Nodes are essential because they provide anchors for the software algorithms for team members who use software packages such as Microsoft Project.
When you combine all of the products and activities from the WBS, the project network diagram, estimates, and resource requirements, you will have a clear  road map of the what, when, how, and who of the project.
To create a project network diagram, list the activities or tasks for the project.  These become the activity nodes in your project network diagram.  Ask the project team if they have activities that need to be finished before other activities can start.  Record the order in which activities need to be completed.  Working in this way, continue identifying and then drawing the dependency relationships to create a network diagram of the project.
Remember that a project network diagram is built only from the level or levels in the WBS in which work is assigned and accomplished.  WBS activities are represented as a sequence flowing from left to right on the diagram.  An arrow going into the left side of a node indicates the start of a task.  An arrow leaving the right side of the node indicates the end of a task.

Elements of a Project Network Diagram

  The elements included in a project network diagram are:

  •   Intuitive start and end points 
  •   Boxes that represent an activity at the work element level
  •   Arrows that denote data about the relationship between tasks
  •   Predecessors and successors

Guidelines for Creating a Project Network Diagram

Follow these guidelines for creating a project network diagram:

  • The project network diagram starts with a task or milestone.  
  • The project network diagram ends with a task or milestone.
  • There are predecessors or successors for all activities--no danglers, or separate, unrelated tasks without connecting arrows.
  • The network logic must be kept up-to-date.  You must go back and check the relationships as the project progresses.  Project changes might mean relationship changes, and the project network diagram must reflect them.
  • There are no loops.  Circular relationships do not allow definition of an end date.  Some sophisticated software tools allow loops, but the default settings must be adjusted and the number of loops specified.

An example of a loop is as follows:

    1. Development sends code to Test.
    2. Test returns code to Development with defects marked.
    3. Development fixes the defects.
    4. Development sends code back to Test.

With the fourth step, the process starts to repeat itself.

Creating a Precedence Diagram  

Three common methods of creating project network diagrams are the precedence diagram method (PDM), the project evaluation and review technique (PERT), and the critical path method (CPM).

Many project managers use the PDM to create a specific type of project network diagram.  In a PDM diagram:

  • Activities are represented by boxes or nodes
  • Activities are linked by one of three common types of precedence relationships
  • The logical relationships of project activities are displayed
  • A time line is drawn running from left (earlier) to right (later)
  • The start and finish dates for each activity are shown

Although a precedence diagram has specific information, such as predecessor, successor, and duration, written on each box, it is different from a conventional flow diagram.  It cannot, for example, contain loops, because this would require moving backward in time.

Each box in a precedence diagram represents an activity at the WBS work element level; these boxes are called nodes.  Nodes are linked by arrows that show the nature of the relationship between predecessor and successor activities.

Creating a Precedence Diagram  (continued)

In the following chart, notice that activity 1.1 is the predecessor to activity 1.2.  This means that activity 1.1 must be completed before activity 1.2 can start.  Following this logic, activity 2.2 cannot start until both activities 1.2 and 2.1 are both completed.  Note that there is no precedence relationship between 1.2 and 2.1, so there is no arrow connecting them.

PDM diagrams are frequently confused with PERT charts.  You can tell them apart because PERT charts contain multiple time estimates for each node, whereas PDM networks have a single time estimate for each work package.  PERT charts also use activity on arrow (AOA), where the arrow represents the activity and the node is the event; for example, the start or finish of an activity.

PDM Network Relationships

The activities in a PDM network diagram have one of three types of precedence relationships:

Click each button to read a description of that type of relationship.

Finish-to-Start Relationships 

The FS relationship is the most common precedence relationship.  In an FS relationship, one activity must finish before another activity begins.  In the following example, activity 1.2 cannot start until activity 1.1 is finished.  
  Examples of FS relationships might include:

  •   Pour the concrete; remove the frame.
  •   Define requirements; write the code.
  •   Set the budget; buy the product.

Finish-to-Finish Relationships 

In an FF relationship, the predecessor activity must be completed at the same time as the successor activity is scheduled to finish.  You might need to know how to build FF relationships if your sponsor is operating on a just-in-time basis or if you have no warehousing capabilities.

FF relationships are important when two tasks must finish at the same time;
for example:

  •   Bake the turkey; bake the yams.
  •   Develop the product; develop the user guide.
  •   Test the code; validate the documentation.

Start-to-Start Relationships 

SS precedence relationships are used in situations where one or more key activities must be started at the same time so that a project can remain on schedule.  An SS dependency requires that the predecessor activity be scheduled to start before or simultaneously with the successor activity.  In the following example, activity 1.2 cannot start until activity 1.1 has started.
These are examples of SS relationships:

  •   Write text; revise text.
  •   Install plumbing; install wiring.
  •   Select a design; select vendors.

Lead Time and Lag Time

Lead time and lag time are changes in precedence relationships that direct a delay or acceleration in the successor task.  Both are formal ways to adjust the schedule.
Lag time is a delay imposed on the relationship between two activities.  For example, in a  finish-to-start dependency with a 10-day lag, the successor activity cannot start until 10 days after the predecessor has finished.  Lag time is generally expressed as a positive number because lag time adds to the overall duration of a series of activities.  Lag time must be counted when computing your schedule duration.
Lead time is an acceleration of the successor activity.  For example, in a  finish-to-start dependency with a 10-day lead, the successor activity can start 10 days before the predecessor has finished.  Lead time is usually expressed as a negative number because it subtracts from the overall duration of a series of activities.

An example of the use of lag time is adding one day to a six-day model airplane project schedule.  After the first three-day activity, Glue Model (activity 1.1), is complete, one day of lag time is added to enable the glue to dry.  Then the remaining three-day activity, Paint Model (activity 1.2), can be accomplished.  The result is an overall schedule duration of seven days. 

Lag time is not counted as part of an activity's duration. Lag represents a fixed delay between the start or finish of one activity and the start or finish of another.
An example of the use of lead time is the subtraction of a week from an overall six-week schedule for creating a software program.  The first activity, Write Code, does not necessarily need to be completed before the second activity, Write Documentation, begins.  By overlapping these two activities by one week, the overall schedule can be reduced to five weeks.

Using the Precedence Diagramming Method 

The first step in drawing a precedence diagram is to determine the dependencies among the activities in your WBS.  A good way to do this is to put the title of each activity on a small piece of note paper.  Take all the notes and stick them on a large piece of paper or on a wall.  Along with members of the project team, work through all the dependencies, putting them in their correct order.  You will probably change your mind several times and move the notes around.  When the activities are in the correct order, draw arrows between them denoting the dependencies.  This gives you the basic layout of your precedence diagram.  Take the time to ensure that the project team agrees on the layout of the project activities.
When you have the basic layout of the diagram, write the estimated duration of each activity in the middle of its box under the title.

Documenting the Values in Each Node 

The boxes you created in the preceding paragraph are part of the standard format for the nodes in a precedence diagram.  The activity name, WBS number, and activity duration are placed in the middle of the box.  Four other values are placed in the corners of the box.  These four values are:

  •   The early start (ES), which is the earliest time the activity can start
  •   The early finish (EF), which is the earliest time the activity can finish
  •   The late start (LS), which is the latest time the activity can start
  •   The late finish (LF), which is the latest time the activity can finish

Calculating Start and Finish Dates

Part of creating a precedence diagram is calculating the start and end dates for each activity.  Two processes that help you do this are the forward pass and the backward pass.

Applying the Forward Pass

The forward pass is used to calculate the ES and EF dates of all network activities.  Here are the steps to follow.
The first activity starts on day 1 of the project; therefore that is the ES date for that activity.  In the following example, the first activity is Mix Concrete.  Its ES is day 1, the first day of the project.

Now you can calculate the EF for the first activity by adding the activity's duration to the ES.  In this case, the duration is 6 days, so the EF is 7. 

The ES for the next activity is the EF of the preceding activity.  In our example, the ES for Pour Concrete is the EF for Mix Concrete, 7.  Add this to the duration of the second activity, 4, to get its EF, 11.

By going through the entire diagram in this way, you will arrive at the project's EF, the earliest date the project can finish.  

The formula for the forward pass is ES + duration = EF.

One point to keep in mind is that some activities have multiple predecessors.  The ES is the earliest date that all the dependencies have been satisfied.

Applying the Backward Pass 

The backward pass is used to calculate the LS and LF dates of all network activities.  These are the latest dates these events can take place without affecting the finish date of the project.
For this example, assume that the LF of the activity following Pour Concrete is 15.  To calculate the LS of Pour Concrete, take 15 and subtract 4, the duration of the activity, to get 11.
The LS of Pour Concrete is the LF for Mix Concrete.  To calculate the LS for Mix Concrete, subtract the duration from the LF: 11 - 6 = 5.  This means that Mix Concrete can start as late as day five without affecting the finish date of the project.
The LS calculation is LS = LF - duration.

Note that in the last activity of the project
the EF is the same as the LF.  Using that
LF, you can start the backward pass. 

Also note that the LS and LF numbers do
not equal the ES and EF on the bottom

Lag and Lead Time in the Forward and Backward Pass 

You might recall that lag time adds time to the schedule and lead time subtracts it.  An example of lag time is waiting until the glue dries before painting a model.  An example of lead time is doing two activities in parallel rather than in sequence to save time in a development project.  You must take lag time and lead time in a schedule into account when calculating using the forward or backward pass to calculate.

In the following example, the EF for Mix Concrete is 7.  Using the forward pass, and with no lag time, that would also be the ES for Pour Concrete as well.  However, if you decided to add 5 days to allow the concrete to cure (notice the arrow), the ES for Pour Concrete becomes 12.  The formula is EF + lag time = ES of the next activity.
Using the backward pass in the following example, you would subtract the 5 days of lag time from the LS of Pour Concrete to get the LF of Mix Concrete. Lag and Lead Time in the Forward and Backward Pass  (continued)

Whereas lag time adds to the schedule, lead time subtracts from it.  In the following example, it has been decided that Pour Concrete can start while Mix Concrete is being done.  Again, notice the arrow.  Using the forward pass, 2 days would be subtracted from the EF of Mix Concrete to calculate the ES of Pour Concrete.  The formula is EF - lead time = ES of the next activity.

Using the backward pass in the following example, you would add the 2 days of lead time from the LS of Pour Concrete, 6, to get the LF of Mix Concrete, 8.

What Is Float?

There are two kinds of float.  Free float, or slack, is the amount of time a single activity can be delayed without delaying the ES of any subsequent activities.  Free float determines the pressure that one activity puts on the next activity.
Total float is the sum of free float for each activity in a particular path.  It is also the amount of time an activity can be delayed from its ES date without delaying the project finish date.  Total float often changes as the project progresses and changes are made to the project plan.
Project managers use total float to adjust schedules and resource allocations.  When it is used to adjust resource allocations, the process is called resource leveling.
Total float is an important indicator of project status.  If total float is greater than 0, then slack time is available.  If total float is 0, then the situation is critical.  If total float is less than 0, then the project is already behind schedule or critically late.

Calculating Free Float and Total Float

Click each button to read the description and calculations.

How to Determine Free Float

Calculations for float time use ES, EF, LS , and LF values.

The calculation for free float, which again is the amount of time an activity can be delayed without affecting the early start date of the successor activity, is:

Free Float = ES (successor task) - EF (predecessor task)

In the following example, the calculation for free float between activity A and activity B is FF = 5 - 3 = 2.  This means that task A can finish as late as day 5 without affecting task B.

Total Float and Free Float Example

Calculate the total float and free float for the following example.  Remember that you must complete the forward pass and then the backward pass before you can calculate float.

The total float for tasks A, C, G, and H is 0.  The total float for tasks B, D, and E is 7:  8 - 1, 11 - 4, or 14 - 7.  The total float for task F is 8:  12 - 4.
The free float for tasks A, C, G, H, B, and D is 0.  The free float for task F is 1:  7 - 6, and for task E, 7:  17 - 10.
Remember that free float is time available between activities, and total float is time available within an activity.  Float can be used to determine wether a project might be finished earlier by using resources that have time available within a task or between tasks to aid those tasks with 0 float.  The tasks with 0 float are critical and must start on the ES date and finish on the EF date, or your project will be late.

Characteristics of the Critical Path

As the project manager, you want to make the best use of your time.  The critical path method helps you do that by focusing your attention on the activities that must start and finish on time or else the project will be late.  All the activities that have zero total float are on the critical path.  If any of them starts or finishes late, then the whole project will be late.  Every project will have at least one critical path that runs from the Start node to the Finish node.

The critical path of a project is the longest path in the network; therefore, it determines the earliest completion date of the project.  In the following example, the critical path runs through tasks A, C, G, and H.  This path is the one with no float, and it is the longest path through the project.  It represents the shortest time period in which the project can be completed: 19 days.

The critical path might change as your project progresses; for example, if another path within your project has a total float of 1 day and is delayed by 2 days, that path might now become the critical path.
Sometimes a project has multiple critical paths.  This can increase the risk of missing the project's completion date because there is more than one path that has no float in the schedule.  If you do not know where the critical paths are, the risk is much higher that you will not meet your schedule.
In summary, the critical path is:

  • The longest path through the project
  • The path with 0 float or slak time
  • The shortes time to komplete the project

Validating the Precedence Diagram

So far you have been making mathematical calculations, and now you need to make sure the results are going to work in the real world.

Before you translate the precedence diagram into a schedule, you must do one final validation. 

The validation steps are:

Ensure that your network is komplete and current

Have you correctly identified your critical path?

Should any tasks with large amounts of float be rescheduled?

Are there any danglers?

Become familiar with your network and analyze it

What risks are on the critical path?

Are there near-critical paths?

How much float is available?

What types of float exist on which tasks?

Ensure that your objectives can be met

  • Do you need to add any milestones?
  • Which tasks involve external deliverables?
  • Can the work be completed in the desired time frame?
  • Is delivery possible within the time frames and durations you have set?

How to Create a Schedule from a Precedence Diagram

The following diagram indicates that there are numerous inputs to the project schedule in addition to the precedence diagram.

Other areas you need to consider include:

  • Identifying required roles: What roles are required for each activity?
  • Assessing staff skills: Who has the correct skills to do the work?
  • Estimating staff availability: Are the staff available during the required time frame?
  • Estimating tasks: How long will it really take to perform each task?

As the project manager, you first determine what must be done to complete each task; this means identifying the necessary roles and the needed skills.  Then you determine who has the required skills and assign them to the appropriate roles.  The people assigned must have the skills necessary to fulfill these roles.  If they do not, you might need to add more people or change the schedule to allow time for training.
The challenge is to coordinate all of these inputs to develop a schedule that satisfies all the stakeholders.

Is there a complete set of roles for each task?  If not, add roles where needed.

Checking the Schedule   

After generating the schedule, you must check each input and assumption one more time to ensure that nothing has been overlooked.  Consider involving an outside person in the checking process.
The following questions will help you check the schedule:

  • Is there a complete set of roles for each task?  If not, add roles where
  • Are there people assigned to these roles?  If not, assign staff where needed.
  • Do the assigned staff possess the needed skills?  If not, add or change people, or re-estimate the duration to allow for training time.  Arrange for training and add the training tasks to the schedule and the WBS.
  • Will the people really be available when needed?  If not, reschedule around nonavailable time, change utilization assumptions to adjust the duration, or add more staff.

Checking the schedule usually requires several iterative passes.

If Your Schedule Is Constrained by Time or Resources  

If your schedule is constrained by time or resources, consider the following options: 

  • Crash the schedule.  This means applying more resources to reduce the overall project duration.  Resources are usually applied to the activities with the least float until the desired project duration is achieved.  Crashing usually increases project cost and risk, but it reduces overall project duration. 
  • Fast-track the schedule.  This means compressing the project schedule by overlapping activities that normally would be done in sequence; for example, design and construction.  Fast-tracking might change the relationships among tasks and shorten the critical path.  Fast-tracking usually increases project cost and risk, but it reduces overall project duration. 
  • Change the approach.  Changing your approach to the work might create a different set of interrelated activities with a shorter critical path.  This might also require changing the WBS.
  • Re-evaluate dependencies.  Determine whether any FS start relationships can be changed to FF relationships.
  • Revisit hard constraints.  If any of these hard constraints affect a task on the critical path, that task might start or end sooner.
  • Use float.  Consider using the float you have available to adjust the schedule.

Types of Schedules  

WWPMM uses two important types of schedules.
A project management schedule defines the planned start and finish dates for, and the dependencies between, all the work units for which the project organizational unit is responsible.  A project management schedule contains all the technical work and all the project management work being done by any reporting organizational unit one level below the unit in the organizational breakdown structure (OBS).
An operational schedule shows how the work of a project organizational unit is broken down into work items.
The purpose of an operational schedule is to:

  • Break the project management schedule into subsets that are easier for the subproject teams to work with
  • Provide each member of the project team with a list of the work items they have to achieve within a period of time, and the planned effort that determines how they organize and perform their work
  • Enable the team leaders to track the progress of team members on their work items

A WWPMM work product description and a template are available to assist you in creating a project management schedule and an operational schedule.  You can find these along with descriptions and templates for all WWPMM work products, at the WWPMM Web site.

Work and Schedule are Predictable Key

This key covers estimating and scheduling, and is often the first key to become unhealthy on a project.  Sometimes problems in this key are due to poor estimation and scheduling during the planning phase.  But the root cause for work and schedule problems are often found in other keys, such as the stakeholders lose their commitment or the scope is not well understood.

Here are some criteria for assessing the Work and Schedule are Predictable key:

  • The project plan is accepted and maintained.
  • Interim and final milestone and deliverable acceptance criteria and roles are accepted.
  • The approach is appropriate, adequate, and followed;  resources have been scheduled.
  • Confidence in the accuracy of progress reports and estimates to complete is high.

Healthy Signs

      Everyone gives the same definition of finished.

      Good evidence of control is available.

      Slippage, when it happens, is predicted

Unhealthy Signs

      Stakeholders and project team members cannot describe what finished means.

      Controls are not evident, including poor plans and tracking mechanisms.

      Slippage is a surprise.

This key is the traditional project management indicator of project health.  It is otherwise known as 'on time and on budget.' The project team uses this early project health indicator to implement a correction in the course of the project.

What's the Value of a Precedence Diagram?  

A precedence diagram is a terrific tool that helps me understand my project, make sure I have
all the activities identified, and understand how they all relate to each other and to the external
dependencies.  As I'm going through the process, I always find additional activities that I had
missed, and I go back and add them to the WBS.  By working through the dependencies, it
becomes clear what needs to be done first and what can be done later. 
A precedence diagram is essential so that I can see how long it's really going to take to finish this project.  The critical path is the key element here.  That defines the longest path.  If any of those activities miss their targets, the schedule starts slipping.  I have to have that data to create my schedules and understand which activities have the highest priority.  Otherwise, I'm just guessing.

Why Check the Schedule So Thoroughly?  

When the schedule is approved by the stakeholders, it becomes one of the project's constraints, along with cost and scope.  That means that it has to be as accurate as possible.  If the schedule is incorrect but the scope is correct, I'm going to miss the dates, and the customer will not be happy.  In most cases, the project will also go over budget at the same time. 
A great  precedence diagram doesn't guarantee a great schedule.  I find that I need to carefully recheck the assumptions that went into the precedence and the schedule after I create them.  I ask myself, Is this schedule based on reality?  Can we really do it?

Change management

Changes occur and cannot be ignored. Managing change is critical to the success of a project.  Change management helps protect projects against scope creep, which occurs when the requirements baseline changes.  As additional requirements are added to the project, the cost of the project increases and the schedule moves out.

When managing change on projects, remember the following steps:

  • First, identify the change. Be sure to clarify the scope of the change and document it on a change request form. Estimate the complexity and the cost of investigating the change.  The Change Control Board (CCB) will approve, reject, or defer the change request.
  • Second, investigate the change. This step might be performed by the CCB. The change is investigated for its impact, as well as for the costs and benefits of the change.  Alternatives might need to be developed.  The cost of the change request must be estimated and submitted to the CCB.
  • Third, implement the change. The change order provides instruction for implementing the change.  Be sure to communicate impact assessment to stakeholders, including the originator of the change request.

Concept: Change Management

What Is Change Management?

Change management includes the processes required to control all of the changes that inevitably arise during the course of a project changes that might jeopardize cost, revenue, quality, or deadlines. 
Managing change is critical to the success of a project.  As stated previously, executing change management might result in changes to one or more of the project baselines.
A change request is defined as a request to change some document or aspect of the project that has been placed under change control, or baselined.
Change management:

  • Analyzes each change to ensure that it is beneficial to the project
  • Determines that a change has occurred
  • Manages changes when they do occur

Change management contains the following:

  • Procedures for managing and controlling the baseline
  • Procedures for managing a change request to completion
  • Formally documented procedures for defining how to manage change
  • The established documentation, tracking systems, and approval levels necessary to authorize change

Some tracking systems might include procedures for addressing changes that can be approved without prior review.  If this is the case, these changes must still be documented and addressed so that they do not cause problems later in the project.

Types of Change 

Changes might be technical or contractual as shown in the following figure.

Technical changes.  Technical changes result from the implementation of the solution.  Normally, the changes are generated internally and are within the scope of the project.  An example of a technical change is implementing a program that automates test cases.  This program helps improve the quality of the testing. 
Contractual changes result from changes in the terms and conditions, the scope of work, the requirements, schedule, and costs.  Normally, contractual changes are externally generated and out of the project scope.  For example, the sponsor might ask IBM to include maintenance of a system as part of a purchase agreement for the system with IBM.

For both technical and contractual changes, a formal change management procedure must be established.

What Is a Baseline?

WWPMM defines a baseline as the reference data on which execution of project activities are planned and controlled.  A baseline consists of elements of the agreement and the project management plans.  A baseline might also be considered as the original plan, plus or minus approved changes.
A baseline becomes formal after the involved stakeholders review and approve it, then sign off in writing.  After it is established, the baseline is under change control.  


Why Establish Baselines?

Changes occur in almost every project.  Experience has shown that without baselines, managing change is very difficult, if not impossible.  Unmanaged change can cause the scope to increase to the point where the project is out of control.
Establishing a baseline helps you determine boundaries for the project, including what is being developed, when it is scheduled to be delivered, and how much it is projected to cost.


Required Baselines for Managing a Project

Although many types of baselines are possible, the three types that must be set for each project are:

  • Requirements
  • Schedule
  • Cost

Requirements, cost, and schedule are known as the triple constraints.  They are interdependent; a change in one of the three has an impact on the other two. 

The requirements baseline is established after all project requirements have been defined and documented and then reviewed and approved by the appropriate stakeholders on the project, including the project sponsor, who then must sign off in writing.

  • The requirements baseline serves as the critical baseline for the project's technical requirements.  Changes to this baseline must be carefully monitored and controlled.  
  • The schedule baseline is established after project planning has been completed and the project schedule has been reviewed and approved.  Again, all appropriate stakeholders, including the project sponsor, must sign off in writing.
  • The cost baseline is established after all cost items on the project have been estimated and the price for the project has been reviewed and approved by the project sponsor.

Baselines and Change Management 

Changes do occur.  Change management ensures that all changes are documented and everyone is aware of the impact they will have on all the baselines.  Change management provides discipline regarding who can provide or modify the baselines.  Without this control, changes could come from almost anywhere, such as senior management, sponsors, users, suppliers, and technical personnel, and the project team might be expected to implement them without regard for the impact on the project.  Uncontrolled baselines can lead to late products, low quality, and cost overruns. 
Changes must be reviewed and approved before they are added to the baseline.  This process ensures that any potential problems are identified before the change is implemented and that the change request is complete, consistent, and feasible.

What Is Included in a Change Management Process

Many projects have encountered serious difficulties because a formal change management process was not established and enforced.  Without a doubt, change management is one of your key responsibilities as the project manager.  Even a one-line change could be extremely significant.  That is why you always need to be careful when managing change.
Given the importance of change management, you, as the project manager, must ensure that the process for managing changes is clearly documented and understood by all project stakeholders, suppliers, and the IBM delivery team.  This process must then be strictly enforced whenever the need for a change occurs.
Change management includes a:

  • Change management process
  • Change request form 
  • Change control board (CCB)
  • Change log 
  • Change order form

You must identify what baselines you will control, at what level of detail, how, and by whom.  Each change to any of these baselines should be documented and follow the defined change management process.  Many projects use a CCB for accepting, rejecting, or deferring change requests.  The powers and responsibilities of a CCB should be well defined and agreed upon by key stakeholders and included in the change management plan.  On some large, complex projects, multiple CCBs might have different responsibilities.

Establishing and enforcing a formal change management process is key to project success.

The Change Management Process Illustrated

The following figure shows the process that should be used to manage changes.

Steps in the Change Identification Process

The major steps in the change identification process are:

  1. Identify the change.  The first step in the change management process is identification of a change by someone on the project.  This change must be documented in a change control form and submitted for consideration to either the project manager or the CCB.
  2. Clarify the scope.  The change request is reviewed and, if necessary, discussed with its originator to clarify what is being proposed, and the rationale and scope of the proposal.  A small change might be immediately accepted.  An example of a small change is a proposed change to the name of a future deliverable in the requirements.  However, keep in mind that even small changes require some amount of coordination and communication.

Estimate the complexity and the cost of investigating.  For large changes, a quick assessment of their complexity and an estimate of the cost of investigating is done.

Approval or rejection.  The change request is then reviewed by the CCB and is approved for a full impact assessment, rejected, or deferred.  If the change request is rejected or deferred, it is logged, the reasons for the rejection or deferral are documented, and the change request is filed for possible future reconsideration.  All interested stakeholders are informed of this decision.

Change investigation

The following steps are performed when investigating any change:

  1. Identify impacts and evaluate costs and benefits.  If the change request is accepted for investigation, it is turned over to the appropriate project  personnel to do a full impact assessment on baselined requirements, cost, and schedule, plus an evaluation of the benefits.
  2. Select an alternative.  It might be appropriate to develop several alternatives to the change request for consideration by the change control board.
  3. Estimate the cost.  The cost of the change request and its alternative, if any, is then estimated and submitted to the change control board.

The change request is reviewed by the change control board and approved for implementation, rejected, or deferred.

If the change request is rejected or deferred, the result is logged, the reasons for rejection or deferral are documented, and the change request is filed for possible future reconsideration.  All interested stakeholders are informed of this decision. 

Change Implementation 

If the change request is accepted for implementation, a change order is generated instructing the appropriate project personnel, including suppliers, to implement the approved change request or its alternative.  In addition, all appropriate baselined documents are updated to reflect the change, including the possible revision of the contract with the sponsor and the supplier.  The result is logged and filed, and all interested stakeholders are informed.

Generally, your approval signature and that of the project sponsor are needed before the change request proceeds to impact assessment.

You must ensure that the impact assessment considers the impact on schedule, costs, resources (hardware and software), personnel (including suppliers), documentation, logistics support, and the contract terms and conditions and performance. 

Communicate the decision for each change request to those who need to know, including the originator of the change request.

The Change Request Form 

Whoever wants changes, either the project team or sponsors, must submit the request using a change request form.  The change request form describes the impact of the change on the project, including the cost of the investigation and the cost of the change.  The purpose of the form is to minimize frivolous changes.
The form is used on both large and small projects and represents the minimum documentation.

Example of a Change Request Form

The graphic shows a template of a change request form.

The Change Log 

Use a change log to list all changes, the owner or originator, and the status.  The change log is a WWPMM work product.  

Typical Follow-Up Actions for Change Requests

If a change is:

  • Accepted and considered to be in-scope, it should be incorporated into the system.  Note that the baselines might need to be changed.  You must prepare a schedule to incorporate the change along with the resources allocated to handle the change.  
  • Accepted and considered to be out-of-scope, prepare a proposal that includes the price of the change to the project sponsor.  Do not implement the change until the contractual agreement is reached and the contract is revised.
  • Rejected, regardless of whether it is considered to be an in-scope or out-of-scope change, ensure that the originator of the change understands why the request was rejected.
  • Deferred, regardless of whether it is considered to be an in-scope or out-of-scope change, direct the project team to perform further analysis, consider alternatives, or hold the request until a specified time and then consider it.

Guidelines for Managing Change 

Follow these guidelines for managing project changes:

  • Introduce change control early in the project.  Make it part of the project kick-off. 
  • Encourage the customer to fund a reasonable number of hours to be used to implement approved changes and to investigate change requests.
  • Determine how changes are to be introduced and processed with a documented procedure that is part of the project management system.
  • Use a change request form to document proposed changes.
  • Ensure that changes are approved in writing by the authorized representatives.
  • Update the baselines and all appropriate documentation after each change is approved.
  • Communicate the decision on each change request to all those who need to know, including the originator of the change request. 
  • Early in the project, use the change control process to authorize a change that has no cost or schedule impact.  The customer is much more agreeable to signing a change authorization if it does not cost them anything.  By executing a no-cost change order, you and the customer will have set a precedent for approving  changes.

How to Implement the Guidelines for Managing Change
IBM's policy is that all projects have change management procedures in place.
You, as the project manager, must implement these guidelines on every project in a strict and conscientious way.  The change management process must be executed and strictly enforced in order to maintain control of your project.
The process of managing change should not be complex.  Problems arise, however, when project managers, in an attempt to reduce bureaucracy, adopt an informal process to handle change requests.  Misunderstandings often result from informality.  As project manager, you might find that, because the project is committed to deliver a changed output, you have to absorb the added cost involved and scramble to meet the old schedule.  Changes to your project might also affect projects managed directly by the customer or other organizations.  For these reasons, change control is an important part of the project manager's job on every project.

Think of all the bad things that can happen to a project if changes are not managed.  And then think of how the Seven Keys will be negatively impacted.  Scope will be unknown.  Work will not be completed on time and on budget.  Team members will not know what they are supposed to be doing.  New risks will arise and existing risks will become more severe.  And finally, stakeholders will be surprised when the deliverables do not match their expectations.

When analyzing each change request, determine how the change will impact each of the Seven Keys.

Why It Is Important to Manage Change  

Have you ever been on a project where change was not managed well?  Think about what the project manager should communicate to the stakeholders in order to successfully control the change management process.

Managing change is a critical factor in the success of a project. Without a sound, well-understood, and enforced change management process, the project will be out of control soon after it starts.
Change is inevitable.  It will happen.  You, as the project manager, must be prepared for it and manage it appropriately.  Your focus should be on controlling the amount of change by ensuring that all changes that are of benefit to the project are appropriately analyzed (including assessing impacts), approved, communicated, and implemented in a timely, cost-effective manner.  At the same time, ensure that any proposed changes that are of little or no value to the project are rejected.

The Project Management Body of Knowledge states that a project manager will spend about 90% of their time communicating.  Change management is an area where it is vital to gather input from stakeholders and communicate the decision about the change, whether it is approved or not, back to the stakeholders.
In all but the simplest of projects, some change is essential.  In projects with an external sponsor or customer, changes can be an important source of additional revenue and improved or enhanced deliverables.  However, too much change can impact productivity and ultimately can lead to the project becoming out of control.  You, as the project manager, must ensure that this does not happen and that change is a positive, well-managed process. 
I encourage you to review the document Prevention Measures to Avoid Troubled Projects, which includes a number of items relating to project baselines and change management.  This document is available at the Quality Assurance Web site.

Project control and execution

Project management is about planning, organizing, monitoring, and controlling all aspects of a project in a continuous process.  Project control is an aspect of project management.  Its focus is to define and execute appropriate actions to ensure the success of the project.  Without good project control, the scope, costs, and risks increase and cause deadlines to be missed.

With project control, remember the following:

  • Start with clear objectives that are based on the projectís goals.
  • The Project Control process has four steps, and itís an iterative process.
  • The Project Control book should contain all the data required to control the project.
  • You can analyze the status of the work using the outputs from project baselines.


Project Management and Project Control   

ISO 10006 defines project management as the planning, organizing, monitoring, and controlling of all aspects of the project in a continuous process to achieve the project's objectives.  Project control, an aspect of project management, is defined as the process required to define and execute appropriate actions to ensure the success of the project.  The focus of project control is monitoring, analyzing, and comparing planned results with actual results for the purpose of predicting what might happen if current conditions continue.
Project control begins with clear objectives and emphasizes the achievement of the project goals.  It involves continuous monitoring of individual project events and elements such as budgets and schedules.  Without good project control, the scope, costs, and risk increase and deadlines are missed.

The Key Elements Required to Control the Project  

Although tracking and controlling a project's overall performance is addressed directly in the WWPMM Tracking and Control domain, you must also focus on plans and procedures in the following key domains:

  •   Change management
  •   Communications management
  •   Deliverables management
  •   Event management
  •   Human resource management
  •   Project definition
  •   Quality management
  •   Risk management
  •   Sponsor agreement management
  •   Supplier management
  •   Technical environment management
  •   Work plan management

Four Steps of Project Control  

The project control process, like many other project management activities, is an iterative process repeated many times throughout the life cycle of a project.  Click each of the following buttons to read about the four steps in project.

Establish standards.

You are responsible for establishing the standards by which the project will be measured as well as the processes that define how the project will be executed.  This involves establishing key project control plans and the processes within each of the 13 WWPMM.  Remember, these are iterative processes that you need to continually update.

As the project manager, you are responsible for executing these four steps.  Regardless of the business processes that you follow, the project management processes are the same.

Observe performance

After you establish the plans, processes, and standards, you observe how the project is progressing.  In this step, performance information is collected from several sources,  including meetings, reports, briefings, letters, audits, and observations.

As the project manager, you are responsible for executing these four steps.  Regardless of the business processes that you follow, the project management processes are the same.

Compare planned with actual performance. 

When you have collected appropriate performance data on your project, you compare its current status with your standards and expectations. 

This step answers two questions:

How is the project doing?  And, if deviations from the original project plan have occurred, what caused the deviations?

Take corrective action. 

Finally, you decide what if any corrective action should be taken.  This step involves activities such as revising plans, reallocating resources, and changing the way the project is organized or managed.

If You Do Not Control the Project  

If you do not control the project, the scope of the project will increase.  This almost always adds cost to the budget and time to the schedule.  In addition, you will not know whether your project is on schedule. 

It is generally more difficult to meet a schedule than to move a schedule.  As a result, if you do not know that you are on schedule and are not focused on staying on schedule, chances are you will not be on schedule.

Poor control often also results in:

  •   Under- or over-allocating team members' work assignments 
  •   Supplier deliverables not being available when needed
  •   Dramatic decreases in quality
  •   Increased risk of failure

What Is a Project Control Book?   

The project control book (PCB) is a collection of project documentation that establishes the framework for controlling the project.  WWPMM defines the PCB as 'the organized folder, or set of folders, where the agreements, plans, procedures, and records supporting the project management system are kept, referenced, and cross-referenced, as appropriate, to help in retrieving the information needed at any point in time for project management purposes.'  In Integrated Product Development (IPD), the PCB is called the integrated project file, or IPF.

The Purposes of a Project Control Book  

The PCB helps you keep the project documentation up-to-date.  It is a central library of project standards and procedures and the output associated with those standards and procedures.  It provides a reference document of outputs used to measure project team performance and up to date information about the progress of the project.  It also defines a standard way to produce, issue, and maintain project documents.  The PCB becomes useful historical information, captures intellectual capital, and is required in some business plans.
The PCB is used as a basis for reviews and audits, as an information repository for team members, and as a tool for other project managers.  It is important that you have all the latest information and status in your PCB.

Contents of the Project Control Book 

To decide what should be in the project control book (PCB), start with the list of project management plans and procedures for your project.  This is an example of such a list:

  •   Project tracking and evaluation
  •   Financial management
  •   Progress reporting
  •   Risk management
  •   Supplier management
  •   Quality management
  •   Change management
  •   Issue and problem management
  •   Contract management
  •   Organization and people management
  •   Deliverables management

You do not have to include all these items in the PCB; in fact, because each project is different, you might not have all these plans and procedures, or you might have others.

When you have decided which plans and procedures to include in your PCB, list the outputs from each of those plans and procedures.  For example, if you include progress tracking procedures, progress reporting procedures, and financial plans in your PCB, you would also include their outputs.  The outputs from progress tracking might be updated schedules and time reports; from progress reporting, they might be contractual status reports and variance analyses.  From financial plans, they might be expense reports and financial reconciliation reports.  By including these in the PCB, you give everyone the latest view of the project.

Contents of the Project Control Book  (continued)

According to WWPMM, if your project uses the following work products, their outputs should be kept in your PCB.

Click each button to read the list of items for each work product.


  •   Action management procedure
  •   Change management procedure 
  •   Compliance incident management procedure 
  •   Continuous risk assessment procedure 
  •   Deliverable acceptance management procedure 
  •   Deliverable release management procedure 
  •   Internal compliance review management procedure 
  •   Issue management procedure


  •   Communication management plan 
  •   Financial plan 
  •   Human resource plan 
  •   Organizational breakdown structure (OBS) 
  •   Project decision structure 
  •   Project definition 
  •   Project management system summary 
  •   Project procedures description 
  •   Project quality plan 
  •   Risk management plan 
  •   Technical environment plan


  •   Project evaluation report 
  •   Quality review documentation 
  •   Situation analysis documentation 
  •   Supplier selection report 
  •   Team charter 
  •   Technical environment assessment 
  •   Project charter

Issue Management and the Issue Log

Problems and issues can affect the control of any project.  A problem is a cause for concern that is within the project manager's domain of control.  The project manager has the tools to fix a problem. 

An issue is more generic than a problem.  An issue is a cause for concern on a project.  Many issues arise during the course of a project.  Most of them are solved by the work team as part of their daily work or by the project manager.  Some issues, however, are beyond the scope of responsibility of team members and the project manager.  These issues affect the project manager's area of control, but the project manager lacks the necessary authority or tools to fix them.  A project manager must either escalate or delegate those issues to the area of control that can provide a solution.

  Each issue should be documented in an issue document, a WWPMM work product that describes the issue in detail and provides a complete history of its progression through analysis and resolution.  There is also a WWPMM work product for the issue log, which lists all the issues that occurred and required recording during the life of a project, including the owner, due date, and status.  Here is a sample issue log. 

Notice that each issue has an owner and a target date for completion.  In most cases, the best way to resolve an issue is to be sure the issue has an owner and a target date for completion.  At each status meeting, ask the owner to report the status of the issue.
The column labeled priority (p) helps you to prioritize the work.  Additionally, there is a date opened column.  This is for reference purposes, so that you can see how long the issue has been open. 
Issue control has much in common with change control.  Both processes involve documenting the change or issue, assigning responsible parties, and tracking the change or issue through to resolution.

How to Control the Project

Follow these general guidelines for controlling your project and monitoring your project plans on a day-to-day basis:

  • Focus your analysis on one cycle back and three cycles forward.  For example, look one week back and three weeks forward.
  • Identify all the work that has been completed.  Support the people who are doing the work, and make them feel like a valuable part of the team.
  • Evaluate the work that will be starting.  Ensure that the owners know and agree that their work can start on time.  
  • Evaluate work that is almost due for completion.  Check with the owners to ensure that the work is on target. 
  • Evaluate trends and other data that supports the owners' opinions.
  • Evaluate work that is late starting or completing.  What are the effects on the schedule and budget?  What actions can you take to lessen the negative effects?  Who should be responsible for each action?
  • Always ask for updated estimates for the completion of tasks.
  • Conduct regular project status meetings with your teams to discuss the schedule, status, dependencies, issues, and concerns.  Also discuss the risks, and review the risk plan periodically.
  • Document the minutes of each of these meetings.  Post them in the PCB.
  • Track issues using issue documents and the issue log.  Keep all the issue documentation in the PCB.
  • Always execute the change management process if changes are requested.
  • Track the actual costs against the budgeted costs on a weekly basis if possible.  Keep current.
  • Conduct project reviews as required.
  • Communicate the overall project status regularly to your team so that they know what is happening around them.

Tracking and Controlling Risk  

After you analyze the risks and assign actions to mitigate them, you must track the risks and keep the risk plan current to control them.  This might result in adding, changing, or removing containment actions.
The project manager and the team must:

  • Implement and track the risk management plan.  
  • Communicate the risk management plan status to the team members and other stakeholders.  Be sure the plan is made clear to the sponsor and to the reviewers during project reviews 
  • Review the risk triggers.  Have any of the risks occurred?  
  • Reassess risk sources on a regular basis.  Are there new risks resulting from changes in the sponsor's technology, project, organization, or resources?  If so, update the plan with the new risks.  
  • Evaluate the defined risks to decide whether they are still possible, whether they will have the same severity, and whether the tolerance is the same.  Does the plan need to be updated?  Does additional action need to be taken?
  • Review the risk contingency reserve and ask whether the plans are still appropriate?  Is any action required based on observed trends?  Are backup strategies appropriate?
  • Review risk mitigation strategies to determine if they are still appropriate.   Determine whether backup strategies should be used or if additional actions are required to implement the strategies.  Does the plan need to be updated?
  • As time passes, you might need to consider that some risks, previously considered non-issues, might become issues, while others, previously  deemed significant, might become insignificant.  Do you need to update the plan?
  • If a risk event occurs, you might need to make appropriate changes to the  work breakdown structure (WBS) and the schedule.
  • Maintain current, accurate, and complete documentation, and disseminate it to the appropriate stakeholders.  Documentation serves as a record of lessons learned and actions taken, and as a means of communication.

Risk tracking and control is a PM subdomain in the Risk Management PM domain.  For more information, go to the WWPMM Web site.

Reacting to Risk  

Reacting to a risk includes executing the necessary risk responses and closing the risk as appropriate:

  • Reacting to a risk occurrence means taking the steps that must be performed when a risk actually occurs.
  • Closing a risk means reaching a final resolution concerning a risk that either has occurred or is no longer considered a significant threat to the project.


A metric is a tool for measuring the progress of a project.  The primary purpose of a metric is to enable you to monitor and communicate project status. 
There are no standard metrics that apply to all projects.  You must determine your sponsor's preferred metrics and choose the most appropriate metrics for your project. 
Metrics must relate to something that can be tracked and measured.  In most cases, you will be measuring actual results and comparing them with planned results; for example, measuring test cases actually completed and comparing them with test cases planned to be completed by this time.
Good metrics must have other characteristics too.  They must be planned for, they must span the life of the project, and they must be understood by the sponsor, the team, and the project manager.  Some examples of metrics are:   

  • Planned versus actual resource utilization
  • Earned value, which compares the actual work done with the planned work and the actual cost with the planned cost
  • Planned versus actual defects
  • Planned versus actual task starts and finishes
  • Planned versus actual schedule milestones
  • Planned versus actual technical control points
  • Planned versus actual revenue
  • Planned versus actual cost
  • Planned versus actual deliverables 
  • Planned versus actual quality trends
  • Planned versus actual consumable resources used

Earned Value Analysis  

Project managers are constantly looking for methods or tools that will provide specific, timely, and accurate project information to support their decisions.   Earned value is one of the methods for gathering such information and monitoring a project's performance.  It serves as an indicator of project status, and helps determine the project's progress.  The term itself refers to a specific measurement, the budgeted cost of work performed.

Earned value analysis is the process of comparing, in terms of earned value, the project's actual performance against its planned performance.  It can be calculated in hours or in dollars, and it can be calculated cumulatively or used to measure subprojects individually.

Earned Value Terminology

Earned value has its own vocabulary.  One way to understand and remember its terms is to think of them in relation to the questions that often arise in project management and review.  Earned value measurements are designed to answer such questions.

The Earned Value (EV) is the amount of work actually accomplished, stated in terms of the budget assigned to accomplish that specific scope of work.  EV answers the questions, How much has been accomplished against plan? or How much work has been performed and verified?  PMI's old term for EV was Budgeted Cost of Work Performed (BCWP).

The Planned Value (PV) refers to the costs that should have been incurred for the work that should have been completed to date.  The PV answers the question, What is the planned cost?  The PV must be established before the EV can be meaningful.  (To use earned value correctly, the PV, and therefore the dollar amounts, must be allocated across the project's WBS, with dollar amounts associated with WBS elements.)  PMI's old term for PV was Budgeted Cost of Work Scheduled (BCWS).

The Actual Cost (AC) is the total cost incurred for the work accomplished during a given period of time.  AC answers the question, How much did it really cost to perform the work?  The AC can be higher than the EV if there are more resources applied to a task than planned, or if a task takes longer than planned. PMI's old term for AC was Actual Cost of Work Performed (ACWP).

Senior management personnel are concerned with facts and how they are interpreted.  It is important to make sure the work is actually completed.  Project managers often make the mistake of saying, 'I'm 90% complete.'  By focusing on PV, EV, and AC, you can avoid such pitfalls.

The following measures are used in earned value forecasting to predict the costs at the end of the project based upon the currently available information:

Budget at Completion (BAC) is the estimated total cost of the project at completion, or what the project should cost if your planning is accurate.  It answers the question, What is the baseline cost of the project?  Notice that the BAC is the sum of the PV.  Be aware that events sometimes occur that disrupt your plan and either decrease or increase the BAC.
Estimate to Complete (ETC) is the projected cost to complete the project from a specified point in time.  It answers the question, How much will it take to finish?  Establishing an ETC needs to be determined periodically after establishing a BAC.  The same data, analysis, and investigation that are used to establish the BAC are required for an accurate ETC.  The only differences are that the starting point for the ETC has moved forward in time and more data is probably available.

Estimate at Completion (EAC) answers the question, 'What will it cost when it is finished?'  Calculating the EAC requires two data points: the AC and the ETC.


A Pictorial View of the Earned Value Components

The following graphic shows, you can see how the Planned Value curve in green compares to the Actual Cost curve in blue and the Earned Value curve in red. The goal is to have the Actual Cost curve and the Earned Value curves both match the Planned Value curve.  In this example, you can see that at the end of the first month, the Earned Value (actual work completed) was below the Planned Value, and the Actual Cost was above the Planned Value.  This graphic clearly shows that the project is behind schedule and over budget.

Earned Value Analysis  

Earned value is a key indicator of overall project status.  It facilitates an objective assessment of variance between plans, budgets, and performance and enables a common understanding of the amount of work actually completed.  Earned value is a moment-in-time metric.
Researchers have found that two of the components of earned value, schedule variance and cost variance, are valid indicators of performance after 20% of the project is underway.  At that point, these two metrics can give you an accurate total picture of the project.
Both schedule variance (SV) and cost variance (CV) are used to pinpoint  potential project problems, which can then be investigated further.  Positive numbers are generally good and negative numbers are usually bad.  A positive SV means the project is ahead of schedule; a positive CV means the project is under budget.  Be aware, however, that these indicators cannot isolate activities on the critical path.
SV answers questions like, What is the difference in value between what was accomplished and what was scheduled?  The formula for SV is:
SV = EV - PV

Notice that EV is used in the equation.  In real life, SV is a reflection of what has been accomplished, the EV; versus what was planned, the PV.  It does not, however, consider what has actually been spent.

If the SV is positive, then more work has been completed than what was scheduled, and the project is ahead of schedule. 

If the SV is negative, then more work was scheduled than has been performed, and the project is behind schedule.

The Cost Variance (CV) answers the question:  What's the difference in value between what was accomplished and what was spent to do it? 

The formula for CV is:

CV = EV - AC

Again, notice that EV is used in this equation.  CV is a reflection of what has been accomplished, the EV;  versus what was actually spent, the AC.  It does not consider what was planned to be done.

If the CV is positive, then the costs were less for the actual work than what was budgeted, and the project is under budget.

If the CV is negative, then the costs were more than budgeted for the work actually accomplished, and the project is over budget.

Percent Complete is a measurement that compares the value of the work accomplished with the total amount of work that needs to be done.  The formula for Percent Complete is:

Percent Complete = EV / BAC
Percent Spent is a measurement that compares the money that has been spent with the total amount of money available.  The formula for Percent spent is:

Percent Spent = AC / BAC

Delivery Organization Benefits are Being Realized Key

The delivery organization manages and completes the work on the project.  It includes groups from IBM and any of the client's staff working on the project.  A successful project will reflect well on the customer's staff, too, and lead to new opportunities.  Profit is just one aspect of this key.  Other aspects include IBM's reputation in the marketplace, the ability to perform future projects more efficiently, and staff development.

Here are some criteria for assessing the Delivery Organization Benefits are Being Realized key.

  • The project will help the delivery organization's reputation.
  • The project will help financially;  billing and collections are current.
  • The project will help team member's careers.
  • The project will contribute to the organization's knowledge and lessons learned.

Besides the earned value analysis, look for these signs:

Healthy Signs

        People feel they are learning.

        People are willing to invest in the project.

        Good press is being created.

Unhealthy Signs

        Good staff members are not available.

        Negative remarks about performance.

Why Is Tracking so Important?  

Methodical tracking of projects is the only way I can keep my projects on schedule.  I have to know what's happening so that I can anticipate the problems before they impact my project.  I have weekly status meetings where we discuss the status of the project compared to the plan and review all the issues and concerns.  I document the issues and track them through resolution.  That's the only way I can be sure each issue gets resolved in a satisfactory manner.
Another tool I use is earned value.  I think it's difficult to know if I'm on schedule.  If the project makes its first milestone on time, I know only that the milestone is on schedule.  But what about all the other activities that are happening at the same time?  By using financial measurements like earned value, I can see what areas are behind or ahead of schedule and where I'm overspending.  I know how much money has been spent, and I can calculate how much money I should have spent.  It's a great tool for getting an objective view.
As a project manager, the worst thing that can happen to me is that I get surprised.  If there's a problem that I wasn't aware of and I didn't make the appropriate changes to mitigate it, it will impact the cost, scope, or schedule of the project.  I need to understand what's happening on the project so that doesn't happen.


Remember, even good projects are not green on all keys all the time.  But successful projects always address their project health issues promptly and effectively.  On the other hand, poor projects generally have one or more keys go red early, and then stay red for the rest of the project.

Points to remember about the Seven Keys: 

  • Do not complicate the Seven Keys.  They are meant to be a simple communication tool.
  • Even a few hours implementing the Seven Keys makes a positive impact.
  • With practice, everything about project or program health is related to the Seven Keys. 

Points about using the Seven Keys:

  • Complicated equations or templates are not needed.
  • An understanding of terminology and using some simple forms is needed.
  • The project manager needs to be comfortable asserting the true project status and the corrective actions needed to ensure success.

Project management review

Project management reviews help ensure that a project is progressing on schedule, and within budget, and is meeting the requirements.  A project management review can indicate if and where a project is in trouble.  There are different kinds of reviews, but here are the kinds of topics that are typically covered:

  • Project overview
  • Highlights of project accomplishments
  • Plans for tracking your project
  • List of project-related risks and problems
  • Objective assessment of the health of the project

Why Conduct Project Management Reviews? 

Project management reviews provide opportunities for you to report project schedule and budget status, highlight project accomplishments, identify problems, escalate issues, and elicit management support.  The main purpose of a project management review is to provide general guidance to you as the project manager with an objective assessment of a project's health.  Reviews should be conducted by an independent group of skilled reviewers outside of the project who can view the project objectively.

Different Types of Project Management Reviews

Different types of project management reviews are held based upon the timing of the review.  Project review types are:

  • Contract readiness review.  Some business units hold this type of review within two to eight weeks after the contract is signed.  Other organizations complete a contract readiness review later in the cycle or do not require one at all.
  • Periodic review.  Some business units hold this type of review every three to six months.
  • Completion review.  This is a project management review that is completed at the end of the project.
  • Special review.  This type of review is held when there appears to be a serious problem or when the project manager has reason to request one, such as when there has been a project management turnover.    
  • Compliance review.  This review ensures that policies and procedures are being followed by the project and identifies improvements that can be made to procedures.  Compliance reviews might be conducted by an IBM organization, external to the project, by the sponsor, or by an outside body.
  • Deliverable review.  This is a review of a deliverable or key component.  The review is held before the deliverable or key component is released to the sponsor to ensure that no open items remain and that delivery is appropriate.

In addition, WWPMM  defines the following types of health reviews:   

  • Business reviews.  This type of review focuses on financial and business exposures.
  • Project management reviews.  This is a review that focuses on the planning and control aspects of the project.
  • Technical reviews.  Technical reviews focus on the technical aspects of the project, including work products,  deliverables, and subcontractor reviews.  This review covers areas such as traceability of requirements, architecture, and technology competitiveness.

As the project manager, you must not rely totally on prescribed reviews but should exercise judgment in determining which reviews are necessary and when they should be held to make the project a success.

Decision Checkpoint Reviews in IPD Projects

Integrated Product Development (IPD) is part of the Decision Checkpoints (DCPs) process.  Although the IPD community does not have a quality assurance (QA) organization, they are still required to execute QA tasks.  DCPs are structured project reviews with specific entry and exit criteria that measure the progress of an IPD project.  DCPs are held, in some cases, as a baseline review.  DCPs are conducted at the following points in a project's life cycle.

Reviews in the CRM Project Management Process

Global Services has a QA organization that conducts project reviews at the following points in a project's life cycle.

QA Process During Solution Design

The QA process starts during opportunity management and continues through proposal development ending with price release. 

The steps are:

  1. Preliminary Risk Assessment
  2. Performed by contract owner
    - Solution Assurance QA1
    - Business Assurance QA2
  3. Performed by service providers
    - Proposal Assurance QA3
  4. Management Review and Approval

Reviews in the CRM Project Management Process  (continued)

Global Services has a QA organization that conducts project reviews at the following points in a project's life cycle.

QA Process During Solution Delivery

Project management and delivery conduct reviews.  The steps are:

  1. At Start:  Contract Readiness Review QA4 
  2. At 2 Months:  Initial Project and Plan Review QA4
  3. Each interium PRM 3-6 Months depending on health
  4. Completion PMR
  5. Solution and Deliverable Readiness Reviews #1 through #N QA6

Topics You Should Cover in a Project Management Review  

Before the review, you should make arrangements with the review team leader to set the schedule for the review.  Typical activities to plan for a smooth review include: the project manager's presentation, interviews with key project members (including subcontractors), interviews with key customer project team members and the project sponsor, project documentation analysis, and review debrief with the project manager.
In the typical project management review, you have an opportunity to present your view of the project at the beginning of the review.  You should cover the following topics that overview:

  • Project overview.  This is where you can orient the review team to your project scope, objectives, major milestones, customer organization, project staffing (including subcontractors), and planning baselines.
  • Highlight project accomplishments.  This is a great opportunity for you to describe all the good things that are happening on your project.
  • Give an overview of the project management processes you are following.  This is where you can describe the plans you have created and are using to track your project and what tools and methodologies you are using on the project.
  • Identify project-related risks and problems.  This is your list of the risks and problems with the actions that you are taking to mitigate the risks and solve those problems.  Also, report the results of any earlier project management reviews or solution or deliverable reviews and the status of their  associated action plans.
  • Provide an objective assessment of the health of the project.  Here you get to tell the reviewers how you think the project is going.  Be objective.  Keep in mind they are going to talk to several other people and go through your documentation; they are not just going to take your word for it.  

Key Questions to Answer  

In the project review process, the key question is, Where are you?  The reviewers want to understand where you are today.  There is also a need to look forward, to predict the future.  You can do both of these by using the earned value (EV) indicators to determine where you are relative to the budget and the schedule today and where you will be at the end of the project.  EV  status and predicting indicators are detailed in Module 9, 'Change Management.'
The following key questions help to determine the health of a project.  The EV status indicator or EV predicting factor associated with each question is included.

  • Where should the project be today?  This indicates the planned value (PV).
  • How much has been done?  This indicates the earned value (EV).
  • How much has the project cost as of today?  This indicates the actual cost (AC).
  • How much will it take to finish the project? This indicates the estimate to complete (ETC).
  • What will the project cost when it is complete?  This indicates the estimate at completion (EAC).

Some of the other key areas that the reviewer will want to investigate are risk management and change control.  Reviewers want to examine your risk management plan to be sure you are keeping it updated and implementing the mitigation plans.  They will also want to examine your change control process and evidence that you are using it and following your process.

The Review Findings   

After the reviewers have reviewed the documentation and talked to the team members, they will want to analyze the information and prepare a report of the findings.  The reviewers might prepare the report on the same day as the review or they might leave and send you the report later.  You are expected to establish a plan to address any concerns or problems noted in the report.

Avoiding Problems  

Troubled projects have a significant impact on IBM's profitability and extensive negative impact on the IBM reputation for high customer satisfaction and quality service.  The most frequent and common denominator in troubled projects is the IBM proposal and the performance team's failure to understand and follow IBM internal processes and guidelines.  Projects also break down because of failure to follow project management discipline procedures, not because of the inability to resolve the technical problems.
By following the steps in the IBM Global Services Worldwide Quality Assurance Management Discipline (WWQA/MD) procedures, you can identify and avoid many potential problems.  Available documentation supporting the implementation of WWQA/MD can be found on the Quality Assurance Web site.
The Prevention Measures to Avoid Troubled Projects white paper contains a description of root causes of troubled projects that are frequently encountered, along with suggested prevention measures.  The white paper links the root causes of troubled projects to various categories or project phases, such as organizing the project or risk management.  The white paper is based on the findings of project management reviews and on the analysis of troubled projects.  The following attachment is the Prevention Measures to Avoid Troubled Project white paper.
You can access this white paper from the Quality Assurance Web site.

Seven Keys to SuccessTM

Suppose you are asked to review two projects. 

  1. The first project is 11 months into a 12 month implementation, and the Seven Keys Heads up Display (HUD) is green for each key. 
  2. The second project has a HUD with an assortment of red, yellow and green, is only 3 months into its 12 month schedule, and is asking the Steering Committee for more funding. 

Which project are you most interested in reviewing?

The first project.  With its HUD all green, it is likely the HUD is not telling the whole truth and there are surprises to be revealed.  In the second project, the problems are visible and are being dealt with.

The Value of Independent Project Management Reviews

As a project manager,  I look at project management reviews as an opportunity to show my
peers what I am doing, to learn something, and to get some help where I need it.  I don't have
the opportunity to compare notes with my peers very often, and project management reviews
give me that opportunity.  When I review the project management review findings, I always
learn something new.
Project management reviews are also a great opportunity to get some support to help me solve problems I might have that cannot be solved any other way.  Don't wait for external QA reviews to report urgent problems!  On one of my projects, I could not get the skilled resources I needed; they were not available.  After QA identified the lack of resources as a problem, the priorities were changed and I was able to get the resources I needed.
Preparing for the project management review takes time.  But the preparation is usually updating documents that should have already been updated, getting those final approvals, or filing the latest status reports.  All of that work needs to be done anyway, and the project review just forces it to be done sooner.

Project Closeout

At some point, every project comes to an end and either succeeds or fails.  The process of closing the project ensures that a number of items are addressed and completed as part of the project life cycle.

Completing these items is not simply housekeeping, but a process that is critical to providing good documentation for use in future projects.

When closing projects, remember these steps:

  • Review all the project documentation and agreements for the project to ensure that they are complete and that all the commitments have been met.
  • Review the project to identify lessons learned and intellectual capital.

When Is a Project Closed?  

Just as views differ about the project life cycle in IBM, different opinions exist about when a project comes to closure.  For example, in the Brands business area, a project is considered finished when the product is withdrawn from the market.  In the Services business area, a project is considered finished when all contractual commitments have been met, the sponsor has accepted the delivered system, and the agreements with the sponsor and the suppliers have been closed.
Sometimes, closing the project can be quick and straightforward.  Other times, it can be a long, extended process.  In many Services projects, the sponsor is reluctant to let IBM close the project because the sponsor has concerns about  running the system.  Sponsors typically want to retain the IBM delivery team and the suppliers for as long as possible.

Actions Required for a Successful Project Closing  

Closing the project is the process of reviewing all the documentation and agreements for the project to ensure that they are complete and that all the commitments have been met.  Closing the project also includes reviewing the project to identify lessons learned and the intellectual capital that should be documented for others' use.
The following figure is from the WWPMM work pattern, C3: Manage end of project, in the Closing work pattern group.

The purpose of closing a project is to ensure that each of the following items has been completed:

  • All the project commitments have been met and the documentation has been updated.
  • The intellectual capital has been identified and documented.
  • The technical environment has been released. 

The customer satisfaction survey has been completed by the customer or the sponsor.

The lessons learned have been collected and documented, as part of the project evaluation report.

The sponsor agreement has been closed.  

Project Closing Terms 

The following terms relate to closing a project.

Administrative closure is generating, gathering and disseminating information to formalize project completion. In the administrative area, all the project documentation must be completed and sent to the appropriate reciepients. IN addition, all the assets must be either returned to their owners or nominate as candidates for the Intellectual Capital Management database.

Closure documentation is communication between the sponsor and the delivery organisation or between the delivery organisation and a sipplier that acknoledges the agreement id complete. Closure documentation provide evidence that all terms of the agreement have been satisfied and all work has been completed.

The project evaluation report is a document created at the end of the project that highlights key points to be gleaned from the project, including lessons learned, intellectual capital and reusable materials.

Project Closing Activities

Project closing activities must be planned and budgeted much as they are in other phases of the project life cycle. 
The major closing activities are:

  • Reviewing the agreement and the project documentation to confirm that all project deliverables have been met  
  • Formally closing the project with the sponsor and the suppliers
  • Preparing a project evaluation report 
  • Releasing staff and technical environments
  • Releasing suppliers

Questions to Ask at the End of a Project

Questions that you should ask at the end of the project include the following.  Of course, many of these items should be an ongoing focus throughout the life of the project.

  • Have all required products and services been provided to the sponsor?
  • Have all actions related to contract changes or revisions been concluded?
  • Have all contractual issues been settled?
  • Have all ongoing maintenance requirements been addressed and agreed to?
  • Is documentation in place that adequately shows the receipt and formal acceptance of all contract deliverables?
  • Has property or information provided by the sponsor been returned?
  • Has the final invoice been submitted and paid?
  • Has the project file been updated and is it completely up to date?
  • Have you gathered lessons learned from the sponsor, suppliers, and your teams?
  • Has the project team determined whether any project material should be nominated for inclusion in IBM's Intellectual Capital Management (ICM) database?
  • Has a sponsor satisfaction survey been conducted?
  • Have the technical environment elements been released?

Documents Required for a Successful Project Closing

To close a project, you should collect updated copies of the sponsor and supplier agreements, any amendments to the agreements, the latest project status reports, and the asset inventory for the project.
After this information is collected, you and the members of your team who have not yet been released from the project should prepare the project evaluation report and oversee the release of the project assets from the asset inventory back to the asset owners. 

The project evaluation report contains the following sections:

  • Project Summary
  • Lessons Learned (what did and did not work)
  • Intellectual Capital

The project evaluation report generally applies to the overall delivery project, but it can be created at any level in the project organizational breakdown structure (OBS).  
This report is typically created at the end of the project by the project manager.  However, it can be created at any time during the execution phase.  For projects of long duration, it is recommended that the project evaluation report be created at the end of each phase of the project or conclusion of a major milestone.  
You create the project evaluation report by soliciting feedback from various project stakeholder groups, such as project team members, the sponsoring organization, suppliers, or IBM management.  Review findings and project  documentation can also be useful sources of input. 

Project Manager's Responsibilities  

You, as the project manager, must focus on the following closeout responsibilities:

Assess the terms of agreement and the completion of all commitments.

  • Review the terms of the project plan and the sponsor agreement and verify the completeness of all deliverables and the currency of all documentation.  
  • Verify that all supplier agreements have been fulfilled and closed.
  • Verify the satisfaction of post-delivery commitments, such as readiness to fulfill warranty and support obligations.

Release the technical environment.
Identify and release technical environment elements, such as office space, computer installations, and related software.  Equipment or space needed for warranty support can be left in place after the project closes.

Obtain sponsor feedback.
Obtain information about the sponsor's areas of satisfaction and dissatisfaction, then document this information and use it as input to the lessons learned.

Assess the lessons learned.
Determine the key lessons learned on the project, document them, and suggest improvements for future projects in the project evaluation report. 

Close out the sponsor agreement.
Perform the administrative closure of the sponsor agreement.  This includes generating, gathering, and disseminating information to formalize project completion and closure.

Submit the intellectual capital.
Submit all intellectual capital generated on the project, including lessons learned, the WBS, project definition reports, and any other related documentation to the ICM AssetWeb.  Current and future projects will benefit from your experience.

Final Project Meetings and Reviews  

Final project meetings and reviews include:
Project review.  Conduct a project review with the sponsor shortly before the project ends to ensure that:

  • All contractual obligations have been met by the supplier to IBM and by IBM to the project sponsor
  • The project sponsor formally accepts the project as being complete
  • All assets on loan to the supplier or the sponsor have been returned
  • Everything is ready and in place to close the project 

Lessons learned meetings.  To identify key lessons on the project, conduct lessons learned meetings with the internal team, the sponsor, and your suppliers.  How to conduct lessons learned meetings is discussed in the 'Lessons Learned' topic of this module.   

Final internal review.  After the project is closed, conduct a final internal review of the project to identify and submit any intellectual capital developed on the project.

Documenting Lessons You Have Learned

Lessons learned on a project are very valuable to delivery team members and members of current or future project teams.  It should not be necessary for every project manager to make every mistake.  A database of lessons learned can help project managers learn from each other's experiences.
This information is documented in the project evaluation report, which becomes part of the organization's historical database for the project.  Accessible to other project managers, a lessons learned list is a valuable tool in any organization.
Lessons learned are not necessarily negative.  They can describe a way to do something better, faster, or more efficiently.  You, as the project manager, should document lessons learned as soon as possible after the lesson is experienced, while the memory is fresh and most likely to be accurate.  When deciding what to document, remember that the lesson:

  • Should be relevant to other projects
  • Must be in the right context, so that the person reading it can understand the environment in which the lesson was experienced and who was involved
  • Should include enough detail to make it understandable and to allow the reader to appreciate the full set of circumstances

Examples of Lessons Learned  

A few examples of lessons learned are:

  • Clearly defined, understood, and agreed-to requirements are key for a successful project.
  • The project team must fully understand the commitments before implementing the formal agreement.
  • Timely involvement by IBM procurement is crucial.
  • Understanding the customer's organization, and who the official and unofficial decision makers are, is key to project success. 
  • Executive management support for a project is key to project success.
  • Provide a long lead time for resource procurement.
  • Sponsor-supplied staff is not always the best or the most productive.
  • Multiple project managers on a project can lead to problems unless the transition from one project manager to the next is carefully managed.
  • Internal projects are as challenging as, or even more challenging than projects with external sponsors.

To make these lessons more relevant and of true value, expand on them.

Gathering Lessons Learned 

Start gathering and documenting lessons learned from the beginning of the project.  At the beginning of the project, identify and document the lessons that you hope will be learned from the project and the intellectual capital that should be created.  These might include:

  • The effectiveness of policies, procedures, processes, standards, methods, and tools used on the project and how they can be improved
  • The effectiveness of the sponsor interface and how it can be improved
  • The effectiveness of the relationship with suppliers and how it can be improved
  • Opportunities for improvement in skills and procedures
  • Lessons learned that should be passed to future projects

Lessons learned should be recorded as soon as possible after the lesson is experienced.  As the project proceeds, you should keep an ongoing list of lessons learned so that you will not lose any.  In addition, you should solicit inputs for lessons learned from delivery team members, suppliers, sponsors,  and key stakeholders.

It is very effective for all of the project managers to share their lessons learned in a respository that is accessible to everyone.  There is no reason why all the project managers need to make the same mistakes. 

Conducting a Lessons Learned Session

Toward the end of the project, conduct a lessons learned meeting.  The output of the meeting will be a list of the lessons learned for inclusion in the project evaluation report.
Invite all the participants on the project.  Ask each to bring a list of what went well, what did not go well, and lessons that each learned.  On some large projects, you might want to conduct multiple meetings or a separate meeting with the suppliers and another meeting with the IBM team. 
The following is a sample agenda that works well. 

  • What went well on the project?  Why did it go well?
  • What lessons were learned from what went well?  
  • What did not go well on the project?  Why did it not go well?
  • What lessons were learned from what did not go well? 
  • Presentation of the lessons learned that you documented during the project

The ICM Knowledge Management Process  

The purpose of knowledge management is to leverage global intellectual capital to IBM's competitive advantage.  As a project manager, knowledge management can:

  • Provide you with intellectual capital that will help you meet your customer's expectations and complete a project on time and within budget
  • Provide you with access to project management subject matter experts, who act as a resource for you throughout a project
  • Assist you in maintaining and enhancing your professional currency by accessing current thought leadership and sharing your knowledge through participation in sharenets, forums, and other Project Management Knowledge Network (PMKN) activities

The PMKN is a community dedicated to leveraging the body of knowledge to achieve efficiencies and effectiveness in project execution.  Intellectual Capital Management (ICM) is part of the total knowledge management process.
In the ICM process, IBM project managers identify reusable products, processes, and lessons learned on a project and submit them, normally during project closing, with submission forms to the ICM AssetWeb, an IBM Global Service centralized system for knowledge sharing, collaboration, and intellectual capital management. 
Adding intellectual capital to the ICM AssetWeb is very important.  Reading and using the information is just as critical.  By using the information already provided, you can improve your project management skills and learn ideas for improving your project.  Access the information in the ICM AssetWeb as you start each new project and whenever you have a question or issue needing the ideas of others.  The probability is high that another IBM project manager in a similar or related project experienced the same issue and documented the actions taken to solve it.
Ensure that the material you submit as intellectual capital is also documented in the project evaluation report for your project.

What Is the ICM Database?  

The ICM database is owned by IBM Global Services.  It is a Lotus Notes team room that can be accessed from Lotus Notes through a portal or a Web site.  To access the database using Lotus Notes, you must be a registered user or be an IBM Global Services employee.  To access it through the Knowledge Network portal, you do not have to be registered nor do you have to be an IBM Global Services employee.
The ICM database is divided into knowledge networks, which are called subcategories in the portal.  All the intellectual capital relative to project management is located in the PMKN.

Instructions for Accessing the Project Management Knowledge Network

You can access the PMKN through the ICM AssetWeb.  Instructions are available at the PM/COE Web site or at the knowledge portal for conducting searches and submitting material. 

To access the PMKN from the PM/COE Web site:

  1. Go to the PM/COE Web site at
  2. From the left navigation panel, click Communities and then click PM Knowledge Network.
  3. Follow the instructions to access the ICM AssetWeb navigator.   

To access the PMKN through the knowledge portal:

  1. Go to the knowledge portal at
  2. Click the category Intellectual Capital and Assets.

Seven Keys to SuccessTM

When gathering lessons learned, it is a good idea to review your Seven Key HUD status reports. 

  • Ask yourself why did a key go red? 
  • What was the corrective action you took? 
  • Was it as successful as you had planned? 
  • Would another course of action been better?

The Seven Keys can help you learn from your mistakes so your next project will run more smoothly.

Documenting Your Lessons Learned  

The pilot for the training subproject has been completed successfully.  The pilot completed with $30,000 over budget, but only two weeks later than planned.  The software vendor was also two weeks late, so the overall project schedule was not affected by the late pilot. 
The executive director has accepted the training course because of the positive comments he received from his staff, who are now using the course as the system is being rolled out. 

Your Assignment  

It is time to document the lessons you have learned on this part of the project.  As a student going through this case study, what did you learn that you will use on the job?  One example might be to use the WWPMM work product for the Project Definition document for your next project or perhaps do a complete closing on your current project.  Create a list of six to eight lessons learned.


No attachments exist for this assignment. 

Check Your Work  

No 'Check Your Work' assignment solution exists for this module.

Why It Is Important to Close the Project
If your project is not closed properly, significant legal, warranty, asset management, and financial implications to IBM can result.  Closing your project  is the final step in what everyone hopes has been a successful project.
I once had a project that I never took the time to close.  I had moved on to the next project and felt I did not have time to do what I considered 'paperwork.'  I had not verified that the commitments had been met, and I did not update the documentation.  As a result, that project haunted me for months.  The customer felt that the project had not ended, and continued to call me constantly to ask for things.  As time passed, it became increasingly difficult to remember the agreements and status of the project.  Because I had not taken the time to update the documentation, I did not have the documentation as backup when I needed it.  What had been a very successful project became a nightmare.  The customer grew increasingly unhappy. 
Donít forget the Delivery Organization Benefits key.  I believe significant benefits are realized from gathering and documenting lessons learned.  When I am getting ready to start a new project, I go through the lessons learned that our team has accumulated for the last several years.  Every time I do, I find something that I can use to make this new project better.  Most of the time my findings are simple suggestions that helped clarify an issue.  A terrific example, one that served me well at one point on a project, was to ensure that the sponsor and the other vendors were using the same word processor to facilitate review of project documents.  Although this compatibility had already been specified for my project, seeing the same information in a lessons learned reminded me to ensure that this compatibility was properly addressed.
When closing the project, take care of your good people.  Recommending awards or having a final thank you celebration can make a team feel good and more willing to work for you again.  A good project manager knows the importance of locating and keeping employees with good skills.  Do not lose team members to another project manager who has been more appreciative.  Whenever I make an effort to say thank you to my team, I find them willing to work with me again. 

Project management tool suite

IBM project management toolsuite

IBM rational protofolio manager is IBMís strategis tool for enabling enterpride project management. It is a Web-enabled tool with a common repository that supports key project management activities for all stakeholders

Project Control BOOK (PCB) is a Lotus Notes-based tool for storing, accessing and managing project management work products.

GS Risk is a risk management roll that has been designed specifically for IBM internal use.

Program Operations Support Tool (POST) is a program management tool., A program is a group of related projects and other activities managed in a coordinated way to achieve a common long-term objective.

Engagement Support Environment (ESE) is a Lotus Notes tool that automates the use of IBM Global Service Method.

DocumentFactory (DF) is a tool that facilitates creation of standardized documents in the Lorus WordPro and Microsoft Word formats.

IBM Rational portofolio manager documents, status reports, financial data, project exceptions, expense reporting

Project control book

GS risk

Program operations support tool (POST) is the concept of program management

Engagement support environment


Politica de confidentialitate



Vizualizari: 3571
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2019 . All rights reserved

Distribuie URL

Adauga cod HTML in site