5. Project Planning

5.5 Cost Management

One of the components of project success is completing the project within budget. Developing and managing a project budget that will accomplish the project objectives is a critical project management skill. Although stakeholders expect the project to be executed efficiently, pressures to remain within budget vary based on the unique constraints and priorities of the project. On some projects, the project completion date is the highest priority leading to a more flexible budget to accommodate the inflexible deadline. Moreover, the project’s scope may have to be scaled back if it is too ambitious to finish within a specific budget.  Understanding the priority of the constraints is critical and allows for effective cost management and the fulfillment of stakeholder expectations.

During the project selection phase, the information needed to develop an accurate and detailed budget is often unknown. This leads to a top-down estimating approach where high-level estimates are created. These estimates are often called a rough order of magnitude (ROM).  The estimate is developed using the information available at the time. These estimates can be +/- 50% in terms of the accuracy level. There are three commonly used techniques for top-down estimating:

1. Apportion method – reviewing actual costs categories from similar projects and applying the same proportions to the current project’s cost categories.
2. Expert judgement – consulting with experts who have done similar work before and seeking their guidance on a high-level estimate for the project’s overall cost.
3. Ratio method – identifies a significant determining factor and applies this factor to estimate the project’s overall cost. For instance, a website development project could estimate the project cost based on the number of web pages to be developed and an approximate cost to develop each page. For instance, assume it costs $1,000 to create one web page. A 20-page website project could cost roughly $20,000.

Given the popularity of the apportion method, let’s examine how this is done in greater detail.

Top-down estimating is simple and inexpensive. The ROM is often accurate enough to help organizations determine if the project’s benefits will outweigh the costs, hence it is often used at the project selection stage.  Moreover, for small internal projects where the project budget is insignificant and the cost to obtain an accurate estimate is not justified, the ROM will become the final project cost estimate.

The clarity of the end solution to be delivered will also impact the project budgeting approach. For instance, when the end solution cannot be clearly defined upfront, this often leads to the use of an adaptive development methodology, such as agile, which accepts a ROM and regular budget refinement as the iterations are defined. When the solution can be clearly defined upfront, the predictive (waterfall) development methodology is used. A more detailed and accurate budget is developed, through bottom-up estimating, to replace the ROM during the detailed planning phase.  Bottom-up estimating begins by identifying the project’s deliverables – the tangible outcomes that must be produced for the project (or iteration) to be completed.  Deliverables are identified as part of our efforts in project scope definition. We break down deliverables into specific activities so we can identify the activity-related costs (described below).   It should be noted that it takes a considerable amount of time to perform bottom-up estimating because we try to involve all the individuals who will do the work to increase accuracy and organizational buy-in.  Given this, it’s important to discuss the level of accuracy expected with the Project Sponsor(s) before the estimating begins as this can guide the effort required.

Once the project budget has been developed (either a ROM or through the bottom-up approach), it must be approved by the project sponsor(s).  Once approved, it becomes the cost baseline and actual results are tracked so budget achievement can be monitored. This tracking is done as part of the monitoring and control work of the project (covered in Chapter 7). If the actual costs are significantly higher or lower, the project team identifies the root causes and takes appropriate action to successfully manage future expenditures.

Types of Project Costs

There are generally seven different types of project costs:

1. Activity-related costs
2. Direct overhead costs
3. Procurement related costs
4. Quality costs
5. Contingency
6. Management reserves
7. General administrative costs

Activity-related costs can be resource-based and materials-based.  Activity-related costing is part of the bottom-up estimating approach and directly link the schedule to the budget. The durations of activities are estimated to produce a project schedule. These same activities are estimated from a cost perspective to produce the project budget.

The human effort required to complete an activity is called the resource-based cost (commonly called “labour costs”).  We determine how much the resource will be paid to complete the activity and how much effort is required. The nature of the project determines the appropriate unit of time for estimating – hours or days is the most common. The resource-based cost is determined by multiplying the length of time required to complete the activity by the resource’s cost. For instance, an activity may take 4 hours for a resource to complete, and that resource may be paid $30 per hour. The resource cost for the activity would be $120 (4 hours x $30 per hour).  It’s important to identify the specific type of resource needed as their hourly rate will vary considerably.  When possible, it’s also important to consider the experience level of the assigned resource, as the amount of effort required can also vary considerably.  Projects often require materials, equipment and supplies to produce the project’s deliverables and this is referred to as the materials-based costs. Materials and supplies are often estimated on a per unit or per use basis.

Direct overhead costs are incurred as a result of the project’s existence, but they are not directly related to specific activities. The rental and maintenance of a workspace for the project team members, as well as their computers and related information technology, supplies, and food are all examples of direct overhead costs.

Procurement costs relate to the expenses associated with outsourcing work or obtaining project materials from sources outside the organization. The costs associated with procurement are above and beyond the cost of the materials, supplies and equipment. Procurement costs typically include fees and other service charges incurred to obtain the needed resources.  Examples include the cost of legal contract development/review, shipping, and storage.

Vendors and suppliers usually require payments during the life of a contract. On contracts that last several months, the contractor will incur significant cost and want the project to pay for these costs as early as possible. A schedule of payments is typically developed and connected to the completion of a defined amount of work or project milestones. These payments made before the end of the project are typically based on work progress and are called “progress payments”. These payments are important considerations in the development of a time-phased budget.

Contract planning includes processes for planning individual work contracts. Many organizations have standards relating to how contracts will be managed, the metrics that need to be met for the contracts to be considered successful, vendor selection criteria, and contract administration. Once the project team determines needed services, the project manager or procurement manager sends out the requirements to sellers. A formal bid process often ensues. The best vendor is selected, and contracts are signed. Once the work begins, the project manager monitors the vendor to ensure they are following the contract specifications and authorizes progress payments as appropriate. When the work is done, the project manager closes out the contract and completes any remaining administrative activities.

A common technique used during the procurement planning stage is “make-or-buy” analysis. When it comes to the completion of activities, the make-or-buy analysis helps you determine if you should complete the work internally or hire an external party. It could also mean deciding whether to build a solution to your problem or buy one that is already available. Lastly, when it comes to materials, supplies and equipment, it can mean deciding to produce what’s needed or contract with an external party.  The “buy” option may involving renting, leasing or purchasing and this is an analysis in its own right.   Regardless of the nature of the decision, some common considerations include the cost of building versus buying and the implications for project scope and project timeline.

Once the decision to engage an external party has been made, the project manager needs to decide what type of contract to pursue. Several types of contracts exist, and the goal is to choose one that creates the most fair and workable deal for you and the external party. See “5.7 Procurement” for a review of the options available.

Project stakeholders have an expectation for the quality of the deliverables produced. Understanding the specific expectations held is an important step in producing a realistic and achievable project budget because it is much more cost effective to build quality into the deliverables at the outset then try to address quality problems after the fact. Achieving the quality expectations often comes with a cost and may involve many prevention and appraisal activities on the project.  Quality costs are not just about testing. Instead, it includes any time spent writing standards, reviewing documents, meeting to analyze the root causes of defects, and reworking to fix the defects once they are discovered by the team; in other words, the cost of quality includes absolutely everything you do to ensure quality on the project.

Quality costs are typically divided into two categories: cost of conformance (or good quality) and cost of nonconformance (bad quality). The cost of conformance includes the cost of preventing quality defects as well as the cost of appraising or detecting defects in the project deliverables or processes. Prevention costs are associated with planned activities such as setting quality standards, developing a project quality plan, conducting deliverable reviews, evaluating process capability, and educating and training team members on quality standards and processes.² Appraisal costs come in the form of measuring and monitoring activities to evaluate “purchased materials, processes, products, and services to ensure that they conform to specifications.”³ Audits, inspections, and testing also fall under the appraisal cost category.⁴

The cost of nonconformance is a result of quality failures—both during and after the project. Internal failure costs, which are incurred when defects are discovered before deliverables are received by the customer, could include costs of scrap, rework, and failure analysis.⁵ External failure costs occur when deliverables that fall short of established quality standards are not detected until after transfer to the customer; such costs could accrue from repair work, complaint resolution, and warranty claims.⁵ Another way to look at nonconformance costs is to think of internal failure costs as “waste” and external failure costs as “downstream consequences,” of which there can be many.⁶

Unfortunately, despite our best efforts, project costs often vary from planned.  In some cases, we expect variations because we knew material prices were highly volatile in the marketplace, estimating the exact quantity needed was very difficult and/or little was known about the specific requirements/specifications of the solution.  In these cases, it is wise to add a contingency to the project budget. Contingency is money set aside to manage the identified risks and as such, these funds are part of the approved project budget.  Identifying the amount of contingency needed is often done as part of the risk management process. For instance, projects that carry a high level of risk would have a high level of contingency – perhaps 30%, 40% or even 50% of the total project costs.  Some projects apply contingency to the labour and non-labour components of the project budget while other projects add contingency to only one of these components – this is determined by the risk analysis performed.  The specific amount of contingency to include is often defined by an organization’s new initiative risk management policy and project leaders should ensure they are aware of and familiar with such policies.  If the contingency is adequate to meet the project’s identified risks, then the project will be completed within budget.

Some projects also include a management reserve.  Management reserves are funds set aside to manage situations that are not anticipated. These situations can be positive and negative. An example of a positive situation is the discovery of new technology that will revolutionize the way the project objectives are achieved. The necessary funds can be made available to take advantage of this opportunity at the project sponsor’s discretion. If such an opportunity were pursued, it would result in a significant change in the project’s scope, especially if the predictive/waterfall development methodology was used. Unlike contingency, management reserves are unlikely to be spent and are not part of the project’s cost baseline. However, they may be included in the funding made available to the project.

Lastly, general administrative costs are indirectly related to a project, and they are incurred even if the project is not carried out. Examples of this type of cost include the costs of departments like marketing, human resources, and accounting. These departments may provide ad-hoc and minimal support to the project teams and as a result, the project sponsors may want a portion of their costs to be allocated to all projects underway in the organization. Allocating a portion of the departments’ costs to the project provides the executive with a full picture of all costs incurred due to the implementation of strategic change initiatives in the organization. This is often referred to as the “fully loaded cost”. However, since the allocation methods are often very subjective, and the project leader has no real control over these costs, common practice is to exclude these costs from the project budget.  The exception is in projectized organizations as the projects undertaken are the mainstay of the organization and this is where full organizational cost recovery occurs.

It is important to note that many projects require significant involvement of some departments.   This should be clearly identified in the project’s scope.  For instance, a project that involves the introduction of new technology will alter the way people work and this will require members of the human resources department to re-evaluate existing job descriptions, performance management plans and compensation levels. In this instance, the human resource function is producing project deliverables, and their work will be considered an activity-related cost.

Developing the Aggregate Budget

Once you have identified all the applicable types of costs for your project, and produced cost estimates, the aggregate budget can be created. The aggregate budget is developed by simply adding up (aggregating) all individual cost estimates. The subtotals are organized by cost category and by activity.  Linking the project budget to the project scope is done by aggregating costs at the deliverable level and this allows the project leader to ensure that the scope can be delivered as the required costs have been considered.

Developing the Time-Phased Budget

The aggregated budget is integrated with the project schedule to produce the time-phased budget. Costs are associated with activities and since each activity has a duration, it is possible to determine how much money will be spent at any given point in the project’s timeline. Recognizing that all the money required to deliver the project is not needed upfront, the time-phased budget allows the cash flow needs of the project to be effectively managed. For smaller organizations facing cash flow challenges, this can result in significant savings as the money required to pay for resources can be transferred to the project account shortly before it is needed. These transfers must be timed so that the money is there to pay for each activity without causing a delay in the start of the work. If the money is transferred too far in advance, the organization will lose the opportunity to use the money somewhere else, or they will have to pay unnecessary interest charges if the money is borrowed.

Project Budgeting – An Example of Bottom-up Estimating.

Let’s imagine the organization you work for has decided it is time to revamp the website.  This is a project – it is a unique endeavor with specific goals and a defined start and end point.  The end point of the project – the revamped website “goes live” with employees and clients/customers – signals a transition to day-to-day operations.

Let’s assume there are two primary objectives for revamping the website: 1) customers are complaining about old/irrelevant content and 2) customers are complaining about the graphics and photos that depict white people only.   Both issues must be addressed in the website revamp project. The WBS for this project could be as follows:

Exhibit 5.12: The WBS for the Website Revamp Project.

Since the objective of a project budget is to estimate the cost of producing the project’s deliverables, the structure of the budget should be aligned with the WBS.  Microsoft Excel is commonly used in situations requiring numerical analysis. Excel was used to illustrate how to develop the structure of the budget in the figure below. Notice it is aligned with the project’s WBS.

Exhibit 5.13: Aggregate budget (total budget) for Website Revamp Project

As noted in the project’s WBS, there are 5 major deliverables. For simplification, one of the underlying sub deliverables from the WBS has been selected for inclusion in the project budget. In practice, it is important that all the sub deliverables are included in the project budget.

The next step is to estimate the cost of the deliverables. In this example, we have activity-related costs (labour and materials), direct overhead expenses, procurement costs and quality costs. Let’s examine the nature of these costs.

Labour costs are determined by estimating the effort associated with the deliverables (in days for this example) and the cost of the resource performing the work (the daily rate in this example). Multiplying these two together will provide the total labour cost for the deliverable.  For instance, for deliverable 2.3 (New Content Design), it is estimated to take 25 days and the work will be performed by a Senior Business Analyst who will earn $30 per hour (with an 8-hour day, this is $240 per day). 25 days x $240 per day generates a labour cost of $6,000 for this activity.

A project of this nature will also incur non-labour costs.  They could include the following:

Materials – several stock images will be purchased as part of the work on new content design. The copyright on these images is estimated to be $100 for lifetime use.  An estimated 20 images will require copyright licensing. The material cost is therefore $100 x 20 = $2,000.

Direct overhead – the project team would like to have dedicated space to improve their collaboration.  The organization does not have additional office space available for the team so a meeting room at a nearby office building has been rented. It is estimated to cost $4,500 per month and it is required for the duration of the project (6 months). Therefore, the expense is estimated to be $4,500 x 6 = $27,000.  See deliverable 6.2.

Procurement costs – the organization decided to hire an external photographer as this skill is not available internally. The photographer has provided estimates for the cost of their work. For instance, the photoshoots are estimated to cost $2,000. See deliverable 3.1.

Quality costs – the new website is expected to have a lot of new content.  All this content has to be easily searchable and therefore, a significant amount of data tagging is required. A Graphic Designer will perform this work. As an extra quality measure, an external web designer will be hired to perform an independent search of the new content to ensure it has been properly tagged. The estimated cost for this work is a flat rate of $2,500. See deliverable 4.3.

In terms of contingency, let’s assume the organization believes this project represents a low level of risk.  In accordance with the organization’s new initiative risk identification policy, a 10% contingency on all costs is applied in these situations.  10% of $65,180 is $6,518 in contingency. The project leader will want access to these funds throughout the project and as such, will be included in the project budget to be approved.

Given the low level of risk associated with this project, management reserves have not been estimated as there unlikely to be needed.

The total cost of the project has been estimated to be $71,698. When we review and revise our budget, we want to ensure we remember how the numbers were determined. Documenting our assumptions helps us keep track of our information sources, stakeholder conversations and underlying cost estimates. The table below provides an example of the key assumptions for our Website Revamp Project. These assumptions may be listed under the Aggregate Budget calculations or consolidated into a separate tab of the Excel workbook.

Exhibit 5.14: Assumptions for the Website Revamp Project.

The next step is to review the project schedule to determine the sequencing of the work so the time phased budget can also be determined.

Let’s assume that our work on the project schedule led us to conclude the project will be completed in 6 months.  This becomes the time horizon for our project budget. Looking deeper into the project schedule, we determine that the Records Retention Policy will be created in the 1st month, the Old Content Archive work will take place over 2 months, etc. See 2.1 and 2.2 below.

Exhibit 5.15: Sequencing the work for the Website Redesign Project’s budget.

Our next step is to determine the monthly costs. A portion of the time-phased budget has been depicted below for illustrative purposes. When we sequenced the work, we decided the Records Retention Policy work would be done in the 1st month. By multiplying the effort (in days) by the daily rate of $240, we determine that a cost of $720 will be incurred when this work is complete. In addition to the labour costs, we must also determine when the non-labour expenses will be incurred. The cells that are highlighted in yellow illustrate the inclusion of non-labour costs. For instance, in the New Content Design deliverable (2.3 in the chart below), the $2,000 material expense associated with copyright licenses has been estimated to occur in the 4th month.

Exhibit 5.16: Time-phased budget for the Website Revamp Project.

By summing up the monthly costs in the time-phased budget, we can determine how much money is needed in each month – this helps the organization to effectively manage their cash flow.

For instance, in Month 1, the project team will need access to $43,742 to cover anticipated expenses. And by Month 3, $123, 387 will have been spent. The time-phased budget is the cost baseline because it becomes possible to track when the work is getting done and how much money is actually being spent. We will explore these concepts further in Monitoring & Control.

Managing the Budget

A key aspect of ongoing cost management is monitoring cost estimates. Baseline budgets often change after they have been approved. Successful project leaders understand that estimates are just that, estimates. As new information and real experience occurs, it may be necessary to revise an estimate. In some cases, the revision is minor and does not impact the achievement of the project’s total budget. In other instances, the necessary revisions are significant, and a new baseline needs to be created. Analytical skills are helpful in this regard as the project leader is routinely assessing the overall impact of modified project costs on the project’s objectives.

It is important for project leaders to discuss the ongoing management of the budget with key stakeholders to understand their expectations of when/how approvals must be obtained. Approval thresholds are typically established. For instance, the project leader may proceed with changes at their own discretion if the changes are not greater than 2% of the overall budget, while project sponsor approval would be required if the changes are beyond this threshold. Complex projects may document stakeholders’ expectations for ongoing cost management in a formal Cost Management Plan.  The project leader will use this plan to guide their efforts around when and how to communicate changes to project costs.

Project costs may deviate from the approved estimate for various reasons. For instance, the actual price for materials in the marketplace may differ from what was expected. Project costs may also deviate based on project performance. In particular, more materials may be required to complete the work than what was expected. Additionally, the effort required may be different than initially estimated. When trends emerge indicating there is a variance between actual and planned project costs, future estimates should be revised, and corrective action may be required.

5.6 Risk and Issue Management

Risks are the uncertainties that exist in all projects. A risk is an uncertain event that can positively or negatively affect project processes or outcomes. Opportunities are positive risks and threats are negative risks.

The role of the project management team is to understand what could happen on a project and intentionally decide what to do about these uncertainties. This is critical because we need to acknowledge that things always don’t go as planned but this does not mean we should take a “wait and see” approach. Good project managers attempt to minimize the likelihood that project objectives are not accomplished, and this requires a commitment to good risk management practices.

Risk Management Plan

By the time a risk turns into an issue on a project, it is often too late to effectively respond to it. The risk management plan allows the project team to reduce the likelihood of negative surprises, proactively take advantage of positive risks (opportunities), and ensure risk management is considered when schedules, budgets, and other management plans are developed. Creating and maintaining a risk management plan significantly increases the likelihood of project success.

The risk management plan identifies the processes and procedures to be used in managing risk throughout the life of the project. It includes several key sections: risk sources, categories, probability/impact assessment (matrix), roles and responsibilities, budget and schedule estimates for risk-related activities, and the risk register.

There are four steps in risk management:

1. Risk identification. The type and severity of risk vary by industry, project complexity, and project phase. Some uncertainties are easy to identify, such as the potential for a damaging storm to disrupt a team’s ability to work, while others are less obvious, such as the potential that a vendor doesn’t deliver what’s expected. Many industries or companies have risk checklists developed from past experience. The value of a checklist is it serves a starting place for risk identification discussions that are typical for certain projects.
2. Risk assessment. Each risk needs to be assessed by estimating its likelihood (probability of occurrence) and impact on project goals. The outcome from this process is a prioritized list of project risks with values (e.g. high, medium, low) that represent the likelihood and potential impact. The probability/impact matrix is a key tool in risk assessment as it facilitates risk prioritization.
3. Risk responses. The human tolerance for risk varies significantly from one person or organization to another. Understanding the needs and expectations of key project stakeholders is a critical success factor for effective risk management practices. This leads to the development of appropriate responses.  In addition, the project team must balance the cost of the risk response strategy against the anticipated benefits for the project. The specific response options will be discussed below.
4. Implementing and monitoring the response. Monitoring is about understanding the effectiveness of implemented risk response strategies once they’ve been put in place. In some situations, implementation of a risk response strategy can lead to the creation of new risks. Risk identification must be an ongoing process throughout the project’s lifecycle. Moreover, a response strategy may not be as effective as initially anticipated so another response strategy may have to be identified.

During the closing phase of a project, agreements for risk-sharing and risk transfer must be concluded and the risk management plan must be examined to ensure all the risk events have been effectively managed. Updating the risk management documents to reflect what occurred is an important step as it will allow other project teams to access this information and use it in their planning.

Let us examine each aspect of effective risk planning in more detail.

Risk Identification

A good place to start identifying risks is the assumptions that have been made in the project justification document (business case) and project charter. Project teams hope the assumptions will be true, but this is not certain. As a result, assumptions can represent risks.

Another important method for identifying project risks is ongoing discussions with the project team. The individuals responsible for specific components of the work are in the best position to identify the risks and opportunities associated with their task(s). More things are unknown at the beginning of a project than at any other phase.  Systematically reviewing the deliverables in the work breakdown structure ensures that the risks associated with the completion of project work has been carefully considered. A good practice is to include risk management discussions as a standing agenda item during project status meetings.

In John’s move, he makes a list of things that might go wrong with his project by using his work breakdown structure (WBS) as a guide. A partial list is shown below.

The result is a clearer understanding of where risks are most concentrated. This approach helps the project team identify known risks but there is a danger in relying exclusively upon the WBS it as it may prevent the team from thinking beyond their work to identify unknown risks that are not easily found inside the WBS.

The third source of risk is risk checklists developed from past projects. These checklists can be a helpful starting point for the project team and often lead to more productive brainstorming meetings. Some industries publish their own risk management checklists that, when feasible, should be utilized. Checklists are often organized by risk category. The categories themselves can add helpful insights during brainstorming sessions. Examples of common risk categories include:

• Technical (related to technology and equipment)
• Cost (specific labour and non-labour estimates)
• Schedule (activity durations and methods of completing work)
• Client/Customer (their willingness to use a new product/service)
• Procurement (vendor performance)
• Weather (adverse weather can impede progress)
• Financial (related to funding sources)
• Environmental (new/changing government regulations)
• Resources (skills, availability, and effectiveness of teamwork on the project)
• Stakeholders (fulfilling expectations of specific stakeholders)
• Communications (related to its effectiveness)

Notice that the categories are broad. Successful project delivery is a multi-disciplinary approach.

Risk Assessment

After the potential risks have been identified, the project team evaluates each risk based on the probability that the risk event will occur, and the potential impact (cost or benefit) associated with it. Not all risks are equal. Some risk events are more likely to happen than others and the cost or benefit can vary greatly. Risk assessment often occurs in a workshop setting where participants with helpful expertise are present.

Many project teams use risk values for prioritization.  As noted in the risk register tool below, risk value is determined by multiplying a risk’s probability score by it’s impact score. This will ensure risk response strategies are developed for high probability – high impact risks first.

For example, suppose high-impact risks are those that could increase the project costs by 5% or more. Similarly, high-probability risk events could be those that carry a likelihood of occurrence of 50% or more. The risk and impact matrix is a good way to visualize the priority of a project’s various risks. See Exhibit 5.17.

Exhibit 5.17: Risk and impact matrix
^{Project Management from Simple to Complex}

There is a positive correlation between project complexity and project risk. This means that both variables increase or decrease together. A project with new and emerging technology will have a high complexity rating and a correspondingly high project risk.  The more complex the technology, the more resources the technology manager typically needs to meet project goals. This is a key consideration for the project’s budget and schedule.

Risk Responses

…To Negative Risks

After the risks have been identified and assessed, the project team develops appropriate risk responses. As previously mentioned, the project team responds to negative risks in various ways:

• Avoidance
• Mitigation
• Transfer
• Acceptance
• Escalate

Avoidance usually involves changing the project approach in some way to avoid the risk. However, the cost of completing the work using this new approach can be much higher.  It’s important to weigh the incremental cost of the approach with the value of having a higher probability of success.

A common risk avoidance technique is using proven and existing technologies rather than adopting new technologies, even though the new technologies may show promise of better performance and/or lower costs. Since better performance and lower costs are not certain, the project team may not feel it is advantageous enough to take the risk.  Similarly, a project team may choose a vendor with a proven track record over a new vendor that is discounting its products/services.  The risk of poor performance is much higher with a new vendor than it is with a proven, existing vendor.  So much so that the price discount may not be attractive enough to take on the higher risk.

Mitigation is attempting to reduce the likelihood and/or impact of a risk a response.  Mitigation is a good strategy for risks that cannot be avoided, or when avoidance is too expensive and/or too time-consuming. For instance, mitigating the risk that costly errors occur is often done by assigning highly skilled resources to complete the work.

Transfer is a risk reduction method that shifts the risk from the project to another party. The purchase of insurance is a risk-transfer method. The risk is transferred from the project to the insurance company. For example, a construction project in the Caribbean may purchase hurricane insurance that would cover the cost of a hurricane damaging the construction site. The purchase of insurance is usually connected to risks that can significantly impact the project while being out of the project team’s control, such as weather, political unrest, and labour strikes.

Acceptance involves doing nothing in response to the risk. The acceptance response is a good one when the likelihood and impact of a risk are low. Acceptance is also a good response strategy when the project team can’t do much about a risk. This may be the case because the project team doesn’t have the needed resources or skills. In this case, many project leaders will think about what can be done after the fact, should the materialize.

Escalate involves recognizing that the risk is outside of the project manager/project team’s authority to manage. For instance, the project may be dependent on funding that is being pursued by a member of the executive team. In this instance, the project manager would inform the project sponsor of the impact of the risk and ask for their assistance in ensuring that it is effectively managed by the appropriate people within the organization.

…To Positive Risks

As previously mentioned, positive risks (opportunities) are uncertainties that, if materialized, will have a positive impact on the project. Project teams have other alternatives to deal with opportunities:

Risk-sharing involves partnering with others to share responsibility for the risk. Partnering with another company to share the risk associated with a portion of the project is advantageous when the other company has the expertise and experience that the project team lacks. This increases the likelihood of the opportunity materializing and, if it does, both organizations share the gains.

Exploitation attempts to eliminate the uncertainty and ensure the occurrence of the opportunity. An example of this could be pursuing a bonus that is available only if an activity is completed early. In this case, the project team will reallocate resources to ensure the activity finishes early and the bonus is obtained.

Enhancement attempts to increase the probability of the opportunity materializing but it does not seek to ensure its occurrence. This requires less investment than the exploitation response and is appropriate when the positive impact is not as great.

Acceptance involves doing nothing in response to the risk. This response is a good one when the likelihood and impact of a risk is low and when the team can do little about the opportunity.

Escalation involves recognizing that the opportunity is outside of the project manager/project team’s authority to manage. For instance, the project may be eligible for an award if its completion leads the organization to partner with a community-based research organization.  In this instance, the project manager would inform the project sponsor of the opportunity and give them the opportunity to pursue the partnership, if appropriate.

Risk Registers

A risk register is a tool that helps project teams keep track of the risks identified and their status. The register helps the project team ensure that response plans are being effectively implemented and monitored. The register is often created during the initiation phase of a project’s life, and it is maintained throughout the remaining phases. In many instances, the active use of a risk register gives the Project Sponsor(s) confidence in the team’s ability to successfully complete the project because it demonstrates a proactive approach to change management.

Exhibit 5.18: Risk register with common headings.

Risk registers typically contain the following information:

ID: A unique identifier for the risk.

Risk Name: Two or three words that describe the essence of the risk.

Risk Description: A more detailed description of the risk.

Likelihood: The probability that the risk will occur. A value of 1 is the lowest likelihood of the risk occurring and a value of 5 is the highest likelihood of the risk occurring. Organizations typically establish parameters for these values. To illustrate what this could look like, imagine the following fictional parameters:

• 1 indicates the probability is 20% or lower.
• 2 indicates the probability is 21% to 39%.
• 3 indicates the probability is 40% to 59%
• 4 indicates the probability is 60% to 79%
• 5 indicates the probability is 80 to 95%.

Project leaders should check the new initiative risk management policy, if available, for guidance on these numbers.

Impact: The severity of the result or end outcome for the project, should the risk occur. A value of 1 is the lowest impact and a value of 5 is the highest impact. Organizations typically establish parameters for these values. To illustrate what this could look like, imagine the following fictional parameters:

• 1 indicates the project would be impacted in a very insignificant way. Any incremental costs incurred as a result of the risk could be absorbed within contingency. Schedule and scope are still achievable.
• 2 indicates the project would be impacted in a somewhat insignificant way. Any incremental costs incurred as a result the risk would fall outside of the established contingency but would be less than 1% of the overall budget. Scope is still achievable, and any schedule delays would be 1 week or less.
• 3 indicates the project would be impacted in moderate way. Any incremental costs incurred as a result of the risk would fall outside of the established contingency and be up to 10% of the overall budget. Scope is unlikely to be achieved and the schedule delays would be beyond 1 week.
• 4 indicates the project would be impacted in a significant way. Most/all project objectives are unlikely to be achieved. Any incremental costs incurred as a result of the risk would fall outside of the established contingency and be up to 20% of the overall budget. Scope is unlikely to be achieved and the schedule delays would be beyond 2 weeks.
• 5 indicates the project would be impacted in a very significant way. Most/all project objectives would not be achieved. Major delays, cost overruns and scope/quality issues would occur.

Project leaders should check the new initiative risk management policy, if available, for guidance on these numbers.

Risk Value: This value is calculated by multiplying the likelihood value with the impact value. For instance, a likelihood value of 3 and an impact value of 2 would lead to a Risk Value of 6 (3×2).

Priority: Thresholds for the risk values are established as a way of prioritizing risks.  To illustrate, an organization could set the following thresholds for risk values:

• 6 and under could be “Low” priority.
• 9 to 15 could be “Moderate” priority.
• 16 to 25 could be “High” priority.

Regardless of the thresholds chosen, all high priority risks should have a risk response strategy. Most, if not all, medium priority risks should also have a risk response strategy. A reasonable risk response strategy for low priority risks could be “acceptance”. Additional response strategies for low priority risks could be considered optional.

Potential Root Causes: Identifying the underlying reasons for a risk is important because response strategies should be put in place to address the root causes. For instance, the risk that a new application is not user friendly could have many root causes – end users were not involved in the design and/or testing did not include members of the end user community. Effective response strategies would address the need for end user engagement.

Triggers: Triggers are early warning signs that a risk may materialize.  For instance, a trigger for a new application that is not user-friendly could be low participation of end users in application design workshops. The project team could set a participation target that when achieved, is likely to lead to a user-friendly application.  The target could be 70% of end users are participating. If only 10% of users show up for the application design workshop in the first week, this can be viewed as a risk trigger. The likelihood of having a user-friendly application has just dropped significantly and risk response strategies should be implemented. Additional workshops could be set up, multiple communication methods for reaching end users could be relied upon and a financial incentive for participating employees could be provided.

Risk Response Strategy: this is the action to be taken in response to a negative or positive risk (opportunity).  It’s important to specify when the action will be taken (before or after the triggers occur) and who is responsible for taking the action. Many risk registers also include a column for “owner” to separately identify the individuals who are accountable for the actions.

Additional columns commonly seen in a risk register include:

• • Due date
  • Steering committee discussion date
  • Status (open or closed)
  • Notes

To illustrate how the risk register comes together, here are 3 risks associated with the project for John’s move to Chicago.

Exhibit 5.19: Risk Register for John’s Move.

Johns Move Risk Register

Implementing and Monitoring the Responses

Project environments are often highly volatile. Forces internal and external to the project can impact the project team’s ability to deliver on project objectives.  As new risks are identified, it’s important to assess them and develop appropriate response strategies. Moreover, the implementation of response strategies for previously identified risks may not have been as effective as initially identified. When this occurs, new response strategies must be developed.

Implementing risk response strategies may require the management of contingency funds.  Contingency funds are set aside by the project team to address project uncertainties.  Risk is not allocated evenly over the life of the project. On projects with a high degree of new technology, most of the risks may be in the early phases of the project. On projects with a large equipment budget, most of the risks may be during the procurement of the equipment. And on global projects with a large amount of political risk, most of the risks may be toward the implementation and closure of the project.

Contingency plans are often reviewed during the life of the project. This review evaluates the effectiveness of the risk responses and whether there is a need for additional contingency.

5.7 Procurement management

The procurement effort on projects varies widely and depends on the type of project. The “procurement cycle” reflects all procurement-related activities from when the decision is made to outsource equipment all the way through to the payment of bills and closing of procurement contracts.

A note about terminology: this text will be using the terms suppliers and vendors interchangeably.

In less complex projects, the project team performs the work associated with procurement management. This includes:

• Identifying the required materials, equipment, and supplies
• Identifying the potential vendors
• Preparing requests for quotes (RFQs) and requests for proposals (RFPs), which include product/service specifications and a detailed delivery schedule
• Evaluating RFQs and RFPs to select the most suitable vendors
• Awarding and signing contracts
• Administering the contract and monitoring vendors’ performance
• Managing contract changes
• Closing out the contract upon work completion

On more complex projects, procurement professionals may be assigned to assist the team throughout the project’s lifetime.

Procurement management follows a logical order. First, determine what the project needs to contract; then plan to do it. Next, send out contract requirements (solution specifications and timeline requirements) to potential vendors. These vendors bid for the chance to work on the project. The project team selects the best vendor and then signs a contract to formalize acceptance of the terms. Once the work begins, the supplier’s performance is monitored to make sure that the contract is being followed. When the work is done, the contract is closed out.

It is important to start with the plan for the whole project. Before doing anything else, consider all of the work that needs to be contracted out for the project. Ensure the project’s needs are closely examined to confirm if contracting is even necessary.

A procurement management plan is used in projects with high complexity as it details how the procurement process will be managed. It includes the following information:

• Roles and responsibilities of the project team and procurement professionals
• Vendor selection criteria and the selection process
• The identification of prequalified sellers (if known)
• The types of contracts to use and any metrics that will be used to measure the vendors’ performance
• The requirements and specifications of the necessary products, services, and equipment
• The planned delivery dates for the work or products being contracted
• The company’s standard documents to be used on the project
• The number of vendors involved and how they will be managed
• How purchasing may impact the constraints and assumptions of the project management plan
• The coordination of purchasing lead times with the development of the project schedule
• Closing contracts

Depending on the complexity level of the project, procurement management plans can take hours or weeks to complete. The activities involved in procurement management are included in the project’s schedule and budget. The time involved in the procurement cycle can influence the scheduling of critical activities, including the decision to self-perform the work or contract the work to others. The delivery dates for equipment and materials and the work completion dates for contracted works are placed on the project schedule. Any procurement activities that create a project delay or fall on the project critical path may require special attention.

The procurement management plan, like all other management plans, becomes a subsidiary of the project management plan.

Let us explore some key activities, tools, and techniques used in the procurement management process.

Lease-or-Buy Analysis

Lease-or-buy analysis is a technique used to determine if needed equipment should be purchased or leased on a project. This can apply to all kinds of equipment, including information technology.

Some of the key questions answered include:

1. How long does the organization need to use the equipment for the project?
2. What will the organization do with the equipment after the project is complete?
3. How will this decision affect the scope of the project?
4. How will it affect the project schedule?
5. How will it affect the stakeholders’ expectations of quality?

A simple example will help illustrate how this analysis is performed. Let us assume a project team needs a 3-D printer. The printer would cost about $15,000 to purchase and require about $200 per month to maintain. Alternatively, the project could lease the printer for $600 a month. The monthly lease rate includes all associated expenses like maintenance.

The first step is to determine when the cost to buy becomes equal to the cost to lease. This can be expressed mathematically as follows:

Cost to lease = Cost to purchase

Assume M is the number of months.

$600 x M = $15,000 + ($200 x M)

($600 – $200) x M = $15,000

$400 x M = $15,000

M = $15,000 ÷ $400 = 37.5

If the project is considerably longer than 37.5 months, it makes sense to buy the equipment. The organization could choose to reassign the printer to future projects or sell it using a very low-cost online alternative. Conversely, if the project is considerably less than 37.5 months, it makes more sense to lease the equipment. If the project’s duration is very close to 37.5 months, this becomes a judgement call and the project leader may wish to consult with others in the organization to determine if there is a need for this type of equipment in other areas.

After the analysis is complete, the project team will be able to determine the nature of the contractual relationship needed with a vendor. It is then time to identify potential vendors. Once the potential vendors have been identified, the project team will move on to bid solicitation. Once the bids come in, they are evaluated. Once the successful vendor has been selected, a contract is awarded. Let us look at each of these steps more closely.

Qualifying Bidders

Potential bidders are people or organizations capable of providing the materials or performing the outsourced work required for the project. On smaller, less complex projects, the parent company typically has a list of suppliers and vendors that have successfully provided goods and services in the past, and the project has access to the performance records of companies on that list. On unique projects, where no supplier list exists, the project team develops a list of potential suppliers and then qualifies them to become eligible to bid on project work. Eligible bidders are placed on the bidder’s list and provided with a schedule of when work on the project will be put out for bid.

The eligibility of a vendor is determined by the ability to perform the work in a way that meets project requirements and demonstrates financial stability. Ability to perform the work includes the ability to meet quality specifications and the project schedule. During times when economic activity is high in a region, many suppliers become busy and stretch their resources. Before they are included on the bidder’s list, the project team investigates the potential suppliers to ensure that they have the capacity and track record to meet deadlines and quality expectations.

The potential supplier must also be financially stable to be included on the bidder’s list. A credit check or a financial report from a reputable credit rating agency (e.g. Dun and Bradstreet, Equifax) will provide the project team with information about the potential bidder’s financial status.

Solicitation

A solicitation is the process of requesting a price and supporting information from bidders. The solicitation usually takes the form of either a request for quotation (RFQ) or a request for proposal (RFP).

An RFQ focuses on price. The product, service, and/or materials are well-defined and can be obtained from several sources. The bidder that can meet the project quality and schedule requirements usually wins the contract by quoting the lowest price.

An RFP is issued when the project team does not know the required solution. The RFP is intended to solicit ideas on how to fulfill the project’s objective with specific solutions. This approach is used in projects utilizing the predictive (waterfall) and adaptive (agile) methodology. For instance, consider a project with the objective of streamlining a service process. The project will involve the introduction of a new service request application. In addition, since the existing desktop computers are too old to run the new application, the project team must upgrade all desktop computers. Since the project team does not know which desktop computer is most appropriate, they issue an RPP to three companies. This project could be following a predictive or an adaptive methodology. The key is that the project team needed assistance in defining an aspect of the full solution. The RFP considers price, but it is more focused on meeting the project’s objective by selecting the appropriate solution. If several vendors have submitted proposals that successfully illustrate how they would be able to support the project’s objective, price can become one of the deciding factors. The process of developing a proposal in response to an RFP can be very time-consuming and expensive for the bidder, and the project team should not issue an RFP to a company that is not eligible to win the bid.

A final consideration is logistics. Equipment and materials that are purchased for use on the project must be transported, inventoried, warehoused, and often secured. This area of expertise is called logistics. The logistics for the project can be managed in many different ways. It can be managed within the project team if they have the needed expertise and access to the required facilities. On larger, more complex projects, a member of the organization’s procurement department may assume accountability for logistics. Lastly, if the organization does not have the required skills and facilities, it will be managed externally, and potentially part of the RFP or RFQ process.

Evaluating Bids

Evaluation of bids in response to RFQs for commodity items (e.g. office supplies) is heavily weighted toward price. In many cases, the lowest total price will win the contract. This is because the vendors have already confirmed they are able to meet the specifications and delivery timelines, so price becomes the determining factor. The total price will include the costs of the goods or services, any shipping or delivery costs, the value of any warranties, and any additional service that adds value to the project. Evaluation of bids for non-commodity items (e.g. services) often considers the vendors’ past performance (obtained from reference checks of existing/past clients).

The evaluation of bids based on RFPs is more complex. The evaluation of proposals includes the price and also an evaluation of the technical approach chosen by the bidder. The project team evaluating the proposal must include people with the expertise to understand the technical aspects of the various proposed approaches and the value of each approach to the project. On more complex projects, the administrative part of the proposal is evaluated and scored by one team, and the technical aspect of the proposal is evaluated by another team. The project team combines the two scores to determine the best proposal for the project. Quite often, the two scores are not weighted equally. Vendor selection is another great example of how the weighted scoring model (discussed in Chapter 2) is used as an effective decision-making tool in project management.

Awarding the Contract

After the project team has selected the bidder that provides the best value for the project, a project representative reviews the contract terms with the successful vendor. Depending on the nature of the product/service to be purchased, some negotiation may occur. Negotiation typically does not occur on less complex awards, such as contracts for standard office supplies. More complex projects require a detailed discussion of the goals, the potential barriers to accomplishing those goals, the project schedule and critical dates, the processes for resolving conflicts and improving work processes, and any penalty clauses. Contracts have a penalty clause if the work is not performed according to the contract. For example, if the new software is not completed in time to support the implementation of the training, the contract might penalize the software company a daily amount of money for every day the software is late. This type of penalty is often used when the software is critical to the project and the delay will cost the project significant money.

Contract Types

In addition, the appropriate contract type has to be identified. There are three primary types of contracts – fixed price, cost reimbursable, and time and materials. The objective is to select the type that creates the fairest and most workable deal for both parties – the project team (client) and the contractor (vendor).

Fixed-Price Contracts

In a fixed price contract, no matter how much time or effort goes into the project, the project always pays the same. As displayed in Exhibit 5.19, the cost to the client remains unchanged while the profit to the vendor decreases as more effort is exerted.

Exhibit 5.19: In a fixed-price contract, the cost to the project is constant regardless of effort applied or delivery date.
^{Project Management for Scientists and Engineers}

The fixed-price contract is a legal agreement between a client (the organization leading the project) and a vendor (person or company) that will provide goods or services for the project at an agreed-on price. The vendor is responsible for incorporating all costs, including profit, into the agreed-on price. The vendor also assumes the risks for unexpected increases in labour and materials that are needed to provide the service or materials and, in the materials, and timeliness needed.

The contract usually details the quality of the goods or services, timing needed to support the project, and price for delivering goods or services. There are several variations of the fixed-price contract. For commodities, goods, and services where the scope of work is very clear and unlikely to change, the fixed-price contract offers a predictable cost. The responsibility for managing the work to meet the needs of the project is focused on the vendor. The project team tracks the quality and schedule progress to ensure the vendor(s) will meet the project needs. Contracts carry a degree of risk. For fixed-price contracts, the risks are the costs associated with project change. If a change occurs on the project that requires a change order from the vendor, the price of the change is typically very high.

Fixed-price contracts require the availability of vendors with appropriate qualifications and performance histories to ensure that the needs of the project can be met. The other requirement is a scope of work that is most likely not going to change. Developing a clear scope of work based on good information, creating a list of highly qualified bidders, and developing a clear contract that reflects that scope of work is critical aspects of a good fixed-priced contract. As a result, solutions that are developed in an iterative fashion (like agile) are generally more challenging to manage with fixed-price contracts.

The fixed-price contract with price adjustment is used for unusually long projects that span years. The main difference is that it considers inflation-adjusted prices. In some countries, the value of its local currency can vary greatly in a few months, which affects the cost of local materials and labour. In periods of high inflation, the contract price is adjusted accordingly. If the adjustment is determined upfront and included in the fixed price, the project accepts the risk that the actual inflation rate is lower than stipulated in the contract and the vendor runs the risk that the actual inflation is higher than stipulated. The volatility of certain commodities can also be accounted for in a price adjustment contract. For example, if the price of oil significantly affects the costs of the project, the contract can allow for an adjustment based on a change in the price of oil.

The fixed-price contract with incentive fee provides an incentive for performing better than stipulated in the contract. A common example is delivering ahead of schedule.

If the service or materials can be measured in standard units, but the amount needed is not known accurately, the price per unit can be fixed—a fixed-unit-price contract. The project team assumes the responsibility of estimating the number of units used. If the estimate is not accurate, the contract does not need to be changed, but the project will exceed the budgeted cost.

Type	Known Scope	Share of Risk	Incentive for Meeting Milestones	Predictability of Cost
Fixed total cost	Very High	All vendor	Low	Very high
Fixed unit price	High	Mostly project	Low	Medium
Fixed price with incentive fee	High	All vendor	High	Medium-high
Fixed fee with price adjustment	High	Depends on how the adjustment will occur (before or after the trigger for adjustment arises)	Low	Medium

Cost-Reimbursable Contracts

Cost reimbursable contracts are also called cost-plus contracts. This is where the vendor charges you for the cost of doing the work plus some negotiated fee or rate. Exhibit 5.21 illustrates this by showing that as efforts increase, costs to the client also increase while the vendor’s profits stay the same.

Exhibit 5.20: In a cost-reimbursable or cost-plus contract, the vendor is guaranteed a profit, but the project’s costs can increase based on effort.
^{Project Management for Scientists and Engineers}

In a cost-reimbursable contract, also known as cost-plus contracts, the organization agrees to pay the vendor for the cost of performing the service or providing the goods. Cost-reimbursable contracts are most often used when the scope of work or the costs for performing the work are not well known.   The project uses a cost-reimbursable contract to pay the contractor for allowable expenses related to performing the work. Since the cost of the project is reimbursable, the vendor has much less risk associated with cost increases. When the costs of the work are not well known, a cost-reimbursable contract reduces the amount of contingency the bidders place in their bid to account for the risk associated with potential increases in costs. This type of contract is often well-suited to projects using the agile development methodology.

This is quite different than fixed-price contracts where vendors try to include as much contingency as possible in their bids as a way to protect their profit margin. In these types of contracts, the vendor is less motivated to find ways to reduce the cost of the project as there is no incentive to do so – the client will reimburse costs incurred by the vendor, even if they are unnecessarily high, as the work is completed. One way to limit exorbitant costs imposed by vendors is to include incentives for supporting the accomplishment of project goals.

Cost-reimbursable contracts require good documentation of the costs that occurred on the project to ensure that the vendor receives payment for all the work performed and that the organization is not paying for something that was not completed. The vendor is also guaranteed a profit over and above cost reimbursement. There are several ways to compensate the vendor:

• A cost-reimbursable contract with a fixed fee provides the vendor with a profit amount, often referred to as a fee, that is determined at the beginning of the contract and does not change.
• A cost-reimbursable contract with a percentage fee provides the vendor with a percentage of the allowable costs as profit. For instance, the fee could be 5% of total allowable costs. The vendor is reimbursed for allowable costs and is compensated with a fee that changes as the costs change.
• A cost-reimbursable contract with an incentive fee is used to encourage performance in areas critical to the project. Often the contract attempts to motivate vendors to save or reduce project costs. For instance, in addition to being reimbursed for allowable costs, the vendor (a talent scout) receives a predetermined bonus fee for each musician who signs on with the record label at a very attractive price.
• A cost-reimbursable contract with award fee reimburses the vendor for all allowable costs plus a fee that is based on performance criteria. The fee is typically based on goals or objectives that are more subjective. An amount of money is set aside for the vendor to earn through excellent performance, and the decision on how much to pay the vendor is left to the judgment of the project team. The amount is sufficient to motivate excellent performance. For instance, in addition to being reimbursed for allowable costs, a music producer receives an award fee from the record label based on the rating of the album.

Cost Reimbursable (CR)	Known Scope	Share of Risk	Incentive for Meeting Milestones	Predictability of Cost
CR with fixed fee	Medium	Mostly project	Low	Medium-high
CR with percentage fee	Medium	Mostly project	Low	Medium-high
CR with incentive fee	Medium	Mostly project	High	Medium
CR with award fee	Medium	Mostly project	High	Medium
Time and Materials	Low	All project	Low	Low

Time and Material Contracts

In a time and materials contract, the client pays a rate for the time spent working on the project and also pays for all the materials used to do the work. Exhibit 5.21 demonstrates that as costs to the client increases, so does the profit for the vendor.

Exhibit 5.21: In a time-and-materials contract, the profit to the vendor increases with increased effort, as do the costs to the project.
^{Project Management for Scientists and Engineers}

For project activities with a high level of uncertainty, the vendor might charge an hourly rate for labour, the cost of materials, plus a percentage of the total costs. This type of contract is called time and materials (T&M). Time is usually contracted on an hourly rate and the vendor would oftentimes be required to submit timesheets and receipts for items purchased for the project. The project reimburses the vendor for the time spent at the agreed-on rate and the actual cost of the materials. The fee, which becomes the vendor’s profit margin, is typically a percentage of the total cost.

T&M contracts are used on projects for work that is smaller in scope and has uncertainty or risk. This is often well suited to projects following the agile development methodology. The project, rather than the vendor, assumes all the risk. However, this can be particularly challenging if there are no limits to the amount of effort and materials that can be applied.

To minimize the risk to the project, the vendor typically includes a not-to-exceed amount, which means the contract can only charge up to the agreed amount. The T&M contract allows the project to adjust the contract as more information about the project’s end solution becomes available. The final cost of the work is not known until sufficient information is available to complete a more accurate estimate.

Since there are numerous contract type alternatives, deciding which type is appropriate for any given project can be challenging. The following considerations can help project teams identify the best alternative for the project:

1. Is the required work or materials a commodity, customized product or service, or unique skill or relationship?
2. How well-known is the scope of work?
3. What are the risks and which party should assume which types of risk?
4. Does the procurement of the service or goods affect activities on the project schedule’s critical path and how much float is there on those activities?
5. How important is it to be sure of the cost in advance?

Progress Payments and Change Management

Vendors usually require payments during the life of the contract. On contracts that last several months, the vendor will incur significant costs and will want the project to pay for these costs as early as possible. Rather than wait until the end of the contract, a schedule of payments is typically developed as part of the contract and is connected to the completion of a defined amount of work or project milestones. These payments made before the end of the project and based on the progress of the work are called progress payments. For example, the contract might develop a payment schedule that pays for the design of the solution, then the development of the solution, and then a final payment is made when the solution is completed and accepted. In this case, there would be three payments made. There is a defined amount of work to be accomplished, a time frame for accomplishing that work, and a quality standard the work must achieve before the vendor is paid for their work.

Just as the project has a scope of work that defines what work will be done by the project team and what will be outsourced, vendors and suppliers have a scope of work that defines what they will produce or supply to the company. Often changes occur on the project that require adjustments to the vendor’s scope of work. How these changes will be managed during the life of the project is typically documented in the contract. Capturing these changes early, documenting what changed and how the change impacted the contract, and developing a change order (a change to the contract) is important to maintaining the progress of the project. Conflict among team members may arise when changes are not documented or when the team cannot agree on the change. Developing and implementing an effective change management process for vendors will minimize this conflict and the potential negative effect on the project.

Managing the Contracts

The contract type determines the level of effort and the skills needed to manage the contract. The individual responsible for managing the contracts develops detailed specifications and ensures compliance with these specifications. They track the vendor’s performance against the project needs, as outlined in measurable performance evaluation criteria, supplying support and direction when needed.

Items that take a long time to acquire—long-lead items—receive early attention from the project team. An example of a long-lead item is equipment that must be designed and built specifically for the project. The equipment might require weeks, months, or years to develop and complete.

Occasionally, vendors do not perform to project expectations. Some project leaders will refer to the contract and impose penalties in an attempt to persuade the vendor to improve performance. Other project leaders will first brainstorm ways that the vendor could improve performance and meet project requirements before penalties are imposed. Both approaches to deal with non-performing vendors can work, and the project team must assess what method is most likely to work in each situation.

Managing vendor performance on a project is as important to the overall project outcomes as the work performed by the project team.

5.8 Quality Management

Ensuring that the project is done on time, on budget, and within scope is important but there is more to project success. Project success also involves delivering the right solution that accomplishes the project’s objective and satisfies stakeholders’ expectations. This is the role of quality management.

High quality is achieved by planning for it rather than by reacting to problems after they are identified. Standards are chosen and processes are put in place to achieve those standards. Similar to the triple constraints (scope, cost, and schedule), quality is managed on a project by setting goals and taking measurements. It is important to understand the quality levels stakeholders believe are acceptable and ensure that the project meets those targets.

When the project team gathers requirements for the solution, they identify all of the specifications that stakeholders want in the product so they know how to define and measure quality. “Fitness to use” is about making sure that the product has the best design possible to fit the customer/client’s needs. For example, you could pound in a nail with a screwdriver, but a hammer is a better fit for the job. Conformance to requirements is the core of both customer satisfaction and fitness to use and is a measure of how well the solution meets expectations. Above all, the solution must fulfill the requirements established by the users.

On large complex projects, the team may decide a formal quality management plan is necessary. This plan should be developed with key stakeholders, including the end-user community. The plan will not only identify what the quality expectations are, but it will also identify the work required to ensure these expectations are fulfilled. Just as the project budget and completion dates may change over the life of a project, the project specifications may also change. The approach to managing change is dependent on the development methodology chosen. When the requirements for the solution are being defined upfront, as is the case with the predictive/waterfall methodology, formal change control processes are important as commitments regarding project duration and/or project cost have likely already been established. Formally assessing changes in quality specifications allows the team to understand the impact on the commitments. In these situations, the impacts are communicated and approvals are sought before implementation occurs. In projects using an adaptive/agile approach, the end solution cannot be clearly defined. The quality expectations will be defined when the capabilities, features, and user stories are developed in cycles.

Project management organizations that execute several similar types of projects may find process improvement tools useful in identifying and improving the baseline processes used on their projects. Process improvement tools may also be helpful in identifying cost and schedule improvement opportunities. Students wishing to learn more about these tools can begin by reading about Lean Six Sigma practices for products and their applicability to service organizations. Ideally, opportunities for improvement are to be quickly identified in order to influence project performance. This is particularly true when the predictive/waterfall development methodology is used since planning is completed upfront. During later project stages, as pressures to meet project schedule goals increase, the culture of the project is less conducive to making changes in work processes.

Many organizations have a quality policy that states how it measures quality across the organization. When planning quality in the project, project leaders must ensure that the project follows the company policy and any government rules or regulations.

Part of good quality planning includes identifying the tasks that need to be performed in order to measure the quality of the project’s solution. These specific tasks will be part of the scope and considered when schedules and budgets are developed.

Techniques

Several different tools and techniques are available for planning and controlling the quality of a project. The extent to which these tools are used is determined by the project complexity and the quality management program in use by the organization.

The following represents some of the quality planning tools in use today:

• Cost-benefit analysis is looking at how much the quality activities will cost versus how much will be gained from doing them. Typical cost considerations include the effort and resources required to carry out the quality activities. Typical benefit considerations include greater user satisfaction, less reworking, and greater productivity.
• Benchmarking is using the results of quality planning from other projects to set goals for the current project. If the last project in the organization had 20% fewer defects than the one before it, the project team should learn from a project like that and put in practice any of the ideas the previous project used to make such a great improvement. Benchmarks can serve as reference points for evaluating a project before the work begins.
• Design of experiments is the list of the array of tests to be run on the product. It might list all the kinds of test procedures, the approaches to be taken, and even the tests themselves. (In the software world, this is called test planning.)
• Cost of quality is obtained by adding up the cost of all the prevention and inspection activities to be performed on the project. This includes many different activities, such as testing, time spent writing standards, reviewing documents, meeting to analyze the root causes of defects, and reworking to fix the defects identified by the team… in other words, absolutely everything that is done to ensure quality on the project. The cost of quality can be compared from one project to another in order to identify innovative ideas and best practices.
• Control charts can be used to define acceptable limits. If some of the functions of a project are repetitive, statistical process controls can be used to identify trends and keep the processes within control limits. Part of the planning for controlling the quality of repetitive processes is to determine what the control limits are and how the process will be sampled.
• Cause-and-effect diagrams can help in discovering problems. When control charts indicate an assignable cause for a variation, it is not always easy to identify the cause of a problem. Discussions that are intended to discover the cause can be facilitated using a cause-and-effect, or fishbone diagram, where participants are encouraged to identify possible causes of a defect.

Example: Diagramming Quality Problems

A small manufacturing firm tries to identify the assignable causes of variations in its manufacturing line. They assemble a team that identifies six possibilities:

• Low-quality raw materials
• Power fluctuation
• Ambient temperature
• Worker absenteeism
• Poor training
• Old equipment

Each of these possibilities is organized into a fishbone diagram below.

Exhibit 5.22: Cause-and-effect (fishbone) diagram

Then, each branch of the diagram can be expanded to break down a category into more specific causes. An engineer and an electrician work on one of the branches to consider possible causes of power fluctuation. They identify:

• Utility reliability
• Personal space heaters and large motor start-up leading to overloaded circuits
• Lighting

Those items are added to their part of the fishbone diagram, as shown below.

Exhibit 5.23: Cause-and-effect (fishbone) diagram expanded

Check sheets, histograms, and Pareto charts are also used to solve several quality problems. When a quality-control issue occurs, a project leader must choose which problem to address first. One way to prioritize quality problems is to determine which ones occur most frequently. These data can be collected using a check sheet, which is a basic form on which the user can make a check in the appropriate box each time a problem occurs, or by automating the data collection process using the appropriate technology.

Exhibit 5.24: Example of a check sheet
^{DanielPenfield, Wikimedia}

Once the data are collected, they can be analyzed by creating a type of frequency distribution chart called a histogram. A true histogram is a column chart where the widths of the columns fill the available space on the x-axis axis and are proportional to the category values displayed on that axis, while the height of the columns is proportional to the frequency of occurrences. Most histograms use one width of the column to represent a category, while the vertical axis represents the frequency of occurrences.

A variation on the histogram is a frequency distribution chart invented by economist Vilfredo Pareto known as a Pareto chart, in which the columns are arranged in decreasing order with the most common on the left and a line added that shows the cumulative total. The combination of columns and a line allows the user to tell at a glance which problems are most frequent and what fraction of the total they represent. For instance, in Exhibit 5.24, there are six reasons why travellers arrive late at the airport. Traffic is the number one reason and it was reported by 55 participants. Approximately 154 people participated in this study. Traffic represents approximately 36% of the total late arrivals (55/154). The second highest cause, child care issues, represents 26% of the total. Cumulatively, traffic and child care issues represent 62% of the total. The third cause, public transportation issues brings the cumulative total to approximately 80% of the total. Understanding what causes the majority of the issues allows a team to prioritize and focus on these key factors. In this case, if the airport wanted to significantly reduce the number of late arrivals, they could focus on traffic, child care and public transportation issues.

Exhibit 5.25: Example of Pareto chart
^{Dense2013, Wikimedia}

Quality and Grade

According to the International Organization for Standardization (ISO), quality is “the degree to which a set of inherent characteristics fulfill requirements.” The requirements of a product or process can be categorized or given a grade that will provide a basis for comparison. The quality is determined by how well something meets the requirements of its grade.

For most people, the term quality also implies good value—getting your money’s worth. For example, even low-grade products should still work as expected, be safe to use, and last a reasonable amount of time.

Thinking back to our case study, John has antique furniture in excellent condition that he inherited from his grandmother. Since the pieces are valuable to John for sentimental reasons, he decides to hire movers (“high-grade professionals”) to load his furniture into the truck using appropriate padding, and restraints to prevent dents or scratches during the move. John’s standard for high quality is that no observable damage occurs to his large pieces of furniture, especially the antiques. If the furniture arrives in his new apartment without a single dent, scratch, or other damage, the activity will be of high quality. On the other hand, since John’s dishes, glassware, and utensils are old and cheap, his standard for packing his kitchen is lower. Therefore, he decides to trust his inexperienced friends (“low-grade amateurs”) to help him pack his kitchen. If a few of the dishes or glassware are chipped or broken in the process, the savings in labour cost will more than makeup for the loss and will still produce good value.

Measurement Terminology

During implementation, services and products are sampled and measured to determine if the quality is within control limits for the requirements and to analyze possible causes for any quality variations. This evaluation is often done by a separate quality control group, and knowledge of a few process measurement terms is necessary to understand their reports. Several of these terms are similar, and it is valuable to know the distinction between them.

Project teams can identify the control limits of the product or process. The size of the range between those limits is the tolerance. Tolerances are often written as the mean value, plus or minus (±) the tolerance.

Tools are selected that can measure the samples closely enough to determine if the measurements are within control limits and whether any trends emerge. Each measurement tool has its own tolerances.

The choice of tolerance directly affects the cost of quality (COQ). In general, it costs more to produce and measure products that have small tolerances. The costs associated with making products with small tolerances for variation can be very high and not proportional to the gains. For example, if the cost of evaluating each screen as it is created in an online tutorial is greater than delivering the product and fixing any issues after the fact, then the COQ may be too high and the instructional designer will tolerate more defects in the design.

Statistics

Determining how well products meet grade requirements is done by taking and interpreting measurements. Statistics, the mathematical interpretation of numerical data, are useful when interpreting large numbers of measurements to determine how well the product meets a specification (when the same product is being made repeatedly). Measurements made on samples of the product must be within control limits, which are the upper and lower extremes of allowable variation, and it is up to the project team to design a process that will consistently produce products between those limits.

 

If a process is designed to produce a product of a certain size or another measured characteristic, it is impossible to control all the small factors that can cause the product to differ slightly from the desired measurement. Some of these factors will produce products that have measurements that are larger than desired, and some will have the opposite effect. If several random factors are affecting the process, they tend to offset each other, and the most common results are near the middle of the range; this phenomenon is called the central limit theorem.

If the range of possible measurement values is divided equally into subdivisions, referred to as bins, the measurements can be sorted, and the number of measurements that fall into each bin can be counted. The result is a frequency distribution that shows how many measurements fall into each bin. If the effects that are causing the differences are random and tend to offset each other, the frequency distribution is called a normal distribution, which resembles the shape of a bell with edges that flare out. The edges of a theoretical normal distribution curve get very close to zero but do not reach zero.

Quality Assurance

The purpose of quality assurance is to create confidence that the quality plan and controls are working properly. Time must be allocated to review the original quality plan and compare that plan to how quality is being ensured during the implementation of the project.

Process Analysis

The flowcharts of quality processes are compared to the processes followed during actual operations. If the plan was not followed, the process is analyzed and corrective action is taken. The corrective action could be to educate the people involved on how to follow the quality plan, or, alternatively, it could be to revise the plan.

The experiments that sample products/processes and collect data are examined to see if they are following statistically valid sampling techniques and that the measurement methods have small enough tolerances to detect variation within control limits.

Because projects are temporary, there are fewer opportunities to learn and improve within a project, especially if it has a short duration. But even in short projects, the quality manager should have a way to learn from experience and change the process for the next project of a similar complexity profile.

The purpose of quality assurance is to build confidence in the user that quality standards and procedures are being followed. This is done by an internal review of the plan, testing, and revision policies or by an audit of the same items performed by an external group or agency.

5.9 Stakeholder and Communications management

Achieving a project’s objectives requires a focused, well-organized project leader who can engage with a committed team and gain the support of all stakeholders. Building strong, trusting relationships with interested parties from the start can make the difference between project success and failure.

Stakeholder management is one of the most important and challenging aspects of successful project management. Project leaders must rely on their soft skills to be effective in this area. Effective project leaders spend a significant amount of time building relationships with stakeholders.

Understanding a stakeholder’s interest is about understanding “what is in it for them?” In addition, asking stakeholders how they define project success is a powerful way of identifying their expectations. Knowing what each stakeholder needs or wants from the project will enable the project leader to anticipate the stakeholder’s level of support and identify any potential conflicts that may arise. Conflicts are common and often healthy for projects. When managed effectively, conflicts lead to good decisions that optimize the value of the project. At the outset, conflicts often arise when prioritizing project constraints. For instance, one stakeholder may believe it is more important to complete the project with an aggressive timeline while another may feel minimizing project cost is the priority. Another common example is in defining solution requirements. Project leaders need to ensure the voice of their stakeholders is continuously heard during solution design and development. This may lead to differences of opinion and these differences need to be resolved in a respectful, timely fashion. Depending on the development methodology chosen, resolving these differences may be part of the product owner, business subject matter expert, scrum master, business analyst, and/or project leader’s accountabilities.

When project leaders are accountable for resolving these differences, interpersonal skills are key. Active listening and a clear willingness to facilitate relationship-building between stakeholders are important. In addition, staying “passionately neutral” in the eyes of stakeholders is important. As a project leader, it is not about what is best for you, it is about identifying what is best for the project and the organization, and passionately pursuing that with stakeholders. Resolving conflicts in respectful ways is a skill that can be developed over time.

In some cases, project leaders will be working with stakeholders that are not supportive of the project. They may feel the project is not going to benefit them and their team in the ways it should. They may also resist making the changes that are necessary to support the project’s outcomes. Some stakeholders are very upfront about their resistance and others are not. In these situations, the project Sponsor may be integral to winning these stakeholders over. Knowing when to tactfully involve others in stakeholder management is another key success factor for effective project management.

Building trust and maintaining an open line of communication is critical in working with all stakeholders. Keeping stakeholders involved is essential and it requires more than simply sharing information. The project leader must ask for their input and demonstrate an understanding of a stakeholder’s unique business challenges. This level of understanding is often done through simple and regular check-ins with stakeholders. Lastly, project leaders who are successful in relationship building understand each stakeholder’s capacity to participate and honour their time constraints.

As mentioned in Chapter 4, the stakeholder register is an effective tool for project leaders to use throughout the project. It allows the project team to keep track of all the stakeholders and ensure their needs are represented in the communications plan.

Let us look more closely at the communication techniques project leaders use to ensure the right information is reaching the right audience at the right time and in the right mediums.

There are two types of communications: synchronous and asynchronous. If all the parties to the communication are taking part in the exchange at the same time, the communication is synchronous. There are many examples of synchronous communications: conference calls, live meetings, and instant messaging. There are many ways to conduct conference calls: telephone, computer-assisted conference audio, and/or video calls. Platforms such as Skype, Zoom, and Microsoft Teams have made virtual collaboration so much more effective.

Getting a team together at the same time can be a challenge, especially if they are spread out across time zones. Many types of communication do not require that the parties are present at the same time. This type of communication is asynchronous (the letter “a” at the beginning of the word means not.) There are several choices of asynchronous communications. Some methods are very traditional, such as mailing legal documents, while others are much more innovative, such as web-based collaboration platforms. Global projects need to consider the availability of collaboration technology for all participants as it can vary significantly by country. Web-based platforms have transformed the way people communicate. However, some organizations still use email to manage projects.

Some messages are best conveyed through synchronous methods while others are well suited to asynchronous methods. For instance, conflict resolution is often more effective when done synchronously as it is much easier to understand other people’s perspectives when body language is observable. Communicating large amounts of technical information are best done asynchronously as this gives the reader the opportunity to review, process, and respond to the information after they have had a chance to absorb it in written form. Project leaders are much more likely to be successful when they have strategically considered and documented how and when project information will be communicated. This is the role of the communications plan. Communication plans answer the following questions:

1. What information do stakeholders need?
2. When is this information needed?
3. How should this information be collected and analyzed? (systems and/or people?)
4. How and when should this information be distributed? (technology platforms and/or people?)
5. How will the project team ensure the communication is effective? (feedback loops)

The first step is a critical one as the planning flows from the communication needs analysis. In deciding what information stakeholders need, project teams consider the information needed to keep stakeholders engaged, supportive and able to make good decisions. Project information is often very abundant and it is easy to overwhelm stakeholders with all of it. Project teams must turn all this information into insight and determine what stakeholders will value. Communicating valuable information does not mean you always paint a rosy picture. Stakeholders should not be sheltered from bad news. Project teams that proactively communicate bad news are much more likely to earn the respect of stakeholders as transparency is valued. After the needs analysis is complete, common information needs emerge. Common needs include project objectives, scope, milestones, budget, risks, issues, action items, performance measures, approvals required, and so forth.

The types of communication technology present on the project heavily influences the approaches taken in answering the remaining questions about how information is communicated, when it is communicated, and who is responsible for developing/delivering the communications. In some cases, the project team will already have the information technology needed to create and deliver effective communications. When this isn’t the case, it’s time to assess new communications technologies.

Assessing New Communication Technologies

New technologies for communicating electronically appear with increasing frequency. Using a new technology that is unfamiliar to the team increases the technical complexity, which can cause delays and increase costs. To decide if a new tool/application should be included in a communications plan, seek answers to the following questions:

• Does the new tool/application provide a benefit for the project by increasing access to information, reducing the cost and time associated with creating and disseminating information and/or preventing mistakes?
• Does the project team have the expertise and capacity to learn new technology quickly?
• Does the company offer support such as a help desk to assist team members to use new communication technology?
• Does the organization, and in particular, the project, have the money needed to acquire new tools/applications?

Communication Plan Templates

In addition to these questions, determining the urgency, complexity and audiences of the information can help project teams match the communication tool to the nature of the information to be communicated. The answers to all of these questions are documented in the communication plan. There are many different types of communication plans. A good template will include the following:

1. Who the stakeholders are (individuals and groups)
2. The communications necessary to satisfy stakeholder expectations
3. The timeframe and/or frequency of communication messages
4. The tools/applications used to communicate the messages
5. Roles and responsibilities for creating and disseminating the messages

Exhibit 5.26: Communications plan template
^{Inte5160, Wikispaces}