6th Edition PMBOK® Guide–Process 13.2 Plan Stakeholder Management: Inputs

The Plan Stakeholder Management process has its aim the production of the Stakeholder Management Plan.   Like the management plans for other knowledge areas, it contains the guidelines for how to do all of the other processes in the area, such as Manage Stakeholder Engagement and Monitor Stakeholder Engagement.

Here are the inputs:

13.2.1  Plan Stakeholder Engagement:  Inputs  Project Charter

The project purpose, objectives, and success criteria can be used in planning how to engage stakeholders.  Project Management Plan

Here are the components of the overall project management plan that can be used for this process.

  • Resource management plan–may contain information regarding roles and responsibilities of the team and other stakeholders listed in the stakeholder register.
  • Communications management plan–the communication strategies for stakeholder management and their implementation plans are input to this process
  • Risk management plan–may contain risk thresholds or risk attitudes that can assist in the selection of the optimal stakeholder engagement strategy.

13.2.3 Project Documents

  • Assumption log–contains information about assumptions and constraints that may be linked to specific stakeholders.  ]
  • Change log–changes to the original scope of the project are usually linked to specific stakeholders who are requesting those changes, or who are involved in the decision about change requests.
  • Issue log–resolving issues contained in the issue log will require additional communications with the stakeholders affected.
  • Project schedule–contains activities that may be linked to specific stakeholder as owners or executors
  • Risk register–contains identified risks of the project and links them to specific stakeholders either as risk owners or as subject to impact from that risk.
  • Stakeholder register–the output of process 13.1 Identify Stakeholders.   The preliminary list of project stakeholders, including additional data about their classification.  Agreements

When planning for the engagement of contractors and suppliers (who are one subset of stakeholders), coordination usually involves working with the procurement/contracting group in the organization to ensure contractors and suppliers are effectively managed.  Enterprise Environmental Factors

  • Organizational culture, political climate, governance framework
  • Personnel administration policies
  • Stakeholder risk appetites
  • Established communication channels
  • Global, regional or local trends
  • Geographical distribution of facilities and resources. Organizational Process Assets

Among the OPAs listed on p. 520 of the PMBOK Guide, here are the ones that I feel are the most relevant to this process.

  • Corporate policies and procedures for social media.
  • Corporate policies and procedures for issue, risk, change, and data management.
  • Lessons learned repository with information about the preferences, actions, and involvement of stakeholders

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

6th Edition PMBOK® Guide–Process 13.1 Identify Stakeholders: Outputs

In the same way that the initial Risk Management planning process creates the risk register, which is then modified throughout the remaining processes in that knowledge area, the initial Stakeholder Management process creates the stakeholder register, which is then modified throughout the remaining processes in the Stakeholder Management knowledge area.

The other outputs are updates to the project management plan and project documents.

13.1.3  Identify Stakeholders:  Outputs\  Stakeholder Register

This document contains the following information about identified stakeholders:

  • Identification information–name, organization position, location and contact details, and role on the project.
  • Assessment information–major requirements, expectations, potential for influencing project outcomes, and the phase of the project life cycle where the stakeholder has the most influence or impact.
  • Stakeholder classification–Internal/external, impact/influence (or power/interest), upward/downward/outward/sideward influence, or any other classification model chosen by the project manager.  Change Requests

The initial iteration of identifying stakeholders will not generate change requests.  However, as stakeholder identification continues throughout the project, new stakeholders or new information about the stakeholders may result in a change request.  Project Management Plan Updates

Of course, the main component that will be updated is

  • Stakeholder management plan–agreed-upon communication strategies for identified stakeholders are recorded in the stakeholder engagement plan.

Additional components of the overall project management plan that may be updated may include the following:

  • Requirements management plan–newly identified stakeholders can impact how requirement activities will be planned, tracked, and reported.
  • Communications management plan–stakeholder communication requirements and agreed-upon communications strategies are recorded in the communications management plan.
  • Risk management plan–if stakeholder communication requirements and agreed-upon communications strategies affect the approach to managing risk on the project, this is reflected in the risk management plan. Project Documents Updates

  • Assumption log–much of the information about the relative power, interest, and engagement level of stakeholders is based on assumptions, which are entered into the assumption log.   Any constraints associated with interacting with specific stakeholders are entered as well.
  • Issue log–new issues raised as a result of identifying stakeholders are recorded in the issue log.
  • Risk register–New risks identified during this process of identifying stakeholders are recorded in the risk register and managed during the risk management process.

This process is actually in the initiating process group, which consists of only two processes:  this one and 4.1 Develop Project Charter.   The fact that identifying stakeholders happens even BEFORE proper planning on the project begins tells you how vital PMI thinks the process is for the success of the project.

Now let’s move to the planning process group, which will create as a result the Stakeholder Management Plan, namely, process 13.2 Plan Stakeholder Engagement.  The inputs to that process are contained in the next post.

6th Edition PMBOK® Guide–Process 13.1 Identify Stakeholders: Tools and Techniques

There are certain processes that go in at the beginning of the project which require a brainstorming approach.   Of course, defining and then refining the requirements of the product, service or result is the core of the project planning.

However, if you want to take your project management career to the next level of success, you need to get a handle on two areas:   Risk Management and Stakeholder Management.   They may not seem on the surface to be related, but they are linked at a deeper level in the following way:   a risk is defined as an event or situation that may affect the project, and a stakeholder is a person who may influence the project (or who may be influenced by the project).   In either case, they are not under your control, and yet may effect the outcome of your project.   Trying to manage these factors that are partially out of your control is key to success so that you don’t get sidetracked on your goal of a successful project outcome.

However, the methods of dealing with these factors differs.  In risk management, you try to mitigate those factors either in terms of probability and/or impact.   You can’t control the weather, for example, but you can buy an umbrella and keep it handy so that if it does rain, you mitigate its impact on you and your clothes.   With stakeholders, we’re talking about people, so rather than try to mitigate their impact, you can actually engage with them and attempt to assuage them if they are initially opposing your project.

But in order to engage them, you have to first identify who the stakeholders are.   That is the goal of this process.  In this post, we will discuss the tools and techniques involved.

13.1.2  Identify Stakeholders:  Tools and Techniques  Expert Judgment

“Expert judgment” and “meetings” (tool and technique–see paragraph below) are what I call “generic” tools and techniques in that they are used with many, if not, most of the project management processes.

In this case, expertise should be considered from people who have specialized knowledge in:

  • Understanding the politics and power structures in the organization
  • Knowledge of the industry or type of project deliverable
  • Knowledge of the wider environment and culture including customers
  • Knowledge of individual team members contributions and expertise  Data Gathering

Here are the techniques for gathering data that can be used for this process.

  • Questionnaires and surveys–these can include one-one-on interviews or focus group sessions (see “Meetings” paragraph below)
  • Brainstorming–this elicits input from groups such as team members of subject matter experts (see “Expert Judgment” paragraph above).   Brain writing is a variant on brainstorming that allows individual participants time to consider the question(s) before the group creativity session is held.  Data Analysis

Once you’re gathered the data in the techniques listed above, how do you analyze them?

  • Stakeholder analysis–stakeholders are listed together with their
    • positions in the organization
    • relationship to the project (are they on the project, are they affected by the outcome of the project, can they affect the outcome of the project)
    • stake in the project (do they have relevant knowledge, resources, ownership or rights to an asset or property, or interest in the project’s outcome)
  • Document analysis–the repository of lessons learned from previous projects may contain information that may help identify stakeholders for the current project  Data Representation

Once you’ve analyzed the data in the techniques listed above, how to you represent them in order to prepare the stakeholder register (the outcome of the process)?

  • Impact/influence grid–this is one example of the way information gathered and analyzed in the techniques listed above can be represented in a way that pulls it all together.   One axis of the grid represents the power or influence a stakeholder has in the organization, and therefore has over the project the organization is undertaking.   One axis of the grid represents the impact that the product, service or result created by the project will have on that stakeholder.   Those who have are not impacted by the project, and who have little interest in the project, will be treated like risks that have little probability or impact on the project–i.e., they will be “monitored” in case their attitude towards the project changes., and simply informed about the results.   On the other hand, those who are greatly impacted by the project, and who have great interest in the project, will be positively engaged by the project manager.   Those in between may be informed about the process and engaged to a lesser extent by the project to increase their interest and support for the project.

The “influence” part of the impact/influence grid listed above can be given further analysis through analysis of the “directions of influence” a person has, such as:

  • Upward (senior management)
  • Downward (subject matter experts who contribute their knowledge or skills)
  • Outward (stakeholder groups and their representatives outside the organization)
  • Sideward (other project managers or middle managers who are in competition for scarce project resources)

There are other data representation techniques, like a “stakeholder cube”, which basically takes the impact/influence grid mentioned above and adds a third dimension to the analysis.   The salience model which assesses the stakeholder’s power, urgency and legitimacy (i.e., their involvement in the project is appropriate), is an example of this type of three-dimensional model.   Look at p. 512 and 513 of the 6th Edition of the PMBOK® Guide for further details.

These techniques help with prioritization of your stakeholder engagement efforts.   Those stakeholders with high levels of impact and/or influence will obviously receive more of your efforts to try to engage them.    The types of engagement you will resort to will be spelled out in the next process 13.2 Plan Stakeholder Management.  Meetings

Meetings are used to develop an understanding of significant project stakeholders through brainstorming techniques that gather and analyze data.   They can take the form of

  • Facilitation workshops
  • Small group guided discussions
  • Virtual groups (using electronics or social media technologies)

The output of these meetings will be to create forms of data representation (mentioned the previous paragraph) to help prioritize the engagement of stakeholders in the next process.

The outputs of this process will be discussed in the next post.

6th Edition PMBOK® Guide–Process 13.1 Identify Stakeholders: Inputs

The 5th Edition PMBOK® Guide introduced a new knowledge area called Stakeholder Management.   Before then, stakeholder management was done as part of communications management.   But PMI felt that it is not only important to communicate with stakeholders, but also to actively engage them during the course of the project.

This concept is continued in the 6th Edition.   Stakeholder management not only has processes in the planning, executing, and monitoring and controlling process group, but it also has a process in the initiating process group, namely this process 13.1 Identify Stakeholders.   This post will discuss the inputs to this process.

13.1.1  Identify Stakeholders:  Inputs  Project Charter

The project charter contains the statement of what the project is about, and gives authorization to the project manager to run the project.   Besides these key functions, however, the project charter contains vital information relevant to specific knowledge areas, including stakeholder management.   It should contain a list of the key stakeholders, which is the starting point for this process, as well as information about their responsibilities within the organization.  Business Documents

Project managers need to look at the documents created by business analysts, whose outputs are the business documents listed below.   These documents may contain key information about stakeholders that will be useful in doing this process.

  • Business case–identifies the project objectives and identifies an initial list of stakeholders affected by the project.
  • Benefits management plan–benefits management does not have to do with human resources; in the language of PMI, it refers to realizing the benefits claimed in the business case.   Stakeholders are identified that will benefit from the delivery of the outcomes of the project.  Project Management Plan

The two components of the overall project management plan that are used in the course of this process are the communications management plan and the procurement management plan.   These knowledge areas are linked; as mentioned above, stakeholder management developed as an outgrowth of communications management.

  • Communications management plan–contains information about how to communicate with the various types of stakeholders
  • Stakeholder engagement plan–identifies management strategies and actions required to effectively engage stakeholders in general  Project Documents

Although project documents are not available for the initial stakeholder identification, they will be useful for stakeholder identification that occurs throughout the project.

  • Change log–may be updated to introduce a new stakeholder or change the nature of an existing stakeholder’s relationship to the project (this can happen if the person’s job description within the organization changes)
  • Issue log–may be updated if new issues introduce a new stakeholder or change the type of participation of existing stakeholders
  • Requirements documentation–may provide information on potential stakeholders that are relevant to specific requirements of the project  Agreements

The parties to an agreement are project stakeholders, whether the agreements are with sellers who provide procurements or with other organizations who are sharing the project work. Enterprise Environmental Factors

  • Government or industry standards
  • Global, regional, or local trends  Organizational Process Assets

  • Stakeholder register templates and instructions, and actual stakeholder registers from previous projects
  • Lessons learned repository with information about the involvement of stakeholders.

The next post will cover the tools and techniques associated with process.

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

This is the final post on this knowledge area, because it contains the outputs for the final process in that area, namely, 12.3 Control Procurements.

Note that in the 5th Edition of the PMBOK® Guide, closing procurements was a separate process (under the closing process group, of course).   However, in the 6th Edition, PMI has essentially but monitoring and controlling AND closing of a procurement in this single process of Control Procurements.

12.3.3  Control Procurements:  Outputs  Closed Procurements.

The authorized procurement administrator for the buyer provides the seller with formal written notice that the contract has been completed.   This happens after the project management team has approved the deliverables, checking that they have been provided on time and meet technical and quality requirements.  Work Performance Information

Information on how a seller is performing, by comparing the following to what was specified in the SOW and in the agreement:

  • deliverables received
  • technical performance achieved
  • costs incurred and accepted Procurement Documentation Updates

During the Control Procurements process, the following procurement documentation may be updated:

  • the contract
  • all supporting schedules
  • requested but unapproved or unresolved contract changes (see paragraph below on Change Requests)
  • approved change requests
  • seller-developed technical information
  • work performance information (see paragraph
  • seller performance reports and warranties
  • financial documents including invoices and payment records
  • results of contract-related inspections  Change Requests

As a result of monitoring and controlling procurements in the course of this process, change requests may be made to the project management plan.   These change requests are processed for review through process 4.6 Perform Integrated Change Control.

Any requested but resolved contract changes need to uniquely identified and documented by project correspondence, as these may changes may be disputed by one party which may can lead to a claim.  Project Management Plan Updates

Of course, the procurement management plan may need some updates:

  • Procurement management plan–updates may be required depending on the results of the performance of the sellers during execution of the work

The other project management plan component that may need updating is the risk management plan.

  • Risk management plan–if significant unexpected risks occur during the execution of the contract, the risk management plan may require updating.  Specific risks are incorporated into the risk register (see project documents updates paragraph below under “Risk Register”).

The baselines, another important component of the overall project management plan, may also need to be updated:

  • Schedule baseline–if significant schedule changes created by sellers impact the overall project schedule performance, the baseline schedule may need to be updated and approved to reflect the current expectations.   The buyer should be aware of any impacts of schedule delays created by one seller that may impact other sellers.
  • Cost baseline–contractor and materials cost can change, and these changes need to be incorporated into the cost baseline.  Project Documents Updates

  • Requirements traceability matrix–updates are made regarding requirements that have been satisfied
  • Risk register–changes made to the risks related to the approved sellers, or new risks 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–Any changes in the contractors and suppliers should be reflected in the stakeholder register, especially those stakeholders that are impacted by those changes.  Organizational Process Assets Updates

  • Payment schedules and requests–these are made in accordance with the procurement contract terms and conditions
  • Seller performance evaluation documentation–this is prepared by the buy and documents the seller’s ability to continue to perform work on the current contract, and indicates whether the seller can be allowed to perform work on future projects.
  • Prequalified seller lists updates–according to the outcomes of the Control Procurement process, sellers could be disqualified and removed from the prequalified seller lists based on poor performance.
  • Lessons learned repository–lessons learned during the procurement process should be archived to improve procurements on future projects.
  • Procurement file—a complete set of indexed contract documentation, including the closed contract, is prepared for inclusion with the final project files.

And that is it for this chapter!   The next chapter will discuss the final knowledge area, stakeholder management, which was created in the 5th Edition of the PMBOK® Guide and continues to be an important element of the 6th Edition of the Guide…


6th Edition PMBOK® Guide–Process 12.3 Control Procurements: Tools and Techniques

Here are the tools and techniques for the process 12.3 Control Procurements.

12.3.2  Control Procurements:  Tools and Techniques  Expert Judgment

This one is a “generic” tool and technique, that is, one that is used in all control processes, not just this one.

Expertise should be considered from individuals or groups with specialized knowledge related to procurements.   In particular, those with expertise in

  • Relevant functional areas including supply chain management
  • Laws, regulations, and compliance requirements,
  • Claims administration (in case of a disputed agreement with a seller)  Claims Administration

If there are contested changes to the agreement where the buyer and seller cannot reach an agreement, then the contested change becomes a claim, and needs to be resolved.   It may be handled through alternative dispute resolution (ADR) following procedures established in the agreement.   If it cannot be resolved, the dispute may be appealed in court.  Data Analysis

  • Performance Reviews–periodically the performance of a contract is reviewed.   This includes identifying work packages that are behind schedule, over budget, or have resource or quality issues.
  • Earned Value Analysis (EVA)–schedule and cost variances (SV and CV) or schedule and cost performances indices (SPI and CPI) are calculated to determine the degree of variance from target.
  • Trend Analysis–this is developing a forecast Estimate At Completion (EAC) for cost performance to see if performance is trending towards improvement or deteriorating.  Inspection

A structured review of the work being performed by the contractor needs to be done.   This inspection can involve a simple review of the deliverables or an actual physical review of the work itself.  Audits

A structured review of the procurement process.   The audit process should be described in the procurement process.   Resulting observations should be brought to the attention of the buyer’s project manager and the seller’s project manager for adjustments to the project if necessary.

With these tools and techniques, the outputs of the control procurement process can be created, which is the subject of the next post.

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 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  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.  Agreements

The agreements are reviewed during this process to make sure that terms and conditions are being met. 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 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.   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  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.  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.


6th Edition PMBOK® Guide–Process 12.2 Conduct Procurements: Outputs

The outputs for this process should be obvious given the tools and techniques such as Bidder Conferences and Proposal Evaluation discussed in the last post:   the list of selected sellers as a result, and of course the agreements themselves.   NOTE:  for some reason, PMI likes to refer to contracts as “agreements” in this 6th Edition of the PMBOK® Guide.

Then the procurements needed to fitted into the overall project, by making change requests to the project management plan, and if approved, incorporating those changes into the plan and any relevant project documents.

12.2.3  Conduct Procurements:  Outputs  Selected Sellers

Based on the proposal or bid evaluation, the selected sellers are those who have been judged to be in a competitive range.   There may be some procurements which are complex, high-value, or high-risk which may require the approve of senior management approval (specification of these thresholds of approval should be specified in the Procurement Management Plan).  Agreements

A contract is a mutually binding agreement between the seller and the buyer:

  • the seller is obligated to provide the specified product, service, or result under the specified conditions
  • the buyer is obligated to compensate the buyer according to the specified amount (and specified conditions, as in the case of an incentive or award fee)

This binds each party legally; if one side contests thinks that the other side has broken the agreement, it may to be handled through alternative dispute resolution (ADR) if negotiations between parties break down.   If ADR does not resolve the issue, then as a result each party may file a lawsuit and take the other party to court.   But the only basis for taking the matter to court is the contract.

Okay, what’s in an agreement?  Let’s break it down by knowledge area:

Integration management

  • Performance reporting
  • Change request handling

Scope management

  • Procurement statement of work (or major deliverables)

Schedule management

  • Schedule, milestones, or date by which a schedule is required

Cost management

  • Pricing and payment terms
  • Incentives and penalties

Quality management

  • Inspection, quality, and acceptance criteria
  • Warranty and future product support

Procurement management

  • Insurance and performance bonds
  • Subordinate subcontractor approvals
  • General terms and conditions
  • Termination clause and alternative dispute resolution (ADR) mechanisms  Change requests

The procurements of agreed-upon sellers will necessarily add to the original project management plan, based on what the buyer can do alone.   These change requests are sent on to process 4.3 Perform Integrated Change Control.  If approved, then the content of those requests are added to the project management plan (see next paragraph and any relevant project documents (see paragraph  Project Management Plan Updates

As mentioned in the post on inputs, not only the procurement management plan component of the overall project management plan, but other components such as the management plans of other knowledge areas and the project baselines (scope, schedule and scope) will be updated as a result of changes that are approved (see paragraph

Here are the components that may be updated as a result of change requests coming from procurements.

  • Requirements management plan–project requirements may be updated due to changes identified by sellers.
  • Quality management plan–sellers may offer alternative quality standards or alternative solutions that impact the quality approaches defined in the original quality management plan.
  • Communications management plan–the communications management is updated  to incorporate the communications needs and approaches of sellers.
  • Risk management updates–each agreement and seller has its own set of risks that may require updates to the risk management plan.  Specific risks are incorporated into the risk register (see project document updates in paragraph
  • Procurement management plan–the results of the contracting and negotiations process are added to the procurement management plan.
  • Scope baseline–the project WBS and deliverables documented in the scope baseline are considered when performing procurement activities.
  • Schedule baseline–if delivery deadline changes are created by sellers that impact overall project schedule performance, the baseline schedule may need to be updated and approved to reflect the current expectations.
  • Cost baseline–The price of contractors and materials may change during the delivery of a project.  These changes can occur because of the fluctuating cost of materials and labor created by the external economic environment and need to be incorporated into the cost baseline.  Project Document Updates

Here are the project documents that may need to be updated as a result of this process.

  • Lessons learned register–in a similar way as with all processes, any information or challenges encountered while conducting procurements and how they could have been avoided, as well as approaches that worked well.
  • Requirements documentation–this may include:
    • Technical requirements that the seller is required to satisfy;
    • Requirements with contractual and legal implications
  • Requirements traceability matrix–the requirements register and the traceability matrix may change depending on the capabilities of the specific seller.
  • Resource calendar–schedule resource calendars may be needed to be updated depending on the availability of the sellers
  • 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–updates are made to the register regarding those stakeholders who are influenced by or who have influence on agreements that are made with specific sellers. Organizational Process Assets Updates

As typical with many processes, the inputs include Environmental Enterprise Factors (external and not just control of the organization) as well as Organizational Process Assets (internal and under control of the organization), but the outputs are confined to updates to the Organizational Process Assets, such as:

  • Listings of prospective and prequalified sellers may be updated with the list of new sellers identified as a result of this process
  • Information on relevant experience with sellers, both good and bad, is added as the procurement proceeds

The final process is 12.3 Control Procurements, which covers monitoring, controlling, and closing the procurement when it is completed.



6th Edition PMBOK® Guide–Process 12.2 Conduct Procurements: Tools and Techniques

In the last post, I covered the inputs to the process 12.2 Conduct Procurements.   In this post, I am moving on to the tools and techniques used in the process.

12.2.2  Conduct Procurements:  Tools and Techniques  Expert Judgment

Experts should be considered from individuals or groups with specialized knowledge or training in the following topics:

  • Proposal evaluation
  • Technical or subject matter related to the project
  • Relevant functional area (finance, engineering, design, development, supply chain management, etc.)
  • Industry regulatory environment
  • Government regulations, laws, and compliance requirements
  • Negotiation

Many organizations centralize their procurement system and will have a procurement manager handle the details of the procurement for you project.  Advertising

Communicating with users or potential user of a product, service, or result in order to solicit interest in bidding on a contract for procurement.   Placing advertisements in selected newspapers and/or specialty trade publications can often expand existing lists of potential sellers.

Note that most government jurisdictions require public advertising or online posting of pending government contracts.  Bidder Conferences

Also referred to as:

  • Contractor conferences
  • Vendor conferences
  • Pre-bid conferences

These conferences ensure that all prospective bidders have a clear and common understanding of the procurement and no bidders receive preferential treatment.  Data Analysis

Proposal evaluation is the technique used for this process.  Using the Source Selection Criteria (one of the outputs included in Procurement Documentation from process 12.1 Plan Procurement Management), the bidder proposals are evaluated to ensure that they are complete and respond in full to the bid documents.   In that way there is no delay in the bidder conferences (see paragraph above).  Interpersonal and Team Skills

Negotiation is the interpersonal and team skill that can be used for this process.

Procurement negotiation clarifies the structure, rights, and obligations of the parties so that they mutual agreement can be reached prior to signing the contract.

The negotiation should be led by a member of the procurement team that has the authority to sign contracts.   As mentioned above, many organizations centralize their procurement, in which case a procurement manager will be leading the negotiations.   The project manager and other members of the project management team may be present during negotiation to provide assistance as needed.

And that concludes the tools and techniques involved in this process.  The next post will cover the outputs.

6th Edition PMBOK® Guide–Process 12.2 Conduct Procurements: Inputs

The first process in the procurement management knowledge area, process 12.1 Plan Procurements Management, is in the planning process group.   This process, 12.2 Conduct Procurements, is in the executing process group.   The next process, 12.3 Control Procurements, is in the monitoring and controlling process group.   In the last edition of the PMBOK® Guide, there was a separate process for closing procurements.   However, in the current 6th Edition, closing procurements is considered part of 12.3 Control Procurements, and does not have a separate process.

With that preliminary note out of the way, let’s now consider the inputs to the process 12.2 Conduct Procurements.

12.2  Conduct Procurements:  Inputs  Project Management Plan

Of course, the procurement management plan, the output of the last process, is an input to this one.

  • Procurement Management Plan–This contains the activities to be undertaken during the other two processes, including this one of Conduct Procurements.

But there are other components of the overall project management plan that are used as inputs for this process as well, in as far as they involve procurements for the project.   These include:

  • Scope Management Plan–describes how the scope of work performed by sellers will be managed
  • Requirements Management Plan–describe how sellers will manage the requirements they are under agreement to satisfy
  • Communications Management Plan–describes how communications between buyers and sellers will be conducted
  • Risk management plan–describes how risk management activities related to procurements will be structured and performed for the project.  NOTE:  The buyer may decide to sign agreements with more than one seller to mitigate damage caused by relying on a single seller, who may have problems that impact the overall project.
  • Configuration management–just as it is important to control the coordination of changes to the overall project through configuration management, it is also important to include formats and processes for how sellers will provide configuration management in a way that is consistent with the buyer’s approach.
  • Cost baseline–this includes the budget for the procurement as well as the costs associated with the procurement process and sellers.  Project Documents

  • Lessons learned register–lessons learned with regard to conducting procurements will be recorded in the register so that they can be applied to later phases in the project (the Control Procurements process) to improve efficiency.
  • Project schedule–the start and end dates of procurement activities are identified, as well as when contractor deliverables are due.
  • Requirements documentation–technical requirements that the seller is required to satisfy, as well as contractual and legal 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–contains the details about the identified stakeholders who are interested in and/or have influence on procurements.  Procurement Documentation

These are outputs of the process 12.1 Plan Procurement Management.

  • Bid documents–These may include the Request for Information (RFI), Request for Proposal (RFP), Request for Quotation (RFP), or other documents sent to sellers so that they can develop a bid response.
  • Procurement statement of work (SOW)–provides sellers with a clearly stated set of goals, requirements, and outcomes from which they can provide a quantifiable response in their bid.
  • Independent cost estimates–provides a reasonableness check against the proposals submitted by bidders.
  • Source selection criteria–describes how the bidder proposals will be evaluated, including evaluation criteria and the weighting system used.  Seller Proposals

These responses to a procurement document package (see paragraph above) form the basic information that will be used to select one or more successful bidders.  The organization may require that the price proposal be submitted separately from the technical proposal.  Enterprise Environmental Factors

The factors outside of control of the organization that may influence this process are:

  • Local laws and regulations regarding procurements (including local sourcing requirements)
  • External economic environment constraining procurement processes, including marketplace conditions.
  • Contract management systems  Organization Process Assets

  • List of preferred sellers that have been pre-qualified.
  • Organizational policies that influence the selection of a seller
  • Specific organizational templates or guidelines that will determine the way agreements are drafted.
  • Financial policies and procedures regarding invoicing and payment processes.

The next post will cover the tools and techniques of this process.