6th Edition PMBOK® Guide–Process 5.1 Plan Scope Management: Tools & Techniques

This post will discuss the tools and techniques involved in the Plan Scope Management Process.   When you have a decision-making process, like you do in most planning processes like this one, the key tools & techniques are going to be

  • expert judgment (these are the people that will help you make decisions)
  • data analysis (these are the techniques that will help you make the decisions)
  • meetings (this is the forum in which you will make the decisions)

This process is like others, and has these three tools & techniques.   Let’s take a look in a little more detail:

5.1.2 Plan Scope Management:  Tools & Techniques  Expert judgment

In particular, those individuals that have experience on previous similar projects should be consulted in creating the scope management plan.  Data analysis

A particular data analysis technique used in this process is alternatives.   There are many requirements that will be discussed; how will they be achieved?   There may be more than one way to achieve a certain requirement, and after brainstorming for alternatives, then the decision becomes which of the alternatives the project will pursue.   That is where alternatives analysis comes in. Meetings

Of course, any decision-making process requires a meeting of the minds because the problem is too big for any one person and their individual perspective to solve.   The people that should be attending, besides the project team of course, are the sponsor and selected stakeholders, and any other individuals who are responsible for scope management processes in the organization.

These are the tools and techniques used in this process; the next post will cover the outputs, the main one of course being the Scope Management Plan.


6th Edition PMBOK® Guide–Process 5.1 Plan Scope Management: Inputs

Before I go into the inputs for this first process in the Scope knowledge area, let me go over some key concepts that are described on p. 131-133

Product scope vs. project scope

The product scope refers to the features and functions that characterize a product, service, or a result, whereas the project scope refers to the work performed to deliver that product, service, or result.

Life cycle–predictive and adaptive

The life cycle is the approach you take when planning and managing the scope of the project. A traditional or predictive life cycle is, as the name implies, one where the scope is defined at the beginning of the project.   In an adaptive or agile cycle, the overall scope is decomposed into a prioritized set of requirements (the product scope) and work to be performed (the project scope) called the product backlog .   At the beginning of each iteration, the team will work to determine how many of the highest-priority remaining items on the product backlog can be determined during the next iteration.

Another important difference between the predictive and the adaptive life cycle is the  process of Validate Scope.   This is the process where the customer is shown the deliverables and formally signs off and approves them.   In a predictive life cycle, this is done at the end of the project when the final deliverable is completed, whereas in an adaptive life cycle, it is done at the end of each iteration.


Project management is increasingly focused nowadays on the management of stakeholder requirements.   Business analysis is the role that comes up with business requirements, and although a project manager may not have to create documents such as the business case, it is important than the project manager understand them.   Why?  Because if conditions change such that the assumptions embedded in the business case are no longer valid, the justification for the project’s continuance may no longer exist.

Now let’s talk about inputs to this process

5.1.1 Plan Scope Management:  Inputs  Project Charter

The parts of the project charter that are relevant to scope management are:

  • Project purpose
  • High-level project description
  • Assumptions
  • Constraints (budget, schedule, or others)
  • High-level requirements Project Management Plan

Components of the project management plan that are relevant include the project life cycle description and development approach (predictive, incremental, or adaptive/agile), as well as the quality management plan.   The scope covers the completeness of the work, but quality covers the correctness of the work. Enterprise Environmental Factors

An organization’s culture and infrastructure are among the factors that can affect the management of scope. Organizational Process Assets

An organization’s policies and procedures are important for any management plan, and  historical information and lessons learned repositories may help guide the development of the scope of the project if it is similar to one done in the past.

The next post will cover the tools & techniques of this process.







6th Edition PMBOK® Guide–Process 4.7 Close Project or Phase: Outputs

This process is the final process you will do as a project manager on a project.   This post will cover the outputs of the process.

4.7.3 Close Project or Phase:  Outputs Project Documents Updates

The most important project document to be updated will be the lessons learned register, which may include information on:

  • Benefits management (making sure benefits of project continue after long after the project is done)
  • Accuracy of the business case (was the business need fulfilled by the project, did this project contribute to the strategic objectives of the organization)
  • Risk and issue management (including risk register and issue log)
  • Stakeholder engagement (including stakeholder register) Final Product, Service, or Result Transition

The product, service, or result created by the project will be handed over or transitioned to a different group or organization if it is an external project, but it will be handed over to the organization itself in the case of an internal project.  Final Report

This is a report on the success of the project based on the success criteria set forth in the project charter, which may be based on  scope, schedule, cost and quality objectives.  Organizational Process Asset Updates

  • Project documents–the entire project management plan may be used to update the procedures, processes and guidelines of the organization
  • Lessons learned repository–the lessons learned register for the project will be added to the organization-wide document called the lessons learned respository.
  • Project closure documents–customer acceptance document from the Validate Scope process will be transferred to the document database of the organization
  • Operational and support documents–documents which help to maintain, operate, and support the product or service delivered by the project.

This is it for the Integration Management knowledge area!   The next post will start the Scope Management knowledge area with the first process, 5.1 Plan Scope Management.

6th Edition PMBOK® Guide–Process 4.7 Close Project or Phase: Tools & Techniques

This process, although it is the final process, is like any other process where there is decision making, in that the key tools are going to be expert judgment, data analysis, and meetings, just like in other processes in this knowledge area such as 4.2 Develop Project Management Plan, 4.5 Monitor and Control Project Work, or 4.6 Perform Integrated Change Control.

However, the purpose will be different–essentially the work should be done by this point, and the customer should have formally accepted the final product of the project in the process 5.5 Validate Scope.   The main work here is close the project formally within the organization.

Here are the tools & techniques of this process.

4.7.2 Close Project or Phase:  Tools & Techniques  Expert Judgment

Experts are needed especially when it comes to matters having to do with legal matters or with internal requirements when closing a project.  Data analysis

This is used to create a “scorecard” of how the project did with regards to the schedule and budget.  Meetings

The project team members and other key stakeholders are the ones who attend these meetings, which are used to do the following:

  • Confirm that deliverables have been formally accepted
  • Validate that success criteria have been met
  • Formalize completion of contracts
  • Evaluate satisfaction of stakeholders
  • Gather lessons learned
  • Transfer knowledge and information from the project
  • Celebrate!

The outputs of this final process are covered in the next post.

6th Edition PMBOK® Guide–Process 4.7 Close Project or Phase: Inputs

This process is the final process you will do as a project manager on a project.   If it is the last process, what is the next to last process.   That is process 5.5 Validate Scope, where you take your final deliverable and show it to the customer for final, formal appearance.  If and only if that deliverable is accepted, does the project enter the “close project”  process.

Let’s go over the numerous inputs to this process.

4.7.1  Close Project or Phase:  Inputs  Project Charter

This should contain the project success criteria, and who signs off on the project (usually the project sponsor).  Project Management Plan

The project work was done based on the project management plan, which is also an input to the process. Project Documents

There are many project documents that are inputs to this process.   The entire list is in the PMBOK Guide, but the most important are:

  • Quality control measurements–this demonstrates compliance with the quality requirements.
  • Requirements documentation–used to demonstrate compliance with the project scope.  Accepted Deliverables

These are the outputs of the process 5.5 Validate Scope.   It is important that the deliverables are accepted formally, i.e, in writing, in order to avoid any possibility for miscommunication.  Business documents

These are inputs to the process 4.1 Develop Project Charter.

  • Business case–justifies the project by documenting the business need and the cost benefit analysis associated with the project.
  • Benefits management plan–ensures that the benefits created by the project will continue beyond the lifetime of that project. Agreements

These contracts with other companies contains the formal closure of procurements that were created by those companies and used on the project.  Procurement Documentation

This documentation is used, together with the contracts (= agreements) themselves, to demonstrate that all procurements are properly closed.  Organizational Process Assets

Here are some of the organization standards, processes and procedures that may be inputs to this process.

  • Project closure guidelines or requirements
  • Configuration management knowledge base (contains baselines and all versions of organizational standards and policies)

The next post will cover the tools & techniques involved in this process.

6th Edition PMBOK® Guide–Process 4.6 Perform Integrated Change Control: Outputs

This process is one of the most important project management processes because it is the management of change on the project, and doing this skillfully can make or break a project.    The last post talked about the tools & techniques–this post is about the outputs of the process.

