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.
2. Review of Processes, Tools & Techniques in Integration Knowledge Area
| Process Name |
Tools & Techniques |
Inputs |
Outputs |
| 4.3 Direct and Manage Project Work |
1. Expert judgment
2. Project management information system
3. Meetings
|
1. Project management plan
2. Approved change requests
3. EEFs
4. OPAs |
1. Deliverables
2. Work performance data
3. Change requests
4. Project management plan updates
5. Project documents updates |
| 4.4 Monitor and Control Project Work |
1. Expert judgment
2. Analytical techniques
3. Project management information system
4. Meetings |
1. Project charter
2. Schedule forecasts
3. Cost forecasts
4. Validated changes
5. Work performance information
6. EEFs
7. OPAs |
1. Change requests
2. Work performance reports
3. Project management plan updates
4. Project documents updates |
3. Outputs of Integration Knowledge Area (for processes 4.3 and 4.4)
a. Deliverables (4.3 Direct and Manage Project Work)
The definition of a deliverable varies slightly from the 4th edition: a deliverable is a unique and verifiable product, result or capability to perform a service that is required to complete a process, phase, or project. The “verifiable” part is a new important part of the definition, because being able to measure success by comparing it to predetermined objective standards is key to being able to say to the organization that you actually have achieved it. In the 4th edition, the deliverable was described as a “unique product, result or service”, but now “service” has been replaced with the most accurate “capability to perform a service”. But this is more of a semantic change than anything of substance.
Now, in a Six Sigma project, rather than the deliverable being a unique product, the deliverable can be an improvement upon an existing process that in turn delivers a higher quality product (i.e., fewer defects). (Although this expanded definition of a project that includes Six Sigma Projects is not to be found in the glossary definition of “project” in the 5th Edition, it is included in the 1st chapter of the 5th Edition of the PMBOK® Guide.)
However, the “verifiable” part of the definition is also crucial to Six Sigma projects, because if you can’t prove that the improvement to the existing process actually results in fewer defects, than it cannot be considered a success. You may have to go back to the proverbial drawing board and come up with the correct root cause and come up with a new process to improve that will correct that.
One last clarification on deliverables: although the output of the process is a “verifiable product”, is the verifying done as part of the process 4.3 Direct and Manage Project Work? No! The verifying of the deliverable takes place in the process 8.3 Control Quality, a Quality Knowledge Area process. Once the deliverable is verified internally within the organization, it then goes over to the customer for them to validate it in the process 5.5 Validate Scope, a Scope Knowledge Area process. As mentioned before, many times the output of one process goes to the input of the next process in sequence within the knowledge area. For example, the Project Management Plan, the output of the process 4.2 Develop Project Management Plan, is an input to the next process in the sequence, 4.3 Direct and Manage Project Work. Where you have to be careful is where the outputs to a process skip over to some other knowledge area, and this is what happens in the case of deliverables.
b. Work Performance Data (4.3 Direct and Manage Project Work)
These are raw observations and measurements that are identified while the activities are being carried out to complete the project work. Examples of these are:
- Percentage work completed
- Key Performance Indicators (KPIs)
- Start and Finish Dates of Schedule Activities
- Actual Costs
- Actual Durations
They are the raw material from which work performance information is derived, which is knowledge that is deemed useful to stakeholders in informing them how the project is going, and is included in the output of the next process.
c. Work Performance Reports (4.4 Monitor and Control Project Work)
These reports include such things as status reports, memos, updates, and possibly recommendations based on work performance information (such as the results of earned value measurement calculations).
d. Change Requests (4.3 Direct and Manage Project Work, 4.4 Monitor and Control Project Work)
You may notice a variation between the work actually being done and what is in the project management plan either
a) while the work is being done, i.e., during the execution process, in which case they are an output of the process 4.3 Direct and Manage Project Work, or
b) during a scheduled milestone where you analyze where you are on the project, i.e., during the monitor & control process, in which case they are an output of the process 4.4 Monitor and Control Project Work.
You may decide that you need to either a) change the work to fit the plan or, if it turns out the plan wasn’t realistic, you may change the plan to fit the work. In either case, this will require you to make a proposed change or a change request.
The change request will be one of three types. Think of the story of the Christmas Carol by Charles Dickens, where Ebeneezer Scrooge was visited by three ghosts, the Ghost of Christmas Past, the Ghost of Christmas Present, and the Ghost of Christmas Future. In an analogous way, a project manager is haunted by three ghosts on a project:
- the Ghost of Defects Past, which are remedied through defect repair;
- the Ghost of Defects Present, which are remedied through corrective action;
- the Ghost of Defects Future, which are remedied through preventive action.
The output of these proposed changes or change requests, whether they occur as an output to 4.3 Direct and Manage Project Work or 4.4 Monitor and Control Project Work, are sent over as inputs to 4.5 Perform Integrated Change Control, where they are analyzed and either approved or rejected.
e. Project Management Plan Updates (4.3 Direct and Manage Project Work, 4.4 Monitor and Control Project Work)
Together with any change requests, there will be updates to the project management plan, especially if the change is to make the plan more realistic so that it conforms more to the work as it is actually being done. Remember that the project management plan is not really a single plan, but a conglomeration of the following baselines and plans:
- the three performance baselines related to scope, time and cost
- nine management plans covering all of the other knowledge areas
- four additional subsidiary management plans (change, configuration, process improvement, and requirements management)
f. Project Document Updates (4.3 Direct and Manage Project Work, 4.4 Monitor and Control Project Work)
Some of the project documents that may be updated together with these two processes are:
- schedule and cost forecasts (will the deadline be met, and will the project come in under budget if things keep going as they are?)
- work performance reports (updates to the output listed in paragraph c above)
- issue logs (to note issues that team members bring to the attention of the project manager as the project goes forward)
4. Inputs of Integration Knowledge Area (for processes 4.5 and 4.6)
The outputs are usually easier to recognize because once you understand what the process does, it is usually relatively easy to figure out what the output of that process will be. The project management plan is, for example, the output of the process 4.2 Develop Project Management Plan. Going in the other direction is somewhat more difficult. If I showed you a picture of a bunch of ingredients on a kitchen table, you might be able to guess at what the dish is I’m going to make. But if I ask you to taste the dish, you would have to be a pretty experienced chef to answer me if I ask you,”what are all the ingredients that went into it?”. So let’s get cooking!
In the case of this knowledge area of Integration, the inputs are relatively straightforward, and the exceptions are noteworthy. When I say “straightforward”, I mean specifically that they are often times the outputs of the previous process in the sequence. But when they come from somewhere else in the process matrix, it is important to note these “exceptions” because they are usually significant (like where the “change requests” go to and what happens to them if they get approved–or rejected).
a) Project Management Plan (4.3 Direct and Manage Project Work)
This is one of the regular inputs, that is, it is the output of the previous process in the sequence, 4.2 Develop Project Management Plan. In simple language, in this process you work the plan, after having planned the work in the previous one.
b) Approved change requests (4.3 Direct and Manage Project Work)
Okay, up in the section on Outputs, I mentioned that, if you see the need for changes in the work or the plan, the proposed changes or change requests may be an output of either 4.3 Direct and Manage Project Work or 4.4 Monitor & Control Project Work). In either case, they go to the process which is designed for one purpose and one purpose only, namely, to analyze those changes and decide whether or not to implement them. If they get rejected, then the rejected change requests gets recorded in the change management plan, together with the details of why it was rejected, for future reference. But if it is approved, then the approved change request gets fed as an input to this process, 4.3 Direct and Manage Project work, so that it can be implemented as part of the process.
c) Schedule Forecasts, d) Cost Forecasts (4.4 Monitor & Control Project Work)
This takes the schedule and cost variance information from earned value management, expressed either in terms of SV and CV or SPI or CPI, respectively, and compares it to the Estimate at Completion or EAC. This tells the project manager whether, according to the work as it is being done now, will result in the project coming in under budget and by the deadline date.
e) Validated Changes (4.4 Monitor & Control Project Work)
Okay, remember the “approved change requests” that went into 4.3 Direct and Manage Project Work to be implemented. They need to be validated to make sure that they are implemented correctly in the process 8.3 Control Quality. Then the output of that process, validated changes, are then input into 4.4 Monitor & Control Project Work.
NOTE: PMI employs some confusing terminology when it comes to the difference between validating and verifying. When it comes to deliverables, verifying deliverables means internally (i.e., within the organization) verifying to see whether they meet the scope and quality criteria set forth in those respective management plans as part of the overall Project Management Plan. Then they are sent over to the customer who validates the deliverables.
In the 4th Edition, these terms were switched around to meet the exactly opposite. To make things worse, when it comes to managing changes to the project as opposed to the deliverables, PMI calls that internal process (again, meaning within the organization as opposed to by the customer or sponsor) validating changes.
I suppose one way to sort this out is by saying that only the organization doing the project can validate whether the changes in the project were implemented or not, but the customer does have a say in whether the end product, the deliverables, meets the customer requirements. So in the case of deliverables, as opposed to changes in the project, there is a need to distinguish between internal verification and external validation. But how should you keep these terms straight? Here’s a memory tip I thought of a while back. When you go to an office building that has a parking garage, you get a parking ticket so that you can pay on the way out of the garage. When it is time to leave your appointment at whatever office you go to, what are the steps you go to on the way to your car? The customer you are visiting validates your parking, and then you yourself must verify by memory (or by a written note on the parking ticket, which is what I always do) where your car actually is in the garage. This may help you remember that the customer does the validation of the deliverables, whereas your organization does the verification.
f) Work Performance Information (4.4 Monitor & Control Project Work)
One of the outputs from 4.3 Direct and Manage Project Work is Work Performance Data, the raw data regarding the scope, cost and schedule which, once analyzed through Earned Value Measurement, gets turns into Work Performance Information. This is an input into this process of 4.4 Monitor & Control Project Work. Examples of this are:
- status of deliverables
- implementation status for change requests
- forecasted estimates to complete
Then after this process is complete, the output is Work Performance Reports, which are the Work Performance Information turned into reports which the stakeholders can receive and from which they can understand the status of the project.
g) EEFs (4.3 Direct and Manage Project Work, 4.4 Monitor & Control Project Work)
To do the work in 4.3 Direct and Manage Project Work, you need
- Organizational or company culture
- Infrastructure (facilities, equipment)
- Personnel administration
- Stakeholder risk tolerances (e.g., allowable cost overrun percentage)
- Project management information system (Microsoft Project, Primavera)
To monitor & control the project work in 4.4 Monitor & Control Project Work, you need
- Government or industry standards
- Organization work authorization systems
- Stakeholder risk tolerances
- Project management information system (Microsoft Project, Primavera)
h) OPAs (4.3 Direct and Manage Project Work, 4.4 Monitor & Control Project Work)
To do the project work in 4.3 Direct and Manage Project Work, you need
- Standardized guidelines, work instructions
- Communication requirements (including record retention guidelines, security requirements)
- Issue and defect management procedures (issue and defect controls, issue and defect identification and resolution, action item tracking) and databases (containing historical information from previous processes)
- Process measurement database (measurement data on processes and products)
- Project files from previous projects (performance baselines, risk registers, lessons learned documentation)
To monitor & control the project work in 4.4 Monitor & Control Project Work, you need
- Communication requirements
- Financial controls procedures (time reporting, expenditure and disbursement reviews, accounting codes, standard contract provisions)
- Issue and defect management procedures (issue and defect controls, issue and defect identification and resolution, action item tracking)
- Change control procedures (including those dealing with scope, schedule, cost, and quality variances)
- Risk control procedures (risk categories, probability and impact matrix)
- Process measurement database (measurement data on processes and products)
- Project files from previous projects (lessons learned documentation)
Don’t try to memorize inputs or outputs! Rather, get a stack of index cards and write the names of inputs and outputs on them. Then take sheets of paper that represent the six processes in the Integration Knowledge Area. After shuffling the index cards, read each input or output and put it on the process you think it goes with. You’ll be surprised how many you’ll guess right the first time, IF you take the time to understand what the process DOES and what TOOLS & TECHNIQUES it uses.
The next post covers the last two processes in this knowledge area, 4.5 Perform Integrated Change Control and 4.6 Close Phase or Project.
Filed under: Uncategorized | 1 Comment »
4squareviews 