5th Edition PMBOK® Guide–Step 6: Memorizing Inputs & Outputs (Scope Management Part 1)

1. Introduction

In this next series of posts on memorizing the processes, we move on to the final step 6, which is memorizing the INPUTS & OUTPUTS associated with each of the 47 processes.   In order to breakdown the memorization into more bite-size chunks, I am breaking down the processes in the 10 knowledge areas into 2 or 3 posts each.

This post covers chapter 5 of the PMBOK® Guide, which covers the Scope Knowledge Area. This knowledge area contains 6 processes,

2.   Summary of Processes, Tools & Techniques, and Inputs & Outputs for processes 5.1 and 5.2

There are a total of six processes in the Scope Knowledge Area.   Because of the large number of inputs and outputs, I am splitting my discussion of the inputs and outputs into three different posts, each one of which will cover two of the processes.    In that way, I can describe the inputs and outputs for these processes in a little bit of detail without the post becoming too long.

Here is a chart which shows the first two processes, 5.1 Plan Scope Management and 5.2 Collect Requirements, together with their tools & techniques (which are discussed in a previous post) and their inputs & outputs.   NOTE:  the generic inputs known as Environmental Enterprise Factors and Operational Process Assets are given by their acronyms EEFs and OPAs, respectively.

Process Name Tools & Techniques Inputs Outputs
5.1 Plan Scope Management 1. Expert Judgment

2. Meetings

1. Project management plan

2. Project charter

3. EEFs

4. OPAs

1. Scope management plan

2. Requirements management plan

5.2 Collect Requirements 1. Interviews

2. Focus groups

3. Facilitated workshops

4. Group creativity techniques

5. Group decision-making techniques

6. Questionnaires and surveys

7. Observations

8. Prototypes

9. Context diagrams

10. Document analysis

1. Scope management plan

2. Requirements management plan

3. Stakeholder management plan

4. Project charter

5. Stakeholder register


1. Requirements documentation

2. Requirements traceability matrix

You will notice that this is one of the rarer instances where the list of tools & techniques for one of the processes, namely 5.2 Collect Requirements, is longer than the list of inputs & outputs.   It’s because collecting the requirements is such an involved process, requiring access to all the stakeholders and then on top of that, needing a lot of technical analysis to take the initial set of requirements and to prioritize them.

3.  Outputs of process 5.1 and 5.2

Let’s discuss the outputs first because they are generally easier to identify than the inputs.

a.  Scope management plan (5.1 Plan Scope Management)

It should be fairly obvious that the primary output of the process “Plan Scope Management” will be the Scope Management Plan.

The scope management plan contains information on the following processes:

  • creation of the main elements of the scope baseline, the project scope statement and the work breakdown structure or WBS
  • the formal acceptance of the completed project deliverables will be obtained
  • the control of requests for changes to the detailed project scope statement

b.  Requirements management plan (5.1 Plan Scope Management)

What may not be so obvious is that one of the 4 subsidiary plans that make up the overall Project Management Plan, is also an output of this process in addition to the Scope Management Plan mentioned in paragraph a above. 

The requirements management plan contains information on the following processes:

  • requirements prioritization process
  • product metrics that will be used
  • requirement attributes that will be captured on the traceability matrix

c.  Requirements documentation (5.2 Collect Requirements)

This includes documentation on the various categories of requirements, such as

  • Business requirements
  • Stakeholder requirements
  • Solution requirements (technology and standard compliance, support and training, quality)
  • Project requirements
  • Requirements assumptions, dependencies, and constraints

d.  Requirements traceability matrix (5.2 Collect Requirements)

This grid links the product requirements to the deliverables that satisfy those requirements.   It helps ensure that the requirements listed in the requirements documentation (paragraph c) above actually are delivered at the end of the project.

These are the outputs of these two processes.

4.  Inputs of process 5.1 and 5.2

a. Project management plan (5.1 Plan Scope Management)

Okay, PMI says that “approved subsidiary plans of the project management plan are used to create the scope management plan.”  My comment to PMI is, “could you be a LITTLE more specific?”   This entry for the inputs of this process is singularly unhelpful, because here’s all of what is in the Project Management Plan, which is not really a single plan, but a collection of baselines (scope, schedule, and cost), subsidiary management plans from the other 9 knowledge areas, and 4 additional subsidiary management plans (change, configuration, requirements and process improvement).   PMI should have listed which particular subsidiary plans they have in mind.

b. Project charter (5.1 Plan Scope Management and 5.2 Collect Requirements)

This provides the high-level of the description of the project and lists the desired product characteristics from the project statement of work.   The project statement of work or SOW is the “seed” of the project.   To learn the difference between the project charter and the project SOW, refer to the following post:


c.  EEFs (5.1 Plan Scope Management)

The EEFs used as inputs to this process are:

  • Organizational culture
  • Infrastructure
  • Personnel administration
  • Marketplace conditions

d.  OPAs (5.1 Plan Scope Management)

The OPAs used as inputs to this process are:

  • Policies and procedures
  • Historical information from previous projects and lessons learned database

e. Scope management plan (5.2 Collect Requirements)

This clarifies how the project teams will determine which types of requirements need to be collected for the project.

f.  Requirements management plan (5.2 Collect Requirements)

Provides the processes to be used throughout the Collect Requirements process to define and document stakeholder needs.

g.  Stakeholder management plan (5.2 Collect Requirements)

Helps understand stakeholder communication requirements and level of stakeholder engagement in order to adapt the level of stakeholder participation in requirements activities.

h.  Stakeholder register (5.2 C0llect Requirements)

Used to identify which stakeholders can give information on particular requirements.  It also captures the major requirements and main expectations stakeholders may have for the project.

These are the inputs to these two processes.   Do not try to actively memorize the list of inputs and outputs!  Rather, try to be able to passively recognize them if they occur in exam questions.    For example, take a sheet of paper with the name of each of the processes in the Scope Management knowledge area.   Take some index cards and write the names of the inputs and outputs.   Then shuffle the deck, and read the names of the inputs and outputs as they come up, and try to identify which of the processes you think it goes with, then use the PMBOK® Guide to check and see if you are right.   You’ll be surprised how many you get correct the first time, IF you have taken the trouble to understand what the process does and understand what some of the tools & techniques are.

The next post will cover the next two processes, 5.3 Define Scope and 5.4 Create WBS.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: