4squareviews

 1. Introduction

In this next series of posts on memorizing the processes, we move on to the final step 6, which is memorizing the INPUTS & OUTPUTS associated with each of the 42 processes. In order to breakdown the memorization into more bite-size chunks, I am going to break down this topic into at least 9 posts, one for each knowledge area. (There may be some knowledge areas that require more than one post.)

 This post covers chapter 4 of the PMBOK® Guide, which covers the Integration Knowledge Area. This knowledge area contains 6 processes, with at least one process in each of the 5 process groups, with Monitoring & Controlling Process having two processes from this area.

 I am splitting the discussion of the Inputs & Outputs into two different posts; this post will cover Processes 4.4 through 4.6.

2. Review of processes in Integration Knowledge Area

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

3. Definition of inputs, outputs

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

4. Generic inputs

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

A. ENVIRONMENTAL ENTERPRISE FACTORS (EEF)

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

B. OPERATIONAL PROCESS ASSETS (OPA)

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

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

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

4.4 MONITOR AND CONTROL PROJECT WORK

INPUTS

4.4.1 Project Management Plan

The project management plan is what the performance of the project is going to be measured against.

4.4.2 Performance Reports

The performance reports show how the project is measuring up against the project management plan (4.4.1).

4.4.3 EEF

The usual suspect, the project management information system, is required. Just as in the executing phase, the shareholder risk tolerances need to be made aware of. Finally, the company work authorization system needs to be referenced as this process may end up producing change requests.

4.4.4 OPA

Lessons learned, risk control procedures, defect management procedures, etc.

TOOLS & TECHNIQUES

4.4.1 Expert Judgment

OUTPUTS

4.4.1 Change Requests

As a result of comparing the planned results (from the project management plan Input 4.4.1) to the actual results (from the performance reports Input 4.4.2), change requests may be issued. These could be actions to bring the results in line with the plan (changes to product deliverables), or it could be a change in the plan itself (changes to the project management plan).

Here are some change requests that affect the performance against the baselines.

However, as mentioned above, there could be changes which affect the project baselines themselves.

4.4.2 Project Management Plan Updates

Of course, if it is decided that the plan itself needs to be changed, then the Project Management Plan is updated. This could include any one of the component plans, or simply to one of the performance baselines (scope, schedule, or cost performance).

4.4.3 Project Document Updates

If issues are uncovered as a result of this monitoring and controlling process, then the issue logs will need to be updated. Also, forecasts of the overall budget (estimate at completion or EAC) and their comparison with the budget as originally planned (budget at completion) will need to be updated as well.

4.5 PERFORM INTEGRATED CHANGE CONTROL

First a word about the process of Perform Integrated Change Control. Just remember that there is configuration control, and change control. Change control refers to changes in the project work. Configuration control refers to changes in the deliverables or products that are the result of the project work.

INPUTS

4.5.1 Project Management Plan

The project management plan tells what the performance of the project is supposed to be.

4.5.2 Work Performance Information

The project management plan tells what the performance of the project actually is.

4.5.3 Change Requests

As a result of comparing the planned results (from the project management plan Input 4.4.1) to the actual results (from the performance reports Input 4.4.2), change requests may be issued. These could be actions to bring the results in line with the plan (changes to product deliverables), or it could be a change in the plan itself (changes to the project management plan).

Here are some change requests that affect the performance against the baselines.

However, as mentioned above, there could be changes which affect the project baselines themselves.

NOTE: These inputs to the Perform Integrated Change Control are the same as the Outputs to the previous process Monitor & Control Project Work.

4.5.4 EEF

Project management information system.

4.5.5 OPA

Change control procedures, procedures for approving and issuing change authorizations (it may require a different level of authority to approve the change depending on its extent), process measurements database.

TOOLS & TECHNIQUES

4.5.1 Expert Judgment

4.5.2 Change Control Meetings

OUTPUTS

4.5.1 Change Request Status Updates

The change requests are processed according to the change control system by a Change Control Board or whatever system the company has in place. If the result of the change control system is that the change is approved, then and only then is it implemented by the Direct and Manage Execution process (see diagram below). the change request log gives the status of the change requests and tells whether the change is accepted or rejected.

4.5.2 Project Management Plan Updates

If the project management plan is changed or the performance baseline is changed, then updates to these are made.

4.5.3 Project Document Updates

The change request log (mentioned in output 4.5.1 Change Request Status Updates) is updated.

4.5 CLOSE PROJECT OR PHASE

INPUTS

4.6.1 Project Management Plan

The final version of the project management plan is used.

4.6.2 Accepted Deliverables

These are deliverables that are accepted by the customer, and are thus outputs of the 5.4 Verify Scope Process.

4.6.3 OPA

Project closure guidelines, and lessons learned knowledge base (to be updated as part of the process).

TOOLS & TECHNIQUES

4.6.1 Expert Judgment

INPUTS

4.6.1 Final product, service, or result transition

This is the hand-off of the final deliverable of the project, be it a product, service or result to the customer or sponsor.

4.6.2 OPA Updates

• All of the documents from the project, such as the project management plan and the performance reports.
  

• Project closure documents, such as the formal acceptance of the deliverable from the customer or the completed contract from the supplier.
  

• Updated lessons learned database.
  

These are the inputs and outputs of processes 4.4 through 4.6.

The next posts will cover the inputs and outputs of the next Knowledge Area, that of Scope.

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

 This post covers chapter 4 of the PMBOK® Guide, which covers the Integration Knowledge Area. This knowledge area contains 6 processes, with at least one process in each of the 5 process groups, with Monitoring & Controlling Process having two processes from this area.

2. Review of processes in Integration Knowledge Area

As a review, here is a chart which gives a summary of the processes themselves, plus the tools & techniques used as part of that process. I am splitting the discussion of the Inputs & Outputs into two different posts; this post will cover Processes 4.1 through 4.3

3. Definition of inputs, outputs

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

4. Generic inputs

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

A. ENVIRONMENTAL ENTERPRISE FACTORS (EEF)

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

B. OPERATIONAL PROCESS ASSETS (OPA)

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

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

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

4.1 DEVELOP PROJECT CHARTER

INPUTS

4.1.1. Project Statement of Work

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

4.1.2 Business Case

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

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

4.1.3 Contract

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

4.1.4 EEF

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

4.1.5 OPA

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

TOOL & TECHNIQUES

4.1.1. Expert Judgment

OUTPUTS

4.1.1 Project Charter

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

Important elements of the Project Charter include:

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

4.2 DEVELOP PROJECT MANAGEMENT PLAN

INPUTS

4.2.1 Project Charter

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

4.2.2 Output from other Planning Processes

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

4.2.3 EEF

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

4.2.4 OPA

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

TOOLS & TECHNIQUES

4.2.1 Expert Judgment

OUTPUTS

4.2.1 Project Management Plan

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

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

4.3 DIRECT AND MANAGE PROJECT EXECUTION

INPUTS

4.3.1 Project Management Plan

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

4.3.2 Approved Change Requests

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

The diagram below should illustrate this relationship.

4.3.3 EEF

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

• Stakeholder risk tolerances
  

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

4.3.4 OPA

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

TOOLS & TECHNIQUES

4.3.1 Expert Judgment

4.3.2 Project Management Information System

OUTPUTS
4.3.1 Deliverables

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

4.3.2 Work Performance Information

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

4.3.3 Change Requests

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

4.3.4 Project Management Plan Updates

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

4.3.5 Project Document Updates

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

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

Filed under: Uncategorized | 1 Comment »

Homewood is a suburb of Chicago, Illinois where I grew up and went to high school with around 1,000 people in our class of 1975 at Homewood-Flossmoor (HF) High School.  I was invited back in mid-April to go to a regional “mini-reunion” for those HF graduates from our class who happen to live in the Southern California area. The reunion was suggested by one of my classmates, Scott Tomlinson, who was taking advantage of a business trip to San Diego to do an all-points call for a get together. He made it along with Marty Leonard and Richard Carroll.  At that reunion, I  got to meet Scott’s son Erik who is stationed there as a Marine.

We had such a good time that Scott suggested that we do it again in August. Well, this time Marty couldn’t make it, but Mike Bentivenga said he would be able to join us this time. We met at a restaurant called Wind & Sea that is literally right at the edge of the harbor at Dana Point.  Traffic was the usual weekend crawl down on the I-5.  I was impatient to get there, not just because I was excited to see everybody again, but because of my half-German, half-Irish background, I’m one of those guys who likes to make it to a pub or to a party on time.

I pulled in half an hour late, and Mike about half an hour after that. But after enduring an hour and a half of highway hell, we spent the next three hours in reminiscing heaven. Mike was the same outgoing guy I remembered from way back when, and I remarked to myself that our outside appearance had changed, but the spark of personality behind each of those slightly older faces seemed ageless, like we were talking about events from last week rather than from 35 years ago or more. That was the same thing I experienced last time when I saw Scott, Marty and Rich 4 months ago. (You can read the account of that reunion in my previous post https://4squareviews.com/2012/04/22/translucent/.)

I thought it was interesting that the experiences we’ve had since high school have been diverse, but our individual waves of successes and setbacks have been hit by the same tidal waves of major events: the dot-com bust, 9/11, the 2008 financial meltdown, and now the changing climate. But I think we must be a pretty resilient bunch, because I’m still basically optimistic despite the overall economic situation our country is in right now.

At this reunion, it was not Scott, but Rich who introduced his son Austin to the rest of us. He’s an avid scouter, and I was afraid that our tales of wild exploits from our high school days would give him some wild ideas. “We’re just telling you these stories to let you know what not to do when you get to be our age,” I tried to tell him, albeit unconvincingly. Scott, Mike and I all recounted the first time we got ill from too much alcohol, and found that we all had the experience of not being able to drink that particular type of alcohol with enjoyment when we grew up because “our bodies still remembered,” as Scott put it.

Another interesting parallel I found was that Mike related that since he is quite an extroverted, A-type personality, he has had to develop a “laid back” persona in order to be able to communicate with people better (especially out here in California) for those who find his regular “switched-on” self a little too intimidating. I realized that I had been doing the reverse. I felt in high school that I was introverted and not leadership material because I was a little too laid back and not forward enough with people. So through my leadership training at Toastmasters, I’ve gone from being a regular member to the Assistant Area governor in a year and a half. I’ve had to develop an “extroverted” persona for the same reason that Mike developed his persona—to be able to communicate with people better. It was interesting to see the parallel between Mike’s case and mine.

Overall, I have to say that having been to the reunion back in April had quite a salutary effect on me. There is something that Carl Jung referred to as the “shadow”, or the embodiment of energies that one has denied in life for one reason or the other. These can be positive or negative energies depending on the reason for the denial. When I looked back at my life after our reunion in April, I realized there were a lot of things I enjoyed doing back in high school that I don’t do any more, like being part of a chorus. I realized that was a whole dimension of my talents and experience that I had left buried after I left college. I bought some CDs of various Broadway hits and started singing along to them. In May, I was approached by someone at a networking event who asked me if I sang, and I said, “well, I used to.” He invited me to a men’s chorus called the Masters of Harmony, and I decided to visit one of their rehearsals. Man, I was hooked! They sounded great, and it reminded me so much of the rehearsals that Walter Rodby, our choral director at HF High School, used to put us through. I went for about a month, and did the preliminary audition in June—and passed with flying colors.

This coming Wednesday I have the second audition (out of a total of four) for which I’ve been practicing about two months, and I hope I pass it as well. I realized on Saturday night that I never would have had the guts to go after this kind of experience if I hadn’t been shocked into “reclaiming territory” of the past inside of my head because of the first reunion.

Well, it was a wonderful three hours, but Scott had to get back because he wanted to have a chance to see his son in San Diego one more time before he was to fly out the next day back to Houston. I asked him about what motivated Erik to join the Marines and he mentioned there was a straight line from 9/11 which happened when he was in 5^th grade to his decision later on in life to be a Marine.

On driving home along the Pacific Coast Highway back home after our reunion, I thought of that decision and I suddenly realized that I would do a speech on 9/11 about my experience on that date, and how it has shaped my later life. It was sparked by my hearing the tune “Try to Remember”, connecting it with 9/11 because of the lyrics “Try to remember the kind of September, When life was slow and oh, so mellow”, and then connecting that with Scott’s story about his son.   I’m always so full of energy and ideas after I meet with my classmates!

I’m very glad I went to the second reunion.  I not only reunited with three great guys from the past, but I also reunited with my bolder self from long ago that is now renewing my present life with more and more energy.   I hope to meet more and more of my fellow classmates in the months and years ahead.

Thanks again, Scott—you don’t know what you’ve started!

Filed under: Uncategorized | Leave a comment »

1. Introduction

In this next series of posts, we move onto step 5, which is memorizing the TOOLS & TECHNIQUES associated with each process. In order to breakdown the memorizing into more bite-size chunks, I am going to break down this topic into at least 9 posts, one for each knowledge area. (There may be some knowledge areas that require more than one post.)

 This post covers chapter 4 of the PMBOK® Guide, which covers the Integration Knowledge Area. This knowledge area contains 6 processes, with at least one process in each of the 5 process groups, with Monitoring & Controlling Process having two processes from this area.

Let’s take a look at the tools & techniques for the processes in the Integration Knowledge Area. You’ll notice that each of them have the same tool & technique in common: Expert Judgment, with process 4.3 Direct and Manage Project Execution having the additional tool & technique of 4.3.2 Project management information system, and 4.5 Perform Integrated Change Control having an additional tool & technique of Change control meetings.    You need experts or those with expertise in each area because the integration of all other processes from the various other knowledge areas is such a crucial part of project management

4.1 DEVELOP PROJECT CHARTER

4.1.1 Expert judgment

Just remember that who an “expert” is depends on what you need that person for. Obviously to develop a project charter, the person who is expert developing a high-level list of requirements, objectives, and risks of the project would include:

• Stakeholders (including customers or sponsors)
  
• Project management office
  
• Consultants and subject matter experts.
  

Some of this expertise is directed towards technical details (product description, project objectives), and some towards management of the project (project risks and milestone schedule).

4.2 DEVELOP PROJECT MANAGEMENT PLAN

4.2.1 Expert judgment

Here the expertise sought needs to be directed towards planning of the project work, including the resources required to get the project done, the project management plan itself, and the overall change control process.

4.3 DIRECT AND MANAGE PROJECT EXECUTION

4.3.1 Expert judgment

Here the expertise sought needs to be directed towards directing and managing the execution of the project. This will include stakeholders (including customers and sponsors), consultants used on the project, and project team members, especially those who have worked on a similar project before.

4.3.2 Project Management Information System

The software used such as Microsoft Project or Primavera, is a tool used to help with scheduling, configuration management (part of 4.5 Perform Integrated Change Control) and other activities that are part of the 4.3 Direct and Manage Project Execution process.

4.4 MONITOR AND CONTROL PROJECT WORK

4.4.1 Expert judgment

The information obtained by the process Monitor and Control Project Work is interpreted by those with expertise in measuring actual project performance against the performance baseline.

4.5 PERFORM INTEGRATED CHANGE CONTROL

4.5.1 Expert judgment

For a change control board, not only the project management team, but stakeholders including the customers may be asked to participate.

4.5.2 Change control meetings

The change control board has meetings to review any change requests that are pending in order to formally approve or reject them. The decisions are documented and communicated to all stakeholders.

4.5 CLOSE PROJECT OR PHASE

4.1.1 Expert judgment

Those with expertise in closing a project need to oversee this process so that all closure processes are completed to the standards set by the organization.

This concludes the Tools & Techniques section of memorizing the processes.

The next series of posts will conclude with a discussion of the inputs and outputs for the 42 processes. This will be most easily done if we follow the same format and divide the processes by knowledge area.

Filed under: Uncategorized | Leave a comment »

 1. Introduction

In this next series of posts, we move onto step 5, which is memorizing the TOOLS & TECHNIQUES associated with each process. In order to breakdown the memorizing into more bite-size chunks, I am going to break down this topic into at least 9 posts, one for each knowledge area. (There may be some knowledge areas that require more than one post.)

 This post covers chapter 12 of the PMBOK® Guide, which covers the Procurements Knowledge Area. This knowledge area contains 4 processes, one in each of the 5 process groups except for the Initiating Process Group.

I am splitting the discussion of the Tools & Techniques into two different posts. This post will cover the tools & techniques in the last two of these four processes, 12.3 and 12.4.

Let’s take a look at the tools & techniques for the processes 12.1 and 12.2 in the Procurements Knowledge Area.

12.3 ADMINISTER PROCUREMENTS

12.3.1. Contract change control system

There is an integrated change control system which handles changes to the project which regards to the work done by the company itself; one portion of this system is a contract change control system which handles changes to the project which regards to the work done by subcontractors or sellers.

12.3.2. Procurement performance reviews

The regular project team has periodic performance reviews that monitor their performance in producing deliverables according to the project scope within cost and on schedule. Similarly, there are procurement performance reviews which monitor the contractors performance in producing deliverables, but in this case according to the contract.

12.3.3. Inspections and audits

As part of the procurement contract, periodic inspections and audits can be held to make sure that the seller is complying with the terms of the contract. The inspections and audits may include personnel from the buyer if this is allowed by the contract.

12.3.4. Performance reporting

This is essentially reporting the results of the procurement performance reviews (12.3.2) to management.

12.3.5. Payment systems

Payment to the seller must be made in strict accordance with the terms of the contract, usually after certification by the buyer that the work done by the seller has been completed satisfactorily.

12.3.6. Claims administration

As a result of the contract change control system (12.3.1), there may be occasions when the buyer and seller cannot agree on changes to be made, or on the amount of compensation to be paid for that change. Many contracts call for settlement of all disputed claims such as these through something called alternative dispute resolution (ADR) to avoid the necessity of litigation.

12.3.7. Records management system

This has to do with the managing of records relating to the procurement process itself and any contract made with the seller as part of that process.

12.4 CLOSE PROCUREMENTS

12.4.1. Procurements audits

This is a review of the processes 12.1 (Plan Procurements), 12.2 (Conduct Procurements), and 12.3 (Administer Procurements). This is to help with lessons learned on the project to help future projects in the company with their procurements processes.

12.4.2. Negotiated settlements

If there is a disputed claim by either buyer or seller (12.3.6) relating to alleged failure of the other party to comply with the terms of the contract, then there should be an attempt to a) directly negotiate a settlement, or b) participate in an alternative dispute resolution or ADR. If that fails, then litigation is the last option.

12.4.3. Records management system

This has to do with the managing of records relating to the procurement process itself and any contract made with the seller as part of that process. As part of the closing process, it means indexing and archiving these records for use by other projects.

Well, we’ve now gone through each of the individual knowledge areas except one: Integration. And that’s because, as I mentioned at the beginning of this series of posts on Tools & Techniques, the Integration processes actually ties together all of the processes in the other knowledge areas (hence its name). So that is why I am covering the Integration Knowledge Area from chapter 4 of the PMBOK® Guide in the last few posts of this series.

Filed under: Uncategorized | Leave a comment »

 1. Introduction

In this next series of posts, we move onto step 5, which is memorizing the TOOLS & TECHNIQUES associated with each process. In order to breakdown the memorizing into more bite-size chunks, I am going to break down this topic into at least 9 posts, one for each knowledge area. (There may be some knowledge areas that require more than one post.)

 This post covers chapter 12 of the PMBOK® Guide, which covers the Procurements Knowledge Area. This knowledge area contains 4 processes, one in each of the 5 process groups except for the Initiating Process Group.

I am splitting the discussion of the Tools & Techniques into two different posts. This post will cover the tools & techniques in the first two of these four processes, 12.1 and 12.2

Let’s take a look at the tools & techniques for the processes 12.1 and 12.2 in the Procurements Knowledge Area.

12.1 PLAN PROCUREMENTS

12.1.1. Make-or-buy analysis

This is the technique used to determine whether work should be done in-house or whether it must be contracted out or purchased from outside the company.

In making this analysis, it is important to consider indirect costs. If you purchase software, you must consider the cost of the ongoing support of that software (indirect cost), and not just the direct cost of its initial purchase.

This is a crucial juncture in the project, because if there are NO procurements whatsoever, and all the work is done in-house, then there will be no processes 12.2 through 12.4. They are processes that are optional depending on the results of this analysis done early on in the project.

12.1.2. Expert judgment

There are two types of expert judgment used here. One is expert technical judgment used to develop the technical criteria for evaluating the various proposals that come back from the sellers in the next process 12.2 Conduct Procurements. The other is expert legal judgment in the crafting of the legal terms and conditions that go into the procurement contracts.

12.1.3. Contract types

There are two general types of contacts, the fixed-price contract or the cost-reimbursable contracts. The former has a greater risk for the seller, and the latter has a greater risk for the buyer.. There is a third type of contract which is a hybrid of these two types called the time and materials contract. Here’s a comparison of these types, with the arrow to the right indicating increasing risk to the buyer:

The fixed-price contract sets a total fixed price for the product or service provided by the seller. If the product or service costs more than what the seller originally bid for, then that cost is borne by the seller. That’s why it is more advantageous to the buyer. For that reason, it is the preferred type of contract for the buyer to propose.

The cost-reimbursable contract pays the seller for all legitimate costs incurred for the product or service provided. If the product or service costs more than what the seller originally estimated, then that cost is borne by the buyer. That’s why it is more advantageous to the seller. For that reason, using the cost-reimbursable form of contract would have to require some justification for its use. It may be justified whenever the scope of work is not precisely defined at the start and needs to be altered, thus requiring many changes on the part of the seller. Another reason for justification is if there is a high risk in producing the product or service, and the seller requires this form of contract in order to compensate it for essentially being transferred this risk.

Time & materials contracts may be left open-ended and subject to a cost increase by the seller, but with certain cap or not-to-exceed value to prevent unlimited cost increases. Another form of time & materials contracts can resemble fixed unit-price arrangements for labor or material rates. The unit-labor price is fixed as in a fixed-price contract, but the number of units is left open like a cost-reimbursable contract. This kind of contract is often used with acquisition of experts or support for product team activities when the precise statement of work cannot be easily described at the beginning of the project.

12.2 CONDUCT PROCUREMENTS

12.2.1. Bidder conferences

The buyer and prospective sellers meet prior to their submittal of a bid or proposal. This ensures that all prospective sellers have a clear and common understanding of the technical and legal requirements of the procurement.

12.2.2. Proposal evaluation techniques

With procurements that are more complex, criteria are set up to evaluate the responses that will come from the sellers. An evaluation committee makes their selection of the seller based on the criteria that are set up in this tool & technique.

12.2.3. Independent estimates

In order to estimate the costs of the procurement, an independent estimate can be obtained from the buyer by an outside professional estimator or it can have the estimate done in-house. If the cost estimates from the sellers come in that are significantly different from this estimate, this may indicate that the sellers did not gain a clear enough understanding of the procurement at the bidder conference (tool & technique 12.2.1).

12.2.4. Expert judgment

A review team with experience in the areas covered by the procurement documents and proposed contract can be used to evaluate the proposals. This can include functional disciplines that are technical, financial, and/or legal in nature.

12.2.5. Advertising

Advertisements can be put in newspapers or selected trade publications to elicit bids for contracts. Government contracts require public advertising of pending government contracts.

12.2.6. Internet search

Some standard components or off-the-shelf items may be procured at a fixed price on the Internet. However, this will not work for non-standard components that have to be specially made for the project.

12.2.7 Procurement negotiations

The buyer and seller must negotiate the terms of the procurement contract. Obviously the price and overall schedule must be agreed to in advance, but also those subjects need to be covered that will affect the administration of the procurement as well, such as reporting responsibilities, and the authority to make changes to the product.

The next post will be on the Tools & Techniques associated with the last two processes 12.3 and 12.4 from chapter 12 of the PMBOK® Guide covering the Procurements Knowledge Area.

Filed under: Uncategorized | Leave a comment »

 1. Introduction

In this next series of posts, we move onto step 5, which is memorizing the TOOLS & TECHNIQUES associated with each process. In order to breakdown the memorizing into more bite-size chunks, I am going to break down this topic into at least 9 posts, one for each knowledge area. (There may be some knowledge areas that require more than one post.)

This post covers chapter 11 of the PMBOK® Guide, which covers the Risk Knowledge Area. This knowledge area contains 6 processes, 5 of which are in the Planning Process Group and the last of which is in the Monitoring & Controlling Process Group.

Since there are 6 processes, most of which contain multiple Tools & Techniques, I am splitting the discussion of the Tools & Techniques into two different posts. This post will cover processes 11.4 through 11.6.

Let’s take a look at the tools & techniques for the processes 11.4 through 11.6 in the Risk Knowledge Area.

11.4 PERFORM QUANTITATIVE RISK ANALYSIS

The previous process did a qualitative risk analysis, identifying risks and then ranking them with regards to their probability and/or impact. In this process, a quantitative risk analysis is done to estimate the cost impact of these risks on the project.

11.4.1. Data gathering and representation techniques

One source of information on the impact of risks on a project is historical experience on previous projects. This information can be obtained through interviewing those participants on previous projects.

Another source of information is probability distributions, which can assist in obtaining an estimate of the most likely risk outcome, as well as the pessimistic and optimistic estimates.

11.4.2. Quantitative risk analysis and modeling techniques

Sensitivity analysis takes one uncertain element that may affect a project and examines how changes in this element would affect the project, with all other uncertain elements being held at their normal, baseline value. This shows the variation associated with each uncertain element. Sometimes these variations are put into something called a tornado diagram, which is simply a bar chart with the elements listed in a vertical manner so that the element with the largest variation is on top, followed by the next-largest, and so on, tapering down to the smallest variation on the bottom. (The name of the diagram comes from the upper-tapering profile of the bars in the chart, similar to the profile of a tornado.)

Expected monetary value analysis is a way of taking probabilities of certain risks happening and quantifying their impact on the project. For example, let’s say that at a certain point in the project, there are two possible outcomes. One, outcome A, has a probability of 25% and costs $100K, whereas outcome B has a probability of 75% and costs 75K. Then the EMV is equal to the sum of the products of the probability of each occurrence times its monetary value. In this case, the EMV = (25% x $100,000) + (75% x $75,000) = $25,000 + $25,000 = $50,000.

