4squareviews

 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 42 processes. In order to breakdown the memorization into more bite-size chunks, I am going to break down this topic into at least 9 posts, one for each knowledge area. (There may be some knowledge areas that require more than one post.)

This post covers chapter 5 of the PMBOK® Guide, which covers the Scope Knowledge Area. This knowledge area contains 5 processes, three of which are in the Planning Process group, and two of which are in the Monitoring & Controlling Process Group.

2. Review of processes in Integration Knowledge Area

As a review, here is a chart which gives a summary of the processes themselves, plus the tools & techniques used as part of that process.

3. Definition of inputs, outputs

The inputs for a given process are the documents or results of other processes that are used in order to do the process. The results of going through the process are the outputs. These outputs are then used as inputs for some other process.

4. Generic inputs

Before we start, there are two “generic” inputs that are used in many, many processes. The term “generic” inputs is not to be found in the PMBOK® guide; that’s just my term I made up in our study group to clue people in to the fact that they are included as an input in more processes than you could probably name off the top of your head.

A. ENVIRONMENTAL ENTERPRISE FACTORS (EEF)

This is the “company culture”, or factors that are external to the project but which influence the project’s success. These can include the company databases and, in particular, the project management software used by the company.

B. OPERATIONAL PROCESS ASSETS (OPA)

Written procedures, policies, and guidelines that are used by the company to guide all operations, including projects. Lessons learned would be an important part of OPA.

Think of the operational process assets as the “hard copy” (written procedures), and the environmental enterprise factors as the “soft copy” (software and the company culture or “unwritten rules” that govern how work is done).

NOTE: Tools & Techniques will be listed for the purpose of completeness and for reference, but their detailed description will be omitted, because it is contained in the blog posts specifically covering Tools & Techniques for that knowledge area.

5.1 COLLECT REQUIREMENTS

.

In the process Collect Requirements, you define and document stakeholders’ needs to meet the project objectives, and you define and manage customer expectations.

INPUTS

5.1.1 Project charter

The process is done by analyzing the information contained in the project charter, which contains high-level project requirements and a product description. From these detailed product requirements will be developed.

5.1.2 Stakeholder register

The process is done by analyzing the information contained in the stakeholder register. From the stakeholder register, those stakeholders can be identified who might have pertinent information on detailed project and product requirements.

TOOLS & TECHNIQUES

5.1.1 Interviews

5.1.2 Focus groups

5.1.3 Facilitated Workshops

5.1.4 Group creativity techniques

5.1.5 Group decision making techniques

5.1.6 Questionnaires and surveys

5.1.7 Observations

5.1.8 Surveys

OUTPUTS

5.1.1 Requirements documentation

The whole purpose of this process is to take high-level requirements and make them more detailed.

The requirements document describes how individual requirements meet the business need for the project. The document lists all the requirements categorized by stakeholder and priority.

5.1.2 Requirements management plan

This plan documents how the requirements will be analyzed, documented, and managed throughout the project.

5.1.3 Requirements traceability matrix

This matrix lists the requirements to their origin (i.e., from which stakeholder) and traces them throughout the project life cycle to see if they have been met. It also can link the requirements to the business and project objevtives. Fnally, it can provide a structure for managing changes to the product scope.

5.2 DEFINE SCOPE

The Define Scope develops a detailed description of the project and product and prepares a project scope statement.

INPUTS

5.2.1 Project charter

This contains the high-level project description and product characteristics, as well as the project approval requirements. This is an output of the 4.1 Develop Project Charter process.

5.2.2 Requirements Documentation

This is the output of the 5.1 Collect Requirements process.

5.2.3 Organizational Process Assets

Templates for a project scope statement can be used and altered for this particular project.

TOOLS & TECHNIQUES

5.2.1 Expert judgment

5.2.2 Product analysi

5.2.3 Alternatives identification

5.2.4 Facilitated workshops

OUTPUTS

5.2.1 Project scope statement

The project scope statement contains the following:

	Document	Explanation
1.	Project scope description	Characteristics of the product, service or result to be produced by the project.
2.	Product acceptance criteria	The criteria for acceptance of the completed product, service, or result.
3.	Project deliverables	The product, service, or result of the project plus reports of the management of the project.
4.	Project exclusions	What is agreed to be out of scope for the project.
5.	Project constraints	Constraints on the project scope, predetermined budget, imposed completion and/or schedule milestone dates,
6.	Project assumptions	Assumptions associated with the project scope.

5.2.2 Project document updates

5.3 CREATE WBS

INPUTS

5.3.1 Project scope statement

This is the output for the previous process 5.2 Define Scope.

5.3.2 Requirements documentation

This is the output for the process 5.1 Collect Requirements

5.3.3 OPA

Templates or other project files from previous projects that may help in creating the WBS.

TOOLS & TECHNIQUES

5.3.1. Decomposition

OUTPUTS

5.3.1 WBS

It is obvious that WBS would be an output of the Create WBS process.

5.3.2 WBS dictionary

The WBS dictionary gives more detailed information on the components of the WBS, including who is responsible for doing the work, the cost estimates for doing that work, etc.

5.3.3 Scope baseline

The scope contains the following documents

• Project scope statement—the output of 5.2 Define Scope
  

• WBS—output of this process 5.3 Create WBS
  
• WBS dictionary—output of this process 5.3 Create WBS
  

5.3.4 Project document update

Requirements documentation may need to be updated after the detailed WBS is created.

5.4. VERIFY SCOPE

INPUTS

5.4.1 Project management plan

This is the output from the 4.2 Develop Project Management Plan process.

5.4.2 Requirements documentation

This is the output from the 5.1 Collect Requirements process.

5.4.3 Requirements traceability matrix

This is the output from the 5.1 Collect Requirements process.

5.4.4 Validated deliverables

These are deliverables which have been internally checked for correctness; they are the output of 4.5 Perform Quality Control Process.

TOOLS & TECHNIQUES

5.4.1 Inspection

OUTPUTS

5.5.1 Accepted deliverables

The Verify Scope process takes the deliverables which are internally validated and shows them to the customer for their acceptance. Once these are formally signed off and approved by the customer or sponsor, they are considered accepted deliverables.

5.5.2 Change requests

If the deliverables are not accepted, then change requests may be necessary to bring them into compliance with the customer’s requests.

5.5.3 Project document updates

Documents that contain the product status will need to be updated to reflect the acceptance or rejected by the customer.

5.5 CONTROL SCOPE

INPUTS

5.5.1 Project management plan

This is the output of the process 4.2 Develop Project Management Plan

5.5.2 Work performance information

This is information about the progress towards completing the deliverables.

5.5.3 Requirements documentation

This is the output from the 5.1 Collect Requirements process.

5.5.4 Requirements traceability matrix

This is the output from the 5.1 Collect Requirements process.

5.5.5 Organizational Process Assets

Monitoring and reporting methods, policies towards controlling scope.

TOOL & TECHNIQUES

5.5.1 Variance analysis

OUTPUTS

5.5.1 Work performance measurements

The comparison is given between the amount of progress towards completing the deliverables and the planned amount of progress (the variance). This is to be communicated to stakeholders.

5.5.2 Organizational Process Assets updates

The cause of any variance, and any corrective action to be taken.

5.5.3 Change requests

There can be a request for preventive, corrective actions, or defect repairs. Or there can be a change request to the scope baseline.

5.5.4 Project management plan updates

These can include updates to the scope baseline (scope statement, WBS, or WBS dictionary).

5.5.5 Project document updates

Requirements documentation and requirements traceability matrix.

The next post will cover the inputs and outputs of the time knowledge area.

Filed under: Uncategorized |