6th Edition PMBOK® Guide–Process 12.3 Control Procurements: Inputs


During the execution phase of the procurements, you may periodically monitor the progress and make any changes if necessary (the “control” part of the process to which the title of the process refers).   Then when the procurements are completed, just as in the case of Validate Scope for the project at large, the final inspection is done and, once the procurement is accepted, the procurement is considered close.

For this process, the inputs come from the most part from the previous two processes, 12.1 Plan Procurement Management and 12.2 Conduct Procurements.

12.3.1  Control Procurement:  Inputs

12.3.1.1 Project Management Plan

Of course, the procurement management plan is going to be an input to this process:

  • Procurement management plan–contains the activities to be performed in this process

But other components of the overall project management plan may also be inputs as well, such as:

  • Requirements management plan–describes how the contractor requirements will be analyzed, documented, and managed
  • Risk management plan–describes how risk activities created by the sellers will be structured and performed for the project
  • Change management plan–contains information about how seller-created changes will be processed.
  • Schedule baseline–if there are slippages created by sellers that impact the overall project performance, the schedule may need to be updated and approved

12.3.1.2  Project Documents

The project documents that can be considered as inputs to this process include:

  • Assumption log–assumptions that have been made during the procurement process will be added to this log
  • Lessons learned register–as with many other processes, lessons learned earlier in the project can be applied further along in the project, in this case, to improve contractor performance and the procurement process.
  • Milestone list–shows when the sellers are expected to deliver their results
  • Quality reports–identifies seller processes, procedures, or products that are out of compliance.
  • Requirements documentation–may include
    • Technical requirements the seller is required to satisfy
    • Requirements with contractual and legal implications
  • Requirements traceability matrix–links product requirements from their origin to the deliverables that satisfy them, and shows the owner of requirements who should be consulted and/or informed about any issues related to those requirements
  • Risk register–risk related to the approved sellers are added to the register, including those related to:
    • The seller’s organization
    • The duration of the contract
    • The external environment
    • The project delivery method
    • Type of contracting vehicle chosen (fixed-cost or cost-reimbursable)
    • Final agreed-upon price
  • Stakeholder register–includes information about identified stakeholders, in particular contracted team members, selected sellers, contracting officers, and other stakeholders who are involved in procurements.

12.3.1.3  Agreements

The agreements are reviewed during this process to make sure that terms and conditions are being met.

12.3.1.4 Procurement Documentation

The following documents related to procurements may be used in this process.

  • Procurement state of work (SOW)\
  • Payment information
  • Contractor work performance information
  • Plans, drawings
  • Correspondence

12.3.1.5 Approved Change Requests

For the change requests are made as a result of this process, if they were approved by the process 4.3 Perform Integrated Change Request, they are then formally documented in writing and then implemented.  Modifications may include:

  • Terms and conditions of the contract
  • Procurement statement of work (SOW)
  • Pricing
  • Descriptions of the products, services, or results to be provided.

Note that the change requests from one seller may, in the case of a complex project, influence other involved sellers.   The product should have the capability of coordinating changes that impact the work of multiple sellers.

12.3.1.6   Work Performance Data

Seller data on project status may include:

  • Technical performance
  • Activities that have been started, are in progress, or have been completed
  • Costs incurred or committed
  • Seller invoices that have been paid

12.3.1.7  Enterprise Environmental Factors

The enterprise environmental factors (outside of the organization’s control) that can influence this process include:

  • Contract change control system
  • Marketplace conditions
  • Financial management and accounts payable system

Note that, for the contract change control system and financial management and accounts payable system, the software itself is created by an outside company and is therefore an enterprise environmental factor or EEF, in a similar way that the Project Management Information System (PMIS) such as Microsoft Project is an EEF.   The data however that is created on the system by the organization is, however, an organizational process asset.

12.3.1.8  Organizational Process Assets

The organizational process asset (under the organization’s control) that can influence this process includes procurement policies of the organization

The next post covers the tools and techniques of this process.

 

Advertisements

Leave a Reply

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

WordPress.com Logo

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

Google+ photo

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

Twitter picture

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

Facebook photo

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

Connecting to %s

%d bloggers like this: