4squareviews

In this post, I continue going through the various outputs for the Plan Procurement Management process.   The most important output is the Procurement Management Plan, from which the process gets its name.   Here are some additional outputs.

12.1.3.1  Plan Procurement Management

12.1.3.2 Procurement Strategy

Once the make-or-buy decision is complete (output 12.1.3.6) and the decision is made to acquire products or services from outside the project, a procurement strategy should be identified which includes the following three major elements.

• Delivery methods
  • For professional services, delivery methods include:  no subcontracting, subcontracting, joint venture, and representative.
  • For industrial and commercial construction, delivery methods include:  turnkey, design build (DB), design bid build (DBB), design build operate (DBO), and build own operate transfer (BOOT).
• Contract payment types
  • Fixed-price contracts:   suitable for predictable work with well-defined requirements
  • Cost-plus contracts:   suitable when work is evolving with not well-defined requirements
  • Incentive fees and awards may be used to align the objectives of buyer and seller
• Procurement phases
  • Sequencing or phasing of the procurement, with criteria for moving from phase to phase
  • Performance indicators and milestones to be used in monitoring, including monitoring and evaluation plan for tracking progress
  • Process for knowledge transfer to use in subsequent phases

12.1.3.3 Bid Documents

Bid documents are used to solicit proposals from prospective sellers.  Terms such as “bid”, “tender”, or “quotation” are used when the seller selection is based on price, and is usually used when purchasing standard items.   On the other hand, a term such as “proposal” is used when the seller selection is based on other considerations such as technical capability or technical approach, and is usually used when purchasing custom items.   Here are the types of bid documents typically used in procurements:

• Request for Information (RFI)–used when collecting information about the capabilities of various suppliers.   This is followed by one of the two following documents:
• Request for Quotation (RFQ)–when the seller selection is based on price
• Request for Proposal (RFP)–when the seller selection is based on technical capability or technical approach in addition to price

The RFP is obviously the most formal of the “request for” documents, and it includes the following:

• Description of the desired form of the response
• Relevant procurement Statement of Work (SOW) (see paragraph 12.1.3.4 below)
• Required contractual provisions

12.1.3.4  Procurement Statement of Work

In the same way that a seed contains the genetic blueprint for a plant, the SOW contains a blueprint of the procurement in the form of the definition of the project scope to be included within that procurement.   The SOW can include the following:

• Technical specifications
• Quantity desired
• Quality levels
• Performance data
• Period of performance
• Work location

Enough detail is included so that prospective sellers can determine if they are capable of providing the products, services, or results to be included in the procurement.

When contracting for services, sometimes Terms of Reference (TOR) are used in place of a Statement of Work.    A TOR can include the following:

• Tasks the contractor is required to perform
• Specified coordination requirements (delivery dates, communication methods, etc.)
• Standards the contractor will fulfill that are applicable to the project
• Data that needs to be submitted for approval
• Detailed list of all data and services that will be provided to the contractor by the buyer for use in performing the contract
• Definition of the schedule for initial submission and the review/approval time required

12.1.3.5  Source Selection Criteria

The buyer seeks to ensure that the proposals selected in response to the RFP will offer the best quality for the services required.   The PMBOK® Guide lists these in somewhat random order on p. 478.   I’m listing them below organized by the knowledge area they are most relevant to.

Integration Management

• Suitability of the knowledge transfer program, including training

Scope Management

• Adequacy of the proposed approach and work plan in responding to the SOW

Schedule Management

• Delivery dates

Cost Management

• Product cost and life cycle cost
• Financial stability of the firm

Quality Management

• Technical expertise and approach

Resource Management

• Capability and capacity
• Specific relevant experience
• Key staff’s qualifications, availability, and competence
• Management experience

Communications Management

• Local content requirements (for international projects)

The specific criteria may be a numerical score, color-code, or a written description on how well the seller satisfies the buyer’s selection criteria listed above.  The criteria form part of a weighting system that can be used to rank all the proposals by the weighted evaluation scores assigned to each proposal, and finally to select a single seller with whom the buyer will sign a contract.

12.1.3.6  Make-or-Buy Decisions

This is the result of the make-or-buy analysis (described in the post on “tools and techniques” for this process).

12.1.3.7  Independent Cost Estimates

For large procurements, the procuring organization may either prepare its own independent estimate or have a cost estimate prepared by an outside professional estimator to serve as a benchmark on proposed responses.

12.1.3.8 Change Requests

If the decision is made to procure goods, services, or resources as a result of the make-or-buy decision (see paragraph 12.1.3.6 above), then this may require a change request to the project management plan, which are then evaluated through the Perform Integrated Change Control process 4.6.

12.1.3.9  Project Document Updates

• Lessons learned register–updated with any relevant lessons regarding:
  • regulations and compliance
  • data gathering (market research)
  • data analysis (make-or-buy analysis)
  • source selection analysis
• Milestone list–shows when the sellers are expected to deliver their results
• Requirements documentation
  • Technical requirements that the seller is required to satisfy
  • Contractual and legal requirements related to the agreements, including:
    • Health
    • Safety
    • Security
    • Performance
    • Environmental
    • Insurance
    • Intellectual Property Rights
    • Equal Employment Opportunity requirements
    • License, permits
• Requirements traceability matrix–links product requirements from their origin to the deliverables that satisfy them, and indicate the owners of the requirements (who is responsible and/or accountable for them, as well as who to consult and inform when making decisions regarding them)
• Risk register–each approved seller will comes with its own unique set of risks related to one of the following:
  • Seller’s organization
  • Duration of the contract
  • External environment
  • Project delivery method
  • Type of contracting agreement chosen
  • Final agreed-upon price
• Stakeholder register–updated with any additional information on stakeholders that may have an impact on procurements, including contracting and/or legal personnel within the organization.

12.1.3.10  Organization Process Assets Updates

Information on qualified sellers is updated to the organization based on the experience gained in this process.

The documentation within the company that relates to procurements includes the following (see previous output paragraphs for details)

• Procurement Management Plan (paragraph 12.1.3.1)
• Procurement Management Strategy (paragraph 12.1.3.2)
• Statement of Work (paragraph 12.1.3.4)
• Bid Documents (paragraph 12.1.3.3)

There is a summary table 12-1 of all the contents of these documents on p. 461 of the PMBOK® Guide.

And that covers the remaining outputs for the process 12.1 Plan Procurement Management.   The next process, 12.2 Conduct Procurements, is in the Executing process group, and the inputs to this process are covered in the next post.

Filed under: Uncategorized | Leave a comment »

In this post, I will review what the outputs are to the Plan Procurement Management process, the most important of which is, of course, the Procurement Management Plan.  Also, there will be a Procurement Strategy, Bid Documents (used in the next process), the Procurement Statement of Work, Source Selection Criteria (used in the next process), Make-Or-Buy Decisions, Independent Cost Estimates, Change Requests, and finally Project Documents Updates and Organizational Process Assets Updates.

Because there are so many outputs, I’m going to split up my discussion into a couple of posts.

Let’s go over the first output in this post.

12.1.3  Plan Procurement Management:  Outputs

12.1.3.1  Procurement Management Plan

The procurement management plan contains the activities to be undertaken in the procurement process, which will take place in the next two processes, Conduct Procurements and Control Procurements.

I will list the ones given on p. 475 of the PMBOK® Guide, but will organize them according to what other knowledge area they intersect (if any).   For all others, I’ll list them under the main knowledge area under consideration, namely Procurement Management.

Integration Management

• Constraints and assumptions that could affect planned procurements.

Schedule Management

• How procurement will be coordinated with project schedule development.
• Timetable of key procurement activities.

Cost Management

• The legal jurisdiction and currency in which payments will be made.
• Determination of whether independent estimates will be used and whether they are needed as evaluation criteria.

Risk Management

• Identifying requirements for performance bonds or insurance contracts to mitigate some forms of project risk (for example, cost risk).

Procurement Management

• Metrics used to manage procurement contracts.
• If the performing organization has a procurement department, the authority levels and other constraints of the project team.
• Prequalified sellers, if any, to be used.

Stakeholder Management

• Stakeholder roles and responsibilities related to procurement.

The level of detail of the plan–whether it is highly detailed or broadly framed, whether it it is written in a formal or informal manner–is based upon the needs of the project and the organization.

The next important output is the Procurement Strategy, which is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

Plan Procurement Management contains some tools and techniques which are generic, that is, common to other similar planning processes for other knowledge areas, and those specific to this particular process.   The generic tools and techniques are Expert Judgment and Meetings.   You talk to the experts who know about this particular knowledge area, and you discuss their findings at meetings with the project team.

You gather data about procurements, you analyze it, and then you use source selection analysis to help you evaluate the proposals for procurements that will come in the next procedure.

12.1.2 Plan Procurement Management:  Tools & Techniques

12.1.2.1 Expert Judgment

As a project manager, you will help from experts who have expertise in the following areas in order to draft your Procurement Management Plan.

• Procurement and purchasing
• Contract types and contract documents
• Regulations and compliance issues

If your company is large enough, it is possible that all procurements will be managed by a procurement manager.   If not, you will need to seek out experts who will assist you in managing them as the project manager.

12.1.2.2  Data Gathering

Market research is a data-gathering technique often used to help create the Project Management Plan.   Market research includes the following examination of industry and specific seller capabilities.   The objectives of market research are to:

• Leverage maturing technologies
• Balance risks associated with the sellers who can provide the desired materials or services, particularly with risks to various project constraints such as cost, schedule, and quality.

12.1.2.3  Data Analysis

Make-or-buy analysis is used to determine whether the deliverables of a project (which are found in the project scope statement) can best be accomplished by the project team or should be purchased from outside sources.   The factors to be considered are:

• the organization’s current resource allocation, as well as their skills and abilities
• the need for specialized expertise
• the desire not to expand permanent employment obligations
• the need for independent expertise
• the risks involved with the make-or-buy decision

The make-or-buy analysis make use financial tools and techniques, including the same ones used to analyze the viability of the project itself, such as

• Return on investment (ROI)
• Internal rate of return (IRR)
• Discounted cash flow
• Net present value (NPV)
• Benefit/cost analysis (BCA)

12.1.2.4  Source Selection Analysis

You need to look into the organization’s method for selecting the source of procurements.   Bidders need to know how they will be evaluated, because some of the selection methods require them to invest a large amount of time and resources upfront.

Commonly used selection methods include the following:

• Least cost–appropriate for procurements of a standard or routine nature which have well-established practices and standards and from which a specific and well-defined outcome is expected.
• Qualifications only–if the value of the procurement is relatively small, a full selection process may not make sense.   The buyer establishes a short list and selects the bidder with the best credibility and qualifications.
• Quality-based/highest technical proposal score.   For products and/or services that involve technology, the sellers are encouraged to submit a proposal with both technical and cost details.  The seller who submitted the highest-ranked technical proposal is selected if their financial proposal can be negotiated and accepted.
• Quality and cost-based.   If the risk and/or uncertainty are greater for the project, quality should be a key element when compared to cost.   The previous method of “quality-based and highest technical proposal score” is similar, but for products and services that involve technology.
• Sole source–if there is no competition, this method is acceptable ONLY when properly justified and viewed as an exception.   It is either for sole providers of a product or service, but for trusted providers with a history of past projects with the company.
• Fixed budget–when the statement of work (SOW) is well-defined, no changes are anticipated, and the budget is fixed and cannot be exceeded, this method may be appropriate.   The available budget is disclosed to invited sellers in the Request for Proposal (RFP) and the highest-ranking technical proposal given in response to that RFP is then selected.

12.1.2.5  Meetings

Meetings are used to determine the strategy for managing and monitoring the procurement, which is essentially the next two processes of procurement management.

The next post reviews the outputs of the Plan Procurement Management process.

Filed under: Uncategorized | Leave a comment »

In the last post on the inputs to the Procurement Management Plan, I listed some of the categories of contracts you can have with a vendor who is producing something you need for your project.

For a person who is new to procurement management, the list of categories (Fixed Cost, Cost Reimbursable, Time and Materials) and the subcategories underneath each of these can be hard to keep straight in your mind.   However, it becomes very simple to understand the difference between the main categories of Fixed Cost contracts and Cost Reimbursable contracts if you understand the concept of cost risk.

Now, risk as you is an event or condition which has an impact on the project, either a positive impact (an opportunity) or a negative impact (what people most commonly think of as a “risk”).    If you look at which particular constraint the risk has an impact on, you can get several categories of risk, such as scope risk, schedule risk, and cost risk.  What it means is that the risk in question may have a positive or negative impact on the costs of the project.   In other words, at least for a negative risk, it might cause the project to go over budget.

In the case of a procurement, it means that the cost to the seller of producing the procurement may exceed the cost that the buyer had originally agreed to pay.   Who pays for the overage?   THAT is the key question which determines whether a contract is a Fixed Cost contract or a Cost Reimbursable contract.    In a Fixed-Cost Contract, the buyer agrees to pay a certain cost for the procurement, and if the costs are above that agreed-upon amount, the seller has to pay the additional costs.   That means that the seller has a cost risk.

Now, in a Cost-Reimbursable contract, the buyer agrees to pay the additional costs, which means it is the buyer who has the cost risk.   So in either type of contract, there is a cost risk either on one side of the transaction or the other.   The whole purpose of the subcategories under each type is to create incentives to balance the cost risk between the parties, so that no party feels that it is taking on the burden of the majority of the cost risk.  The type of incentive will determine the type of sub-category of each contract type.

So that is the relationship of the cost risk to the type of procurement contract you choose.   In a future post, I will discuss the different types of incentive.  In the next post, I will return to discussing the first procurement management process, 12.1 Plan Procurement Management.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

In monitoring risks, you are not only monitoring the existing risks in the risk register, but you are seeing if there are new risks out there to be added to that register.   The tools and techniques listed under “Data Analysis” below are part of that process.   This is what might be considered the analogy of “quality control” when it comes to risk management.  The analogy of “quality assurance” comes with “Risk Audits”, another tool and technique listed below.

And since risk is such a multi-faceted phenomenon, it requires a large set of eyes and differing perspectives that come with them in order to get a handle on it.   This is where the final tool and technique comes in, that of “Meetings”, which should be a familiar tool and technique because it happens with a lot of processes that cover a lot of complex territory.

11.7.2  Monitor Risks:  Tools and Techniques

11.7.2.1  Data Analysis

• Technical performance analysis–technical performance measures such as weight of the item being produced, transaction times, number of delivered defects, storage capacity, etc. (depending on the type of project) can be analyzed to see if there is deviation, which can indicate the possible existence of underlying risk.
• Reserve analysis–reserve analysis compares the amount of contingency reserves remaining to the amount of risk remaining at any time in the project in order to determine if the remaining reserve is adequate.   So this is monitoring risk not directly, but indirectly through the contingency reserves which are used to pay for risk responses.   If risks do not occur, then the contingency reserves which were meant to pay for those risks can go back into the “pool” of reserves and strengthen this ratio.

11.7.2.2  Risk Audits

Risk audits consider the effectiveness of the risk management process.    Although the project manager is responsible for ensuring that risk audits are performed, PMI suggests that risk audit meetings be held separately from the risk review meetings in order to separate the “quality control” (focusing on the results) vs. the “quality assurance” (focusing on the process) aspects of risk management.   The format for the risk audit needs to be defined in the risk management plan before the audit is conducted.    The “quality control” part of the risk review is reviewing the effectiveness of the risk responses themselves, and this is done as part of the risk review meetings (see paragraph below).

11.7.2.3  Meetings

Risk reviews are scheduled meetings and, although PMI prefers to have risk review meetings separate from the periodic status meetings, they can be combined if this is specified in the risk management plan.   However, PMI does consider it imperative that risks be reviewed periodically in such meetings whether they are separate or combined with other meetings, and these meetings should discuss the following topics:

• Documenting the effectiveness of risk responses in dealing with overall project risk and identified individual project risks
• Identification of new individual project risks (including secondary risks that arise from agreed-upon risk responses)
• Reassessment of current risks (are they are any risks on the watch list, for example, that have increased in either probability and/or impact such that they now merit a risk response)
• Closing of risks that are outdated (and return of the contingency funds for the associated risk responses to the overall contingency reserve)
• Issues that have arisen as the result of risks that have occurred
• Identification of lessons to be learned for implementation in ongoing phases of hte current project

In the next post, I will cover the outputs for this process.

Filed under: Uncategorized | Leave a comment »

The last process was in the executing process group, as we implemented the risk responses that we had planned in a previous process.   Now we switch to the monitoring and controlling process group.    Here the process is not just monitoring risk responses, but monitoring risks in general, and if necessary, making changes (the controlling part of the process) to the risk register, and to any other documents that are necessary.

This post will cover the inputs to the process.

11.7.1  Monitor Risks:  Inputs

11.7.1.1  Project Management Plan

The risk management plan is the component that is mainly used as an input.   This will give guidance on

• how often risks should be reviewed
• which policies and procedures for the organization should be followed when doing the review
• the roles and responsibilities of the people doing the monitoring process
• formats for reporting the results of the process (with risk reports)

11.7.1.2  Project Documents

Here are the project documents considered as inputs for the process.

• Issue log–this will be used to see if there are any open issues that have been updated which may affect the risk register
• Lessons learned register–lessons related to risk that were recorded earlier in the project will be reviewed to see if they apply to later phases in the project.
• Risk register–the key inputs will include
  • identified individual project risks
  • risk owners
  • agreed-upon risk responses
  • specific risk response implementation actions
  • control actions for assessing the effectiveness of the risk respones plans
  • symptoms and warning signs of risk
  • residual and secondary risks
  • watch-list of low-priority risks
• Risk report–assessment of the current overall project risk exposure as well as the agreed-upon risk response strategy, as well as the major individual risks with planned responses and risk owners.

11.7.1.3  Work Performance Data

This contains data related to risk such as:

• risk responses that have been implemented
• risks that have occurred
• risks that are active
• risks that have been closed out (because the risks associated with certain project activities did not occur)

11.7.1.4  Work Performance Reports

Information from performance measurements can be analyzed to provide project work performance information such as:

• Variance analysis
• Earned value data
• Forecasting data

This information could be relevant when monitoring performance-related risks (such as missing an intermediate milestone, etc.).

The next process will be the tools and techniques associated with this process.

Filed under: Uncategorized | Leave a comment »

This post covers the output of the process 11.6 Implement Risk Responses, which is part of the executing process group for risk management.

In this process, the risk responses that were planned in process 11.5 Plan Risk Responses   are actually implemented if the underlying risk is triggered.   If that risk response requires resources and/or time to implement, you must make a change to the cost and schedule baselines to reflect the additional time and/or cost incurred (see paragraph 11.6.3.1 below).

Of course, there are some risk responses which require additional time and/or cost incurred even if the risk does not occur, mainly because you are trying to reduce the probability of a risk occurring and/or the impact of that risk if it were to occur.   An example is:   if the data you have from a client is valuable and should not be lost, then you may want to pay the expense of having a mirror server which will take that data at the end of each day and copy it onto a server which is not in the same location.   When I was working for an insurance company that was in Los Angeles, this was done to prevent data loss in case of an earthquake.   It would not make sense to send the data to a server that is merely in another building across the street, so we sent it to a remote site that would not be effected if the local area had an earthquake.   Although this was an expense that we incurred even if an earthquake did not occur, it was considered a good idea to implement this risk response beforehand in order to mitigate the damage if one were to occur.

If there are any issues encountered in the implementation of the risk, or if there are any changes made to the risk response in the course of implementing it, you also need to update the appropriate project documents (see paragraph 11.6.3.2 below).

11.6.3  Implement Risk Responses:   Tools and Techniques

11.6.3.1  Change Requests

If a risk response is implemented because the underlying risk has been triggered and it is a contingent risk response (meaning that it is only implemented if the risk occurs), then a change request may need to be done to update the cost and schedule baselines of the project management plan in order to account for the additional cost and/or expense.   The scope management plan, particular the Work Breakdown Structure, may also have to be amended to account for the additional activities required in the risk response.

11.6.3.2  Project Document Updates

• Issue log–if issues are uncovered in the implementation of risk responses, then these issues are recorded in the issue log.
• Lessons learned register–if challenges are encountered when implementing risk responses, then information is added to the lessons learned register on how to avoid those challenges or on approaches that worked well when confronting them.
• Project team assignments–the resources associated with the risk response are allocated, including the personnel required to implement them.
• Risk register–if there are any changes to the risk responses made in the course of implementing them, these changes are recorded in the risk register used by the project team.
• Risk report–if there are any changes to the risk responses made in the course of implementing them, these changes are recorded in the risk report that is send to stakeholders.

The next process group is monitoring and controlling, which in the case of risk management gives us the next and final process 11.7 Monitor Risks.   It not only is used for monitoring the implementation of agreed-upon risk responses plans, but for tracking identified risks (whether they occur or not), and periodically reviewing the risks on the project to see if there are any new risks that need to be added to the register.   Also, the effectiveness of the risk process is evaluated during the process.

The inputs to this process 11.7 Monitor Risks will be discussed in the next post.

Filed under: Uncategorized | Leave a comment »

The risk responses should have been all planned at this point in the previous process 11.5 Plan Risk Responses.    This process is one of carrying them out in the most efficient and effective manner, and  to validate them once they are done.

As opposed to the planning process which requires some special tools and techniques unique to the process, implementing the risk response just requires what I call “generic” tools and techniques, ones that are used in quite a lot of different processes.

11.6.2  Implement Risk Responses:  Tools and Techniques

11.6.2.1  Expert Judgment

You should consider expertise from individuals who have specialized knowledge in how to carry out the risk responses in an efficient (doing things right) and effective (doing the right things) manner.   Hopefully you will have already chosen that person as the risk owner.

11.6.2.2  Interpersonal and Team Skills

Since you cannot as a project manager be everywhere on a project, that is why you assign risk owners to the various risks.   You need to use your influencing skill to encourage risk owners to take the necessary actions needed, and you may need to facilitate the risk process.   This is really no different than the influencing skill you need for people to get the underlying work done on the project for the process 4.3 Direct and Manage Project Work

11.6.2.3  Project Management Information System (PMIS)

This is the computer software program, like Microsoft Project, used to monitor the schedule, cost and resources on a project.   In the case of this process, it is to ensure that the risk response plans and their associated activities that have been agreed upon are integrated into the project alongside the other activities.

The next post covers the outputs of the process.

Filed under: Uncategorized | Leave a comment »