Modeling through Monte Carlo analysis is a way of doing a calculation using various combinations of probabilities of outcomes for the various risks that impact a project. It can generate a cost estimate of the overall project doing a cost estimate similar to the monetary value analysis described in the last paragraph, or for estimating the impact of risks on a schedule, can is an analysis that would generate an estimate of the duration of a project.

11.4.3. Expert judgment

As usual, asking those who have worked on a similar project before, either within the organization (team members) or outside the organization (subject matter experts).

11.5 PLAN RISK RESPONSES

11.5.1. Strategies for negative risks or threats

As can be seen, if the risk is low, you can simply accept it. However, if the risk is moderate, you may try to mitigate or transfer the risk. If the risk is high, you may try to simply avoid it altogether.

11.5.2. Strategies for positive risks or opportunities

As can be seen, if the opportunity is a good one, you should try to exploit it. If it is of lesser probability, you can either enhance it or share it. If the probability is low, you can essentially accept it, and if it does occur, you can allocate the unused reserve to the project.

11.5.3. Contingent response strategies

This is a list of responses to be used if certain risks occur. Therefore a list of events that trigger these contingency responses needs to be created and tracked through the course of the project. If the events end up not occurring, then the reserves to be used for the contingency responses should be returned to the budget.

11.5.4. Expert judgment

Those who have worked on similar projects before, either within the organization (team members) or outside the organization (consultants) can assist in creating a set of appropriate risk responses.

11.6 MONITOR AND CONTROL RISKS

11.6.1. Risk reassessment

New risks are identified, current risks are reassessed as to their probability and impact, and risks that are outdated are closed (risk reserves returned to the budget).

11.6.2. Risk audits

This is an audit of the effectiveness of risk responses to make sure they are updated to reflect the new risks and current risks that were reassessed in the tool & technique mentioned in the previous paragraph.

11.6.3. Variance and trend analysis

Variance and trend analysis can reveal deviation from the baseline, which in turn may indicate the potential impact of threats or opportunities.

11.6.4. Technical performance measurement

This compares technical accomplishments such as number of defects, etc., that may help forecast the degree of technical risk faced by the project.

11.6.5. Reserve analysis

When risks occur, they have positive or negative impacts on the budget or schedule, and these are added to or subtracted from the contingency reserves. Reserve analysis compares the amount of the contingency reserves remaining to the amount of risk remaining in order to determine whether the amount of reserves is adequate.

11.6.6. Status meetings

Periodic status meetings are places where periodic risk management should take place. It is frequent discussions in a group that makes it more likely that risks and opportunities will be properly identified.

The next post will be on the Tools & Techniques associated with chapter 12 of the PMBOK® Guide covering the Procurements Knowledge Area.

Filed under: Uncategorized | Leave a comment »

 1. Introduction

In this next series of posts, we move onto step 5, which is memorizing the TOOLS & TECHNIQUES associated with each process. In order to breakdown the memorizing into more bite-size chunks, I am going to break down this topic into at least 9 posts, one for each knowledge area. (There may be some knowledge areas that require more than one post.)

This post covers chapter 11 of the PMBOK® Guide, which covers the Risk Knowledge Area. This knowledge area contains 6 processes, 5 of which are in the Planning Process Group and the last of which is in the Monitoring & Controlling Process Group.

Here’s a description of the four processes that are included in the Human Resources Knowledge Area, together with a listing of the Tools & Techniques used in those processes. Since there are 6 processes, most of which contain multiple Tools & Techniques, I am splitting the discussion of the Tools & Techniques into two different posts. This post will cover processes 11.1 through 11.3.

Let’s take a look at the tools & techniques for the processes 11.1 through 11.6 in the Risk Knowledge Area.

11.1 PLAN RISK MANAGEMENT

11.1. Planning meetings and analysis

The project manager meets with selected project team members and stakeholders in order to do high-level planning regarding the following

• Risk management activities are developed to be included in the project schedule
  
• The cost of these risk management activities are estimated to be included in the project budget
  
• Risk management responsibilities are assigned
  
• General organizational templates for categorizing risk are tailored for the specific project.
  

The results of these discussions are included in the risk management plan.

11.2 IDENTIFY RISKS

11.2.1. Documentation reviews

Risks are identified by reviewing documents which contain the project requirements and assumptions.

11.2.2. Information gathering interviews

A risk breakdown structure is a mapping of risks associated with the activities in the work breakdown structure. To generate this there are many techniques, some of which are:

11.2.3. Checklist analysis

One way to create a risk breakdown structure is to use a checklist based on historical information about similar projects that have been done in the past.

11.2.4. Assumptions analysis

The assumptions about the project are analyzed to identify risks to the project from the incompleteness or inaccurate about the assumptions. This contrasts with the first tool & technique 11.2.1 where the risks are analyzed on the assumptions ARE correct. This tool & technique therefore is a deeper level of analysis of risk.

11.2.5. Diagramming techniques

These techniques are used for determining the causes of risks.

11.2.6. SWOT analysis

The Strengths and Weaknesses (internal to the organization) and the Opportunities and Threats (external to the organization) are identified. These represent events to be avoided and/or encouraged in the course of the project.

11.2.7. Expert judgment

One way to identify risks is to discuss those with experience on similar projects, either within the organization or subject matter experts (consultants).

11.3 PERFORM QUALITATIVE RISK ANALYSIS

11.3.1. Risk probability and impact assessment

Each risk is investigated as to its a) likelihood of occurring and b) impact on the project if it occurs.

11.3.2. Probability and impact matrix

Based on the risk probability and impact assessment done in the last tool & technique, the

risks can be ranked into levels of overall risk such as low, moderate, or high.

11.3.3. Risk data quality assessment

This is an analysis not of the risks themselves, but of the risk data’s reliability. This is a second-order analysis which helps the project manager decide whether it is necessary to gather higher-quality data on the risks.

11.3.4. Risk categorization

Risks are categorized based on the area of the project most exposed to the effects of uncertainty. Grouping risks together in categories related to common root causes can help lead to a more effective risk response than dealing with them on a case-by-case basis.

11.3.5. Risk urgency assessment

The urgency of a risk is based on those that need to be addressed in the near-term, that is, closer to the beginning of a project. Another factor that can be included in the priority of a risk is the time and cost it would take to respond to such a risk. The results of this risk urgency assessment can be combined with the risk ranking (based on tool & technique 11.3.2 Probability and impact matrix) to get the final risk severity rating.

11.3.6. Expert judgment

One way to categorize and/or rank risks is to discuss them with those that have experience on similar projects, either within the organization or subject matter experts (consultants).

The next post will be on the Tools & Techniques associated with the last three processes of the Risk Knowledge Area.

Filed under: Uncategorized | Leave a comment »

 1. Introduction

In this next series of posts, we move onto step 5, which is memorizing the TOOLS & TECHNIQUES associated with each process. In order to breakdown the memorizing into more bite-size chunks, I am going to break down this topic into at least 9 posts, one for each knowledge area. (There may be some knowledge areas that require more than one post.)

This post covers chapter 10 of the PMBOK® Guide, which covers the Communications Knowledge Area. This knowledge area contains 5 processes which are located in all process groups except the Closing Process Group.

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

1. Stakeholder analysis

2. Expert judgment10.2 Plan CommunicationsDetermining the needs of project stakeholders for information and defining a communication approach.1. Communication requirements analysis

2. Communication technology

3. Communication models

4. Communication methods

10.3 Distribute InformationMaking relevant information available to project stakeholders.1. Communication methods

2. Information distribution tools

10.4 Manage Stakeholder ExpectationsCommunicating with project stakeholders to meet their needs and address issues as they occur.1. Communication methods

2. Interpersonal skills

3. Management skills

10.5 Report PerformanceCollecting and distributing performance information (status reports, progress measurements, forecasts) to project stakeholders.1. Variance analysis

2. Forecasting methods

3. Communication methods

4. Reporting systems

Let’s take a look at the tools & techniques for the 4 processes 9.1 through 9.4 in the Human Resources Knowledge Area.

10.1 IDENTIFY STAKEHOLDERS

10.1.1. Stakeholder analysis

The stakeholders need to be identified, not just with organizational information such as their roles and departments, but also the following

• Knowledge and/or experience levels
  
• Expectations regarding the project (interest level)
  
• Levels of influence the project (power level)
  

These factors can be compared in a grid, an example of which is below. In this grid, the horizontal axis is the interest level, and the vertical axis is the power level. This results in four quadrants with the various combinations of levels, and a strategy for dealing with each combination.

10.1.2. Expert judgment

This is to be consulted in identifying and classifying stakeholders. Those with a special knowledge of the key stakeholders, including the stakeholders themselves, can be consulted as experts with regards to this question.

10.2 PLAN COMMUNICATIONS

10.2.1. Communication requirements analysis

Using the formula n(n-1)/2, you can calculate the number of possible communication channels among a group of n stakeholders. How the stakeholders communicate is the focus of this tool and technique, including the requirements for how often communication is required, and in what form (e-mail, telephone call, face-to-face meeting, etc.).

10.2.2. Communication technology

This is a matter of using the appropriate technology for communication, from simple written documents to virtual meetings.

10.2.3. Communication models

The basic model of information is that information that person A wants to send to person B is encoded by being put into some sort of language. This output is the message which is transmitted through some medium to the other person who then decodes it. Any noise that occurs during the transmission process can distort the message, but the message can also get distorted in the encoding and decoding phases, if person A puts the message into an ambiguous form which is then understood erroneously by person B.

10.2.4. Communication methods

These different methods are used when there is a different level of interactivity and/or engagement between the two parties.

• Interactive communication (between two or more parties), such as face-to-face meetings or phone calls
  
• Push communication (from one to multiple parties), such as e-mail or memos
  
• Pull communication (for multiple parties), such as intranet sites, pre-recorded lectures or seminars
  

10.3 DISTRIBUTE INFORMATION

10.3.1 Communication methods

Group meetings, video conferences or audio conferences (via telephone) are ways to disseminate information about the project to a wide audience.

10.3.2 Information distribution tools

These can exist in physical form (memos, press releases), electronic form (voice mail, e-mail, video conferences) or software (project management software such as Microsoft Project or Primavera).

10.4 MANAGE STAKEHOLDER EXPECTATIONS

10.4.1. Communication methods

This is obtained from the communications management plan.

10.4.2. Interpersonal skills

These are the soft skills that today are often referred to as “emotional intelligence.”

10.4.3. Management skills

This deals not with project management per se, but people management skills, including skills at public speaking, doing effective presentations, and negotiating.

10.5 REPORT PERFORMANCE

10.5.1. Variance analysis

This is the analysis of the difference between the actual performance and the performance measurement baseline. A comparison of the current variance with the previous variances can yield a trend.

10.5.2. Forecasting methods

These are methods of showing, based on the trends found in the last tool & technique 10.5.1 Variance Analysis, what the future project performance will be.

10.5.3. Communication methods

The results of the trend analysis and forecasting done in the last two tools & techniques is then communication to those interest parties through status review meetings (a form of push communication which is a one-to-many type of communication).

10.5.4. Reporting systems

This is usual some standard reporting tool such as a spreadsheet or other graphical analysis of the data to demonstrate at the status review meetings mentioned in the tool & technique 10.5.3 Communication methods, the conclusions reached with the first two tools & techniques 10.5.1 Variance Analysis and 10.5.2 Forecasting methods.

The next post will be on the Tools & Techniques associated with chapter 11 of the PMBOK® Guide dealing with the Risk Knowledge Area.

Filed under: Uncategorized | Leave a comment »

1. Introduction

In this next series of posts, we move onto step 5, which is memorizing the TOOLS & TECHNIQUES associated with each process. In order to breakdown the memorizing into more bite-size chunks, I am going to break down this topic into at least 9 posts, one for each knowledge area. (There may be some knowledge areas that require more than one post.)

This post covers chapter 9 of the PMBOK® Guide, which covers the Human Resources Knowledge Area. This knowledge area contains 4 processes, the first of which is in the Planning Process Group, and the last three of which are in the Executing Process Group.

As a reminder, Human Resources Knowledge Area is the only knowledge area not to have a process in the Monitoring & Controlling Process Group.

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

Let’s take a look at the tools & techniques for the 4 processes 9.1 through 9.4 in the Human Resources Knowledge Area.

9.1 DEVELOP HUMAN RESOURCES PLAN

9.1.1. Organizational charts and position descriptions

This is a natural tool you would expect a human resources plan to include. This specifies the roles and responsibilities of the various team members. Here are three types of charts or formats these roles and responsibilities can be specified in.

9.1.2. Networking

This is simply formal and informal interaction within an organization. This is important for a project manager to do not only at a beginning of a project, but also during the course of the project as well.

9.1.3. Organizational Theory

This gives information on how people, teams, and organizational units behave and what motivates them the most.

9.2. ACQUIRE PROJECT TEAM

9.2.1. Pre-assignment

Team members can be either be pre-assigned if their assignments are specified within the project charter during the initiating process. Otherwise their assignments are negotiated during the planning process.

9.2.2. Negotiation

As mentioned in the previous paragraph, if functional managers (in a matrix-type organization) have control over the assignment of certain team members, a project manager may have to negotiate with that functional manager to use these team members for a certain duration on the project.

9.2.3. Acquisition

In case certain expertise on the project is not available within the organization, the project manager may have to negotiate with the human resources department to acquire team members on a temporary basis as consultants for the purpose of the project.

9.2.4. Virtual teams

If the company has several locations in a country, employees may have to meet via a video conference rather than face-to-face. However, losing the face-to-face component of interactions may require a project manager to make sure that nothing gets “lost in the translation” to a virtual environment.

9.3 DEVELOP PROJECT TEAM

9.3.1. Interpersonal skills

These are the soft skills that a project manager can use to increase cooperation. Nowadays, these interpersonal skills are styled as part of “emotional intelligence”.

s

9.3.2. Training

These are the hard skills or knowledge and experience-based skills that a project manager must either ensure that his team members have or develop during the course of the project.

9.3.3. Team-building skills

Even for those that are experienced with projects, it is important to build a team from the start of a project because that particular group of people may not have worked with all members before. Here are the five stages of development of a team:

9.3.4. Ground rules

Ground rules are established for interactions among project team members; this is extremely important in the conducting of team meetings, so that the meetings are productive.

9.3.5. Co-location

Active members are located in the same physical location for as much of the project as feasible. This could be as simple as providing a team meeting room, or locating all of the team members in the same section of the facility. This is opposed to the usage of virtual teams.

9.3.6. Recognition and rewards

This is an important way to motivate team members to encourage them to work hard, both individually and together, on the project.

9.4 MANAGE PROJECT TEAM

9.4.1. Observation and conversation

This is why networking is an effective tool not just in the planning phase, but during the entire execution of the project. This is the most genuine way of getting information on the progress of team members, and is more personal than just e-mailing members to distribute or obtain information.

9.4.2. Project performance appraisals

This is when a project manager sits down with team members from time to time and goes over any issues that may need to be resolved, to clarify future goals, or to recognize and reward those who have achieved previously set goals.

9.4.3. Conflict management

Team members themselves should have responsibility for resolving conflicts among themselves. However, if the conflict escalates, project managers need to be able to help team members who have a conflict with each other to reach an amicable resolution of their conflict. There are six general techniques for resolving conflict.

9.4.4. Issue log

If there is a conflict, an issue log can be used to document not only the conflicts that arise, but also their resolution. This is particularly helpful for updating lessons learned on the project.

9.4.5 Interpersonal skills

Leadership through example, and the ability to influence team members over which the project manage may not have direct responsibility (as in a matrix-type organization) are important skills for a project manager to have.

The next post will be on the Tools & Techniques associated with chapter 10 of the PMBOK® Guide dealing with the Communications Knowledge Area.

Filed under: Uncategorized | Leave a comment »