5th Edition PMBOK® Guide—Chapter 5: Process 5.6 Control Scope

Posted on March 16, 2013 by Jerome Rowley

This process is probably one of the most crucial when it comes to maintaining the scope baseline and only changing it when necessary. If the scope is expanded in an uncontrolled manner, this is called “scope creep” and something which the Project Management Institute wants project managers to avoid.

The following is a summary of the inputs, tools & techniques, and outputs of the 5.6 Control Scope process. The inputs have to do with the scope, change, configuration and requirements management plans, the only tool and technique used is that of variance analysis, and the outputs have to do with updates to the scope management-related plans and documents.

5.6 CONTROL SCOPE
INPUTS
1. Project Management Plan The following elements are inputs to the process:

  • Scope baseline—compared to actual results to determine if a change request is necessary
  • Scope management plan—describes how the project scope will be monitored and controlled
  • Change management plan—defines the process of managing change requests on a project
  • Configuration management plan—defines items that are configurable, those items that require formal change control, and the process for controlling changes to such items
  • Requirements management plan—describes how project requirements will be analyzed, documented, and managed
2. Requirements Documentation Well-documented requirements make it easier to detect any deviation in the scope agreed for the project or product.
3. Requirements traceability matrix Helps detect the impact of any change or deviation from the scope baseline.
4. Work performance data Number of change requests received, the number of change requests accepted, number of deliverables completed.
5.. OPAs
  • Scope-related policies, procedures, guidelines
  • Monitoring and reporting methods and templates
TOOLS & TECHNIQUES
1. Variance analysis Used to determine the cause and degree of difference between the baseline and actual performance.
OUTPUTS
1. Work performance information How the project scope is performing compared to the scope baseline.
2. Change requests Analysis of scope performance can result in a change request to the scope baseline, or a change such as defect repair, corrective action, or preventive action.
3. Project management plan updates
  • Scope baseline updates
  • Cost and schedule baseline updates
4. Project documents updates
  • Requirements documentation
  • Requirements traceability matrix
5. OPA updates
  • Causes of variance
  • Corrective actions taken
  • Lessons learned from scope control

This is the last process in the Scope Management Area.

Filed under: Uncategorized | 1 Comment »

5th Edition PMBOK® Guide—Chapter 5: Process 5.5 Validate Scope

Posted on March 15, 2013 by Jerome Rowley

The basic idea of the process is to take the deliverables which have been internally checked in process 8.3 Control Quality to see whether they meet the customer’s requirements, and then actually present them to the customer for formal acceptance, which means to validate them. These are the interim deliverables, of course; the final deliverables are formally accepted as part of the 4.7. Close Project or Phase Process.

NOTE: The 5th Edition PMBOK® reverses the definitions of verify and validate scope that were used in the 4th Edition. In the 4th Edition, validate means to check internally and to verify means to verify with the customer; in the 5th Edition, the reverse is true.

Here’s a summary of the inputs, tools & techniques, and outputs of the Validate Scope process.

5.5 VALIDATE SCOPE
INPUTS
1. Project Management Plan Contains Scope Management Plan which specifies how formal acceptance of the completed project deliverables will be obtained.
2. Requirements Documentation Lists all the project, product, and other types of requirements for the project and product, along with their acceptance criteria.
3. Requirements traceability matrix Links requirements to their origin and tracks them throughout the project life cycle.
4. Verified deliverables Completed and checked internally for correctness through the Control Quality process.
5.. Work performance data Includes degree of compliance with requirements, number and severity of nonconformities.
TOOLS & TECHNIQUES
1. Inspection Measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria.
2. Group decision-making techniques Used to reach a conclusion when the validation is performed by the project team and other stakeholders.
OUTPUTS
1. Accepted deliverables Deliverables that meet acceptance criteria are formally signed off and approved by the sponsor or customer.
2. Change requests Deliverables that do not meet acceptance criteria are documented, along with the reasons for their nonconformance. These deliverables may require a change request for defect repair.
3. Work performance information Information about which deliverables have been started, their progress, which deliverables have been finished, or which have been accepted.
4. Project documents updates Documents that define the product or report status on product completion.

If the deliverables are accepted, then the project continues as before; however, if the deliverables are not accepted, then change requests are generated which will bring the deliverables in line with the customer’s requirements.

The next process is 5.6 Control Scope, which is covered in the next post.

Filed under: Uncategorized | 1 Comment »

5th Edition PMBOK® Guide—Chapter 5: Process 5.4 Create WBS

Posted on March 14, 2013 by Jerome Rowley

The WBS or work breakdown structure takes the scope as outlined in the project scope statement and breaks it down into more manageable components called deliverables.  It serves as a graphical illustration of the structure of the project and is thus useful as a communication tool for explaining the project to key stakeholders.

Here is a summary of the inputs, tools & techniques, and outputs of the process.

5.4 CREATE WBS
INPUTS
1. Scope Management Plan Tells how to create the WBS from the project scope statement and how the WBS will be maintained and approved.
2. Project Scope Statement Describes the work that is to be performed and the work that is excluded.
3. Requirements Documentation Essential for understanding what needs to be produced as a result of the project and what needs to be done to produce the final product
4. EEFs
  • Industry-specific WBS standards
5.. OPAs
  • Policies, procedures and templates for the WBS
  • Project files from previous projects
  • Lessons learned from previous projects
TOOLS & TECHNIQUES
1. Decomposition Technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts.
2. Expert judgment Used to analyze the information needed to decompose the project deliverables down into smaller, more manageable parts.
OUTPUTS
1. Scope baseline Consists of three elements

  • Project scope statement
  • WBS
  • WBS dictionary
2. Product documents updates
  • Requirements documentation

It is a hierarchical decomposition of the total scope of the work, with the lowest level of the decomposition being work packages. The activities to create these work packages are done in the first process of the Time Management Knowledge Area, 6.1 Define Activities, and so process 5.4 Create WBS and 6.1 Define Activities are often profitably combined into one process.

The next process in the Scope Management knowledge area takes us to the Monitoring & Controlling Process Group with the process 5.4 Validate Scope. That is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

5th Edition PMBOK® Guide—Chapter 5: Process 5.3 Define Scope

Posted on March 13, 2013 by Jerome Rowley

After the process 5.2 Collect Requirements, which takes the high-level requirements and needs of the key stakeholders and analyses them, in the process 5.3 Define Scope they are then used to create a detailed description of the project and product, which is called the project scope statement.

Here is an overview of the inputs, tools & techniques, and outputs used in the process.

5.3 DEFINE SCOPE
INPUTS
1. Scope Management Plan Establishes activities for developing, monitoring, and controlling the project scope.
2. Project Charter Provides the high-level description and product characteristics.
3. Requirements Documentation This will used to select the requirements that will be included in the project.
4. OPAs
  • Policies, procedures and templates for a project scope statement.
  • Project files from previous projects
  • Lessons learned from previous phases or projects
TOOLS & TECHNIQUES
1. Expert judgment Used to analyze the information needed to develop the project scope statement.
2. Product analysis For projects that have products as a deliverable, product analysis can be a useful tool for translating high-level product descriptions into tangible deliverables.
3. Alternatives generation Develops many potential options as possible in order to identify different approaches to perform the work of the project.
4. Facilitated workshops These intensive working sessions help to reach a cross-functional and common understanding of the project objectives and its limits.
OUTPUTS
1. Project scope statement Detailed description of the project scope, including major deliverables, assumptions, and constraints. It documents the project scope and the product scope, and describes the project’s deliverables and the work required to deliver them.
2. Project documents updates The following project documents may be updated as a result of this process:

  • Stakeholder register
  • Requirements documentation
  • Requirements traceability matrix

One of the things to realize about the Define Scope process is that the process 5.2 Collect Requirements represents the “universe” of requirements from which the final project requirements will be chosen.

The Define Scope takes the high-level product descriptions, assumptions and constraints, which were documented in the process 4.1 Develop Project Charter during the initiating process group, and creates from them a more detailed description of the scope in the Project Scope Statement.

It is possible that in the first pass through this process, the project scope may not be fully defined. As additional risks, assumptions and constraints are added, so the project scope may be revised or updated as necessary as part of the iterative process of developing the project scope.

So the process goes from high-level requirements to detailed requirements from the customer and major stakeholders, and these are translated into major deliverables and then detailed deliverables which the organization will deliver as the goal of its project in order to fulfill those requirements.

I have included the numbers of the project management processes above the stages of the development of the scope.

The next process, 5.4 Create WBS, goes to the final level of the development of the scope, the deliverables in the form of work packages which are the components of the Work Breakdown Structure. The overview of that process will be the subject of the next post.

Filed under: Uncategorized | Leave a comment »

#FSI Language Courses Are Restored!

Posted on March 12, 2013 by Jerome Rowley

On March 3rd I wrote a blog post about the fact that the Foreign Service Institute language courses website fsi-language-courses.org was down.  I found I was not alone in noticing this and missing the access to these courses that were in the public domain.

As I mentioned in my previous post, I had used the Advanced courses for various European languages and was now going through the various modules of the Standard Chinese: A Modular Approach course.

Jennifer Wagner at the website ielanguages.com commented on my blog today telling me that the foreign languages, including the audio files, were now available at a site called fsi.antibozo.net.

I checked this site out, and it is true that the courses and audio files are all there from the original FSI site. I’m putting this blog post out as a public service to those who had linked to my recent blog post lamenting the disappearance of these courses.

I just linked to the site and downloaded the files for the Module 4 of the Standard Chinese course, and was preparing to do some housework while listening to the files. I find that, besides language learning, the audio files for the course are great for practicing in the following situations:

  1. Commuting—I live in LA where the daily commute is one of the banes of our existence. However, if you listen to FSI language course audio files and practice them while you drive, the drudgery of waiting in traffic goes away. And if you do get frustrated, you now have the choice of another language in which to curse at the other drivers!
  1. Housework—Another task that is necessary but boring is housework. I have found that if I schedule myself to complete one audio tape while doing housework, that it causes me to get the work done more efficiently because my mind is occupied with language learning and doesn’t have any mental room left to complain about what I have to do.
  1. DMV and other bureaucracies—When you have to wait in line at a government office, or a doctor’s office, just plug in your iPhone and practice your language while you are waiting to be called. The time goes by so much more quickly that way!

These are just some ways that you can carve time into your day for language learning, which so many of my friends say they want to do, but they can’t because they don’t have it. If you don’t have the time, create it!

Filed under: Uncategorized | 4 Comments »

5th Edition PMBOK® Guide—Chapter 5: Process 5.2 Collect Requirements

Posted on March 11, 2013 by Jerome Rowley

According to the PMBOK® Guide, this process determines, documents and manages stakeholder needs and requirements in order to meet the project objectives.

The inputs are the management plans that give information about the requirements, and the stakeholders that will need to be consulted in order to carry out this process.

The tools & techniques contain a variety of different methods for developing the requirements.

The outputs are the requirements documentation and requirements traceability matrix.

5.2 COLLECT REQUIREMENTS
INPUTS
1. Scope Management Plan How project teams will determine which type of requirements need to be collected for the project.
2. Requirements Management Plan Provides processes that will be used throughout to define and document the stakeholder needs.
3. Stakeholder Management Plan Used to understand stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirements activities.
4. Project Charter High-level description of the product, service, or result of the project so that detailed requirements can be developed.
5. Stakeholder register Identifies stakeholders who can information on the requirements, and captures major requirements and main expectations stakeholders have for the project.
TOOLS & TECHNIQUES
1. Interviews Aids in identifying and defining the features and functions of the desired product deliverables.
2. Focus groups Used to learn about expectations and attitudes about a new product, service, or result.
3. Facilitated workshops Focused sessions that bring together key stakeholders to define product requirements.
4. Group creativity techniques Organized to identify product and project requirements.
5. Group decision-making techniques An assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements.
6. Questionnaires and surveys Written sets of questions designed to quickly accumulate information from a large number of respondents.
7. Observations It is helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements.
8. Prototypes Obtains early feedback on requirements by providing a working model of the final product.
9. Benchmarking Compares actual practices, such as processes and operations, to those of comparable organizations in order to generate best practices.
10. Context diagrams A scope model which visually depicts the product scope by showing a business system and how people and other systems interact with it.
11. Document analysis Elicits requirements by analyzing existing documentation and identifying information relevant to the requirements.
OUTPUTS
1. Requirements documentation Consists of the following categories of requirements:

  • Business requirements
  • Stakeholder requirements
  • Solution requirements
  • Project requirements
  • Transition requirements
  • Requirements assumptions, dependencies, and constraints.
2. Requirements traceability matrix Traces requirements with respect to the following:

  • Business needs
  • Project objectives
  • Project scope/WBS deliverables
  • Product design
  • Product development
  • Test strategy and test scenarios
  • High-level requirements to more detailed requirements

The important thing is that the needs and requirements of the customer and other key stakeholders need to be translated from high-level requirements to more detailed requirements that eventually will turn into the deliverables that comprise the Work Breakdown Structure.

The next post will give an overview of the next process, 5.3 Define Scope.

Filed under: Uncategorized | 3 Comments »

5th Edition PMBOK® Guide: Chapter 5—Requirements Management Plan

Posted on March 10, 2013 by Jerome Rowley

The process 5.1 Plan Scope Management has the purpose of creating a framework for most of the other scope management processes. Four of these processes (5.3 through 5.6) are reflected in the Scope Management Plan, and one of them 5.2 Collect Requirements is reflected in another project management plan, the Requirements Management Plan.

The purpose of this post is to outline the elements of the Requirements Management Plan as laid out by the PMBOK® Guide.

Element of Requirements Management Plan Explanation
1. Requirements activities management Manages how these activities will be planned, tracked, and reported 
2. Configuration management activities
  • How changes to the product will be initiated
  • How they will be traced, tracked, and reported
  • Authorization levels required to approve changes
3. Requirements prioritization process If two or more requirements are in conflict, which receive priority? 
4. Products metrics Which metrics will be used and why? 
5. Traceability structure Which requirement attributes will be captured on the traceability matrix?

So the two project management plans, the Scope Management Plan and the Requirements Management Plan, are the outputs of the process 5.1 Plan Scope Management.

The next post will describe the next scope management process, 5.2 Collect Requirements.

Filed under: Uncategorized | 2 Comments »

5th Edition PMBOK® Guide—Chapter 5: Scope Management Plan

Posted on March 9, 2013 by Jerome Rowley

1.  Introduction

The output of process 5.1 Plan Scope Management is, not surprisingly, the Scope Management Plan. You should be aware that in previous editions of the PMBOK® Guide, this process did not exist. What, you may say, they didn’t use to create a Scope Management Plan? Well, no, not exactly. A Scope Management Plan was created, but it was done as part of creating the most general Project Management Plan as part of 4.2 Develop Project Management Plan. But to emphasize that each knowledge area does require the creation of its own management plan, the 5th Edition of the PMBOK® explicitly creates a separate process doing just that.

The purpose of this post is to look at the elements of what is in a Scope Management Plan.

2.  Elements of the Scope Management Plan

As mentioned in an earlier post, the main purpose of the scope management plan is to provide the framework for most of the other 5 scope management processes. You can see this if you look at the following table of the elements of the plan.

Element of Scope Management Plan Related Scope Management Process
1. Process for preparing detailed project scope statement 5.3 Define Scope
2. Process that creates WBS from the detailed scope statement 5.4 Create WBS
3. Process that establishes how the WBS will be maintained and approved 5.4 Create WBS
4. Process that specifies how formal acceptance of the completed project deliverables will be obtained 5.5 Validate Scope
5. Process to control how requests for changes to the detailed project scope statement will be processed 5.6 Control Scope

The only scope management process not mentioned, 5.2 Collect Requirements, is covered by another management plan, the Requirements Management Plan, and this the other output of process 5.1 Plan Scope Management, and is covered in the next post.

Filed under: Uncategorized | Leave a comment »

5th Edition PMBOK® Guide—Chapter 5: Project Charter vs. Project Scope Statement

Posted on March 8, 2013 by Jerome Rowley

1. Introduction

In this particular post, I review the differences between the Project Charter and the Project Scope Statement. There are differences between them, but both of them have some common elements, so it may be difficult to distinguish them. The purpose of this post is to make the distinction between them clearer.

2. Project Charter vs. Project Scope Statement: Processes

The project charter is something that is an output of the process 4.1 Develop Project Charter. This is in the Initiating Process Group. As such, it is a document that is created at a high-level (broad-based rather than detailed) for the purpose of getting the project approved by the sponsor.

Once the sponsor says “yes” to the project, then the project manager can proceed to the Planning Process Group and create the Project Scope Statement as an output of the process 5.3 Define Scope. The Project Scope Statement is created at a detailed level from the general description of the Scope contained in the Project Charter, (an output of process 4.1 Develop Project Charter), along with the Scope Management Plan (an output of process 5.1 Plan Scope Management), and the Requirements Documentation (an output of process 5.2 Collect Requirements).

3. Project Charter vs. Project Scope Statement: Contents

Here are the elements of the Project Charter (used for approval of the project) compared to the elements of the Project Scope Statement (used in planning of the project). Those elements which are similar are put in the same row.

Project Charter Project Scope Statement
a. Project purpose or justification (fits business needs, strategic plan)
b. Project objectives, product characteristics a. Project scope description
c. High-level requirements b. Deliverables
d. Project assumptions, constraints, high-level descriptions, boundaries c. Project exclusion, constraints, assumptions
e. Project success criteria d. Project acceptance criteria
f. High-level risks
g. Summary schedule, budget
h. Stakeholder list
i. Project approval requirements and approval authority
j. Project manager assigned to project

As you can see, the project charter contains elements that deal with the justification for the project, who is running the project, and who has authority and approval over the project. But in addition, there are elements from the following knowledge areas:

  • Scope management
  • Cost management
  • Time management
  • Risk management
  • Stakeholder management

As you can see from the Project Scope Statement fleshes out in detail those portions of the Project Charter that specifically deal with the Scope Management Area.

Filed under: Uncategorized | Leave a comment »

5th Edition PMBOK® Guide—Project Statement of Work vs. Project Charter

Posted on March 7, 2013 by Jerome Rowley

1. Introduction

The Project Statement of Work is an input to the 4.1 Develop Project Charter process in the Initiating Process Group. The output of that process is the Project Charter.

The purpose of this post is to make the distinction between the Project Statement of Work and the Project Charter clearer. I will do this by answering the questions: What is it? How does it fit in the flow of PM processes? Who creates it? What’s in it? How does it compare to the Project Charter? How is it related to procurements?

2. Project Statement of Work (SOW)—What is it?

The best way I can describe the Project Statement of Work is as the “seed” of the project. It is watered during the Initiating Process into the Project Charter which causes it to germinate and become a seedling. The seedling is planted in the ground during the Planning process of creating the Project Scope Statement. It then turns into a plant during the Executing Process (where it is given sunlight and water, analogous to project resources) and Monitoring & Controlling Process (where it is checked periodically to see if there are any adverse conditions such as pests or diseases), and is finally harvested at the time of the Closing Process.

3. Project Statement of Work (SOW)—How does it fit into the flow of PM Processes?