4.6.3.  Perform Integrated Change Control:  Outputs  Approved Change Requests

The process can either approve or reject change requests.   If they are rejected, they go into the change log (see paragraph on Project Documents Updates).    If they are accepted, and only if they are accepted, then they are implemented.    They are also put into the change log and this can be used to track their implementation.  Project Management Plan Updates

Approved change requests may change one or more of the project baselines (scope, cost, and schedule) or any other component of the project management plan

4.6.3  Project Documents Updates

Project documents may be changed by this process, but the one that is ALWAYS affected is the change log, which documents both those changes which were accepted (in order to track their implementation) and those which were rejected (to record the reasons for that rejection).

This next process is the very last process to be done on the project:  4.7  Close Project or Phase.   This will be the subject of the next post.

A New Toastmasters Pathway

I am taking a break today from going through my posts on project management to talk about another subject that is near and dear to me:   Toastmasters.   Today is the day that the new Pathways educational program arrives here in District 103 of Toastmasters International in the Chicagoland area.

The educational program as it existed before consisted of four educational award levels (Competent Communicator, Advanced Communicator Bronze, Advanced Communicator Silver, and Advanced Communicator Gold) and three leadership award levels (Competent Leadership, Advanced Leadership Bronze, Advanced Leadership Silver).   If you complete all seven of those levels, then you get the crowning achievement of Toastmasters as an individual, the designation of being a Distinguished Toastmaster.   I joined Toastmasters at the very end of December 2010, so a little more than 7 years ago.  I followed the educational program and, step by step, award by award, finally became a Distinguished Toastmaster in the Spring of 2016.

Since then, I have been waiting patiently for the new Pathways educational program to arrive because I knew I wanted to start from square one again and become a Distinguished Toastmaster again.   It would be as if I were given a chance to go back to college and avoiding all of the mistakes I made the first time around.    So instead of graduating Summa Cum Lousy, this time I’ll graduate Summa Cum Laude!

Pathways is about getting a customized learning path that is geared towards your interests, essentially the answer to the question “What is it you hope to gain from joining Toastmasters?”   Some people want to become professional speakers; some people want to become trainers, coaches, or better mentors; some people want to use the confidence gained in the program to become better leaders.   That latter was my interest, and after the assessment, it chose the pathway of Dynamic Leadership as being the most appropriate.   Each pathway consists of 5 different levels, rather than the 3 or 4 in the previous educational program, and you have to complete 2 pathways in order to become a Distinguished Toastmaster.

But like everybody else in the District, I am starting at square one, so I now am going back to the Toastmasters International website to start my journey.   In the past half-dozen years or so in Toastmasters, getting my first Distinguished Toastmaster award has led to several leadership positions, including being a leader in my church (I am the President of the Board of Trustees), being a leader in our local Project Management Institute chapter (as the Director of Certification and then Director of Executive Council), and of course within Toastmasters itself (as Division Director).    With the new Dynamic Leadership program as my focus area in the new Pathways program, where will my pathway towards my next Distinguished Toastmaster designation lead me?

I can’t wait to find out!


6th Edition PMBOK® Guide–Process 4.6 Perform Integrated Change Control: Tools & Techniques

Oksy, you now have been given a change request as an input to this process.   How do you actually go about evaluating the request so you can either accept or reject it?   The following blog post lists the tools & techniques you will need to use in order to do this.

4.6.2 Perform Integrated Change Control:  Tools & Techniques  Expert Judgment

Any time you have a decision-making process, like this one, PMI is going to at minimum recommend two tools:  Expert Judgment and Meetings.   Expert judgment because you want the best inputs into the decision, and Meetings (see paragraph below) because you want the best forum to make that decision.  Change Control Tools

Change Control Tools in this context does not mean the Change Control Board alone, but also the tools used, let’s say, if a change request is approved.  (If the change is rejected, it gets recorded in the project document called the change log.)

If a request is approved, that means there will have to be changes in the project management plan.   How can you make sure that everybody working on the project or stakeholders monitoring the project use the “new and improved” version of the project management plan, and don’t up using one of the older, obsolete versions instead?   That is where the configuration management plan comes in.    The details of these activities are contained in the PMBOK Guide.

The other tools used are for managing the change request and the resulting decisions, including action items to implement the change.   These tools have to be accessible to all those who responsible for implementing those changes.  Data Analysis

Cost-benefit analysis helps analyze the requested change in terms of costs and benefits:  will the costs of the change be more than the benefits it will create?

Alternatives analysis uses criteria to evaluate the change requests so that they may not only be accepted or rejected, but perhaps modified by alternatives.  Decision Making

These techniques include the following:

  • Voting–get take the form of unanimity, majority, or plurality (the most votes even if no one block of votes gets a clear majority)
  • Autocratic decision making–one individual takes the responsibility for making the decision for the entire group
  • Multicriteria decision analysis–a systematic analytical approach to evaluate requested changes according to a set of predefined criteria  Meetings

Change control meetings are held by the change control board.   Remember the main work of this meeting is to analyze the impact the proposed change will have on constraints on the project such as time, cost, resources, or risks.    Then the requested changes are discussed along with any alternatives using the data analysis techniques outlined in paragraph   Finally, a decision is made using the decision making techniques outlined in paragraph and the results are communicated to the stakeholders, and the change is managed using change control tools outlined in paragraph

The next post will cover the outputs of this process.


6th Edition PMBOK® Guide–Process 4.6 Perform Integrated Change Control: Inputs

In the last process, 4.5 Monitor and Control Project Work, one of the main outputs that can occur as a result of that process are change requests, in the form of

  • Defect repair–an activity that modifies a nonconforming product or product component
  • Corrective action–an activity that realigns the performance of the project work with the project management plan
  • Preventive action–an activity that ensures the future performance of the project work is aligned with the project management plan.

There is a fourth type of change requests as well.   Let’s say that in analyzing the variance between the project work and the project management plan, that it was discovered that the project management plan was unrealistic because of information uncovered during the process 4.5 Monitor and Control Project Work.   Then the change request might be to change a component of the project management plan to fit a more realistic estimate.   So instead of changing the work to fit the plan as in the three categories above, you might have to change the plan to fit the work…

Now at this point, a change request is simply that, a request.   The decision as to whether  it gets implemented or not is the purpose of this process.   The change can be a change to the product scope (i.e., changes to the features and functions of the product being created by the project) or to the project scope (i.e., changes to the work performed to deliver a product).

An orderly approach to this process is essential to avoid the bane of a project manager’s existence called scope creep.   In a study group session, I once joking gave a definition of that term as when some creep starts messing with your scope.    Well, that may be how it feels as a project manager, but the actual definition is the “uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.”   So you and your project team are expected to do more and more with the same resources, putting more and more pressure on your team.   When you are the project manager responsible for the success of the project, that puts you in a difficult position.

One way to spread the responsibility is to have a Change Control Board, which reviews the change requests and analyzes their impact on the various constraints of the project such as time, cost, and resources, and accepts or rejects them based on criteria established in the change management plan.

Let’s go over are the inputs to this process:

4.6.1  Project Management Plan

The components of the project management plan that are inputs to this process include:

  • Change management plan–this provides the instructions for managing the change control process, including the roles and responsibilities of the Change Control Board (CCB).
  • Configuration management plan–if a change request is accepted, then the project management plan will be altered and perhaps the product scope as well.   The configuration management plan establishes a system to distinguish the various versions of the product/project scope so that everyone is literally on the same page working on the current configuration and not mistakenly working off of a version that is obsolete.
  • Scope/cost/schedule baselines–these baselines are used to assess the impact of the changes to the product/project scope on the project cost and/or schedule. Project Documents

The following project documents may be used to help analyze the impact of change requests.

  • Basis of estimates–this shows how the duration, cost, and resources estimates were derived and can be used to calculate the impact of the proposed change of product/project scope will have on the project schedule, budget, or resources.
  • Requirements traceability matrix–this helps assess the impact of the proposed change on the project scope
  • Risk report–this helps show the impact of the proposed change on overall and individual project risks. Work Performance Reports

These are the outputs of process 4.5 Monitor and Control Project Work.   This contains not only schedule/ cost data, and earned value analysis, but also an analysis of the causes of variation. Change Requests

Change requests are the outputs of the last process 4.5 Monitor and Control Project Work but may be an output of the Executing process 4.3 Direct and Manage Project Work as well.   These are the requests that the Change Control Board or other mechanism described in the Change Management Plan will evaluate and either approve or reject.  Enterprise Environmental Factors

The following EEFs may influence this process:

  • Legal restrictions, legal and regulatory requirements and/or constraints
  • Government or industry standards
  • Organizational governance framework
  • Contracting and purchasing constraints  Organizational Process Assets

The following OPAs may influence this process:

  • Change control procedures (spelled out in the Change Management Plan component of the Project Management Plan), including procedures for approving and issuing change authorizations (e.g., different levels of authorization may be required for changes that exceed certain thresholds in terms of their impact on the schedule and/or budget)
  • Configuration management knowledge base–contains organizational standards regarding how configurations of a project and/or product are to be organized

The next post will cover the actual tools and techniques of this process.




6th Edition PMBOK® Guide–Process 4.5 Monitor and Control Project Work: Outputs

This process includes monitoring the actual work done on the project and comparing it to what is in the project management plan.   If there are variances from the plan, then the process analyzes the cause of the problem and a solution to the problem is recommended in the form of change requests which can include changes to the project management plan itself as well as to project documents.   Another important part of this process is letting the stakeholders know the status of the project, and this is done through work performance reports.

Let’s go throughout the outputs of this process in more detail.

4.5.3 Monitor and Control Project Work:  Outputs Work Performance Reports

Let’s take the work performance data that is generated during the process 4.3 Direct and Manage Project Work.   This is then compared to the project management plan in the control processes of the various knowledge areas.   For example, with regard to Schedule Management, let’s say the work performance data is that “during the past week, John worked on the project 20 hours, and Mary worked on the project 20 hours.”   In the process 6.6 Control Schedule you would compare these actual hours worked with what was supposed to have been done according to the schedule.   Let’s say the schedule shows that John was supposed to work 30 hours, and Mary was supposed to work 20 hours.   Then we know that someone John worked 10 hours less than he was scheduled to.   This can even be put into a schedule performance index or SPI by calculating 40 hours (actual)/50 hours (scheduled) or 0.80.

This SPI of 0.80 is work performance information that is now input into this process 4.5 Monitor and Control Project Work.   Here an analysis is done as to WHY John worked only 20 hours rather than 30 as scheduled.   If John says, “hey, my operational manager told me I had to work on something else”, then the question becomes is this a temporary problem, i.e., was this request for John’s time something that won’t happen the following week?   If so, then John can make up the lost hours next week and the project will be back on track.   However, if John’s operational manager says there will be ongoing duties that John has to take care which will prevent him from doing more than 20 hours of work on the project, then the project manager will have to discuss with the operational manager what kind of accommodation can be done in the future.   This kind of analysis of what kind of action will be taken to solve a problem is something that goes in the work performance report.   It is sent to the stakeholders, therefore, because their help may be needed to take action that will solve the problem.  Change Requests

As a result of the data analysis techniques done during this process, change requests may be generated, such as:

  • Defect repair–activity to modify a nonconforming product
  • Corrective action–activity that realigns the performance of the project work with the project management plan.
  • Preventive action–activity that ensures that future performance of the project work is aligned with the project management plan  Project Management Plan

Let’s say a variance is discovered between the actual project work done and what is in the project management plan.   It is possible that in analyzing the reason for the variance that the cause will not be a problem with the work done, but with the project management plan itself, in that it was unrealistic to begin with.  In which case, a component of the project management plan may need to be changed so that the plan is made to fit the work rather than the situation above with the change requests, where the work is made to fit the plan.  Project Documents

In addition to  the project management plan, the following documents may need to be updated as a result of this process.

  • Issue log–new issued raised as a result of this process are recorded in the issue log
  • Lessons learned register–effective responses to variances, including corrective and preventive actions, are updated to this register
  • Cost/schedule forecasts–changes in cost or schedule forecasts resulting from this process are recorded
  • Risk register–new risk identified during this process are recorded

If there are any change requests, these are processed in the next process 4.6 Perform Integrated Change Control, which will be the subject of the next post.