6th Edition PMBOK® Guide–Process 12.1 Plan Procurement Management: Inputs


Goods and services needed to do your project can be procured from other parts of the organization performing the project, in which case you will get them through Resource Management, which is covered by chapter 9 of the PMBOK® Guide, or you will get them from external sources, in which case you get will get them through Procurement Management, which is covered by chapter 12 of the PMBOK® Guide.

The first process in Procurement Management is process 12.1 Plan Procurement Management, which outlines how to do the other do processes, Conducting Procurement (process 12.2) and Controlling Procurement (process 12.3).

This post will cover the inputs to this process 12.1 Plan Procurement.

12.1.1 Plan Procurement Management:  Inputs

12.1.1.1  Project Charter

This contains the objectives of the project, a project description, summary milestones and the pre-approved financial resources for the project.    The objectives of the project and project description will help when describing the project to the potential sellers, and the summary milestones and pre-approved financial resources for the project will help in determining when to acquire the needed goods and services and how to acquire them.

12.1.1.2  Business Documents

  • Business case–this is usually created by the business analyst, and the main point in referring to this document is that the procurement strategy needs to be aligned to the strategy underlying the business case.
  • Benefits management plan–this describes when the specific project benefits are expected to be available, which will drive the dates of the procurement as well as the language of the contract.

12.1.1.3  Project Management Plan

The components of the project management plan that may serve as inputs to this process are:

  • Scope management plan–this will describe how the scope of work done by the contractors will be managed through the execution phase of the project.
  • Quality management plan–this will describe any applicable industry standards as well as any other codes that the project is required to follow.   These standards will be included in bidding documents such as the Request for Proposal (RFP), and may be used as part of the selection criteria for supplier prequalification.
  • Resource management plan–this has information on which resources will be purchased or leased, along with any assumptions or constraints that would influence the procurement.\
  • Scope baseline–the scope baseline actually consists of three separate documents:  the scope statement (which breaks the scope down from the requirements to the level of deliverables), the Work Breakdown Structure or WBS (which breaks the scope down further from the level of deliverables to the level of work packages), and the WBS dictionary (which gives additional information on the work packages).   The scope baseline is used to develop the
    • statement of work (SOW), a narrative description of products, services, or results to be delivered by the project, and the
    • terms of reference (TOR), which defines the purpose and structures of the project.

12.1.1.4   Project Documents

  • Milestone list–this list of major milestones for the project will show when the sellers are required to deliver their results
  • Project team assignments–this contains information on the skills and abilities of the project team and their availability to support the procurement activities.
  • Requirements documentation–this may include:
    • Technical requirements that the seller is required to satisfy
    • Requirements with contractual and legal implications, such as health and safety regulations, licenses, permits, intellectual property rights, etc.
  • Requirements traceability matrix–this lists the product requirements from their origin to the deliverables that satisfy them, as well as the “owners” of the requirements who can be consulted if there are questions concerning them.
  • Risk register–some risks may be transferred to the seller via a procurement agreement.
  • Stakeholder registre–provides details on the project participants and their interests in the project, which for the sake of procurement will include the contracting personnel (those specializing in procurement within the organization doing the project) as well as legal personnel (who manage the agreements with sellers).

12.1.1.5  Enterprise Environmental Factors

  • Marketplace conditions, as well as products, services and results available in the marketplace.
  • Past performance of reputation of potential sellers
  • Multi-tier supplier system of prequalified sellers based on prior experience
  • Typical terms and conditions for products, services and results for the specific industry
  • Unique local requirements, such as regulatory requirements for sellers (including local labor)
  • Contract management systems, including procedures for contract change control)
  • Legal advice regarding procurements
  • Financial accounting and contract payments system

12.1.1.6  Organization Process Assets

  • Preapproved seller lists–lists of sellers that have been properly vetted can streamline the steps needed for the seller selection process
  • Formal procurement policies, procedures, and guidelines–most organizations have formal procurement policies and buying organizations.   In fact, all aspects of procurement may be handled not by the project manager, but by a designated procurement manager for the organization.   If this is not the case, then the project team will have to supply both the resources and the expertise to perform such procurement activities.
  • Contract types–all legal contractual relationshps generally fall into two broad families:   either fixed-price contracts where the cost risk falls on the seller, or cost-reimbursable contracts where the cost risk falls on the buyer.   These contract types can be modified by incentive fees, economic price adjustments, and/or award fees in order to balance the risk between the parties.  There is a third type of contract called the time and materials contract, which is considered a hybrid type or contract, as the risk is shared by both the seller and the buyer.

The details regarding the variations on the fixed-price and cost-reimbursable contracts are on pp. 471 and 472 of the 6th Edition of the PMBOK® Guide.   The next post will cover the tools and techniques of the process 12.1 Plan Procurement Management.

Advertisements

6th Edition PMBOK® Guide: Process 11.7 Monitor Risks: Outputs


Well, I’m back after a brief “vacation” from having moved and sold our old house.   Now that I’m not 100% unpacked yet, I’m installed enough into my new place to be able to start making blog posts again.

Today I’m concluding Chapter 11 on Risk Management with the final post on the outputs for the last risk management process, 11.7 Monitor Risks.   Now the process group is the “monitoring and controlling” process group, and even though the title of the process is “monitoring”, it always includes the “controlling” part, which means making changes if the monitoring part of the process shows that changes are needed.   These change requests are handled in the usual way, by being processed through the Perform Integrated Change Control process 4.6 (under the Integration Management knowledge area).

11.7.3  Monitor Risks:  Outputs

11.7.3.1  Work Performance Information

The risk register is reviewed and any changes to the previously agreed-upon risk responses for individual project risks are noted.   These changes are reviewed to indicate the effectiveness of the response planning (process 11.5 Plan Risk Responses) and response implementation processes (process 11.6 Implement Risk Responses).   Any changes in either the planning or the implementation should be made through a change request (see next paragraph).

11.7.3.2  Change Requests

The process of reviewing the risk register may result in changes to risk response planning and/or the implementation of those risk responses.   If these changes in turn require changes to the cost and/or schedule baseline (to account for the additional cost and/or time required to implemented those changed responses), then all of these changes need to be made through a change request.   These changes may be made with respect to individual project risks or to address the current level of overall project risk.

These requests are sent to the Perform Integrated Change Control process 4.6 in order to make the decision to accept or reject them.   If rejected, they go into the change log with the reasons for the rejection.   If they are accepted, then the changes are made to the project management plan (see next paragraph on Project Management Plan Updates).

11.7.3.3  Project Management Plan Updates

If the change requests mentioned in the last paragraph are accepted, the project management plan is updated accordingly, especially if the changed risk responses require changes to the cost and/or schedule baseline (to account for the additional cost and/or time required to implement the new or changed responses).   The changed risk responses themselves will be recorded in the risk register (see next paragraph on Project Document Updates)

11.7.3.4  Project Document Updates

  • Assumption log–in the process of monitoring risks, new assumptions may be uncovered, and existing assumptions may be revisited and changed.   The assumption log is updated with this new information.
  • Issue log–issues uncovered in the process of monitoring risks, usually related not to the contents of the risks themselves but in the handling of those risks, are recorded in the issue log.
  • Lessons learned register–if there are lessons learned as a result of the risk reviews done in this process, then these are recorded in the register so that they can be used on later phases of the project.
  • Risk register–the following are changes that might be made as a result of the Monitor Risks process:
    • Adding new risks that were not picked up during the original risk assessment but were noticed during the review
    • Updating outdated risks, so that if a risk triggered by a particular activity or task does not occur, then this risk can be considered outdated or obsolete.   This is important because the contingency reserve for the risk response associated with that risk may now be returned to the project budget, since it is now no longer needed for the outdated risk.
    • Updating risks that were realized to compare the amount of money actually spent with the amount put aside from the contingency reserve to pay for the response.   Besides reviewing the contingency reserve for those responses, the actual risk response needs to be reviewed to compare it with the expectation of how it should have occurred.   This may indicate that the effectiveness of the response planning and/or response implemtnation process needs to be changed.
    • Monitoring the risks on the “watch list” (those with low impact/low probability) to see if any of them need to be taken off the watch list, i.e., if their impact and/or probability has increased to the point where you need to add a risk response to account for them.
  • Risk report–another important part of the Monitor Risk process is letting the shareholders know what is going on with respect to risk.   This is done through the risk report, which is updated with the following based on the results of this process:
    • Current status of major individual project risks, including details of the top individual project risks, the agreed-upon risk responses and risk owners for those risks
    • Current level of overall project risks
    • Conclusions and recommendations for changes to the risk responses themselves
    • Conclusions from risk audits on the effectiveness of the risk management process

11.7.3.5  Organizational Process Assets Updates

The Monitor Risks process may result in changes to the following organizational process assets:

  • Templates for the risk management plan, risk register, and risk report
  • Risk breakdown structure (shows the source of risk on the project by category)

 

Wow, that chapter covers one of the most complicated aspects of project management, but one which will take you from being a good project manager to a great one if you can master it!

The next post will start on Project Procurement Management, which is the only “optional” knowledge area for project management, because you may be working on a project whose scope is limited enough that you can get the entire project done with resources from within the organization you belong to.   If, however, you need to acquire products, services, or results from outside the organization, then you need procurement management.   I will start with the inputs needed for the first process 12.1 Plan Procurement Management.