The SOW is the seed or kernel of the idea for the project which is then developed at a high level for the purpose of approval of the project during the Initiating Process Group as process 4.1, Develop Project Charter. As seen in the previous post, this Project Charter, if approved, is developed at a higher level of detail in the Planning Process Group as process 5.3, Define Scope. So here’s the flow of how the documents are connected:

3. Project Statement of Work (SOW)—Who creates it?

This is going to depend on the end result of the project is going to be a product, service, or result that is used internally within the company, or is to be delivered to an external customer.

If the sponsoring organization is the one that is going to use the end result, then the sponsor is the one that originates the SOW. If a customer is the one that is going to use the end result, then the customer is the one that originates the SOW. The SOW may be part of a bid document (request for proposal, request for information, request for bid) or as part of a contract.

4. Project Statement of Work (SOW)—What’s in it?

The PMBOK® Guide references 5 inputs to the 4.1 Develop Project Charter process, two of which are the generic Enterprise Environmental Factors (EEF) and the Organizational Process Assets (OPA), the “company culture” and “company processes” that are inputs to many PM processes. The other three are the Project Statement of Work, the Business Case, and Agreements.

However, listing these three like this is somewhat misleading and obscures their interrelationships. Here are more detailed descriptions of these three inputs

a. SOW
The components of the Project SOW are as follows:

Element Description
1. Business need Why do the project? Because of some external factor such as:

  • Market demand (new demands create new products)
  • Technological advance (taking advantage of new materials and/or available technologies
  • Legal requirement
  • Government regulations (environmental, safety, etc.)
  • Environmental consideration
2. Product scope description Characteristics of the product, service, or result for which the project is undertaken. What is the relationship between that product, service, or result and business need the project addresses?
3. Strategic plan The project must contribute to the organization’s overall objectives or high-level mission statement.

b. Business Case

How is the business need different from the business case? The business case takes the business need outlined in the SOW (element 1 in the chart above) and justifies how the result of the project (element 2 in the chart above) will satisfy that need AND align with the strategic goals of the organization (element 3 in the chart above). It is the analysis that ties together the 3 elements of the SOW like so:

c. Agreements

As mentioned above, IF the product is to be made for a customer, then the SOW may come from the contract, a memorandum of understanding (MOU), a letter of intent, or some other form. The key is that the statement of work may come either internally (from the sponsor) or externally (from the customer).

I hope this explanation clears up the distinction between these three inputs of the process 4.1 Develop Project Charter other than the generic EEFs and OPAs.

5. Project Statement of Work: How does it Compare to the Project Charter?

Here are the elements of the Project Statement of Work (the “seed” idea of the project) compared to the elements of the Project Charter (used for approval of the project). Those elements which are similar are put in the same row. In this chart, the elements 1 and 3 from the above chart on the Project Statement of Work correspond to the first element of the Project Charter, and element 2 from the above chart corresponds to the second element of the Project Charter.

Project Statement of Work Project Charter
a. Business need, strategic plan a. Project purpose or justification (fits business needs, strategic plan)
b. Product scope description b. Project objectives, product characteristics
c. High-level requirements
d. Project assumptions, constraints, high-level descriptions, boundaries
e. Project success criteria
f. High-level risks
g. Summary schedule, budget
h. Stakeholder list
i. Project approval requirements and approval authority
j. Project manager assigned to project

The Project Statement of Work is therefore the core of the first two elements of the Project Charter.

The other elements of the project charter deal with the project scope rather than the product scope (Project assumptions, constraints, high-level descriptions, boundaries), the criteria for success and those risks that may prevent the project from being successful, the high-level constraints of time and cost, the stakeholder list, the project approval requirements and authority, and finally, the actual project manager assigned to the project.

The next post will discuss the difference between the Project Charter, the output of 4.1 Develop Project Charter and the Project Scope Statement, the output of 5.3 Define Scope.

Filed under: Uncategorized | 6 Comments »

« Previous Page — Next Page »