5th Edition PMBOK® Guide—Memorizing the Processes (Step 3: Procurement Knowledge Area)


 

 

1.   Introduction

After memorizing the 5 process groups (step #1) and the 10 knowledge areas (step #2), the next step in mastering the memorization of the processes is figuring out where the 47 project management processes fit in the matrix made by those process groups and knowledge areas.    The best way to do that is to first memorize the names and order of the processes by knowledge area.    In previous posts, I have covered the knowledge areas of Integration (chapter 4 of the PMBOK® Guide), Scope (Chapter 5), Time (chapter 6), Cost (chapter 7), Quality (chapter 8), Human Resources (chapter 9), Communications (chapter 10), and Risk (chapter 11).    This post will cover the processes involved in the Procurement Management knowledge area, which is covered by chapter 12 of the PMBOK® Guide.

Here are the 47 processes of project management; the chart indicates how many are in each knowledge area and process group.

Initiating Planning Executing Monitoring & Controlling Closing
Integration 6

1

1

1

2

1

Scope 6

4

2

Time 7

6

1

Cost 4

3

1

Quality 3

1

1

1

Human Resources 4

1

3

Communications 3

1

1

1

Risk 6

5

1

Procurements 4

1

1

1

1

Stakeholder 4      1

1

1

1

 47

2

24

8

11

2

2.  Procurement Management knowledge area

Here’s the portion of the above matrix of 47 processes that lists the processes in the Risk Management knowledge area, which is covered in chapter 11 of the 5th Edition of the PMBOK® Guide.

Knowledge Area Total # of Processes Initiating Planning Executing Monitoring & Controlling Closing
Procurement

4

1  1  1  1

You should notice two things about the distribution of processes among the process groups for the Procurement Management knowledge area.    There is one process in each process group except for the initiating process group, that means one in each of Planning, Executing, Monitoring & Controlling, and Closing.

In addition, the fact that has a process in the Closing group is significant; it is the only knowledge area except for the Integration Knowledge Area that has a process in that Closing group.

Here’s a chart describing all of the 4 processes, one in each process group (except for the Initiating Process Group).

Process

Group

Process

Number

Process
Name
Process Description
Planning 12.1 Plan Procurement Management Documents project procurement decisions, specifies the approach, and identifies potential sellers.
Executing 12.2 Conduct Procurement Obtains seller responses, selects seller, and awards contract.
Monitoring & Controlling 12.3 Control Procurement Manages procurement relationships, monitors contract performance, makes changes and corrections as needed.
Closing 12.4 Close Procurement Completes project procurement.

12.1 Plan Procurement

The Plan Procurement process is a framework for all the procurement processes to follow.    The most important decision that is made as part of this process is the make-or-buy decision, which is where an organization decides whether any procurement are indeed even necessary.    If the company can make all of the components of the product, then it may not need to buy any at all, in which case it will not be necessary to carry out any of the processes 12.2 through 12.4.

If on the other hand the company has to buy components from suppliers, however, then they must be obtained through the procurement process which is outlined in the Procurement Management Plan, the output of the 12.1 Plan Procurement process.   The technical and other criteria for the component are set forth, and potential sellers or suppliers identified (perhaps based on previous projects or through information obtained through industry associations).    A sample procurement contract is usually given as a template and the conflict resolution process is specified in case the supplier is unable to fulfill that contract during the course of the project.

12.2 Conduct Procurement

This process is where the contract is awarded through a bidding or proposal process to the seller that meets the criteria set forth in 12.1 Plan Procurement.

12.3 Administer Procurement

Once the seller has been selected in 12.2 Conduct Procurement, the “monitoring” part of this process confirms that the terms of the contract are fulfilled by the seller and that a good relationship with the seller is maintained.    The “controlling” part of this process occurs when there is some conflict with the seller, and an attempt is made to resolve the conflict through the conflict resolution process, which is specified in 12.1 Plan Project Management.

12.4 Close Procurement

This is the only project management process that is in the Closing Process Group other than 4.6 Close Project or Phase under the Integration Management knowledge area.    The work that the seller has done and the deliverables that the seller produces to help complete the project are verified as acceptable by the buyer, and the buyer then formally signs off on the completion of the procurement contract, which together with the conclusion of the financial reporting requirements brings the procurement to formal closure.

The reason why this knowledge area has a process in the Closing Process Group is because from the standpoint of the supplier, the procurement is in essence a project unto itself.   Like the overall project the buyer is undertaking, it starts out with the seed of a “statement of work” or “SOW”; in the case of the procurement, it is a “Procurement SOW”.    And like the overall project the buyer is understaking, it ends with a formal closure which requires the deliverables to be verified.   In the case of the procurement, the buyer does the validating of the final deliverable from the supplier, and in the case of the overall project, the customer or the sponsor does the validating of the final deliverable from the organization (the “buyer” in the procurement relationship).

If I were running the PMI, I would have put Stakeholder Management as chapter 11 right after Communications Management in Chapter 10, and moved the other chapters (Risk and Procurement) to be chapters 12 and 13.   Why do I think this?   Because Stakeholder Management is to a large extent based on Communications Management, and in fact is an outgrowth of that knowledge area.    However, it is conceptually related to Risk Management, as the following post discusses

https://4squareviews.com/2013/09/13/the-relationship-between-risk-management-and-stakeholder-management/

But since I am not running PMI, I accept their decision to tack Stakeholder Management on as the last chapter, chapter 13.   The processes in the Stakeholder Management knowledge area are the subject of the next post.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: