Project Procurement Management According to the PMBOK

PMBOK Guide

Most projects require some form of external purchasing (procurement) in order to meet their goals.  Executing these procurements to fulfill the needs of the project falls under the knowledge area of Project Procurement Management.

Contractors usually have better expertise or experience and can provide a higher quality product.  But often they are not motivated by the same factors as the project team.  Delivering their portion of the work on time or under budget requires the active involvement of the project manager.

Successful sub-contracting requires knowledge of the types of contracts available, as well as how to write them.  Requests for Proposals, Invitations to Tender, and the like must be drawn up, as do the contracts themselves.  This is a significant amount of knowledge, and many firms outsource even those tasks to law firms, engineers, etc.

PMBOK Knowledge Area:  Project Procurement ManagementThere are four processes:

  1. Plan Procurement Management
  2. Conduct Procurements
  3. Control Procurements

Plan Procurement Management

During the project planning phase the procurement needs of the project are identified. For each external vendor requirement, a Statement of Work is composed which is known by many names (Terms of Reference, Scope Statement, etc.) but serves as a written statement of what work the contractor will do. Procurement documents normally consist of a Request for Proposal, Invitation to Tender, or the like, with the Statement of Work included as an attachment. Thus it is the guiding document to the project team and the more specific it is, the better the boundaries of each organization’s work is defined. Additionally, the procedures used to solicit proposals and/or bids as well as the decision making criteria are determined at this stage. Potential sellers are identified and preferred vendors might be contacted. All of this information is compiled into a Procurement Management Plan, a subset of the overall Project Management Plan.

PMBOK Process:  Plan Procurement ManagementInputs

  1. Project charter
  2. Business documents
    • Business case
    • Benefits management plan
  3. Project management plan
    • Scope management plan
    • Quality management plan
    • Resource management plan
    • Scope baseline
  4. Project documents
    • Milestone list
    • Project team assignments
    • Requirements documentation
    • Requirements traceability matrix
    • Resource requirements
    • Risk register
    • Stakeholder register
  5. Enterprise environmental factors
  6. Organizational process assets

Tools & Techniques

  1. Expert judgment
  2. Data gathering
    • Market research
  3. Data analysis
    • Make-or-buy analysis
  4. Source selection analysis
  5. Meetings

Outputs

  1. Procurement management plan
  2. Procurement strategy
  3. Bid documents
  4. Procurement statement of work
  5. Source selection criteria
  6. Make-or-buy decisions
  7. Independent cost estimates
  8. Change requests
  9. Project documents updates
    • Lessons learned register
    • Milestone list
    • Requirements documentation
    • Requirements traceability matrix
    • Risk register
    • Stakeholder register
  10. Organizational process assets

Conduct Procurements

Once the procurement needs of the project are identified and procurement procedures are determined, the procurements are executed. Requests for Proposal (RFP’s) or Invitations to Tender are sent out, and responses are analyzed. Selection criteria should be determined in advance. Agreements are signed and the project management plan is updated with the new cost/budget and schedule information obtained from the vendor.

PMBOK Process:  Conduct ProcurementsInputs

  1. Procurement management plan
    • Scope management plan
    • Requirements management plan
    • Communications management plan
    • Risk management plan
    • Procurement management plan
    • Configuration management plan
    • Cost baseline
  2. Project documents
    • Lessons learned register
    • Project schedule
    • Requirements documentation
    • Risk register
    • Stakeholder register
  3. Procurement documentation
  4. Seller proposals
  5. Enterprise environmental factors
  6. Organizational process assets

Tools & Techniques

  1. Expert judgment
  2. Advertising
  3. Bidder conferences
  4. Data analysis
    • Proposal evaluation
  5. Interpersonal and team skills
    • Negotiation

Outputs

  1. Selected sellers
  2. Agreements
  3. Change requests
  4. Project management plan updates
    • Requirements management plan
    • Quality management plan
    • Communications management plan
    • Risk management plan
    • Procurement management plan
    • Scope baseline
    • Schedule baseline
    • Cost baseline
  5. Project documents updates
    • Lessons learned register
    • Requirements documentation
    • Requirements traceability matrix
    • Resource calendars
    • Risk register
    • Stakeholder register
  6. Organizational process assets

Control Procurements

Poor subcontractor management can cause budgets and schedules to spiral out of control and derail projects when everything else has been executed flawlessly. During regular project status intervals, the project manager must review subcontractor agreements, progress updates, and work performance information as necessary to ensure that subcontractors are on pace to meet their budget and schedule commitments. It is not enough to assume that subcontractors are “good at what they do” and will meet their contractual obligations. When subcontractors mismanage their work, everyone loses, including the contracting organization. Thus, project managers should be aware of the status of subcontractor work and make the appropriate change requests and project management plan updates as early as possible.

PMBOK Process:  Control ProcurementsInputs

  1. Project management plan
    • Requirements management plan
    • Risk management plan
    • Procurement management plan
    • Change management plan
    • Schedule baseline
  2. Project documents
    • Assumption log
    • Lessons learned register
    • Milestone list
    • Quality reports
    • Requirements documentation
    • Requirements traceability matrix
    • Risk register
    • Stakeholder register
  3. Agreements
  4. Procurement documentation
  5. Approved change requests
  6. Work performance data
  7. Enterprise environmental factors
  8. Organizational process assets

Tools & Techniques

  1. Expert judgment
  2. Claims administration
  3. Data analysis
    • Performance reviews
    • Earned value analysis
    • Trend analysis
  4. Inspection
  5. Audits

Outputs

  1. Closed procurements
  2. Work performance information
  3. Procurement documentation updates
  4. Change requests
  5. Project management plan updates
    • Risk management plan
    • Procurement management plan
    • Schedule baseline
    • Cost baseline
  6. Project documents updates
    • Lessons learned register
    • Resource requirements
    • Requirements traceability matrix
    • Risk register
    • Stakeholder register
  7. Organizational process assets updates

About Bernie Roseke, P.Eng., PMP

Bernie Roseke, P.Eng., PMP, is the president of Roseke Engineering. As a bridge engineer and project manager, he manages projects ranging from small, local bridges to multi-million dollar projects. He is also the technical brains behind ProjectEngineer, the online project management system for engineers. He is a licensed professional engineer, certified project manager, and six sigma black belt. He lives in Lethbridge, Alberta, Canada, with his wife and two kids.

View all posts by Bernie Roseke, P.Eng., PMP

2 Replies to “Project Procurement Management According to the PMBOK”

  1. I’m not clear why a STRATEGY is the output of a PLAN. According to the dictionary “A strategy is a careful plan or method” It seems like the two words are virtually interchangeable.

    However, it’s clear in the PMBOK guide that a strategy results from a plan.

    What is the difference between a Procurement STRATEGY and a Procurement PLAN?

    1. It is unfortunate that PMBOK uses the word PLAN for each of the Knowledge Areas first processes.

      They are clearly showing the “how” – which is a STRATEGY.

      Take the Risk Management Plan as an example, it is all about HOW you will apply risk management to this project and therefore HOW you will use/tailor/blend, the remaining risk management processes.

      Perhaps a better phrase to use would be The Risk Management APPROACH, which would immediately resolve this confusion!

      Dave Litten
      https://www.projex.com/pmp

Leave a Reply

Your email address will not be published. Required fields are marked *

*