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 4 of the PMBOK® Guide, which covers the Integration Knowledge Area. This knowledge area contains 6 processes, with at least one process in each of the 5 process groups, with Monitoring & Controlling Process having two processes from this area.

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. I am splitting the discussion of the Inputs & Outputs into two different posts; this post will cover Processes 4.1 through 4.3

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.

4.1 DEVELOP PROJECT CHARTER

INPUTS

4.1.1. Project Statement of Work

The Project Statement of Work, sometimes referred to as an SOW, is a description of the products or services to be delivered by the project. It relates this product or service to both the business need for the product, and aligns the project with the strategic plan of the organization.

4.1.2 Business Case

There should be some sort of demand for the product or service, a demand that might be created by one or more of the following factors:

• Market demand
  
• Organizational need
  
• Customer request
  
• Technological advance
  
• Legal or regulatory requirement
  
• Social need
  

4.1.3 Contract

If the organization is to produce a product for an external customer, than a sample contract is an input to this process.

4.1.4 EEF

• Government or industry standards
  
• Organizational infrastructure
  
• Marketplace conditions (see input 4.1.2 Business Case)
  

4.1.5 OPA

• Organizational standard processes, policies, and definitions
  
• Templates (for project charter)
  
• Lessons learned database from previous projects
  

TOOL & TECHNIQUES

4.1.1. Expert Judgment

OUTPUTS

4.1.1 Project Charter

It makes sense that the output of the Create Project Charter process would be the Project Charter, right?

Important elements of the Project Charter include:

• Project purpose or justification
  
• Project requirements, assumptions and risks (high-level)
  
• Measurable objectives
  
• High-level schedule and budget summary
  
• Project manager assigned to project
  
• Sponsor approval
  

4.2 DEVELOP PROJECT MANAGEMENT PLAN

INPUTS

4.2.1 Project Charter

This input is actually the output from the previous process Develop Project Charter.

4.2.2 Output from other Planning Processes

It is important to note that this process takes all the management plans from the other Knowledge Areas and integrates it into the overall Project Management Plan. So the output from the Planning Processes becomes the input for this process.

4.2.3 EEF

Project information management tools, organization culture and infrastructure, and personnel administration (for figuring out what people are needed for project).

4.2.4 OPA

Templates from previous projects, lessons learned and other documents from previous projects, etc.

TOOLS & TECHNIQUES

4.2.1 Expert Judgment

OUTPUTS

4.2.1 Project Management Plan

Again, it makes sense that the output of the Develop Project Management Plan is, of course, the Project Management Plan. Important elements of the Project Management Plan include:

• Project life cycle: will the project be broken up into phases for better control?
  
• Determine team: who will be needed to work on the project?
  
• The how to execute and control the project in order to accomplish the objectives
  
• Change management (how will changes to the project be managed?), and configuration management plans (how will changes to the product be managed)?
  
• Performance baseline (scope baseline, cost baseline, schedule baseline)
  

4.3 DIRECT AND MANAGE PROJECT EXECUTION

INPUTS

4.3.1 Project Management Plan

Again, note how the output to the previous process is now the input to this process.

4.3.2 Approved Change Requests

Perform Integrated Change Control (process 4.5) is where requests for changes are approved or rejected. If the output of that process is that the status of the change request is “APPROVED”, then those changes are inputs to work on the project as represented by this particular process, Direct and Manage Project Work.

The diagram below should illustrate this relationship.

4.3.3 EEF

In addition to the usual suspects under EEF (company culture, project management information system), an interesting item for this process in particular is

• Stakeholder risk tolerances
  

This helps in planning how to direct and manage the project work within the risk tolerances specified by the stakeholders.

4.3.4 OPA

Process measurement database from previous projects is particularly helpful here so that measurable data on the processes can be developed.

TOOLS & TECHNIQUES

4.3.1 Expert Judgment

4.3.2 Project Management Information System

OUTPUTS
4.3.1 Deliverables

Of course, the whole purpose of project execution is to execute the work as specified in the plan in order to produce the product, service or result, also known as the deliverable.

4.3.2 Work Performance Information

This is information on the status of the deliverable, plus information on the costs incurred (AC or actual costs) as well as the schedule progress (which is obtained by comparing the PV or planned value to the EV or earned value).

4.3.3 Change Requests

If during the course of executing the project, issues develop that require a change to the scope, budget, or schedule, or quality, then change requests are developed. Note that the change requests are made in the Executing Progress Group, but are evaluated and either accepted or rejected as part of the Monitoring & Controlling Progress Group. If they are accepted, these changes get fed into the Executing Progress Group once again.

4.3.4 Project Management Plan Updates

During the course of the execution of the project, the project management plan may needs to be updated.

4.3.5 Project Document Updates

Issue logs, risk registers, and stakeholder registers may need to be updated during the course of execution of the project.

The next post will cover the Inputs & Outputs to processes 4.4 through 4.6 in the Integration Knowledge Area.

Filed under: Uncategorized |