6th Edition PMBOK® Guide–Process 4.3 Direct and Manage Project Work: Outputs


In the last post, on Tools & Techniques for process 4.3 Direct and Manage Project Work, I mentioned that this process is where a lot of the budget of the project is spent.   The outputs of the process are not just the results of the process; they are about communicating those results to those stakeholders who matter the most, those who fund the project (i.e., the customer for external projects or upper management for internal ones).    Another important aspect of the results is the comparison between those results and the project plan.    Of course, this comparison is done explicitly during the Monitoring & Controlling processes, but it can be done in real time during the Executing processes as well such as this one.   These results on a project are referred to as deliverables.

If you compare a project being run to a ship traveling across the ocean, then the progress of a ship across the ocean is charted by several key variables such as the distance traveled (analogous to earned value), and the amount of fuel spent (analogous to the actual costs incurred).   These variables on a project are recorded as another important output, work performance data.

Now let’s say a naval officer is doing a quick inspection tour of the ship and comes across some safety hazards or other problems on board that could potentially cause injuries at some point in the future.    The officer can list these problems and take them to the executive officer or XO.   The equivalent of this list of problems on a project is the issue log, another important output.

If you notice the actual results are veering away from the plan, you don’t have to wait for a review meeting to start to take action.   If a sailor is watching out at the horizon and sees an iceberg heading straight for the ship, the sailor will alert the watch officer immediately and corrective action will be taken.    In a similar way, people on the project team who see a problem as it is occurring should alert the project manager, who can then order action to be taken (see paragraph below on change requests).

Now if there arises some sort of severe storm in the direction the ship is headed, the officers may decide to change the planned route of the ship in order to avoid the storm.   In a similar way, rather than changing the work to fit the plan (as with most change requests), the project manager may decide to change the plan to fit the work, especially if it is revealed during the execution of the work that the original project plan as conceived wasn’t, in fact, very realistic.   In this case the project management plan must be updated.

But in any case, even if there are no change requests made and the ship goes smoothly towards its destination, if there are any changes in conditions such as weather, these will be noted in the ship’s log, the equivalent of which on a project would be the project documents which must be updated, even they reflect a situation where everything is going perfectly according to plan.

Let’s talk more in detail about the outputs of process 4.3 Direct and Manage Project Work.

4,3,3 Direct and Manage Project Work:  Outputs

4.3.3.1 Deliverables

A deliverable is a unique and verifiable product, service or result that is completed as a stepping stone to complete the final product, service or result of the project that will be delivered to the customer.   They are the result of completion of work packages, the units of work that the project work is broken up into during the planning phase.

4.3.3.2  Work Performance Data

These are the measurements identified during activities performed to carry out the project work.   For example, today John worked 4 hours on the project and Jane worked 4 hours as well.   This is the lowest level of detail about project work and it is gathered during the Executing phase of the project.   This passes to the Controlling processes of the project where the actual work done is analyzed by comparing it to the work that was supposed to be done in the project plan.

4.3.3.3  Issue Log

Problems and conflicts that occur during the executing phase of the project are recorded and tracked in an issue log, where a project manager helps manage the issues so that they are investigated and resolved so that they do not impact the project performance.

4.3.3.4  Change requests

Change requests are formal proposals to modify any document, deliverable, or baseline.  Normally, these are thought of as being done as the result of the Monitoring & Controlling process called 4.5 Monitor and Control Project Work.   However, if a problem is uncovered during the Executing phase (as in this process 4.3 Direct and Manage Project Work), a change request may be made immediately to be considered in the way specified by the Change Management Plan, for example, by a Change Control Board.

There are several types of change requests.   The first three types are when the work is seen to differ from what it is the project plan.   These can be explained by analogy to Charles Dicken’s book A Christmas Carol.   In that book, Ebeneezer Scrooge is visited by three ghosts, the Ghost of Christmas Past, the Ghost of Christmas Present, and the Ghost of Christmas Future.   In a similar way, a project manager can be haunted by the specter of a defect or other negative impact in three ways:

He or she can be haunted by the Ghost of Defects Past, where a product component that has already been completed in the process 4.3 Direct and Manage Project Work is shown to be defective somehow.   The remedy?   Defect repair.

Now, what if the project manager is haunted by the Ghost of Defects Present, where the performance of the project work being done right now in the process 4.3 Direct and Manage Project Work is not in alignment with the project management plan?  The remedy:   Corrective action, an intentional activity that realigns the performance of the project work with the project management plan.

And finally, what if the project manager is haunted by the Ghost of Defects Future, where the performance of the project work is in danger of becoming unaligned with the project management plan at some point in the near future?   The remedy:  Preventive action, an intentional activity taken now that ensures that the future performance of the project work is aligned with the project management plan.

For the final category, rather than changing the work to fit the plan, what if in doing the project work in this process, it is discovered that the project management plan wasn’t very realistic after all?   Then, it is possible to do updates to the project management plan so that it is more realistic.   These change requests are covered in the next output.

4.3.3.5 Project Management Plan Updates

Any component of the Project Management Plan may be updated as a result of a change request.

4.3.3.6 Project Documents Updates

Now, besides changes to the work or to the project management plan, there may be other changes to project documents that are necessitated by things that happen during the executing of project work.   For example:

  • Activity list–additional activities may be added or activities may be modified.
  • Assumption log–if the original assumptions or constraints (specified in the project charter) have changed, the assumption log may be modified.
  • Lessons learned register–although this is normally updated during the next process 4.4 Manage Project Knowledge during the Monitoring & Controlling phase, if a lesson is learned during the course of the project work, it may be added to the lessons learned register right away, without even waiting for the following process.  As a reminder, a change request is a change to the product or to the project plan; lessons learned are changes to the process of doing the project itself.
  • Requirements documentation–during the course of work on the project, new requirements may be identified and added to this documentation.   In addition, the progress made in meeting the current requirements may be updated.
  • Risk register–new risks identified during the course of work on the project are added to the risk register.   Also, if a work package that entailed some risk is completed without incident, the risk associated with that work package is no longer in play and the risk register can be updated to reflect that.
  • Stakeholder register–if there are new stakeholders, or if the status of a stakeholder changes that might affect the analysis of that stakeholder, then these additions or changes are made.

4.3.3.7  Organizational Process Assets Updates

Organizational process assets or OPAs are the plans, processes, policies, procedures, and knowledge bases used by the organization performing the project.   If during the course of the project work, there are lessons learned (see the paragraph “Lessons learned register” in the last paragraph 4.3.3.6 Project Documents Updates) that may be useful outside of the current project, i.e., that suggest changes to the policies and procedures of the organization in general, then these OPAs may be updated as a result.   In this way, knowledge is transferred from the project team to the organization.

This transference of knowledge gained on the project to the organization in general is the subject of the next process 4.4 Manage Project Knowledge.   This is a new project management process for the 6th Edition of the PMBOK® Guide, and it is has its origins in Agile project management methodology.   For that story, please see the next post…

Advertisements

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s

%d bloggers like this: