5. Project Planning

Overview

After the project has been approved and the project team has been appointed, you are ready to enter the second phase in the project management life cycle: project planning. This phase involves creating a set of plans to help guide your team through the execution, monitoring, and closure phases of the project. The plans created during this phase will help you manage time, cost, scope, quality, changes, risk, and other related issues. They will also help you lead staff and work with external suppliers to ensure that you deliver the project on time, within budget, and with the desired feature/functionality.

The planning phase is often the most challenging phase for a project leader because they must make educated guesses about the staff, resources, and equipment required to complete the project.

In collaboration with the project sponsor(s), the project leader identifies the work to be done for the project or the iteration (depending on the development methodology used). Once the major components of the project (or iteration) are known, the project leader will identify team leaders to carry out the detailed planning of the project’s sub-components. These components are often called “work packages” in predictive methodology and “sprints” in agile’s adaptive methodology.

Also, at this stage, resource requirements are identified in whole or in part (depending on the development methodology used). A strategy is developed for accomplishing the work. Then, the timeframes, dependencies, and resources required for work packages or sprints are documented in a project schedule. In addition, the project leader coordinates the preparation of a budget by providing cost estimates for the labour, equipment, and materials. The budget is monitored during the implementation and closure phases.

Once the project team has identified the work, prepared the schedule, and estimated the costs, the three fundamental components of the planning process are complete. This is an excellent time to identify and try to deal with anything that might pose a threat or an opportunity to the successful completion of the project. This is called risk management. In risk management, the threats and opportunities are identified along with the action that is to be taken as a response in order to optimize the likelihood of project success. In the initiation phase, a preliminary list of project stakeholders was identified. During the planning phase, the list is reviewed to ensure that it remains current and stakeholders continue to be prioritized. Stakeholder engagement is a critical success factor. An effective communication plan is one of the tools used to ensure stakeholders remain informed and supportive of the project’s objectives. Effective project leaders spend about 90% of their time on a project communicating with stakeholders.1

In some instances, organizations need to obtain products and utilize services from outside of the organization. Overseeing these transactions is known as procurement management. During the planning stage, it involves identifying the type of vendors required and the selection criteria to be used. Finally, project leaders ensure that the team understands the quality expectations of the stakeholders. In order to fulfill these expectations, a quality management plan is developed (identifies quality targets, assurance, and control measures), along with an acceptance plan (lists the criteria to be met in order to gain stakeholder acceptance).

The project leader integrates the team’s planning efforts. Various tools and techniques are used to effectively perform integration management. A comprehensive project plan may be created to ensure all the various management plans identified above are cohesive and well-aligned. Project plans are typically created for projects with a medium-to-high level of complexity and rarely for low complexity projects. Determining the need for a project plan is part of the tailoring work done by the project leader at the outset of each new project.

The planning phase refines the project’s objectives, which were identified during the initiation phase. This phase also includes planning the steps necessary to meet those objectives by further identifying the specific activities and resources required to complete the project. Once the objectives have been fully recognized, they must be clearly articulated, specifically detailing in-depth scrutiny of each objective. When viewed under such scrutiny, the team’s understanding of the objectives may change. Often, the very act of describing something precisely allows us to better understand its scope. This articulation serves as the basis for the development of requirements. What this means is that, after an objective has been clearly articulated, it can be described in concrete (measurable) terms and the steps to achieve it are easier to identify. Obviously, if a poor job is done of articulating the objectives, the requirements will be misdirected, and the resulting project will not represent the true need.

1.1 Eliciting Project Requirements

After the objectives of the project are identified, the project leader needs to better understand the solution’s requirements. Requirements describe the characteristics of the final outcome, which may be a product, service, or result of the project. Moreover, requirements describe the functionality that the final outcome must possess and specific conditions that must be met in order to satisfy the objectives of the project.

It is important to start defining requirements at the project level. Project requirements describe what the project is supposed to accomplish. This gives the project team a clear understanding of the required outcomes and their corresponding organizational value. These outcomes often describe the transformation that will occur within the organization as a result of the project’s implementation. A clear picture of the current state (the “as-is”) and the desired future state (the “to-be”) is an effective way to help the team determine what the solution must achieve. Teams that lack an understanding of the project requirements are unlikely to deliver solutions that provide organizational value.

Solution requirements are developed after the project requirements. When the adaptive development methodology is used, the requirements are developed in an iterative or incremental fashion. As previously mentioned, in agile, solution development begins with an epic, which are the rough outlines and boundaries of the solution. The end-user community is involved in numerous requirement development sessions. These sessions determine the required capabilities, enablers, and features of the solution. Features are written as user stories which are then compiled in a product backlog that becomes the basis of iteration planning. The iterations are referred to as sprints, each containing a set of requirements that guides the development and testing efforts.

In contrast, when the predictive development methodology is used, the end solution is clear, allowing the requirements to be completed upfront. The end-user community participates in far fewer requirement development sessions than when an adaptive approach is used.

In general, solution requirements may include attributes such as dimensions, ease of use, colour, specific ingredients, and so forth. Requirements must be measurable, testable, related to identified organizational needs or opportunities, and defined to a level of detail sufficient for solution design.

The Nature of Requirements

When developing a solution, many different aspects must be considered. At the simplest level, the project team will seek to understand how the end-user community expects the solution to function. In addition, the project team must determine how this functionality will be delivered through technology and related systems. Lastly, there may be regulatory or industry-specific requirements that require consideration.

The End-User Community

Solution requirements start with the end-user. In fact, project success is dependent on a  clear understanding of the end users’ needs. When project teams identify the end users’ functional requirements, they are focusing on the user experience with the new product, service, and/or result. End-user requirements can be written as user stories that describe what the user wants the solution to do and how the solution should perform. This allows the project team to understand which features are valued and therefore required, by the end-users. When the needs of the end-user community are considered in solution design, the project team can begin to narrow down the potential design alternatives. Further, the needs of the end-users help identify which quality expectations must be fulfilled.

Technical Requirements

Technical requirements emerge from an understanding of the end users’ requirements. Functional requirements provide answers to questions such as: how will the problem be solved this time, and will it be solved technologically and/or procedurally? These requirements specify how the system must be designed and implemented in order to provide the required functionality and fulfill quality expectations.

For example, in a software project, the functional requirements may stipulate that a database system will be developed to allow access to financial data through a remote terminal. The corresponding technical requirements would spell out the required data elements, the language in which the database management system will be written, the hardware on which the system will run, the telecommunication protocols that should be used, and so forth. Similarly, end-users may require the solution to be functional and accessible 95% of the time. The technical requirements will identify how this will be done using backup power supplies and so forth.

Regulatory or Industry-Specific Requirements

Regulatory requirements are rules that are mandated by the government. For an example of a regulatory requirement, privacy and the protection of confidential client/customer information are extremely important to consider for projects in a variety of industries due to strict laws imposed by parliament. Regulatory requirements can be very industry-specific, which, as previously mentioned, is beyond the scope of this textbook.

Elicitation Techniques

Although the project leader is responsible for ensuring that the requirements are clear and well documented, they usually do not perform this work. The approach taken varies considerably depending on the chosen development methodology. Key differences include the roles responsible for requirement development and the number of sessions held throughout the project. Predictive (waterfall) development methodologies define solution requirements upfront. As a result, fewer requirement development sessions are necessary. In contrast, when the adaptive development methodology is used, a product owner works very closely with the project leader to plan the number and nature of the sessions required.

Despite these differences, some of the information sources are similar. For instance, the following documents are often reviewed:

  • Process flows for the “as is” environment
  • Policies and procedures
  • Problem/issue logs (including customer complaint logs)
  • User cases/stories created for technological implementations

Although documents can be helpful, they are often incomplete. It is important to consult with end-users directly. This direct consultation may involve discussions with employees who represent the voice of the end customer as well as the end customers themselves. The following techniques can be used:

  • Interviews
  • Focus groups
  • Facilitated group sessions
  • Group creativity techniques, such as:
    • Brainstorming
    • Mind-mapping
  • Observation of clients, customers, and/or end-users
  • Questions and surveys
  • Group decision-making techniques, such as:
    • Seeking consensus (among experts, the project team, the end-user community and so forth)
    • Majority rule voting
    • Dictatorship (project sponsor or product owner decides)

An important note about adaptive development approaches: prototyping is a common method used to identify requirements. It allows stakeholders to experiment with an evolving model of the final product and/or solution. This is very helpful because many stakeholders find it challenging to verbally explain or write down their needs. Seeing how things work may help them articulate their needs. Additionally, a prototype allows the project team to measure the product and/or solution’s functionality and performance in a more realistic way. Once assessed, the prototype can be refined based on any revelations learned.

Requirements Traceability Matrix

Keeping track of the requirements is important for many reasons. Firstly, tracking the source of the requirement is helpful in resolving issues of prioritization. It may not be possible to develop a solution with all the requested requirements due to a lack of feasibility, time, and/or money. Consultation with stakeholders becomes critical in these situations. In addition, difficulties may arise during development, requiring the input and review of specific stakeholders depending on whether their requirements have been affected. These situations underscore the importance of knowing which stakeholders have requested which requirements.

There is an arguably more important reason to track requirements; it ensures that each requirement can be efficiently traced back to the objectives of the project. This allows the team to constantly reflect on whether specific requirements add value.

In summary, a requirements traceability matrix is a popular tracking tool because it offers the following benefits:

  1. Supports requirement prioritization by linking value to implementation effort (“must have” versus “nice to have”)
  2. Supports effective stakeholder management by understanding a requirement’s source
  3. Aids in tracking the status of each requirement, specifically ensuring that requirements are considered in the product or service design and delivered by the end of the project
  4. Provides a structure for managing changes, if necessary, to a requirement’s scope

An effective requirements traceability matrix includes the following information:

  • Requirements to organizational value and project objectives
  • High-level requirements to more detailed requirements
  • Requirements to project scope/work breakdown structure
  • Requirements to product/service design
  • Requirements to product/service development
  • Requirements to test strategy and test scenarios

Additionally, attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about each requirement. Typical attributes used in the requirements traceability matrix may include a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved), date completed, and acceptance criteria, which ensure that the requirement has met stakeholders’ satisfaction.

Once the requirements are documented, the appropriate stakeholders sign off to confirm their needs have been accurately recorded. The project leader then ensures that the requirements are incorporated into the overall project plan (for predictive approaches) or iteration plans (for adaptive approaches).

The effective specification of requirements is one of the most challenging undertakings tackled by project teams. Inadequately specified requirements will guarantee poor project results. Excellent communication and negotiation skills are critical as project leaders often need to educate stakeholders about the organizational impacts and implementation complexity of some of their requirements. In addition, when elaborate requirements introduce additional complexity in a project, more staff, time, and/or money may be required. The added complexity may also have an impact on project quality. Furthermore, some aspects of the project may be unfeasible. If this is the case, there must be transparency with stakeholders so they can adjust their expectations and/or prepare for future organizational challenges.

5.2 Scope Management

Requirements assist project teams in making scope decisions. During the initiation phase, the scope is often broadly defined. High-complexity projects are more likely to have broad definitions of scope,  describing the desired outcomes of the project, since the availability of information regarding the solution may have been minimal. However, as more information is obtained, the scope begins to be further refined in the planning phase.

Scope statements identify the product and project deliverables that will be produced during the project or the iteration. Deliverables are tangible outcomes that must be produced created in order for the project or the iteration to be completed. This includes the project management deliverables and the product/service/result deliverables, which are features that characterize the solution. In essence, the project scope denotes what work will be done whereas the other project plans denote how the work will be done.

When the predictive/waterfall development methodology is used, a scope statement representing the full scope of the project is created. Then, the development team uses this scope statement to design and develop the end solution in its entirety. When the adaptive development methodology is used, all the user stories contained in the product backlog represent the scope of the project. The development team does not work on the entire backlog at once. During iteration planning, the backlog is prioritized into small “sprints.” The scope of these small sprints usually represents a few weeks of development effort. The results of each sprint are reviewed with the end-user community and adjustments are made as appropriate. The scope of the sprints may change as the team learns more about the end users’ requirements and the effort required in each sprint.

One of the most common challenges in projects following a predictive (waterfall) development methodology is the unintentional expansion in the project scope. This is referred to as scope creep. Sometimes this occurs because the scope was poorly defined at the onset. Perhaps the scope statement was poorly developed and/or lacked the necessary stakeholder input and approval. Furthermore, the project team may have chosen the wrong development methodology. For instance, if the team knew that the outcome of the project was unclear and chose the predictive (waterfall) methodology regardless, scope management will prove to be very challenging for the project team and stakeholders. This is because the stakeholders are likely to advocate for the preservation of timeline and budget commitments. This leaves the project team with the chaotic task of figuring out how to deliver on these commitments while the scope remains fluid.

This is not to say that scope should never be expanded. The key is how the scope is changed. When scope changes are analyzed and formally approved (versus automatically or unintentionally pursued), project leaders can determine the impact of this change on the project’s timelines, budget, and quality constraints (recall the triple constraints theory). Communicating the impact of scope expansion on these constraints allows stakeholders to make effective decisions about project priorities.

Work Breakdown Structure

The work breakdown structure (WBS) is a powerful communication tool. It is a visual depiction of the work (scope) to be completed during a project by breaking the project down into smaller, more manageable components.

When the predictive (waterfall) methodology is used, a deliverable-oriented WBS is often used to identify the relationship between the deliverables, sub-deliverables, and, ultimately, the work packages associated with the project. Each level of the WBS hierarchy represents a more detailed breakdown of the project work wherein the top of the hierarchy represents broad categories and the lower levels represent increasing amounts of detail, with work packages always being the lowest level of the WBS. Some project teams prefer to use a phase-oriented WBS to depict the deliverables of each phase. For instance, the phases could be initiation, planning, development, testing, rollout and closure. Both are acceptable forms of the WBS. The project leader is free to determine the number of levels in the WBS based on the complexity of the project. It is important to include enough levels to accurately estimate project time and costs, but not so many levels that it becomes too detailed and difficult to read.

When an adaptive methodology such as agile is used, the WBS depicts the relationship between the project (an “epic”), the capabilities of the solution, the features/enablers of the solution, the user stories, and the sprints that contain the development teams’ tasks.

It is very important to note that the WBS defines what needs to be done, not how. The how is developed by the work package leaders once the WBS has been completed and it is depicted using tools like the project schedule and project budget.

A WBS can be structured in a graphical form where boxes represent the major deliverables, sub deliverables and work packages. The individual boxes cascade in a hierarchy, illustrating the relationship of the underlying work. Exhibit 5.1 depicts the WBS language used in predictive (waterfall) and adaptive (specifically agile) methodologies.

Exhibit 5.1: The WBS for Predictive and Adaptive development methodologies. In predictive methodology, the sequence is as follows: project, major deliverables, sub-deliverables, and work packages. In the case of iterative/agile methodology, the sequence is: project (may be referred to as an ‘epic’), capabilities, features/enablers, and sprints.

It is also possible that the list format is used. This format simply lists the deliverables and the underlying work in a list format. The list format below uses terminology from the predictive methodology.

WBS Formatting

Project Name

1.0 Major Deliverable

  • 1.1 Sub Deliverable
  • 1.2 Sub Deliverable
  • 1.3 Sub Deliverable

2.0 Major Deliverable

  • 2.1 Sub Deliverable
    • 2.1.1 Work Package
    • 2.1.2 Work Package
    • 2.1.3 Work Package
    • 2.1.4 Work Package
  • 2.2 Sub Deliverable
  • 2.3 Sub Deliverable

3.0 Major Deliverable

  • 3.1 Sub Deliverable
    • 3.1.1 Work Package
    • 3.1.2 Work Package
    • 3.1.3 Work Package
  • 3.2 Sub Deliverable
    • 3.2.1 Work Package
    • 3.2.2 Work Package
  • 3.3 Sub Deliverable

Each level of a WBS can be assigned a unique identifier. This unique identifier is typically a number that is used to track costs, durations and resources associated with WBS elements. These identifiers are usually associated with an organization’s chart of accounts, which is used to track costs by category. In addition, these identifiers are often referred to in a project schedule and a project budget as this allows the project team to ensure all the project work has been properly scheduled and resourced.

Work packages and sprints are components that are easily assignable to a team of people, providing clear accountability and responsibility for detailed planning and ultimately implementation. It is important to ensure that individuals with the appropriate skills, experience, and capacity are assigned to manage the delivery of this work. They collaborate with the appropriate stakeholders to:

  1. Confirm who must be involved in the work
  2. Identify the tasks to be performed
  3. Create a detailed schedule for the tasks, including identifying all the required resources, durations, sequencing, and key monitoring points for measuring success.
  4. Identify the cost of completing the work
  5. Identify specific assumptions, risks, and issues

The project leader compiles the work of all work package/sprint teams in order to produce integrated plans for the project as a whole. Project leaders often discover situations where the schedules and budgets are in conflict with stakeholder expectations. When this occurs, the project leader gathers the appropriate stakeholders (e.g. scrum master and product owner[s] in cases where adaptive methodology has been used). The project leader then facilities alignment with the stakeholders and the project’s objectives.

The upcoming sections on schedule management, budget management, risk management, and stakeholder management will delve deeper into these important aspects of project management.

5.3 Resource management

Resources are people, equipment, space, money, and anything else needed to produce the project’s deliverables. Staffing the project with the right skills, at the right place, and at the right time is an important responsibility of the project leader. The project usually has two types of team members: functional participants and process participants. The titles and roles given to these functional resources may vary by organization and/or the development methodology chosen. For instance, some organizations refer to their functional representatives as business owners and business SMEs (subject matter experts). High-complexity projects often involve people who are gifted in project management processes. These individuals would have process expertise in estimating, cost tracking, planning, and scheduling. In projects involving the launch of a new product, functional team members would include sales and marketing representatives from their respective departments. The functional representatives will play a vital role in ensuring the project team understands the requirements of the solutions to be developed. The project leader requires functional and process experts to work together in the planning and execution of a successful project.

Exact start and end dates for team members are often negotiated to best meet the needs of individuals and the project. Projects typically have a core team that includes members of the project management team (project leader, project coordinator, and so forth) and key members with functional expertise. Core team members provide continuity and “corporate memory” throughout the project, particularly to external hires who may not be as familiar with the strengths and weaknesses of the organization’s previous projects.

The staffing plan is determined by the different phases of the project. Team members who are utilized in the early or conceptual phases of the project are often not needed during the later phases, such as project closeout. Each phase has staffing requirements; the staffing of a complex project requires detailed planning to have the right skills, at the right place, and at the right time.

Project team members may be acquired from outside the organization. This occurs when specific expertise is required on a project that the organization lacks internally. Alternatively, it may be necessary to temporarily replace internal staff with the required project expertise with temporary resources to perform their day-to-day function while assigned to the project. These temporary resources may have been sourced from agencies specializing in temporary staffing. Many projects use a combination of these staffing options.

Resource Planning

Each task in the task list must have resources assigned to it. Before resources can be assigned, their availability has to be determined. Many resources, such as external consultants and training rooms, have to be scheduled in advance, and they may only be available at certain times. This is important to know during planning. Project leaders need to match their resource requirements with the resource’s availability. This often involves negotiation with functional managers. As is the case with the larger discipline of project management, there are software applications that simplify the management of project resources.

5.4 Schedule management

Developing and managing a project schedule that will deliver on the timeline objectives is the primary responsibility of the project leader. Effective schedule management is integral to overall project success. The objective is to create a schedule that effectively and efficiently uses allocated resources to complete the project in the shortest amount of time possible.

Schedules must be communicated to project stakeholders. Generally speaking, stakeholders want to know when the work will be completed. A technique called the critical path is used to determine the earliest date by which a project or iteration can be completed. Once the completion date is determined, it is important to confirm whether this date is able to meet the expectations of the project sponsor (and appropriate designates). Once timeline commitments have been made, stakeholders must be kept up to date on any delays that will cause deviation from the agreed-upon schedule.

If the project sponsor requires completion sooner than initially determined by the schedule, the team will identify what can be done to bring the completion date in line with stakeholder expectations. Many options are available and the brainstorming begins by examining the tasks on the critical path. Everything from changing resource assignments to completing more tasks in parallel is discussed.

If the schedule indicates that the project will be completed sooner than expected, this creates additional contingency (a buffer) and increases the likelihood that the overall project will be delivered on time. We will explore the critical path in greater detail in the section below.

Defining Tasks

Detailed planning begins by identifying all the tasks to be completed. The project team begins by reviewing the scope of the project which is found in the project scope statement (predictive projects) or in the product backlog (agile projects). A work breakdown structure (WBS) allows the team to have a visual representation of the forthcoming work. As discussed in the scope management section, the WBS is a powerful planning tool. By breaking the project down into smaller, more manageable components, the WBS assists work package leaders (predictive methodology) and scrum masters (adaptive methodologies) in identifying the specific tasks. The team then determines how long it will take to complete the required tasks.

Sequencing is important. Sequencing defines the order in which tasks must be completed. Network diagrams can be used to determine the sequencing of tasks. Network diagrams are similar to flow charts in that they graphically depict which tasks must be completed before other tasks can begin and which tasks can be done in parallel. Some teams chose to create these diagrams by using software such as Microsoft Project. In smaller, simpler projects, brainstorming the sequence of tasks can be done using digital whiteboards or with sticky notes.

If an organization maintains a project repository, it may offer examples of task lists, how tasks were sequenced in past similar projects, and task duration estimates. When a project repository is not available, expert judgement may be used. Expert judgment draws on the knowledge of project team members with prior experience in developing an activity list using a WBS. One approach could be to draft a task list which is then reviewed by the expert(s) who may suggest improvements. Alternatively, depending on available resources, the expert(s) can be involved in creating the first draft of the activity list.

Once the work package leader(s) or scrum master have developed a schedule for the work they are accountable for, it is given to the project leader, who then develops an integrated schedule for the whole project.

A Case Study: “John’s Move”

Schedule development involves a lot of new terms and concepts. In order to effectively illustrate the use of these terms and concepts, a simple example from everyday life has been selected.  The example involves moving from one city to another.  The simplicity of this example is intended to make it easier to learn new concepts.  In addition, a physical move is something that many students are familiar with and the familiarity should further support the learning process.  It is important to note that a project of this size would typically not require all the tools and techniques described in the following examples.  

***

John Karpuk has a small, but important, project. Currently living in Chicago, he has accepted a job in Atlanta and must be there, ready to work, in the new year. If the furniture arrives in good condition at least 2 days before John begins his new job, and the move costs less than $5,000, the project will be a success. John’s move to Chicago 5 years ago cost $5,000. John is hoping to be able to move to Atlanta for less than $5,000 by leveraging his experience and his friends. Since the end outcome of this project is well-known and easy to define, the predictive (waterfall) development methodology will be used.

John created a simple project charter and scope statement. He shared these documents with his friends. He began developing a WBS by identifying all the deliverables to be produced during this project.

In John’s move project, these top-level deliverables are numbered 1, 2, 3, and so on. As shown below, creating a plan for the move is the first major deliverable.

Top-Level Deliverables in Move Planning

  1. Plan move
  2. Pre-packing
  3. Packing
  4. Moving
  5. Unpacking
  6. Project closeout

The WBS is then decomposed, or broken down into smaller sub deliverables. The 1.1, 1.2, and 1.3 numbers are the first subdivision of the work. For example, one of John’s major deliverables is packing (3.0). Although the packing of delicate items will occur in 2.0 (pre-packing), 3.3 is the major apartment packing and includes the coordination and support of labour (friends Dion Demitre and Carlita Stone). The deliverable is then broken down to create the next level by listing the individual rooms that need to be packed, as shown below.

Major Deliverable Decomposed into Smaller Activities

3. Packing

  • 3.1. Confirm Dion’s and Carlita’s help
  • 3.2. Pick up donuts and coffee
  • 3.3. Pack apartment
    • 3.3.1. Pack kitchen
    • 3.3.2. Pack living room
    • 3.3.3. Pack bedroom
      • 3.3.3.1 Pack closet
      • 3.3.3.2 Pack drawers
      • 3.3.3.3 Pack blankets
    • 3.3.4. Pack remaining items

The WBS could be decomposed further to a greater level of detail by listing the activities required for each sub-deliverable, as seen above for the sub-deliverable 3.3.3. Pack bedroom.

This type of numbering of the activities is called intelligent numbering. In intelligent numbering, the numbering system has meaning in a way that a member of the project team knows something about the activity based on its associated number. For example, any activity associated with packing begins with a 3; even picking up donuts can be an activity that supports the completion of this major deliverable.

The WBS is developed or decomposed to the level required by the project leader in order for the project to be effectively managed and controlled. Typically, larger, more complex projects require a more detailed WBS.

In this example, the project schedule may be just as effective without detailing the packing of individual rooms in John’s Chicago apartment. If these items were to be deleted, would John know when he needed to pack each one of these rooms? If the answer is yes, then his WBS may not require that level of detail.

Estimating the Resources

The goal of activity resource estimating is to assign resources to each activity in the activity list. There are four tools and techniques for estimating activity resources.

Expert judgment is when input is requested from experts, especially ones who have previously participated in similar projects, on the required resources.

Alternative analysis is when several different options and possibilities for how you assign resources are considered and examined, such as adjusting the number of resources as well as the kind of resources utilized; oftentimes, there is more than one way to accomplish an activity.

Published estimating data is when project leaders collect and analyze data from articles, books, journals, and periodicals, as well as other people’s projects, to aid in more accurate resource estimation. This is a very useful tool for project leaders because published data is abundant and field-specific.

Project management software is when project leaders employ the use of programs, such as Microsoft Project, to estimate resource needs and constraints, and find the best combination of assignments for the project.

Estimating Activity Durations

There are two fundamentally different ways to estimate – top-down and bottom-up.

In the top-down approach, high-level estimates are created. 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 durations from similar projects and applying the same proportions to the current project.
  2. Expert judgement – settling on a high-level estimate for overall project duration based on input from experts who have previously participated in similar projects.
  3. Ratio method – identifying and applying significant determining factor(s) to estimate the project’s overall duration.
    • For instance, a website development project could estimate the project duration based on the number of web pages to be developed and the approximate time to be spent per page. Assume the project is the development of a 20-page website and it is determined that one webpage takes five days to create; the estimated project duration would be 100 days.

Given the popularity of the apportion method, let us examine how this is done in greater detail. We begin the planning work by looking for examples of similar projects that have been completed in the recent past. Assume we found a project meeting our criteria and discovered it took one year to complete. An estimate of one year could be used on the current project. This estimate can then be broken down into high-level estimates for each major deliverable and sub-deliverable. The project team would allocate a similar percentage of the overall project duration to each major deliverable and sub-deliverable based on the historical information. For instance, assuming that the previous one-year project had three major deliverables that took 25%, 50% and 25% of the project’s total duration, the current project’s major deliverables would receive the same percentage allocation of time. This is demonstrated in the figure below.

Exhibit 5.2: Apportion method

Top-down estimating is simple and inexpensive. Because of this, it is often used at the project selection stage and for small internal projects.

In contrast, bottom-up estimating is a technique that estimates project duration at the task level.

Once activity resource estimating is complete, it is possible to estimate how long each task will take. With this approach, estimating the duration of a task is based on the information available about that specific task and the resources that have been assigned to it.

Bottom-up estimating occurs when accuracy is a higher priority, for example, if project stakeholders have an inflexible launch deadline. This approach takes a considerable amount of time to perform and tends to produce estimates that are +/- 30% accurate.

Some of the common methods for creating a bottom-up estimate of project duration include:

  • WBS method – producing an estimate of the work package’s or iteration’s duration based on duration estimates of the tasks within each work package or iteration. These summary estimates are then rolled up to the major deliverable or capability level in order to produce an estimate for the project as a whole.
  • Parametric estimating – entering data about the project into a formula, spreadsheet, or computer program that produces a duration estimate by extrapolating information from a database of actual durations from past projects.
  • Three-point estimates – basing duration estimates on three scenarios: a realistic estimate (most likely to occur), an optimistic estimate (best-case scenario), and a pessimistic estimate (worst-case scenario). The final duration estimate is the average of the three.

The unit of duration is typically working days but could include other units of time, such as hours, weeks, or months. The unit is chosen by understanding the level of detail needed to effectively manage the complexity of the project and must be used consistently throughout the schedule.

It is imperative to distinguish between effort and duration. Effort is the time required to complete a task. It only includes the time spent on the task. Wait time, often associated with the time it takes to receive an approval, is part of duration but not effort. For instance, it may take John two hours to put his clothes in boxes, but his friends may not be able to assist him with moving these boxes to a central room for loading until the following day. Assuming it takes his friends 15 minutes to move his boxes to the central location, the duration of “pack bedroom” is two days while the effort is two hours and 15 minutes. Duration is used for scheduling purposes. Effort is used for budgeting in order to track labour costs.

A final consideration is the factors that impact estimate accuracy. In top-down estimating, the estimates are inaccurate and this is appropriate for the circumstances. In bottom-up estimating, an attempt is made to produce an accurate estimate, but a number of factors can impede this. Clifford Gray and Erik Larson (2021)2 identified seven factors that impact estimate accuracy. They are:

  1. Planning horizon – tasks to be completed in the distant future are more difficult to estimate accurately as the future can be very unpredictable.
  2. Project complexity – the more complex the work, the harder it is to create accurate estimates.
  3. People – the skill and experience levels of the people creating the estimates will have a big impact on estimate accuracy.
    1. If the individuals involved have skills and experiences from similar past projects, they are likely to produce estimates with a higher degree of accuracy.
  4. Project structure – dedicated team structures tend to produce the most accurate estimates, assuming the team members have the required skills and experience.
    • Since project team members in functional environments must balance the needs of the project and their day-to-day work, it often is more difficult to find the time and focus required to produce accurate estimates.
  5. Human tendency to pad – it is human nature to overestimate time and costs in order to increase the likelihood of being successful. If this is common practice throughout the organization, estimate quality will suffer as a result of actual duration and cost being significantly overstated by team members.
    • A better approach is to add contingencies at the project level and base these contingencies on the degree of risk associated with the change initiative.
  6. Organizational culture – the value placed on accuracy has a big impact on the level of accuracy provided.
    • In some cultures, accuracy is not viewed as worthwhile (causing estimates to be high-level) and in others, it is seen as an important way of doing business (causing estimates to be meticulously calculated).
  7. Other non-specific project factors – many factors are difficult to estimate. For instance, equipment downtime and staff illness are generally not very predictable. Vacation periods are generally more predictable and should be considered for duration estimates.

Resource Allocation and Calendars

A common resource constraint is availability. To consider the availability of team members, consultants, and key pieces of equipment, a resource calendar that indicates each resource’s availability may be created. Sometimes, in lieu of a resource calendar, a company calendar may be used to track working days, weekend days, and holidays for team members within the company. Additionally, each team member may have their own individual calendar that shows any vacation or personal days they have booked off. If major pieces of equipment are only available for certain periods of time, they can be given their own resource calendar. Resource calendars are important tools for making schedule adjustments. When a resource calendar is applied to a duration estimate, the duration in days is distributed across the available calendar days. For example, if the duration of an activity is three days and the start date is Thursday, the activity would begin on Thursday and end on Monday of the following week, assuming the resource calendar indicates that the individuals assigned to this activity have the weekend off. If the weekend included an extra day off for a holiday such as Labour Day (Exhibit 5.3), the completion day of the same three-day activity would be pushed to Tuesday.

Exhibit 5.3: An example of a resource calendar for John’s move.

Resource Leveling

Resource levelling is a tool for examining the unbalanced use of resources (usually people or equipment) over time and resolving over-allocations and/or conflicts.

When performing project planning activities, the project leader will attempt to schedule certain tasks simultaneously. When resources, such as people or equipment, are needed more than they are available, or perhaps a specific person is necessary for numerous tasks, the tasks will have to be rescheduled sequentially to manage the resource constraint. Resource levelling can also be used to balance the workload of primary resources over the course of the project. When this occurs, it often impacts the project’s overall timeline, budget, and/or scope (the triple constraints).

When using specially designed project software, such as MS Project, levelling typically means resolving conflicts or over-allocation in the project schedule by allowing the software to automatically schedule the to-be-completed tasks as resources become available. Project management software levelling requires tasks to be delayed until the necessary resources are made available. In more complex environments, resources may be allocated across multiple, concurrent projects, thus requiring the process of resource levelling to be performed at the company level. Resource levelling could result in a later project completion date if the tasks affected are on the critical path.

Task Sequencing

It is important to determine the relationship of an activity to other activities. Sometimes, certain activities must begin before others can commence. Understanding the order in which activities need to be completed is an important step in building a realistic schedule. Sequencing involves determining the predecessors (activities that come before) and successors (the activities that come after). These terms describe a relationship similar to a family relationship, such as a parent and child. The parent exists in time before the child. However, oftentimes, a schedule has much more complex predecessor-successor relationships, just like families are composed of several generations. Additionally, activities can have more than one predecessor, just like a child may have a parent and a step-parent.

The relationship between a predecessor activity and a successor activity is called a dependency. Since the successor activity starts after, it is dependent on the predecessor activity. In the context of our case study, since a conversation with Dion and Carlita must take place before a meeting can be scheduled, the meeting has a natural dependency on it because it can only occur once the predecessor has been completed. Activities with predecessor-successor relationships occur sequentially—one after the other. Another term for this type of relationship is finish-start, which means the first activity must finish before the next one can start.

Some activities take place concurrently—at the same time. Concurrent activities must be scheduled to start or finish at the same time depending on their nature. If they must start at the same time, they have a start-start relationship. If the activities can start at different times but they must finish at the same time, they have a finish-finish relationship.

Before we examine the sequencing of John’s move, let us review the exhibit below.

Exhibit 5.4: The work breakdown structure for John’s project illustrating the major deliverables and underlying activities.

Sequencing for John’s Move

In our case study of John’s move, “Contacting Dion and Carlita” (Activity 1.1) comes before the lunch meeting is scheduled. You must logically contact Dion and Carlita before you schedule  “Planning Lunch” (Activity 1.2). As a reminder, all activities that begin with the same number (e.g. 1) are part of the same major deliverable (e.g. “Plan Move”). Your conversation with Dion and Carlita will provide you with their availability and confirm their commitment to helping John move. Therefore, the conversation with Dion and Carlita is a predecessor to the Planning Lunch. This relationship is diagramed below.

Exhibit 5.5: Relationship between two activities, displaying the dependency (finish-start) of the successor on the predecessor.

Predecessor Relationships in John’s Move

The WBS excerpt below shows the activities in John’s move with the predecessors identified in bold for the Plan Move and Pre-packing groups of activities. Because the finish-start relationship is by far the most common, the type of relationship is assumed to be finish-start unless otherwise mentioned.

Outline of Activities in John’s Move with Predecessors Identified

1. Plan Move

  • 1.1 Contact Dion and Carlita
  • 1.2 Host planning lunch (1.1)
  • 1.3 Develop and distribute  move schedule (1.2)
  • 1.4 Make hotel arrangements in Atlanta (1.1)

2. Pre-packing

  • 2.1 Gather packing material
  • 2.2 Select moving van company and sign contract
    • 2.2.1 Contact three moving van companies and get bids (1.3)
    • 2.2.2 Select company and negotiate a final price (2.2.1)
    • 2.2.3 Sign moving contract (2.2.2)
  • 2.3 Pack small delicate items (2.1)

Network Diagrams

Many people recognize relationships and patterns more effectively when they look at diagrams like the one in Exhibit 5.6. The precedence diagram method (PDM) is a technique for graphically displaying the sequence logic of a schedule by placing the activities in boxes with arrows between them to illustrate the predecessor-successor relationships. The boxes in this type of diagram are called nodes and the arrows indicate finish-start relationships. The network diagram below portrays the predecessor-successor relationships for John’s move. It becomes much easier to trace a sequential path from one task to the next in the precedence diagram.

Exhibit 5.6: Precedence diagram method illustrating the sequence between sub-deliverables.

Lag and Lead Times

Most tasks have a finish-start relationship. If a certain amount of time must pass before a successor task can begin, the required delay is called lag time. For example, concrete does not reach its full strength for several days after it is poured. As shown in Exhibit 5.7, lag time is required between the end of the pouring process and the beginning of future construction which requires the concrete to be fully hardened. Similarly, we often have to allow lag time for cheques to be processed by the banking system before we can spend the money.

 Exhibit 5.7: The time required to allow the concrete to rest before further construction can begin is considered to be lag time.

In some cases, the successor task can overlap the end of its predecessor task and begin before the predecessor is finished. This is called lead time.

Lead Time in John’s Move

In John’s move, he could begin packing the small and/or delicate items before he obtains the packing materials. John would do this by setting these items aside. When John gathers the packing materials (sub-deliverable 2.1), sub-deliverable 2.3 is already partially completed. Assuming it took John one day to set the small and/or delicate items aside, he would have shortened the time it takes to pack these items by one day.

Exhibit 5.8: Overlap is called the lead time of the successor tasks.

As shown in a partial table of tasks in Exhibit 5.8, at this point in the process of analyzing John’s move, each task has an identifying code, a short description, predecessors, and lead or lag times. The characteristics and identifiers of a task are called its attributes.

This information is easily displayed in scheduling software such as MS Project.

Exhibit 5.9: Table of attributes (accessible version)

Milestones

Milestones are significant events in a project. In some cases, milestones represent major constraints in a schedule. An example of a scheduling constraint is the need to have a government contract signed before a specific time period in order to be eligible for the associated funding. Even though milestone events are significant to the project, they consume no resources and have no duration. Milestones are usually indicated on the project schedule with a diamond (see Project Plan Image 1).

Milestones in John’s Move

In John’s move project, we might create a milestone called “Accept job offer in Atlanta” to represent the date when John begins to plan his move.  Any delay in this date will mean a delay to the start of the project, which causes a delay in all the other downstream activities.

Project Plan Image 1: Gantt chart depicting milestones in John’s move. John’s move is scheduled to begin on May 6th and will last 14 days.

Graphic Representations: Gantt Charts

Relationships between activities are easier to recognize if they are presented using graphics, such as bar charts or a network of connected boxes.

The type of bar chart used to illustrate task relationships is the Gantt chart. The Gantt chart was developed by Henry Gantt and has been used on major projects, including building the Hoover Dam and the U.S. interstate highway system. The Gantt chart, also called a bar chart, is a time-scaled graphic representing each task with a bar that reflects its duration, start, and finish time, as was also shown in Exhibit 5.3.

Critical Path and Float

The critical path is the longest series of activities that results in the earliest completion date of the project, phase, or iteration. In order to identify the critical path, the duration of each activity must be calculated.

If any activity on the critical path is delayed, the completion date of the project, phase, or iteration will be delayed by an equal amount. It is important to note that the critical path contains the tasks with the greatest total duration and the least amount of slack. To determine the critical path, add the duration of each successor activity to the duration of the previous activity to determine which series of activities has the longest total duration, as shown below in Exhibit 5.10. In this example, durations are indicated in days (d) and tasks on the critical path appear in red. The critical path through these tasks will take at least eight days.  Notice the project duration in the Gantt chart depicted above is also eight days as it is driven by the critical path.

Exhibit 5.10: The critical path is the longest sequence of tasks.

When the team has identified the project’s critical path, they can carefully monitor the tasks that, if individually delayed, could lead to delays in the project’s completion date.  These tasks will receive the needed resources and support to ensure they stay on track as much as possible due to their role within the critical path.

Float, sometimes called slack, is the amount of time a task, network path, or phase/iteration/project can be delayed from the early start without changing the completion date of its successor task(s) or phase/iteration/project.

Total Float

Total float is the difference between the finish date of the last task on the critical path and the date stakeholders expect the project to be completed. Any delay in a task on the critical path would reduce the amount of total float available for the release/iteration/project. It is also possible to have a negative float. This occurs when the calculated completion date of the last task on the critical path is later than the expected completion date established and communicated to the stakeholders at the beginning of the project.

Total Float in John’s Move

In John’s move project, the last task on the critical path is 5.4 (unpack and assemble items). Once this is completed, John will be ready to begin his new job since he has effectively settled into his new apartment. Task 5.4 will be completed on May 25, 2021. Since John does not have to start work until June 1, 2021, his move project has a total float of six days. This float serves as a buffer. If a task on the critical path is delayed by a few days, John will still be ready to begin his new job on time.

Project Plan Image 2: Gantt chart depicting total float in John’s move.

Ongoing Schedule Management

As previously mentioned, the schedule should be approved and signed off by key stakeholders. The functional managers who have been asked to provide subject matter experts to participate in the project are particularly important. Giving functional managers the project schedule ensures that they have read the schedule, understand the dates and resource commitments, and will be supportive of the project’s resource needs. The schedule cannot be finalized until the project leader receives approval and commitment for the resource assignments outlined in it. Once the schedule is approved, it becomes the baseline for the remainder of the project, phase, or iteration. Progress and task completion will be monitored and tracked against the project schedule to determine if the project as a whole is staying on course as planned.

Another key aspect of ongoing schedule management and monitoring is duration estimates. Baseline schedules often change after they have been approved. Successful project leaders understand that estimates are just that – estimates. As new information and real experience occur, it may be necessary to revise an estimate. In some cases, the revision is minor and does not impact the achievement of any of the milestones or the project’s completion date. In other instances, the necessary revisions may be significant, leading to the calculation of a new baseline. It is important for project leaders to discuss the ongoing schedule management with key stakeholders to understand their expectations of when/how they want to be informed of any necessary changes. Very higher-complexity projects may document stakeholders’ expectations for ongoing schedule management in a formal schedule management plan. On lower-complexity projects, stakeholder expectations regarding schedule communication can be documented in the stakeholder register.

There are two key schedule compression techniques that can be used when teams discover they are running behind schedule. One technique is called crashing. This involves adding more resources to critical path tasks or reassigning resources from non-critical path tasks as a way to create more focus on critical path tasks. The goal is to realign the schedule with commitments and stakeholder expectations. Crashing can be very expensive and it does not always work. If the budget is limited, this is not an effective technique.

The other technique is called fast-tracking. Sometimes the project team realizes that two tasks, which were originally planned to occur sequentially (e.g., finish-start), can occur concurrently (e.g. start-start, finish-finish). However, this can be risky to implement as there is a possibility that some of the work will have to be redone if issues are discovered. These issues may have been easily identifiable if the tasks occurred sequentially as initially planned.

5.5 Cost Management

One of the components of project success is completing the project within budget. Developing and controlling 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 in time. On other projects, for example, ones with limited funding available, remaining within budget is the highest priority. When this is the case, effective cost management is imperative and trade-offs with scope, quality, and/or time may be required.

During the project selection phase, the information needed to develop an accurate and detailed budget is often unknown. As a result, a rough order of magnitude (ROM) is developed using the information available at the time. Expert knowledge and/or past experience are often used to develop the ROM estimate. When using past experience, estimates from previous projects are often scaled to match the size and complexity of the current project. Although the ROM is not accurate due to insufficient information, it does help the organization determine if the project should be approved.

During the initiation phase, more information may be available, allowing the newly assigned project leader to refine the ROM from the previous phase. In some instances, however, the project’s end solution cannot be clearly defined at this point and, therefore, the cost estimates remain vaguely defined.

As the project moves into the planning phase, the development methodology is selected and this determines how the project budget is created. When the solution cannot be clearly defined upfront, this often leads to the use of an adaptive development methodology, such as agile, which accepts a loosely defined ROM since the focus is on the cost of the iterations (sprints) as a way of refining the total cost of the entire project. Additionally, it takes time to fully understand the end users’ expectations, so project leaders are often careful to not commit to a project budget until more is known about the end solution. Project leaders also must ensure that the budget is developed collaboratively with the product owner(s) and the scrum master(s). The cost estimates for the product backlog are ultimately integrated with the cost of each iteration, leading to the creation of a detailed project budget.  As previously mentioned, when the predictive (waterfall) development methodology is used, the project’s end outcome is clear and can be defined upfront. The outcome can be broken down into smaller work packages. Then, the work package leaders estimate the cost of their work. Lastly, the cost of all work packages is integrated to create the detailed project budget.

Once the project cost has been estimated, the actual cost of executing the required work is tracked and compared to the approved estimates. This tracking is done during the monitoring and control phase of the project (covered in Chapter 7). If the actual costs are significantly higher or lower, the project team explores reasons for the difference and takes appropriate action to successfully manage future 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 variance between actual versus planned project costs (due to consistent over- or underestimating), future estimates are revised and corrective action may be required.

Effective project leaders understand the importance of revising cost estimates as new information becomes available. 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. Stakeholders expect to be kept informed of significant changes. Most organizations require project leaders to obtain approval for changes to the existing project estimates. In very large complex projects, a cost management plan, which identifies who will provide approval, will be created through conversation with the appropriate stakeholders. The project leader will use this plan to guide their efforts around when and how to communicate changes to project costs. 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.

Types of Project Costs

There are generally three different types of project costs:

  1. Direct costs
  2. Direct overhead costs
  3. General administrative costs

The primary difference between these costs is how closely related they are to the specific activities of the project.

Direct costs are, as the name implies, directly related to specific project tasks. These costs represent the labour, time, and materials associated with specific tasks.

Direct overhead costs are incurred as a result of the project’s existence, but they are not directly related to specific tasks. These costs represent the compensation paid to individuals who are supporting the project in its entirety, such as the project leader and their support staff (project analysts, coordinators, etc.). These costs also represent materials, facilities, and related equipment that were purchased to support the project in general. The rental and maintenance of workspace for the project team members, as well as their computers and related information technology, supplies, and lunch (if provided), are all examples of direct overhead costs.

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 marketing, human resources, and accounting department-related expenses. 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 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. Since the allocation methods are often very subjective, many organizations exclude general administrative costs from the project budget. The time it takes to come to a consensus about the proposed subjective estimates may not be worth the benefit they provide in terms of organizational and project-related decision-making.

It is important to note that some projects require the direct involvement of these administrative functions. This should be clearly identified in the project’s work breakdown structure. For instance, a project that involves the introduction of new technology will alter the way people work and this may require members of the human resources department to re-evaluate existing job descriptions, compensation levels and so forth.  In this instance, the human resources function is a work package and the costs associated with their work are direct costs.

Estimation Techniques

There are two fundamentally different ways to estimate – top-down and bottom-up.

In the top-down approach, high-level estimates are created. 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 s from similar projects and applying the same proportions to the current project.
  2. Expert judgement – consulting with experts who have done similar work before in order to settle 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. Assuming it cost $1,000 to create one web page, a 20-page website project could cost $20,000.

Given the popularity of the apportion method, let’s examine how this is done in greater detail. Assume we found a similar project that was completed in the recent past and it cost $500,000. An estimate of $500,000 could be used for the current project. This estimate can be broken down into high-level estimates for each major deliverable and sub deliverable by using this method. In our example of a similar project with a $500,000 cost, the project team would allocate a similar % of the overall project cost to each major deliverable and sub deliverable based on the historical information. For instance, assuming that the previous project had 2 major deliverables that took 20% of the project’s total duration, 10%, 10%, 40% and 30% respectively, the current project’s major deliverables would receive the same % allocation of time.

Exhibit 5.12: Ratio Method

Top-down estimating is simple and inexpensive. It is often used at the project selection stage and for small internal projects.

In contrast, bottom-up estimating is a technique that is used when accuracy is valued. This is especially the case when project stakeholders place a high priority on the project cost. In these instances, the project may have a fixed budget. This approach takes a considerable amount of time to perform and tends to produce estimates that are +/- 30% accurate.

Some of the common methods for creating a bottom-up estimate of project duration include:

  1. WBS Method – the cost of the tasks within each work package or iteration are estimated and rolled up to produce an estimate for the work package or iteration as a whole. These summary estimates are then rolled up to the major deliverable or capability level in order to produce a cost estimate for the project as a whole.
  2. Parametric estimating – entering data about the project into a formula, spreadsheet, database, or computer program that comes up with an estimate. The software or formula that you use for parametric estimating is based on a database of actual durations from past projects.
  3. Three-point estimates – works with three estimates: a realistic estimate that’s most likely to occur, an optimistic one that represents the best-case scenario, and a pessimistic one that represents the worst-case scenario. The final cost estimate is the average of the three.

It is important to determine the level of detail needed to effectively manage the project. Large, complex projects require more coordination. The level of detail that can be achieved at the beginning of the project will depend on the clarity of the end outcome. In projects with clear outcomes (predictive/waterfall), it is possible to develop detailed estimates from the onset. In projects that do not have clear outcomes (agile), the detailed estimates can only be produced as the user requirements become clear.

Additional considerations:

  • Labour costs: The people who will be working on the project are often also the largest cost component of it. Taking the time to estimate the labour rates is important and may require market analysis.
  • Vendor bid analysis: Sometimes external organizations are required on the project. The project may send out RFQs (Request for Quotations) or RFPs (Request for Proposals). RFQs are used when the project team knows the required solution but is unable to provide it internally. RFPs are used when the project team does not know the required solution and requests proposals from organizations with relevant expertise. In both instances, the bids must be analyzed and evaluated in order to determine which is best for the project.
  • Cost of quality: Many project teams overlook the costs associated with the quality-related tasks for a project. This includes measures to error-proof solutions, create checklists, and inspect deliverables before they are presented to stakeholders for review and sign-off. Since it is cheaper to identify flaws earlier than later in the project, there are always quality costs associated with everything a project produces. Cost of quality is a way of tracking the cost of those tasks. It is the amount of money it takes to assure that the project is executed efficiently.
  • Reserve analysis: It is important to set aside some money for cost overruns. Higher-risk projects require more reserve than lower-risk projects. The reserve is intended to assist the project team with managing risks by putting mitigating strategies in place.

There are two types of reserves:

  • Contingency reserves are funds set aside to manage the identified risks. Because there is a chance that these funds will be required, the contingency reserve is incorporated into the project budget. If this fund is adequate to meet the project’s unplanned expenses, then the project will be complete within the budget.
  • 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 reserves, 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.

Estimates can change over time and it is important to consider new information as it becomes available. In addition, it is also important to document the assumptions you make and the source of the supporting information used to make the assumptions. This makes it easier to analyze variances and revise projections as needed.

Apportion Estimate for John’s move

John sold his apartment and purchased another one. It is now time to plan for the move. John asked a friend for advice about the cost of his move. His friend replied, “I moved from an apartment a little smaller than yours last year and the distance was about the same. I did it with a 14-foot truck. It cost about $600.It was $360 (60% of total costs) for the truck rental, $150 (25%) for the gas, $60 (about 10%) for the hand truck, $12 (2%) for the pads, $12 (2%) for the boxes, and $6 (1%) for the rope.”

Because of the similarity of the two projects, John set his initial estimate at $700 to account for rising gas prices and apportioned the costs accordingly.

Exhibit 5.13: John’s move is estimated to be $700, which includes $426 for the truck rental, $183 for the gas, $61 for the hand truck, $12 for the pads, $12 for the boxes, and $6 for the rope.

This high-level estimate was sufficient for John to secure the funds needed to pay for his move.

Parametric Estimate for John’s move

If the project consists of tasks that are common to many other projects, average costs are available per unit. For example, if you ask a construction company how much it would cost to build a standard office building, the estimator will ask for the size of the building in square feet and the city in which the building will be built. From these two factors—size and location—the company’s estimator can predict the cost of the building. Factors such as size and location are parameters—measurable factors that can be used in an equation to calculate a result. The estimator knows the average cost per square foot of a typical office building and the required adjustments for local labour costs. Other parameters, such as the quality of finishes, are used to further refine the estimate. Parametric estimates are calculated by multiplying measured parameters by cost-per-unit values.

To estimate the required truck size for John’s move, the parameter used by a truck rental company is the number of bedrooms (as shown in Exhibit 5.14). The company assumes that the number of bedrooms is an important parameter in determining how big a truck is needed for a move. John has a one-bedroom apartment, so he chooses the 14-foot truck. Once the size is determined, other parameters, such as distance and days, are used to estimate the cost of the truck rental.

Exhibit 5.14: Parametric cost estimate used by U-Haul when renting a moving truck.

Bottom-up estimate for John’s move

After evaluating the bids by the moving companies, John decides that the savings are worth his time if he can get the packing done with the help of his friends. He decides to prepare a detailed estimate of costs (Exhibit 5.15) for packing materials and the use of a rental truck. He looks up the prices for packing materials and truck rental costs on company websites to prepare a detailed list of items, quantities, and costs.

This type of estimate is typically more accurate than the apportion or parametric methods. In this example, the sum of packing materials and truck expenses is estimated to be $661.25.

The estimate can be rolled up, or subtotaled, to display less detail. This process is made easier using computer software. On projects with low complexity, the cost estimates can be done on spreadsheet software. On high complexity projects, software, such as MS Project, is able to manage schedules as well as costs, which then can be sorted by activity and category.

Category Description Activity Quantity Unit Price Cost
Packing Materials Small Boxes 2.1 10 $1.70 $17.00
Packing Materials Medium Boxes 2.1 15 $2.35 $35.25
Packing Materials Large Boxes 2.1 7 $3.00 $21.00
Packing Materials Extra-Large Boxes 2.1 7 $3.75 $26.25
Packing Materials Short-Hanger Boxes 2.1 3 $7.95 $23.85
Packing Materials Box Tape 2.1 2 $3.85 $7.70
Packing Materials Markers 2.1 2 $1.50 $3.00
Packing Materials Mattress/Spring Bags 2.1 2 $2.95 $5.90
Packing Materials Life Straps per Pair 2.1 1 $24.95 $24.95
Packing Materials Bubble Wrap 2.1 1 $19.95 $19.95
Packing Materials Furniture Pads 2.1 4 $7.95 $31.80
Truck Rental 2.2 $400.00
Truck Gas at 10mpg 2.2 200 $2.25 $45.00
Total Cost $661.25

Exhibit 5.15: Bottom-up cost estimates

Cost Budgeting

The main goal of the cost budgeting process is to produce a cost baseline. This baseline is a time-phased budget that can be used to measure and monitor cost performance after it has been approved by the key project stakeholders. The aggregated budget is integrated with the project schedule in order to produce the time-phased budget. Costs are associated with tasks, and since each task has a start date and a duration period, it is possible to calculate how much money will be spent by any particular date during the project. Recognizing that all the money required to deliver the project is not needed upfront, 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 task without causing a delay in the start of the task. 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.

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 occur, 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. It is important for Project leaders to discuss the ongoing management of the schedule with key stakeholders to understand their expectations of when/how they are informed of changes that need to be made. Very large complex projects may document stakeholders’ expectations for ongoing cost management in a formal Cost Management Plan. In addition, there are a number of tools and techniques that help project leaders monitor and control project budgets.

5.6 Risk and Issue Management

Risks are the uncertainties that exist in all projects. A risk can be positive or negative. Some uncertainties, such as the potential of finding an easier way to do a task and/or lower prices for certain materials, can make it easier to achieve a project’s objectives. When this type of uncertain happens, the risk is positive and is therefore referred to as an opportunity. Examples of negative risks are the potential for technology to fail and/or a vendor missing an important delivery.

The role of the project management team is to understand the types and severity of risks on the project, and then develop and implement plans in response to these risks. The type and severity of risk vary by industry, project complexity, and project phase. The human tolerance for risk varies significantly from one person or organization to another. Due to this, it can be difficult for project team members to reach a consensus on the riskiness of an activity and overall project. Understanding the risk tolerance of a project’s stakeholders is a critical success factor in risk management.

There are four steps in risk management:

  1. Identifying the uncertainties. Some uncertainties are easy to identify, such as the potential for a damaging storm in the Caribbean, while others are less obvious, such as the potential for a project team to experience poor health. Many industries or companies have risk checklists developed from past experience. The value of a checklist is the stimulation of discussion and thought among team members about the potential risks of a particular project.
  2. Assessing each identified risk 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.
  3. Developing risk responses, such as accepting the risk (do nothing to prevent it from happening), eliminating it (change something in the project to avoid its occurrence), transferring it (to a third party by purchasing insurance), or mitigating it (reduce its likelihood and/or impact).
  4. Implementing and monitoring the response. After selecting the appropriate response for a particular risk, the project team must balance the cost of the response against the anticipated benefit for the project. Monitoring is important because new risks emerge and understanding the effectiveness of implemented risk response strategies ensures project risks are effectively managed throughout the project’s lifecycle.

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

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 a number of key sections: risk sources, categories, assessment definitions (e.g. very high to very low), probability/impact assessment (matrix), roles and responsibilities, budget and schedule estimates for risk-related activities, and the risk register. The risk management plan is integrated into the project management plan (or, in the absence of this plan, into the execution approach for the project) and the response strategies are assigned to the appropriate individuals in the organization.

A risk register is a key tool that helps project teams keep track of the status of risks, ensure response plans are effectively implemented, and new risks are managed. The register is often created during the initiation phase of a project’s life and it is maintained throughout the remaining phases

Risk Identification

Since risks are uncertainties, a good place to start in identifying risks is the assumptions that have been made in the project justification document and project charter. Project teams hope the proposed assumptions will materialize, but this is not certain. Often, these assumptions represent significant risks.

Another important method for identifying project risks is the project team itself. The individuals responsible for specific components of the work are in the best position to identify the risks and opportunities associated with the task(s). Risk management should be a standing agenda item during project status meetings

The third source of risk is risk checklists developed from past projects. These checklists can be helpful to the project team in identifying specific risks on the checklist and expanding the thinking of the team. 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.

Risks can also be categorized according to the deliverables of the work breakdown structure (WBS). This is commonly referred to as a risk breakdown structure (RBS).

In John’s move, he makes a list of things that might go wrong with his project by using his work breakdown structure as a guide. A partial list for the planning portion of an RBS is shown below.

Task Risk
 

 

Contact Dion and Carlita

 

•     Dion backs out

•     Carlita backs out

•     No common date available

 

Host planning lunch

 

•     Restaurant full or closed

•     Wring choice of ethnic food

•     Dion or Carlita may have food allergies or preferences

 

Develop and distribute schedule

 

•     Printer out of toner

•     Out of paper

The result is a clearer understanding of where risks are most concentrated. This approach helps the project team identify known risks but it may prevent the team from thinking beyond the list to creatively identify unknown risks that are not easily found inside the WBS.

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/benefit) associated with it. Not all risks are equal. Some risk events are more likely to happen than others and the cost/benefit of a risk can vary greatly. Risk assessment often occurs in a workshop setting.

Having criteria to determine high-impact risks can help narrow the focus on a few critical risks that require responses. For example, suppose high-impact risks are those that could increase the project costs by 5% or more. Similarly, high-probability risk events are those that carry a likelihood of occurrence of 50% or more. Only a few potential risk events are likely to be high-impact and high-probability. These risks become the “critical few” and, therefore, promptly identifying the risks within this category is helpful in deciding early on where the funds and time should be allocated for risk-related activities. See Exhibit 5.16.

Exhibit 5.16: 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 project management team will assign the appropriate resources to the technology managers to ensure the accomplishment of project goals. The more complex the technology, the more resources the technology manager typically needs to meet project goals, and each of those resources could face unexpected problems.

On projects with a low-complexity profile, the project leader may informally track items with risk potential. On more complex projects, the project management team may develop a list of items perceived to be higher risk and track them during project reviews. On projects of even greater complexity, the process for evaluating risk is more formal with risk assessment meetings occurring throughout the project’s lifecycle to assess relevant risks during different project phases. On highly complex projects, an outside expert may be included in the risk assessment process, leading to the risk assessment plan taking a more prominent place in the project implementation plan. In addition, statistical models are sometimes used to evaluate risk because there may be too many possible combinations of risks to calculate them one at a time. One example of the statistical model used on highly complex projects is the Monte Carlo simulation, which simulates a possible range of outcomes by evaluating many different combinations of risks based on their likelihood. The output from a Monte Carlo simulation provides the project team with the probability of a risk event successively occurring with other combinations of risk events. For example, the typical output from a Monte Carlo simulation may indicate a 10% chance that a key piece of equipment will be late and that the weather will be unusually bad upon equipment arrival.

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:

  • Risk avoidance
  • Risk mitigation
  • Risk transfer
  • Risk acceptance

Each of these responses can be an effective tool in reducing individual risks as well as the overall risk profile of the project. The risk response plan captures the risk management approach for each identified risk event and actions the project management team will take to manage the risk.

Risk avoidance usually involves developing an alternative strategy with a higher probability of success, but, usually, the associated cost of task completion also becomes higher. A common risk avoidance technique is using proven and existing technologies rather than adopting new techniques, even though the new techniques may show promise of better performance and/or lower costs. A project team may choose a vendor with a proven track record over a new vendor that is providing significant price incentives to avoid the risk of working with a new vendor. Alternatively, a project team that requires drug testing for team members is practicing risk avoidance by attempting to evade damage done by someone under the influence.

Risk mitigation is a response to a risk that cannot be avoided or if it is unwise to avoid it (due to risk avoidance strategies being too expensive, too time-consuming, etc.). In this case, the project team is attempting to reduce the likelihood and impact of a risk. For instance, assigning highly skilled resources to an activity reduces the likelihood and impact of errors occurring.

Risk transfer is a risk reduction method that shifts the risk from the project to another party. The purchase of insurance on certain items is a risk-transfer method. The risk is transferred from the project to the insurance company. 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.

Risk 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. In some cases, little else can be done about the risk, leading to acceptance being the only feasible option. When this response is chosen, many project leaders have developed a strategy to deal with the risk if it does materialize. This often involves setting aside funds (contingency reserves) in the project budget.

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

Risk 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 in order to ensure the activity finishes early and the bonus is obtained.

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

Risk acceptance involves doing nothing in response to the risk. This acceptance response is a good one when the likelihood and impact of a risk is low.

Project Risk by Phases

Another effective way to manage risks is to consider the project lifecycle. Risk management techniques can vary by project phase. In the simplest of terms, the initiation phase usually involves simply assessing overall project risk by identifying the key risks. During the planning phase, the team is able to identify, assess, and respond to many more risks. During the implementation phase, previously identified response strategies require modification if they have been deemed ineffective or significant new risks emerge. During the closure stage, contractual arrangements related to risk management are terminated and risk management documentation is updated.

Let us look at the core principles of risk management using our case study. We will examine these principles from a phase-by-phase approach

Initiation

Risk is associated with the unknown. More things are unknown at the beginning of a project than at any other phase. When overall project risk is considered in the initiation phase, it is weighed against the potential benefit of the project’s success in order to decide if the project should be chosen.

Risk Identification by Phase in John’s Move

In the initiation phase of his move, John considers the risk of events that could affect the whole project. Since John’s project involves changing jobs as well as changing cities, this project incurs greater risk than if he was just changing jobs or just changing cities

He identifies the following high-impact risks during the initiation phase and rates their likelihood from low to high.

1. His new employer might change his mind and take back the job offer after John has given notice at his old job LOW
2. The current tenants of his new apartment might not move out in time for John to move in by the first day of work at his new job MEDIUM
3. The movers might lose his furniture LOW
4. The movers might be more than a week late delivering his furniture MEDIUM
5. He might get in an accident driving from Chicago to Atlanta and miss his first day of work LOW

John then considers appropriate responses for each of the risks.

  1. During his job hunt, John received more than one offer, so he is confident that he could get another job if this risk occurs, however, he would likely lose the deposit money on the apartment and the mover. He would also lose wages during the time it took to find another job. John’s risk management strategy is to mitigate the risk of his new employer changing his mind by making sure that he keeps his relationship with his new employers cordial and writes to each of them thanking for their consideration in his recent interviews.
  2. In accepting this risk, John checks the market in Atlanta to determine the weekly cost and availability of extended-stay motels.  If this proves to be too expensive, John could try to mitigate the risk. A strategy to reduce the likelihood of this risk occurring would be to ask his new landlord to introduce him to the current tenants in his new apartment. This would allow John to get to know the existing tenants and express his gratitude for a timely move.  Further, John could offer to buy them dinner on their moving day as further incentive to vacate the apartment on time.
  3. John checks the mover’s contract to confirm that they carry insurance against lost items, but they require the customer to provide a detailed list with value estimates and they limit the maximum total value. John decides to pursue the risk transfer approach by going through his apartment with his digital camera and taking pictures of all of his possessions that will be shipped by truck. The pictures provide John with a visual record so he will not have to rely on his memory to make a list. He seals and numbers the boxes so he can tell if a box is missing.
  4. John can accept this risk and use his research on extended-stay motels to arrange for temporary accommodation while he waits for his furniture to arrive. . He checks the moving company’s contract to see if they compensate the owner for late delivery, and he finds that they do not. This means that he would have to cover the cost of temporary accommodations. If John preferred to transfer this risk, he could approach his insurance company to see if coverage is available.
  5. John checks the estimated driving time from Chicago to Atlanta and gets an estimate of 11 hours of driving time. He decides that it would be too risky to attempt to make the drive by himself in one day, especially if he is unable to leave until after the moving truck is packed. John plans to spend one night on the road in a motel to reduce the risk of an accident caused by driving while too tired. John’s overnight stay is an effective risk mitigation strategy.

John concludes that the risks can be effectively managed so he decides to proceed with his new job in a new city.

Planning Phase

Once the project is approved and it moves into the planning phase, additional risks are identified. Moreover, the list of initial risks identified during the initiation phase is considered in greater detail.

Risk Identification in John’s Move

John decides to ask Dion and Carlita for their help during their first planning meeting to identify risks, rate their impact and likelihood, and suggest mitigation plans. They concentrate on the packing phase of the move. They fill out a table of risks, as shown in Table 5.6.3

Legend:

  • RA: Risk avoidance
  • RS: Risk sharing
  • RM: Risk mitigation
  • RT: Risk transfer

Exhibit 5.17: Table denoting response strategies for identified risks (accessible version)

 

Implementation, and Monitoring and Control Phases

As more information becomes available to the team and tasks are performed without loss, the overall project risk typically reduces. As the project progresses, the risk management plan must be updated with new information and risks related to the completed tasks must be checked off.

As the project’s progress is monitored, the need to make changes may arise. Sometimes, these changes occur as a result of risk management strategies that have been pursued in response to newly identified risks. For instance, in order to avoid a failed move when John discovers his rental van is not big enough to carry all his possessions, he could decide to immediately sell or give away some of his furniture, thereby reducing the scope/complexity of his move. In some situations, the project timeline may need to be extended or the project budget may need to be increased (or the timeline/budget may need to be reduced if an opportunity has been discovered!).

Understanding where or when risks occur in a project is important information for managing the project’s contingency funds. Most organizations develop a plan for financing the project from the existing organizational resources, including financing the project through a variety of financial instruments. In most cases, there is a cost to the organization to keep these funds, including the contingency budget, available to the project. As the risks decrease over the length of the project, if the contingency is not been used, then the funds set aside by the organization can be allocated for other purposes.

Closing Phase

During the closing phase, 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. If a risk register was used to track risks and their respective response strategies, a final update should be composed in order to ensure the register can be shared with and easily understood by future project teams in order to improve their likelihood of success. Similarly, identifying how much of the contingency funds were required is an important project closure step. This allows future teams to understand how much funds they may have to set aside to manage similar risks on their projects. Lastly, if a Monte Carlo simulation was done, the predicted result can be compared to the realized result.

To close out the risk management plan for his move, John examines the risks he identified and the associated response strategies he developed. He adds a column to his risk register to identify the closeout activities he has to perform.

Exhibit 5.18: Table denoting closeout activities associated with risk response strategies (accessible version)

Risk is not allocated evenly over the life of the project. On projects with a high degree of new technology, the majority of the risks may be in the early phases of the project. On projects with a large equipment budget, the majority of the risks may be during the procurement of the equipment. On global projects with a large amount of political risk, the majority of the risks may be toward the implementation and closure of the project.

Contingency Plan

Contingency funds are set aside by the project team to address unforeseen events that cause an increase in project costs. Projects with a high-risk profile will typically have a large contingency budget. The amount of contingency allocated in the project budget is often a function of the risks identified in the risk analysis process. It is possible to allocate contingency to specific activities. However, contingency can also be managed as a “one-line item” in the project budget when risks are difficult to assign to specific activities.

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.20 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.21: 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.22: 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.24: 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.25: Communications plan template
Inte5160, Wikispaces


References

Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide) (6th ed., p. 61). Project Management Institute.

Larson, E. W., & Gray, C. (2021). Project management: The managerial process. (8th ed.). McGraw Hill Education.

License

Icon for the Creative Commons Attribution-NonCommercial 4.0 International License

Project Management Fundamentals Copyright © 2021 by Shelly Morris is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License, except where otherwise noted.

Share This Book