Delivering Value with Project Management

© 2023 CC-BY-SA-NC

Juanita M. Woods, Ph.D., PMP, PgMP

R. Scott Marshall, PMP

Louisa Schlesiger

Table of Contents

1 Introduction to Project Management 10

1.1 What is a Project? 11

1.2 What is Project Management? 18

1.3 Project Management Roles 22

1.4 The Project Manager 25

2 Projects and Organizational Strategy 35

2.1 Value Creation and Strategic Alignment 36

2.2 Organizational Structures 38

2.3 Project Governance 46

3 Approaches to Delivering Project Outcomes 50

3.1 Project Management in Multiple Contexts 51

3.2 Development Approaches 52

3.3 Project life Cycles 56

3.4 Aligning Approach, Cadence, and Life Cycle 58

3.5 Delivering Value Throughout the Project Life Cycle 61

4 Identifying and Selecting Projects 64

4.1 Aligning Projects with Strategy 65

4.2 Types of Projects 66

4.3 Cost of Projects 67

4.4 Selecting Projects 69

5 Chartering Projects 77

5.1 Defining the Project 77

5.2 The Project Charter 78

5.3 Ensuring Business Needs are Met 83

5.4 Project Communications 84

6 Working with Project Stakeholders 93

6.1 Identifying Project Stakeholders 93

6.2 Managing Project Stakeholders 99

7 Identifying Project Outcomes 104

7.1 An Overview of Project Planning 105

7.2 Identifying Project Scope 106

7.3 Project Requirements 113

8 Scheduling Project Work 120

8.1 Identifying Activities 120

8.2 Estimating Activity Duration and Effort 122

8.3 Assigning Project Resources 123

8.4 Mapping Relationships Between Activities 124

8.5 Building Quality into the Schedule 128

8.6 Creating A Project Schedule 129

8.7 Optimizing The Project Plan 133

9 Budgeting Projects 138

9.1 Estimating Project Costs 138

9.2 Developing the Baseline Budget 142

10 Documenting the Project Plan 145

10.1 Documenting The Project Management Plan 145

10.2 Moving From Planning to Producing 154

11 Managing and Measuring Project Work 155

11.1 Managing Changes to Scope, Schedule, and Budget 155

11.2 Managing Project Resources 157

11.3 Managing Stakeholder Expectations 157

11.4 Implementing Risk Responses 158

11.5 Conflict Management and Negotiation 158

11.6 Ensuring and Controlling Quality 163

11.7 Managing Project Learning and Knowledge 166

12 Working with Project Teams 167

12.1 Leading Project Teams 167

12.2 Leading Without Authority 172

12.3 Developing High-Performing Project Teams 179

13 Monitoring and Reporting Project Status 184

13.1 Earned Value Analysis 184

13.2 Communicating Project Status 192

14 Closing Projects 195

14.1 The Closing Stage Processes 195

14.2 Post-Project Work 200

15 Your Next Steps in Project Management 202

15.1 Starting your Career in Project Management 202

16 Appendix 204

16.1 Index 204

16.2 End Notes 207

Table of Figures

Figure 1.1 Kimberly Wynn White, MSEE, CSM 11

Figure 1.2 Building a house is a project. 12

Figure 1.3 Questions to Distinguish Projects from Operations 13

Figure 1.4 Summary of Project Characteristics 13

Figure 1.5 The Triple Constraint 16

Figure 1.6 Launch of Apollo 15 to the moon on July 26, 1971, by NASA 18

Figure 1.7 Project Management Principles 21

Figure 1.8 Project Performance Domains 21

Figure 1.9 A Project Team Working Together 23

Figure 1.10 Areas of expertise that a project manager should bring to the project team 26

Figure 1.11 Important factors to consider within the project environment 27

Figure 1.12 PMI Framework of Project Environment 28

Figure 1.13 Internal Organizational Environmental Factors that may affect a project 28

Figure 1.14 External Environmental Factors that may affect a project 28

Figure 1.15 Interpersonal Skills Useful to A Project Manager 29

Figure 1.16 Active Listening Increases Understanding 32

Figure 2.1 Military Communications 35

Figure 2.2 Information Flows Between Strategy and Operations 36

Figure 2.3 Types of Success Criteria 38

Figure 2.4 Managerial Authority by Organization Structure 39

Figure 2.5 A Typical Functional Organization 41

Figure 2.6 A Project Manager and Team in a Functional Organization 42

Figure 2.7 Project Teams in a Projectized Organization 43

Figure 2.8 Potential Outcomes of Matrix Organizations 44

Figure 2.9 The Project Manager’s Role Across Organizational Structures 45

Figure 2.10 Projects, Programs, And Portfolios 46

Figure 2.11 Olympic Games May Be Managed as Programs 47

Figure 2.12 Comparing Project, Programs, Portfolios, and Products 49

Figure 3.1 Joseph Sisto, PMP, PMI-ACP 50

Figure 3.2 Tailoring Process 52

Figure 3.3 Development Approaches as a Continuum 53

Figure 3.4 Product, Service, or Result Characteristics to Consider When Selecting an Approach 54

Figure 3.5 Factors Relating to Project Characteristics 54

Figure 3.6 Factors Relating to Organizational Characteristics 55

Figure 3.7 A Process-Based Life Cycle 57

Figure 3.8 Example Life Cycle for a Wedding Using a Predictive Approach 58

Figure 3.9 Research Paper as an Iterative Multiple Delivery Life Cycle 59

Figure 3.10 An Incremental Project with Multiple Deliveries 60

Figure 3.11 Adaptive Life Cycle 61

Figure 3.12 Processes in Delivering Value 62

Figure 4.1 Christian Riis 64

Figure 4.2 An Example Corporate Strategy Balanced Scorecard 66

Figure 4.3 A Simple Checklist 70

Figure 4.4 Advantages and Disadvantages of a Checklist 71

Figure 4.5 Weighted Scoring Model with Critical Factors and Weighted Scoring 72

Figure 4.6 Summary of Economic Scoring Methods 74

Figure 5.1 A Sample Communications Plan 88

Figure 6.1 Project Stakeholders are Numerous 94

Figure 6.2 Stakeholder Management Key Processes 95

Figure 6.3 Types of Project Stakeholders 96

Figure 6.4 Stakeholder Register Contents 101

Figure 6.5 Possible Engagement Strategies based on Power and Interest 102

Figure 7.1 Overview of Project Planning 106

Figure 7.2 WBS for a Wedding 110

Figure 7.3 Sample WBS Dictionary for Wedding 112

Figure 7.4 Example RACI Chart for Wedding 113

Figure 7.5 The importance of documenting requirements 118

Figure 7.6 Sample Requirements Traceability Matrix 119

Figure 8.1 Activity Definition for Work Package 3.1 Bridal Attire 121

Figure 8.2 Comparing Duration and Effort 122

Figure 8.3 Approaches to Estimating Activity Resources 124

Figure 8.4 Sample Network Diagram 125

Figure 8.5 Predecessor Relationships for Activities in Work Package 3.1 127

Figure 8.6 Completed Critical Path Analysis with Schedule Attributes 127

Figure 8.7 Bottom-Up versus Top-Down Scheduling 130

Figure 8.8 Project Schedule with Durations, Relationships, and Resources 131

Figure 8.9 An example of a Gantt Chart 132

Figure 9.1 Example Activity Costs for 3.1 Bridal Attire 139

Figure 9.2 Example Baseline Budget 143

Figure 9.3 An Example of a Time-Phased Budget 143

Figure 10.1 Sample Risk Register 149

Figure 10.2 Risk Assessment Matrix 149

Figure 10.3 Possible Risk Response Options to Crossing a Busy Road 150

Figure 10.4 A Simple Change Control Process 153

Figure 11.1 Using a Simple Change Control Process 156

Figure 11.2 Example Change Log 156

Figure 11.3 Thomas & Kilmann Conflict Model for Getting Agreement 159

Figure 11.4 Approaches to Resolving Conflict Based on Cooperation and Assertion 160

Figure 11.5 Conflict Resolution Responses 160

Figure 11.6 Sample Quality Check Sheet 164

Figure 11.7 Sample Histogram 165

Figure 11.8 Sample Pareto Chart 165

Figure 12.1 Types of Power Available to Project Managers 173

Figure 12.2 Common Influence Tactics 176

Figure 12.3 The Tuckman Model of Team Development Stages 180

Figure 13.1 Earned Value Terms 186

Figure 13.2 Earning Rules to Report Earned Value on Activities 187

Figure 13.3 A Summary of Earned Value Formulas 191

Figure 13.4 RAG Status Meanings 194

About this Book

Juanita Woods and Scott Marshall teach project management to students at the University of North Georgia, USA. They recognized a need to create a zero-cost open-source project management textbook after project management professional standards were updated in 2021. Affordable Learning Georgia (ALG; https://www.affordablelearninggeorgia.org/) awarded the team a Textbook Transformation Grant in 2022 to support the development of the textbook and supporting materials.

The authors gratefully acknowledge the extensive help of their student assistant, Louisa Schlesiger, for her excellent work as a project assistant and developer of the instructor materials. They also appreciate the support of their students who patiently accepted the textbook in its early forms, and professional colleagues who provided the stories incorporated into the book.

© 2023 CC-BY-NC-SA (www.creativecommons.org)

The textbook and associated materials were adapted from the following open-source materials:

• Christianson, J. S. (2017). Project Management Fundamentals. OERCommons.org, OER Commons. https://www.oercommons.org/courseware/lesson/76030/overview-old
• Daddey, F. and A. Watt (2019). Project Management. Nova Scotia Community College, Pressbooks. https://pressbooks.nscc.ca/projectmanagement/
• Russell, J., Pferdehirt, W. & Nelson, J. (2018). Technical Project Management in Living and Geometric Order, Third Edition. Madison, WI: University of Wisconsin. https://biz.libretexts.org/Bookshelves/Management/Book%3A_Technical_Project_Management_in_Living_and_Geometric_Order_(Russell_Pferdehirt_and_Nelson)
• Morris, Shelley. (2021). Project Management Fundamentals. Toronto: Seneca College.

How this book is organized

This textbook begins with a discussion of how projects support organizational strategy and how organizations use projects to deliver value. While the textbook introduces adaptive and predictive approaches to managing projects (see Chapter 2.3.3), it is structured to follow a predictive planning approach. This structure was chosen to support students in general management programs who may be working in operations, manufacturing, or similar environments where projects generally follow predictive approaches.

Following the foundational elements, we move into pre-project work, where we explore the processes for identifying, selecting, and chartering projects. Once projects are chartered, project planning begins. Project planning includes the work of a project manager to engage project stakeholders and identify project outcomes. Once the project manager and stakeholders identify project outcomes, the project manager produces a project management plan that contains a schedule of the work, cost, and processes followed to produce the project outcomes.

Once planning is complete, the book focuses on activities performed by a project manager during the execution phase of project work. These chapters focus on the processes of managing and measuring project work, working with project teams, and monitoring and reporting project status. The textbook introduces project closure activities that ensure the projects deliver value to the organization and ultimately satisfy the organization’s strategy.

The textbook concludes with a brief discussion of careers and certifications available to students interested in pursuing a career in project management.

Throughout the chapters, the authors have included “Deeper Dive” activities that allow students to explore concepts in more detail through online articles, reports, or podcasts. “Test Your Knowledge” activities and examples are also included as checkpoints for students to ensure they understand the presented material.

Figure 0.1 The Structure of this Textbook

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Introduction to Project Management

People have been undertaking projects since the earliest days of organized human activity. The hunting parties of prehistoric peoples could be considered projects. Large and complex undertakings such as the pyramids and the Great Wall of China were also projects. Today, project managers work in both the public and private sectors and in every industry and business size. Projects happen in companies around the world with three or 3,000 people.

The skills used when managing projects are helpful for most careers and daily life. Strong planning skills, effective communication, and the ability to implement a project to deliver the product or service while monitoring for risks and managing the resources provide an edge toward career and professional success.

The starting point in learning how to manage projects appropriately is understanding what a project is and, just as importantly, what it is not. People use the term "project" frequently in daily conversations. Someone may tell their friend, "My main project for this weekend is to straighten out the garage." Working on school and home projects, building pyramids, and fixing faucets all share certain features that make them projects.

In this chapter, you learn about projects, the discipline of project management, and the work of a project manager.

Chapter Learning Objectives

• Define projects and explain the characteristics and constraints of typical projects.
• Describe project management and its benefits.
• Identify factors that affect projects and explain how these factors influence either the success or failure of projects.
• Understand the relationship between project roles and organizations.
• Evaluate the significance of developing strategic, technical, and interpersonal skills for successful project management.

What is a Project?

Definition of a Project

Numerous project definitions exist, but all have the essential elements described below. For those looking for a formal definition of a project, the Project Management Institute (PMI) defines a project as a "temporary endeavor undertaken to create a unique product, service, or result."² The temporary nature of projects requires a definite beginning and end. The end is reached when the project's objectives have been achieved, upon termination because its objectives will not or cannot be met, or when the need for the project no longer exists.

In popular culture, people use the term "project" in numerous ways, from describing everyday tasks (planting a garden, hanging a picture, running errands) to large-scale enterprises (building a house, constructing a new highway). However, when professional project managers talk about projects, they use a narrower definition.

Every book, organization, or standards body in the project management field agrees that a project demonstrates the following characteristics:

• is a temporary endeavor with a defined start and end,
• has a specific objective,
• has customers or stakeholders,
• has constraints such as time, cost, and scope,
• has measures for success, and
• includes some amount of uncertainty.

Project Attributes

A project has distinctive attributes distinguishing it from ongoing work or business operations. Projects are temporary and are not everyday business processes. This characteristic is important because a large part of the project effort is dedicated to ensuring that the project is completed at the appointed time. To do this, project schedules show when tasks should begin and end. Projects can last minutes, hours, days, weeks, months, or years.

People and organizations use projects to deliver a product, service, or result that hasn't existed before. In this sense, a project is unique. Unique means that this is new; this has never been done before. Maybe it's been done in a very similar fashion before but never precisely in this way. We consider updating existing applications, processes, or facilities unique because something new is being added to something already existing.

Figure 1.2 Building a house is a project.

Source: Word

Attribution: Microsoft

License: © Microsoft. Permission granted by EULA.

In contrast to projects, operations are ongoing and repetitive. Operational activities involve continuous work without a defined end date and with the same processes repeated to produce the same results. The purpose of operations is to keep the organization functioning, while the purpose of a project is to meet its goals and add value to the organization. Therefore, operations are ongoing, while projects are unique and temporary.

A project is completed when its goals and objectives are accomplished. These goals drive the project and all the planning and implementation efforts to achieve them. Sometimes projects end when it is determined that the goals and objectives cannot be accomplished or when the product or service of the project is no longer needed, and the project is canceled. We discuss completing projects in Chapter 14.

Project Characteristics

To determine if you have a project, first, you need to identify its characteristics by answering a few questions (Figure 1.3).

Figure 1.3 Questions to Distinguish Projects from Operations

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Second, you need to determine the project’s specific characteristics relating to the project outcomes, timing, and goals (Figure 1.4).

Figure 1.4 Summary of Project Characteristics

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Finally, a successful project meets or exceeds the expected project outcomes. Project stakeholders are individuals, groups, or organizations interested in a project and who may affect or be affected by the project processes or outcomes, so projects are considered successful when they satisfy the project stakeholders.

Project Constraints

On any project, several project constraints compete for your attention, including scope, time, cost, quality, risk, and resources. You may have heard of the term "triple constraint," which traditionally consisted of only time, cost, and scope. However, we must also consider other project constraints, such as risk, resources, and quality. We often illustrate the triple constraint as a triangle to visualize the project work and see the relationship between the scope, time, cost, and quality (Figure 1.5).

Figure 1.5 The Triple Constraint

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Each side of the triangle represents the “triple constraints,” wherein any changes to any side cause a change in the other two sides. The best projects perfectly balance the three constraints. Maintaining this balance is difficult because projects are prone to change. For example, if scope increases, then cost and time may increase disproportionately. Alternatively, if the amount of money you have for your project decreases, you may be able to do the same amount of work, but your time may increase.

Scope is what the project is trying to achieve. It entails all the work involved in delivering the project outcomes and the processes used to produce them. It is the reason and the purpose of the project.

Time refers to how long it will take to complete the project. Time is often the most frequent project oversight in developing projects. Projects are late when deadlines are missed, and deliverables are not completed as planned. Proper control of the schedule requires the careful identification of tasks to be performed and accurate estimations of their durations, the sequence in which they will be done, and how people and other resources are to be allocated. The project schedule should consider team member vacations and company holidays.

Cost is the budget approved for the project, including all necessary expenses needed to deliver the project. Within organizations, project managers must balance not running out of money with not under-spending. Many projects receive funds or grants with contract clauses taking a "use it or lose it" approach to project funds. Poorly executed budget plans can result in a last-minute rush to spend the allocated funds. For virtually all projects, the cost is a limiting constraint; few projects can go over budget without eventually requiring corrective action.

Quality combines the standards and criteria to which the project's products must be delivered to perform effectively. The product must perform to provide the functionality expected, solve the identified problem, and deliver the benefit and value expected. It must also meet other performance requirements or service levels—such as availability, reliability, and maintainability—and have an acceptable finish and polish. Project quality is controlled through quality assurance (QA), which includes activities to regularly evaluate overall project performance to provide confidence that the project will satisfy the relevant quality standards.

Risk is defined by potential external or internal events that may negatively impact your project if they occur. Risks are evaluated by the probability that such an event occurs with some impact on the project. Suppose the probability of the occurrence and impact on the project is too high. In that case, you should identify the potential event as a risk and put a proactive plan in place to manage the risk.

Resources are required to carry out project tasks. They can be people, equipment, facilities, funding, or anything else capable of definition (usually other than labor) required to complete project activities.

Your project may have additional constraints that you must face, and as the project manager, you must balance the needs of these constraints against the needs of the stakeholders and your project goals. For instance, if your sponsor wants to add functionality to the original scope, then you will very likely need more money to finish the project; or, if they cut the budget, then you will have to reduce the quality of your scope; and, if you don't get the appropriate resources to work on your project tasks, then you will have to extend your schedule because the resources you assigned to the task have taken much longer to finish the work.

What is Project Management?

Now that we have explored the concept of projects, we can explore how projects are managed in organizations. First, we will look at a brief history of project management.

A Brief History of Project Management

While we can trace project management to the building of the Great Pyramids in Egypt, it was in the post-World War II industrial boom of the 1950s that project managers developed the tools and techniques used in modern project management. These tools were used to complete large industrial and military projects where the scope of work was well-defined.

Figure 1.6 Launch of Apollo 15 to the moon on July 26, 1971, by NASA

Source: Wikimedia Commons

Attribution: NASA

License: Public Domain

At that time, the process of managing projects became more formalized when international organizations began defining project management processes and activities. One organization, the Project Management Institute (PMI; www.pmi.org), was founded in 1969 to support the growing project management profession. Their initial goal was to establish an organization where members could share their experiences in project management and discuss issues. Today, PMI is a non-profit project management professional association and the most widely recognized organization promoting project management best practices. PMI was formed to serve the interests of the project management industry. The premise of PMI is that common tools and techniques of project management are widely applied to all industries, from software to the construction industry. PMI first began offering the Project Management Professional (PMP) certification exam in 1984. Since then, more than 1 million individuals worldwide have earned the PMP designation as of July 2020. Since 1984, PMI has added numerous other certifications to support the growing diversification of project management as a discipline.

To help keep project management terms and concepts clear and consistent, PMI introduced A Guide to the Project Management Body of Knowledge (PMBOK Guide) in 1987. The most current version, updated in 2021, is the seventh edition. More than one million copies of the PMBOK® Guide are currently in circulation. PMI is responsible for developing and promoting the PMBOK and administers professional certifications for project managers. If you want to get grounded in project management, PMI is the place to start, and if you want to make project management your profession, then you should consider earning a certification.

The Process of Project Management

You've determined that you have a project. What now? The notes you scribbled down on the back of the napkin at lunch are a start but not exactly good project management practice. Too often, organizations follow Nike's advice when managing projects: "just do it." An assignment is made, and the project team members jump directly into developing the product or service requested. Ultimately, the delivered product doesn't meet the customer's expectations. Unfortunately, many projects follow this poorly- constructed path, which is a primary contributor to many projects not meeting their original objectives, as defined by performance, schedule, and budget.

Applying solid project management practices is one way to help reduce project risks. Good project management skills do not eliminate problems, risks, or surprises. However, the value of good project management is that you have standard processes in place to deal with all contingencies.

Project management is "the application of knowledge, skills, tools, and techniques applied to project activities to meet the project requirements.”^[2] Project management is a process that includes planning, putting the project plan into action, and measuring progress and performance.

Managing a project includes identifying your project's requirements and writing down what everyone needs from it. What are the objectives of your project? Keeping them on the right path is much easier when everyone understands the goal. Set goals that everyone agrees on to avoid team conflicts later. Understanding and addressing the needs of everyone affected by the project means the result of your project is far more likely to ensure a satisfactory project outcome.

The Project Management Framework

The latest version of The Standard for Project Management by the Project Management Institute presents a model, or framework, of project management as a set of organizational processes and functions that deliver value to organizations through project work. A deeper discussion on how projects deliver organizational value will be discussed in Chapter 2, Projects and Organizational Strategy. For now, we offer a brief overview of this system for value delivery, the guiding principles to deliver value, and the performance domains associated with project work.

Delivering Value

The main goal of most for-profit organizations is to be profitable and deliver value to its shareholders, employees, and customers. Even not-for-profit organizations have value-driven objectives to satisfy the people they serve. Projects are one way that organizations deliver value through new or improved products, processes, or services. Project management is a deliberative approach to obtaining that value.

Guiding Principles

With project management as a system to deliver organizational value, the actions taken by project managers must align with the values of the organization and the values of society. PMI identifies 12 guiding principles by which project managers should demonstrate ethical and appropriate behaviors when managing projects (Figure 1.7). These principles will be discussed throughout this text as appropriate.

Figure 1.7 Project Management Principles

Adapted from Project Management Institute, Standard for Project Management, 2021

Source: Original Work

Attribution: Juanita Woods, adapted from Project Management Institute, Standard for Project Management, 2021 (PMBOK® Guide 7E)

License: CC BY-NC-SA 4.0

Performance Domains

The 12 project management principles guide project manager behavior as they manage project work. The work performed by a project manager can be described by eight "performance domains” (Figure 1.8). The eight performance domains provide a comprehensive framework of interrelated activities for successfully delivering organizational value through projects.⁴

Activities described in each performance domain may take place at any point during a project. The selection of activities is determined by the organizational context, the project, the project team, stakeholder needs, and other relevant factors.

Figure 1.8 Project Performance Domains

Adapted from the Standard for Project Management, Seventh Edition, Project Management Institute, 2021

Source: Original Work

Attribution: Juanita Woods, adapted from Project Management Institute, Standard for Project Management, 2021 (PMBOK® Guide 7E)

License: CC BY-NC-SA 4.0

Project Management Roles

Delegating responsibility and work to others is a critical project management skill. The responsibility for executing the project belongs to the project manager. Often other team members on the project will complete project work while reporting to a functional manager in the parent organization.

Figure 1.9 A Project Team Working Together

Source: Word

Attribution: Microsoft

License: © Microsoft. Permission granted by EULA.

The following people typically play a critical role in a project's success: the project sponsor and upper management, the project manager, project team members, and subject matter experts, including business analysts. Chapter 12 will provide more details on leading and developing project teams.

Project Sponsor

In some organizations, an upper-level executive will be charged with, or volunteer to be, the project's champion or sponsor. This person acts as the liaison between the project team and upper management. They may provide the project manager with direction, information about how the project fits into the company's strategic goals, and assistance with getting the resources needed to complete the project. The best project sponsors are cheerleaders for the project, enthusiastically supporting the project and its team members.

Upper management support is essential because project managers are asked to use company resources to achieve organizational objectives. The organization's executives support the project by establishing the company's strategy, providing project funding and resources, and making project-related decisions. Suppose the top management team is not on board with the project outcomes. In that case, a project manager may have difficulty engaging project team members or using company resources to complete a project.

Project Manager (PM)

The project manager is involved in a project throughout its life cycle. The PM develops the project plans, ensures they are executed with appropriate changes as needed, and turns over the project when it is complete. Being a project manager can be extremely rewarding but comes with its own set of challenges. A project manager may have responsibility for a project's success but often does not have full authority over the resources required to complete the project successfully. One reason having excellent interpersonal skills is vital for project managers is that they may have to negotiate for project resources from upper management or functional managers within the organization.

Being a great communicator and working well with various personalities are important skills for a project manager (skills that anyone can develop and improve). A project manager will use these skills with upper management, other stakeholders, and the project team. One of the primary responsibilities of a PM is motivating and building project teams. How a PM behaves in this role will depend on how they view the motivation of their team members.

Project Team

The project team works with the project manager to develop the project management plans, schedule the work of the project, acquire the needed resources, monitor project progress, and see the project through to its successful completion. Team members may be devoted solely to working on the management aspects of a project or may also be performing the project's work. How well the project team works together will determine the success or failure of a project.

The project team includes people dedicated to the project or borrowed on a part-time basis. They provide subject matter expertise to the project. Subject matter experts (SMEs) have specialized knowledge or skills about a particular function or product the project will use or create. Project managers must provide leadership, direction, and support to team members as they accomplish their tasks. Working closely with the team to solve problems can help you learn from the team and build rapport. Showing your support for the project team and each member will help you get their support and cooperation.

One key role on the project team is that of a business analyst (BA). A business analyst helps ensure that the business needs are accurately and appropriately satisfied with the project outcomes. Business analysis is the process of identifying what is needed and recommending viable solutions to satisfy business needs. Activities include documenting requirements and validating that those requirements are satisfied by the project outcomes.

The Project Manager

As a project manager, you should bring some areas of expertise to the project team to manage the project and competing constraints. These areas are technical knowledge, strategic business and management knowledge and skills, and leadership and interpersonal skills.

Figure 1.10 Areas of expertise that a project manager should bring to the project team

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Technical knowledge

Technical knowledge includes understanding standards, regulations, application areas, and best project management practices. Standards are guidelines or preferred approaches that are not necessarily required. In contrast, regulations are mandatory rules that must be followed, such as government-imposed requirements through laws. As a professional, you must follow all applicable laws and rules to your industry, organization, or project. Every industry has standards and regulations. Knowing what affects your project before you begin work will help the project unfold smoothly and allow for effective risk analysis. While knowledge of the industry type is important, you will have a project team supporting you in this endeavor.

Some projects require specific skills in particular application areas. Application areas contain common elements, characteristics, or technology. They can be defined by industry group (such as logistics, healthcare, technology) or department (Administration, Finance, Marketing, and Human Resources, for example). These application areas are usually concerned with disciplines, regulations, the project's specific needs, the customer/client, or the industry. For example, most government agencies have specific procurement rules that apply to their projects that wouldn't apply to the software industry. For them, today's fast-paced advances can leave them behind fairly quickly if they don't stay abreast of current trends.

Experience in the project application area may give the project manager some advantages in managing a project in a particular discipline. While it is helpful to call in experts who have the application area knowledge, a project manager can benefit from understanding the specific aspects of the project’s application areas.

Strategic Business and Management Knowledge and Skills

Project management is more than just getting the work done. Inherent in the project management process are general management skills that allow the project manager to complete the project with some level of efficiency and control. In some respects, managing a project is similar to running a business: there are risks and rewards, finance and accounting activities, human resource issues, time management, stress management, and a purpose for the project to exist. Therefore, general management skills are needed in every project.

Understanding the Project Environment

The project environment, composed of many internal and external factors in your organization, can influence your project's success. Internal organizational factors include structure, culture, people, and processes. External organizational factors include the external environment in which an organization operates (Figure 1.11).

Figure 1.11 Important factors to consider within the project environment

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

PMI distinguishes between enterprise environmental factors and organizational process assets to describe the many ways in which the project environment can influence project processes and outcomes (Figure 1.12).⁵ External environmental factors are those factors that are present inside and outside the organization, but are outside of the project team’s control or influence. Organizational process assets include processes and information unique to the organization, which the project team can utilize to understand the business environment in which the project operates.

Figure 1.12 PMI Framework of Project Environment

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Internal Organizational Environment

Internal environmental factors include an organization's processes, people, and assets, culture and structure, infrastructure, and physical assets available to a project team (Figure 1.13). Also known as organizational process assets, a project manager needs to be familiar with the resources that are available to effectively plan and manage projects.

Figure 1.13 Internal Organizational Environmental Factors that may affect a project

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

External Environment

External environmental factors can influence a project within an organization and include all factors that affect the organization's success. One way to think about the external factors that may affect a project within an organization is to use the PESTLE acronym^[3] (Figure 1.14).

Figure 1.14 External Environmental Factors that may affect a project

Source: Original Work

Attribution: Juanita Woods, adapted from What is PESTLE Analysis?

License: CC BY-NC-SA 4.0

Political systems influence how businesses operate and directly affect the economy or industry in which a business operates. Social-cultural factors relate to how people interact with each other and the values and norms of behavior they hold. Technological factors include automation, computing, and innovations that can affect how a company competes in its market. Legal and ethical factors include laws that affect the business environment and the ethical frameworks that people and organizations uphold. Environmental and natural resources include the physical surrounding environment, the regional and global climate, and how these factors affect how an organization conducts its business.

All the factors are important to consider, but the cultural and international factors are often misunderstood or ignored. How we deal with clients, customers, or project members from other countries or societies can be critical to the project's success. For example, colors have different meanings in different cultures. White, a sign of purity in North America (e.g., a bride's wedding dress) and thus a favored background color in North America, signifies death in Japan (e.g., a burial shroud).

Project managers in multicultural projects must appreciate the cultural dimensions and try to learn relevant customs, courtesies, and business protocols before taking responsibility for managing an international project. A project manager must consider these various cultural influences and how they may affect the project's completion, schedule, scope, and cost. 

Power Skills for Project Managers

Project managers need strong interpersonal skills when managing and leading projects. This section will discuss additional interpersonal skills needed to effectively lead and develop high-performing project teams (Figure 1.15).

Figure 1.15 Interpersonal Skills Useful to A Project Manager

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Leadership

Leadership is the ability to motivate and inspire individuals to work toward expected results. Leaders inspire vision and rally people around common goals. As a leader, a good project manager can guide the team to see the vision and value of the project. In addition, the project manager can inspire the team to find a solution to overcome perceived obstacles to getting the work done. A more in-depth discussion of leading teams without authority will be presented in section 12.1.

Delegation

Delegating responsibility and work to others is another critical project leadership skill. The responsibility for executing the project belongs to the project manager. Often, team members work on the project but report to a functional manager in the parent organization.

Delegation, or giving others the autonomy, accountability, and responsibility for how to do their assigned work, involves creating a project organizational structure with the work organized into manageable units. Delegation involves understanding the knowledge, skills, and abilities needed to manage that work and matching the team members with the right skills to do it. Good project managers are good delegators. They recognize that delegation is often more effective than exerting a great deal of control when working with competent staff engaged in the project.

For example, the procurement leader for a major project may also report to the organization’s vice president for procurement. Although the procurement plan for the project must meet the organization’s procurement policies, the procurement leader on the project will take day-to-day direction from the project manager.

The amount of direction given to the procurement leader or others on the team is the project manager’s decision. Suppose the project manager delegates too little authority to others to make decisions and act. In that case, the consequent lack of a timely decision or lack of action will cause delays in the project. Delegating too much authority to others who do not have the knowledge, skills, or information will typically cause problems that result in delays or increased project costs. Finding the right balance is a critical project management skill.

Influence

Project management is about getting things done. Every organization has different policies, operations modes, and culture. Political alliances, differing motivations, conflicting interests, and power struggles exist. A project manager must understand the unspoken influences at work within an organization. Influence is the ability to get people to do things for you when you don’t have the authority or other types of power to get them to do those things. A more in-depth discussion of leading teams without authority will be presented in section 12.2.

Emotional Intelligence

Emotions are mental and physiological responses to external environmental and internal stimuli. Leaders should understand and value emotions to appropriately respond to the client, project team, and project environment. Emotional intelligence includes the following:

• Self-awareness: recognizing your emotions and how they affect you and your interactions with others
• Self-regulation: managing emotional responses in your interactions with others
• Empathy: recognizing the emotions held by others
• Relationship management: managing emotions in relationships for more effective interactions

Emotions are essential to generating energy around a concept, building commitment to goals, and developing high-performing teams. Emotional intelligence is vital to the project manager’s ability to build trust among the team members and stakeholders. It is necessary to establish credibility and open dialogue with project stakeholders. Emotional intelligence is critical for project managers, and the more complex a project, the more influential the project manager’s emotional intelligence becomes to project success.

Motivation & Teamwork

Building motivation in your team helps everyone work more efficiently and produce better results. Motivation is an internal force that drives people to perform at their best. The project manager motivates the team toward completing project goals with passion and provides a profound reason to complete the work. The project manager uses various team-building techniques and exercises to motivate the team. Team building is getting a diverse group to work together most efficiently and effectively. This may involve management events and individual actions designed to improve team performance.

Recognition and rewards are an essential part of motivating teams and are formal ways of recognizing and promoting desirable behavior. These strategies are most effective when carried out by the management team and project manager. Consider individual preferences and cultural differences when using rewards and recognition. Some people don't like to be recognized in front of a group; others thrive on it.

Communication

Project managers spend the majority of their time communicating. Therefore they must be good communicators, promoting a clear, unambiguous exchange of information. As a project manager, you must keep many people well informed. It is essential that your project staff know what is expected of them: what they have to do, when they have to do it, and what budget, time constraints, and quality specifications they are working toward. If project staff members do not know their tasks or how to accomplish them, the entire project will grind to a halt. If you do not know what the project team is (or is not) doing, you will be unable to monitor project progress. Finally, if you are uncertain of what the customer expects of you, the project will not get off the ground. Project communication can be summarized as knowing "who needs what information and when" and ensuring they have it.

Active Listening

One of the most useful communication skills a project manager has is the ability to listen actively. Active listening is placing oneself in the speaker’s position as much as possible, understanding the communication from the speaker’s point of view, observing body language and other environmental cues, and striving not just to hear but to understand. Active listening takes focus and practice to become effective. It enables a project manager to go beyond the basic information being shared and develop a complete contextual understanding of the information. Active listening techniques include:

• Listening intently to the client’s words and discerning their body language
• Nodding and expressing interest in the client without forming rebuttals
• Providing feedback and asking for clarity while repeating a summary of the information back to the client
• Expressing understanding and empathy for the client

Figure 1.16 Active Listening Increases Understanding

Source: Word

Attribution: Microsoft

License: © Microsoft. Permission granted by EULA.

Negotiation and Conflict Management

Project managers must negotiate for the good of the project. In any project, the project manager, the project sponsor, and the project team will have to negotiate with stakeholders, vendors, and customers to reach an agreement acceptable to all parties involved.

Negotiation is an active process where you try to get an agreement between the people involved in a disagreement. Negotiation is necessary when stakeholders disagree on what is to be included or not included in the project scope. A project manager will need to facilitate discussions between the competing stakeholders to determine the best decision for the project.

Conflict in a project is to be expected because of stress levels, lack of information during the early phases of the project, personal differences, role conflicts, and limited resources. Although good planning, communication, and team building can reduce conflict, issues will emerge. How the project manager deals with conflict results in either problems or an opportunity to build energy, creativity, and innovation. A more in-depth discussion of conflict management and negotiation will be discussed in section 11.5.

Problem-Solving

Problem-solving is the ability to understand the root of a problem, identify viable solutions, and then decide to implement the best solution. The starting point for problem-solving is defining the problem. Problem definition involves evaluating the cause and effect of the problem; this centers on root-cause analysis. If a project manager treats only the symptoms of a problem rather than its cause, then the symptoms will perpetuate and continue through the project life. Even worse, treating a symptom may result in a more significant problem. For example, increasing the ampere rating of a fuse in your car because the old one keeps blowing does not solve the problem of an electrical short that could result in a fire. The root-cause analysis looks beyond immediate symptoms to the cause of the symptoms, which then affords opportunities for solutions. Once a project manager identifies the root of a problem, they must take action to resolve it.

Solutions can be presented by vendors, the project team, the project manager, or various stakeholders. A viable solution focuses on more than just the problem; it looks at the cause and effect of the solution itself. In addition, a timely decision is needed or the window of opportunity may pass, and a new decision will be required to address the problem. As in most cases, the worst thing you can do is nothing.

All of these (and more) interpersonal skills will be used in all areas of project management. So start practicing now because it's guaranteed that you'll need these skills on your next project.

Projects and Organizational Strategy

As discussed in the prior chapter, organizations engage in projects to deliver value through new and improved products, services, or results. Project governance structures fit within the organization's structure, and the type of organizational structure influences how projects are governed. This chapter will teach you about organizational structures and how projects fit within them. You will also explore the processes involved in identifying and selecting projects that satisfy organizational objectives.

Chapter Learning Objectives

• Understand the role of projects in delivering organizational value.
• Distinguish between the different organizational structures and understand how project work might fit within those structures.
• Explore the structures involved with project governance and oversight.

Value Creation and Strategic Alignment

Creating value and aligning with organizational strategy requires project managers to understand an organization's vision, mission, and strategy, as well as success factors that allow organizations to evaluate the effectiveness of project activities.

Vision, Mission, and Strategy

Organizations exist to fulfill a purpose. This purpose is expressed in an organization’s vision statement. The vision statement is an ideal that describes what leaders want an organization to accomplish. The mission statement is more specific, describing how the organization will fulfill its vision.

An organization’s strategy is the game plan for ensuring that the organization’s efforts are directed toward a common goal. It is an expression of its mission and overall culture. In a well-run company, every decision about a project supports the organization’s strategy (Figure 2.2). The strategy, in turn, defines the company’s portfolio of projects and day-to-day operations. Projects and their budgets flow out of the organizational strategy.

Figure 2.2 Information Flows Between Strategy and Operations

Source: Original Work

Attribution: Juanita Woods, adapted from Project Management Institute, Standard for Project Management, 2021 (PMBOK® Guide 7E)

License: CC BY-NC-SA 4.0

Successful organizations are intentional about performing actions that fulfill their vision and mission. These organizations analyze their external and internal environments to understand the opportunities and threats present in the areas in which they operate. An organization must also analyze and work with its strengths and weaknesses. Organizational leaders use analysis to inform their decision-making. In particular, the organization must develop objectives to reach its desired strategic goals. These objectives are usually some sort of performance goal. Examples of performance goals include increasing market share for a product/service, improving profitability, and improving client satisfaction.

Without a clearly defined strategy, an organization cannot expect to navigate the complexities of its external environment. This is especially true if the strategy is motivated by the organization’s attempt to push its vision onto customers rather than pulling the customer’s definition of value into its daily operations.

Projects are one approach that organizations take to operationalize strategy. In the end, effectively executing a strategy means pursuing suitable projects. In other words, it’s a matter of aligning projects and initiatives with the company’s overall goals. For example, a company with a mission of providing meals to people experiencing food insecurity would be better served focusing on a project that develops a streamlined process to deliver food, instead of focusing on a project that improves the executive’s office space. We will discuss the process of aligning projects with an organization's strategy in Chapter 4.

Success Factors

Project success depends on project management success, but these two types of success are distinct (Figure 2.3). Project success deals with the effects of a project’s outcomes or final product or service on stakeholders. Project management success focuses on the processes of a project, including successfully completing the project and delivering the agreed-upon scope within budget (cost), time (schedule), and quality requirements.

We can also consider organizational success criteria, which are success factors that connect with the organization’s strategy. An organization identifies its vision and mission, but organizational leaders must operationalize how the mission will be realized by identifying measurable strategic objectives. These strategic objectives can also be considered organizational success criteria, often used to identify and select projects (see section 4.4).

Figure 2.3 Types of Success Criteria

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Successful organizations need successful projects, and successful projects need successful project management. Effective project management requires good planning, a skilled project manager, good communication and information flows, value to stakeholders, engaged team members, and changing activities to accommodate the dynamic nature of projects.

A project may be successfully managed but not meet the client or customer's expectations. Because the purpose of project work is to create value, success levels can be measured by stakeholders to determine added value upon completion.

Effective project management practices play a role in project success. However, many other factors outside the project manager's direct control influence project management success. Therefore, even if the project management process is successful, stakeholders may perceive the accomplished project as a failure. Factors that may cause project management to fail include^[4]:

• Inadequate rationale, objectives, tasks, and goals
• Unqualified or inexperienced project manager
• Lack of support from top management
• Lack or misuse of project management techniques
• Inadequate or incorrect communications
• Inadequate project planning
• Lack of commitment to the project.

Organizational Structures

As discussed previously, organizations rely on the strategic use of projects to ensure the organization’s work aligns with its mission and strategy. To achieve this, leaders structure organizations to maximize the effectiveness and efficiency of operations to achieve organizational goals. An organization’s structure directly influences how projects fit within the organization to help deliver the value desired by the organization.

Principles of Organizational Structures

Organizational structure refers to how various tasks are divided, resources are deployed, and how units or departments are coordinated. Organizations are structured around standard tasks, formal reporting relationships, and effective employee coordination across departments with the help of authority, reliability, responsibility, and accountability. These principles are fundamental to developing effective organizational structures and workflows based on their clear understanding by all employees.

The following principles help describe an organization’s structure:

• Authority is the right to make decisions, issue orders, and allocate resources to achieve desired outcomes. This power is granted to individuals (possibly by position) so that they can make full decisions.
• Reliability is the degree to which a team member can be depended on to ensure the project’s success with sound and consistent effort.
• Responsibility is an obligation incurred by individuals in their formal organizational roles to effectively perform assignments or work toward the organization’s success with or without guidance or authorization.
• Accountability is the extent to which an individual or project team is answerable to stakeholders and provides visible evidence of action (accountability = authority + responsibility).

Authority and responsibility can be delegated to lower levels in the organization, whereas accountability usually rests with individuals. Yet many executives refuse to delegate and argue that an individual can have total accountability through responsibility alone.

An organizational structure outlines the various roles within an organization, who reports to whom, and how an organization will departmentalize its work. Traditional job groupings result in different organizational structures, impacting project management because of possible conflicts in authority, responsibility, and accountability.

An organization can be organized according to three broad structures: functional, matrix, and projectized. These structures represent a continuum (Figure 2.4), from structures where the project manager has very little authority (functional) to those where project managers have comprehensive power (projectized).

Figure 2.4 Managerial Authority by Organization Structure

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Many studies have considered the impact of organizational structure on project success, and it is not uncommon for corporations to change their organizational structures to increase relative success in executing projects on time and within budget. Structural change takes great effort and may take a long time to fully implement.

Instead of changing its structure, an organization may create a dedicated project team to carry out a critical project without reorganizing the entire enterprise. This way, they can get many of the same benefits of the projectized organization without reorganizing the enterprise. This approach is not without risk, as we’ll explore in the discussion of dedicated project teams below.

Understanding organizational structures and how projects fit within them gives project managers insights into managing projects more effectively and efficiently.

A typical organization has several layers of management. Think of these layers as a pyramid like the one shown below (Figure 2.5). Top managers occupy the narrow space at the peak, employees occupy the broad base, and middle managers spread throughout the levels in between. As you move up the pyramid, management positions get more demanding, but they carry more authority and responsibility (along with more power, prestige, and pay). Top managers spend most of their time planning and decision-making, while first-line managers focus on day-to-day operations. For obvious reasons, far more people are positioned at the pyramid's base than at the other two levels.

Figure 2.5 A Typical Functional Organization

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Functional Organizations

In functional organizations, the reporting structure is traditionally organized by function into various departments, with staff in each department reporting to a departmental manager or head. This allows for groupings of specialists within the organization to work together, share knowledge, and prioritize their work. Traditional functional departments might include:

• Human resources
• Accounting
• Procurement
• Marketing
• Sales
• Shipping

These functional units work independently, and the functional managers serve as conduits for communications and collaboration. This structure is very efficient and continuous process improvement can be conducted on all regular departmental operations. However, it is not optimal for project completion.

Projects often require work across disciplines. In a functional organization, with staff isolated inside their departmental “silos,” communication is directed through functional managers (Figure 2.6). These managers often have diverging priorities, making communications slow and error-prone in a functional organization.

Figure 2.6 A Project Manager and Team in a Functional Organization

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

The success of projects within a functional organization depends on functional and project managers working together and cooperating. While someone may be designated as the project manager for a particular project, that person may not have much authority. In this case, a functional organization may use the titles Project Coordinator, Project Scheduler, or Project Expediter to identify the people who manage projects. Regardless of title, those in charge of projects are often put in the role of simply trying to maintain a schedule of what is happening.

Projectized Organizations

Projectized organizations are at the opposite end of the organizational spectrum from functional organizations. These organizations focus their energy and resources on completing projects rather than managing ongoing operations. In a projectized organization, operations are minimal, and the project manager has full authority over resources and personnel decisions. Projectized organizations may have organizational units called departments, and these groups either report directly to the project manager or provide support services to projects.

In the project-based structure, personnel are assigned to the project and report directly to the project manager (Figure 2.7). The project manager is responsible for the performance appraisal and career progression of all team members while on the project.

Figure 2.7 Project Teams in a Projectized Organization

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

As you can imagine, employees in this environment can focus their loyalty on a project rather than their discipline. Not all people can succeed in such an organization, as they must adapt to different project managers' leadership styles and organizational skills.

This structure is the most efficient organizational type for conducting projects, and it is used in organizations that bid on and undertake large projects, such as construction, industrial, and scientific projects that may last several years.

Examples of project-based organizations include construction companies, aeronautical manufacturers, and many software development companies.  This type of organizational structure can put additional stress on employees as, once their project is over, they have no home to return to if they are not quickly selected for a subsequent project. However, this structure is generally considered ideal for project management since it significantly reduces the bureaucratic layers that a project manager must navigate.

Matrix Organizations

While it may work well in times of little change, a functional organization structure is limiting when a company's success depends on adaptability. A matrix organizational structure attempts to combine the strengths a functional organization provides for operations management with the strengths a projectized organization provides for project management. In a matrix organization, the functional and project managers share authority and responsibility, which can lead to positive and negative outcomes (Figure 2.8).

Figure 2.8 Potential Outcomes of Matrix Organizations

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

There are three basic types of matrix structures.

• Weak Matrix: The project manager has less control over resources and people than the functional managers. Project managers in a weak matrix may go by other titles, such as project coordinator or project scheduler.
• Balanced Matrix: In a balanced matrix, the project manager and functional manager share authority over resources and staff equally. This setup allows the organization to experience the best of both a projectized and functional organization simultaneously. However, this system presents many challenges:
  • Functional managers and project managers must work well together and maintain regular communications.
  • Staff will have two managers to whom they must report, breaking the chain of command concept and organizational structure.
  • If functional and project managers have conflicting priorities, subordinates may be unable to meet expectations.
• Strong Matrix: In a strong matrix, the project manager has more direct control over resources and staffing while the functional manager will support the project staff in hiring, technical expertise, and professional development. Of all the matrix structures, the project manager has the most authority in this type while the functional manager has the least.

Dedicated Project Team

Many functional organizations find that they often need to carry out essential projects but do not want to change their entire organizational structure. Recognizing the advantages achieved by giving authority to a project manager, functional organizations often organize dedicated project teams where a project manager can have authority over the staff assigned to a particular project. The project manager and project team members are sometimes located in a designated office, away from the desks and duties they typically have within the functional organization. This can be a very effective way to complete projects. However, some challenges can arise, including:

• Temporary loss of staff from functional groups.
• Integration of project team members into the functional organization can be complex after the project is completed.
• An “us versus them” mentality, where people on the project team are deemed “better” than those working in functional departments. There have been numerous case studies of conflict arising from dedicated project teams.

A classic case of using a dedicated project team and the problems it can cause to the functional organization was when Steve Jobs picked the best and brightest engineers from Apple to work on the development of the Macintosh computer. The project was very successful, but there was a lot of tension between the project team and the functional organization.

Figure 2.9 summarizes the project manager’s authority and role across the different organizational structures discussed here. Additionally, the table highlights who has control of the project budget and project resource availability.

Figure 2.9 The Project Manager’s Role Across Organizational Structures

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Project Governance

Projects versus Programs versus Portfolios

Most organizations do not have the resources or time to complete all possible projects, even if all of those ideas might result in a successful outcome that would move the organization forward. As a result, organizations will typically keep a list of possible projects and review it periodically to see if it's the right time to pursue a particular project.

Project Portfolio Management (PPM) is one approach organizational leaders use to align proposed projects with an organization’s strategic goals. Portfolios are the complete set of initiatives, including projects, programs, and operational activities, that a company enacts to achieve organizational strategies and objectives.

Figure 2.10 Projects, Programs, And Portfolios

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Within portfolios, a company may have several programs, which are sets of coordinated projects. Program management is the process of managing all these coordinated projects. Programs are established when a set of projects share something in common, such as resources, customers, or products and services. Programs allow organizations to use limited resources more efficiently and ensure similar projects do not conflict with one another. Program managers work with project managers on the various projects which make up the program to balance resources, risk, and scope.

The international Olympic Games is one example of a program. Hosting the Olympics is a program because many projects must fit together and be ready by a hard deadline, such as constructing stadiums and aquatic centers, creating marketing campaigns, installing new networks and power connections for media, etc. By coordinating all these projects, program managers can ensure that all is ready for the opening ceremonies.

Figure 2.11 Olympic Games May Be Managed as Programs

Source: Word

Attribution: Microsoft

License: © Microsoft. Permission granted by EULA.

Project Management Office

Organizations often have many project managers working on multiple projects, which may or may not be part of a coordinated program. A Project Management Office (or PMO) provides a central place for developing project management best practices, collecting lessons learned, supporting project managers, and assisting with Project Portfolio Management (PPM). Some PMOs will also support project managers by conducting analyses (for example, Monte Carlo risk analysis), such as assisting with time and cost estimates, for example. The PMO may be the home of all the project managers in an organization, or it may simply be a resource for all project managers who report to their line areas.

Typical objectives of a PMO are:

• Help ensure that projects are aligned with organizational objectives
• Provide templates and procedures for use by project managers
• Provide training and mentorship
• Provide unbiased facilitation for project meetings
• Stay abreast of the latest trends in project management
• Serve as a repository for project reports and lessons learned

The existence and role of PMOs tend to be somewhat fluid. If a PMO is created and increased success is not experienced in organizational projects, the PMO is at risk of being disbanded as a cost-saving measure. If an organization in which you are a project manager or a project team member has a PMO, try using available resources. If you are employed as a resource person in a PMO, remember that your role is not to get in the way and create red tape but to enable and enhance the success of project managers and project success.

Project Versus Product Management

Recently, the focus has shifted from project success criteria to the value achieved from products produced by projects.

Products are the outcomes of projects, and organizations measure product success in terms of business value over the product's life. This contrasts with project success, where the focus is on value delivery when the project ends.

Product management focuses on the "integration of people, data, processes, and business systems to create, maintain, and evolve a product or service throughout its life cycle.”^[5] A product's life cycle includes all project stages, from the initial idea to the product's retirement.

Product management involves analyzing three trends in the market to determine how and what to do with a given product. These trends focus on the customer, the impact of technology, and changes to how products are purchased and supported.

In the past, organizations saw customers as merely end-users of their products or services. Today, organizations see customers as partners in designing, developing, and delivering products and services. Customer engagement and loyalty programs keep them involved in product improvement decisions throughout the product's life cycle.

Technology enhancements also influence how organizations manage products. As the world moves toward interconnected systems and societies, product features and functions must change to stay relevant and valuable to consumers.

Technology has also influenced how customers purchase and acquire new products and services. For example, transitioning from a pay-to-own to a subscription-based model has drastically changed how organizations deliver incremental improvements to existing products and how new products are designed for consumer use.

The focus on continuous value delivery and customer involvement has driven organizations to think of a product as part of an environment to be managed. Thinking this way, organizations tend to transition from temporary project teams that disband when the project is finished to stable teams that continue to support the evolution of the product or service. Incremental funding is made possible by the stability of the product environment, which improves financial projections and profit estimates.

Organizations often use programs and portfolios, discussed in the previous section, to manage product life cycles. Figure 2.12 compares the duration, scope, change, success criteria, and funding sources of projects, programs, portfolios, and products.

Figure 2.12 Comparing Project, Programs, Portfolios, and Products^[6]

Approaches to Delivering Project Outcomes

Project management is not a one-size-fits-all approach that can be applied to organizations without considering their unique characteristics and the environment in which they operate. A good project manager learns when to modify, or tailor, project management methods, tools, techniques, and approaches to suit their organization’s unique characteristics.

Organizational characteristics also influence the approach taken to manage projects. In this chapter, we will discuss the various development approaches and understand when each would be most beneficial for a given project. Further, we will explore project life cycles and how value can be delivered to an organization through project outcomes.

Chapter Learning Objectives

• Understand the process of tailoring the PMBOK® Guide and Standard to a specific project, considering project and organization attributes.
• Compare and contrast the various development approaches and understand when each would be most beneficial for a given project.
• Understand the relationship between the development approach and a project’s life cycle.
• Explain the difference between a project life cycle and performance domains.
• Understand the project manager’s role in ensuring value is delivered to the organization by the project outcomes.

Project Management in Multiple Contexts

Every organization is different, with its own culture, leadership, measures of success, and business strategy. This variation requires project managers to tailor, or customize project management approaches and processes to work within the organization’s unique environment or context.

As discussed in Chapter 1, the guidebook we reference throughout this textbook, PMBOK® Guide (PMI, 2021),^[7] is a collection of performance domains, methods, models, and artifacts generally accepted as best practices within the project management discipline. The PMBOK® Guide provides the fundamentals and common vocabulary within the project management profession. In addition, it identifies “good practices” of project management to apply skills, models, methods, and artifacts to enhance the prospect of successfully delivering project outcomes.

However, the PMBOK® Guide does not describe every step you must take to manage a project. Each project team and organization must determine the processes and strategies appropriate to their specific business, industry, and type of project. PMI calls this “tailoring,” and it is necessary to tailor processes, documents, and engagement strategies to fit your organization, team, and project characteristics.

Tailoring project management approaches and processes require a conscious awareness of project management principles (see Figure 1.7) and business needs. Tailoring does not mean a project manager can pick and choose processes and approaches whimsically, rather the project manager must carefully choose appropriate methods and activities to ensure the project delivers a new product, service, or result valuable to the organization.

Tailoring processes include adding, modifying, removing, combining, or aligning activities to eliminate unnecessary steps that might otherwise reduce the effectiveness and efficiency of project management processes (Figure 3.2). For example, suppose it is organizational policy not to allocate funding to projects but rather include the cost of project work in operational expenses. In that case, a project manager does not have to perform cost estimation, planning, and budget control activities. Likewise, if additional safety requirements or regulations need to be satisfied, a project manager can adapt the project life cycle to ensure the project meets those requirements.

Figure 3.2 Tailoring Process

Source: Original Work

Attribution: Juanita Woods, adapted from Project Management Institute, Standard for Project Management, 2021 (PMBOK® Guide 7E)

License: CC BY-NC-SA 4.0

Development Approaches

Development Approaches

Every project has a certain rhythm, or cadence, that reflects when certain activities occur while the project progresses. Additionally, the outcomes of projects can be delivered at one time or in stages, depending on the goals of the project and the beneficiaries’ project outcome needs. The rhythm of a project can be reflected in its development approach, that is, how the project outcomes are produced, and the life cycle, which reflects how the project phases, or stages of work, are structured to deliver outcomes.

According to the PMBOK® Guide, a development approach is “a method used to create and evolve the product, service, or result during the project life cycle.”^[8] A continuum of approaches exists, ranging from predictive to adaptive. PMs use predictive approaches when there is significant uncertainty associated with project outcomes or processes. Defining the project requirements as comprehensively as possible before producing results will limit uncertainty levels before incurring a significant project cost.

On the other side of the spectrum, PMs use adaptive approaches when customers cannot fully describe requirements before project work begins. In adaptive approaches, numerous cycles of definition, creation, evaluation, and adjustment often occur throughout the project’s life. Adaptive approaches incur costs in a more balanced way during the project’s life, unlike predictive approaches, which incur most of the project costs during outcome production.

Between predictive and adaptive approaches lies the hybrid approach that balances the uncertainty-reduction of predictive approaches with the flexibility of adaptive approaches (Figure 3.3). In addition, hybrid approaches may deliver outcomes iteratively, incrementally, or both. Iterative development includes frequent feedback loops during each project phase, while incremental development provides outcomes with progressively more features and functionality.

Figure 3.3 Development Approaches as a Continuum

Source: Original Work

Attribution: Juanita Woods, adapted from Project Management Institute, Standard for Project Management, 2021 (PMBOK® Guide 7E)

License: CC BY-NC-SA 4.0

Choosing a Development Approach

Project managers must consider several things when choosing the development approach for a project. Sometimes, the type of project or the organization’s project management processes dictate the approach; often, however, the project manager has discretion in choosing a method. The project manager should consider the following factors when deciding which approach to use on a given project. These factors relate to project outcomes (product, service, or result), project processes, and the organization. When a project demonstrates a need for both adaptive and predictive approaches, the PM may need to consider hybrid approaches.

Factors relating to the product, service, or result include the degree of innovation, certainty of requirements, stability of the project’s scope, ease of incorporating changes, delivery options, amount and type of risks, and safety or regulatory requirements (Figure 3.4).

Figure 3.4 Product, Service, or Result Characteristics to Consider When Selecting an Approach

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Factors relating to the project include stakeholder involvement, schedule constraints, and funding availability and timing (Figure 3.5).

Figure 3.5 Factors Relating to Project Characteristics

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Factors relating to the organization include its structure, culture, capabilities, and the size and location of the project team (Figure 3.6). Organizational culture includes the practices, norms, and values that influence how the organization relates to its employees and how employees relate to one another. Organizational capabilities include the intangible assets an organization uses to achieve its strategic goals and include the combined skills, talent, knowledge, and mindset of organizational leaders and members.

Figure 3.6 Factors Relating to Organizational Characteristics

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Project life Cycles

Life Cycles and Phases

The project manager and project team have one shared goal: to carry out the project's work to meet its objectives. Every project has a cycle: a beginning, a middle period during which activities move the project toward completion, and an ending (either successful or unsuccessful).

A project’s life cycle describes the structure and flow of project work that occurs as the project moves from start to finish. Different industries represent project life cycles in ways that make sense for their area of expertise. Regardless of the life cycle, each project phase includes several processes we use to manage the project. A phase represents a grouping of similar activities with a loosely defined beginning and end. In predictive approaches, phases are typically sequential, where the prior phase is complete before the next phase begins. With more adaptive approaches, phases may not have clear-cut end dates, and some activities in an early phase of the project will continue into its later phases. Project managers often use phase-gate reviews, or checkpoints, to confirm that the work to be performed in the current phase has been completed successfully, indicating that the team can move forward to the next phase.

Process-Based Life Cycles

When projects follow a set of processes to move from project identification to delivery, project managers may find it appropriate to organize the project life cycle into stages that reflect groups of similar processes. Such a strategy will simplify project status discussions and provide a meaningful framework to follow.

The Project Management Institute (PMI) developed a life cycle containing five process groups that many industries and project types find useful (Figure 3.7).^[9] The process groups are structured so that the outputs of one phase are inputs to the next. The work described in the process group phases most often refers to project management activities that ensure project deliverables meet customer expectations.

Figure 3.7 A Process-Based Life Cycle

Source: Original Work

Attribution: Juanita Woods, adapted from Project Management Institute, Standard for Project Management, 2021 (PMBOK® Guide 7E)

License: CC BY-NC-SA 4.0

The five process groups in this process-based life cycle include:

• Initiating – the processes completed during project initiation to define the project, phase, or contract. Authorization to proceed to the next stage generally happens when the project is described in enough detail to be planned and elaborated in the next phase.
• Planning – processes that include elaborating the project scope, schedule, budget, and other aspects of the project, phase, or contract. Authorization to proceed to the next stage generally happens after a detailed plan has been documented and approved, including scope, schedule, and budget baselines, and plans to manage resources, contracts, risk, stakeholders, and other project areas.
• Executing – processes that ensure the project team is producing the deliverables required by the project. These processes often happen in parallel to the monitoring and controlling processes.
• Monitoring and Controlling – processes that the project manager follows to ensure work is progressing as expected, changes are evaluated, and project performance is measured and reported. The plans documented during the planning stage are enacted here to keep the project “on track.”
• Closing – processes completed to wrap up a project, phase, or contract and deliver outcomes to the appropriate stakeholders. Activities included here allow for the formal handoff of project outcomes, releasing project resources, and closing procurements.

Aligning Approach, Cadence, and Life Cycle

The development approach and delivery cadence influence how a project is structured. Below are four examples of life cycles that consider the approach and cadence of project work.

Predictive – Single Delivery

Projects using a predictive-single delivery life cycle generally produce a product, service, or result that can only be delivered all at once. The phases of this life cycle flow in a sequential pattern, with one phase ending before the next one can begin.

Examples of projects that would use a predictive-single delivery life cycle might be a new home, a small building, a wedding, or a similar one-time event (Figure 3.8). A wedding exemplifies a linear project focused on one outcome, the wedding day. The project would begin after the proposal is accepted and the couple hires an event coordinator. The event coordinator would start planning, making reservations, paying deposits, and ensuring the bride gets the wedding of her dreams. After planning, the wedding day arrives, and while the bride, groom, and guests are busy enjoying the hard labor of the wedding coordinator, the wedding coordinator makes sure the wedding and reception occur without issues. After the wedding (and honeymoon), it’s time to close the project by paying the bills and moving on with life.

Figure 3.8 Example Life Cycle for a Wedding Using a Predictive Approach

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Iterative – Multiple Deliveries

Projects that use an iterative approach to delivering multiple versions of a product, service, or result would use this life cycle. Each phase of the project will focus on enhancing the initial version of the outcome delivered. For example, a research paper project might follow this approach (Figure 3.9). Notice the incorporation of feedback from one iteration to the next.

Figure 3.9 Research Paper as an Iterative Multiple Delivery Life Cycle

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Incremental – Multiple Deliveries

Instead of enhancing a single product, service, or result through multiple iterations, projects that use an incremental approach to delivery add new features and functions to a baseline product, service, or result in increments. Each increment has additional features and functions that were not present in the baseline, or first, version of the outcome.

For example, a small team of students might develop a reservation and ticketing system for Student Government Association (SGA) events (Figure 3.10). The first system version would include students' ability to reserve tickets online. After that, students would need to go to an office to pay for the tickets and pick them up. While the SGA uses the system for events at the start of the semester, the development team works on the next increment, allowing students to pay for their tickets online, though they would still have to go to an office to pick them up. The development team continues their work while implementing this system for the end-of-year events. By the spring, the reservation system now allows self-printing tickets, even allowing students to gift tickets to other students.

Figure 3.10 An Incremental Project with Multiple Deliveries

Project Phases

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Adaptive – Periodic Deliveries

Adaptive life cycles incorporate feedback throughout the development of products, services, or results. Agile is a broad term for adaptive project management techniques. Rather than trying to develop all aspects of a project or software application and then present that result to the customer after a long development cycle (6 to 24 months), Agile techniques use short development cycles in which features of high value are developed first, and a working product/software is reviewed and tested at the end of the cycle (typically from 14 to 40 days).

This process allows the customer to verify that features are being developed as they want and allows them to suggest improvements. It also offers the customer the opportunity to release the product or software earlier than initially planned if the version presented at the end of a cycle is deemed good enough. This option is one of the many reasons Agile is favored for software development. With Agile, companies can bring products to market quickly and continuously improve them with subsequent updates.

In the previous example of the ticketing system, the team continued to develop it based on their initial plan and internal assessment of the project’s priorities. However, if they were to incorporate feedback from the students using the system at stages along the way and adjust the focus of their work accordingly, the team would be using a more adaptive approach (Figure 3.11). For example, students may prioritize having a QR code on their phone to scan for admission over self-printing and gifting. In an adaptive project, this prioritization would drive the development team’s next steps.

Figure 3.11 Adaptive Life Cycle

Source: Original Work

Attribution: Juanita Woods, adapted from Project Management Institute, Standard for Project Management, 2021 (PMBOK® Guide 7E)

License: CC BY-NC-SA 4.0

For many years, traditional (predictive) and Agile (adaptive) project managers viewed each other with a certain amount of skepticism regarding the value of each other’s methods. However, in recent years project managers have seen the value of techniques used in both project management approaches. As a result, it is not unusual to see a building design using Agile techniques and software development projects conducting a traditional risk analysis. Project managers must choose the best approach and life cycle for the project to complete successfully.

Delivering Value Throughout the Project Life Cycle

Throughout the project life cycle, a project manager should remember the value being delivered to the project recipient. Since projects are enacted to support strategic objectives, project managers must ensure that what is delivered meets the objectives. While value is technically delivered at the end of a predictive project, a manager ensures that activities to build value into the outcomes happen during the appropriate stages (Figure 3.12).

Figure 3.12 Processes in Delivering Value

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Aligning Project Scope to Project Value

A project charter may provide a high-level overview of how the project will deliver value, and is a good place for the project manager to start. Requirements and project deliverables should be described and documented considering why the project was started in the first place (see section 7.2).

Once all deliverables have been produced, the project manager reviews acceptance criteria and technical performance expectations to ensure the deliverables are complete. Acceptance criteria (also known as completion criteria) are the criteria that must be met by the deliverable before it is accepted by the customer or recipient. Acceptance criteria are usually high-level statements of what the deliverable is expected to accomplish, do, or be before it is determined ready to use. For example, an acceptance criterion for a new website might be, “the website contains all functionality specified in the version 1 requirements document.”

Technical performance expectations refer to the parameters in which a deliverable is expected to behave or function. For example, a new website may be expected to be available continuously, with response speeds of less than 2 milliseconds on an internal corporate network. The project manager documents these parameters as part of the requirements definition, which may also be documented in the deliverable descriptions or high-level scope statements.

Deciding on the Definition of Done

The project manager should not wait until the end of the project to determine what everyone means by “done.” Instead, they should establish a definition of done early in the project while defining the scope and deliverables. A good definition of done generally includes a checklist of all criteria that must be met by a deliverable before it is considered ready for use. The checklist items often include the acceptance and technical performance criteria.

Because change happens throughout a project, a project manager needs to update the criteria of “done” whenever changes to the project scope occur.

Ensuring Project Value with Quality Processes

Quality relates to how usable and valuable the project outcomes are to the end users. Incorporating quality prevention, appraisal, and correction activities in the project schedule helps ensure that the project outcomes delivered provide value to the organization. Building quality into a project through prevention, appraisal, and correction activities will be discussed in detail in section 8.5.

Identifying and Selecting Projects

The preceding chapters provide foundational knowledge about projects, project management, and how project managers can design projects that deliver value to their organizations by ensuring the project outcomes align with organizational strategy.

But where do these projects come from? This chapter will discuss common approaches to identifying and selecting projects in organizations.

Chapter Learning Objectives

• Understand how to align projects with organizational strategy.
• Understand the three main types of projects.
• Evaluate the importance of considering costs when identifying and selecting projects.
• Describe approaches to selecting projects using both non-financial and financial methods.
• Understand the role a project manager plays in the project identification and selection process.

Aligning Projects with Strategy

The problem facing most businesses and organizations is not uncovering possible projects but determining which projects to do given existing resources and time limitations, a process that ensures projects align with an organization’s strategy. An organization may be considering both internal and external projects for customers. Organizations may choose from numerous approaches for identifying and selecting projects, from qualitatively evaluating project goals to the financial and economic impact analysis of proposed projects. When identifying and selecting projects, project managers must understand several aspects of the project, including opportunity costs, sunk costs, ongoing maintenance costs, and other factors that can affect why a project might be selected.

Successful companies and organizations employ methodologies to choose the projects most likely to move the organization toward meeting its strategic goals. Some of these methods are simple, while others are more complex. The method(s) used should reflect the priorities and values of the organization. However, selection methods carry some uncertainty as many criteria involve subjective assessment, even in financial models.

The importance an organization places on a project directly influences the chances of the project’s success. For example, when conflicting demands for scarce resources arise, resources are usually given to the projects that the organization predicts will provide the most significant benefit.

Organizational leaders assess the importance of projects to the larger organization by investigating how a project supports the organization’s top priorities. The following four organizational documents can help confirm that a project’s identified needs and objectives are appropriate:

• Strategic plan (determines organizational strategy, vision, mission, and goals)
• Annual budget
• Capital appropriations plan
• Managers’ annual performance objectives (management by objectives).

One way that an organization can align its mission, vision, and values is through a balanced scorecard (Figure 4.2). Regardless of the method the organization chooses to communicate its strategy, it is vital to examine the organization’s relationship with outside clients/stakeholders and seek information from all possible sources.

Figure 4.2 An Example Corporate Strategy Balanced Scorecard

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Types of Projects

Organizations generally create three broad categories of projects: strategic projects, operational projects, and compliance projects.

Strategic projects involve creating something new and innovative. A new product, service, retail location, branch, division, or even a new factory might be a strategic project because it will allow an organization to gain a strategic advantage over its competitors.

Operational projects improve current operations. These projects may not produce radical improvements, but they will reduce costs, get work done more efficiently, or produce a higher-quality product. Often, external customers are unaware operational projects have taken place, though they may see some benefit in the company’s efficiency at a future date.

Compliance Projects must be done to comply with industry or governmental regulations or standards. Often there is no choice about whether to implement a project to meet regulations, but there may be several options to consider, any of which would result in meeting compliance requirements.

Anyone in an organization may identify a project, but that does not mean the identified project will be selected. Project selection is a crucial step to ensure that projects undertaken by the organization align with the strategic, operational, or compliance targets. Project managers may not directly participate in project identification and selection, but they must understand how projects are identified and selected. Knowing the organizational processes to identify and select projects will allow the project manager to ensure that the projects undertaken align with the organization's goals.

Cost of Projects

When evaluating potential projects, organizational leaders need to consider four main costs: project costs, opportunity costs, sunk costs, and the total cost of ownership.

Project Costs are those costs directly associated with the project, including:

• Direct costs, such as materials, labor, and equipment,
• Indirect costs, such as insurance and project manager labor, and
• Contingency funds and budgetary reserves.

These costs add up to the total estimated cost of our project. Details regarding how to calculate these costs are covered in Chapter 9. Whenever a project is selected to move forward, others are rejected and may never be completed. We will never be able to reap the rewards of the projects we don’t complete. The cost of NOT doing a project is considered the opportunity cost.

Sunk costs are costs that have been put into a project and cannot be recovered. We talk about this type of cost here because sometimes projects may have costs incurred before the project is formally approved. Even though these costs have already happened, organizational leaders should not consider sunk costs when selecting projects.

Sunk costs are significant because people often make decisions based on data and emotions. Project managers want their projects to move forward and are generally optimistic about the future. As a result, their judgment can be clouded by what they want to happen. It may be difficult for them to step back and realize that a project should be canceled rather than investing more time and money into what will be neither beneficial nor profitable.

However, with a project that produces a physical product or deliverable, such as a building, not all costs are sunk forever. When a building has outlived the useful life for which it was designed, it can still have some value as an asset.

When our project involves the creation of a physical product, we need to consider the cost of operating or maintaining that product after the project is complete. For example, consider the construction of a new school with 20 classrooms. Each classroom will have a digital projector for use by the teacher. If the project team evaluates the projectors based on their initial cost and accepts the lowest bid that meets the technical specs, then over time, the school may suffer higher costs for operating and maintaining the projectors. The total initial cost of the projectors (or any item) and the cost to operate (e.g., electricity costs) and maintain them (e.g., cost to replace the lamps) is called total cost of ownership, or TCO.

Selecting Projects

Evaluating Projects for Selection

Organizations select projects by comparing the costs and benefits of potential projects. Some of the selection methods are more subjective than others, but all try to use a standard set of criteria to determine which project is the best for an organization to pursue. The process an organization follows when selecting projects depends on several factors, including the type of organization or industry, the size of the organization, and the amount of risk an organization is willing to take.

Of course, companies are not limited to just one methodology when choosing a project. They can and typically do use a combination of selection criteria. The project selection process is a series of screens that filter many ideas, opportunities, and needs to a few approved projects. The organization selects a subset that warrants consideration from all available ideas, opportunities, and needs, given its alignment with the organization’s strategy. As projects progress, they are subjected to a series of decisions based on various business and technical feasibility considerations.

Before exploring the various project selection methods, we should mention that projects are sometimes selected because of political or emotional considerations rather than purely objective comparisons. For example, a high-level executive may have an idea for a project and the power to make sure it moves forward, regardless of the soundness of the project or its imagined benefits. These projects are referred to as “sacred cows” because the project is being completed to meet the wishes of an executive or leader within the organization and cannot be canceled. This practice is simply a reality that many project managers face in their daily work. However, when taking a PMI exam, remember that PMI assumes organizations will always follow a proper and rational approach to project management selection and that politics will not intrude into the decision-making process.

Qualitative or Non-Financial Scoring Methods

Qualitative Scoring Methods for project selection are non-financial assessments of project alignment with the organization’s strategy and allow for input from many people about the projects up for review. Qualitative scoring methods can take a variety of factors into account. These elements range from simple checklists (Figure 4.3) to complex weighted scoring systems. Scoring models might survey various experts and have them rate the project in terms of importance to the company or relative chance of success.

Figure 4.3 A Simple Checklist

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Checklists are simple to use and understand, although there are advantages and disadvantages to using a checklist for project selection (Figure 4.4). A set of selection criteria is generated and agreed upon by the major project stakeholders or sponsors. Those who study management might refer to these criteria as Critical Success Factors (CSF). These elements can be measurable indicators of success that tie to an organization’s strategy, for example, “the project is likely to attract 3,000 new customers to our store in the next 12 months,” or, “the project is likely to make a 30% return on investment.”

Figure 4.4 Advantages and Disadvantages of a Checklist

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Each project is reviewed and scored against the success criteria in a simple checklist. Scoring can be done by a wide range of people inside and outside the organization, and good practice suggests soliciting input from a diverse group of subject matter experts. The project with the most boxes checked is the highest priority project.

Since decision-making models often consider numerous criteria when evaluating projects, tools such as the weighted scoring model are beneficial. Weighted scoring models introduce objectivity in what could otherwise be a very subjective decision-making process.

A weighted scoring model, therefore, allows decision-makers to structure the decision-making process by:

• Specifying and prioritizing needs by identifying decision-making criteria; then
• Evaluating, rating, and comparing different alternatives; and
• Selecting the best matching solution.

Creating a weighted scoring model starts with careful consideration of decision-making criteria. In the case of project selection, many organizations refer to their strategic plans or departmental goals to identify important factors that are often a mix of financial and non-financial criteria. Once the criteria have been selected, we give each criterion a weight value to indicate its relative importance. The more important the criterion, the higher its weight. Each potential project gets evaluated against the criteria and given a score.

A separate section containing these most important criteria can be put into a checklist to ensure that a project meets an organization’s “must have” criteria. If the project fails to meet one or more of these factors, then it will be rejected before it is evaluated by the weighted scoring model.

Weights can also be assigned to the critical success factors to reflect the relative value of some factors over others. For example, equal weight may be given to the product design and to the cost of maintaining the facility. Alternatively, different weights may be given to different criteria to reflect the relative importance of each to the organization. It is only essential that the sum of all weights equal 100%. In Figure 4.5, the weight column shows that the highest-weighted consideration for this set of projects is whether they are likely to make $30,000 or more in revenue per year. The lowest weighted criterion is whether the project will positively affect the organization’s reputation in the press. This does NOT mean that good press is unimportant to the organization. In fact, all other criteria being equal, in this model, a project that generates good press would be chosen over one that does not.

Weighted scoring models have several advantages over simple checklists:

• Political games/sacred cows are exposed.
• Allows ranking of projects according to impact on key performance indicators for the company.

Figure 4.5 Weighted Scoring Model with Critical Factors and Weighted Scoring

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Economic or Financial Scoring Methods

Economic scoring methods assess the project's ability to help the bottom line by increasing profits or reducing costs. These models often look at the cash flow that a project will generate after it is completed. Economic scoring methods for project selection compare the costs and benefits of different projects. While these models generally are unbiased, they may still involve some subjective risk as, in many cases, forecasts of sales, savings, or returns on investments are still estimates and not guarantees.

Economic scoring methods include:

• Payback period
• Time value of money
• Net present value
• Internal rate of return
• Benefit-cost ratio

The payback period is generally the most common method used in many organizations, especially government and non-profits. In it, one calculates the amount of time it will take to recover the project's costs through either increased revenue or reduced operating costs. For example, ABC Corporation of Arizona is considering a project to address rising energy prices through solar panels. The project is not meant to eliminate all external power needs, though. The estimate for the project is $70,000. The accounting department estimates the company will save $10,000 annually by enacting this project. Therefore, ABC Co. should recover its initial investment within seven years at current rates. If rates increase, that payback period may be even shorter.

The time value of money considers that future dollars are worth less than current dollars. How much less depends on how well you can make your current dollars and predicted inflation rates work for you. Net present value is one way to account for the time value of money in project selection. NPV uses a discount rate that reflects the future decrease in the value of money each year.

Internal Rate of Return (IRR) is another measure that considers the future value of money, but rather than calculating a dollar amount, IRR is expressed as a percentage. This percentage represents the return a company will receive from an investment. When calculating IRR for a project, those with a negative IRR should be rejected, and those with a positive IRR should be considered. When choosing between two or more mutually exclusive projects using IRR, the project with the highest positive IRR should be selected.

Another technique is the Benefit-Cost Ratio (BCR) method. This method compares the benefits of doing a project to the costs associated with the project and factors in the time value of money. Benefit-cost ratios are often used on large public works projects. Quantifying benefits and costs can be lengthy and complicated, and companies will have their own ways of arriving at those numbers.

Calculating Payback, NPV, IRR, and BCR can require the consideration of many factors and is often done with assistance from accounting departments. The terms should be familiar to finance and accounting students. For project management purposes, the key is that financial models often do not consider company priorities and longer-term, non-financial goals.

Figure 4.6 Summary of Economic Scoring Methods

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

 Constrained Optimization Methods

Constrained Optimization Methods of project selection are mathematically intensive means of analyzing a series of projects and are not easily generalized. In project management, these methods can include:

• Linear Programming
• Dynamic Programming
• Branch and Bound Algorithms
• Integer Programming

We might also refer to constrained optimization methods as mathematical approaches to project selection. These methods are beyond the scope of this text, but students preparing to take PMI exams should know that if they see any programming or algorithms used for project selection, a constrained optimization method is being used.

A Project Manager's Responsibility in Project Selection

It is vital that project and program leaders understand an organization’s strategies and objectives. This knowledge allows them to ensure that the decisions made in their projects and programs align with the organization’s strategic goals and they fulfill their project selection responsibilities. Project and program leaders can assess the complexity of a change initiative. Generally, more complex initiatives are riskier and require a more extended implementation and business benefits realization period. Therefore, project selection decisions will weigh the benefits offered with the time frame required to realize these benefits. Projects that offer significant benefits that can be realized relatively quickly are more likely to be approved.

When participating in the project selection process, pay attention to the following red flags, which often signal a poorly conceived project:^[10]

• Lack of strategic fit with the mission
• Lack of upper management support
• Unclear responsibility for project risks
• Risks outweigh potential benefits
• Unclear or unrealistic time frame, budget, or scope
• Unclear or unattainable project requirements or insuperable constraints
• Unclear responsibility for project outcomes

Practical Tips for Project Selection

An effective project manager should consider nine practical tips when selecting projects.

Tie every project to your organization’s strategy. Make a conscious effort to connect your organization’s strategy to every project you manage to help all stakeholders understand their greater purpose. For example, your organization might settle on pursuing government contracts. This move would involve learning everything about government contracts, which requires careful adherence to the details of a request for proposal (RFP) and then pursuing government contracts systematically. An organization taking this approach would have a greater chance of success than one that occasionally pursues government contracts without seriously attempting to learn the ins and outs of such work. 

Identify the decision-makers in your organization. An effective project manager understands which people in an organization have the influence to make a project happen and addresses the interests and concerns of those decision-makers. 

Understand your organization’s project selection process. It’s essential to understand how your organization decides which projects to take on, as it is critical to how you seek approval for your project and how you present it to decision-makers.

Learn all you can about your organization’s project selection criteria. In many organizations, the criteria for project selection are not always clear. Seek opportunities to engage with colleagues and managers who can help you better understand how and by whom decisions about project selection and continuation are made. This strategy can be a good information source if your organization has a Project Management Office (PMO).

Be ready to adapt to a change in strategy. Implementing an organizational strategy requires discipline and tradeoffs. Ideally, upper management monitors a strategy's effectiveness, just as a project manager monitors a project and makes changes when necessary. If external factors force your organization to change its strategy, you must be ready to adapt.

Accept that an approved project could be canceled at a later stage. A project might get a green light during the selection process, only to be terminated later by another decision maker who might be an officially designated exit champion or someone who isn’t interested in the project. In either case, you need to be flexible and adaptable. 

Be mindful of how your project connects with related projects. The interdependence of projects can affect an organization’s portfolio strategy. One project may not have value except in conjunction with other projects. Keep in mind that executing all or none of a cluster of related projects or a program may be necessary.

Be mindful of the importance of having key personnel available. Often, the biggest constraint on projects is getting key personnel assigned and working. 

Keep in mind the relationship between strategy and scope. When discussing altering the scope of a project, take some time to determine if the altered scope conflicts with your organization’s strategy. If it does, then it’s probably not a good idea. If your team and the sponsors agree to a change in scope, this must be documented and signed off on by all parties to ensure agreement.

Chartering Projects

Regardless of the approach you take to planning and managing a project, every project needs a clear starting point that is visible to all stakeholders connected with the project. This starting point has many names, depending on the industry and type of project, but for our purposes, we will use the term “project initiation.” Project initiation activities include establishing a high-level agreement for a project and developing a charter to ensure the project will address business needs. Typically, a business analyst will work with a project manager to ensure they hear all interested parties and meet the beneficiary organization’s needs.

At this point, we don’t know much about the project other than it met the organization’s selection criteria, and we were assigned as project manager. Often, a project manager’s first job is to describe the project at a high level so the organization can start assigning resources to the project's subsequent phases.

Project definition begins with developing a “30,000-foot view” by interviewing the project sponsor, key stakeholders, and presenting what we know in a project charter. This chapter discusses the processes often followed in project definition, charter development, and communications planning.

Chapter Learning Objectives

• Understand the importance and process of chartering projects and demonstrate the ability to create a project charter.
• Understand the role of the business analyst to ensure business needs are met by project outcomes.
• Evaluate the importance of good communication in project management.
• Create a communication plan.

Defining the Project

After selecting a project (see section 4.4), the project champion identifies the objective or need, which can be a business problem or opportunity. Before assigning a project manager to describe the project in more detail, an organization may complete a business case or feasibility study to ensure the proposed benefits outweigh the cost of doing the project.

An appropriate response to need is sometimes documented in a business case with recommended solution options. After a business case is documented, a feasibility study may be conducted to investigate whether the various options offered by the business case address the project objectives and determine a final recommended solution. Issues of feasibility (“can we do the project?”) and justification (“should we do the project?”) are addressed. Once the recommended solution is approved, a project is initiated to deliver the approved solution, and a project manager is appointed.

Chartering projects is often the first phase where the project manager becomes directly involved and begins to plan the project and work with the project team. Developing the project charter produces a document that outlines a project’s framework and primary goals, provides an initial identification of project stakeholders (see section 6.1) and risks (see section 10.1.4), and authorizes the project manager to acquire resources and move forward. The project’s outcomes and participating work groups are identified, and the team begins to take shape. Developing the charter produces a clear mandate for a successful project that everyone on the team understands and agrees to before proceeding to the next phases.

The Project Charter

The project charter provides essential information about a project and is used to gain authorization to start it. The charter document can be a single page or many pages. Ideally, it will be short (less than 5 pages) and written in clear, concise language so that anyone who reads it, regardless of their technical background, will have a solid understanding of the project. Most project charters include a place at the end of the document for approval sign-off by sponsors or customers (i.e., those who are paying for the project).

The project manager uses the charter during the project's planning phases. The project charter informs the project manager about what skills will be required on the team and indicates the project’s general scope of work. An approved project charter authorizes the manager to begin planning and acquiring resources.

Some organizations skip creating a project charter, viewing it as a document that wastes time to create and contains information that "everyone already knows." This approach can be a big mistake. The project manager and stakeholders can reference the charter if some of the project's goals are not met or if they are asked to do something outside the project's scope. A well-drafted project charter can prevent political interference in achieving project goals and reduce scope creep. In many organizations, the project charter may be the only formal document defining the project.

Key stakeholders contribute to the project charter to outline their shared vision (sometimes with the help of a project manager or PMO). Creating the charter prompts stakeholders to reevaluate assumptions about the project's purpose. Any differences in understanding about the project's goals can be resolved as quickly as possible in this stage.

Contents of a Project Charter

Many templates are available for project charters which vary in content and level of detail. For instance, the PMI-affiliated website ProjectManagement.com offers several project charter templates.

At a minimum, good project charters will contain the following sections.

Project Information

This section includes identifying information about the project, including the project name, project manager, and sponsoring organization. Details in this section are typically defined by the organization’s project management policies.

Project Purpose

This section should provide a broad overview of the project and answer the following questions:

• What is the purpose of the project?
• Where did the project originate? Have we conducted similar projects in the past?
• Who is the project manager, and what authority does the project manager have?

Business Case

The Business Case answers the following questions:

• Why was this project selected to move forward (project justification) over others?
• What selection criteria were used? (see section 4.4)
• What problems is this project solving, or what opportunities is it creating? What are the high-level requirements?

Project Goals

Listing project goals ensures that the stakeholders will not be disappointed when the project is completed. This section should answer the following questions:

• What are the broad goals of this project?
• How will we know if the project is a success (what are our metrics for success)?
• Are there industry standards we are trying to meet or benchmarks for performance that we want this project to attain?

Key Stakeholders

This section describes the key stakeholders and their interest in the project. This need not be an exhaustive list of stakeholders but should contain a list of people who are interested in the project and who will pay for or benefit from it.

Major Milestones

This section provides a summary of the major milestones for the project. A listing of any hard deadlines for the project should be included. Milestones, or target dates, can relate to project work (when are major deliverables expected to be complete?), outside constraints that affect the project timeline (such as the date of an event like an election or the first day of classes), and invoicing and payment deadlines. The list includes proposed start and end dates, with milestones listed in ascending date order.

Keep in mind that milestones are single points in time with zero duration. They are not lists of tasks that take place over time. For example, “Painting the Hallways” and “Painting the Bedrooms” are not milestones. “Hallway painted” is a well-written milestone.

Project Budget

The project budget section should provide an estimate of cost and information about how it was determined. It answers the following questions:

• What is the initial budget for this project?
• How was that budget developed?
• Are the numbers used for budgeting rough estimates based on top-down estimation techniques, such as analogous or parametric estimating, or are they hard constraints?
• What contingency funds have been allocated?

Constraints

This section will list any constraints on our project or the final product. Constraints are limitations or boundary conditions on the project. This section answers the following questions:

• What technology, training, knowledge, or skills does the team need to deliver the project outcomes?
• Are there technological training requirements or other limitations on the project outcomes?
• Are there regulatory constraints that our product must meet to be successfully marketed in certain countries?
• Are there other limitations we need to consider regarding our scope of work?
• Can the work only be done during certain hours or on certain days?

Assumptions

Assumptions are information we assume to be true as we plan a project. Identifying assumptions early on will help the project manager mitigate risks later. This section answers the following questions:

• What assumptions are we making about this project or the environment we are operating in?
• If we use physical materials, are we assuming that prices will remain stable over the project’s lifetime?
• Are we assuming we will receive funding on time and key team members will not retire or find other positions?

Risks

This section will list the risks that can currently be identified. Risks are uncertain events that may negatively affect a project and will be discussed in more detail in section 10.1.4. The risk list will be expanded when we develop a formal risk management plan. For now, we need to consider the significant risks involved in this type of project. The list of assumptions will help inform risk analysis.

Project Authorization

This part of the document provides a place for project sponsors to approve the project charter. By signing the document, the sponsors are giving the project manager authorization to develop the planning documents and start the project. Obviously, the project manager will communicate regularly with those authorizing the project after this stage.

Defining SMART Project Goals

In the early 1980s, George T. Doran introduced the SMART criteria for developing management goals and objectives.^[11] SMART is an acronym for Specific, Measurable, Assignable, Realistic, and Time-related. The SMART criteria have been applied in many different areas of management, including project management. Let's look at Doran’s criteria as they apply to project management.

Specific – A project needs to be specific about what it will accomplish. Unlike many organizational goals, the goal of a project should not be vague or nebulous. An organization may want to “make Gainesville, Georgia a great place to live,” but its projects need to focus on a specific goal, such as building a downtown farmers market. A project that is specific can be clearly communicated to all team members and stakeholders.

A specific project goal will answer the five ‘W’ questions:

1. What do we want to accomplish?

2. Why are we undertaking this project?

3. Who is involved in or will be affected by the project?

4. Where will this project be conducted?

5. Which constraints (scope, time, money, risk, etc.) have been placed on our project?

Measurable – How will project progress and success be measured? What will be the measurable difference once our project is completed successfully? These measures should be quantifiable.

Assignable (or Actionable) – Who will do the work? Can we identify people in the organization with the expertise to complete this work? Or can the expertise be hired from outside of the organization?

Realistic – Is it realistic that the organization can achieve this project, given its talents and resources? This is an essential consideration for businesses of all sizes. Yes, producing a new driverless car would be great, but is that realistic, given the organization's available resources?

Time-related – when will the project be completed, and how long will it take?

These criteria can be advantageous when defining a project. If the description for a project does not meet all these criteria, then it is time to go back to the drawing board and make sure that what is being described is a project rather than a program or strategic goal.

Ensuring Business Needs are Met

As discussed in section 2.1, projects deliver value by supporting organizational strategies. To ensure projects (and programs and portfolios) are aligned with organizational strategy to meet business needs, innovative organizations ensure business analysis processes are part of the project identification, selection, and planning processes. Business analysis applies knowledge and processes to identify opportunities and problems, recommend solutions based on business needs, gather and communicate requirements for new projects and products, and evaluate the benefits achieved through project work.^[12]

When done effectively, business analysis ensures business needs are met, risk and rework are reduced, product and service issues are minimized, and stakeholders are satisfied with the organization’s products and services. Business analysis begins with defining the problem or opportunity before projects are selected (see Chapter 4, Identifying and Selecting Projects) and ends with measuring the intended benefits of the project, program, or portfolio initiatives.

Business analysts are individuals responsible for supporting the business analysis function in organizations. Business analysts work closely with project managers to ensure the project accurately reflects the beneficiaries needs. Business analysts participate in the project charter’s development by gathering high-level requirements from key stakeholders and ensuring the scope reflects the business needs the project will address, as it is understood at this early stage. Business analysts will also help the project manager plan after the charter is approved and serve as customer or organizational representatives to ensure outcomes meet their needs.

Project Communications

The Importance of Communication

Successfully completing a project requires teamwork and effective communication among team members. If those team members work in the same building, they can arrange regular meetings, stop by each other’s workspace to get a quick answer, or even discuss a project informally at other office functions. On the other hand, many projects in today’s environment involve team members not located in the same building or city, making in-person meetings difficult. Teams that use electronic communication methods without face-to-face meetings are called virtual teams.

Communications management is about keeping everybody informed. Communications planning involves defining the types of information you will deliver, who will receive it, the format for communicating it, and the timing of its release and distribution. Much of a project manager’s time is spent on communication, so it is essential to ensure everybody gets the right message at the right time.

All projects require sound communication plans, but not all projects will have the same types of communication or the same methods for distributing information. For example, will data be distributed via mail or email, is there a shared website, or are face-to-face meetings required? The communication management plan documents how the project team will meet the stakeholders’ communication needs. This plan also includes the types of data the team will communicate, who will initiate communication, and who will receive it; the methods used to communicate; communication timing and frequency; the method for updating the plan as the project progresses, including the escalation process; and a glossary of standard terms.

The first step in defining your communication plan is figuring out what information your stakeholders need from the project to make good decisions. Your project will produce much information, and you do not want to overwhelm your stakeholders. Your job is to figure out what they feel is valuable. Communicating valuable information does not mean you always present a positive picture. Communications to stakeholders may consist of either good or bad news. You do not want to bury stakeholders in too much information; instead, you want to give them enough so that they can be informed and make appropriate decisions.

The information you will typically communicate includes project status, scope statements and updates, baseline information, risks, action items, performance measures, project acceptance, and so on. The stakeholders’ information requirements need to be determined early in the planning phase of the project management life cycle so that while you and your team develop planning documents, you already know who should receive copies of them and how they should be delivered.

Finally, consider project duration and environment. Will the technology you choose work throughout the project’s life, or will it be upgraded, updated, or discontinued? And how does the team function? Are they located together or spread out across several campuses or locations? The project team should document the answers to these questions in the communication plan. All projects require a sound communication plan, but not all projects will have the same types of communication or the same methods for distributing the information. The communication plan documents the types of information the stakeholders need to know, when the information should be distributed, and how the information will be delivered.

Communication Media

Communication media, or the way project information is shared, can take many forms, such as formal reports, conversations, emails, meetings, online dashboards, and collaboration platforms. You should consider timing and technology before choosing the methods you will use to communicate information. The first factor is the timing of information exchanges. Daily communication may be too much; monthly is likely not enough. One update per week is appropriate for most projects. Hold project meetings as required, but don’t let too much time pass between meetings. Be sure to answer stakeholders’ questions and emails promptly. Regular communication is always appreciated – and may even soften the blow when you have bad news to share.

Second, do you need to procure new technology or systems, or are there systems already in place that will work? The available technologies should figure into your plan to notify everyone of project status and issues. Staff experience with technology is another factor. Are the team members and stakeholders experienced using this technology, or will you need to train them?

Consider how stakeholders wish to obtain information. The PM may consider “push” versus “pull” techniques for information. Some stakeholders prefer the PM to push, or send, information to them regularly, such as an email with a project status report. Others may prefer to pull the information conveniently by going to an online project dashboard that displays updated progress reports and metrics.

Synchronous Communications

If all parties involved in communication are participating in the exchange simultaneously, the communication is synchronous, such as when making a telephone call or holding a video conference. Other examples of synchronous communications include:

• In-person meetings: Gathering of team members at the same location
• Virtual meetings: includes sharing audio, video, and documents between participants who are not at the same location
• Instant messaging: Exchanging text or voice messages using electronic devices
• Online collaboration platforms: a shared repository for project information, including options for communications and messaging.

Modern communication technologies make it possible to assemble project teams from anywhere worldwide. Most people work during daylight hours, making synchronous meetings difficult if the participants are in different time zones. However, they can be advantageous in some circumstances; for example, if something must be done by the start of business in Boston tomorrow, team members in Asia can work on the problem during their regular work hours while team members in North America get some sleep.

Asynchronous Communications

Getting a team to meet at one time can be challenging, especially if they are spread out across time zones. However, many communication types do not require everyone to be present simultaneously. This type of communication is asynchronous. Several choices of asynchronous communications exist, including physical mail and package delivery, fax, email, and online collaboration technologies.

Email is widely used to coordinate projects and to communicate between team members. Information can be sent to a list of team members. Messages can be saved to document the process in case of a misunderstanding or miscommunication. Files can be attached and distributed. However, email can also be used too much, overwhelming stakeholders. Project managers should balance emails with other means of communication like collaboration portals or project dashboards to reduce information overwhelm.

The ability to collaborate with people anytime and anywhere has increased over the last 15 years thanks to technological advances. These tools allow project teams to communicate quickly, share information, and plan and coordinate work. All they require is a computer and a connection to the Internet. A good collaboration tool will be easy to use and not interfere with work, which is delivering the product, service, or result the project was assigned to deliver. Collaboration technology may also improve team development for teams who do not work together in one physical location.

Culture and Communication

When working with internal and external customers on a project, project managers must pay close attention to relationships, context, history, and corporate culture. Corporate culture refers to the beliefs, attitudes, and values that organizational members share and the behaviors consistent with them. Corporate culture sets one organization apart from another and dictates how members of the organization will see you, interact with you, and sometimes judge you. Often, projects have a specific culture, work norms, and social conventions.

Some aspects of corporate culture are easily observed; others are more difficult to discern. You can easily observe the office environment and how people dress and speak. In one company, individuals work separately in closed offices; in another, teams may work in a shared environment. The more subtle components of corporate culture, such as the values and overarching business philosophy, may not be readily apparent but are reflected in member behaviors, symbols, and conventions.

Project managers must be aware of cultural norms around communications and incorporate them into their project communications plans. For example, in some cultures, communication must follow a specific hierarchy, with each layer only communicating with those immediately above or below. In other, more egalitarian cultures, a project team member might be expected to communicate directly and casually with the CEO.

Communication Planning

Once the corporate culture has been identified, members should try to adapt to the frequency, formality, and type of communication customary in that culture. This adaptation will strongly affect project members’ productivity and satisfaction internally and externally. Consider the following:

• Which stakeholders will be involved in decision-making? Will your project decisions and documentation have to go through several layers to get approval? If so, what criteria and values may affect acceptance in the organization? For example, is being on schedule the most important consideration? Is cost or quality more important?
• What type of communication among and between stakeholders is preferred? Do they want lengthy documents? Or is “short and sweet” the typical standard?
• What communication medium is preferred? What kind of medium is usually chosen for this type of situation? Check to see what others have done. Ask others in the organization.
• What vocabulary and format are used? What colors and designs are used (e.g., at Hewlett-Packard, all rectangles have curved corners)?

A communications plan is a document that lists all communications a project manager will deliver to manage a project (Figure 5.1). The information in the communication plan provides details about the timing (frequency), communication type, method of communication, audience, and content of each information exchange.

Figure 5.1 A Sample Communications Plan

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Managing Team Meetings

Team meetings are an important method of communicating project information and are conducted differently depending on the meeting's purpose, the leadership style appropriate for it, and team members’ personality types.

Action Item Meetings

Action item meetings are short meetings to develop a shared understanding of what the short-term priorities are for the project, individual roles, and expectations for specific activities. This type of meeting is for sharing, not problem-solving. Any problems that emerge from the discussion are assigned to a person, and another meeting is established to address the issue. Action item meetings focus on short-term activities, such as tasks that usually last less than a week. The action item meeting is fact-based and information oriented. This meeting has little dialogue except to ask clarifying questions. A problem-solving meeting or workgroup is arranged to deal with any problem or issue if a discussion is needed or a disagreement is not quickly resolved. On smaller topics, solutions meeting might occur immediately after the action item meeting and only include those interested in the discussion's outcome.

The project manager keeps the successful action item meeting short and focuses on only those items of information needed for the short-term project objectives. The project manager will restate the common understanding of what activities are priorities and who will be responsible for the activities. Often these meetings can include a review of safety or security procedures when these issues are relevant to the project. The leadership approach to action item meetings focuses on data, actions, and commitments. Although the project manager may observe stresses between team members or other issues, they do not resolve them in this meeting. These are fact-based meetings. If issues arise between people, the project manager will develop other opportunities to address these issues in another forum.

Management Meetings

Management meetings are longer in duration and focused on planning. They are oriented toward developing plans, tracking the progress of existing plans, and adjusting plans in response to new information. These meetings include discussions on generating a common understanding of the existing plan's progress. This discussion is based on quantitative information on schedule progress and other data, but the discussion is qualitative in evaluating the data to develop a complete understanding. The project manager solicits everyone’s experience and opinions, and when a disagreement about the data's meaning arises, encourages a deeper discussion to strengthen understanding. Through this discussion, a mutual sense of the project's status should emerge, and the project manager invites conversation, encourages people to offer their thoughts, and ensures that disagreements are positive discussions about interpreting the information. Disagreements should not become personal. Management meetings also focus on developing mid-term goals.

Project goals may be evaluated monthly or quarterly for larger, more complex projects. For smaller or less complex projects, weekly goals will provide the focus. The project manager focuses the discussion on broad priorities for the next period and includes all the functional leaders in the discussion. The goals that emerge from the discussion should represent a consensus on priorities for the next term.

For example, during a project's early phases, the team is focused on developing a conceptual understanding of the project. A major milestone on complex projects is typically the completion of the conceptual plan. The project manager would lead a discussion on what needs to be accomplished to meet the milestone and ask what potential barriers exist and what key resources are needed. From that discussion, the team develops a few key goals that integrate their various functions and focus them on priorities.

Management meetings combine information sharing with analysis, creativity, and innovation. The project manager allows and encourages conversation in developing and evaluating goals but focuses the discussion on both goals and obstacles. Management meetings provide an opportunity to discover obstacles to goal achievement. The project team reallocates resources or develops alternative methods for accomplishing the goals. As the team discusses goal progress, the project manager explores potential obstacles and encourages exposing potential problems in achieving goals. The project manager focuses the team on finding solutions and avoids searching for blame.

The project manager also uses a facilitative leadership approach, encouraging the management team to contribute their ideas. Then the PM builds consensus on what goals will bring the appropriate focus. The project manager focuses on developing these goals, tracking progress, identifying barriers, and adjusting efforts to accomplish current goals. Although there are typically meetings for scheduling and procurement and other meetings where goals are established and problems solved, the management meeting and goal development process create alignment among leadership on items critical to project success.

Leadership Meetings

Leadership meetings are held less frequently and are longer in duration. These meetings are used by the project manager to reflect on the project, explore its more significant issues, and back away from daily problem-solving. The project manager will create a safe environment for sharing thoughts and evaluations of less data-oriented issues. Leadership meetings creatively focus on the people issues of the project: the relationships with clients, vendors, and project teams. Team members who favor feeling, perceiving, and intuition may contribute valuable insights at this type of meeting. The team might also share perceptions by upper management and the community in which the project is being executed. Where the time frame for action item meetings is in weeks and management meetings is in months, the time frame for leadership meetings is longer and considers the entire project's length and impact.

Key Meeting Management Skills

Skilled project managers know what type of meeting is needed and how to develop an environment to support each meeting type. Action item meetings focus on information sharing with little discussion. These meetings require efficient communication of plans, progress, and other information team members need to plan and execute daily work. Management meetings focus on developing and progressing goals. Leadership meetings are more reflective and focus on the project's mission and culture. In addition to these three types of meetings, project managers may lead other types of meetings, depending on the need.

Specific problem-solving, vendor evaluation, and scheduling meetings are examples of other project meetings. Understanding what types of meetings are needed on the project and creating the proper focus for each type is a critical project management skill.

The project manager’s meeting management skills include creating the right atmosphere for team discussion. The manager creates an action item meeting for discussions based on data and facts. The conversation focuses on sharing information and clarification. The conversation for leadership meetings are different, where discussion is more open-ended and focuses on creativity and innovation. Because each type of meeting requires a different atmosphere and focus, mixing the purposes of a meeting will make it difficult for the project manager to develop and maintain the appropriate conversation for each stage.

Working with Project Stakeholders

Many individuals and groups may interact with projects in organizations. These individuals and groups may be affected by or have an impact on the project. A successful project manager will identify these individuals early, including those who can positively or negatively influence the project. In each case, the manager needs to identify what these groups want or need and their influence over the project. Based on this information, the team can identify project communication needs and develop a communication plan to be used during all project phases.

Chapter Learning Objectives

• Understand the importance of stakeholder identification and management.
• Identify and assess the needs of various stakeholders involved in a typical project.
• Discuss why the sponsor is the key ingredient to successful project completion.
• Develop and apply tools for managing stakeholders effectively
• Understand how a Stakeholder Register and Stakeholder Matrix are used.

Identifying Project Stakeholders

A project is successful when it achieves its objectives and meets or exceeds the stakeholders' expectations. But who are the stakeholders? Project stakeholders are individuals, groups, or organizations interested in a project and may affect or be affected by the project processes or outcomes (Figure 6.1). Stakeholders are those who care about or are vested in your project. They are actively involved with the project's work or have something to gain or lose because of it.

Figure 6.1 Project Stakeholders are Numerous

Source: Word

Attribution: Microsoft

License: © Microsoft. Permission granted by EULA.

For example, when you manage a traffic citation project (Figure 6.1), advocacy groups may be positively affected stakeholders. However, you may negatively affect the court system with an increase in traffic citations. Additionally, local law enforcement may be affected by different policies and procedures developed, and community members may be affected by changing policies.

Knowing the key stakeholders ensures a successful project. Key stakeholders' attitudes about your project or its outcomes can make or break the project success. Even if all the deliverables are met and the objectives are satisfied, if your key stakeholders aren't happy, it doesn't matter if the project outcomes are satisfactory.

Once you know the project stakeholders, you can create a stakeholder management plan. A stakeholder management plan is a guide that tells the project manager how to identify, analyze, and engage project stakeholders (Figure 6.2).

Figure 6.2 Stakeholder Management Key Processes

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

A stakeholder register is used to identify and track interactions between the project and each stakeholder. This register must be updated regularly, as new stakeholders can arise at any time, and a particular stakeholder's needs and interest levels may change throughout the project. We will discuss how to create a stakeholder register below.

The project sponsor (see section 1.3.1), generally organization executive with authority to assign resources and enforce decisions regarding the project, is a key stakeholder. Customers, subcontractors, suppliers, and sometimes even government agencies are stakeholders. The project manager, team members (see section 1.3.3), and managers from other organization departments are also stakeholders. It's necessary to identify all stakeholders in your project upfront. Leaving out crucial stakeholders or their department's function and not discovering the error until well into the project could be detrimental.

The number of stakeholders project managers must deal with ensures they will have a complex job guiding their project through the life cycle. Problems with any of these members could derail the project. Project managers must deal with people external to the organization along with the internal environment, which is undoubtedly more complex than what a manager faces in an internal environment. For example, suppliers who are late in delivering crucial parts may negatively impact the project schedule. To compound the problem, project managers generally have little or no direct control over any of these individuals.

Let's look at the different types of stakeholders and their relationships with the project manager (Figure 6.3).

Figure 6.3 Types of Project Stakeholders

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Top Management

Top management may include the company's president, vice presidents, directors, division managers, the corporate operating committee, and others. These people direct the organization’s strategy and development. On the plus side, you will likely have top management support with a project that aligns with the company's goals and values. Having top management support means it will be easier to recruit the best staff to carry out the project and acquire needed material and resources; also, visibility can enhance a project manager's professional standing in the company. On the minus side, failure can be dramatic and visible to all, and if the project is large and expensive (most are), the cost of failure will be more substantial than for a smaller, less visible project. Some suggestions for dealing with top management are:

• Understand what is important to them and what their preferred communication methods are. Do not waste time with unnecessary or inappropriate communications. For example, one executive might prefer to be called if a key event or milestone is about to be reached, while another may never want to speak via telephone.
• Develop in-depth plans and major milestones that must be approved by top management during the planning and design phases of the project.
• Ask top management associated with your project for their information reporting needs and frequency.
• Develop a status reporting methodology to include distribution on a predictable schedule.
• Keep them informed of project risks and potential impacts.

Your Manager

Typically, the boss decides assignments and who will work with the project manager on projects. Keeping your manager informed will help ensure you get the resources needed to complete your project. If things go wrong, having an understanding and supportive boss advocating for you is helpful. By supporting your manager, you will find that your manager will support you more often.

• Find out exactly how your performance will be measured. When unclear about directions, ask for clarification.
• Develop a reporting schedule and methodology that is acceptable to your boss.
• Communicate frequently in the manner your boss prefers.

Peers

Peers are at the same level in the organization as you and may or may not be on the project team. These people may also have a personal stake in your project's product, service, or result. However, they have neither leadership responsibilities nor accountability for the success or failure of your project. Your relationship with peers can be helped or hindered by how you work with them. Your peers may be working on projects that compete with yours, but there are ways to maintain positive working relationships. To ensure you have cooperation and support from your peers:

• Get the support of your project sponsor or top management to empower you as the project manager with whatever necessary authority is needed for success. The sponsor should express the project's importance to the organization and her expectations for all team members to work towards the success goal.
• If you notice a dysfunctional behavior, such as bad-mouthing the project, discuss it with your peer to determine if there are any underlying issues. This can also indicate that you are aware of the undermining behavior.

Resource Managers

Because project managers are in the position of borrowing resources, resource managers control the resources a project manager needs to complete a project. So, a project manager's relationships with resource managers are significant. If the relationship is good, project managers may be able to consistently acquire the best staff and equipment for their projects. If relationships aren't good, project managers may have difficulty obtaining good people or equipment needed for the project.

Internal Customers

Internal customers are individuals within the organization who are clients for projects that meet the needs of internal demands. The customer can accept or reject your work. Early in the relationship, the project manager must negotiate, clarify, and document project specifications and deliverables. After the project begins, the project manager must stay attuned to the customer's concerns and issues and keep them informed. Common stumbling blocks when dealing with internal customers include:

• A lack of clarity about precisely what the customer wants
• A lack of requirement documentation
• A lack of knowledge regarding the customer's department or division and their operating characteristics
• Unrealistic deadlines, budgets, or specifications requested by the customer
• Customer hesitancy to sign off on the project or accept responsibility for decisions
• Changes in project scope

To meet the needs of the customer, client, or owner, be sure to do the following:

• Learn the client's departmental terminology, culture, and business.
• Clarify all project requirements and specifications in a written agreement.
• Specify a change in procedure.
• Establish the project manager as the central point of communication for the project.

External Customers

External customers are the customers outside an organization. In the case of Ford Motor Company, for example, the external customers would be the buyers of automobiles. Also, if you manage a project at your company for Ford Motor Company, they will be your external customer.

Government

Project managers in certain heavily regulated environments (e.g., pharmaceutical, banking, or military industries) will have to deal with government regulators and departments. These can include all or some levels of government, from municipal, provincial, and federal to international.

External Partners

Sometimes organizations do not have in-house expertise or resources, so work is turned over to contractors or subcontractors. Contractors are team members who are not employees of the project's organization. These can be construction management supervisors, network consultants, electricians, carpenters, architects, lawyers, or other experts. Managing contractors or suppliers requires the same skills as managing full-time project team members. The same problems can arise with contractors or subcontractors, such as work quality, cost overruns, and schedule slippage.

Many projects depend on goods provided by outside suppliers. For example, construction projects will acquire lumber, nails, bricks, and mortar from outside suppliers. If the supplied goods are delivered late, in short supply, of poor quality, or if the price exceeds what was quoted initially, the project will suffer. Managing contractor and supplier relationships can consume most of the project manager's time, depending on the project's complexity. This task is not purely intuitive; it involves a sophisticated skill set that includes managing conflicts, negotiating, and other interpersonal skills, often while having few practical levels of recourse to address issues. If a contractor came about through a lengthy bid process, or is one of the only businesses in the region doing that work, firing the contractor may not be a viable option to address individual problems or issues. The PM may find that doing so would derail the project. Therefore, the PM needs to use their skills to resolve issues.

The Project Team

The project team is an essential stakeholder with a great deal of influence. Logically, the project team would want the project to succeed, but we must realize that the team might be composed of individuals with different and competing goals for what they want to see out of the project. Therefore, the project manager must understand the characteristics of effective teams to help their team be more effective (see Chapter 12).

Managing Project Stakeholders

Achieving a project's objectives takes a focused, well-organized project manager 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 be the difference between project success and failure.

Often there is more than one major stakeholder in a project. An increased number of stakeholders adds stress and influences the project's complexity level. The business or emotional investment of a stakeholder, and the stakeholder’s ability to influence project outcomes or execution, will also influence project complexity. In addition to the number of stakeholders and their level of investment, the degree to which the project stakeholders agree or disagree affects project complexity.

Analyzing Project Stakeholders

After taking time to identify the stakeholders, the project manager’s next step is to begin building solid relationships by actively engaging them in the project. The critical activities performed during stakeholder analysis include the following.

Stakeholder analysis, which assesses a project's key participants and how the project will affect their problems and needs, is an important step. During stakeholder analysis, the project manager identifies individual characteristics and interests and discovers what motivates and provokes project stakeholders. Defining roles and levels of participation helps reduce the chance of conflicts of interest among stakeholders.

A lack of stakeholder support can negatively affect a project. Whether stakeholders initially support your project or not, you should secure their support if they are essential to your project. Importance in the organization does not necessarily mean they are important to your project, however. Just because they think they are essential does not mean they are. Even if they don't think they need to be involved, they may have to be. The typical suspects are your manager, the manager's manager, customers, any subject matter expert (SME) you need, and the board reviewing and approving your project.

Note that in some situations, there are people who think they are stakeholders. From your perspective, they may not be, but be careful how you handle them. They could be influential with those who have the power to impact your project. Do not dismiss them out of hand.

The more influential a stakeholder is, the more a project manager will need to engage them. Consider the question, "What’s in it for them?” when approaching stakeholders. Knowing what each stakeholder needs or wants will enable the project manager to gauge their level of support. And remember to balance support against influence. Is it more important to have strong support from a stakeholder with little influence or lukewarm support from one with a high level of influence?

A project manager needs to determine what power the identified stakeholders have and their intentions toward your project. Do they have the power to have an impact on your project? Do they support or oppose you? What strategies can you use with them? The project manager also needs to evaluate any relationships between stakeholders. Can you improve your project’s chances by working with those who support you to boost the views of less enthusiastic people?

Finally, stipulate expectations for meetings. Ask for clarification when needed to be sure requests are thoroughly understood. Define “success.” Each stakeholder may have a different idea of what project success looks like. Discovering this difference at the end of the project is a formula for failure. Gather definitions up front and include them in the objectives to ensure all stakeholders support the outcomes.

Now that you have this information, you can conduct a stakeholder analysis to help define your strategies to improve their support. Because of the sensitive nature of this information, this document should be kept confidential by the project manager to avoid offending anyone. The stakeholder analysis should be used as a mechanism for you to understand your stakeholders and develop plans to engage and manage them during the project. A stakeholder register lets you document the results of the stakeholder analysis and includes the following information (Figure 6.4).

Figure 6.4 Stakeholder Register Contents

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

If you want to share information about project stakeholders with your team, consider creating a second version of the stakeholder register, which removes comments about their power, interests, or needs that might be detrimental to share with the team. A stakeholder register will help your project team understand the timing and methods of communicating with stakeholders during the project but keeps confidential information from being public.

Engaging Project Stakeholders

To help identify possible strategies for enhancing stakeholder support, you might consider using their levels of power and interest to determine an optimal engagement strategy. A power-interest grid can help with this effort; where stakeholders fit in the grid will help you determine how to engage and manage each one and the amount of attention to give each member.

Figure 6.5 Possible Engagement Strategies based on Power and Interest^[13]

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

General strategies for managing stakeholders depend on where they are placed on the grid, as follows:

• Important Stakeholders: Stakeholders with a moderate to high degree of influence and interest in the project require the project team to work closely with them and involve them in project planning.
• Influential Stakeholders: Stakeholders with high influence but little interest. These stakeholders need to be kept satisfied and informed about the project, so they are not surprised if there are changes or delays. These stakeholders can be a source of risk to the project.
• Interested Stakeholders: These stakeholders have a high degree of interest in the project, but less influence or power to affect the project. These stakeholders need to be kept informed of the project’s progress.
• Aware Stakeholders: Stakeholders in this box do not require much interaction from our project team. These stakeholders should be monitored in case their level of interest or influence changes but are generally the lowest priority for the team.

Learning to relate to stakeholders is the foundation of building strong stakeholder relationships. But as in any relationship, there are subtleties that successful project managers understand–such as learning the differences between and relating well to different stakeholder personalities.

By conducting a stakeholder analysis, project managers can gather enough information to build strong relationships–regardless of their differences. For example, the needs and wants of a marketing director will differ from those of a chief information officer. Therefore, the project manager’s engagement with each will also need to differ. Stakeholders with financial concerns will need to know the potential return of the project’s outcomes. Others will support projects if there is sound evidence of their value in improving operations, boosting market share, increasing production, or meeting other company objectives.

Keep each stakeholder’s expectations and needs in mind throughout each conversation, report, or email, no matter how casual or formal the communication may be. Remember that the company’s interests are more important than any individual’s–yours or stakeholders’. When forced to choose between them, put the company’s needs first. No matter what their needs or wants are, all stakeholders will respect a project manager who:

• Is always honest, even when telling them something they don’t want to hear,
• Takes ownership of the project,
• Is predictable and reliable,
• Stands by his or her decisions, and
• Takes accountability for mistakes.

Once you understand your engagement strategies, you can decide how and when to communicate with your stakeholders. A crucial part of your stakeholder management efforts is consistent, valuable communication. Using the information from your stakeholder analysis, you should develop a communications plan that secures your stakeholders’ support. A communication plan (see section 5.4.4) documents what information stakeholders want from you about the project, how often the information is needed, and in what format to present the information. Knowing how influential and interested each stakeholder is in the project will help you decide how, when, and what to communicate.

Identifying Project Outcomes

Project planning is at the heart of a project life cycle and tells everyone involved where you’re going and how you will get there. During project planning, the project plans are documented, deliverables and requirements are defined, and the schedule is created. Planning involves documenting processes to help guide your team through the project’s implementation and closure phases. The plans created during this phase will help you manage time, cost, quality, changes, risk, and related issues. They will also help you supervise staff and external suppliers to ensure that you deliver the project on time and within budget.

Project planning is often the most challenging phase for a project manager, as you need to make an educated guess about the staff, resources, and equipment needed to complete your project. You may also need to plan your communications and procurement activities and contract any third-party suppliers. The purpose of the project planning phase is to:

• Establish business requirements,
• Establish cost, schedule, list of deliverables, and delivery dates,
• Establish resource plans,
• Create plans to manage stakeholders, schedules, cost, quality, change, risk, and related issues during project production phases, and
• Obtain management approval and proceed to the next phase.

Project planning is one of the most important activities for which a project manager is responsible. Without proper planning, projects often fail to achieve their intended goals. Project planning activities refine objectives, which were gathered during project charter development. Activities include steps necessary to meet those objectives by identifying the tasks and resources required to complete the project.

Now that these objectives have been recognized, they must be clearly articulated, detailing in-depth scrutiny of each recognized objective. With such scrutiny, our understanding of the objective may change. Often, trying to describe something precisely gives us a better understanding of what we are looking at. This articulation serves as the basis for requirement development. This means that after an objective has been clearly articulated, we can describe it in concrete (measurable) terms and identify what we must do to achieve it. Obviously, if we do a poor job articulating the objective our requirements will be misdirected, and the resulting project will not represent the actual need.

We will discuss project planning processes and considerations in the following chapters. We will also examine several typical project documents developed during the planning process and explore ways to improve the project plans before beginning to work on producing outcomes. This chapter will explore the processes associated with defining and describing project outcomes.

Chapter Learning Objectives

• Demonstrate awareness of the importance and purpose of project planning and identify the fundamental processes and activities required in the planning phase.
• Demonstrate skills in defining and describing project scope and deliverables.
• Understand the various types of project requirements and give an example of each.
• Create a responsibility assignment matrix for project deliverables.

An Overview of Project Planning

The Planning Process

The planning process is an integral part of project management, but depending on the development approach, you may not know everything about a project before you begin. When we discussed development approaches in Chapter 3, we discovered that the approach taken depends on the level of uncertainty in project outcomes or the level of uncertainty in project requirements.

In predictive development approaches, where there is high uncertainty in project outcomes, the team must know what work needs to be done before work begins. In more adaptive approaches, planning the work in advance is less critical because the requirements are not fully known before the project begins. However, for either approach, it is possible to plan ahead.

Regardless of approach, the project manager gathers initial project facts from the project charter. In addition, background information on the stakeholder’s workplace, existing business model and rules, etc., assist in creating the vision of the final product, service, or result and the project scope.

The scope planning process is the first thing you do to manage your scope. Project scope planning includes defining all the work needed to successfully meet project objectives. Scope planning is a critical step because you need to have as clear a picture as possible of all work that needs to happen on your project, and as the project progresses, you need to keep that scope up to date and written down in the scope management plan.

Although the project scope is the primary document for identifying project deliverables, the work breakdown structure (WBS; 7.2.2) incorporates all project deliverables and reflects any documents or information that clarify the project deliverable. The project manager uses the WBS to develop a project schedule. The project schedule lists the activities needed to accomplish the work identified in the WBS. The more detailed the WBS, the more activities are identified to accomplish the work.

Once the team develops the WBS, the project manager will assign responsibility for each deliverable to key team members and begin scheduling project work based on what is required to produce each deliverable. At this time, cost and duration estimates can be identified, and project schedules and budget baselines can be established. Project planning ends when everyone clearly understands what, how, and when project outcomes will be produced and delivered during the next phase of the project (Figure 7.1).

Figure 7.1 Overview of Project Planning

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Tailoring Guidelines

Tailoring project management processes, tools, and techniques used during planning allows the project manager to consider the unique characteristics of the project environment as discussed in section 3.1. Tailoring during the planning process does not mean you do not identify project scope, work, costs, and risks. Tailoring does mean that you adapt the processes to fit your project and the organization. A small project, for example, may not need multiple rounds of requirement documentation. Adaptive projects identify a broad scope at the beginning and then progressively elaborate on deliverables and requirements as each stage progresses.

Identifying Project Scope

Project Scope and Deliverables

Project scope defines the characteristics of a project's outcomes and includes work done within its boundaries. The project scope is documented to clearly communicate what work will be accomplished by the end of the project—the deliverables. The project scope specifies what will, and in some cases what will not, be done. The documented scope is the basis for agreement by all stakeholders.

Scope statements may take many forms depending on the type of project being implemented and the nature of the organization. The scope statement details project deliverables and describes primary objectives. The objectives should include measurable success criteria for the project.

A scope statement broadly captures project outcomes, for example, the “development of a software-based system to capture and track orders for software.” A scope statement should also include the list of people using the product and the desired features. A baseline scope statement should contain the following information:

• Project name and identifier
• Link to project charter
• Project owner, sponsors, and stakeholders
• Project goals and objectives (what is “in scope”)
• High-level project requirements
• Project deliverables
• Exclusions (what is “out of scope”)
• Assumptions and constraints relating to project scope

A clear project scope statement is also critical to managing change. Since the project scope reflects what work will be accomplished, any changes in expectations that are not captured and documented create confusion and failure to meet requirements. If a sponsor and team member discuss a potential change to a specification and agree to it but do not propose it to the rest of the project team or the PM, it is likely not being documented. Without tracking and verifying these changes, it sets up the project team for failure.

One of the most common challenges project managers face is the incremental expansion of project scope by sponsors or customers. This trend is labeled “scope creep.” Scope creep occurs when the project sponsor or customers add deliverables without going through a formal review process. When scope creep happens, deliverables grow in number, feature, functionality, or type without a corresponding adjustment to the schedule, budget, and use of resources. Scope creep threatens the success of a project because the small increases in scope require additional resources that were not budgeted.

Due to project managers and team members wanting to please sponsors and key stakeholders, increasing project scope is common. However, changes and expansion of project scope should be documented and agreed upon. Adjustments should also be made to the project budget and schedule to account for these changes. The project manager considers the effects of the change on project constraints, discussed earlier (section 1.1.4). Scope creep occurs when these changes are not recognized or not managed.

In addition to scope creep, the expansion of scope can come from within the project team. Gold Plating occurs when project team members add additional features, services, or products to the project scope without prior approval. These features may or may not be appreciated by the sponsor. As these features are outside the agreed-upon scope of the project, they can significantly impact the project schedule and budget.

A project manager's ability to identify potential changes is often related to the quality of scope documents. Events do occur requiring the project’s scope to change. Changes in the marketplace, for example, may require changes in product design or product delivery timing. Changes in the client’s management team or financial health may also result in changes to project scope.

Changes in project schedule, budget, or product quality will influence the project plan. Generally, the later in the project the change occurs, the greater its impact on costs. The project manager is responsible for establishing a change management system. The system should capture changes to the project scope and ensure that these changes are authorized by the appropriate management level in the client’s organization. The project manager also analyzes the cost and schedule impact of these changes and adjusts the project plan to reflect the changes authorized by the client. Changes to the scope can cause costs to increase or decrease.

No single template works for all projects. Some projects require a detailed scope of work, and some have a short summary document. The more complex the project, the more detail is needed for success. The scope’s quality is measured by the project manager and stakeholders’ abilities to develop and maintain a shared understanding of what products or services the project will deliver. Well-written project scope statements should address the following:

• A clear description of the scope of work to be performed,
• Acceptance criteria for project deliverables,
• List or map of project deliverables,
• Scope exclusions (what is out-of-scope),
• Constraints to project scope, and
• Assumptions held when identifying project scope.

An experienced project manager can draw on past experiences with similar projects to forecast the work that can realistically be completed, given time and cost constraints. Communication and negotiation skills are a “must-have” as well. Project managers must prepare stakeholders for the impacts of choices made about project work. More deliverables add complexity to a project by requiring more staff, time, or money. Adding project scope may also have an impact on project quality. Some aspects of the project may be unfeasible–stakeholders need to know this to adjust their vision or prepare for future challenges.

Determining what should (and should not) be included in a project is a team effort and can be accomplished using one or more of the following techniques:

• Interviews
• Focus groups
• Facilitated groups such as JAD (joint application development)
• Group creativity techniques such as brainstorming, nominal groups, Delphi, mind map, or affinity diagnostics
• Prototyping/wireframing
• Observation
• Questions and surveys
• Group decision-making techniques, such as unanimity, majority, plurality, or dictatorship

Documenting Deliverables

You already have a head start on refining the project’s objectives in quantifiable terms, but now you need to plan further and write down all the intermediate and final deliverables that you and your team will produce throughout the project. One of the project manager’s primary functions is to accurately document project deliverables and manage the project so that they are finished or “delivered” according to the agreed-on criteria.

Deliverables include everything you and your team produce for the project (i.e., anything that your project will deliver). The deliverables for your project include all the products or services that you and your team are producing for the client, customer, or sponsor. They include every intermediate component that will be made along the way, including any project management documents you develop. Product deliverables are tangible outcomes, measurable results, or specific items that must be produced to consider either the project or the project phase completed. Project deliverables are the things you produce as you plan and manage the project, including schedules, budgets, tracking lists, and reports. Deliverables, like objectives, must be specific and verifiable. All deliverables must be described in sufficient detail to differentiate them from related deliverables. For example:

• A twin-engine plane versus a single-engine plane
• A red marker versus a green marker
• A daily report versus a weekly report

Now that we have well-defined deliverables and requirements, breaking down the project's work via a work breakdown structure (WBS) begins. The WBS defines the project's scope and divides the work into components that can be scheduled, estimated, and easily monitored and controlled. The idea behind the WBS is simple: you subdivide a complicated deliverable into smaller deliverables until you reach a product, service, or result that cannot be further subdivided (Figure 7.2). This process is called “decomposition.”

Figure 7.2 WBS for a Wedding

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Each descending level of the WBS represents an increasingly detailed definition of the project work. WBS describes the products or services to be delivered and how they are decomposed and related. It is a deliverable-oriented decomposition of a project into smaller components. It defines and groups a project’s discrete work elements in a way that helps organize and define the work. A WBS provides the framework for detailed cost estimating and control, along with guidance for schedule development and resource allocation.

It is important to note that we do not worry about the sequence in which the work is performed or any dependencies between tasks when we do a WBS. That will be considered when we develop the schedule. However, most people think sequentially. This approach can lead to team members spending too much time trying to get the WBS to conform to the order of work needed to achieve the deliverables. The main idea of creating a WBS is to capture all the deliverables, irrespective of their order.

A WBS can be structured in a way that makes sense to you and your project. In practice, the chart structure is often used, but a WBS can also be composed in outline form. The WBS can be organized by deliverable, where the project's major deliverables are used as the first level in the WBS. For example, the deliverables might include the book, audio file, and video if you are doing a multimedia project. Alternatively, you can organize the WBS by project phases in which each phase would represent the first level of the WBS, and their deliverables would be the next level and so on (e.g., planning, design, production, delivery).

Each element in the WBS needs to be assigned a unique identifier. This unique identifier is typically a number, and it will be used to sum and track costs, schedules, and resources associated with WBS elements. Project managers use the WBS during project execution to track the status of deliverables and work packages. The items in a WBS are numbered so everyone on the project team can easily understand the relationships between deliverables, sub-deliverables, and subsequent activities. Notice that in Figure 7.2, “Deliverable 2.1 Wedding Chapel” is decomposed into two sub-deliverables, “2.1.1. Location Contract” and “2.1.2 Decorations.” We can also recognize that “3.5 Other Participants” is a sub-deliverable of “3.0 Wedding Party” because both WBS identifiers begin with “3.”

This numbering system allows for easy reference and filtering. For example, a bridesmaid helping with the invitations only needs to receive details and updates related to sub-deliverables that start with “1.” (the invitations deliverable).

The project manager is free to determine the number of levels in the WBS based on the project’s complexity. You need to include enough levels to accurately estimate project time and costs but not so many levels that it becomes difficult to distinguish between components.

Regardless of the number of levels in a WBS, the lowest level is called a work package. Work packages are the components that can be easily assigned to one person or a team of people with clear accountability and responsibility for completing the assignment. Work packages contain information about the work to complete a deliverable, including time, cost, and resource estimates.

Another rule to remember is the 100 percent rule, one of the most essential things to consider when developing and evaluating the WBS. This rule states that each decomposed level (child) must represent 100 percent of the work applicable to the next higher (parent) element.

Once satisfied that all the deliverables are identified and decomposed to the best manageable level, you can create a WBS dictionary, a tabular representation of the deliverables. A WBS dictionary includes information about the source of deliverables, known requirements, assumptions and constraints about the deliverable, and any other information the project manager may need to further plan the project (Figure 7.3).

