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 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.

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:

https://4squareviews.com/2013/03/07/5th-edition-pmbok-guide-project-statement-of-work-vs-project-charter/

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.

Filed under: Uncategorized | 2 Comments »

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

For a review of the following two processes and their tools & techniques, please see previous posts (look in the search function under “Chapter 4”).     As usual, the generic inputs EEFs stand for “Enterprise Environmental Factors” and OPAs stand for “Operational Process Assets.”

3.  Outputs of Integration Knowledge Area processes 4.5 and 4.6

We will discuss the outputs of the processes first before the inputs.

a.  Approved change requests (4.5 Perform Integrated Change Control)

Since the purpose of the process is to take change requests, analyze them and then either approve or reject them, it should make sense that this is the most basic (and most important) of the outputs of the process.

b.  Change log (4.5 Perform Integrated Change Control)

What happens if the change is rejected instead of approved?    It gets captured in the change log, which lists the details of all proposed changes, and whether they are approved or rejected.  If they are rejected, the reason for the rejection is given.

c.  Project management plan updates (4.5 Perform Integrated Change Control)

The changes to the project may require the adjustment of other constraints.   Both the changes and the other adjustments made to accommodate them must be reflected in the performance baselines and the affected subsidiary plans that deal with those constraints.

d.  Project document updates (4.5 Perform Integrated Change Control)

All documents that are part of the formal change control process will be updated as the result of a change request.

e.  Final product, service, or result transition (4.6 Close Project or Phase)

The final product, service, or result is transferred from the organization that has done the project to either the customer or sponsor who requested it.

f.  OPAs

The OPAs that are updated as a result of the process 4.6 Close Project or Phase include:

• Project files (project management plan, risk registers, change management documentation)
• Project closure documents (customer acceptance documentation, financial closure documentation, etc.)
• Historical information (lessons learned, etc.) to be used on future projects

4.  Inputs of Integration Knowledge processes 4.5 and 4.6

a.  Project management plan (4.5 Perform Integrated Change Control)

In particular, the parts of the project management plan that are used as inputs for the process 4.5 Perform Integrated Change Control are:

• scope baseline (scope statement, WBS, and WBS dictionary)
• scope management plan (includes procedures for scope changes)
• change management plan (provides direction for managing the change control process and documents the format change control board or CCB)

The parts of the project management plan that are used as inputs for the process 4.6 Close Project or Phase are:

• The agreement between the project manager and project sponsor on what constitutes successful project completion

b.  Work performance reports (4.5 Perform Integrated Change Control)

Earned value measurement reports and reports about resource availability.

c.  Change requests (4.5 Perform Integrated Change Control)

These are what are to be analyzed and either approved or rejected as part of this process.

d.  EEFs (4.5 Perform Integrated Change Control)

• Project management information system (Microsoft Project, Primavera, etc.)

e.  OPAs

The OPAs that are inputs of the process 4.5 Perform Integrated Change Control include:

• Change control procedures
• Procedures for approving and issuing change authorizations
• Process measurement database (measurement data on processes and products)
• Project documents (performance baselines, project calendars, project schedule network diagrams, risk registers, planned risk response actions, and defined risk impacts)

The OPAs that are inputs of the process 4.6 Close Project or Phase include:

• Project or phase closure guidelines or requirements
• Historical information and lessons learned knowledge base

f.  Accepted deliverables (4. Close Project or Phase)

The documentation for accepted deliverables may include such items as

• approved product specifications
• delivery receipts
• work performance documents

That covers the inputs and outputs for the last two processes of the Integration Management Knowledge Area.  The next post will start the same coverage of the inputs and outputs of the next chapter of the 5th Edition of the PMBOK Guide, Scope Management.

Filed under: Uncategorized | Leave a comment »

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

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 | Leave a comment »

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

3.  Outputs of Integration Knowledge Area

Let’s go backwards and start with the Outputs first–they are usually more obvious than the inputs.

a.  Project charter (4.1 Develop Project Charter)

Okay, it should be fairly obvious that the output of the “4.1 Develop Project Charter) process is going to be the “Project charter”.    The project charter is the document issued by the project initiator or sponsor that formally authorizes the project.  It documents business needs, assumptions, constraints, and the customer’s needs and high-level requirements.    These collectively can be considered the “high-level boundaries of the project.”

b.  Project management plan (4.2 Develop Project Management Plan)

Likewise, it should be fairly obvious that the output of the “4.2 Develop Project Management Plan” is going to be the “Project Management Plan.”   It consists of

• all of the management plans from all the other 9 knowledge areas
• the 3 project baselines (scope, schedule, and cost baselines)
• subsidiary management plans (requirements management plan, process improvement plan, change management plan, configuration management plan

It is the detailed description of how the plan will be carried through the execution and monitoring & controlling process groups to the end of the project.

4.  Inputs of Integration Knowledge Plan

Okay, now that the outputs are clear from the names of the processes, let’s see if we can look at the inputs for each process.

a.  Project Statement of Work (SOW) (4.1 Develop Project Charter)

The Project Statement of Work, sometimes referred to as an SOW, is the “seed” of the project, and it contains a high-level description of the products or services to be delivered by the project.

b.  Business Case (4.1 Develop Project Charter)

There should be some sort of business need 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

The business case ties together the product together with the business need (to show that there is a market for the project) and a cost-benefit analysis (to show that the benefits will outweigh the costs) to show that the results of the project will be aligned with the strategic plan of the company.

c.  Agreements

If the organization is to produce a product for an external customer, than a contract, memorandum of understanding (MOU), or other written agreement is an input to this process.

d.  Environmental Enterprise Factors or EEFs (4.1 Develop Project Charter)

• Government or industry standards
• Organizational culture and structure
• Marketplace conditions

These give the environment in which the project takes place.

e.  Organizational Process Assets or OPAs (4.1 Develop Project Charter)

• Organizational standard processes, policies, and process definitions
• Templates (for project charter template)
• Historical information and lessons learned database

These give the documentation on which the project processes are based.

f.   Project Charter (4.2 Develop Project Management Plan)

This is a typical pattern, where the output of one process (4.1 Develop Project Charter) becomes the input to the next process in the sequence (4.2 Develop Project management Plan)

g.  Outputs from other processes (4.2 Develop Project Management Plan)

Since the Project Management Plan is really not one single plan, but an coordination of all the other management plans throughout the 9 other knowledge areas, it makes sense that one of the inputs is going to be … all the other management plans.  That’s what this input stands for.

h.  Environmental Enterprise Factors or EEFs (4.2 Develop Project Management Plan)

• Government or industry standards
• Project management body of knowledge for application area
• Project management information system (e.g., Microsoft Project, Primavera)
• Organizational culture
• Infrastructure
• Personnel administration

These give the environment in which the project takes place, either those external to the organization (the first two) or those internal to the organization (the last four).

i.  Organizational Process Assets or OPAs (4.1 Develop Project Management Plan)

• Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria
• Project management plan template
• Change control procedures
• Project files from previous projects
• Historical information and lessons learned knowledge base
• Configuration management knowledge base

These give the documentation on which the project processes are based.   Since the Integration Knowledge Area is where all the changes to the project are managed, the subsidiary plans from the change management plan (change control procedures) and the configuration management plan (configuration management knowledge base) are inputs to this process.

With the inputs and outputs, it is harder to actively memorize them, in the sense of being able to recall a list of them given the name of any particular process.    It is sufficient for the purpose of the PMP certification exam, however, to be able to recognize them passively, so that given a list of 4 possibilities, you can pick the one that most likely applies to any given process.   In order to do this, understanding the purpose of the process, plus the tools & techniques used in this process, should be sufficient.

The next post will cover the next two processes in the Integration Knowledge Area, 4.3 Direct and Manage Project Work and 4.4 Monitor and Control Project Work.

Filed under: Uncategorized | Leave a comment »

This series of posts take the Ken Wilber’s introduction to Integral Theory called A Brief History of Everything and discusses the 12 main tenets concerning the concept of a holon and how they can be applied to the field of project management.   This is the last post in the series, and it covers tenet #12.

1.  Recap–definition of a holon, and tenets #1-11

A holon is an entity which consists of components, and yet is itself a component of a larger whole.

Tenet #1. Reality as a whole is not composed of things or processes, but of holons.

Holons must be considered from the standpoint of interacting with other holons on the same level, and with holons at higher levels (of which the holon is just a part) and lower levels (which comprise the parts of the holon).

Tenet #2 Holons display four fundamental capacities: The horizontal capacities of self-preservation, self-adaptation, and the vertical capacities of self-transcendence and self-dissolution.

Holons follow the dual rules of evolution when it comes to holons at the same level:    survival of the fittest (self-preservation) and survival of the fitting (self-adaptation).    Holons have the property of being able to evolve to the next highest level (self-transcendence), and they can also “devolve” into their component parts (self-dissolution).

Tenet #3 Holons emerge

As mentioned in Tenet #2, holons have the property of self-transcendence or evolution to the next highest level.    This is not just a higher degree of organization, but also involves emergent properties or differences in kind from the level below.

Tenet #4 Holons emerge holarchically

Holons, as seen above, are units that are both wholes containing parts and parts of larger wholes.   This kind of nested or concentric linking of holons reminiscent of the Russian matroshka dolls is considered a holarchy.    In contrast, we see in an organizational chart the traditional notion where parts are linked vertically to the levels above them (the notion of hierarchy), and horizontally to the units at the same level (the notion of a heterarchy).

Tenet #5  Each emergent holon transcends but includes its predecessor(s)

When a higher level of holons emerges, it incorporates the holons from a lower level but adds emergent properties.  A cell contains molecules, but is an entity which is capable of reproduction, where a property that goes above and beyond what a mere collection of molecules could do on its own.

Tenet #6  The lower sets the possibilities of the higher; the higher sets the probabilities of the lower.

Tenet #5  tells us that the higher level of holon has emergent properties which go above and beyond the lower level.  However, tenet #6 says that the higher level cannot ignore the lower level, and it there is bound to a certain extent by the possibilities set by the holons of the lower level.  However, the higher level also affects the lower level in that, the order imposed by the higher level of holons will influence the patterns in which the lower levels interact.

Tenet #7–The number of levels which a hierarchy comprises determines whether it is “shallow” or “deep”; and the number of holons on any given level we shall call its “span.”

Tenet #8  Each successive level of evolution produces GREATER depth and LESS span

This tenet follows from tenet #7 if you think about the definition of “depth” and “span” of a concentrically organized system of a holarchy.   Ken Wilber makes this point because if you look at the concentric diagrams of any holarchy, the circle containing the highest level of organization is going to be on the outside, and the visual impact is that it has greater “span” in terms of area.    He is simply emphasizing the fact that span refers to the number of holons at the same level; the reason why the circle is so large is so that it can encompass the lower levels inside of it.    The fact that the largest circle, representing the holon at the highest level, has several circles within it actually means that it has the greatest depth because it includes the most levels or holons (represented by the nested series of circles inside of it).

Tenet #9  Destroy any type of holon, and you will destroy all of the holons above it and none of the holons below it.

The lower level of holon, while having less depth than the higher level (based on tenets #7 and #8), is nonetheless more fundamental for precisely the reason mentioned in the tenet.   If you get rid of the lower level of holon, you are in fact getting rid of the very components of the higher level.

Thus the higher level is more significant, in terms of adding coordination and direction to the lower level of holons, but the lower level of holons are more fundamental to the enterprise, because without them, there would BE no higher level of holons.   In terms of project management It is very important to remember as a project manager, that despite the significance of all that you do as a manager of the project, and despite the fact that the project charter and your authority has to be sponsored by management, without the team members you would not have a project at all.   They are truly fundamental to the project’s success; that is why you must take care of the members of your team.

This tenet is, therefore, a lesson in humility and a warning against humiliation of any the members of your team for having made mistakes.    Failure is to be seen as an opportunity to learn, not to be cast in terms of blame or moral failing.    By understanding that the team member is more fundamental to the project than you are as the project manager, the more likely you will treat that team member with the respect that he or she deserves.     Once you do so, you will be surprised at how much more engaged that team member will be in the success of the project.

Tenet #10–Holarchies coevolve

Recall that a holon is an entity which is both a whole and a part of a larger whole, and a holarchy is that concentric nesting of holons at higher levels.    What does “coevolve” mean?    An individual holon exists in an environment, and it evolves to fit into the environment.   When the environment changes, the holon must also change in order to maintain its fitness.

What does tenet #10 mean in the context of project management?    Every project manager exists in a system of best practice regarding project management which is codified by the Project Management Institute into the Project Management Body of Knowledge or PMBOK®.   In order to survive in the fast-changing world of project management, the project manager must evolve as well through training, which is the whole point of the PDU system of continuing education.

Another example of the principle espoused in tenet #10 that “holarchies co-evolve (with their environments)” is the fact that companies in a certain application area need to evolve as the industry in that application area evolves.    The rapid growth of agile methodology in products involving IT development is a great example of this.    The recognition of the growing importance in the IT industry of agile methodology has meant that PMI is developing a new, separate category of certification called PMI-ACP or PMI-Agile Certified Practitioner to meet this demand for agile methodology.

Tenet #11–The micro is in relational exchange with the macro at all levels of its depth.

The first step in understanding this tenet is to figure out what “micro” and “macro” refer to when talking about a holon.    Each holon, say a person on a team, exists in a network of relationships with other holons at the same level of structural organization, in this case, other team members.    The “micro” referred to in the tenet means the “individual holon” and the “macro” refers to the “network of relationships with others holons at the same level of structural organization.”   Okay, each team member exists in a network of relationships with other team members.   So what?   Well, it should be obvious to a project manager that it is necessary for a successful project for the team members to have good relationships with each other, right?   So far, so good.

Where this tenet comes into play, is the insight that team members also exist in a network of relationships at higher levels of structural organization with the company–they are also members of certain functional departments, and they are also members of the organization as a whole as managed by upper management.     To maintain the success of a project, it is of course necessary to foster good relationships between team members, but it is not sufficient.   You must also foster good relationships between department members, and between members in relationship to upper management.

2.  Tenet #12–Evolution has directionality

Evolution is marked by creative emergence of novel properties, increasing depth  and greater consciousness, according to Ken Wilber.   That is why evolution tends in the following directions, which are related:

a.   Increasing complexity–emergence of new levels of holons which create new structures within the holon itself (between the various levels in the holon) and between holons at the same level.

b.  Increasing differentiation/integration–the structures between holons at the same level is the “differentiation”, whereas the structures between the levels of the holon is the “integration”

c.  Increasing organization/structuration–this is the consequence of increasing complexity (the “new structures” mentioned in paragraph a above).

d.  Increasing relative autonomy–this is the greater capacity for self-preservation in the midst of fluctuations in the environment

e.  Increasing telos (purpose)–the deep structure of a holon (the structures between the levels of the holon) acts an attractor for the actualization of the holon (the interaction between the holon and its environment).

The Project Management Office is something which many organizations aspire to create within their organization.   This is considered the ultimate step in “evolution” of project management within the organization.    However, because it is the holon or entity at the “top” level of organization of projects, its evolution must be solidly built up from the holons at the lower levels (project team members, project, program, portfolio).    There must be a coordination between holons at each level, and the different levels of the holon, so that the project manager coordinates the project team members, the program manager coordinates the projects, etc.    Although there is increasing complexity, Ken Wilber says that at the functional level there should be a simplification.    The Project Management Office therefore has to be guided by a mission statement or some other organizing set of principles so that if there are conflicting directions within the PMO, they can be ranked and then resolved by reference to this set of principles.

If this mission statement then harnesses the forces of the organization, the PMO can be a source of innovation, rather than a source of bureaucratic inertia that holds that innovation back.   This is what this tenet means to me, that the organization try to evolve a healthy set of relationships of these lower levels (between project team member and project manager, between project manager and program manager, between project manager and upper management) BEFORE the next step of evolution, the Project Management Office is attempted.    The PMO must be evolved, rather than imposed upon an existing organization structure, or it will not work organically (between the various levels of project management) as it was meant to.

This is the last of the posts on the twelve tenets of Integral Theory, showing how they can be applied to project management.   It has been a learning exercise for me to see how Integral Theory can be applied to any field of knowledge, including that of project management.    It holds together a lot of piecemeal observations I have made about project management in one single framework, and for that reason, it is a worthwhile tool.    I hope it generates new ideas not just for me, but for those who have read this series of posts.

Filed under: Uncategorized | Leave a comment »

This is a post on the documentary Harvest of Empire: the Untold Story of Latinos in America, that was presented at the Unitarian Universalist Church of Park Forest, Illinois on Saturday, October 26th.

The movie was based on the book of the same name written by Juan Gonzalez, the co-host with Amy Goodman of the Democracy Now program.    The documentary showed  7 separate stories of migration of Latinos from the Caribbean, Mexico, and Central America to the United States.     The first four stories listed deal with the consequences of the United States’ covert actions to install dictatorships in formerly democratic countries.    The last three deal with the territorial expansion of the United States into territory formerly held originally by Spain, but then by the republics which rebelled against Spain like the United States rebelled against Britain.

1.   Dominican Republic

Rafael Trujillo was the dictator of the Dominican Republic who ruled with an iron fist from 1927-1961.   When he was assassinated in May 1961, there was a period of instability which lasted for four years.    When Juan Bosch won the elections were held in December 1962, his leftist policies led to a right-wing military coup led by Colonel Elias Wessin.   The rebellion against the coup ushered in a period of U.S. military intervention from 1965-66.    True democracy was not restored until 1998.

2.  Guatemala

After World War II, Guatemala had free, democratic elections, but in 1951, Jacobo Arbenz Guzman adopted a major land reform policy, which led to a military coup in 1954 orchestrated by the CIA.   A bloody civil war ensued for the next few decades which only ended in 1996.

3.  Nicaragua

Nicaragua suffered for 43 years under the hereditary dictatorship of the Somoza family.   This ended in July 1979, when the Sandinistas took power and then won in general elections in 1984 which were accepted by the Carter administration, which tried to work with the new government.    However, the following Reagan administration, after first floating the idea of military intervention which garnered widespread opposition in the United States, decided that “two wrongs make a right” in the infamous Iran-Contra scandal, where he negotiated with the Iranian government to supply them with weapons to fight against Saddam Hussein in Iraq in return for the funding of a paramilitary group called the Contras whose mission was to overthrow the Sandinistas.

Only recent years have brought some measure of economic growth and political stability.

4.  El Salvador

In 1979, a coup d’etat brought Napoleon Duarte out of exile, and this started a period of brutal oppression through so-called “death squads” or paramilitary groups that were designed to spread any leftist insurrection.    When Archbishop Oscar Romero started criticizing the policies of the government, he was assassinated.    The conflict in El Salvador spilled over into neighboring Honduras, threatening to engulf the entire region into the conflict.   Only the economic reforms of 1990s have brought some measure of stability to the country.

In the above four countries, political turmoil aided and abetted by the United States led to the overthrow of democratic governments.   These were replaced by authoritarian regimes that created such a nightmare of brutality that many people ended up not immigrating to the United States as a matter of seeking a better economic opportunity, but rather fleeing for their very lives.

And yet the number of applications for immigration that were accepted on the basis of “political asylum” were abysmally low, usually less than 5%.    The immigration of these groups were birthed from an atmosphere of national trauma, in the middle of which those who made it to the United States now confronted a country that was indifferent to their plight.

In the case of the following three countries, the expansion of the United States into territory that was originally claimed by Spain and later by the Latin American Republicans which they gave birth to, meant that as opposed to other immigrant groups which came to the United States, these groups had the borders of the United States and its empire come to them.

The irony is that, at times of a labor shortage such as during World War II in the other states, the immigrant populations created a safety valve which helped stabilize the economy in the United States during times of expansion.    However, during times of economic reversal, like the one we are experiencing now, there is great political pressure to put up barriers to legal immigration, pressure which is encouraged by a “divide and conquer” strategy of having the economically disadvantaged fight against either other rather than cooperating with each other to change the economic equation more in their favor.

5.  Puerto Rico

Being an unincorporated territory of the United States, Puerto Rico has enjoyed a “grey” status of neither state, nor separate country, but somewhere in between.    You can technically speak only of “migration” of Puerto Ricans to the United States, since they are already citizens.

6.  Cuba

Alone of all the other political upheavals in the Caribbean, this was a leftist revolution which was NOT able to reversed.   This time the immigration came from relatively well-to-do Cubans who were fleeing the communist regime.    They set up in Miami, Florida, and a once sensecent city has turned into one of the most vibrant Latino towns in the United States.

7.  Mexico

Mexico has the most ambiguous status, since many of those who were of Mexican heritage were here BEFORE the settlers came in from the East.    So the phrase that many nativists use,  “go back where you came from”, has a uniquely ironic ring for many Mexicans.    They are the largest immigrant group of all of those that come from Latin America.

Taken together, these groups and others from Latin America form the fastest-growing minority, and the present-day status of LA, where whites are the minority, is what will happen in the future in the U.S.  by the year 2050.    For someone like me, who believes in the strength that of this multi-cultural, multi-ethnic to assimilate new gropus, this is not a negative future to be feared but an opportunity to be welcomed.    We in this country have so many connections through immigration with so many countries in the world, that we have a unique window into the culture of the world that should be celebrated.

However, the demographic trend towards a larger Latino population in the United States has caused a lot of resistance in the Republican party, which currently is on the record of opposing immigration reform.    It is a measure of the rightward shift in this country that the accommodation of Latinos in Texas was something that was supported by George Bush, but was treated as anathema by Republican candidates for the Presidency in 2012.

The solutions to this potential inter-ethnic conflict in the United States between the growing minority of Latinos and the rest of the country are “radical,” according to the capsule summary by Kenneth Maxwell of Foreign Affairs referenced below

http://www.foreignaffairs.com/articles/56082/kenneth-maxwell/harvest-of-empire-a-history-of-latinos-in-america

These include three positive measures

• complete labor mobility between the United States and Mexico to end the “predatory” market in cheap Mexican labor;
• recognition of minority language rights;
• investment in U.S. cities and public schools;

and three measures to put an end to

• U.S. militarism,
• Puerto Rico’s colonial status, and
• the blockade of Cuba.

The Trans-Pacific Partnership now being discussed in secret between Washington and other trade partners is like “NAFTA on steroids” and goes in the complete other direction of complete capital mobility.     Juan Gonzalez makes the point that it is not only in the interest of Latinos to have these policies mentioned above implemented, but also in the interest of the Anglos as well.

I agree, and my own family history having connections with Honduras (my uncle lived there for many years in the 1960s) I find that this story of Latinos is also, indirectly, my story as well, and one which needs to be told to EVERYBODY.   I intend to get Juan Gonzalez’ book and study this in more detail.   I’m glad the church put on this film to tell the story to a sympathetic audience.    But it takes more than empathy, which is based on a commonality of feeling; it also takes a definite thinking component of understanding to realize what the immigrants from Latin America have gone through, so that we can see them as neighbors who have much to teach us, and as allies in our struggle for a better economic future for all Americans, no matter what country they have come from.

Filed under: Uncategorized | Leave a comment »

1. Introduction

This series of posts assumes that you have already memorized the names of the 47 project management processes, and you are ready to go on to the task of memorizing the tools & techniques.    This post covers chapter 13 of the 5th Edition PMBOK® Guide, the Stakeholder Knowledge Area.

2.  Stakeholder Management Processes

Here is a list of the 4 procurement management processes, together with a brief description and a list of the tools & techniques used in those processes.

3.   Stakeholder Management Tools & Techniques

Here is a closer look at the tools & techniques used in the stakeholder management processes.

a.  Stakeholder Analysis (13.1 Identify Stakeholders)

Systematically gathers and identifies information to determine which stakeholder’s interests should be taken into account during the project.

b.  Expert judgment (13.1 Identity Stakeholders, 13.2 Plan Stakeholder Management, 13.4 Control Stakeholder Engagement)

The judgment of those with expertise in the stakeholders on the project, in particular, senior management, functional unit managers, and project managers who have worked on previous projects.

c. Meetings (13.2 Plan Stakeholder Management, 13.4 Control Stakeholder Management)

Used to define the required engagement levels of all stakeholders on the project.

d.  Analysis, analytical techniques (13.1 Identify Stakeholders, 13.2 Plan Stakeholder Management)

The current engagement level of the stakeholders is compared to the desired engagement level.

e.  Communication skills (13.3 Manage Stakeholder Engagement)

The methods of communication identified in the communications management plan are used for each stakeholder.

f.  Interpersonal skills (13.3 Manage Stakeholder Engagement)

Used to manage stakeholder’s expectations.

g.  Management skills (13.3 Manage Stakeholder Engagement)

Used to coordinate and harmonize the group toward accomplishing the project objectives.

h.  Information management systems (13.3 Manage Stakeholder Engagement)

Used to capture information on project progress and distribute it to stakeholders as set forth in the communications management plan.

“Stakeholder analysis” is a technique used in 13.1 Identify Stakeholders to a) identify who the stakeholders are and b) to determine their general interest and impact on the project.   This is a preliminary analysis in the initiating process group done to determine the general strategy of how to deal with the stakeholder:   Manage closely, keep satisfied, keep informed, or monitor (listed from greater to lesser level of engagement).   “Analysis” and “analytical techniques” are more specific in that they are used to determine the desired level of engagement with each stakeholder.    “Expert judgment” is used to determine the actual  level of engagement, and the purpose of all of the tools & techniques with the word “skills” such as communication skills, interpersonal skills, and management skills, are used to try to bring the actual level of engagement in line with the desired level of engagement.

4.  Conclusion

This is the last of the knowledge areas, and once you understand the basic concept of the processes, to determine the actual level of engagement and bring it in line with the desired level, the tools & techniques are pretty easy to understand.

This concludes stage 5 of memorizing the processes.   Next Monday I will start on the final step, which is memorizing the inputs and outputs.   This is kind of a misnomer, because you will not be expected to actively remember each of the inputs and outputs for any given process, but you should be able to passively recognize from a list of inputs and outputs, which one is the one that pertains to that given process, given the tools & techniques that go with it.    It is a longer, more involved set of posts, because of the sheer number of inputs & outputs involved, so each knowledge area will be covered in 2 or more posts.

Filed under: Uncategorized | Leave a comment »

1. Introduction

This series of posts assumes that you have already memorized the names of the 47 project management processes, and you are ready to go on to the task of memorizing the tools & techniques.    This post covers chapter 12 of the 5th Edition PMBOK® Guide, the Procurement Knowledge Area.

2.  Procurement Management Processes

Here is a list of the 4 procurement management processes, together with a brief description and a list of the tools & techniques used in those processes.

3.   Procurement Management Tools & Techniques

Here is a closer look at the tools & techniques used in the procurement management processes.

a.  Make-or-buy analysis (12.1 Plan Procurement Management)

This decides whether a particular part of the project can be accomplished by the project team or should be purchased from outside sources.   After all, if no procurements are needed and the entire project can be done by the project team, then there is no need for procurements management.    This knowledge area is then the only truly optional knowledge area in that there are some projects for which it is not needed.

b.  Expert judgment, meetings (12.1 Plan Procurement Management, 12.2 Conduct Procurements)

By now, you should be familiar with the fact that when you doing a planning process, you are doing knowledge gathering to develop the management plan.    That’s where expert judgment comes in, by asking the people who either are expert at a certain subject matter area, in this case procurement management, or who are expert regarding procurement management with similar projects in the past.

In this case “meetings” can refer to meetings of the project team to develop the management plan, but it can also include meetings with potential bidders to exchange information, a process which is continued in the 12.2 Conduct Procurements process.

c.  Market research (12.1 Plan Procurement Management)

This is an examination of the capabilities of vendors within the industry in general, and specific vendors that would be possible candidates for vendors on this specific project.

d.  Bidder conference (12.2 Conduct Procurements)

These are meetings between the buyer and all prospective sellers prior to the submittal of a bid or a proposal.   The purpose is to ensure that all prospective sellers have an understanding of the procurement requirements before they submit their bid.

e.  Proposal evaluation techniques (12.2 Conduct Procurements)

This is the formal evaluation review process when bids are received, based on criteria that developed during the 12.1 Plan Procurement process.

f.   Independent estimates (12.2 Conduct Procurements)

One tool for evaluating the bids when they are received from prospective sellers, is to have an independent estimate of the costs of doing the work involved with the procurement.    This will give a “ballpark” figure against which to evaluate the various bids.

h.  Advertising (12.2 Conduct Procurements)

Existing lists of potential sellers can be expanded through advertisements in appropriate newspapers or specialty trade publications.

i.   Analytical techniques (12.2 Conduct Procurements)

These are ways of analyzing the vendor’s capabilities to do the work, often on the basis of past performance of that vendor on previous procurements,

j.   Procurement negotiations (12.2 Conduct Procurements, 12. 4 Close Procurements)

These negotiations are for working out the terms of the procurement agreement with sellers selected in the bidding process, in order to finalize the procurement contract.

k.  Contract change control system (12.3 Control Procurements)

This is the process by which the procurement may be modified by mutual agreement of the buyer and seller.    This contract change control system is incorporated into the integrated change control system for the project at large.

l.  Procurement performance reviews (12.3 Control Procurements)

This is a structured review of the seller’s progress during the course of the procurement to make sure that the work is progressing as per the terms of the procurement contract.

m.  Inspections and audits (12.3 Control Procurements)

These may be required by the buyer to verify compliance of the seller’s work processes and the quality of the deliverables.    The difference between this and the “procurement performance reviews” described in paragraph l above is that the procurement performance reviews may be passed passively on information supplied by the seller; the inspections and audits are more active methods of monitoring progress that are conducted by the buyer, either by the buyer’s own procurement personnel or done by independent personnel agreed upon by both parties.

n.  Performance reporting (12.3 Control Procurements)

This is ongoing reporting of the work done by the seller as compared to the agreement requirements.   It is the most passive form of monitoring of compliance in that it is simply information that is supplied on a regular basis to the buyer.    This may form the basis of the buyer’s structured procurement performance review as described in paragraph l above.

o.  Payment systems (12.3 Control Procurements)

This is the accounts payable system of the buyer, which is coordinated with the certification of satisfactory work done in accordance with the procurement contract.

p.  Claims administration (12.3 Control Procurements)

If a change is suggested in the contract control change system referred to above in paragraph k, but the change cannot be mutually agreed upon by the buyer and seller, or compensation for the change cannot be agreed upon, then this contested change becomes a “claim, dispute, or appeal” that must be resolved through an agreed upon mechanism, either through negotiations between the parties themselves or through an alternative dispute resolution (ADR) process.

q.  Records administration system (12.3 Control Procurements, 12.4 Close Procurements)

This is the management of contract and procurement documentation and records, and the system contains an archive of contract documents and correspondence.

r.  Procurement audits (12.4 Close Procurements)

This is a structured review of the procurement process at the completion of the procurement.    It differs from the “inspections and audits” referred to in paragraph m above in that it is contingent upon the satisfactory completion of the procurement contract.   The purpose is for contribution to a “lessons learned” document for future procurements.

The procurement tools and techniques to be used should be relatively straightforward as to which process they belong to; there are only a few which belong to multiple processes (such as the records administration system, used for both monitoring & controlling, and for closing the procurement).

Some of these tools & techniques will be used with most types of procurements, such as the bidder conference, whereas some tools & techniques offer a range of options for the company to choose from (such as performance reporting, inspections and audits, and structured performance reviews).

The next post will be on the LAST chapter of the 5th Edition PMBOK® Guide, namely, the 13th chapter on Stakeholder Management.   This knowledge area has been added in the 5th Edition, as an outgrowth of the Communications Knowledge area that goes beyond simply communicating with stakeholders, and actively engages them during the course of the project.

Filed under: Uncategorized | 1 Comment »

1. Introduction

This series of posts assumes that you have already memorized the names of the 47 project management processes, and you are ready to go on to the task of memorizing the tools & techniques.    This post covers chapter 11 of the 5th Edition PMBOK® Guide, the Risk Knowledge Area.

2.  Risk Management Processes

Here’s a description of the six processes that are included in the Risk Management Knowledge Area, together with a listing of the Tools & Techniques used in those processes.

c.  Documentation reviews, Information gathering techniques, checklist analysis (11.2  Identify Risks) “Documentation reviews” means a structured review of project documentation in order to identify possible risks on the project. Information gathering techniques include

• Brainstorming–generated by a group under the leadership of a facilitator
• Delphi techniques–reaches a consensus through the use of a questionnaire given anonymously to a group of experts
• Interviewing–one-on-one interviews of subject matter experts, experienced project participants, or stakeholders

“Checklist analysis” are risk identification checklists developed based on historical information regarding the industry and application area involved in a project. c.  Assumptions analysis, diagramming techniques, SWOT analysis “Assumptions analysis” explores the validity of assumptions as they apply to the project. Diagramming techniques include

• Cause and effect diagrams–also known as “fishbone” or “ishikawa” diagrams, used to identify causes of risks
• System or process flow charts–shows how elements of a system or process interrelate; used to identify the mechanism of causation of a problem
• Influence diagrams–graphical representations of situations showing causal influences, time ordering of events, and other relationships among variables and outcomes

SWOT analysis stands for the analysis of “Strengths-Weaknesses-Opportunities-Threats”, and is used to identify risks that come from within an organization and those that come from without. All of these techniques are used in the identification of risks as they not only identify risks but characterize what parts of the project they would effect.

d.  Risk probability and impact assessment, probability and impact matrix (11.3 Perform Qualitative Risk Analysis)

These tools are used to identify the a) probability of each risk of occurring, and b) its potential impact on the project.   At this stage, qualitative labels such as low/medium/high, or ranking on a scale from 1-10 are used to give a ranking along each dimensions for a given risk.   These two dimensions are then combined in a probability and impact matrix, which is used to give a risk rating to risks in order to prioritize them, and to give a general strategic response to that risk depending on where they fall in that matrix.

e.   Risk data quality assessment (11.3 Perform Qualitative Risk Analysis)

This assesses the accuracy of the data on the risks because low-quality risk data may be of little use to the project, and even worse, may harm the project due to inaccuracy of the data on which the risks were categorized.

f,   Risk categorization (11.3 Perform Qualitative Risk Analysis)

In preparing a risk to be put on the risk register, many features of the risk need to be understood, such as:

• sources of risk (using Risk Breakdown Structure)
• area of the project affected (using Work Breakdown Structure)

g.  Risk urgency assessment (11.3 Perform Qualitative Risk Analysis)

This assesses at which stage of the project the risk may be triggered.    Those risks that may be triggered at an earlier stage of the project have more urgency, as these near-term risks will need to have risk responses in place sooner than those risks which may occur later on in the project.   Some organizations combine not just the two factors of probability and impact, but they add a third factor of urgency to get an overall risk rating in order to prioritize risks.

h.  Data gathering and representation techniques (11.4 Perform Quantitative Risk Analysis)

When you have tools that have the word “Data” or “Quantitative” in them, you know you are dealing with 11.4 Perform Quantitative Risks Analysis).   Data gathering techniques regarding quantitative risk analysis include

• Interviewing–draws on historical experience with similar projects in the past to quantity the probability and impact of risks on project objectives
• Probability distributions–used in modeling and simulation techniques

i.  Quantitative Risk Analysis and Modeling Techniques (11.4 Perform Quantitative Risk Analysis)

These includes such techniques as

• Sensitivity analysis–determines which risks have the most potential impact on a project
• Expected monetary value (EMV) analysis–quantifies the potential impact on a project by taking the dollar value of the impact of a risk if it occurs and weighting it (multiplying it) by the probability of that risk occurring
• Modeling and simulation–Monte Carlo technique is when a project model (showing assumptions which affect the risk) is simulated many times to get the average impact of the risks over the course of the entire project

j.  Strategies for negative risks (11.5 Plan Risk Responses)

Based on the results of the probability and impact matrix done in the Perform Quantitative Risk Analysis process, these are the general risk response strategies for dealing with negative risks.

k.  Strategies for positive risks or opportunities (11.5 Plan Risk Responses)

Based on the results of the probability and impact matrix done in the Perform Quantitative Risk Analysis process, these are the general risk response strategies for dealing with positive risks.

k.  Contingent response strategies (11.5 Plan Risk Responses)

Some responses may be triggered only if certain events occur, and under certain predefined conditions.  Risk responses that are identified in this way are called contingency plans.

l.  Risk reasessment (11.6 Control Risks)

At various points on the project, it is a good idea to do a risk reassessment, which includes doing the following:

• identification of new risks
• reassessment of current risks (i.e., have the probability and/or potential impact changed)
• closing of risks that are outdated (because the events that would have triggered them did not occur)

m.  Risk Audits (11.6 Control Risks)

Rather than a reassessment of the risks, which is done in the the “risk reassessment” technique described in paragraph l above, risk audits examine the effectiveness of risk responses, as well as the effectiveness of the risk management process as a whole.

n.  Variance and Trend Analysis (11.6 Control Risks)

These types of analysis compare the planned results to the actual results.    If the risk management plan may include predefined levels of variance at which various actions must be taken, either corrective action or preventive action.

o.  Technical Performance Measurement (11.6 Control Risks)

As opposed to measurement of the scope, time or cost baseline, which is done in Variance and Trend Analysis (see paragraph n above), Technical Performance Measurement compares technical performance measures such as number of defects, transaction times, delivery times, etc.

p.   Reserve analysis (11.6 Control Risks)

If risks do occur, then the funds for risk responses come from contingency reserves if the risks are on the risk register.   If they are not planned risks (i.e., risks that are on the risk register), then ad hoc risk responses called “workarounds” must be developed and these come not from contingency reserves, which are under control of the project manager, but from management reserves, which as the name implies are under control of management that sponsored the project, and not under the direct control of the project manager. Once the risk responses are completed, the remaining contingency reserves are analyzed to see if they are adequate for the remainder of the project of if they need to be increased, in which case it should be reported to management.    If risk responses are not utilized because certain risks do not occur, then the excess in contingency reserves should also be reported to management, because this excess no longer being needed on the project, might be utilized for other projects in the organization.

4.  Conclusion

Risk management contains a wide variety of tools, but because the processes are relatively distinct in character, there are very few tools & techniques which are used on multiple processes (expert judgment, meetings for example are the only ones that come to mind).    In addition, for any given tool & technique, it should be fairly obvious which process it is associated with.   The real test of your knowledge will be for your to be able to think of at least 3 tools and/or techniques for each of the six processes.

The next post will be on the Tools & Techniques associated with the processes of chapter 12 of 5th Edition PMBOK® Guide, that covering the Procurement Management knowledge area.

Filed under: Uncategorized | Leave a comment »

1. Introduction

This series of posts assumes that you have already memorized the names of the 47 project management processes, and you are ready to go on to the task of memorizing the tools & techniques.    This post covers chapter 10 of the 5th Edition PMBOK® Guide, the Communications Knowledge Area.

2.   Communications Knowledge Area Processes

Here’s a description of the three processes that are included in the Communications  Knowledge Area, together with a listing of the Tools & Techniques used in those processes.

3.  Communications Knowledge Area Tools & Techniques

Here’s a closer look at the tools & techniques used in the communications knowledge area.   Many of these are used in multiple processes.

a.  Communications requirements analysis (10.1 Plan Communication Management)

This determines the information needs of the project stakeholders.

b.  Communication technology (10.1 Plan Communication Management, 10.2 Manage Communications)

Various factors are considered in choosing the communication technology to be used on a project:

• Urgency of the need for the information
• Availability of technology
• Ease of use
• Project environment
• Sensitivity and/or confidentiality of the information

c.  Communication models (10.1 Plan Communication Management, 10.2 Manage Communications)

The basic steps of a communication model are

• Encode
• Transmit message
• Decode
• Acknowledge
• Feedback/response

d.  Communication methods (10.1 Plan Communication Management, 10.2 Manage Communications)

The basic communication methods are

• Interactive communications (for a multidirectional exchange of information):   meetings, conference calls, videoconferencing, etc.
• Push communications (send to specific recipients who need to receive the information):  letters, memos, reports, e-mails, etc.
• Pull communications (for large amounts of information to be accessed by recipients as needed):  intranet sites, e-learning, etc.

e.  Expert judgment, meetings (10.1 Plan Communication Management, 10.3 Control Communications)

These are used in planning to make sure the various detailed aspects of the communication management plan are put into place.    During monitoring & controlling of communications, used to resolve problems, make decisions, and suggest changes to the project and/or communications management plan

f.  Information management systems (10.2 Manage Communications, 10.3 Control Communications)

This is a tool, not a technique, used to facilitate the other techniques and manage

• Hard-copy documents
• Electronic communications
• Electronic project management tools (Microsoft Project, Primavera, etc.)

g.  Performance reporting (10.2 Manage Communications)

This is the collection and distribution of performance information to tell the various interested stakeholders how the project is going.

This set of tools & techniques is relatively straightforward in terms of understanding why they are used with communications, because most of them even have the word “communications” in them.    The only caveat is that some of them are used for more than process.

The next post will cover the tools & techniques of the next chapter, chapter 11 of the 5th Edition PMBOK® Guide, that of the Risk Management knowledge area.

Filed under: Uncategorized | Leave a comment »