Figure 7.3 Sample WBS Dictionary for Wedding

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Assigning Responsibility for Deliverables

Once the project deliverables are identified and requirements are mapped to ensure they are identified and described, the project manager may now assign responsibility or oversight to each deliverable. A responsibility assignment matrix (RAM) lists product and project deliverables in the first column and key stakeholders across the top row. Each deliverable is mapped to one or more stakeholders to indicate who has responsibility or oversight to ensure that the deliverables are developed appropriately.

RAMs come in several forms, but one of the most useful is a responsible, accountable, consulted, and informed (RACI) chart, which designates each stakeholder’s relationship to each deliverable. RACI charts help project managers determine if they have enough resources for a project and record who is responsible for what (Figure 7.4).

In a RACI chart, stakeholders are given various types of responsibility toward the deliverable.

• Responsible - indicates who does the work to produce the deliverable
• Accountable - indicates who has final authority over the work package to ensure it was produced appropriately; only one person assigned
• Consulted - indicates individuals who provide information about the deliverable
• Informed - indicates who is informed after the work package is completed, often because his or her own work depends on it

Figure 7.4 Example RACI Chart for Wedding

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Project Requirements

After the high-level deliverables are identified, the project manager must document all the project requirements. A requirement is something needed or wanted by the project outcome recipients and is a necessary condition to project acceptance. Requirements describe the characteristics of the final deliverable, whether it is a product or service. They describe the required functionality the final deliverable must have or specific conditions it must meet to satisfy the project's objectives.

Requirements are gathered throughout the project defining process. In chartering, we collect high-level requirements because these may affect scope and deliverables. Then, as the charter comes to completion and gets signed off, these requirements help form the scope statement. However, on larger projects, requirements are more detailed during the planning stage. At this time, a project manager may facilitate a requirements session to gather more details about scope and deliverables. Business analysts support the project manager by identifying and documenting project requirements. Other subject matter experts become more involved as additional requirements not discovered initially during the chartering process are identified. These detailed requirements may increase the project’s complexity and introduce new scope or deliverables. Any changes need to be documented as they will be different from what is in the charter. A requirements traceability matrix (Figure 7.5) is used to track when requirements are identified and by whom.

The project’s requirements, defined by the project scope, describe what a project is supposed to accomplish and how the project is supposed to be created and implemented. Requirements answer the following questions regarding the as-is and to-be states of the business: who, what, where, when, how much, and how does a business process work?

Requirements may include descriptors relating to dimensions, ease of use, color, specific ingredients, and so on. Requirements specify what the final project deliverables should look like and what they should do. Requirements must be clearly stated and concise, measurable, testable, related to identified business needs or opportunities, consistent with other requirements, and defined to a level of detail sufficient for system design.

Requirements can be divided into six basic categories: functional, non-functional, technical, business, user, and regulatory.

Functional Requirements

Functional requirements describe characteristics of the final deliverable in ordinary, non-technical language. They should be understandable to customers, and customers should play a direct role in their development. An example of a functional requirement for the wedding deliverable 2.2 Reception Venue might be, “the venue must include 3 dressing rooms with vanity sinks, showers, and floor-to-ceiling mirrors for the bridal party.”

Non-Functional Requirements

Non-functional requirements specify criteria that indicate how you want the functional requirements to be delivered. Also called “features,” non-functional requirements may be used to judge the final product or service that your project delivers. They are restrictions or constraints to be placed on the deliverable and how to build it. Without any constraints, the solutions offered might result in anything being developed that would satisfy the project scope. Non-functional requirements can be split into two types: performance and development. Performance constraints describe how the deliverables should behave or appear.

For example, a performance requirement for the reception venue might be, “the venue should allow room for dancing and dining for 200 guests.”

Non-functional requirements are designed to restrict the number of options the team offers. In addition to performance constraints, it may be necessary to identify development constraints. There are three general types of non-functional requirements:

• Time: When a deliverable should be delivered
• Resource: How much money or which personnel are available to develop the deliverable
• Quality: Standards used to develop the deliverable, development methods, etc.

For the wedding reception venue, a non-functional development requirement might be, “the venue should be available the day of and the day after the reception.”

Quality requirements are an important type of non-functional requirement. It’s not enough to make sure you get a project done on time and under budget. You must make the right product to suit your stakeholders’ needs. Everybody “knows” what quality is. But the way the word is used in everyday life differs from how it is used in project management. Quality is the suitability of project outcomes for their intended purpose and refers to “fitness-for-use” or a product or service’s ability to satisfy customer requirements.

Quality means ensuring that you build what you said you would and do it as efficiently as possible. And that means trying not to make too many mistakes and always keeping your project working toward creating the right product. Like the triple constraint (scope, cost, and schedule), you manage project quality by setting goals and taking measurements. That’s why you must understand the quality levels your stakeholders believe are acceptable, and ensure that your project meets those targets, just like it needs to meet their budget and schedule goals.

Project quality focuses on the deliverables that reflect the project’s purpose. The project manager is responsible for developing a plan that clearly describes the expected deliverables and quality specifications. For example, the manager of a housing construction project needs to understand which rooms in the house will be carpeted and what grade of carpet is needed. A room with a high volume of traffic will need a high-grade carpet.

When the team gathers requirements for the specification, they try to write down all the things the customers want in the product so that you know how to make them happy. Some requirements can be left unstated. Those are the ones that are implied by the customer’s explicit needs. For example, some requirements are just common sense (e.g., a specific product can’t be made from toxic chemicals that may kill the product user). It might not be stated, but it’s a requirement.

Which would you choose: a beautifully designed, well-constructed, solidly built, and all-around pleasing product that does not do what you need or a product that does what you want despite being ugly and hard to use? You’ll always choose the product that fits your needs, even if it’s limited in other ways. That’s why it’s vital that the product both does what it is supposed to do and does it well. 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 your product does what you intend. Above all, your product needs to do what you wrote down in your requirements document. Your requirements should consider what will satisfy your customer and the best design possible for the job. That means conforming to both stated and implied requirements. In the end, your product’s quality is judged by whether you built what you said you would build.

Technical Requirements

Technical requirements emerge from the functional requirements to answer the questions: how will the problem be solved this time, and will it be solved technologically and/or procedurally? They specify how the system needs to be designed and implemented to provide correct functionality and fulfill required operational characteristics. Projects that do not produce a physical product or result may not have technical requirements. The wedding discussed above does not have technical requirements because there is no problem to be solved with developing a physical product or result.

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 (due to existing knowledge in-house), the hardware on which the system will run (due to existing infrastructure), telecommunication protocols that should be used, and security requirements that are needed for access.

Business Requirements

Business requirements describe the sponsoring organization’s needs from a management perspective. Business requirements are statements of the business rationale for the project. They are usually expressed in broad outcomes, focused on satisfying business needs rather than addressing specific functions the system must perform. These requirements grow out of the vision for the product that, in turn, is driven by mission (or business) goals and objectives. Business requirements are tied to organizational or department objectives. For example, if a customer service department had an objective to "increase customer satisfaction ratings to 4.2 by year-end," then a business requirement for a related project might be, "the project will support the department’s goals of increasing customer satisfaction ratings.”

User Requirements

User requirements describe what the users need to do with the system or product. The focus is on user experience with the system under all scenarios. These requirements are included to verify that project outcomes match the end user’s expectations. For example, in the wedding project, a user requirement might be, “the bride will need access to the dressing rooms 3 hours before the wedding starts to change into her wedding attire.”

Regulatory requirements

Regulatory requirements can be internal or external, usually non-negotiable, and includes restrictions, licenses, and laws applicable to a product or business imposed by the government. Obtaining a marriage license three days before the wedding would be an example of a regulatory requirement for the wedding project.

The Importance of Documenting Requirements

Accurately specifying requirements is one of the most challenging undertakings faced by project managers. While the project manager makes sure requirements are documented, the project manager does not perform this task alone. The project manager enlists the help of all key stakeholders (business analysts, requirement analysts, business process owners, customers, and other team members) to conduct discussions, brainstorming, and interviews to document requirements. The project manager is responsible only for enabling the process and facilitating it.

Inadequately specified requirements will guarantee poor project results and may also introduce the potential for scope creep. Documenting requirements is more than just writing down the requirements as the user sees them; accurate documentation should cover what decisions have been made and why they have been made. Understanding the reasoning followed to arrive at a requirement is critical to avoid repetition. For example, the fact that a particular feature has been excluded because it is simply not feasible needs to be recorded. The project risks wasted work and repetition if decisions are not recorded, such as when a stakeholder requests the feature be reinstated during development or testing.

The requirements traceability matrix is a document that links requirements to their origin and traces them throughout the project life cycle. A requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the planning stages are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope. This process includes, but is not limited to, mapping requirements to the following sources.

• Business needs, opportunities, goals, and objectives
• Project objectives
• Project scope, work breakdown structure, deliverables
• Product design
• Product development roadmaps and plans
• Test plans, strategy, and scenarios

Typical attributes included in a requirements traceability matrix may include:

• A unique identifier for each requirement
• A textual description of the requirement
• The rationale or justification for inclusion
• Owner (person responsible for the requirement)
• Source (who identified or asked for the requirement)
• Priority (urgent, high, medium, low)
• Version (to track changes, when and what updates were made)
• Status (such as active, canceled, deferred, added, approved)
• Date delivered.

Additional attributes to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance criteria.

Once the requirements are documented, have the appropriate stakeholders sign off on their requirements as confirmation of what they desire. The project manager then reviews the requirements, incorporates them into the project documentation library, and uses them as input for the project plan.

Figure 7.5 Sample Requirements Traceability Matrix

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Scheduling Project Work

Project management success includes delivering the correct scope on time and with the agreed-upon budget. When we discussed projects in Chapter 1, we learned that projects have numerous constraints placed on them, specifically cost, scope, quality, risk, resources, and time. In this chapter, we will discuss time constraints and how to develop a project schedule that satisfies these restrictions.

The project manager is responsible for developing and managing a schedule that ensures the project completes on time. On smaller projects managers may create the schedule, but on complex projects the manager may seek the assistance of scheduling experts.

Regardless of who develops the project schedule, the team reviews the scope, constraints, and other project information to determine important dates. Based on this information, the team develops a milestone schedule.

The milestone schedule establishes key dates that must be met for the project to finish on time. Milestones help the team meet contractual obligations or communicate progress at appropriate intervals. A milestone schedule may suffice for less complex projects to track progress.

For complex projects, a more detailed schedule is required. In this case, the work packages identified in the WBS form the basis of the schedule. Work packages contain a list of activities to be performed, work assignments, and relationships between the activities. This section will discuss how to identify and schedule project work to develop a schedule baseline.

Chapter Learning Objectives

• Understand the processes and activities of identifying and scheduling project work.
• Describe the approaches to assigning resources and estimating activity duration and effort.
• Apply critical path analysis to determine a project’s duration and most essential activities.
• Demonstrate awareness of best practices for building quality into a project schedule.
• Employ methods to optimize project schedules.

Identifying Activities

The activity definition process is a further breakdown of the work package elements in the WBS. It documents the specific activities needed to produce the deliverables detailed in the WBS. These activities are not the deliverables but individual units of work that must be completed to produce them. Activity definition uses everything we already know about the project to divide the work into activities that can be estimated. You might want to look at all the lessons learned from similar projects your company has completed to get an idea of what you need to do on the current one.

Project team members with prior experience developing scope statements and WBS can help you define activities by sharing their expert judgment. Expert judgment is the application of specialized knowledge and skills to make decisions and provide solutions, often provided by an individual with specialized training or experience. Suppose you are asked to manage a project in a new domain. In that case, you might rely on subject matter experts to help define tasks so you can understand what activities will be involved. You may want to create an activity list and then have the expert review it and suggest changes. Alternatively, you could involve experts from the beginning and ask to have an activity definition conversation with them before making your first draft of the list.

Now that the activity definitions for work packages have been completed, the next task is to complete the activity list, which includes all the activities that must be accomplished to deliver each work package, plus everything else that needs to be done to complete your project (Figure 8.1). Activity attributes include a description of the work, relationships, constraints, assumptions, and other important information you may need as you plan the project. Activities should be tracked back to a specific work package.

Figure 8.1 Activity Definition for Work Package 3.1 Bridal Attire

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Sometimes, project managers must begin projects without knowing much about the work that will be done later. Rolling-wave planning lets you plan and schedule only the portion you know enough about to plan well. When you don’t know enough about a project, you can use the higher-level deliverables as placeholders for unknown portions until you know more.

As the team defines project activities, they may also estimate how long these tasks will take. For some activities this information may already be established, but in others the project manager may have to develop a best guess. One consideration is what your team members with the most experience at a task estimate for the time it will take. Building consensus is another approach.

Estimating Activity Duration and Effort

Once you’re done with activity identification, you can now determine how long each activity will take. That’s done in a process called activity duration estimating, where you look at each activity in the activity list, consider its scope and resources, and estimate how long it will take to perform.

Estimating activity duration means starting with the information you have about that activity and the resources assigned to it and then working with the project team to come up with an estimate. Most of the time, you’ll start with a rough estimate and then refine it to make it more accurate. You’ll use one or more of the following tools and techniques to create the most accurate estimates:

1. Expert judgment involves relying on your project team members who are familiar with the work that must be done to develop activity estimates. If you don’t get their opinion, there’s a considerable risk that your estimates will be wrong.

2. Analogous estimating is when you look at similar activities from previous projects and how long they took. This strategy only works if the activities and resources are similar to the current project.

3. Parametric estimating means plugging data about your 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 relies on data of actual durations from past projects.

4. Three-point estimating calculates duration based on three values: 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 estimate is a weighted average of the three.

5. Reserve analysis means adding extra time to the schedule (called a contingency reserve or buffer) to account for extra risk.

In developing estimates for tasks, you often must distinguish between the duration and effort needed to complete the task. Duration refers to the amount of time elapsed to complete an activity, while effort refers to how much time people spend completing the activity. Duration and effort can be measured in hours, days, weeks, or months, depending on the activity.

For example, if you were assigned a project to paint a room, you might have several tasks to complete (Figure 8.2). Looking at tasks B and C in particular, we might define these as effort-based tasks. We estimate it would take two hours for B and six hours for C, assuming we only have one resource (person) working on the tasks. However, we might be able to cut that time in half by adding a second person to help remove the furniture and paint the room. Therefore, painting the room would take six hours of effort that could be divided between two resources and accomplished in three hours.

Figure 8.2 Comparing Duration and Effort

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

On the other hand, tasks A and D would be duration-based tasks. We estimate it will take one week to receive the paint and supplies orders and two days for the paint to dry before we can move the furniture back into the room. Regardless of how many people are working on the project, adding more people will not change the speed at which the paint dries. (Although a project manager may find other resources, such as industrial fans, that could speed along the drying time of the paint at additional expense.)

Assigning Project Resources

Project Resources include people, equipment, physical locations, money, or anything else you need to complete the activities you are planning. Every activity on your activity list needs to have resources assigned to it. Before you can assign resources to your project, you need to know their availability. Resource availability includes information about what resources you can use on your project, when they’re available to you, and the conditions of their availability.

Resource management is the efficient and effective deployment of an organization’s resources when needed. Such resources may include financial resources, inventory, human skills, production resources, or information technology (IT).

Don’t forget that some resources, like consultants or training rooms, must be scheduled in advance and might only be available at certain times. You’ll need to know this information before you can finish planning your project. If you are starting to plan in January, a June wedding is more challenging to plan than a December wedding because the wedding halls are all booked up in advance. That is a resource constraint. You’ll also need the activity list that you created earlier, and you’ll need to know how your organization typically handles resources. Once you understand these things, you’re ready to estimate resources.

The goal of activity resource estimating is to assign resources to each activity in the activity list. A project manager may use one or more approaches to estimate activity resources (Figure 8.3).

Figure 8.3 Approaches to Estimating Activity Resources

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Mapping Relationships Between Activities

After identifying the activities, the project team sequences the tasks according to the order in which they are to be accomplished. An outcome of sequencing is the project network diagram. A network diagram represents the logical sequence of activities needed to complete a project.

Many project managers use network diagrams when scheduling a project. The network diagram is a way to visualize the interrelationships of project activities. Network diagrams provide a graphical view of the tasks and how they relate to one another. The activities in the network are from the WBS work packages. All the work package activities must be included in the network diagram because they must be accounted for in the schedule. Leaving even one activity out of the network could change overall schedule duration, estimated costs, and resource allocation commitments. The first step is to arrange the activities from your WBS into a sequence. Some activities can be accomplished at any time throughout the project, while other activities depend on input from another activity or are constrained by time or resources.

The WBS is not a schedule, but it is the basis for it. The network diagram is a schedule but is used primarily to identify critical scheduling information that ultimately goes into user-friendly schedule formats, such as milestone and Gantt charts. The network diagram provides visual information to the project team by showing how the activities are related (Figure 8.4), where the risk points are in the schedule, how long it will take as currently planned to finish the project, and when each activity needs to begin and end.

Figure 8.4 Sample Network Diagram

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

There are two primary ways to design network diagrams. Showing the activities in rectangles and their relationships as arrows is called a precedence diagramming method (PDM). This kind of diagram is also called an activity-on-node diagram (AON). Another way to show how tasks relate is with the activity-on-arrow diagram (AOA) where the arrows represent the activities or tasks. Although AON is more commonly used and is supported by all project management programs, PERT is the best-known AOA-type diagram and the historical basis of all network diagramming. The main difference is the AOA diagram is traditionally drawn using circles as nodes, with nodes representing the beginning and ending points of the arrows or tasks.

All network diagrams have the advantages of showing task interdependencies, start and end times, and the critical path but the AOA network diagram has some disadvantages that limit their use.

The three major disadvantages of the AOA method are:

1. The AOA network can only show finish-to-start relationships. It is not possible to show lead and lag except by adding or subtracting time, which makes project tracking difficult.
2. Instances of “dummy activities” can sometimes occur in an AOA network. Dummy activities are activities that show the dependency of one task on other tasks but for other than technical reasons. For example, one task may depend on another because it would be more cost effective to use the same resources for the two; otherwise, the two tasks could be accomplished in parallel. Dummy activities do not have durations associated with them. They simply show that a task has dependence on another task.
3. AOA diagrams are not as widely used as AON diagrams simply because the latter are somewhat simpler to use, and all project management software programs can accommodate AON networks, whereas not all can accommodate AOA networks.

How do you figure out a schedule that makes everything fit together? Until you have finished building the schedule, you will find it nearly impossible to have a complete view of your resource needs. The same goes for your activity list and duration estimates. When you lay out the schedule, you’ll likely discover that some of your activities and durations conflict.

Some activities must be done sequentially while others can be done concurrently. The project manager should schedule activities in a way that effectively and efficiently uses resources and completes the project in the shortest time. On larger projects, several paths are created that represent a sequence of activities from the beginning to the end of a project. The longest path to project completion is the critical path.

Knowing where your critical path is can give you a lot of freedom. If you know an activity is not on the critical path, then you know a delay in that activity may not necessarily delay the overall project. This knowledge can help with handling emergencies. Even better, it means that if you need to bring your project in earlier than was initially planned, you know that adding resources to the critical path will be much more effective than adding them elsewhere.

The schedule can be displayed in a variety of ways, some of which are variations of what you have already seen. Project schedule network diagrams will work as schedule diagrams when you add the start and finish dates to each activity. These diagrams usually show the activity dependencies and critical path. Project managers can use critical path analysis to keep projects on track (see section 8.4.1). Critical path analysis identifies the string of activities that, if you add up all the durations, is longer than any other path through the network. It starts with the first activity in the network and ends with the last one. Knowing the critical path is essential because every activity on the path must finish on time for the project to come in on time. A delay in any one of the critical path activities will cause the entire project to be delayed.

Relationships between activities or scheduling constraints should be listed in the attributes along with descriptions and any other information about resources or time that you need for planning. Predecessor relationships occur between activities that must occur in a particular order. The three main kinds of predecessors are finish-to-start (FS), start-to-start (SS), and finish-to-finish (FF). The most common kind of predecessor is the finish-to-start. A finish-to-start relationship means that one task needs to be completed before another one can start. This sequence is the most common relationship identified between tasks. It’s called finish-to-start because the first activity’s finish leads into the second activity’s start.

We can also think of relationships between activities as mandatory or discretionary. Mandatory predecessors are the kinds that must exist just because of the nature of the work. You can’t address an invitation that hasn’t been printed yet. Printing invitations is a mandatory predecessor for addressing them. Discretionary predecessors are optional relationships, usually process- or procedure-driven or best-practice techniques based on experience. In the wedding example, the bride and groom want the bridesmaids to arrive at the reception before the couple arrives. This setup is not a requirement, rather it’s a matter of preference.

In Figure 8.5, the activities in the wedding work package “3.1 Bridal Attire” have different relationships. Activities 3.1.1 and 3.1.2 have finish-to-start relationships, which tells us that 3.1.1 must finish before 3.1.2 can start. Activities 3.1.3 and 3.1.4 have a start-to-start relationship, which tells us that the two activities can start at the same time. Activities 3.1.2 and 3.1.6 have a finish-to-finish relationship, which tells us that they must finish together.

Figure 8.5 Predecessor Relationships for Activities in Work Package 3.1

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Critical Path Analysis

Once a network diagram has been made and estimated activity durations have been assigned, the critical path can be identified. Critical path analysis identifies flexibility in the project schedule. During the life of the project scheduling conflicts often occur, and the project manager is responsible for reducing these conflicts while maintaining quality and meeting cost goals. Mapping the critical path helps to identify the activities that need to be monitored most closely.

Using this method, the following attributes of each activity can be calculated (Figure 8.6):

• Early start time (ES) – earliest time an activity can start based on predecessor relationships
• Late start time (LS) – latest time an activity can start based on successor relationships
• Early finish time (EF) – earliest time an activity can finish based on predecessor relationships
• Late finish time (LF) – latest time an activity can finish based on successor relationships
• Slack or float (SL or FL) – the difference between an activity’s early start and late start; activities on the critical path will have a slack = 0.

These activity attributes are calculated using two processes: the forward pass and the backward pass. The forward and backward pass are also used to fully calculate the critical path(s) in a project.

Figure 8.6 Completed Critical Path Analysis with Schedule Attributes

Source: Original Work

Attribution: Louisa Schlesiger

License: CC BY-NC-SA 4.0

Building Quality into the Schedule

The project manager is responsible for developing a project quality plan that defines the quality expectations and ensures that specifications and expectations are met. Developing a good understanding of project deliverables through documenting specifications and expectations is critical to a good quality plan.

Quality planning focuses on taking all the information available to you at the beginning of the project and figuring out how you will measure quality and prevent defects. Your company should have a quality policy that states how it measures quality across the organization. You should make sure your project follows the company policy and any government rules or regulations on how to plan quality for your project. You need to plan which activities you will use to measure the quality of the project’s product, and you’ll need to think about all the quality-related activity costs you want to complete. Then you’ll need to set some guidelines for what you will measure against. Finally, you’ll need to design the tests you will run when the product is ready to be tested.

The project manager integrates the processes for ensuring that the specifications and expectations are met are integrated into the project schedule. Just as the project budget and completion dates may change over the life of a project, the project specifications may also change. Changes in quality specifications are typically managed in the same process as cost or schedule changes. The impact of such changes is analyzed for influence on cost and schedule, and with appropriate approvals, changes are made to the project execution plan.

Although any of the quality management techniques designed to incrementally improve operational work can be applied to project work, the unique aspects and relatively short duration of projects makes minor improvements less attractive on projects. Rework on projects, as with manufacturing operations, increases the cost of the product or service and often increases the time needed to complete the reworked activities. Because of a project’s time constraints, appropriate skill development, material allocation, and work process setup early in the project are critical to success. On more complex projects, time is allocated to developing a plan to understand and cultivate the appropriate skill levels and work processes.

Project management organizations that execute several similar types of projects may find process improvement tools helpful 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. Opportunities for improvement must be found quickly to influence project performance. The investment in time and resources to find improvements is greatest during the early stages, when the project is in the planning phases. During later project stages, as pressures to meet project schedule goals increase, there is less focus on making changes in work processes.

Creating A Project Schedule

A project schedule can be built from the top-down or from the bottom-up (Figure 8.7). Top-down scheduling is useful when project objectives are clearly identified, but the underlying deliverables or work is not so clear. The schedule is estimated based on consensus or experience and will be refined as the deliverables are further defined. While top-down estimating helps determine the overall project schedule during the early stages of a project, it does not enable the project manager to effectively monitor progress.

Bottom-up scheduling helps the project manager more effectively monitor progress and starts with identifying the deliverables (see section 7.2.2). After the project team organizes deliverables down into work packages, the team identifies activities needed to complete each work package, including durations and relationships between tasks and deliverables, and assigning resources. The project manager uses these activities to determine the project schedule.

Figure 8.7 Bottom-Up versus Top-Down Scheduling

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Up to this point, we have identified project deliverables and the activities required to produce them. We have identified activity relationships, durations, and resources. However, we still do not have a project schedule. A project schedule displays activity durations, resources, relationships, and timing. A project schedule will also include milestones, which are activities with zero duration and effort that show target dates for completing various aspects of project work. The important checkpoints for your project are tracked as milestones. Some of them could be listed in your contract as requirements of successful completion; some could just be significant points that you want to keep track of. The milestone list needs to let everyone know which milestones are required and which are not. Milestones do not have assigned durations or resources but serve as time markers to allow the project manager to monitor delivery.

Figure 8.8 Project Schedule with Durations, Relationships, and Resources

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Project schedules can be viewed as either a table (Figure 8.8) or as a time-based visual of project work. A Gantt chart is one type of visual time-based chart, developed by Henry Gantt, that illustrates a project schedule (Figure 8.9). Gantt charts are easy to read and commonly used to display schedule activities. These charts display the start and finish dates of terminal and summary project elements. Terminal and summary elements comprise the project’s work breakdown structure. Some Gantt charts also show dependency relationships (i.e., precedence network) between activities.

Gantt charts show all the stages of a project and their duration as a bar chart with the time scale across the top. The key stages are placed on the bar chart in sequence, starting in the top left corner and ending in the bottom right corner.

Figure 8.9 An example of a Gantt Chart

Source: Wikimedia Commons

Attribution: User “Zorkow”

License: CC BY-SA 4.0

A Gantt chart can be drawn quickly and easily and is often the first tool a project manager uses to provide a rough estimate of the time it will take to complete essential tasks. Sometimes it is helpful to start with the target deadline for completion of the whole project because it is soon apparent if the time scale is too short or unnecessarily long. The detailed Gantt chart is usually constructed after main objectives have been determined.

For a complex project, you may decide to produce a separate Gantt chart for each project stage. If you do this shortly before each key stage begins, you will be able to take any last-minute eventualities into account.

These charts provide a valuable tool for monitoring and control as the project progresses. Various software apps and tools are available to assist project managers in creating dynamic Gantt charts. Once the data have been entered, a program helps you work on “what if” scenarios, showing what might happen if a project stage is delayed or sped up.

Sometimes you need to give some extra time between activities. Lag time is when you purposefully put a delay between the predecessor task and the successor. For example, when the bride and her father dance, the guests wait awhile before joining in. Lead time is when you give a successor task some time to get started before the predecessor finishes. For example, you might want the caterer to prepare the dessert an hour before everybody is finished eating dinner.

The final project schedule is called a schedule baseline, which will be used by the project manager during the production phases to monitor work and ensure the project stays “on schedule.”

Optimizing The Project Plan

Optimizing the project plan includes evaluating the schedule and budget to ensure they are as accurate and realistic is possible. Project schedules can be optimized using several methods, including crashing and fast-tracking, discussed below. PERT analysis (see section 8.7.4) is one method of optimizing a project schedule based on probabilities and prior experience.

Optimizing the Project Schedule and Budget

Because certainty during planning is challenging to achieve, a project manager must carefully review the schedule and budget before publishing baselines. Schedule optimization is the final step in the process in which the project manager and team take a very critical look at the draft schedule and seek ways to improve it–that is, to make it more accurate, realistic, effective, and faster.

Much of project planning involves making estimates and assumptions, which introduces variables and risk to a project. Sometimes a task takes longer than initially estimated, whether due to optimistic anticipation of what work needs to be done, or to unforeseen challenges that arise. Therefore, a project manager must know the critical path (or paths) of a project.

If the critical path can be completed before the client needs the project completed, the project has a positive total float or project slack. In other words, the project can likely be completed ahead of schedule. If, after mapping out the tasks and determining the critical path, the PM determines that the project cannot be completed by the client’s deadline, the project has a negative float. If the projected total time is much longer than the project sponsor’s expectations, the PM will need to renegotiate the time scale.

Crashing and Fast-Tracking a Project Schedule

To successfully manage a project, the project manager must also know how to accelerate a schedule to compensate for unanticipated events that delay critical activities–those activities along the critical path. Project managers rely on two common techniques: crashing and fast-tracking. Crashing is a form of schedule compression that involves applying additional resources to a task along the critical path at the lowest incremental cost. The additional costs may be in the form of additional personnel, equipment, overtime, or expedited manufacture or delivery of equipment.

For effort-driven tasks, adding personnel or equipment can decrease the amount of time it takes to complete a task. In the room painting example (Figure 8.2), we estimated a room could be painted in six hours using one individual. If we pay for a second worker, the painting could be completed in half the time, thereby cutting the time for that task in half. Spread over several rooms, additional personnel could decrease the amount of time needed to complete a project, but such a decision does come at additional cost.

For duration-driven tasks, additional resources could come in the form of expediting production or shipping needed parts. For example, when working on a wedding, the wedding planner may decide that invitations need to be mailed out two weeks prior to the initially planned date. The wedding planner may pay a priority fee to the printing shop to move the wedding’s priority to the front of the queue for printing as well as to pay for overnight shipping, rather than waiting an additional 3–5 days for standard mail delivery.

Another method for compressing the schedule is fast-tracking. Fast-tracking refers to starting tasks in parallel that are typically done sequentially. As the most common relationship between dependent tasks is a finish to start relationship, fast-tracking can involve starting a task before the predecessor task is completed. One downside to fast-tracking is that it may introduce additional risk to a project.

For example, a wedding generally needs a venue for the ceremony, and sometimes a venue for the reception. The standard plan may show that the task involving designing and printing the wedding invitations are dependent on having the venues selected and reserved. However, the printing company may need six weeks to print the invitations, which will make it challenging to address the invitations in time to mail them six weeks before the wedding. If the PM decides to print the invitations without having a contract signed, she runs the risk of having to redo all the invitations if the contract falls through. If the PM only develops a sample, she may save some days off the project by writing the venue information on the invitations. The PM must balance risk with potential savings in any step that is fast tracked.

A key differentiation to remember between crashing and fast-tracking is this: crashing involves adding additional resources to a project, which can affect the budget. Fast-tracking involves modifying the sequence of activities, which can increase risk in the project, but no additional resources are added.

When optimizing the schedule, one must consider the effect on project costs, benefits, and risks. There may be opportunities to speed up the schedule, but if the cost for crashing is high, the PM must weigh the added costs with the time savings. Similarly, with fast-tracking, the risk introduced to the project may not be worth the incremental time savings.

If a project manager does not include steps to optimize the project schedule and avoid the potential risks of doing so, they must be ready to address potential changes to the project schedule following established change management processes. Even the best project schedules will need to be adjusted once the work begins to produce project outcomes, because as Mike Tyson, world-famous boxer of the 1980s said, “everybody has plans until they get hit for the first time.”^[14]

Optimizing Project Resources

Resource leveling is used to examine unbalanced resource use (usually people or equipment) over time to resolve over-allocations or schedule conflicts. When performing project planning activities, the project manager will attempt to schedule some tasks simultaneously. When more resources, such as machines or people, are needed than are available or perhaps a specific person is needed in both tasks, the tasks will have to be rescheduled sequentially to manage the constraint. For example, multiple shipments might arrive at a warehouse at the same time, but the warehouse operator has one forklift to move the shipments that cannot be moved by hand. Some tasks that are waiting on a shipment may have to be delayed while the forklift is being used to deliver materials for another task. If the tasks that are being delayed are on the critical path, the decisions for using the forklift may delay the entire project.

Resource leveling during project planning is the process of resolving these conflicts. It can also be used to balance the workload of primary resources over the course of the project, usually at the expense of one of the traditional triple constraints (time, cost, scope). When using specially designed project software, leveling typically means resolving conflicts or over-allocations in the project plan by allowing the software to calculate delays and update tasks automatically. Project management software leveling requires delaying tasks until resources are available. In more complex environments, resources could be allocated across multiple, concurrent projects thus requiring the resource leveling process to be performed at company level. In either definition, leveling could result in a later project finish date if the tasks affected are in the critical path.

PERT Analysis

Program Evaluation and Review Technique (PERT) was one of the first systems for diagramming and analyzing project networks. Many of the techniques covered in this and other project management textbooks originated with PERT. Over the years, PERT concepts have been augmented and extended. As a result, many project managers don’t directly mention PERT, but use a variation of the PERT system as it was developed in the 1950s.

PERT is useful for analyzing the variability in project time estimates. Estimate variability represents a substantial source of risk for any project. A PERT analysis can help project managers make better assumptions about the likely completion time for tasks and projects. A PERT analysis gives the project manager the information needed to address estimate variability by adding time buffers and allocating contingency funds.

A PERT analysis starts with a three-point time estimate. For each activity, estimators provide:

• An optimistic time estimate (if all goes well, what is the shortest time one could realistically expect to complete this activity?)
  • This will be designated in calculations as “O.”
• The most likely time estimate (if all goes as expected, what is the average time one could realistically expect to complete this activity?)
  • This will be designated in calculations as “M.”
• A pessimistic time estimate (if work goes poorly, what is the longest time one could realistically expect to complete this activity?)
  • This will be designated in calculations as “B.”

PERT uses a weighted average to reflect that the most likely estimate (M) should be weighted more heavily than the others. For PERT, this weighted average is called T_e and is computed by the formula below. This equation can be adjusted for different circumstances, but the version below is the generally accepted formula.

Project management studies have found that T_e values follow a beta distribution of probable completion dates. As a result, when given the values for O, M, and P for each task on the critical path, the project manager can calculate the probability of the project being completed within a given time. The variance can tell us the probability that an activity will complete within a given time. For calculations involving PERT, the calculation of the variance for project activities is as follows:

To determine the probability of completion, a formula is used that compares proposed schedule completion dates (T_s) with the time predicted by our critical path (T_e). This equation determines a statistical Z value and the probability of meeting the proposed completion date. The formula for this calculation is:

This Z value can then be found in a probability table or calculated using a spreadsheet program like Excel. More advanced simulations can use these variances to calculate probabilities of all network paths to produce a robust (although time consuming) model of a project’s probable completion date, which paths/tasks present the most risk, etc.

Budgeting Projects

Once we know the activities and resources required to complete a project, we can create a project budget. Every project boils down to money. If you had a bigger budget, you could probably get more people to do your project faster and with more outcomes. That’s why no project plan is complete until you come up with a budget. But no matter if your project is big or small, or how many resources are used or activities identified, the process for figuring out the bottom line is always the same. A project manager must provide detailed estimates for all project costs by adding up the cost estimates into a budget plan. This budget plan will make it possible to track the budget while work is ongoing.

Chapter Learning Objectives

• Understand the processes and activities of estimating project costs.
• Apply best practices to develop and optimize project baseline budgets.

Estimating Project Costs

Often when you start a project, the project sponsor has an expectation of how much it will cost or how much time it will take. When you make an estimate early in the project without knowing much about it, that estimate is called a rough order-of-magnitude estimate (or a ballpark estimate). This estimate will become more refined as time goes on and you learn more about the project.

Here are some tools and techniques for estimating cost:

• Determining resource cost: People who will be working on the project all work at a specific rate. Any materials you use to build the project (e.g., wood or wiring) will be charged at a rate too. Determining resource costs means figuring out what the rate for labor and materials will be for each activity.
• Vendor bid analysis: Sometimes you will need to work with an external contractor to get your project done. You might even have more than one contractor bid on the job. This tool is about evaluating those bids and choosing the one you will accept.
• Reserve analysis: You need to set aside some money for cost overruns. If you know that your project has a risk of something expensive happening, setting aside cash to deal with the risk is good management practice. Reserve analysis means putting some cash away in case of overruns.
• Cost of quality: You will need to figure the cost of all your quality-related activities into the overall budget. Since it’s cheaper to find problems earlier in the project than later, quality costs are associated with everything your project produces. Cost of quality is just a way of tracking the cost of those activities and is the amount of money it takes to do the project right.

Once you apply these tools, you will arrive at an estimate for how much your project will cost. The project manager should keep a record of all supporting information used when making this estimate. That way, everyone knows the assumptions made when preparing the budget estimate. Now the project manager can build the budget plan.

Activity-Related Costs

The most accurate and time-consuming estimating method is to identify the cost of each item in each scheduled activity, including labor and materials. Bottom-up estimating means breaking down complex activities into pieces and working out the costs for each component. The process involves estimating individual activity resource needs or costs and then adding these up together to come up with a total estimate. Bottom-up estimating is a very accurate means of estimating, provided the estimates at the schedule activity level are accurate. However, it takes a considerable amount of time to perform bottom-up estimating because every activity must be assessed and estimated accurately to be included in the bottom-up calculation. The smaller and more detailed the activity, the greater the accuracy and cost of this technique.

Resource-based cost refers to the cost of human effort to complete an activity. An hourly rate is often assigned to each project resource, which is multiplied by the number of effort-hours to complete an activity. This value identifies the resource, or labor, cost of an activity. Materials-based cost refers to the cost of materials and supplies needed to complete the activity. Note that Figure 9.1 does not include any resource costs. All costs are material costs. Some projects only have resource-based costs, while other projects have only material costs. Most projects have a combination of resource-based and material-based costs.

Figure 9.1 Example Activity Costs for 3.1 Bridal Attire

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Other Project Costs

Procurement Costs

Procurement costs relate to the expenses associated with outsourcing work or obtaining project materials from sources outside the organization. The costs associated with procurement are above and beyond material costs and include fees and other service charges incurred during procurement.

Contractual agreements with vendors often require partial payment of costs during the project. Those contracts can be managed more conveniently if the unit of measure for partial completion is the same as that used for cost budgeting. For example, if a graphic designer is putting together several pieces of artwork for a textbook, their contract may call for partial payment after 25% of their total number of drawings is complete.

Vendors and suppliers usually require payments during the life of a contract. On contracts that last several months, the contractor will incur significant cost and want the project to pay for these costs as early as possible. Rather than wait until the end of the contract, a schedule of payments is typically developed and connected to the completion of a defined amount of work or project milestones. These payments made before the end of the project and based on work progress are called progress payments.

For example, a contract might develop a payment schedule that pays at three points: first, for the curriculum design, second, after curriculum development, and third, when the curriculum is completed and accepted. In this case there would be three payments made. The project has 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 contractor is paid.

Contract Planning

Contract planning includes processes for planning individual work contracts. The organization usually has standards relating to how contracts will be managed, the metrics that need to be met for the contracts to be considered successful, seller selection, and contract administration. Once the project team determines needed services, the project manager may send out requirements to sellers. Vendors and sellers bid for the chance to work on the project. The project manager selects the best vendor and contracts are signed. Once the work begins, the project manager monitors the vendor to ensure they are following the contract specifications. When the work is done, the project manager closes out the contract and fills out all the paperwork.

Some tools and techniques used during the procurement planning stage include make-or-buy analysis and contract type definition. Make-or-buy analysis assists with determining whether you should be contracting the work or doing it yourself. It could also mean deciding whether to build a solution to your problem or buy one that is already available. Most of the same factors that help you make every other major project decision will help you with this one. For example, consider:

• How much does it cost to build it as opposed to buying it?
• How will this decision affect the project scope?
• How will it affect the project schedule?
• Do you have time to do the work and still meet your commitments?

As the project team plans out what will and won’t be contracted, the team needs to evaluate their reasoning very carefully. There are some resources (like heavy equipment) that the company can buy, rent, or lease depending on the situation. The project manager should examine leasing-versus-buying costs to determine the best way to proceed.

Once the decision to engage in contracts is made, the project managers needs to decide what type of contract to pursue. Several types of contracts exist, and the goal is to choose one that creates the most fair and workable deal for you and the contractor. Fixed price contracts have the lowest risk for a project because no matter how much time or effort the vendor spends, you always pay the same. Cost reimbursable contracts are another type of contract where the seller charges you for the cost of doing the work plus some fee or rate. The third major kind of contract is a time and materials contract, which is where the client pays a rate for the time spent working on a project and pays for all the materials used to do the work.

Quality Costs

Delivering a project’s quality requirements means considering the cost of quality, which includes costs over the life of the product, not just those incurred during the project. Cost of quality is what you get when you add up the cost of all the prevention and appraisal activities you are going to do on your project. It doesn’t just include testing. Instead, it includes any time spent writing standards, reviewing documents, meeting to analyze the root causes of defects, and reworking to fix the defects once they’re found by the team; in other words, the cost of quality includes absolutely everything you do to ensure quality on the project. Cost of quality helps determine whether your project is doing well or having trouble. For example, suppose your company tracks the cost of quality on all its projects. You could tell if you are spending more or less than has been spent on other projects to get your project up to quality standards.

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

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

Project Reserves

Most projects have something unexpected occur that increases costs above the original estimates. If estimates are rarely exceeded, the estimating method should be reviewed because the estimates are too high. It is impossible to predict which activities will cost more than expected, but it is reasonable to assume that some of them will. Estimating the likelihood of such events is part of risk analysis, which is discussed in more detail in section 10.1.4.1. Instead of overestimating each cost, money is budgeted for dealing with unplanned but statistically predictable cost increases. Funds allocated for this purpose are called contingency reserves. Because it is likely that this money will be spent, it is part of the total budget for the project. If this fund is adequate to meet the unplanned expenses, then the project will complete within the budget.

If something occurs during the project that requires a change in project scope, money may be needed to deal with the situation before a change in scope can be negotiated with the project sponsor or client. It could be an opportunity as well as a challenge. For example, if a new technology were invented that would significantly enhance your completed project, acquiring the new technology would add cost and require a change to the scope, but it would be worth it. Money can be made available at the sponsor’s discretion to meet needs that would change the project scope. These funds are called management reserves. Unlike contingency reserves, they are not likely to be spent and are not part of the project’s budget baseline, but they can be included in the total project budget.

Developing the Baseline Budget

Once you have broken your project down into activities, you will be able to calculate your overall project costs by estimating and totaling the individual activity costs. The process of subtotaling costs by category or activity is called cost aggregation.

A budget baseline is established once all known project costs are identified (Figure 9.2, Example Baseline Budget). The project manager uses the budget baseline during the project’s production phases to monitor costs and ensure the project stays “on budget.”

Figure 9.2 Example Baseline Budget

Source: Original Work

Attribution: Juanita Woods

License: CC BY-NC-SA 4.0

Time-Phased Budgets

While a baseline budget like the one shown above is helpful, it does not tell the project manager when to expect project expenses to occur. A time-phased budget helps address this issue. A time-phased budget shows planned expenses during each reporting period for the duration of the project and 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 to produce the time-phased budget. Costs are associated with deliverables, and since each deliverable 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 project’s cash flow needs 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 next 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.

Figure 9.3 An Example of a Time-Phased Budget