PROJECT

MANAGEMENT:
NAVIGATING THE
COMPLEXITY WITH A
SYSTEMATIC
APPROACH (OGUZ)

Abdullah Oguz
Cleveland State University
 Project Management: Navigating the
Complexity with a Systematic Approach
This text is disseminated via the Open Education Resource (OER) LibreTexts Project ([Link] and like the hundreds
of other texts available within this powerful platform, it is freely available for reading, printing and "consuming." Most, but not all,
pages in the library have licenses that may allow individuals to make changes, save, and print this book. Carefully
consult the applicable license(s) before pursuing such effects.
Instructors can adopt existing LibreTexts texts or Remix them to quickly build course-specific resources to meet the needs of their
students. Unlike traditional textbooks, LibreTexts’ web based origins allow powerful integration of advanced features and new
technologies to support learning.

The LibreTexts mission is to unite students, faculty and scholars in a cooperative effort to develop an easy-to-use online platform
for the construction, customization, and dissemination of OER content to reduce the burdens of unreasonable textbook costs to our
students and society. The LibreTexts project is a multi-institutional collaborative venture to develop the next generation of open-
access texts to improve postsecondary education at all levels of higher learning by developing an Open Access Resource
environment. The project currently consists of 14 independently operating and interconnected libraries that are constantly being
optimized by students, faculty, and outside experts to supplant conventional paper-based books. These free textbook alternatives are
organized within a central environment that is both vertically (from advance to basic level) and horizontally (across different fields)
integrated.
The LibreTexts libraries are Powered by NICE CXOne and are supported by the Department of Education Open Textbook Pilot
Project, the UC Davis Office of the Provost, the UC Davis Library, the California State University Affordable Learning Solutions
Program, and Merlot. This material is based upon work supported by the National Science Foundation under Grant No. 1246120,
1525057, and 1413739.
Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not
necessarily reflect the views of the National Science Foundation nor the US Department of Education.
Have questions or comments? For information about adoptions or adaptions contact info@[Link]. More information on our
activities can be found via Facebook ([Link] Twitter ([Link] or our blog
([Link]
This text was compiled on 01/05/2024
TABLE OF CONTENTS
Licensing

1: Introduction to Project Management

1.1: Learning Objectives and Overview
1.2: Definition and Key Concepts of Project Management
1.3: Project Characteristics
1.4: Project Constraints
1.5: Project Success
1.6: Project Management Life Cycle and Process Groups
1.7: Project Management Knowledge Areas
1.8: Key Takeaways
1.9: Questions and Exercises
1.10: Attribution

2: Strategy, Objectives, and Project Selection

2.1: Learning Objectives and Overview
2.2: Business Strategy and Goals
2.3: SMART Objectives
2.4: Business Case
2.5: Project Selection Process
2.6: Key Takeaways
2.7: Questions and Exercises
2.8: Attribution

3: Project Initiation
3.1: Learning Objectives and Overview
3.2: Project Charter
3.3: Project Environment
3.4: Organizational Dimensions and the Structure
3.5: Project Management Office (PMO)
3.6: Key Takeaways
3.7: Questions and Exercises
3.8: Attribution

4: Project Planning and the Project Scope

4.1: Learning Objectives and Overview
4.2: Project Planning
4.3: Eliciting Requirements
4.4: Requirements Traceability Matrix
4.5: Project Scope Management
4.6: Microsoft Project Tutorial
4.7: Key Takeaways
4.8: Questions and Exercises
4.9: Attribution

1 [Link]
5: Stakeholder Management
5.1: Learning Objectives and Overview
5.2: Identifying Stakeholders and Managing Their Expectations
5.3: Stakeholder Analysis
5.4: Managing and Monitoring Stakeholder Engagement
5.5: Key Takeaways
5.6: Questions and Exercises
5.7: Attribution

6: Communication Management, Leadership, and Project Team

Management
6.1: Learning Objective and Overview
6.2: Communications Management
6.3: Communication Types
6.4: Communications Management Protocol
6.5: Leadership Skills
6.6: Leadership Styles and Servant Leadership
6.7: Creating a Project Culture
6.8: Developing and Managing a Project Team
6.9: Key Takeaways
6.10: Questions and Exercises
6.11: Attribution

7: Scheduling
7.1: Learning Objectives and Overview
7.2: Project Schedule Management Plan
7.3: Defining Activities
7.4: Estimating Activity Durations
7.5: Creating an Activity Network Diagram
7.6: Creating a Gantt Chart
7.7: Microsoft Project Tutorial
7.8: Key Takeaways
7.9: Questions and Exercises
7.10: Attribution

8: Resource Management
8.1: Learning Objectives and Overview
8.2: Resource Management
8.3: Project Resource Management Plan
8.4: Estimating the Resources
8.5: Resource Allocation
8.6: Solving Resource Overallocation- Resource Leveling
8.7: Schedule Compression Techniques
8.8: Microsoft Project Tutorial
8.9: Key Takeaways
8.10: Questions and Exercises
8.11: Attribution

2 [Link]
9: Budget and Procurement
9.1: Learning Objectives and Overview
9.2: Project Costs
9.3: Project Cost Management Plan
9.4: Estimating Costs and Determining Budget
9.5: Establishing the Project Budget
9.6: Managing Project Costs
9.7: Project Procurement Management
9.8: Microsoft Project Tutorial
9.9: Key Takeaways
9.10: Questions and Exercises
9.11: Attribution

10: Project Risks

10.1: Learning Objectives and Overview
10.2: Project Risk
10.3: Risk Management Plan
10.4: Identifying Risks
10.5: Risk Assessment
10.6: Developing and Implementing Risk Responses
10.7: Key Takeaways
10.8: Questions and Exercises
10.9: Attribution

11: Monitoring and Controlling

11.1: Learning Objectives and Overview
11.2: Monitoring and Controlling Project Work
11.3: Qualitative Monitoring
11.4: Earned Value Management (EVM)
11.5: Change Control Process
11.6: MS Project Tutorial
11.7: Key Takeaways
11.8: Questions and Exercises
11.9: Attribution

12: Agile (Adaptive) Project Management

12.1: Learning Objectives and Overview
12.2: Introduction to Agile
12.3: Adopting and Creating an Agile Environment
12.4: Common Agile Framework and Methods
12.5: Recent Trends in Agile Project Management
12.6: Key Takeaways
12.7: Questions and Exercises
12.8: Attribution

13: Closing the Project

13.1: Learning Objectives and Overview
13.2: Closing the Project
13.3: Activities to Close a Project
13.4: Post Implementation Reviews and Archiving Documents

3 [Link]
 13.5: Validating the Realization of Business Benefits
13.6: Key Takeaways
13.7: Questions and Exercises
13.8: Attribution

Index

Glossary
Detailed Licensing

Detailed Licensing

4 [Link]
Licensing
A detailed breakdown of this resource's licensing can be found in Back Matter/Detailed Licensing.

1 [Link]
 CHAPTER OVERVIEW

1: Introduction to Project Management

1.1: Learning Objectives and Overview
1.2: Definition and Key Concepts of Project Management
1.3: Project Characteristics
1.4: Project Constraints
1.5: Project Success
1.6: Project Management Life Cycle and Process Groups
1.7: Project Management Knowledge Areas
1.8: Key Takeaways
1.9: Questions and Exercises
1.10: Attribution

This page titled 1: Introduction to Project Management is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

1
1.1: Learning Objectives and Overview
Learning Objectives
1. Define projects and explain the characteristics of the projects.
2. Explain two main project characteristics (uniqueness and being temporary) that distinguish projects from operations and
processes.
3. Identify primary project constraints.
4. Explain why projects cannot be successful all the time.
5. Elaborate on the project management life cycle, the process groups, and knowledge areas.

Overview
This chapter’s primary objective is to list and explain the key concepts related to project management and describe important
benefits related to projects as well as the formal study of project management. This chapter provides an overview of project
management, defining both projects and project management and exploring the difference between project management and
operations management. Technological innovations and disruptions, and constantly changing social and economic conditions
locally and all across the world impose new burdens on the organizations to shorten the time needed to develop and deliver new
products and services that would increase organizations’ competitive advantage. Therefore, many organizations have become more
aware of adopting a systematic project management approach that can drive the change they desire (see Chapter 12). This chapter
also provides the concepts of project life cycle, project management process groups, and project management knowledge areas
according to the PMBOK Guide 6th Edition.

This page titled 1.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

1.1.1 [Link]
1.2: Definition and Key Concepts of Project Management
Projects are defined by PMBOK Guide 6th and 7th editions as “a temporary endeavor undertaken to create a unique product,
service, or result”. These two characteristics will be detailed in the following section “Project Characteristics”. Besides, key project
management concepts, which are constraints, key success factors, project life cycle, project process groups, and knowledge areas,
will be delineated.
All of us are engaged in projects on a regular basis in our daily lives, and we use the term “project” frequently in our daily
conversations. Although it had not been put forward in an organized way, people have been undertaking projects since the earliest
days of organized human activity when our prehistoric ancestors had hunting parties. Large complex undertakings such as the
seven wonders of the world including the only surviving artifact, the pyramids of Giza, were also projects. Even something as
simple as creating a dinner or picking up your daughter from school can be considered a project. Renovating our house’s garage,
planning a Disney vacation for kids, getting married, and achieving a degree, diploma or certificate are all projects as well. One of
the common and most utilized project software programs, Microsoft Project Professional 2019, provides a “Wedding Planner”
template.
Examples of some projects and their outcomes can be given as planning and executing the summer and winter Olympic games,
building the Great Wall of China, developing the COVID-19 vaccine, constructing the Chernobyl New Safe Confinement,
preparation, and publication of a journal or a project management textbook, building the Suez Canal, development of a commercial
jet airplane such as Airbus A380 and Boeing 787, developing or modifying software packages, and successfully launching the
Hubble Space Telescope. Besides these far-famed projects, Project Management Institute’s (PMI) web pages on “PMI Project of
the Year Award”[1] and “Most Influential Projects”[2] would be very helpful to be familiar with some of the recent ongoing or
successful, and influential projects implemented all across the world.
Organizations of all shapes and sizes continue to transform the ways they innovate and deliver to continuously improve customer
satisfaction levels. If an organization wants to increase its revenue and profit, gain more market share, increase the number of loyal
customers, and ultimately obtain a stronghold in its market, it needs to plan and execute projects that will lead to and drive change
rather than just performing and relying on routine daily tasks. If we have a grocery market, selling the same products every day to
the customers would help us maintain the profits at a level we can survive. However, consider that there is another grocery market
started to operate in our neighborhood. Besides traditional in-person shopping, we all witness a significant surge in electronic
commerce websites’ product portfolio and sales (e.g., web-based businesses such as Amazon and AliExpress, click and mortar
businesses such as Walmart and Target). Together, both factors, a grocery market in the neighborhood and e-commerce websites,
could lead to a downward trend in sales and profit for our grocery market. Thus, even to protect our current position, we may have
to come up with new ideas that have not been implemented by us before. We can add new brands to our shelves, offer new product
lines, expand the store to accommodate more products, offer promotions to attract more customers, create social media and
YouTube videos, launch a new e-commerce website, or establish a partnership with food delivery companies such as Grubhub and
Uber eats. All of these ideas require preparing a business case to evaluate the feasibility of these ideas. If we decide to proceed with
this idea, we can initiate a project to generate outcomes that would produce tangible and intangible benefits for our grocery market.
Disruption is the new normal, but when an organization introduces change, it must be done correctly. Succeeding in such turbulent
times means organizations cannot afford to waste precious resources on failed projects. This is the primary reason why many
organizations recognize tools, techniques, and processes associated with project management, and implement a systematic project
management approach relying on best practices and lessons learned.

1. [Link] ↵
2. [Link] ↵

This page titled 1.2: Definition and Key Concepts of Project Management is shared under a CC BY-NC 4.0 license and was authored, remixed,
and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

1.2.1 [Link]
1.3: Project Characteristics
PMBOK Guides define a project as a temporary endeavor undertaken to create a unique product, service, or result. The starting
point in discussing how projects should be properly managed involves evaluating how we identify a project and understanding how
we differentiate it from daily operations, and hence, clearly outline which tasks cannot be defined as a project. Therefore, it is of
high importance to distinguish between a project and a process (or an operation that is a routine task repeated regularly).
A project has two primary attributes that distinguish it from ongoing and routine works that are business operations. They can be
listed as below:
1. Projects and their outcomes are unique.
2. Projects are temporary, that is, they have a definite beginning and ending date.
Projects are completed when the project goals are achieved or it’s determined that the project is no longer viable. Eventually, a
successful project meets or exceeds the expectations of the stakeholders.
In the following subsections, let us discuss these two distinctive characteristics.

Unique outcome
Projects produce unique products, services, or results. Projects exist to bring about a product, service, process, or outcome that
hasn’t existed or been used before by the implementing organization or beneficiaries. While some projects are based on previous
projects that were carried out in a similar fashion, each project is unique and begins with a business case and project charter.
Constructing a replica of a building should be also considered a project although the same architectural blueprints are used.
Although containing repetitive elements, this new construction work requires conceptualization and planning. A project manager is
assigned to that project, who creates, develops, and manages a new project team and prepares detailed planning for the project
constraints such as scope, schedule, budget, resources, risks, and quality. That building may be constructed in the same area (even
next to the existing building) or another city, state, or country. Naturally, construction at other locations could necessitate
substantial customization (tailoring) taking into account the internal influencers as well as external influencers such as weather,
legislative regulations, and supply chain factors in new locations.
Projects can involve developing and producing a new deliverable. Besides, in many cases, they may address improving and
modifying an existing deliverable. Examples of projects can be listed as below:
1. Modification of an ERP (Enterprise Resource Planning) system by revising the current modules and adding new modules,
2. Installing new safety features to a vehicle (e.g., new airbags, traction systems, accident prevention systems),
3. Remodeling a building or a parking lot,
4. Renovating the power lines all across a city or state,
5. Reorganizing the workflow in a workplace such as a restaurant, grocery market, local motor vehicles bureau, and a library,
6. Creating a designated area for self-checkout kiosks in markets,
7. Creating a new TV, YouTube, or social media advertisement for a hand sanitizer.
Each project requires a unique approach based on the objectives to be achieved, the complexity and/or the size of the work
required, the number, interests, and powers of stakeholders involved, and the clarity of the solutions being pursued. Those skilled in
the art and science of project management can tailor the use of tools, techniques, and processes to maximize the value delivered to
and by the organizations.
When the project deliverables are inspected and accepted by the client (i.e., customer or product owner), and the project is closed,
the project manager can hand over the deliverables to the operational units which can be either internal or external clients. For
example, if the project’s objective was to create a new payroll information system in an organization, the system is delivered to the
IT department and/or the payroll department of the organization. From there, these functional departments can utilize and maintain
the system. The payroll department can pay the employees’ salaries every month based on the inputs entered into the system.
Paying salaries to these employees regularly becomes an operation (a routine task). Thus, the organization can gain benefits from
the new system since payrolls are computed properly with minimum acceptable errors and by avoiding human errors. However,
whenever there is a new need to modify the system or purchase a new one, this should be treated as a new project, which will
require the establishment of a new project team and the assignment of a project manager. Therefore, this leads us to the second
characteristic of a project, which is its temporary nature.

1.3.1 [Link]
Temporary Nature
The second characteristic that distinguishes a project from an ongoing work is its temporary nature. Projects are not an everyday
business process and have a definite beginning date and an end date. A project is assigned a schedule with a certain completion
date because the ultimate objective of a project is to benefit from its deliverables. Therefore, a significant portion of project effort is
dedicated to ensuring that the project is completed at the appointed time. To do this, schedules are created to explicitly indicate
when tasks should begin and end. Activity network diagrams and Gantt charts help determine, visualize, and monitor the schedule
of the whole project and the interdependence among project activities. Projects can last minutes, hours, days, weeks, months, or
years.
In contrast with projects, operations are ongoing and repetitive. They involve work that is continuous without an ending date
wherein the same processes are 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 strategic goals and create a change in the organization to acquire new or
additional tangible or intangible benefits that cannot be acquired by conducting daily operations. Projects aim at moving an
organization from a current state to a future desired state where the organization could find the opportunity to move forward and
improve its financial and market conditions.
To illustrate this, consider a hypothetical automaker that operates on a global scale. Designing a new SUV and its components
based on a strategic objective, creating prototypes, and conducting crash and safety tests require a systematic project management
approach. After delivering the final product, this SUV can be placed into the assembly line in a factory. Whenever all the parts are
assembled in this manufacturing facility by workers, robotic arms, and machinery, and hundreds of vehicles are manufactured on a
daily, weekly, or monthly basis, this process becomes an operation. Ordering raw materials and vehicle parts to create many
vehicles in the factory constitutes the operational process which also consists of the transactions occurring along the supply chain
on an ongoing basis. As long as consumers demand this vehicle model and it is profitable for the company to manufacture and sell
it, the company can continue manufacturing it. All these repetitive and routine manufacturing processes can be considered an
operation. However, when there is a need to change some features of the vehicle (e.g., adding new airbags, modifying some engine
components), the company would need to start a new project.
A project is completed when its goals are accomplished, and its deliverables are approved by the client. Sometimes projects end
when it is determined that the goals and objectives cannot be accomplished or when the project outcome is no longer needed.
Serious schedule delays or a need to increase the budget substantially might cause the project sponsor to consider cancellation.
Some reasons to terminate the projects earlier than their scheduled completion time can be listed as follows:
1. Funding is exhausted or no longer available,
2. Resources (human or physical resources, or services) are no longer available,
3. The external client (funder) or the current or potential customers no longer wants the project completed,
4. The organization changed its strategy or determined a new priority,
5. Management decided to end the project, and
6. A legal cause or a new regulation necessitated the project to end.
It is not uncommon to terminate a project earlier than its completion time without achieving its goals and carrying out all the
activities. Nevertheless, these unsuccessful projects are still considered as projects.

Case Study 1.1: Characteristics of a Project Undertaken by Grocery LLC

The uniqueness of a project and its temporary nature would help a business or organization to assess if it has a project, and hence,
would need to implement a systematic project management approach and form a project team.
Consider a scenario that our organization is a grocery chain (Grocery LLC) with fifty branches across five states. During the
weekends, and between 4 pm and 7 pm during the week, these branches, in general, experience more than usual traffic of
customers. Therefore, long lines form in front of the current check-out stations where the cashiers work. Sometimes, it is not
possible to assign an adequate number of cashiers to all the existing stations because of the lack of personnel. The chief operations
officer (COO) of Grocery LLC visited CEO’s office several times to discuss potential solutions to this problem. With the help of
her operations team, she prepared a business case with several solutions. During the preparation of the business case, in order to
elicit the business, stakeholder, and solution requirements of these solutions, the team sent paper and e-mail surveys to all the
branches to understand managers’ and employees’ expectations and interviewed ten managers, ten supervisors, and thirty
employees who volunteered for follow-up and further examination. Furthermore, two hundred customers who volunteered and

1.3.2 [Link]
were given a $20 gift card to spend at the grocery market were interviewed when they visited these branches to do their shopping
during the busy hours. The team also visited other grocery chains’ markets which are the main competitors of Grocery LLC to
observe their daily operations. The team also collaborated with a market research consultancy company for further analysis and to
receive expert judgment. Among several options, the candidate solution with the highest priority was identified as the
establishment of self-checkout areas in all the branches. This solution was discussed in the project selection committee meeting at
which our organization’s CFO, CTO, and senior representatives from three departments (R&D, procurement, and human resources)
are the members. Based on pre-determined criteria and the weights that our organization uses for all the projects (see Chapter 2,
Table 2.5), this solution was selected to proceed with as a project. The committee decided to organize the project as a program and
to assign 5 project managers who are responsible for ten branches each. Grocery LLC wanted to start the project in January 2022
and finish all the works by August 2022. Once self-checkout areas are built and inspected to verify if they can be utilized to the full
capacity with all the requirements met, customers will be able to check out their items themselves without the presence of cashiers,
and, hence they can avoid crowded lines.
Based on this case study, we should ask, first off, if this can be considered a project. Projects are temporary, and hence have a
definite start date and an end date. They result in the creation of a unique product, service, process, or outcome, and are completed
when their goals and objectives have been met (or the objectives cannot be met, and accordingly they are terminated early) and
finally signed off by the project sponsor and the clients (funder).
Using these criteria, let’s examine if the establishment of self-checkout areas in all branches is a project:
Is it unique?
Yes, because the self-checkout kiosks don’t exist in this grocery chain. The outcome of this project offers a new way of service to
the customers which would increase the speed of checkouts and reduce the lines at traditional checkout stations. The main purpose
of this project is to provide faster service to the customers during busy hours. For each branch, a new design and implementation
can be required due to the different layouts and sizes, and according to varying demands of the local customers. Therefore, it is also
a unique endeavor for each branch.
Is this a temporary endeavor? Is there a way to determine when the project is completed?
Yes, the project starts in January 2022 and ends in August 2022. When the kiosks are installed and the self-checkout service is
offered to the customers at each branch, we can close the project and disband the project teams. Then, this will become an
operation that is carried out every day.
Besides these two characteristics, we should also ask another question that is related to the constraints of a project.
Is there a way to determine stakeholder satisfaction?
Yes, the expectations of the stakeholders will be documented in the form of requirements while preparing a needs assessment,
business case, and a benefits realization plan before a project start, and during the initiation and planning processes. These
requirements will be compared to the finished product to determine if the self-checkout stations could satisfy the expectations of
stakeholders, primarily market employees and customers.

Case Study 1.2: Characteristics of Another Project Undertaken by Grocery LLC (M-Commerce
Project)
Consider a new scenario for Grocery LLC. Physical sales have declined since the onset of the COVID-19 pandemic all across the
world. Customers prefer buying online instead of visiting a store in person since they have serious concerns to contract Covid-19.
Our fifty stores in five states lost around 30% of regular customers, and the revenue declined by 25% since the start of the
pandemic restrictions in March 2020. Considering the pessimistic trends forecasted regarding the pandemic as well as the
increasing digitalization of companies and consumers, the project selection committee decided to have a better online presence by
creating a mobile app and optimizing the website for mobile devices. Therefore, our current customers who purchase goods and
services from our grocery stores, as well as potential customers, will have the opportunity to purchase through their computers and
smartphones. So, our team was asked to elicit the requirements by communicating with the key stakeholders such as grocery
managers and employees, and customers. It was planned to start this project on May 2, 2022, and finish on October 27, 2022.
Let’s evaluate this project in terms of uniqueness and temporary nature.
Is it unique?

1.3.3 [Link]
Yes, because the grocery chain diversifies its sales channels by strengthening its online presence through optimizing its website for
mobile devices and creating a new mobile application. The outcome of this project offers a new way of service to the customers.
Is this a temporary endeavor? Is there a way to determine when the project is completed?
Yes, the project starts on May 2, 2022, and finishes on October 27, 2022. When the mobile app is ready for the customers to install
on their smartphones, and customers can view the website on their mobile devices, we can perform administrative and financial
tasks to close the project, and we can disband the project team. Then, this becomes a routine task for the operational units to
maintain and support the website and mobile app.
Is there a way to determine stakeholder satisfaction?
Yes, the expectations of the stakeholders will be documented in the form of requirements while preparing a business case, and
during the initiation and planning processes. The requirements for a mobile app and optimized mobile website will be compared to
the finished products to determine if they satisfy the expectations of stakeholders.

This page titled 1.3: Project Characteristics is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

1.3.4 [Link]
1.4: Project Constraints
Projects do not live in a vacuum. They are affected by many factors including constraints, assumptions, and internal and external
factors (referred to as Enterprise Environmental Factors – EEFs by PMBOK Guide 6th Edition). Three main constraints (i.e., triple
or iron triangle constraints) are scope, schedule, and cost, and they are considered the main pillars of a project. They are also
regarded as the main reason why we need a systematic project management approach. These primary constraints also compete with
each other. Therefore, project managers should consider trade-offs among them. For example, increasing the project scope may
require a revision of the schedule and budget. In many cases, expanding the project scope with more product specifications and
project activities would result in a longer schedule and higher budget. This trade-off will be discussed in the following sections, and
mostly in their respective chapters. Maintaining the balance among these constraints is difficult because projects are prone to
change. Thus, the technical and interpersonal skills of project managers, and how they utilize the best and proven practices of
project management, and the quality of a project team are essential prerequisites of conducting an effective project.
Besides triple constraints, the other three constraints which are also tightly linked to the triple constraints are resources, quality, and
risks. Tightly aligned with and at the top of all these six constraints, the success of a project depends on the client and/or
stakeholder satisfaction. Clients make their decisions to accept the final deliverables of a project by evaluating these constraints.

Scope
Project scope is the work performed to deliver a product, service, or result with the specified features and functions[1]. Scope refers
to 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 reflects the purpose of the project. The difference between the project and product scopes will be detailed in
Chapter 4 “Project Planning”.
A project is built upon the scope. After all the product or service requirements are elicited from all relevant stakeholders,
observations, documents, and other sources, the project manager can start working on the project activities which will be carried
out to meet these requirements. After product requirements and project activities are defined, and the activities are sequenced, the
project manager and the team can proceed with the estimation of activity durations, allocation of resources, estimation of costs, and
identification of risks, quality, and performance metrics.

Schedule
A schedule is a model for executing the project’s activities, including durations, dependencies, and other planning information[2].
Project scheduling provides a detailed plan that represents how and when the project will carry out all the activities that would lead
to the delivery of the products, services, and results defined in the project scope. It serves as a tool for communication and
collaboration with all the stakeholders and managing and monitoring their expectations. It also serves as a baseline for performance
reporting[3]. While monitoring the performance and progress of a project, a schedule is assessed commonly to identify problems
(e.g., delays, missed deadlines, incomplete deliverables) in the project. After the project team defines the activities based on the
product and project scopes, activity durations are estimated, activities are sequenced, their interdependences are outlined, and
hence, the resources can be allocated to each activity. The project schedule should also consider national, federal, or local holidays
and the absence of human resources due to vacations and other issues such as sickness and family issues. We will discuss
scheduling in Chapter 7 “Scheduling”.

Cost
Cost is the budget approved for the project including all necessary expenses needed to deliver the project. Within organizations,
project managers have to balance between not running out of money and not underspending because many projects receive funds or
grants that have contract clauses with 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 ultimately a limiting constraint; few projects can
go over budget without eventually requiring corrective action. We will cost management in Chapter 9 “Budget and Procurement”.

Quality
Quality is a combination of the standards and criteria to which the project’s products must be delivered for them to perform
effectively. As quoted by the PMBOK Guide 6th Edition from ISO 9000 standards, “quality as a delivered performance or result is
the degree to which a set of inherent characteristics fulfill requirements”. 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

1.4.1 [Link]
requirements, or service levels, such as availability, reliability, and maintainability, and have acceptable finish and polish. We will
discuss quality management in Chapter 11 “Monitoring and Controlling”.

Resources
In order to carry out and complete project activities, the project manager should allocate various resources such as human resources
for the project team and all other activities, physical resources (e.g., equipment, materials, facilities, software, testing environments,
licenses, infrastructure, and supplies), and services (e.g., consulting and subcontractors). Resources can be determined and
allocated when the activities are defined and scheduled. Then, the budget for each activity can be computed based on the allocation
of all resources. We will discuss resource management in Chapter 8 “Resource Management”.

Risks
A risk is an uncertain event or condition that, if occurs, has a positive or negative effect on one or more project objectives. Negative
risks are called threats, and positive risks are called opportunities[4]. Two main factors determine the severity of a risk: (1)
Probability of the occurrence, and (2) impact on the project. Risk responses are planned based on the severity level. We will discuss
individual and overall project risks and their management in Chapter 10 “Project Risks”.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2021). A guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.).
Project Management Institute. ↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
4. Project Management Institute. (2021). A guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.).
Project Management Institute. ↵

This page titled 1.4: Project Constraints is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

1.4.2 [Link]
1.5: Project Success
Project success and project management success are generally evaluated as different concepts. Project success deals with the
impacts of a project’s final product or service on stakeholders. Projects aim to create a unique outcome. Project management
success focuses on the processes of a project including the successful accomplishment of the scope, within budget (cost), within
time (schedule), and quality aspects. In our grocery chain example, we can close the project when the self-checkout areas are
inspected by the inspection committee that is composed of the representatives of the operational unit which is responsible for all
fifty markets, and also several store managers. The evaluation and acceptance are conducted by the inspection committee by
comparing the requirements with the final deliverables, validating that all the requirements have been implemented, and the self-
checkout stations are ready to use by the customers. The inspection committee checks all fifty branches to confirm if the
requirements in the project scope were met, and quality standards are complied with. Let’s assume that the project finished on time,
and the budget was not exceeded. Therefore, we can consider this as a project management success. Eventually, we can close the
project and disband the project teams.
After these self-checkout areas opened for the customers, we observed that most of the customers started to avoid these areas and
continued to use checkout stations where cashiers and baggers are available even though customers waited in lines for more than
ten minutes. This project was successfully managed but did not meet the client and customer expectations. Projects are initiated by
organizations to address business needs (problems or opportunities) and create tangible and intangible benefits by creating an
outcome that organizations can benefit from. Realized value of the project can be measured by the project stakeholders. However,
our company couldn’t gain the expected value. When the underlying reasons were investigated, it was found that lack of human
contact was the main reason. Most of the customers, especially Generation X and baby boomers, still wanted to maintain an
interaction with employees to ask for the warranties, the quality of the items, or even have a short chat with the cashiers and
baggers. Since it was not a problem due to the technology but affected the solution significantly, the COO and her team decided to
add some employees in these areas to help the customers. After changes were done, it was observed that more customers started
using the self-checkout areas. However, the operational team decided to monitor the performance of these areas to take further
actions if needed.
It is evident that not all projects benefit from successful completion. Many factors influence the success of a project. PMI 2020
Pulse of the Profession[1] reported that 11.4% of investment is wasted due to poor project performance. What makes it worse is that
this percentage spikes up to 67% in the organizations that undervalue project management as a strategic competency for driving
change. PMI’s same study reported that the factors responsible for the failure were lack of clearly defined and/or achievable
milestones and objectives to measure progress (37%), poor communication (19%), lack of communication by senior management
(18%), employee resistance (14%), and insufficient funding (9%).
Another report by the Standish Group, “CHAOS 2020: Beyond Infinity”, indicated that 31% of projects were successful while 50%
were challenged and 19% failed[2]. This report referred to three factors to improve project performance, that are good sponsor, good
team, and good place.
Consequently, a project should be managed effectively by a project manager and the team. If not done so, projects may fail due to
the factors listed below:
Unrealistic and vague goals
Uncontrolled expansion of the project scope (Scope creep)
Absent or ineffective relations with the clients/customers and other stakeholders
Cost overruns
Schedule delays
The insufficient amount and/or quality of resources
Toxic organizational culture and politics (e.g., mistreatment, aggression, incivility, harassment)
Organizational and/or team conflicts
Poor communication with stakeholders
Unsatisfied stakeholders
Ineffective quality assurance and inspections, and/or poor quality

1.5.1 [Link]
 1. PMI (2020). Ahead of the Curve: Forging a Future-Focused Culture. Pulse of the Profession.
[Link]
2. [Link] ↵

This page titled 1.5: Project Success is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

1.5.2 [Link]
1.6: Project Management Life Cycle and Process Groups
Projects start their life by developing the project’s foundations (i.e., primary objectives, high-level scope, schedule, budget and
risks, project team composition), continue with planning all the knowledge areas, executing all the activities, and producing the
outcomes (i.e., products, services, or processes), and end by reaching a close-out by archiving all the documents, completing all
administrative works, and disbanding the team. This is the life cycle of a project, which makes it temporary and unique. This life
cycle is composed of stages or phases which are generically named as starting (initiating, conceptualization), planning (organizing
and preparing), implementing (executing, carrying out), and termination (close-out, ending) (Figure 1.1). These phases can also be
named differently based on the industry, product scope, project complexity and size, needs of management, legal or regulatory
requirements, decision points such as go/no-go decisions, and milestone review. For example, if the project aims to create an
information system such as a payroll system, project life cycle stages can be named as feasibility study, elicitation of customer
requirements, development of solutions, design, creating prototypes, coding, testing, transiting, commissioning, milestone review,
lessons learned, administrative closure, and archiving.

Figure 1.1 Project Life Cycle Phases

While project life cycle stages offer a step-by-step process to manage a project, practical issues require focusing on processes and
their groups as described by the PMBOK Guide 6th Edition. The project life cycle is managed by executing a series of project
management activities known as project management processes. These processes are prescriptive, which means that they explicate
each process within an input-output diagram where various project management tools and techniques are utilized. Although they
are very helpful for project managers, PMBOK Guide 6th edition always emphasizes the tailoring of processes and techniques
based on each project’s own characteristics. This is why PMBOK Guide 7th Edition adopted a new approach through which the
processes have been replaced by principles. Nevertheless, project managers can still benefit from the process-centered approach as
processes provide a comprehensive guideline.
Each process makes use of inputs and produces outputs by using appropriate tools and techniques. These processes can be
implemented globally across industries. For example, one of the processes, developing a project charter, is the starting point for all
projects regardless of their industry, size, complexity, and location. This process uses business documents, agreements, enterprise
environmental factors, and organizational process assets as inputs. It produces the outputs as a project charter and assumption log
by utilizing tools and techniques such as expert judgment, data gathering, interpersonal and team skills, and meetings.
Different from project life cycle phases, but in line with them, these processes are grouped inside five project management process
groups according to the PMBOK Guide 6th Edition. Names of these groups and their purposes are provided below:
1. Initiating
To define a new project or a new phase of an existing project by obtaining authorization to start the project or phase.
1. Planning
To establish the scope of the project, refine objectives, and define the course of action required to attain the objectives.

1.6.1 [Link]
 2. Executing
To complete the work defined in the project management plan to satisfy the project requirements.
3. Monitoring and Controlling
To track, review, and regulate the progress and performance of the project, to identify any areas in which changes to the plan
are required, and to initiate the corresponding changes.
4. Closing
To formally complete or close the project, phase, or contract.
An important factor that distinguishes these process groups from the life cycle stages is the addition of monitoring and controlling
as a separate process group. Monitoring and controlling process group is performed throughout the project as it is of high
importance and necessity to ensure that the project is on the track, and to intervene in problems when detected. As seen in Figure
1.2, these process groups overlap with one another, and the sharp boundaries in the project life cycle disappear, which makes it
more realistic. For instance, planning continues with lower levels of process interaction and effort while executing process group is
conducted since plans and product requirements are subject to changes due to the factors such as changes in stakeholder
requirements, dynamic market conditions, and technological advancements.

Figure 1.2: Project Management Process Groups (Adapted from PMBOK Guide 6th Edition)

This page titled 1.6: Project Management Life Cycle and Process Groups is shared under a CC BY-NC 4.0 license and was authored, remixed,
and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

1.6.2 [Link]
1.7: Project Management Knowledge Areas
Another way of categorizing processes is through the knowledge areas according to the PMBOK Guide 6th edition. These
knowledge areas are defined by knowledge requirements. They are:
1. Project Integration Management
2. Project Scope Management
3. Project Schedule Management
4. Project Cost Management
5. Project Quality Management
6. Project Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management
10. Project Stakeholder Management
These knowledge areas constitute the basic layout of almost all project management textbooks. This also would be the main
approach we are following throughout this book.

This page titled 1.7: Project Management Knowledge Areas is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated
by Abdullah Oguz (MSL Academic Endeavors) .

1.7.1 [Link]
1.8: Key Takeaways
Key Takeaways
A project is a temporary endeavor undertaken to create a unique product, service, or result.
A project has two distinctive characteristics that distinguish it from ongoing and routine works – business operations. Projects
are unique and temporary.
Projects are confined to a variety of constraints. Triple (iron triangle) constraints are scope, schedule, and cost. Besides, and
tightly linked with triple constraints, resources, quality, and risks are also evaluated as constraints.
Project success deals with the impacts of a project’s final product or service on stakeholders. Project management success
focuses on the processes of a project including the successful accomplishment of the scope, within budget (cost), within time
(schedule), and quality aspects. A project may be successfully managed but not meet the client or customer’s expectations.
The project life cycle is composed of phases which are generically named as starting (initiating, conceptualization), planning
(organizing and preparing), implementing (executing, carrying out), and termination (close-out, ending).
Different from project life cycle phases, but in line with them, processes are grouped inside five project management process
groups according to the PMBOK Guide 6th Edition. They are named initiating, planning, executing, monitoring and controlling,
and closing.
Project management is also assessed in terms of knowledge areas that constitute the basic layout of most of the project
management textbooks.

This page titled 1.8: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

1.8.1 [Link]
1.9: Questions and Exercises
There are 10 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 1.9: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

1.9.1 [Link]
1.10: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).

This page titled 1.10: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

1.10.1 [Link]
 CHAPTER OVERVIEW

2: Strategy, Objectives, and Project Selection

2.1: Learning Objectives and Overview
2.2: Business Strategy and Goals
2.3: SMART Objectives
2.4: Business Case
2.5: Project Selection Process
2.6: Key Takeaways
2.7: Questions and Exercises
2.8: Attribution

This page titled 2: Strategy, Objectives, and Project Selection is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated
by Abdullah Oguz (MSL Academic Endeavors) .

1
2.1: Learning Objectives and Overview
Learning Objectives
1. Define the business strategy and goals that constitute the basis of business cases and projects in an organization, and describe
the strategy cycle.
2. Create SMART objectives that can be used in business cases, project charters, and project management plans.
3. Outline the content of a business case that would lead to the selection of projects.
4. Employ a variety of selection models to select projects.

Overview
Projects don’t start from out of anywhere. Before the organization’s project selection committee and/or executive management
decides on which projects the organization can go with, the reasons to start a project must be delineated in a pre-project stage. This
stage often consists of the preparation of a business case accompanied by a needs assessment and a benefits realization
management plan. A business case is a document that helps an organization decide whether the project will have a positive
economic, financial, and/or social impact. Business analysts, systems analysts, or product managers, or a team composed of them
and relevant stakeholders can prepare a business case. In many cases which are not rare, project managers can be assigned with the
task to create a business case during the initiation of a project if the project’s feasibility hasn’t been assessed before. Organizations
produce plenty of business cases in which the organizational needs are detailed. However, due to the scarcity of resources, time,
and budget, and also taking into consideration the boundaries determined by the organizational priorities and strategic objectives,
organizations choose only some of the business cases and their solutions as projects to develop. Project managers may not
participate in this process. Nevertheless, it is of utmost importance for the project managers and teams to be familiar with the
process since business cases constitute the basis of projects and they include fundamental information about the projects. Business
cases are used as input to conceptualize a project and lead directly to the preparation of a project charter through which project
managers can receive the authorization to start the project.

This page titled 2.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

2.1.1 [Link]
2.2: Business Strategy and Goals
Organizations exist to fulfill a purpose. These purposes are analyzed through a process and ultimately expressed in an
organization’s vision and mission statements. Vision statements are often very broad and they describe what the organizational
leaders want the organization to accomplish. Mission statements are more specific: they describe how the organization is going to
fulfill its vision. Recently, on many organizations’ websites, mission and vision statements have not been explained separately, but
as one statement named “mission statement”. Organizations may also elaborate on their principles, values, culture, and goals to
explicate their missions. Some examples of vision and mission statements as well as other information such as principles, values,
and culture are provided below:
LinkedIn [1] :
Vision: Create economic opportunity for every member of the global workforce.
Mission: The mission of LinkedIn is simple: connect the world’s professionals to make them more productive and
successful.
Facebook [2] :
Mission: Give people the power to build community and bring the world closer together.
Culture: At Facebook, we are constantly iterating, solving problems, and working together to connect people all over the
world. That’s why it’s important that our workforce reflects the diversity of the people we serve. Hiring people with
different backgrounds and points of view helps us make better decisions, build better products and create better experiences
for everyone.
Ikea [3] :
Vision: Our vision is to create a better everyday life for the many people – for customers, but also for our co-workers and
the people who work at our suppliers.
Business idea: While our vision tells us why we exist, our business idea tells us what we want to achieve. And for
everyone that has visited IKEA, our business idea is pretty obvious – “to offer a wide range of well-designed, functional
home furnishing products at prices so low, that as many people as possible will be able to afford them.”
Microsoft [4] :
Mission: Our mission is to empower every person and every organization on the planet to achieve more.
One way to consider the interrelated nature of Vision and Mission Statements, as well as other core components of an organization,
is to think about them as part of what is called a Strategy Cycle. Figure 2.1 presents an orderly process for strategic management
that helps us understand the process and the components of strategic analysis. The cycle ends with “vision and mission” statements
which convey the executive summary of the whole process. We should also keep in mind that, most of the time, top managers deal
with these steps simultaneously rather than following a stepwise approach.

2.2.1 [Link]
 Figure 2.1: The strategy cycle.. Attribution: Rice University, OpenStax

Organizations create specific strategies that should be pursued in the long term. Projects are often used to help carry out those
strategies. These long-term objectives help organizations to gain a competitive advantage and a higher market share, and eventually
to acquire a variety of tangible and intangible benefits in line with organizations’ field of operations (e.g., businesses, government
agencies, nonprofits). These strategies are directly linked to the objectives being pursued and will vary widely depending on the
industry and maturity of the organization. Whereas nonprofits or government agencies pursue to offer a public and social benefit,
companies would target to acquire financial benefits. Examples of strategies an organization may implement include the launch of
new products and services, the introduction of new technology, the streamlining of operational processes, and employee
development initiatives. The strategies are embodied in objectives where they are described in detail. The following section
“SMART objectives” discusses how these objectives can be created in a way that makes sense to the organization and all the
stakeholders
After the identification of strategic objectives, organizations choose strategies that will guide them for a period of time (i.e., one
year, three, five, or ten years), and move into the strategy implementation stage. Depending on the complexity of the changes being
introduced, the strategies may be implemented as individual stand-alone projects or programs consisting of multiple projects which
are related to each other. Project and program managers apply their expertise to the implementation domain and play a vital role in
helping organizations achieve their vision and mission. It is critically important that project and program managers understand an
organization’s strategies and objectives. This knowledge allows them to ensure that the decisions being made in their projects and
programs are aligned with the organization’s strategic direction.

1. [Link] ↵
2. [Link] ↵
3. [Link] ↵
4. [Link] ↵

This page titled 2.2: Business Strategy and Goals is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

2.2.2 [Link]
2.3: SMART Objectives
All the business cases, projects, project deliverables, activities, and milestones are characterized with objectives that describe what
is expected to be achieved at the end. The information provided in this subsection can be used not only for business cases but also
for projects and their components. Successful organizations are intentional about the actions they take to fulfill their vision and
mission. These organizations analyze their external and internal environments to understand the opportunities and threats present in
the environments in which they operate (see Chapter 3 – Project Initiation). An organization also must analyze and work within its
own strengths and weaknesses. This analysis directly refers to a SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis.
These analyses can be used to inform the decision-making that follows.
The primary goal of a business case and a project and their objectives must be clearly defined, must contain a measure of how to
assess whether they have been achieved, and should be realistic. A commonly utilized guideline to create this kind of objective is to
follow the SMART protocol. SMART is an acronym that represents the criteria of being specific, measurable, achievable, relevant,
and time-based. SMART objectives also serve as performance metrics to monitor the progress of a project and decide whether the
outcomes are successful and can be accepted by the client or customer. Thus, the project manager can monitor and control these
performance metrics.
Let’s use a scenario to explicate each SMART criterion. Consider that our organization which is a regional office of a government
agency (Department of Environment), named as Smalltown Office, has experienced some problems in providing quality service to
the citizens in that region. We, as a team, were assigned to examine the problem and offer some solutions to overcome this quality
problem.
Specific [1]
We should develop unambiguous objectives that all our stakeholders can understand what we want to achieve. Thus, these
objectives should be well-defined, specific, and written in clear, concise, and understandable terms. While creating an objective, we
should ask “What do we want to accomplish?”, “What do we intend to impact?”, “Why is this goal important?”, “Who is
responsible for carrying out the action?”, and “Who is our target audience/population?”. Such questions would help us create
specific objectives.
Based on our regional office’s quality service problem, the business analyst created one of the business requirements as follows:
“The Smalltown Office affiliated with the Department of Environment in the State X will provide quality improvement training to
the staff.”
This objective can be considered specific as it addresses the primary objective by referring to the target population and responsible
organization, and we want to achieve. However, it still lacks other elements of SMART.

Measurable
The success of a project relies on measurable quantitative criteria that must be met to achieve the objectives. If we don’t use any
metrics to measure the progress and performance, we can never be sure if we are on the track and can accomplish the targets when
we finish the tasks or a project. These quantitative measures can indicate a number, percentage, or any standard unit. By means of
measures, we can know that change has occurred how much, and in what direction. Besides, we should consider the source of
verification and the data to prove the target is met. In our example, we can quantify the objective by adding the percentage of
employees who are expected to receive this training.
“The Smalltown Office affiliated with the Department of Environment in the State X will provide quality improvement training to
at least seventy-five percent of the staff members who communicate and interact directly with the citizens.”
Sometimes, it is not possible to directly measure the performance or achievement. Quality improvement training could be an
effective method to increase the quality of the services provided to the citizens. However, it is of high importance to ask directly the
citizens using interviews or surveys about their satisfaction level with the services they receive. Therefore, we can support this
objective with another objective as below:
“The satisfaction level of the citizens who receive service from Smalltown Office will increase by 25% according to a survey
replied by at least 500 citizens.”
In order to measure the improvement of 25%, the average satisfaction level of the citizens before the training is delivered should be
measured, which would constitute the baseline. We also make this objective specific by adding the target audience who are at least

2.3.1 [Link]
500 citizens.

Time-based
The last letter of the SMART acronym refers to “time-based” objectives. The SMART protocol doesn’t necessarily impose an order
of letters to follow while creating SMART objectives. However, discussing the time-based criterion can be more practical taking
into consideration the nature of time as a measure itself. While assessing this criterion, we can address the issues such as how long
to expect a project to take, and how much time for different success metrics to be met.
“The Smalltown Office affiliated with the Department of Environment in the State X will provide quality improvement training to
at least seventy-five percent of the staff members who communicate and interact directly with the citizens by the end of July 2022.”
“The satisfaction level of the citizens who receive service from Smalltown Office will increase by 25% according to a survey
replied by at least 500 citizens by the end of December 2022.”
While we create these objectives, we should also consider if the performance measures and deadlines are realistic (achievable).

Achievable
We should also consider the factors that may affect the achievability of objectives. These factors include the evaluation of
resources, knowledge, and time that are available to carry out the tasks to achieve the objectives. Therefore, in order to clarify
achievability, it may be helpful for our team to explain who will deliver this quality improvement training to Smalltown Office
employees, the availability of funds that can be allocated to the trainers, and the availability of an adequate number of employees
that can serve the citizens in a timely manner while others receive the training. We should also clarify if the time to achieve these
objectives is realistic. Can Smalltown Office provide this training to at least 75% of the staff by July 2022? Or do we need to
reassess the percentage and the deadline? Constraints that may affect the achievement of these objectives should also be taken into
account.
As can be seen here, SMART is an iterative process through which each criterion should be evaluated constantly considering the
impact of each of them on other criteria.

Relevant
The last criterion that needs to be considered is the relevance of these objectives with higher-level organizational goals such as
strategic objectives, mission and vision statements, and the goals of programs or portfolios that the business need or project is
affiliated with. This alignment can ensure that the business case or project would have a higher chance of approval from the
organizational leadership and greater buy-in from the stakeholders.
In our example for Smalltown Office, we should check the strategic plan of the Department of Environment. We need to see if
there is an objective for the quality management and improvement that is planned for the organization as a whole, or the
departments and regional offices. The review should not be limited to the strategic plan, but also other projects, programs, and
portfolios since there may be a planned or ongoing project regarding quality management. Therefore, we can also avoid
duplications and redundancy, and save time and budget.

Case Study 2.1: SMART Objectives for Grocery LLC’s Mobile-Commerce Scenario
We started working on a case study in Chapter 1 as regards a grocery chain, Grocery LLC, with fifty branches across five states.
There were two business needs for this scenario:
1. Long lines form in front of the current check-out stations where the cashiers work.
2. Declining sales in markets since the onset of the COVID-19 pandemic.
Let’s work on the second business need to develop SMART objectives. The primary objective is to create solutions for customers
who purchase goods and services from our grocery stores through their smartphones. Based on the business case, it was decided to
produce two solutions which are the optimization of the mobile website for Android and IOS, and a smartphone application.
Objectives in line with these two solutions have been determined as:
1. To redesign the website in 2 months so it’s responsive and easier for the customers to place orders on their smartphones.
2. To create a new mobile application in 2 months that can work in both operating systems (Android and IOS).

2.3.2 [Link]
These two objectives can be considered specific as both describe what is intended to achieve for which audience. Besides, both are
time-based. So, we know when we can have both solutions operational for the online customers. But we need more to evaluate
other criteria (measurable, achievable, and relevant). Let’s create another objective that supports these two objectives:
In three months after the mobile website and the new mobile application go live, online sales will increase at least 25%,
customer satisfaction will increase at least 20%, and we can retain our loyal customers.
This objective provides us with the quantitative measures to evaluate the effectiveness of the two solutions. Both help us
understand if the customers do online shopping and if they are happy with their online shopping experience. Besides, we can ask
our loyal customers if they also buy online, and thus they don’t often prefer other stores and e-commerce websites to substitute for
the physical shopping they used to do in our grocery markets. To verify these measures, we should have reliable sources as detailed
below:
Online sales figures before the mobile solutions are introduced and three months after they go live will be compared.
Two surveys (before the mobile solutions are introduced and three months after they go live) will be conducted by a market
research company to measure the satisfaction level of customers.
The customers who have bought items from our company for the last three years will be interviewed to understand if they still
do their shopping at our grocery markets and on new mobile solutions.
We also should answer these questions to assess if these objectives are achievable and relevant?
Does the grocery chain have the time, budget, and resources to conduct and finish the whole project?
Are these objectives in line with the grocery chain’s mission statement, and strategic objectives?
Are there any conflicts with other ongoing or future projects? Is there a need to cooperate with other projects to share and
assign resources or to synchronize some activities and deliverables?

1. [Link] ↵

This page titled 2.3: SMART Objectives is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

2.3.3 [Link]
2.4: Business Case
Organizations initiate projects to exploit business opportunities that are aligned with the organization’s strategic goals or eliminate
business problems they encounter[1]. Projects are generally preceded by a business case that provides the economic, financial,
and/or social feasibility and justification of the business need (Figure 2.2). However, some projects may be initiated in a short time
with an order from the CEO or executive management team to address competitive measures, government mandates, or an
exclusive inclination[2]. Hence, there may not be a formal business case that the project team can utilize to initiate the project.
Nevertheless, in such situations, project managers are generally asked to conduct a needs assessment and feasibility study as well
as a benefits management plan. Business cases aim to respond to a need, generally in the form of a problem or an opportunity, and
they are generally prepared by business analysts in an organization in collaboration with relevant units and stakeholders.
A business case attempts to elaborate on the need for a project by providing an analysis of the current state, a description of the
desired future state, and the actions to take to fill the gap between the current state and the desired future state. It also includes
business, stakeholder, solution, and transition requirements, designs and recommended solutions generated according to these
requirements, and the evaluation of solutions to understand the potential value of these solutions[3]. A business case is accompanied
by a needs assessment and benefits realization management plan. A needs assessment often precedes the business case, and it is
used to assess the current internal and external environments and current capabilities of the organization to determine the viable
solution options that, when pursued, would help the organization meet the desired future state[4].

Figure 2.2: Pre-Project Work, Project Life Cycle, and Post-Project Work.. Source: PMBOK Guide 6th Edition
The value of a business case to the project is two-fold. First, it is used as an input in the development of a project charter during the
initiation (starting, conceptualization) project life cycle stage. Additionally, it is utilized as input to identify stakeholders who may
be affected by or may affect decisions, activities, or outcomes of a project[5]. Therefore, business cases are utilized as a basis for
authorization of further project management activities.
A business case can also be described as an economic feasibility study documented to justify and establish boundaries for the
project. The validity of benefits is established through two accompanying processes, which are business needs analysis and cost-
benefit analysis. Therefore, the required investment to start a project to acquire the expected outcomes can be justified from a
business standpoint.
While many business cases share common elements, each one is tailored to the organization in which it is used. A business case
can be formatted based on the needs of the organization and/or the organization’s templates in its knowledge repository. The main
components of a business generally consist of:
1. Need statement (Underlying problems or opportunities)
The cause-effect diagram (fishbone diagram) is a useful instrument in this stage to identify the underlying issues rather than
describing the surface-level issues.
If it is an opportunity, the main contributors are investigated.
2. Statement of goals (Business requirements)

2.4.1 [Link]
 3. Stakeholders and their requirements
4. Analysis of current state and future state, and creation of a business change strategy
5. Constraints, dependencies, assumptions, risks, critical success factors, and decision criteria
6. Designs and alternative solutions
7. Potential value (benefits and costs)
Although preparation of a business case and its accompanying documents are considered a pre-project work, project managers may
also involve in this process, in particular, if a PMO (Project Management Office) exists in an organization, or the project initiation
is requested from the top level or if it is an urgent request from a client.
Project managers or project steering committees use the information available in a business case to initiate the project, identify
stakeholders, and develop a project charter. A business case helps create performance metrics that are utilized to measure the
project success against the objectives whenever a deliverable is produced and the project outcomes are generated at the end of the
project.
Business cases play an essential role during project selection. Project selection committees or senior managers assess all the
business cases and their recommended solutions as candidate projects. Due to various factors such as time, budget and resource
constraints, internal and external factors, and organizational strategic priorities and plans, organizations cannot put all the projects
into implementation. The next section discusses the project selection criteria.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2015). Business analysis for practitioners: A practice guide. ↵
3. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide),
version 3.0. Toronto, Ont: International Institute of Business Analysis. ↵
4. Project Management Institute. (2015). Business analysis for practitioners: A practice guide ↵
5. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 2.4: Business Case is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

2.4.2 [Link]
2.5: Project Selection Process
When selecting a project, both quantitative and qualitative analysis is useful in order to arrive at projects which have the greatest
potential impact. Generally, more complex projects involve a greater amount of risk. They also require a longer implementation
and business benefits realization period. Therefore, project selection decisions will weigh the benefits offered with the timeframe
required to realize these benefits. Organizations will often consider the payback period, which refers to the amount of time it takes
to recover the cost of an investment. Projects that offer significant benefits, and that can be realized in a relatively short time, are
more likely to be approved. However, this is only one of the methods to evaluate if a project is favorable compared with other
projects.[1]
In Chapter 1, we started evaluating the uniqueness and temporary nature of a project through which our grocery market chain,
Grocery LLC, aimed at establishing self-checkout areas at all fifty markets across five states to solve the problem of more than
usual traffic between 4 pm and 7 pm during the weekdays. Assume that we had two solution candidates for this problem. One is the
self-checkout area to be established at all fifty stores (See Chapter 1, Case Study 1.1). Let’s name the “establishment of self-
checkout areas” project as “Project B”. We also wanted to evaluate another solution through which we can increase the number of
checkout stations where our cashiers work. This solution is named Project A.
Table 2.1 provides cash inflows and outflows of two candidate projects assuming that both project deliverables have a lifetime of
five years. As can be seen in Table 2.1, the payback period for Project A would be three years, which means that our organization
can recover the cost ($100,000) of this project’s investment in three years.
-100,000 (year 0) + 30,000 (year 1) + 40,000 (year 2) + 30,000 (year 3) = 0
Table 2.1: Cash outflow and inflows of two projects ($)

Project A Project B

(Traditional checkout stations) (Self-checkout areas)

Year 0 ($100,000) ($200,000)

Year 1 $30,000 $15,000

Year 2 $40,000 $50,000

Year 3 $30,000 $75,000

Year 4 $10,000 $105,000

Year 5 $10,000 $75,000

For Project B, the payback period

would be 3.57 years (3 years + 60,000/105,000). As can be seen
in Table 2.2, when we finished the third year, the net cash flow was still negative
(-200,000 + (15,000 + 50,000 + 75,000) = – 60.000). Therefore, the breakeven point
would be after the fourth year. Because Project A’s payback period (3 years) is shorter
than Project B’s (3.57 years), we can prefer Project A over Project B only taking into
account the payback period.
Table 2.2: Net cash inflows of two projects ($)

Project A Net Cash Flow Project B Net Cash Flow

Year 0 ($100,000) ($100,000) ($200,000) ($100,000)

2.5.1 [Link]
 Year 1 $30,000 ($70,000) $15,000 ($185,000)

Year 2 $40,000 ($30,000) $50,000 ($135,000)

Year 3 $30,000 $0 $75,000 ($60,000)

Year 4 $10,000 $10,000 $105,000 $45,000

Year 5 $10,000 $20,000 $75,000 $120,000

However, this financial method ignores a crucial factor that may affect the real value of our cash inflows, which is the time value of
the money, that is affected by two main annual rates: (1) Inflation rate (pt), and (2) required rate of return (r). Therefore, the
discount factor needs to be incorporated into the computation to have real values.

In our example above, let’s take pt 0.02, and r 0.08. Our organization expects to earn a minimum of 0.08 annually on average when
we invest. This can also be considered as the opportunity cost.

For each year, we should multiply the discount factor by each cash inflow to find the real value.
Table 2.3: Net cash outflow and inflows of two projects with discount factors ($)

Project A Today’s Value Net Cash Flow Project B Today’s Value Net Cash Flow

Year 0 ($100,000) ($100,000) ($100,000) ($200,000) ($200,000) ($200,000)

Year 1 $30,000 $27,273 ($72,727) $15,000 $13,636 ($186,364)

Year 2 $40,000 $33,058 ($39,669) $50,000 $41,322 ($145,041)

2.5.2 [Link]
 Year 3 $30,000 $22,539 ($17,130) $75,000 $56,349 ($88,693)

Year 4 $10,000 $6,830 ($10,300) $105,000 $71,716 ($16,976)

Year 5 $10,000 $6,209 ($4,091) $75,000 $46,569 $29,593

As can be seen in Table 2.3, the payback period changed for both projects. The payback period for Project A cannot be attained in
five years, which means that our organization cannot recover the cost ($100,000) of this project’s investment even in five years. For
Project B, it would be 4.36 years (4 years + 16,976/46,569). Eventually, after taking into account the time value of the money, we
can choose Project B over Project A on the contrary of our first decision without the discount factor.
NPV (Net Present Value) is another way of showing the long-term profitability of a project. At the end of the expected lifetime of a
project outcome, NPV indicates the profit (Earnings – Project investment costs). As seen in Table 2.4, NPV is negative for Project
A while it is positive for Project B. Therefore, we can select B over A.
Table 2.4: NPVs for Projects A and B ($)

Project A Today’s Value Project B Today’s Value

Year 0 ($100,000) ($100,000) ($200,000) ($200,000)

Year 1 $30,000 $27,273 $15,000 $13,636

Year 2 $40,000 $33,058 $50,000 $41,322

Year 3 $30,000 $22,539 $75,000 $56,349

Year 4 $10,000 $6,830 $105,000 $71,716

Year 5 $10,000 $6,209 $75,000 $46,569

NPV ($4,091) $29,593

Financial models such as payback period and NPV consider solely the financial indicators. Since little may be known about the
specific solution at the time of project selection, financial evaluations are based on high-level estimates only. However,
organizations need to consider other qualitative factors such as competitive advantage, future market potential, risk, legal and
regulatory issues, and safety. Therefore, many organizations utilize project selection models where they can include criteria
prioritized for the organization in general, and the projects and their affiliated programs and portfolios. In this chapter, we will
discuss only one of the models commonly used by organizations, which is the weighted scoring model.
Non-financial reasons for selecting projects are often viewed as strategic considerations; they include everything from ending a
dependency on an unreliable vendor to restoring the image of an organization. Once a project is selected, a more detailed financial
analysis is often performed. Since decision-making models often consider numerous criteria when evaluating the change
alternatives, tools such as the weighted scoring model are very helpful. Weighted scoring models introduce objectivity in what
would otherwise be a very subjective decision-making process. A weighted scoring model allows decision-makers to structure the
decision-making process by specifying and prioritizing needs by identifying decision-making criteria; 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 to identify important factors. These criteria are often a mix of financial and non-
financial criteria. Once the criteria have been selected, we give each criterion a value, called a weight, in order to illustrate its
relative importance. The more important the criterion, the higher its weight. Each of the potential change initiatives (e.g., business
cases) is evaluated against the weighted criteria and given a score for each criterion. These models can help us introduce more
objectivity into our decision-making.

2.5.3 [Link]
Let us continue with our grocery market chain’s project candidates. Thereafter, let us increase the number of projects to four. The
project selection committee will evaluate these four potential projects based on six criteria. We have already discussed two
projects’ NPVs. The committee had scheduled a meeting today to discuss these four projects (Table 2.5). Project A targets to
increase the traditional checkout stations in all the markets if their layouts allow for an expansion inside the markets. Project B
aims to designate areas for self-checkout stations. In this project, we will need to reduce the number of traditional checkout
stations. Project C’s goal is to create new ads for television and social media (e.g.. YouTube, Facebook, Instagram). Finally, Project
D aims to create a new mobile (smartphone and tablet) application and make the current website compliant with the smartphones.
The organizational constraints (time, budget, resources, risks) allow the selection of a maximum of two projects. They are using a
weighted scoring model. There are six criteria as shown in Table 2.5. They are strategic opportunity, competitive advantage in IT,
the potential for higher market share, profitability (NPV), sustainability, and risk aversion. As can be seen here, we are not focusing
on only the profitability, but also other factors that bring about a holistic approach to evaluating the feasibility and benefits of
projects. The committee members will score each criterion. A score of 1 represents unfavorable, 2 satisfactory, and 3 favorable.
Although weights are provided out of 100 percent, in order to make the computation easier to follow, they are typed in Table 2.5 as
two-digit numbers instead of decimals. Therefore, the total weight must not exceed 100. These weights may be decided after
brainstorming meetings with subject matter experts and stakeholders. The subjectivity of these criteria’s weights and points can be
mitigated to some extent with the brainstorming activity. Most of the time, the organizations or the external client may impose the
weights according to the organizational strategy and priorities.
Table 2.5: Weighted Scoring Model

Projects

Category Weight A B C D

Strategic opportunity 25 1 3 2 3

Competitive advantage in IT 15 1 3 1 3

Potential for higher market share 20 2 2 3 3

Profitability (NPV) 10

Sustainability 10 3 2 1 1

Risk aversion 20 3 2 3 1

As you can see in Table 2.5, NPV is just one of the criteria that is used by the selection committee. The required rate of return is
0.08, and the inflation rate is 0.02. We have already computed the discount factors above. The committee should incorporate the
NPV scores based on the estimated cash flows given in Table 2.6, and the decision table in Table 2.7.
Table 2.6: Estimated cash flows ($)

Project Investment Year 1 Year 2 Year 3 Year 4 Year 5

A -100,000.00 30,000.00 40,000.00 30,000.00 10,000.00 10,000.00

B -200,000.00 40,000.00 60,000.00 75,000.00 105,000.00 100,000.00

C -30,000.00 20,000.00 15,000.00 10,000.00 3,000.00 1,000.00

C -125,000.00 25,000.00 40,000.00 50,000.00 55,000.00 65,000.00

2.5.4 [Link]
 Table 2.7: NPV score decision table

NPV SCORES

NPV < 0 1

0 ≤ NPV < 20,000 2

20,000 ≤ NPV 3

NPVs for four projects are, respectively, (1,046.07); 19,276.94; 8,284.08; and 42,182.60. Therefore, NPV scores are 1, 2, 2, and 3
respectively.
Table 2.8: Total Weighted Score (Computation of Total Scores)

Projects Weighted Scores

Category Weight A B C D A B C D

Strategic opportunity 25 1 3 2 3 25 75 50 75

Competitive advantage in IT 15 1 3 1 3 15 45 15 45

Potential for higher market share 20 2 2 3 3 40 40 60 60

Profitability (NPV) 10 1 3 2 2 10 30 20 20

Sustainability 10 3 2 1 1 30 20 10 10

Risk aversion 20 3 2 3 1 60 40 60 20

TOTAL SCORES 100 180 250 215 230

Based on the results, the selection committee should choose Project B (Self-checkout areas) since it has the highest score. Project D
(M-commerce) has the second-highest total points (230 points). Since we can select two projects and initiate them, we can move
forward for projects B and D. The project initiation will be discussed in Chapter 3. In that chapter and following chapters, we will
focus on Project D.
However, it is always possible to modify the weights to favor another project. Therefore, this reminds us of the fact that these
models are not free from subjectivity. For example, if we change the “strategic opportunity” weight from 15 to 10, the “competitive
advantage in IT” weight from 25 to 10, the “profitability (NPV)” weight from 10 to 5, the “sustainability” weight from 10 to 25,
and the “risk aversion” weight from 20 to 30, we can make Project A (Increasing the number of traditional checkout stations) the
highest score. Hence, we can select Project A (Table 2.9). As can be seen in this example, this method is subject to substantial
subjectivity.
Table 2.9: Total Weighted Score (Changed weights)

Projects Weighted Scores

Category Old New A B C D A B C D

Weight Weight

Strategic opportunity 15 10 1 3 2 3 10 30 20 30

2.5.5 [Link]
 Competitive advantage in IT 25 10 1 3 1 3 10 30 10 30

Potential for higher market share 20 20 2 2 3 3 40 40 60 60

Profitability (NPV) 10 5 1 3 2 2 5 15 10 10

Sustainability 10 25 3 2 1 1 75 50 25 25

Risk aversion 20 30 3 2 3 1 90 60 90 30

TOTAL SCORES 100 230 225 215 185

Weighted scoring models are easier to use as they offer structurally simple models. These models allow organizations to prioritize
criteria according to their strategic objectives and client expectations. Management can directly ask the committees to consider the
weights they provide so that it can be a direct reflection of managerial policy. Additionally, the weights can be modified in order to
accommodate any changes in management and program levels. One of the apparent drawbacks of these models is that they don’t
allow a linear comparison among the projects. If a project gets 100 points, and another gets 200 points, it doesn’t necessarily mean
that the second project is two times more important than the first project. Another drawback could emerge when the number of
criteria increases to a level where weights become relatively small. Thus, this model becomes like a non-weighted model at which
criteria weights don’t have an impact on the total scores.
This model is meant to add objectivity to our decision-making process; it is not meant to replace our own judgment. When the
weighted scores are close, this indicates that a slight change in the weight of a criterion and/or a change in the subjective scores
could significantly change the decision. For this reason, a weighted scoring model is often viewed as a tool that is meant to be
revised as we learn more about what truly matters to us and/or the organization.

1. [Link] ↵

This page titled 2.5: Project Selection Process is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

2.5.6 [Link]
2.6: Key Takeaways
Key Takeaways
Organizations create specific strategies that should be pursued in the long term. These long-term objectives help organizations
to gain a competitive advantage and a higher market share, or to acquire a variety of tangible and intangible benefits in line with
organizations’ field of operations (e.g., businesses, government agencies, nonprofits). Projects are utilized to accomplish these
long-term strategic objectives.
The SMART protocol is commonly utilized by organizations to clearly define achievable and relevant objectives that contain
measures and time-bound targets of how to assess whether they have been achieved. A commonly utilized guideline to create
this kind of objective is to follow the SMART protocol. The SMART acronym represents being specific, measurable,
achievable, relevant, and time-based.
A business case is a feasibility document that justifies a need for an organization. It consists of the need statement, analysis of
the current state and the desired future state, requirements, designs, and recommended solutions, and the evaluation of the
solution to understanding the potential value.
Organizations cannot put all the business cases and ideas into practice due to the constraints such as lack of time, resources, and
budget. Thus, they implement project selection models to evaluate candidate projects and select some of them which satisfy the
criteria of the models. These models are assessed in two main categories, that are financial and non-financial models. While
payback period and net present value (NPV) fall into the financial models, weighted scoring models are used as non-financial
models.

This page titled 2.6: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

2.6.1 [Link]
2.7: Questions and Exercises
There are 10 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 2.7: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

2.7.1 [Link]
2.8: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).

This page titled 2.8: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

2.8.1 [Link]
 CHAPTER OVERVIEW

3: Project Initiation
3.1: Learning Objectives and Overview
3.2: Project Charter
3.3: Project Environment
3.4: Organizational Dimensions and the Structure
3.5: Project Management Office (PMO)
3.6: Key Takeaways
3.7: Questions and Exercises
3.8: Attribution

This page titled 3: Project Initiation is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

1
3.1: Learning Objectives and Overview
Learning Objectives
1. Explain the process of developing a project charter to authorize the project, and describe the roles of the project sponsor and
project manager.
2. Describe the project environment, and outline the internal and external factors that may affect a project.
3. Explain the formal and informal organizational structure, and compare three main organizational structure types based on the
project manager’s authority level.
4. Describe the responsibilities of a Project Management Office (PMO).
All projects are undertaken for a reason. Some projects can be initiated for business reasons (i.e., strategic objectives) such as
increasing profits, decreasing customer wait time, and improving employee working conditions. Other projects exist for social
reasons such as a municipal recycling system or installing clean energy solutions. Often, the pressure to produce results encourages
people to identify possible solutions without fully understanding the needs and purposes of the project. This approach can create a
lot of immediate activity, but it also creates the likelihood that the change initiative will fail to deliver the proposed organizational
value.
As detailed in Chapter 2, one of the best ways to gain approval for a project is to clearly communicate the project’s objectives and
describe how the project provides a solution for an organizational need or how it capitalizes on a business opportunity. A needs
analysis that accompanies a business case is often conducted to better understand the underlying organizational needs and how
meeting these needs would help the organization achieve strategic objectives (e.g., increase profits, improve customer experience,
develop new products). Once alternative solutions are identified, each solution is assessed to determine if it supports the
organization’s vision and strategies. Issues of justification (“should we do the project?”) and feasibility (“can we do the project?”)
are addressed for each solution. Finally, some projects are selected to initiate. It is important to note that project justification is a
key part of the project initiation phase: a project must have a reason to exist and, if no such justification can be determined, then it’s
best to stop the project before too much time, money, and resources are invested in it. If issues of justification are not adequately
addressed, the project will lack the required organizational support and, therefore, will ultimately be unsuccessful.

This page titled 3.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

3.1.1 [Link]
3.2: Project Charter
Project justification starts when a business case is prepared which addresses the needs, and feasibility of solutions. Project
managers may be involved during this phase though it is also common not to have a project manager in this pre-project work. In
organizations having a Project Management Office (PMO) or a program department, project managers, or a team of project
managers and their assistants, could participate in developing the business case with business analysts, subject matter experts, and
representatives from relevant departments. A business case could be prepared during the initiation if it wasn’t made in the pre-
project phase.
When a project selection committee decides to go with some of the projects proposed, the sponsor, business analysis team, relevant
departments, or selection committee members can start the preparation of a project charter which will allow the formal
authorization of the existence of a project. A project charter provides the project manager with the authority to apply organizational
resources to project activities[1]. Developing a project charter requires inputs such as business documents (business case, needs
analysis, and benefits management plan), agreements, enterprise environmental factors (discussed in Project Environment below),
and organizational process assets. A project charter is necessary to initiate both internal projects at which a client is a unit in our
organization and external projects at which the client is outside our organization. If we are conducting a project with an external
client, the two parties (i.e., our organization and the external client) will also need a formal and legally binding contract to establish
an agreement.

Figure 3.1: Pre-Project Work, Project Life Cycle, and Post-Project Work. Source: PMBOK Guide 6th Edition
In the initiation stage (Figure 3.1), there are two main processes according to the PMBOK Guide 6th edition: Developing a project
charter and identifying stakeholders. The former process will be discussed in detail in Chapter 5 “People Management:
Stakeholders and Communication”. The initiation of the project is the process group to start developing the project infrastructure to
support all the activities associated with planning, executing, monitoring, and closing the project. In this stage, project managers
should give the priority to address stakeholders’ expectations and concerns in order to properly determine all the components (e.g.,
scope, schedule, budget, resources, risks, quality) of the project. Therefore, project managers conduct one or more kickoff meetings
to align all the various stakeholders. The strength of the initial alignment will have a big impact on project success. At this early
stage, project managers learn how to identify the appropriate means of communication with key stakeholders. Effective
communication with project stakeholders is another critical success factor so this work must begin early (see Chapters 5 and
6).Initiation is the first project life cycle stage to begin team building and developing collaborative approaches for working
together. During the kick-off meeting, the project manager, the team, or the sponsor should share the information below with the
main stakeholders involved:
The project’s objectives
Known priorities and success metrics
Organizational constraints and related trade-offs
A high-level description of the project scope
Key milestones

3.2.1 [Link]
 An initial list of project risks
Key stakeholders
After the initial kick-off meeting, subsequent meetings with primary stakeholders lead to more clarification and elaboration on the
information above and the development of a project charter. Just like with project justification documents, low complexity projects
may have very short project charters while higher complexity projects may require longer, more comprehensive project charters. In
either case, there are two very important aspects of the project charter: key stakeholders including a detailed description of their
roles and responsibilities, and project success metrics.
A project charter must be approved by the project sponsor. The project sponsor is the most powerful stakeholder and is usually an
executive in the organization with the authority to assign resources and enforce decisions regarding the project. They often initiate
the project and, as such, are often referred to as the “initiating sponsor.” A project sponsor has the authority to start and stop the
project and will support the completion of project objectives by removing the barriers to success. They can be regarded as the
“external champion” because they often serve as the last escalation point when the project team needs support bringing an off-track
project back on track. Successful project teams know how to leverage the power and position of the project sponsor and will
proactively ask them to deliver influencing communications throughout the organization in order to maintain the project’s
momentum and high morale within the team. Many project sponsors can assign one or more sustaining sponsors to act as the
“internal champion(s)” of the project. The sustaining sponsors are often leaders of the internal departments that are most affected
by the project, such as a marketing manager or human resources manager. When the project sponsor selects the sustaining
sponsor(s), one of their goals is to ensure that the project team frequently considers the organizational impacts of the changes being
introduced. By keeping the sustaining sponsor(s) actively engaged in the project, they will ensure their teams are intently
participating in the project and identifying the operational impacts that must be considered in order for the change to be sustained
once the project has been completed. On a day-to-day basis, the sustaining sponsor(s) act as the first point of escalation as
issues/risks are raised.
The project charter formally recognizes the existence of the project by presenting the project leader’s understanding and
conceptualization of the project’s objectives. Most importantly, it authorizes the project leader to apply organizational resources to
achieve the project’s objectives. Once the Charter is approved and formally signed off, it becomes an agreement between the
project leader and the project sponsor. As such, some organizations prefer to refer to this document as a letter of agreement instead
of a project charter. Approval of this document, whether a letter of agreement or a project charter, signals the transition into the
planning phase of the project.

The Content of a Project Charter [2]

A project charter is a necessary document to initiate a project. Organizations may have different templates for a project charter.
Below is a generic template for a project charter that would help students understand the main components and hence develop one
in their individual and team (group) assignments, and when they are involved in project teams. Our template has thirteen sections.
Case Study 3.1 below will elaborate on each section.
1. Project purpose
2. Measurable project objectives
3. High-level requirements
4. High-level project description, boundaries, and key deliverables
5. Assumptions and constraints
6. Overall project risk
7. Summary milestone schedule
8. Preapproved financial resources
9. Key stakeholder list
10. Project approval requirements
11. Project exit criteria
12. Project team
13. Name and authority of the sponsor authorizing the project charter.

Case Study 3.1: Project Charter of Grocery LLC’s Mobile-Commerce Project

In Chapter 1, we started evaluating the uniqueness and temporary nature of the two projects. The first project aimed to establish
self-checkout areas at all fifty markets across five states to solve the problem of more than usual traffic between 4 pm and 7 pm

3.2.2 [Link]
during the weekdays (Case 1.1). The second project aimed to create a new mobile application and make the current website
compliant with the smartphones (Case 1.2). In Chapter 2, we performed a weighted scoring model (Table 2.8) to compute the total
scores of project candidates based on various criteria which are not only dependent on financial factors and chose projects A (self-
checkout stations) and D (m-commerce). Project D addressed the problem of declining sales at Grocery LLC’s all fifty markets in
general with the onset of the COVID-19 pandemic. Considering the priority of the project and the pessimistic trends forecasted
regarding the pandemic as well as the increasing digitalization of companies and consumers, we will use this project in this chapter
and the following chapters.
1. Project Purpose:
To create solutions for customers who purchase goods and services from our grocery stores through their smartphones.
2. Measurable Project Objectives:
i. To redesign the website in 2 months so it’s more responsive and easier for the customers to place orders on their
smartphones.
ii. To create a new mobile application in 2 months that can work in both operating systems (Android and IOS).
In three months after the mobile website and the new mobile application go live, online sales will increase at least 25%, customer
satisfaction will increase at least 20%, and we can retain our loyal customers.
Online sales figures before the mobile solutions are introduced and three months after they go live will be compared.
Two surveys (before the mobile solutions are introduced and three months after they go live) will be conducted by a
market research company to measure the satisfaction level of customers.
The customers who have bought items from our company for the last three years will be interviewed to understand if
they still do their shopping at our grocery markets and on new mobile solutions.

3. High-Level Requirements
The mobile website and smartphone application shall:
Include all the functions that a desktop website possesses.
Be accessed with the same login username and password.
Synchronize the customer profile and the cart with the desktop website.

4. High-level project description, boundaries, and key deliverables

Needs Statements are retrieved from the business cases if available.
There has been a steady decline for the last six months in online purchases. Our company lost many customers due to the
pandemic. Customers prefer buying online instead of visiting a store in person since they have serious concerns to contract Covid-
19. Our fifty stores in five states lost around 30% of regular customers, and the revenue declined by 25% since the start of the
pandemic restrictions in March 2020. When our business analysts investigated the issue by conducting a root-cause analysis, they
found that many customers use their smartphones to buy online rather than using their desktop or laptop computers. When the
customers visited our company’s website, they could not complete their online transactions since the website has not been
optimized for mobile. Besides, we haven’t had a mobile application that our customers can use on their smartphones. E-commerce
websites such as Amazon, and brick and click stores such as Walmart and Target, and grocery chains such as Whole Foods
(through Amazon) are strong competitors from which customers can do their online shopping conveniently.
Therefore, our project has been initiated to optimize the desktop website on both Android and IOS smartphones and to create a new
smartphone application. In this project, we are not directly targeting tablets since their screen size would allow us to display the
regular desktop website. Besides, the smartphone application can be used in tablets.
5. Assumptions and Constraints
Assumptions:
i. A positive trend is expected in the long term that mobile e-commerce transactions will rise.
ii. Our current website will continue to function during the project.
iii. The owners and the top executives will continue to support this project.

3.2.3 [Link]
 Constraints:
i. Some loyal customers who prefer in-person shopping may be resistant to change so that they may not want to use
online shopping.
6. Overall project risk
Shortage of web designers and mobile app developers
Due to the COVID-19 pandemic, there is a higher demand for web designers and mobile app developers. Besides,
these qualified employees may not be available if they contract COVID-19 when they are working on our project.
During the execution of our project, customers may prefer to do their shopping on large e-commerce websites such as
Amazon as they can find more varieties with lower prices and better deals. Therefore, our deliverables may not be
utilized in the way that is desired.

7. Summary Milestone Schedule

The project starts on May 2, 2022, and finishes on July 1, 2022.
1. Kick-off: May 2, 2022
2. Finalization of requirements elicitation: May 10
3. Completion of analysis and design: May 25
4. Completion of coding and testing: June 15
5. Completion of alpha testing: June 20
6. Completion of beta testing: June 30
7. Customers can visit the mobile website and install the smartphone app: July 1, 2022

8. Preapproved Financial Resources

The initial budget for this project was determined as $200,000. Two similar projects conducted and completed by two other
companies were used. The itemized budget will be available and can be revised when the analysis and design are completed.

9. Key Stakeholder List

1. Project manager (Senior Systems Analyst)
2. Project team members (The core team)
3. Project sponsor (Chief Operations Officer – COO)
4. Product owner (The representative from the operational department who was assigned by the COO)
5. IT Department
6. Sales Department
7. Marketing Department
8. HR Department
9. Store managers and employees
10. Suppliers
11. Online customers
12. Customers who visit the stores in person
13. Government agencies that announce the pandemic restrictions

10. Project Approval Requirements

The mobile website and the smartphone app will be subject to alpha testing first. Then, beta testing will follow, where customers
can install the beta version on their smartphones and do their online shopping. During the implementation of the beta version, all
the feedback from customers and their mobile devices will be evaluated and the bugs and problems will be corrected. When the
mobile website and the app are fully functional, customers should log in with their usernames and passwords, browse items, add
them to their carts, proceed to checkout, and complete their payment.

3.2.4 [Link]
The sponsor must approve the sign-off after they receive the inspection and acceptance report.

11. Project Exit Criteria

The project will be closed successfully if both deliverables pass beta testing and all the human resources working on this
project are paid.
The project will be canceled if the financial situation of our company worsens significantly so that it is not possible to fund
the project.

12. Project Team

i. Project manager: Senior systems analyst
ii. Two systems (business) analysts
iii. Two UI/UX designers
iv. Three developers (including Android and IOS developers, and the backend developer)
v. Two testers (quality assurance engineers)
vi. Two sales and marketing experts

13. Authority of the Sponsor

The COO (Chief Operations Officer) of Grocery LLC is the sponsor. The project manager will have the full authority to identify
the necessary tasks and resources needed to complete all the project activities and deliverables. The sponsor shall authorize the
project and assign the project manager when they approve this project charter.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Charter template from [Link]↵

This page titled 3.2: Project Charter is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

3.2.5 [Link]
3.3: Project Environment
When the business case and the project charter, and later, the project management plan and its subcomponents are prepared, the
project environment surrounding the project should be examined thoroughly to delineate the factors that may have a negative or
positive impact on the project activities and its outcomes. In PMBOK Guide 6th Edition, this environment is composed of
enterprise environmental factors (EEFs) and organizational process assets (OPAs). PMBOK Guide 7th edition refers to them as the
project environment. The project environment is composed of two components – internal and external, which are described in
detail in the following sections.

3.2.1 Internal Environment

The internal environment in which a project is developed consists of the factors that are internal to the organization, but outside the
project itself. These factors include elements such as organizational culture, structure, and governance as well as security and safety
measures. Other tangible elements include geographic location as well as distribution of facilities and resources, infrastructure, IT
software and hardware, resource availability, and employee capability. The internal environment also includes organizational
process assets, which are processes, policies, and procedures as well as organizational knowledge bases (e.g., financial data,
historical information, lessons learned, project files from previous projects)[1].
Consider the project charter example above. While we are creating the business case as well as preparing the project charter and
project management plans, it would be wise to incorporate all the factors that may affect the mobile app and website optimization
project. We should enumerate the main properties of our grocery store chain, some of which are provided below:
Strategic objectives, mission, and vision
Organizational values and beliefs
Cultural norms that influence the relationships among coworkers
Code of conduct
The number of employees
Geographic locations and the size of the stores
Variety of the products and services sold
Financial situation
We should also take into account the organizational structure of the headquarters and all the branches. This also helps us identify
internal and external stakeholders who are affected by our project and who may affect our project. Additionally, this helps us
identify the dependencies among the departmental units, and also identify internal resources that might need to be utilized to
complete the project. Reporting structure inside the organization could influence our project’s decision-making and change request
processes. When our project needs to utilize hardware and software tools to facilitate the activities, we can obtain them in an
expedited way directly from the assets of our organization, which also saves the budget. When we need resources such as human
resources, materials, and equipment, since we have already delineated the organizational structure with tasks and responsibilities of
each unit, we can benefit from the agreements which have already been made with approved providers and subcontractors. Another
advantage of listing all the capabilities of our organizations would be when we establish the project team. If our organization
employs business or systems analysts, developers, user interface designers, or testers, we can ask their managers or executive-level
managers above these managers to provide these qualified employees with specialized knowledge for our project. This may also
reduce the external risks that we may face if we hire them from outside our organization. We will elaborate on the organizational
structure in the “Organizational Structure” section below.

3.2.2 External Environment

A project’s external environment consists of the factors that exist outside of the organization. It includes market conditions, social
and cultural influences and issues, legal restrictions, commercial databases, academic research, government or industry standards,
financial considerations, and physical environmental elements[2].
Figure 3.2 illustrates types of general macro environments and forces that are interrelated and affect organizations: sociocultural,
technological, economic, government and political, natural disasters, and human-induced problems that affect industries and
organizations. Macro environment refers to the outermost layer of elements in a firm’s external environment that can impact a
business but are generally beyond the firm’s direct control, such as the economy and political activity. This environment can also
affect projects conducted by organizations. For example, economic environmental forces generally include such elements in the

3.3.1 [Link]
economy as exchange rates and wages, employment statistics, and related factors such as inflation, recessions, and other shocks—
negative and positive. Additional factors include hiring and unemployment, employee benefits, factors affecting organizational
operating costs, revenues, and profits, all of which are affected by global, national, regional, and local economies. Politics and
governmental policies, international wars, natural disasters, technological inventions, and sociocultural forces could directly affect
our organization and the projects or may interact with other forces such as economic forces.

Figure 3.2: Macro Forces and Environments (Attribution: Copyright Rice University, OpenStax, under CC-BY 4.0 license)
Besides the macro environment as explained above and illustrated in Figure 3.2, the micro environment is another external
environment element that refers to the middle layer of elements in a firm’s external environment, primarily concerned with a firm’s
industry situation. Harvard strategy professor Michael Porter developed an analysis tool to evaluate a firm’s micro environment.
Porter’s Five Forces is a tool used to examine different micro-environmental groups in order to understand the impact each group
has on a firm in an industry (Figure 3.3). In this textbook, we will not explain each factor (See the reference link[3]). However,
these five factors, industry rivalry, the threat of new entrants, threat of substitutes, supplier power, and buyer power, could have a
substantial influence on a project. Therefore, we should take these external factors into account while assessing the factors that may
affect our project from outside the organization.

3.3.2 [Link]
 Figure 3.3: Porter’s Five Forces Model of Industry Competition (Attribution: Copyright Rice University, OpenStax, under CC-BY
4.0 license)
It is important to keep these external factors in mind when preparing for and managing a project since many if not most of these
external factors and any changes in these factors may have negative or positive impacts on projects. They could lead to risks that
may put the project activities and deliverables, and the overall project in jeopardy.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2021). A guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.).
Project Management Institute. ↵
3. Principles of Management. (2019). Retrieved from [Link]
environment-porters-five-forces?
query=micro%20environment&target=%7B%22type%22%3A%22search%22%2C%22index%22%3A0%7D#fs-
idm537041840↵

3.3.3 [Link]
This page titled 3.3: Project Environment is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

3.3.4 [Link]
3.4: Organizational Dimensions and the Structure
Organizations have formal and informal subsystems that affect everything from big-picture strategic planning and execution to
daily operations. Figure 3.4 shows internal organizational dimensions. Formal subsystems include leadership, strategy,
management, goals, marketing, operations, technology, and structure. Informal subsystems consist of culture, norms, relationships,
politics, and leadership skills. Understanding organizational dimensions – and how projects fit within them – gives project
managers insights into managing projects more effectively and efficiently.

Figure 3.4: Internal Organization (Attribution: Copyright Rice University, OpenStax, under CC-BY 4.0 license)

3.3.1 Formal Subsystem

An organization’s formal subsystems govern how various tasks are divided, resources are deployed, and how units/departments are
coordinated in an organization. An organizational structure includes a set of formal tasks assigned to employees and departments,
formal reporting relationship, and a design to ensure effective coordination of employees across departments/units with the help of
authority, reliability, responsibility, and accountability, which are fundamental to developing organizational structures and
workflow based on their clear understanding by all employees. In short, an organizational structure is the system of task and
reporting relationships that control and motivate colleagues to achieve organizational goals. In discussing organizational structure,
the following principles are important:
1. Authority is the ability to make decisions, issue orders, and allocate resources to achieve desired outcomes. This power is
granted to individuals (possibly by the position) so that they can make full decisions.
2. Reliability is the degree to which the project team member can be dependent to ensure the success of the project with a sound
and consistent effort.
3. Responsibility is an obligation incurred by individuals in their roles in the formal organization to effectively perform
assignments or to work on the success of the project with or without guidance or authorization.
4. Accountability refers to the extent to which an individual or project team is answerable to the project stakeholders and provides
visible evidence of action.
Authority and responsibility can be delegated to lower levels in the organization, whereas accountability usually rests with an
individual at a higher level.
An organizational structure outlines the various roles within an organization, which positions report to specific individuals or
departments, and how an organization segments its operations into a discrete department. An organizational structure is an
arrangement of positions that is most appropriate for the company at a specific point in time. Given the rapidly changing
environment in which organizations operate, a structure that works today might be outdated tomorrow. That’s why we hear so often

3.4.1 [Link]
about organizations restructuring—altering existing organizational structures to become more competitive/efficient once conditions
have changed.
Organizational structures can be categorized in terms of a spectrum of a project manager’s authority. This spectrum includes three
main types as below:
1. Functional (Centralized)
2. Matrix
3. Project-oriented / Projectized
As illustrated in Figure 3.5, the project manager’s authority is none or little in a functional organization whereas it is high to almost
total in a project-oriented organization. However, each of the organization types has advantages and disadvantages, and some
organizations can even be a mix of multiple types.

Figure 3.5: The Spectrum of Organizational Structure Types based on Project Manager’s Authority Level
A functional organization has workgroups arranged by the tasks and jobs being performed by specialized departments such as
manufacturing, marketing and sales, human resources, and finance as seen in Figure 3.6. Since there is not any project management
department or office, a project manager or a coordinator is generally selected from the department that is primarily responsible for
conducting a given project. However, this person may not have a designated project manager or coordinator role, and their service
in this role is often temporary until the project is completed. This department is generally the main beneficiary of the project or it is
the implementing department. For example, if the project’s goal is to improve customer service, a project manager can be selected
from among senior or experienced employees, who is also considered as a subject matter expert in the topic of the project, from the
“Customer Service” division under the “Marketing & Sales” department. This person may not work full time as a project manager
as they may still carry out the routine tasks of their division and department. Additionally, this project manager would be under the
supervision of the “Marketing & Sales” department manager. When they need human resources and other resources, they may not
be able to directly obtain them but should negotiate with their manager (Marketing & Sales department in our case) and other
department managers (e.g., Manufacturing, Finance). Thus, the project budget is managed by the functional manager, not the
project manager. Moreover, the project team may not have administrative staff. Therefore, the project manager may use their
department’s administrative staff on a part-time basis. The main advantage of this organization type is that the project manager can
acquire qualified and experienced human resources from other functional departments.

3.4.2 [Link]
 Figure 3.6: Functional Organization Type
When we move to the right on the spectrum (Figure 3.5), we can arrive at a weak matrix organization where functional units still
exist but the role of project manager also becomes more well-defined, and might even be its own role within the organization. In a
weak matrix, the project manager still works part-time in their department while they have more authority than they have in a
functional organization, but at a low level (Figure 3.7).

3.4.3 [Link]
 Figure 3.7: Weak Matrix Organization Type
As we continue across the spectrum, we now have a balanced matrix organization type in which we may have a designated project
manager with a higher authority. The project manager may manage the project budget to some extent, not completely, although the
functional manager has still more say.
As illustrated in Figure 3.8, in a strong matrix organization type, a Project Management Office (PMO) or a designated program
management office is added besides functional departments. This department employs full-time project managers with a designated
job role. They manage the project budget, and their authority becomes moderate to high. They can also have a full-time
administrative staff. This organizational structure may be preferred by many project managers since they can acquire qualified and
experienced team members from functional departments inside the organization while they have higher levels of authority.

3.4.4 [Link]
 Figure 3.8: Strong Matrix Organization Type
In a project-oriented or projectized organization type, tasks are arranged by projects, not functions (Figure 3.9). Project managers
work independently with a very high authority having full-time designated job roles. However, they may have some challenges
while acquiring human resources and other resources since the organization doesn’t have specialized departments where skilled and
experienced employees work.

3.4.5 [Link]
 Figure 3.9: Project-Oriented Organization Type

3.3.2 Informal Subsystem

When working with internal stakeholders (those who are inside an organization) and external stakeholders (those who are outside
an organization) on a project, it is essential to pay close attention to the hierarchy and authority relationships, relationships, context,
history, and the corporate or organizational culture. Organizational (corporate) culture refers to the beliefs, attitudes, and values that
the organization’s members share and the behaviors consistent with them (which they give rise to). Organizational 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 also have a specific culture, work norms, and social conventions (see Chapter 6).
An organization’s culture is defined by the shared values and meanings its members hold in common and that is articulated and
practiced by an organization’s leaders. Purpose, embodied in corporate culture, is embedded in and helps define organizations. Ed
Schein, one of the most influential experts on culture, also defined organizational corporate culture as “a pattern of shared tacit
assumptions learned or developed by a group as it solves its problems of external adaptation and internal integration that have
worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and
feel in relation to those problems.[1]” Some aspects of organizational culture are easily observed; others are more difficult to
discern. We 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 subtler components of organizational
culture, such as the values and overarching business philosophy, may not be readily apparent, but they are reflected in member
behaviors, symbols, and conventions used. Organizational culture can give coworkers a sense of identity through which they feel
they are an indispensable component of a larger and strong structure.
Some cultures are more conducive to project success than others. As a project leader, it is very important to understand the unique
nature of the corporate culture that we operate in. This understanding allows us to put in place the processes and systems most
likely to lead to project success.
Organizational culture is considered one of the most important internal dimensions of an organization’s effectiveness criteria. Peter
Drucker, an influential management guru, once stated, “Culture eats strategy for breakfast.”[2] He meant that corporate culture is
more influential than strategy in terms of motivating employees’ beliefs, behaviors, relationships, and ways they work since culture
is based on values. Strategy and other internal dimensions of an organization are also very important, but organizational culture
serves two crucial purposes: First, culture helps an organization adapt to and integrate with its external environment by adopting

3.4.6 [Link]
the right values to respond to external threats and opportunities. Secondly, culture creates internal unity by bringing members
together so they work more cohesively to achieve common goals. Culture is both the personality and glue that binds an
organization. It is also important to note that organizational cultures are generally framed and influenced by the top-level leader or
founder. This individual’s vision, values, and mission set the “tone at the top,” which influences both the ethics and legal
foundations, modeling how other officers and employees work and behave. A framework used to study how an organization and its
culture fit with the environment is offered in the Competing Values Framework (Figure 3.10).

Figure 3.10: The Competing Values Framework as adapted from K. Cameron and R. Quinn, 1999. Diagnosing and Changing
Organizational Culture, Addison-Wesley, p. 32.. (Attribution: Copyright Rice University, OpenStax, under CC-BY 4.0 license)
Assume that you are leading a project in an organization with a hierarchical culture. Projects are about changing the way an
organization operates. Introducing change in an organization with this type of culture can be very challenging because they value
caution, conservative approaches, and careful decision-making. If the project you are leading involves the introduction of
innovative practices and technologies, it may be very difficult and time-consuming to get the approvals required to proceed with
the project at its various stages. Innovative practices are not guaranteed to work; success requires a high degree of risk tolerance in
decision-making processes. This may be difficult to achieve in organizations with this type of culture. Furthermore, the already
aggressive schedule of employees in hierarchal organizations may not be able to accommodate the potential numerous and lengthy
deliverable reviews required for innovative projects, causing project success to be viewed as unachievable. Project leaders in this
type of culture are wise to speak openly and candidly about the project’s risks and plan for additional deliverable reviews as a way
of setting the project up for success. If this very same innovative project was being delivered in an organization with a market
culture, the decision-making approach and the schedule are likely to be fundamentally different.

1. Schein, E. (2017). Organizational culture and leadership, 5th ed., Hoboken, N.J.: John Wiley & Sons. ↵
2. Hyken, S. (2015, December 5). Drucker said culture eats strategy for breakfast. Forbes.
[Link]
proves-it/#7a7572822749↵

3.4.7 [Link]
This page titled 3.4: Organizational Dimensions and the Structure is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or
curated by Abdullah Oguz (MSL Academic Endeavors) .

3.4.8 [Link]
3.5: Project Management Office (PMO)
A project management office (PMO) is an organizational structure that standardizes the project-related governance processes and
facilitates the sharing of resources, methodologies, tools, and techniques. The responsibilities of a PMO can range from providing
project management support functions to the direct management of one or more projects.[1]
Many large and even medium-sized organizations have created a department to oversee and support projects throughout the
organization. This is an attempt to reduce the high number of failed projects. These offices are usually called PMO. 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. PMBOK Guide 6th Edition categorizes PMOs as supportive, controlling, and directive. Supportive PMOs provide a
consultative role while controlling PMOs provide support and require compliance through various means. Directive PMOs have
full-time project managers who participate in the projects and manage directly by taking full control of the projects.
In general, PMOs help ensure that projects are aligned with organizational objectives, provide templates and procedures for use by
project managers, provide training and mentorship, provide facilitation, stay abreast of the latest trends in project management, and
serve as a repository for project reports and lessons learned.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 3.5: Project Management Office (PMO) is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

3.5.1 [Link]
3.6: Key Takeaways
Key Takeaways
The official selection of a project based on the alignment of its business case with project selection criteria is followed by the
development of a project charter that authorizes the project manager to apply organizational resources in order to achieve the
project’s objectives.
A project charter consists of high-level content about a project such as a project purpose, measurable project objectives, high-
level requirements, key deliverables, constraints, assumptions, overall project risks, summary milestone schedule, preapproved
financial resources, key stakeholder list, project approval requirements, project exit criteria, project team members, and the
information regarding the sponsor. A project charter provides the project manager with the authority to apply organizational
resources to project activities. It is signed off by the project sponsor.
A project is significantly affected by the environment comprised of internal and external factors. These factors should be taken
into account while developing a business case, and while initiating, planning, executing and closing a project.
Organizational structure, as an internal environmental factor, plays a critical role in projects as they are an indispensable part of
the organization they belong to. The formal subsystem of the organizational structure consists of three main organization types,
that are functional, matrix, and project-oriented. The informal subsystem includes the organizational culture which sets one
organization apart from another with the beliefs, attitudes, and values the organization’s members share.

This page titled 3.6: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

3.6.1 [Link]
3.7: Questions and Exercises
There are 10 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 3.7: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

3.7.1 [Link]
3.8: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 3.8: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

3.8.1 [Link]
 CHAPTER OVERVIEW

4: Project Planning and the Project Scope

4.1: Learning Objectives and Overview
4.2: Project Planning
4.3: Eliciting Requirements
4.4: Requirements Traceability Matrix
4.5: Project Scope Management
4.6: Microsoft Project Tutorial
4.7: Key Takeaways
4.8: Questions and Exercises
4.9: Attribution

This page titled 4: Project Planning and the Project Scope is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

1
4.1: Learning Objectives and Overview
Learning Objectives
1. Describe the importance and purpose of project planning.
2. Identify the basic processes and activities required in the planning phase.
3. Explain the main components of requirements elicitation.
4. List the main components of a project management plan.
5. Describe the process to develop a detailed description of the project.
6. Elaborate on the WBS structure to subdivide project deliverables and project work into smaller, more manageable components.
7. Practice on Microsoft Project to create a WBS.

4.0 Overview
After the project charter is approved by the sponsor, the project manager is appointed as the primarily responsible authority to
utilize the budget and resources, define the primary components of the project such as scope, cost, schedule, quality, and risks,
manage, control and monitor project activities, and finally close the project. From now on, the project manager is ready to enter the
second phase in the project management life cycle. This is referred to as the planning phase, which directly follows the initiation
phase. The planning phase involves creating a set of plans to help guide the team through the execution and closure as well as the
monitoring and controlling which occurs throughout the whole project. The plans created during this phase help the project
manager and the team manage triple (iron triangle) constraints, which are scope, schedule and cost, and other constraints such as
quality, resources, and risks, and other related issues and knowledge areas (e.g., integration, procurement, stakeholders,
communication). They also help the project manager lead the project team and work with external suppliers to ensure that the
project deliverables can be delivered on time, within budget, and with the desired functionality.

This page titled 4.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

4.1.1 [Link]
4.2: Project Planning
Planning consists of the processes required to establish the scope of the project, refine the objectives, and define the course of
action required to attain the objectives that the project was undertaken to achieve[1]. Although most of the project effort (i.e.,
making use of the workforce and other resources) is spent during the execution phase that occurs after the planning phase, project
managers and their teams face the most challenging tasks and perform many processes during the planning phase. The project
planning phase is often the most challenging phase for a project manager, as the project manager is often required to make educated
guesses about the team members, resources required for all the activities, and the schedule and budget needed to complete the
project. In addition, the planning includes communications and procurement activities, as well as planning contracts with any third-
party suppliers.
Thorough and proper planning helps the team have a smoother execution process with a better prediction level. However, it is of
high importance to keep in mind that predictability is at low levels in many projects in terms of scope (requirements and project
activities), schedule, budget, and risks. This is why agile (adaptive) project management comes to the forefront, which started in the
1990s with software projects and extended to information systems projects over time, and other fields such as, but not limited to,
new product development, high technology projects, and start-ups. Agile project management will be discussed in Chapter 12
“Agile (Adaptive) Project Management”.
Project planning is at the heart of the project life cycle and tells everyone involved where the project is going and how the team is
going to get there. It involves creating a set of plans to help guide the team through the implementation and closure phases of the
project. The plans created during this phase help the project team manage time, cost, quality, changes, risk, and related issues. The
purpose of the project planning phase is to:
Provide guidance and direction on how scope, schedule, cost, quality, resources, communications, risks, procurements, and
stakeholders will be managed throughout the project[2],
Refine and elaborate on the SMART (Specific, Measurable, Achievable, Relevant, Time-based) objectives, establish the
business, stakeholder, solution, and transition requirements, and translate them to project activities by defining the scope and
create WBS (Work Breakdown Structure),
Develop project schedule by defining and sequencing project activities and milestones, and by estimating activity durations.
Determine resources, identify risks based on the requirements and activities, and eventually estimate costs and determine
project budget,
Identify the methods to track, review, and regulate the progress and performance of the project (e.g., EVM – Earned Value
Management),
Communicate and collaborate with all the stakeholders, and obtain the approval of the sponsor and the client, and proceed to the
next phase, which is the implementation (execution) phase.
Project managers identify the work to be done for the project in collaboration with the stakeholders including the project sponsor,
team members, relevant functional departments of our organization, end-users, customers, regulatory organizations, and
government agencies – in short, all the stakeholders that are affected by or are affecting the overall project or at least one activity,
decision or outcome. Once the major components of the project are known, the project manager can assign those in the team who
will carry out the detailed planning of the project’s sub-components. The lowest level manageable activities are called “work
packages” in predictive (waterfall) methodology. We will discuss Work Breakdown Structure (WBS) which is composed of work
packages in its section below. In agile methods and frameworks, especially in Scrum, which is the most common agile framework
utilized by organizations worldwide, “sprints”, “timeboxes”, or “cycles” are used with compressed life cycle stages (see Chapter
12).
The planning phase refines the project’s objectives in the Project Charter, which were identified at higher levels during the
initiation phase. This phase also includes planning the steps necessary to meet those objectives by further identifying the specific
activities and resources required to complete the project. Once the project objectives have been fully recognized, they must be
clearly articulated, specifically developing each of them according to the SMART protocol. These objectives would lead to the
identification and elaboration of product requirements in line with the project deliverables. Often, the very act of describing a
project’s objectives using detailed, precise language allows us to better understand the project’s scope. This articulation serves as
the basis for the development of requirements. What this means is that, after an objective has been clearly articulated, it can be
described in concrete (measurable) terms and the steps to achieve it are easier to identify. If a poor job is done of articulating the
objectives, the requirements will be misdirected, and the resulting project will not represent the true need.

4.2.1 [Link]
In general, the planning phase involves three fundamental components: Identifying the scope, preparing the schedule, and
estimating the costs. These are triple constraints that also serve as our baselines throughout the project to measure the project’s
success. After these activities are complete, it is a good time to identify and try to deal with anything that might pose a threat or an
opportunity to the successful completion of the project. This is called risk management. In risk management, the threats and
opportunities are identified along with the action that is to be taken as a response in order to optimize the likelihood of project
success (see Chapter 10). In the initiation phase, a preliminary list of project stakeholders was identified. During the planning
phase, the list is reviewed to ensure that it remains current and stakeholders continue to be prioritized. Stakeholder engagement is a
critical success factor, and communication plays a key role in this engagement. Effective project leaders spend about 90% of their
time on a project communicating with stakeholders[3]. An effective communication plan is one of the tools used to ensure
stakeholders remain informed and supportive of the project’s objectives (see Chapters 5 and 6).
In some instances, organizations need to obtain products and utilize services from outside of the organization. Overseeing these
transactions is known as procurement management. During the planning stage, procurement management involves identifying the
type of vendors required and the selection criteria to be used. Finally, project managers ensure that the team understands the quality
expectations of the stakeholders. In order to fulfill these expectations, a quality management plan is developed to identify quality
targets, assurance, and control measures, along with an acceptance plan.
Throughout all these project planning activities, it is the job of the Project Manager to integrate the team’s planning efforts—a
process known as integration management. Developing a project charter and a project management plan are two processes of seven
processes carried out within the project integration management[4]. Project managers should assure that all the necessary processes
and activities are included to identify, define, combine, unify, and coordinate the various process and project management
activities. They should manage the interdependencies among all the project management knowledge areas. Consequently, a
comprehensive project plan should be created to ensure all the various management plans identified above are cohesive and well-
aligned.
In this chapter, we will elaborate on the development of a project scope management plan including requirements management.
Other subcomponents of the project management plan will be explained in their respective chapters (e.g., project communications
management plan in Chapter 6; project schedule management plan in Chapter 8).

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
4. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 4.2: Project Planning is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

4.2.2 [Link]
4.3: Eliciting Requirements
After all the deliverables are identified, the project manager needs to document all the requirements of the project. While PMBOK
Guide 6th Edition refers to this process as “Collect Requirements”, BABOK Guide v3 refers to elicitation[1]. Elicitation is more
than just collecting. As BABOK Guide states “It is the drawing forth or receiving of information from stakeholders or other
sources. It is the main path to discovering requirements and design information, and might involve talking with stakeholders
directly, researching topics, experimenting, or simply being handed information.” BABOK Guide defines a requirement as a usable
representation of a need. The nature of the representation may be a document (or set of documents) but can vary widely depending
on the circumstances.
The requirement is defined by the PMI Guide to Business Analysis as “a condition or capability that is required to be present in a
product, service, or result to satisfy a contract or other formally imposed specification.” The responsibility for defining
requirements should be assigned to resources that have sufficient business subject matter expertise and decision-making
authority[2]. Project teams consist of business analysts who are involved in the elicitation of requirements. There may be other job
titles that perform business analysis. These titles were enumerated by BABOK Guide as business architect, business systems
analyst, data analyst, enterprise analyst, management consultant, process analyst, product manager, product owner, requirements
engineer, and systems analyst.
A project manager must assure that requirements are defined in a way that project activities can be determined and sequenced, and
hence, a schedule and budget can be created. As quoted by the Business Analysis for Practitioners: A Practice Guide, “inaccurate
requirements gathering” was reported by 37% of organizations as a primary cause of project failure. Poor requirements
management practices were identified as the second leading cause of project failure, second only to changing organizational
priorities[3]. Therefore, project managers need to ensure that all the stakeholders have been identified so that requirements can be
elicited thoroughly from all of them, and all the expectations and concerns can be addressed.
A requirement represents something that can be met by a product, service, or process, and can address a need of the business,
person, or group of people. A requirement should be independent of the design of the solution that addresses it. A requirement may
explain a feature that is to be met by a product or software component. The project’s requirements, defined in the scope
management plan, describe what a project is supposed to accomplish and how the project is supposed to be created and
implemented. Requirements may include attributes like dimensions, ease of use, color, specific ingredients, and so on.
When a specific type of requirement is under discussion, the term requirement is preceded by a qualifier such as stakeholder,
business, or solution. The hierarchical relationship among requirements can be illustrated in Figure 4.1.

4.3.1 [Link]
 Figure 4.1: Relationships between Requirements. (Adapted from “Requirements Classification Schema” in “A Guide to the
Business Analysis Body of Knowledge® – BABOK® guide”, version 3.0)
As illustrated in Figure 4.1, business requirements are developed based on the business needs (problems or opportunities) that an
organization is striving to find a solution to overcome the problem or exploit the opportunity. As discussed with examples in
Chapter 2, objectives should be SMART (Specific, Measurable, Achievable, Relevant, Time-based). Project Managers should also
consider this SMART protocol while creating requirements, especially when getting into greater detail about business
requirements. Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a
level of detail sufficient for system design. Moving down, as illustrated in Figure 4.1, means that requirements are determined in a
hierarchy starting from the business requirement at the top, and elaborating on them with stakeholder requirements, and solution
requirements[4]. Besides these three requirement types which are structured in a hierarchy, there is a fourth type called transition
requirements.
Business requirements are the needs of the internal or external client, always from a management perspective. They are the
statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an
enterprise, a business area, or a specific initiative[5]. Business requirements are statements of the business rationale for the project.
They are usually expressed in broad outcomes, satisfying the business needs, rather than 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. We can define our business requirements as below:
A mobile application shall be used by customers of our grocery stores.
Customers should access the mobile website and applications on their smartphones and tablets, and complete the purchase.
In our Project Charter example in Chapter 3, the high-level requirements were as follows. They can be considered either business
requirements or stakeholder requirements.
The mobile website and smartphone application shall:

4.3.2 [Link]
 Include all the functions that a desktop website possesses.
Be accessed with the same login username and password.
Synchronize the customer profile and the cart with the desktop website.
In order to elicit the requirements, a team should dig deep by implementing various techniques such as interviews, surveys, focus
group meetings, observations, and document analysis. In organizations, business analysts or other positions performing the tasks of
a business analyst perform these techniques to ensure that they can address the need from the perspective of stakeholders (e.g.,
customers, end-users). Stakeholder requirements serve as a bridge between business and solution requirements. In our m-commerce
project initiated by Grocery LLC, we can write some of the stakeholder requirements as below:
Business Requirement: A mobile application shall be used by customers of our grocery stores.
Stakeholder Requirements:
Customers shall log in to the application by using their usernames and passwords.
Customers shall also log in to the application through biometrics identification.
Customers shall use their usernames and passwords across all interfaces (mobile application, mobile website, and desktop
website).
Customer profile information including the name, shipping and billing addresses, and payment accounts shall synchronize
across all interfaces (mobile application, mobile website, and desktop website).
Customers shall browse the items of their choice after selecting the categories or typing on a search box.
After stakeholder requirements are developed, solution requirements can be derived from these stakeholder requirements. They
describe the capabilities and qualities of a solution that meets the stakeholder requirements[6]. Thus, they can provide an
appropriate level of detail for the development and implementation of the solution. These requirements are divided into two
subcategories as functional and non-functional requirements.
Functional requirements describe the characteristics of the final deliverable in ordinary non-technical language. They should be
understandable to the customers, and the customers should play a direct role in their development. Functional requirements are
what you want the deliverable to do. They describe the capabilities that a solution must have in terms of the behavior and
information that the solution will manage.
Stakeholder Requirement: Customers shall log in to the application by using their usernames and passwords.
Functional Solution Requirement: Customers shall receive a one-time password to their mobile phones as a text message
or to their email addresses so that they can type this one-time password on the mobile application or the mobile application
can recognize the text message and automatically transfer it to the mobile application.
Stakeholder Requirement: Customer profile information including the name, shipping and billing addresses, and payment
accounts shall synchronize across all interfaces (mobile application, mobile website, and desktop website).
Functional Solution Requirement: The profile page consists of the fields “First Name”, “Middle Name”, “Last Name”,
“Gender”, “Street Address”, “Apartment/Suite Number”, “City”, “State”, “Zip Code”, “Mobile Phone Number”, “Other
Phone Number”, “Debit/Credit Card Number”, “Debit/Credit Card Expiration Date”, and “Debit/Credit Card Security
Code”.
Functional Solution Requirement: When customers type new information or edit existing information in their profile
pages on only one of the interfaces, this information will be updated immediately on other interfaces.
Non-functional requirements or quality of service requirements do not relate directly to the behavior or functionality of the
solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have[7]. End
users cannot see directly on the mobile application how these requirements are met.
Stakeholder Requirement: Customers shall view the total price of the items they added to their cart, and shall checkout by
entering their addresses and payment information.
Non-Functional Solution Requirement: The system shall confirm the validity of the payment tool (debit or credit card),
and carry out the transaction securely by blocking any breach from outside the system.
The last requirement type is the transition requirements (Figure 4.1). These requirements describe the capabilities that the solution
must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are
not needed once the change is complete[8]. They describe temporary capabilities such as data conversion, training and business

4.3.3 [Link]
continuity requirements. They are essential for the organizational readiness to make the project outcomes and deliverables
operational. In our m-commerce project, some transition requirement examples can be outlined as below:
Functional solution requirement: Customers shall be able to chat with and have a phone call with call center agents and
customer service representatives when they need to contact due to any issues or demands related to the mobile application.
Transition requirements: Before mobile application becomes operational, it shall be ensured that:
Employees in call centers shall be trained to effectively find solutions to the customers’ requests through the mobile
application.
Call centers shall be equipped with the necessary hardware and software tools to support customers who do their shopping
on the mobile application.
Call centers shall be supported via a stable and fast network connection.
The call center database shall be hosted in a cloud server with a backup option.
The effective specification of requirements is one of the most challenging undertakings project managers face. Inadequately
specified requirements will usually lead to poor project results.
Documenting requirements is much more than just the process of writing down the requirements as the user sees them; it should
cover not only what decisions have been made, but why they have been made, as well. Understanding the reasoning that was used
to arrive at a decision is critical in avoiding repetition. For example, the fact that a particular feature has been excluded, because it
is simply not feasible, needs to be recorded. If it is not, then the project risks wasted work and repetition, when a stakeholder
requests the feature be reinstated during development or testing.
Once the project requirements are documented, the next step is for key stakeholders to sign off on the requirements to confirm that
everyone is operating with the same set of expectations. While the project manager is responsible for making certain the
requirements are documented, it does not mean that the project manager performs this task. The project manager enlists the help of
all the stakeholders (business analysts, requirement analysts, business process owners, customers, and other team members) to
conduct the discussions, brainstorming, and interviews, and to document and sign off the requirements. As with many aspects of
project management, the project manager is responsible only for enabling the process and facilitating it. If the project manager feels
that the quality of the document is questionable, their duty is to stop the development process.
The project manager reviews the requirements, incorporates them into the project documentation library, and uses them as input for
the project plan.

1. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide),
version 3.0. Toronto, Ont: International Institute of Business Analysis. ↵
2. Business Analysis for Practitioners: A Practice Guide (2015). Project Management Institute. ↵
3. Business Analysis for Practitioners: A Practice Guide (2015). Project Management Institute. ↵
4. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide),
version 3.0. Toronto, Ont: International Institute of Business Analysis. ↵
5. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide),
version 3.0. Toronto, Ont: International Institute of Business Analysis. ↵
6. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide),
version 3.0. Toronto, Ont: International Institute of Business Analysis. ↵
7. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide),
version 3.0. Toronto, Ont: International Institute of Business Analysis. ↵
8. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide),
version 3.0. Toronto, Ont: International Institute of Business Analysis. ↵

This page titled 4.3: Eliciting Requirements is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

4.3.4 [Link]
4.4: Requirements Traceability Matrix
The project team should link the requirements to the activities and deliverables that satisfy them during the project. Requirements
traceability matrix is a common structure that is used by project teams. It also shows each requirement’s relationship to other
requirements. Traceability is used to help ensure that the solution conforms to requirements and to assist in scope, change, risk,
time, cost, and communication management[1]. A formal traceability matrix is usually built hierarchically, starting with high-level
requirements and filling in the details as the requirement is progressively elaborated. This hierarchy is similar to an outline that is
filled in as more detail is known[2].
This matrix can include the information regarding:
Requirement ID
A unique identifier
Associate ID
A unique identifier for requirements associated with higher-level requirements
Requirement category
Requirement description
A textual description of the requirement
Current status
E.g., active, canceled, deferred, added, approved, assigned, completed.
Status date
Business needs, goals, and objectives
To address the rationale of inclusion
Project objectives
To address the rationale of inclusion
WBS number
The relationship of the requirement with project activities and milestones
Design ID
The relationship of the requirement with the design elements
Build ID
The relationship of the requirement with an implementation of a specific feature
Test strategy and test scenarios (e.g., technical/system case tests, user/acceptance case tests)
Test cases that will validate that the built features perform as required by the requirements.
Let’s create a small version of the requirements traceability matrix for Grocery LLC’s m-commerce project.
ID (1): Customers shall log in to the application by using their usernames and passwords.
ID (2): Customer profile information including the name, shipping and billing addresses, and payment accounts shall
synchronize across all interfaces (mobile application, mobile website, and desktop website).
Table 4.1: Requirements Traceability Matrix

ID Associate Requirements Description Current WBS Design Build Test

ID Status ID ID case

1 1.1 Customers shall receive a one-time Active 2.2 D3 B3 Case 2

password to their mobile phones. 3.2 D6 B8

1.2 Customers shall be able to prefer signing in Active 2.2 D3 B3 Case 3

to the mobile application by swiping their 3.2 D6
fingerprints on their smartphones.

2 2.1 The profile page consists of the fields “First Active 2.2 D2 B2 Case 6

4.4.1 [Link]
 Name”, “Middle Name”, “Last Name”, 4.4
“Gender”, “Street Address”, 5.2
“Apartment/Suite Number”, “City”, “State”,
“Zip Code”, “Mobile Phone Number”,
“Other Phone Number”, “Debit/Credit Card
Number”, “Debit/Credit Card Expiration
Date”, and “Debit/Credit Card Security
Code”.

2.2 When customers type new information or Active 2.2 D2 B2 Case 7

edit existing information in their profile 4.4 D9
pages on only one of the interfaces, this 5.2
information will be updated immediately on
other interfaces.

1. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide),
version 3.0. Toronto, Ont: International Institute of Business Analysis. ↵
2. Business Analysis for Practitioners: A Practice Guide (2015). Project Management Institute. ↵

This page titled 4.4: Requirements Traceability Matrix is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

4.4.2 [Link]
4.5: Project Scope Management
Before starting the implementation of any project activities, the project team needs to know exactly what work has to be done.
Therefore, the team needs to plan first to provide guidance and direction on how the scope will be managed throughout the
project[1]. In this very beginning process, the project team creates a scope management plan that documents how the project and
product scope will be defined, validated, and controlled. Project managers should coordinate the responsibilities of each team
member. In order to do so, they should know exactly what they’re going to do to meet the project’s objectives. Therefore, the scope
planning process is the very first thing to be done. Project scope planning is concerned with the definition of all the work needed to
successfully meet the project objectives. Project managers and teams should have a clear picture of all the work that needs to
happen on their projects, and as the project progresses, they should ensure that the scope is up to date.

4.4.1 Defining the Scope

We already have a head start on refining the project’s objectives in quantifiable terms, but now we need to plan further and write
down all the intermediate and final deliverables that we will produce over the course of the project. Deliverables include everything
that we produce for the project (i.e., anything that the project will deliver). The deliverables for the project include all of the
products or services that we are performing for the internal or external clients, and/or the end-users and customers. They include
every intermediate document, plan, schedule, budget, blueprint, and anything else that will be made along the way, including all of
the project management documents that are put together. Project deliverables are tangible outcomes, measurable results, or specific
items that must be produced to consider either the project or the project phase completed. Intermediate deliverables, like the
objectives, must be specific and verifiable.
All deliverables must be described in a sufficient level of detail so that they can be differentiated 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
A departmental solution versus an enterprise solution
In our case of m-commerce project carried out by Grocery LLC, there are two main deliverables which are:
1. A mobile application that can be installed on Android and IOS smartphones.
2. A mobile website optimized for Android and IOS smartphones.
We should also define what is not included in the project’s scope. M-commerce project doesn’t directly target tablets since their
screen size would allow them to display the regular desktop website. Besides, the smartphone application can be used in tablets.
Besides, smartphones with operating systems other than Android and IOS are excluded.
One of the project manager’s primary functions is to accurately document the deliverables of the project and then manage the
project so that they are produced according to the agreed-on criteria. Deliverables are the output of each development phase,
described in a quantifiable way to assure measurability. In our case study, project objectives have been provided to ensure
measurability:
1. To redesign the website in 2 months so it’s more responsive and easier for the customers to place orders on their smartphones.
2. To create a new mobile application in 2 months that can work in both operating systems (Android and IOS).
The process of defining scope generates a “Project Scope Statement”[2]. It is the description of the project scope, major
deliverables, assumptions, and constraints. The project charter contains high-level information while the project scope statement
contains a detailed description of the scope components. The project scope statement documents the entire scope, including project
and product scope. Project Scope Statement is composed of the components as outlined below[3]. Readers should always keep in
mind that they should create a long and detailed statement when they work as a project manager or a team member on a project in
their organizations.
1. Product scope description
The mobile application and the mobile website will have the same functions that allow online customers to conveniently do their
shopping by browsing, searching, and locating the items they want to purchase, adding them to the cart, specifying the number and
weight of the items, choosing the delivery and shipping options, checking out via their payment option, and tracking the items they

4.5.1 [Link]
ordered. The mobile application will work on smartphones having Android and IOS. Customers will use the same username and
password they use to access the desktop version. If they leave the application or the website, the items in their cart will not be
removed and synchronized with all the interfaces (mobile application, mobile website, and desktop website). If an item’s price
changes or this item is sold out, they will be notified of this when they access their carts.
2. Deliverables
A mobile application
Optimized mobile website
3. Acceptance criteria
The mobile website and the smartphone app will be subject to alpha testing first. Then, beta testing will follow, where customers
can install the beta version on their smartphones and do their online shopping. During the implementation of the beta version, all
the feedback from customers and their mobile devices will be evaluated and the bugs and problems will be corrected. When the
mobile website and the app are fully functional, customers should log in with their usernames and passwords, browse items, add
them to their carts, proceed to checkout, and complete their payment.
The sponsor must approve the sign-off after they receive the inspection and acceptance report.
4. Project exclusions
This project doesn’t directly target tablets since their screen size would allow them to display the regular desktop website.
Besides, the smartphone application can be used in tablets.
Smartphones with operating systems other than Android and IOS are excluded.

4.4.2 Work Breakdown Structure (WBS)

After defining deliverables and requirements, and creating a Project Scope Statement, the next step would be to create a Work
Breakdown Structure (WBS) that defines all the activities required to complete the project. The WBS defines the scope of the
project and breaks the work down into components that can be scheduled, estimated, and easily monitored and controlled. The idea
behind the WBS is simple: dividing a complicated task into smaller tasks until we reach a level that cannot be further subdivided.
We stop breaking down the work when we reach a low enough level to perform an estimate of the desired accuracy. At that point, it
is usually easier to estimate how long the small task will take and how much it will cost to perform than it would have been to
estimate these factors at the higher levels. Each descending level of the WBS represents an increased level of detailed definition of
the project work. A WBS also provides the necessary framework for detailed cost estimating and control, along with providing
guidance for schedule development and control.
The purpose of developing a WBS is to allow easier management of each component, accurate estimation of time, cost, and
resource requirements, easier assignment of human resources, and easier assignment of responsibility for activities.
WBS is a hierarchical decomposition of the project into phases, deliverables, and work packages. It is a tree structure, which shows
a subdivision of effort required to achieve an objective. In a project, the WBS is developed by starting with the end objective and
successively subdividing it into manageable components in terms of size, duration, and responsibility, which includes all steps
necessary to achieve the objective. An example of this hierarchical decomposition can be starting from the highest level which is
the project and moving downwards along the systems, subsystems, components, tasks, and subtasks, and stopping when we arrive
at the lowest level which is work packages.
The WBS creation involves:
Listing all the project outputs (deliverables and other direct results)
Identifying all the activities required to deliver the outputs
Subdividing these activities into subactivities and tasks
Identifying the deliverable and milestone(s) of each task
Considering the usage of all the resources (personnel and material) required to complete each task
WBS formatting can be made through various approaches such as the top-down approach, the use of organization-specific
guidelines, and the use of WBS templates[4]. The WBS can be developed in different ways to represent the second level after the
highest level, the project. The second level can represent the phases of the project life cycle or major deliverables. Below illustrates
a WBS with major deliverables at the second level.

4.5.2 [Link]
0 Project Name
1 Major Deliverable
1.1 Sub Deliverable
1.2 Sub Deliverable
1.3 Sub Deliverable
2 Major Deliverable
2.1 Sub Deliverable
2.1.1 Work Package
2.1.2 Work Package
2.1.3 Work Package
2.1.4 Work Package
2.2 Sub Deliverable
2.3 Sub Deliverable
3 Major Deliverable
3.1 Sub Deliverable
3.1.1 Work Package
3.1.2 Work Package
3.1.3 Work Package
3.2 Sub Deliverable
3.2.1 Work Package
3.2.2 Work Package
3.3 Sub Deliverable

4.4.3 Case Study 4.1: WBS of Grocery LLC’s M-Commerce Project

Based on the Project Charter we developed in Chapter 3 as well as the requirements and the scope detailed in this chapter for
Grocery LLC’s M-Commerce Project, we can create a WBS for the mobile application as below[5]. Optimization of the mobile
website is not included in this WBS. Different from the generic WBS above which has been developed based on the major
deliverables and sub deliverables, the WBS below displays the phases of the project in the second level (e.g., scope,
analysis/application requirements, deployment). This WBS has three levels including the highest level which is the project itself. In
Chapter 7 “Scheduling”, we will have an exercise regarding the fourth level for “1.3 Preparation of Project Charter” in the
“Defining Activities” section. Although some WBS components such as “1.6 Initiation stage complete” and “2.7 Analysis
Complete” are on the Activities column, they are milestones with zero duration which show
Table 4.2: WBS for the Mobile App Development Project

WBS Activities

0 Mobile App Development

1 Scope

1.1 Clarify project purpose and determine project scope

1.2 Secure project sponsorship

4.5.3 [Link]
1.3 Preparation of project charter

1.4 Approval of project charter by the sponsor

1.5 Secure core resources

1.6 Initiation stage complete

2 Analysis/App Requirements

2.1 Conduct needs analysis

2.2 Draft preliminary stakeholder specifications

2.3 Review specifications with team and stakeholders

2.4 Incorporate feedback on the specifications

2.5 Develop preliminary budget and delivery timeline

2.6 Obtain approvals to proceed (concept, timeline, budget, resources)

2.7 Analysis complete

3 Design

3.1 Review preliminary stakeholder specifications

3.2 Develop solution (functional and non-functional) specifications

3.3 Develop transition requirements

3.4 Develop design mockups based on specifications

3.5 Review specifications

3.6 Incorporate feedback into specifications

3.7 Obtain approval to proceed

3.8 Design complete

4 Development

4.1 Review solution and transition specifications

4.2 Assign development staff

4.3 Develop on SDKs (Software Development Kits)

4.4 Developer testing (primary debugging)

4.5.4 [Link]
4.5 Development complete

5 Testing

5.1 Develop a test plan based on specifications and SDK

5.2 Conduct automated test plans

5.3 Conduct performance and stress tests

5.4 Conduct regression testing

5.5 Conduct localization testing

6 Training

6.1 Develop training specifications for end users

6.2 Develop training specifications for helpdesk support staff

6.3 Develop training materials

6.4 Finalize training materials

6.5 Training materials complete

7 Documentation

7.1 Develop Help specification

7.2 Develop Help system

7.3 Review Help documentation

7.4 Incorporate Help documentation feedback

7.5 Develop user manuals specifications

7.6 Develop user manuals

7.7 Review all user documentation

7.8 Incorporate user documentation feedback

7.9 Documentation complete

8 Pilot

8.1 Identify test group

4.5.5 [Link]
 8.2 Develop software delivery mechanism

8.3 Install/deploy software

8.4 Obtain user feedback

8.5 Evaluate testing information

8.6 Pilot complete

9 Deployment

9.1 Determine final deployment strategy

9.2 Develop deployment methodology

9.3 Get approval from Android and Apple stores

9.4 Train support staff

9.5 Deploy software

9.6 Deployment complete

10 Post Implementation Review

10.1 Document lessons learned

10.2 Archive all documents

10.3 Complete all pending payments

10.4 Create software maintenance team

10.5 Final meeting with stakeholders to close the project

10.6 Disband the team

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
4. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
5. Adopted from Microsoft Project Professional 2019 Software Development Plan Template ↵

4.5.6 [Link]
This page titled 4.5: Project Scope Management is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

4.5.7 [Link]
4.6: Microsoft Project Tutorial
Microsoft Project is one of the most common software tools used in project management across the world. In this textbook, we use
Project Professional 2019. Recently, Project Professional 2021 has been introduced. As the main functions remain the same in these
versions, we will continue using the 2019 version. If new versions necessitate an update, the online version of this book will be
updated. In this book, all our examples and screenshots are based on the 2019 version. At many universities in the USA, students
may be allowed to access the Microsoft Azure website ([Link] with their school credentials (username and
password). Therefore, they can download Microsoft software programs on the “Education” webpage (Figure 4.2), such as Project
Professional 2021 or 2019, Access 2016, 2019 or 2021, Visio Professional 2016, 2019 or 2021, and Visual Studio, as well as
Windows 10 or 11.

Figure 4.2: Microsoft Azure Portal – Education webpage

If you have a MacBook, you cannot download MS Project directly. The only way to run MS Project on your MacBook would be to
dual-boot Windows and macOS on your MacBook. You can visit [Link] for more information.
Nevertheless, many school labs and libraries provide computers in which MS Project 2019 or earlier versions are installed.
When you open MS Project for the first time, you can open a “Blank Project” or you can select a template (Figure 4.3).

Figure 4.3: MS Project “New” Window

When you select “Blank Project”, the project page will open with a ribbon that includes tabs (in the same format we have on
Microsoft Office programs such as Word, Excel, and PowerPoint) (Figure 4.4). While the default view is “Gantt with Timeline”,

4.6.1 [Link]
we changed it from “Options” to “Gantt Chart” view. Therefore, Figure 4.4 doesn’t display the timeline. In Figure 4.5, under
Project View, default view is set as Gantt with Timeline.

Figure 4.4: Blank Project (Gantt Chart with Timeline)

Figure 4.5: Project Options – General tab

In this chapter’s tutorial and the following chapters, we will use “Gantt with Timeline” as our default view. Besides, we are not
changing the schedule options. It means that we are not working at the weekends, and our durations are automatically labeled as
“days”. However, we can type another unit such as a week (wk or wks) or month (mon or mons) (Figure 4.6).

4.6.2 [Link]
 Figure 4.6: Project Options – Schedule tab
Under the “Format” tab, we should check “Project Summary Task” first. Therefore, our project’s total duration can be
automatically calculated by MS Project. The row number becomes zero for the project summary task. If we insert a column titled
“WBS”, the system also gives zero to this task. MS Project doesn’t use the name “Activity”, but “Task”.

Figure 4.7: Project Summary Task

For this MS Project tutorial, we will use letters and numbers for the activities. A is the project, and it is the highest level which is 1.
The lowest level in our WBS is the third level.
Table 4.3: Activities

WBS Level Activity

1 A

2 a1

2 a2

3 a21

3 a22

1 B

2 b1

3 b11

4.6.3 [Link]
 3 b12

1 b2

After we type all the activities, we can select a1 and a2, and indent them as both are under A (Figure 4.8). WBS numbers are given
automatically by MS Project when we indent and outdent. After we indent a1 and a2, these two activities can be subtasks of A
which could be considered as a phase or major deliverable.

Figure 4.8: Indenting tasks “a1” and “a2”

For a21 and a22 at the third level, we should click the “Indent Task” icon twice as they are under a2 which is at the second level.
Figure 4.9 displays the WBS numbers after all the activities have been indented.

Figure 4.9: Indenting all the tasks at second and third WBS levels
As can be seen in Figure 4.9, WBS numbers changed automatically when we indented the tasks. This tutorial served as an
introduction to Microsoft Project and only discussed how a WBS can be created. Therefore, we have not typed the durations and
predecessors. We will cover them in Chapter 7 “Scheduling”.

4.6.4 [Link]
This page titled 4.6: Microsoft Project Tutorial is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

4.6.5 [Link]
4.7: Key Takeaways
Key Takeaways
The project planning phase is often the most challenging phase for a project manager, as the project manager is often required to
make educated guesses about the team members, resources required for all the activities, and the schedule and budget needed to
complete the project.
Thorough and proper planning helps project managers and teams have a smoother execution process with a better prediction
level and a higher probability of project success. Developing a project management plan involves creating a set of plans to help
guide the team through the implementation and closure phases of the project.
Project managers identify the work to be done for the project in collaboration with the stakeholders including the project
sponsor, team members, relevant functional departments of our organization, end-users, customers, regulatory organizations,
and government agencies.
A project manager must assure that requirements are defined in a way that project activities can be determined and sequenced,
and hence, a schedule and budget can be created.
A requirement represents something that can be met by a product, service, or process, and can address a need of the business,
person, or group of people. Business requirements are developed based on the business needs (problems or opportunities) that
an organization is striving to find a solution to overcome the problem or exploit the opportunity.
Requirements can be categorized as business, stakeholder, solution, and transition requirements.
In order to elicit the requirements, a team should dig deep by implementing various techniques such as interviews, surveys,
focus group meetings, observations, and document analysis.
Requirements traceability matrix is used to link the requirements to the activities and deliverables that satisfy them during the
project.
Planning starts with developing a scope management plan that documents how the project and product scope will be defined,
validated, and controlled.
The project scope statement describes the project scope, major deliverables, assumptions, constraints, acceptance criteria, and
project exclusions (what the scope doesn’t include).
The WBS (Work Breakdown Structure) breaks the project scope down into components that can be scheduled, estimated, and
easily monitored and controlled. The lowest level of a WBS is called a work package.

This page titled 4.7: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

4.7.1 [Link]
4.8: Questions and Exercises
There are 8 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 4.8: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

4.8.1 [Link]
4.9: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 4.9: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

4.9.1 [Link]
 CHAPTER OVERVIEW

5: Stakeholder Management
5.1: Learning Objectives and Overview
5.2: Identifying Stakeholders and Managing Their Expectations
5.3: Stakeholder Analysis
5.4: Managing and Monitoring Stakeholder Engagement
5.5: Key Takeaways
5.6: Questions and Exercises
5.7: Attribution

This page titled 5: Stakeholder Management is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

1
5.1: Learning Objectives and Overview
Learning Objectives
1. Describe the process to identify stakeholders in a project and create a stakeholder register.
2. Explain the management of stakeholders to meet their needs and expectations, address issues, and foster appropriate stakeholder
engagement involvement.
3. List the conditions when project managers need to update the stakeholder engagement plan.

5.0 Overview
A project is successful when it achieves its objectives and meets or exceeds the expectations of the stakeholders who are
individuals, groups, teams, businesses, corporations, communities, government organizations, or non-governmental organizations
who either care about or have a vested interest in a project. They may affect the whole project, its outcomes, some activities, or
even only a decision, an activity, or an outcome of the project negatively or positively. Stakeholders may be actively involved with
project activities or have something to either gain or lose as a result of the project. Project managers and their teams spent most of
their time communicating and collaborating with the stakeholders. Indeed, project managers, themselves, spent 90% of their time
communicating[1]. This chapter discusses stakeholder management and how project managers should pay attention to while they
communicate with the stakeholders including their key stakeholders such as project team members, sponsors, internal or external
clients, customers, end-users, and regulatory and government agencies.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 5.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

5.1.1 [Link]
5.2: Identifying Stakeholders and Managing Their Expectations
A project starts with two processes – developing the project charter and identifying stakeholders[1]. Triple constraints (scope,
schedule, cost) and stakeholders constitute the main pillars of a project. If stakeholders are not identified properly, the project and
its outcomes cannot address all the stakeholders’ expectations and concerns. Incomplete elicitation of the requirements from
stakeholders might leave some key requirements out of the equation, putting the project and its outcomes in danger.
Stakeholders are those who have a positive or negative influence on the project, or who are or might be positively or negatively
affected by the project, or its activities, decisions, and outcomes. Stakeholders can be anyone including, but not limited to,
individuals, groups, teams, businesses, corporations, communities, government agencies, not-for-profit organizations, international
bodies, and non-governmental organizations. They may affect the whole project, or only one or some of the decisions or activities,
or the outcomes of the project negatively or positively. Stakeholders may be involved actively or passively in the project, or its
activities and decisions. When you manage a project to add lanes to a highway, motorists are stakeholders who are positively
affected by the outcome of this project whereas they may be affected negatively during the construction due to the closed roads and
detours. However, your project may negatively affect residents who live near the highway during your project (with construction
noise) and after your project with far-reaching implications (increased traffic noise and pollution). Stakeholders can be inside the
implementing or client organization (e.g., subcontractors who undertake the construction work of additional lanes) or outside it
(e.g., motorists, residents).
Internal stakeholders which are inside the organization, but not limited to, are:
Project sponsor
Project manager
Project team members
PMO (Project Management Office)
Program manager
Project/Portfolio steering committee
Board of trustees
Company owners/founders
Top management (e.g., C-level executives)
Project managers of other projects in the organization
Functional departments/units in the organization, their managers, and all employees (e.g., research & development, finance,
accounting, human resources, sales, marketing, manufacturing)
End users in functional departments, regional offices, and international offices of the organization
Regional offices/branches of the organization
International offices/branches of the organization
External stakeholders which are outside the organization, but not limited to, are:
Customers
End users outside the organization
Suppliers
Contractors and subcontractors
Shareholders
Regulatory bodies
Government agencies (e.g., federal, state, local, county)
Current and potential competitors
Often there is more than one major stakeholder in the project. An increase in the number of stakeholders adds stress to the project
and influences the project’s complexity level. The business or emotional investment of the stakeholder in the project and the ability
of the stakeholder to influence the project outcomes or execution approach also impact the stakeholder complexity of the project. In
addition to the number of stakeholders and their level of investment, the degree to which the project stakeholders agree or disagree
also influences the project’s complexity and outcomes.
While identifying stakeholders, in the initiation stage of a project, a project charter generally consists of key stakeholders whose
power or interest levels are at a high level. Key stakeholders can make or break the success of a project. Even if all the deliverables

5.2.1 [Link]
are met and the objectives are satisfied, if your key stakeholders aren’t happy, nobody’s happy. This is why all the key stakeholders
must be identified before proceeding with the preparation of the project management plan. However, identifying the stakeholders
doesn’t finish in the initiation stage, but is an ongoing process through which project managers should review and analyze their
interests, involvement, interdependencies, influences, and potential impact on project success regularly during the project life
cycle[2]. Data representation techniques such as stakeholder power/interest grid/matrix help a lot to review where stakeholders are
positioned based on the criteria used and be prepared and implement strategies to manage stakeholders. In the following subsection,
we will discuss one of the common data representation techniques, power/interest grid (matrix) based on a scenario.
There are many project decelerators, one of which is the lack of stakeholder support. Whether the stakeholders support our project
or not, if they are important to the project, we must secure their support. How do you we that? First, we must identify who our
stakeholders are. Just because they are important in the organization does not necessarily mean they are important to our project.
Just because they think they are important does not mean they are. Just because they don’t think they need to be involved does not
mean they do not have to be. The typical suspects that we should consider would be our top managers, relevant departments’
managers, supervisors or key employees, and the project sponsor (champion), our internal or external client, subject matter experts
(SMEs) we need to consult, and the selection or steering committee reviewing and approving our project. In some situations, some
think they are stakeholders in our project. Even though they aren’t, as they perceive that they are affected by the project and its
activities and decisions, we should consider them as stakeholders. From our perspective, they may not be, but we should be careful
while handling them. They could be influential with those who have the power to impact our project. We shouldn’t dismiss them
out of hand.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 5.2: Identifying Stakeholders and Managing Their Expectations is shared under a CC BY-NC 4.0 license and was authored,
remixed, and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

5.2.2 [Link]
5.3: Stakeholder Analysis
After the initial assessment has been completed, stakeholder prioritization can occur. A power/interest grid would be a very helpful tool for prioritization
(Figure 5.1). It helps project managers categorize stakeholders and create effective communication strategies for each category of stakeholder on the project.
This tool is one of the most common techniques utilized to group stakeholders according to their level of authority (power) and their level of concern about
the project’s activities and outcomes (interest)[1]. Besides the power/interest grid, other techniques can be used such as power/influence grid, impact/influence
grid, stakeholder cube, and salience model. In this book, we will not cover these techniques.

Figure 5.1. Stakeholder Matrix: Power/Interest Grid and the Strategies to Deal with the Stakeholders
The stakeholder power/interest grid is a two-dimensional matrix with four quadrants. Power refers to the authority of stakeholders through which they can
affect the course of activities and decisions and may block or facilitate and accelerate them. Interest refers to stakeholders’ level of concern about the project’s
activities and outcomes, and how they are affected by them, either negative or positive. While carrying out the activities to identify stakeholders, we should
make our research and investigation thoroughly to determine and prioritize the stakeholders. Some stakeholders would have more power and interest in our
project. Therefore, we should identify them, and create a strategy to engage them during the project. These strategies have been indicated in Figure 5.1 for
each quadrant based on the level of power and interest.
Properties of each quadrant with the potential stakeholder inside them have been described below:
1. High power – High interest: These stakeholders are decision-makers and have the biggest impact on the project’s success and hence we must closely
manage their expectations[2]. We should work closely with them to ensure that they agree with and support the change[3]. The project sponsor, project
manager, and the team can be included in this quadrant.
2. High power – Low Interest: These stakeholders need to be kept satisfied even though they aren’t interested because they yield power. This type of
stakeholders should be dealt with cautiously as well since they may use their power in a not desired way in the project if they become unsatisfied.
Government and regulatory agencies which inspect the quality of your work in compliance with legal provisions and standards can be included in this
quadrant.
3. Low power – High interest: We should keep these stakeholders adequately informed and talk to them to ensure that no major issues are arising. They are
likely to be very concerned and may feel anxious about a lack of control. They can often be very helpful with the detail of your project. Our customers or
end-users who are willing to purchase the outcome of the project (e.g., a product or a service) can be included in this quadrant.
4. Low power – Low interest: We should monitor these stakeholders, but do not bore them with excessive communication. The public and the customers who
are not willing to purchase our products can be included in this quadrant. We can send them newsletters once every month, but not every week. We should
monitor their interest and power level in case they may change.
When considering a stakeholder’s interest, we should assess the following:
How is their performance evaluated?
Will their performance be impacted by the project and/or the project’s outcomes?
Are they needed to help produce the project’s outcomes?
When considering a stakeholder’s power, we should assess the following:
What position do they currently hold in our organization or their organizations?
How much authority does this position afford them over the project?
Can they influence people in positions of high power?
Tools such as stakeholder power/interest grid help project managers prioritize stakeholders. Some stakeholders have little interest and little power in a project
and as a result, do not require as much contact from the project team. Understanding who these stakeholders are allows the project team to spend more time
with the stakeholders that have a significant interest in the project and who exert significant influence over the project. Project teams assess the interest and

5.3.1 [Link]
power of project stakeholders by researching their current positions and their actions in previous change initiatives, and by directly speaking with them about
the project.
Below, let’s consider a fictitious case study of a vehicle rental company to elaborate on the stakeholder power/interest grid.

5.2.1 Case Study 5.1: A Vehicle Rental Company’s Project for their Booking System
Our car rental company, Best Rental Company Worldwide (BRCW), has a serious problem. Our booking system crashes frequently. The employees working
in the relevant departments, branches, and the call center cannot process the information properly. Besides, there are significant errors in scheduling and
pricing while individual and corporate customers are renting vehicles on the company’s website, and when they reach the call center to book a vehicle. The
company’s IT director, who is CTO (Chief Technology Officer), asked us to initiate a project that would address the problems, and solve them. First, we
should create a business case that should investigate the problem thoroughly. We should figure out the underlying reasons. In order to dig into the reasons, we
should first identify the stakeholders to whom we should consult to learn what they experience with the current system, and what their concerns and
expectations are. Our team targets to develop a new booking module in the ERP system, a website, and a mobile application our customers will access and
use to book vehicles. We identified the stakeholders as follows:
1. Project manager
2. Project team members
3. Project sponsor: IT Director – Chief Technology Officer (CTO)
4. Steering Committee (composed of car rental company managers)
5. IT Department
6. HR Department
7. Sales Department
8. Marketing Department
9. Maintenance / Repair Department
10. Call Center and its managers and employees
11. Branches across the USA (and their managers and employees)
12. Branches outside the USA
13. Individual Customers
14. Organizational Customers (Corporates that rent vehicles based on a contract with BRCW)
15. Insurance companies
16. Travel agencies (including e-commerce agencies such as Expedia)
17. Vehicle manufacturers
18. Suppliers of vehicle spare parts and consumables for offices at the central units and branches
19. Government agencies (e.g., Department of Transportation, US Environmental Protection Agency)
20. Google Play store (for Android phones and tablets) and App Store (for Apple phones and tablets)
21. Not-for-profit organizations (e.g., associations that were established to reduce carbon emissions)
Project sponsor, project manager, project team members, steering committee, IT, sales, marketing and maintenance/repair departments, call center, and
branches all across the USA are our internal stakeholders that are inside our company, BRCW. Although it may look counterintuitive to include the manager
and team members, they are also stakeholders. Indeed, they are the most important stakeholders who have a strong impact on project activities, milestones,
decisions, deliverables, outcomes, and the overall project.

5.3.2 [Link]
 Figure 5.2. Stakeholder Power/Interest Grid for Rental Car Company’s Project

[Link] Project Sponsor

The project sponsor is typically the most powerful stakeholder. In our case, CTO is the sponsor. Sponsors have high power and high interest. They are the
decision-makers and act as a supervisor and controller of the project. Sponsors often initiate the project by signing off and approving the project charter and
authorizing the project manager to form and lead the team, start planning, define the scope, activities, schedule, and risks, and allocate and utilize the budget
and resources. A sponsor is the authority superior to the project manager inside the organization and acts as a supervisor and facilitator during the project. A
sponsor releases the budget for the team to use for the project activities. If the project client is one of the units of the organization, that is an internal client, the
project sponsor also becomes the funder. If the client is outside the organization, this external client becomes the funder while the sponsor should be still
inside the organization that is implementing the project. A legal contract is created between the organization (where the project sponsor, project manager, and
team are), and the external client (funder). While the contract is a legally binding agreement, we still need a project charter that should be signed by the
sponsor who is in our organization where the team resides. The charter should be based on the contract, and it regulates the requirements and resource
allocations on the organization’s side. As discussed in Chapter 3 regarding the project charter, the project sponsor can be referred to as the “initiating
sponsor.” They have the authority to start and stop the project and will support the achievement of project objectives by removing the barriers to success.
They can be regarded as the “external champion” because they often serve as the last escalation point when the project team needs support bringing an off-
track project back on track. Successful project teams know how to leverage the power and position of the project sponsor and will proactively ask them to
deliver influencing communications throughout the organization in order to maintain the project’s momentum and high morale within the team. Project
sponsors can assign one or more sustaining sponsors to act as the “internal champion(s)” of the project. These sponsors are often leaders of the internal
departments that are most affected by the project, such as a marketing manager or human resources manager. When the project sponsor selects the sustaining
sponsor(s), one of their goals is to ensure that the project team frequently considers the organizational impacts of the changes being introduced. By keeping
the sustaining sponsor(s) actively engaged in the project, they will ensure their teams are intently participating in the project and identifying the operational
impacts that must be considered in order for the change to be sustained once the project has been completed.

[Link] Project Manager and Project Team

The project manager and the team members have high power and high interest since they are responsible for conducting all the teamwork and project
activities, and they define and sequence activities, estimate their duration, budget, and resources, identify resources and allocate them, identify and manage
risks, and monitor and control all project activities. They are those who are held accountable in the first place for the success of the project. Project managers
have to deal with stakeholders external to the organization as well as the internal environment, certainly more complex than what a manager in an internal
environment faces. For example, suppliers who are late in delivering crucial parts may blow the project schedule. To compound the problem, project
managers generally have little or no direct control over any of these stakeholders. Therefore, it is a challenging process for project managers and the team. We
will discuss team management in more detail in Chapter 6.

[Link] Top Management and Steering Committee

Top management may include the president of the company, vice-presidents, directors, division managers, and the corporate operating committee. They direct
the strategy and development of the organization. Project managers should have top management support, which means it will be easier to recruit the best
staff to carry out the project and acquire needed material and resources. Moreover, visibility can enhance a project manager’s professional standing in the
company. On the minus side, failure can be quite dramatic and visible to all, and if the project is large as is in our case and expensive, the cost of failure will
be more substantial than for a smaller, less visible project. Therefore, while dealing with top management, project managers should develop in-depth plans
and major milestones that must be approved by top management during the planning and design phases of the project. They should ask top management

5.3.3 [Link]
associated with the project for their information reporting needs and frequency. They should also develop a status reporting methodology to be distributed on
a scheduled basis, and keep them informed of project risks and potential impacts at all times. In our case study, the steering committee which is composed of
top managers and their representatives plays a crucial role during the project.

[Link] Functional Departments

In our case study, we have functional departments, which are the IT, sales, marketing, and maintenance/repair departments as well as branches all across the
USA. In general, central functional units have more authority than the regional offices have. All these units have managers and employees at various
hierarchical levels. Among the central units, the IT department is the one that we should work with more closely since the project is directly related to their
responsibilities, and most of the human and physical resources we need for the project activities reside in the IT department. Therefore, the IT department has
high power and high interest. The project also needs human resources from the sales, marketing, and maintenance departments. We need to consult subject
matter experts in these departments. Therefore, these department heads control their resources, and we rely on them. If we have a good relationship with
them, they may be able to consistently provide the best staff and the best equipment for our project. Employees from these departments may be in our core
team, or they may attend the project activities. Since the booking system directly affects their day-to-day operations, they have a higher interest. However,
their power level may not be very high all the time. It may fluctuate from moderately high levels to lower interest levels though it is generally not very low.

[Link] Internal Customers: Branches and Call Center

The branches in our case, and also the call center, are the internal customers of our project. They will be the end-users of the new ERP module when our
individual customers and employers of our organizational customers visit the branches or call the call center to book a vehicle or to talk about another issue
related to the booking (e.g., complaints, roadside assistance). These two categories of internal customers are those who hold the power to accept or reject the
deliverables of activities and the overall project when completed. However, they are generally represented by their managers, a product owner, or an
inspection and acceptance committee who have high power and naturally very high interest. Therefore, we should place them in the quadrant that makes us
manage them closely. Early in the relationship, the project manager will need to negotiate, clarify, and document project specifications and deliverables. After
the project begins, the project manager must stay tuned in to the customer’s concerns and issues and keep the customer informed. If call center agents don’t
find the new system user-friendly and easy to use, they may resist using it. They must be kept informed frequently, and their feedback should be sought
especially in critical decisions. Their resistance and dissatisfaction may lead to rework, which may cause the project to have budget overruns and schedule
slippages. This is why continuous user involvement and feedback are crucial during the project to minimize the risk of unacceptance.
While dealing with internal customers, the project manager and the team should pay attention to ensuring clarity about what stakeholders, in particular
customers, want precisely. This is a part of product and project scope management. Project managers should assign business and/or systems analysts who can
elicit requirements utilizing techniques such as surveys, interviews, focus group meetings, workshops, root and cause analysis, and document analysis. Project
managers should be aware of any issues regarding the lack of documentation for what is wanted, lack of knowledge of the customer’s organization and
operating characteristics, unrealistic deadlines, budgets, or specifications requested by the customer, hesitancy of the customer to sign off on the project or
accept responsibility for decisions, and changes in project scope. As explicated in Chapter 3 “Project Initiation” and Chapter 4 “Project Planning”, project
managers should address the needs and expectations of stakeholders such as customers, clients, or owners, and be sure to do the following:
Learn the organization’s organizational structure, culture, buzzwords, and business.
Clarify all project requirements and specifications in a written agreement.
Specify a change procedure clearly in change management and configuration management plans.
Establish the project manager as the focal point of communications in the project organization.

[Link] External Customers

Providing clarity about what stakeholders want precisely, as explained above for internal customers, is true for external customers too. Business and/or
systems analysts should also elicit requirements from external customers by utilizing techniques such as surveys, interviews, focus group meetings,
workshops, root and cause analysis, and document analysis. External customers are outside our organization. Therefore, they are within the external
stakeholders. In our case, external customers are individual customers (people who rent vehicles for leisure or work) and organizational customers (corporates
that rent vehicles based on a contract). When we finalize our project, they can book the rental vehicles on our website and mobile app, call the call center to
reserve a vehicle or talk about another issue related to the booking (e.g., complaints, roadside assistance) or they can visit a branch to reserve, pick up or
return a rental vehicle. Organizational customers, in general, have a contractual relationship with our company as they regularly and frequently rent vehicles
with better prices and conditions. They will be interested in our new booking system since a more effective system helps them have a smoother process with
minimum flaws. Most of the individual customers may not be frequent customers. They may pursue lower prices by comparing the prices based on the
vehicle type. Therefore, their interest in our new system may not be high most of the time. We can name them as occasional individual customers. However,
the customers who rent their vehicles from our company regularly may be interested in our project, and they may be willing to receive newsletters, for
example, once every month in their email accounts. The power level for both individual and organizational customers would be low since they don’t have the
authority and decision-making authority to significantly affect the course of the project (Figure 5.2).

[Link] External Stakeholders

In our case, individual customers (see [Link]), organizational customers (see [Link]), mobile app stores, insurance companies, travel agencies (including e-
commerce agencies), vehicle manufacturers, suppliers, government agencies, and not-for-profit organizations are our external stakeholders.
An important stakeholder group in our case would be two common mobile application stores – Android’s Google Play and Apple’s App Store. Our mobile
app developers and testers will use their SDKs (Software Development Kits), and they should authenticate the app before it can be used by the customers on
their smartphones. There will be also standards such as regarding privacy and security that we need to comply with. Thus, these two stores will have high
power in our project. However, their interest level may not be high as they are not impacted by this project and its outcomes. We should keep them satisfied
by complying with their standards, and terms and conditions.

5.3.4 [Link]
Government and regulatory agencies are generally considered to have high power and low interest if they have an inspection and approval authority in the
project. Project managers working 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, federal, to international. Besides,
constructors are subject to permits and inspections from the local (city and county offices such as Public Works, Fire, and Health Departments) and federal
agencies regarding the quality and legal standards they need to adhere to in their constructions (e.g., building permits, fire evacuation plan, fire and smoke
equipment, safety). This is why these agencies’ power level is high. In our case, government agencies were listed as the Department of Transportation and the
US Environmental Protection Agency. Although these agencies may perform controls and inspections, and release permits for our operations, they may not
have power and interest in our booking system. Thus, they are inside the low-power and low-interest quadrant in Figure 5.2. If there is a function or condition
that need to be added to our system, and these agencies should approve before we make the system available, then we can include them inside the high-power
and low-interest quadrant.
In our booking system project, we also have not-for-profit organizations such as associations that were established to reduce carbon emissions. Similar to
government agencies in our case, these organizations may not have power in our project. However, they may have a low or moderate level of interest since
the system could include the fuel efficiency rates for each car. In Figure 5.2, they were placed within the low-power and low-interest quadrant.
Insurance companies and travel agencies may be interested in our new booking system since some of them have an ongoing contractual relationship with
our company. When a customer wants to rent a vehicle, they can select an insurance plan during their rental time. Travel agencies, and/or travel websites (e.g.,
Expedia, Priceline) communicate with our company’s system to check the availability of our rental cars. Therefore, both insurance companies and travel
agencies may be interested in our project. However, their power level would be at a low level as they don’t have the decision-making authority to affect the
project activities.
Another stakeholder would be vehicle manufacturers from which our company, BRCW, purchases the vehicles to rent to the customers. Although they have
a high interest in our vehicle portfolio, and they have an ongoing relationship with our company, they may not have a high-level interest in the booking
system. Indeed, vehicle manufacturers prefer their vehicles to appear in the booking system with high-quality pictures and accurate technical information.
This is why they may have a moderate level of interest in our booking system. They would be willing to see the same look and feel or the picture and
information quality available in our current system. Therefore, they were placed in the low-power and high-interest quadrant in Figure 5.2. We can also use
the maintenance and service points of these vehicle manufacturers. However, this wouldn’t be related to the booking system.
Another stakeholder, suppliers of vehicle spare parts and consumables for offices at the central units and branches, wouldn’t have a high interest in our
booking system. They may have a moderate level of interest in the functions and conditions in our ERP module if spare parts and consumables are included.
Neither do they have power in our project. Many projects heavily depend on goods provided by outside suppliers. This is true for example of construction
projects where lumber, nails, brick, and mortar come from outside suppliers. If the supplied goods are delivered late or in short supply or of poor quality or if
the price is greater than originally quoted, the project may suffer. Therefore, their interest level would be high. However, in our case, their interest level
wouldn’t be high. Hence, they were replaced in the low-power and low-interest quadrant in Figure 5.2.
We didn’t include any contractors in our case study. However, there are times when organizations don’t have in-house expertise. Thus, available resources and
work is farmed out to contractors or subcontractors for the whole project or some of the activities. In a construction project, these subcontractors may be
consultants, electricians, carpenters, and architects. Managing them requires many of the skills needed to manage full-time project team members. We may
have problems with them regarding the quality of the work, cost overruns, and schedule slippage.

5.2.2 Case Study 5.2: Grocery LLC’s Mobile-Commerce Project

In Chapter 3 of this textbook, we created a project charter in the initiation phase of Grocery LLC’s mobile e-commerce project. The stakeholders specified in
this charter under “9. Key Stakeholder List” are below. Besides, project team members who are indicated under “12. Project Team” in Chapter 3 have been
included in the list below.
1. Project manager (Senior Systems Analyst)
2. Project team members (The core team)
1. Project manager: Senior systems analyst
2. Two systems (business) analysts
3. Two UI/UX designers
4. Three developers (including Android and IOS developers, and the backend developer)
5. Two testers (quality assurance engineers)
6. Two sales and marketing experts
3. Project sponsor (Chief Operations Officer – COO)
4. Product owner (The representative from the operational department who was assigned by the COO)
5. IT Department
6. Sales Department
7. Marketing Department
8. HR Department
9. Store managers and employees
10. Suppliers
11. Online customers
12. Customers who visit the stores in person
13. Government agencies that announce the pandemic restrictions
14. Google Play and App Store for the mobile application

5.3.5 [Link]
The stakeholders have been placed on the grid as illustrated in Figure 5.3. Different from Figure 5.2, this grid shows each stakeholder with dots inside their
quadrants. We should always keep in mind that the location of each dot should be justified, and they don’t indicate a GPS location so that they provide a
comparison of their locations with other stakeholders.

Figure 5.3. Stakeholder Power/Interest Grid for Mobile Commerce Project

High Power – High Interest Quadrant
We have explained in Case Study 1.1 that the project sponsor, project manager, and project team are placed in this quadrant. The product owner in the m-
commerce project of Grocery LLC is a representative from the operational department who was assigned by the COO. This person represents the interests of
the internal client, and the priority of the product specification is managed and directed by this person. Therefore, the product owner has a high authority to
affect the course of the project, and naturally, their interest is at a very high level from the very beginning to the very end of the project, extending beyond the
completion of the project. Let’s assume that two store managers will be assigned to the inspection committee that will assess the performance measures of the
mobile application to grant acceptance. In any case, whether they are at the committee or not, store managers are directly affected by the activities and
outcome of this project. Finally, the IT Department will be the main functional unit that will coordinate this project’s technical activities (programming,
testing, deployment), and assign systems (business) analysts, UI/UX designers, developers (including Android and IOS developers, and the backend
developer), and testers if these human resources are available in this department. If they are not available, the IT department will start a recruitment process
through the HR department.
High Power – Low Interest Quadrant
Similar to Case Study 1.1, mobile application stores, Android’s Google Play and Apple’s App Store, would have high power in this project. Developers and
testers in this project will use their SDKs (Software Development Kits), and they should authenticate the app before it can be used by the customers on their
smartphones. Thus, we should keep them satisfied by complying with their standards, and terms and conditions. During the project, we should keep an eye on
the announcements made by the government agencies regarding the pandemic. Modifications or new restrictions may affect the ongoing activities, and
challenge the allocation of human and physical resources. The fourth stakeholder in this quadrant would be the HR department. Although the HR department
may not have high interest, their power level could be higher due to the fact that the recruitment process should be carried out through them as explained
above in the “high power – high interest quadrant”.
Low Power – High Interest Quadrant
As indicated in the “high power – high interest quadrant”, store managers’ interest will be high as their stores will need to manage the online orders. They
will also be interested in the features of this application and its store interface since the store employees will need a user-friendly application to process the
orders smoothly. Therefore, employees are expected to have a high-level interest in this project. Although both managers’ and employees’ power to influence
the project activities and outcomes wouldn’t be high, we can still expect a moderate level of power because of their key role in the process. In the
headquarters of Grocery LLC, sales and marketing departments are expected to have a high interest in this project. Actually, both departments will provide
human resources directly in the project team. Besides, the mobile application’s content and its marketing tools will be managed by these two departments.
Finally, we can place online customers in this quadrant as the end-users of the mobile app. The project team should elicit these stakeholders’ expectations
from the app while creating, validating, and finalizing the requirements of the app.
Low power – Low Interest Quadrant
In this case study, we have two stakeholder groups in this quadrant. Suppliers have a key and frequent relationship with the grocery chain. However, their
interest would be mostly on the supply chain management system through which they communicate with the chain and the intermediaries to dispatch the

5.3.6 [Link]
items ordered by the stores. Increased sales by means of the mobile app would benefit suppliers. However, the relationship with the grocery chain depends on
the agreements and contracts independent of the mobile application. Nevertheless, we can still expect a moderate level of interest in this project. The second
stakeholder group in this project would be customers who prefer visiting the stores in person, and hence who don’t think of using the mobile app. Their
interest level can be at a minimum level.

5.2.3 Stakeholder Register

In order to have a better picture of stakeholders, we should have a stakeholder register accompanied by the power/interest grid we delineated above. This
register should include information about all our stakeholders, both key and those with low interest and low power. Table 5.1 illustrates an example of a
stakeholder register based on our case study about a rental vehicle booking system implemented at BRCW.
Table 5.1. Stakeholder Register

ID Stakeholder Organization Power Interest Current Level of Risk Related Issues & Engagement
Name, Title, Name Level Level Level of Support Rating Stakeholders Concerns Strategy &
and Contact (H/M/L) (H/M/L) Support Required (H/M/L) Tactics
Information

1 Project BRCW H H Supports Supports L Project Committed Should be

Sponsor Actively Actively to the project managed
Team and wants to closely.
CTO
Steering ensure the Signs off the
Committee external project charter
IT resources the
organization and the plan,
Department and authorizes
provides
deliver on the project
expectations. manager.
Releases the
budget and
resources.
Very frequent
communication.

2 Google Play Google H L Neutral Supports M App Store Should Google Play
Store (Android) authenticate guidelines must
Project our app be followed for
Team before it can compliance.
be used by
our
customers on
their
smartphones.
Google
Play’s SDK
will be used.
App
features,
privacy, and
security
issues should
be complied
with.
New apps
must target
at least
Android 11
(API level
30).

3 Organizational Company X L H Opposes Supports H Project Company X The project

Customer managers team and sales
Team raised some department
Sales issues in the must
Department recent communicate
Call Center meetings to with this
terminate the stakeholder’s
Branches
contract with top
BRCW. management
They don’t frequently to
think that show BRCW’s
commitment to
BRCW can this project.
create a new

5.3.7 [Link]
 effective Each increment
app. of the website
and mobile app
should be
shown to
receive
feedback.

4 Occasional NA L L Neutral Supports L Project They try to The new

individual find the most booking system
customers Team affordable should be
Call Center price among optimized to
Branches many rental show the best
companies’ offers to these
offers. customers.

Level of support (either current or desired) can be evaluated in five levels[4]:

1. Supports Actively: Anticipates and feels the need for change, actively works with the project team.
2. Supports: Anticipates and feels the need for change, but does not involve in the project team.
3. Neutral – Neither supporting nor opposing.
4. Opposes – Neither feels the need for change nor tries to prevent the change.
5. Opposes Actively – Doesn’t see the need for change, actively working to prevent the change.
In some cases, it isn’t uncommon for project managers to be working with stakeholders that are not supportive of the project. They may feel the project is not
going to benefit them or their organizations. They may also resist making the changes that are necessary to support the project’s outcomes. Some stakeholders
are very upfront about their resistance and others are not. In these situations, the project sponsor may be integral to winning these stakeholders over. Knowing
when to tactfully involve others in stakeholder management is another key success factor for effective project management.
Stakeholders are critical factors to be taken into account while identifying the risks. Their risk rating helps the team determine individual and overall project
risks. The project manager and the team should use judgment in deciding how to handle each stakeholder by evaluating their current and desired support
level, the potential impact on the project activities, decisions and outcomes, and their issues and concerns regarding the project and other stakeholders. The
role of stakeholders in identifying and managing risks will be discussed in Chapter 10.
Stakeholders may convey their issues regarding the project explicitly or implicitly. Therefore, the team should attempt to analyze and list what kind of issues
and concerns are available and may emerge during the implementation of the project. Based on all the inputs discussed, the team should carry out
brainstorming sessions and come up with strategies for the stakeholders whose lack of support significantly might impact the project’s success, how to gain
their support, and how to engage them effectively in the project. Table 5.1 includes issues and concerns with four stakeholders in the rental booking system
project, and engagement strategy and tactics.
Furthermore, we should consider the relationship among stakeholders. Can we improve the project’s chances by working with those who support us to
improve the views of those who oppose? Therefore, as indicated in Table 5.1, it would be helpful for the team to have information regarding the relationships
among the stakeholders. For example, related stakeholders have been indicated as the project team, sales department, call center, and branches for
organizational customers.
A stakeholder register is a living document that should be reassessed regularly as is done for other plans and documents such as risk register and issue log
(see Chapter 10). Thus, the project team should assign some time in their weekly or monthly meetings to discuss whether revisions are required to do in the
stakeholder register. Stakeholders’ power and interest levels, support levels, risk ratings, issues and concerns, and accordingly engagement strategies and
tactics could change throughout the project. Besides, new stakeholders may be added later. This process is discussed in 5.3 “Managing and Monitoring
Stakeholders”.

[Link] Stakeholder Engagement Assessment Matrix

Another data representation tool that can be used is a Stakeholder Engagement Assessment Matrix. It can also be incorporated into the stakeholder register. In
Table 5.1 above, the level of support was indicated in five levels: (1) Supports actively, (2) supports, (3) neutral, (4) opposes, and (5) opposes actively[5].
Besides this, another matrix can be used as detailed in the PMBOK Guide 6th Edition. C indicates the current engagement level whereas D indicates desired
level.
Table 5.2 Stakeholder Engagement Assessment Matrix (Adopted from PMBOK Guide 6th Edition)

Stakeholder ID Unaware Resistant Neutral Supportive Leading

1 C D

2 C D

3 C D

*C: Current, D: Desired

5.3.8 [Link]
As indicated in Table 5.2, stakeholders are evaluated based on five levels of engagement. They may be unaware of the project and its potential impacts. They
may be aware of the project and potential impacts but resistant to any changes that may occur as a result of the work or outcomes of the project. These
stakeholders will be unsupportive of the work or outcomes of the project. When stakeholders are aware of the project but neither supportive nor unsupportive,
we can classify them as neutral. When they are aware of the project and potential impacts and supportive of the work and its outcomes, we can classify them
as supportive. Eventually, stakeholders are classified as leading when they are aware of the project and potential impacts and actively engaged in ensuring that
the project is a success.

[Link] Responsibility Assignment Matrix (RACI Chart)

Another data representation technique that can be used to illustrate each team member’s and relevant stakeholders’ roles and responsibilities in each project
activity can be a responsibility assignment matrix. It shows the project resources assigned to each work package (lowest level activities in a WBS). One of the
common responsibility assignment matrices is RACI (responsible, accountable, consult, and inform) chart. A RACI chart is a useful tool to ensure clear
assignment of roles and responsibilities when the team consists of internal and external resources[6]. As seen in Table 5.3, a RACI chart displays the activities
associated with team members and stakeholders.
In order to avoid confusion about who is ultimately in charge of supervision and/or decision-making for an activity, there should be only one person
associated with accountability[7]. A role that is “Accountable” has the final authority or accountability for the task’s completion. This role is generally
assumed by the project sponsor, project manager, or a supervisor or team members delegated by the project manager for an activity. As seen in Table 5.3, for
each activity, we have only one role that assumes an accountability role. For example, in the “Collect Requirements” activity, Jim is the team member who is
responsible for coordinating the whole activity and/or performing the tasks directly. Jim can consult Jane and Anna who may be subject matter experts who
have a substantial amount of experience and knowledge or those who are affected significantly by the activity and have an interest in this activity and the
overall project. Thus, Jim can interview Jane and Anna, and learn about their needs, expectations, and concerns. Mary can be the project manager or the
supervisor in the team that audits and approves the activity and its deliverables. Tom could be a stakeholder with high interest and low power. We should keep
him informed about what is going on in this activity. We can also receive feedback from Tom to improve the tasks in this activity.
Table 5.3 RACI Chart

Team Member or Stakeholder

Activity Jim Mary Chris Jane Anna Tom

Plan Scope Management A R R I C C

Collect Requirements R A I C C I

Define Scope A R R I C C

Create WBS A R R R I

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.
↵
2. [Link] ↵
3. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK Guide), version 3.0. Toronto, Ont:
International Institute of Business Analysis. ↵
4. Anupam (n.d.). Stakeholder Analysis Register. Retrieved from [Link] ↵
5. Anupam (n.d.). Stakeholder Analysis Register. Retrieved from [Link] ↵
6. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.
↵
7. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.
↵

This page titled 5.3: Stakeholder Analysis is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

5.3.9 [Link]
5.4: Managing and Monitoring Stakeholder Engagement
After we identify the stakeholders, analyze their positions in terms of interests, power, influence, involvement, interdependencies,
and potential impact on the project success, and accordingly develop strategies to involve them in the project to make them
supportive of the project (and at least not opposing the project), we can manage and monitor their engagement[1]. This engagement
should be detailed in a stakeholder engagement plan which is a component of the project management plan that identifies the
strategies and actions required to promote the productive involvement of stakeholders in decision making and execution[2]. The
stakeholder power/interest grid, stakeholder register, and other data gathering and analysis techniques are included in this plan
created to guide the project team throughout the project to identify the strategies and approaches for engaging stakeholders.
During the execution of project activities, the project manager allocates most of the workforce and resources required for activities
and spends a substantial amount of the budget. Based on the stakeholder engagement plan and its components, project managers
should communicate and work with stakeholders to meet their needs and expectations, address issues, and foster appropriate
stakeholder involvement[3]. This plan helps us while eliciting stakeholders’ requirements, expectations, and concerns, having
meetings, interviews, and workshops with them, sending them periodic newsletters to keep them updated about the progress of our
project, carrying out the activities to create deliverables that can satisfy their needs, and closing out the project after the approval of
the client.
Identification of stakeholders brings about another key aspect of stakeholder management – communication with them. The
communication protocol must be incorporated into the stakeholder engagement plan. Communication methods can be adapted to
suit the unique nature of the project. This adaptation will also strongly affect project success. Key questions the project team needs
to address are:
Which stakeholders will make the decision in the organization on a specific issue, and which of them should be involved in this
process? In particular, to whom we should consult about an issue, and inform?
What type of communication types and methods should we utilize? Do the stakeholders want lengthy documents? Formal or
informal communication? Is “short and sweet” the typical standard?
What medium of communication is preferred? What kind of medium is usually chosen for various situations? Check the lessons
learned repositories to see what past projects have done.
Although project managers keep each stakeholder’s expectations and needs in mind throughout each conversation, report or email,
we should always remember that the interests of both our company and the client are more important than any stakeholder’s
interests. However, preferring our company’s or client’s interests over other stakeholders’ may lead to failure during the
implementation or after the deliverables of the project are made available for the clients and customers in the market. Market
demand is a critical determinant of the success of our project outcome.
No matter what stakeholders’ needs or wants are, all of them will respect the project manager who:
always provides justification of the actions and results, 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.
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 make the difference
between project success and failure. Managing stakeholder engagement helps to ensure that stakeholders clearly understand the
project goals, objectives, benefits, and risks for the project, as well as how their contribution will enhance project success[4].
The project manager’s interpersonal skills are needed especially while communicating with the stakeholders (see Chapter 6 for
more discussion of interpersonal and leadership skills). Project managers must rely on their soft skills to be effective. Effective
project management spends a significant amount of time building relationships with stakeholders. It is of high importance for a
project manager to obtain, confirm, and maintain stakeholders’ commitment to the success of the project. Project managers manage
their expectations through negotiation and communication. Building trust and maintaining an open line of communication are
critical in working with all stakeholders. Keeping stakeholders involved is essential and it requires more than simply sharing
information. The project manager must ask for their input and demonstrate an understanding of a stakeholder’s unique business
challenges. This level of understanding is often done through simple and regular check-ins with stakeholders. Project managers

5.4.1 [Link]
who are successful in relationship building understand each stakeholder’s capacity to participate and honor their time constraints.
Then, addressing risks or potential concerns and anticipating future issues that may be raised by stakeholders would be less
challenging for a project manager equipped with effective interpersonal skills. Finally, project managers can clarify and resolve
issues that have been identified.
Besides managing stakeholder engagement, project managers should assure that they and their teams monitor stakeholder
relationships, and modify engagement strategies and plans during the project when needed. As is the case for all knowledge areas,
project managers have a critical responsibility to track, review and regulate the progress and performance of the project, and
accordingly to identify areas where modifications are required in the plan, and to perform corrective and preventive actions if
needed. Stakeholders’ interests and power levels may change during the project. This leads to a change in strategies to engage
them. Moreover, a stakeholder’s support of the project objectives and outcomes may change in an opposite direction. It may move
from supportive to resistant due to various factors. Supporting stakeholders may find new information that isn’t in favor of their
interests, and even may give harm. In our rental vehicle booking case, assume that one of the insurance companies that we work
with is not included in the new system as an insurance provider. This company’s representatives thought that their company’s
partnership with BRCW would continue. However, they were informed that their company’s offer will be listed as an alternative to
another insurance company’s offer. Therefore, their attitudes may change to oppose the project when they are informed about it.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
4. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 5.4: Managing and Monitoring Stakeholder Engagement is shared under a CC BY-NC 4.0 license and was authored, remixed,
and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

5.4.2 [Link]
5.5: Key Takeaways
Key Takeaways
Stakeholders are those who have a positive or negative influence on the project, or who are or might be positively or negatively
affected by the project, or its activities, decisions, and outcomes. Stakeholders can be anyone including, but not limited to,
individuals, groups, teams, businesses, corporations, communities, government agencies, not-for-profit organizations,
international bodies, and non-governmental organizations.
The stakeholder power/interest grid is a two-dimensional matrix with four quadrants. It helps project leaders categorize
stakeholders and create effective communication strategies for each category of stakeholder on the project.
Stakeholder register provides a snapshot about all the stakeholders in terms of their power and interest levels, current and
required support levels, risk ratings, their relationship to other stakeholders, issues and concerns, and engagement strategy and
tactics to keep them supportive of the project or keep their resistance in a very low level.
One of the common responsibility assignment matrices is the RACI (responsible, accountable, consult, and inform) chart which
is a useful tool to ensure clear assignment of roles and responsibilities when the team consists of internal and external resources.
The project manager’s interpersonal skills are needed especially while communicating with the stakeholders. Project managers
must rely on their soft skills to be effective. Effective project manager spends a significant amount of time building
relationships with stakeholders. It is of high importance for a project manager to obtain, confirm, or maintain stakeholders’
commitment to the success of the project.

This page titled 5.5: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

5.5.1 [Link]
5.6: Questions and Exercises
There are 8 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 5.6: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

5.6.1 [Link]
5.7: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).

This page titled 5.7: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

5.7.1 [Link]
 CHAPTER OVERVIEW

6: Communication Management, Leadership, and Project Team Management

6.1: Learning Objective and Overview
6.2: Communications Management
6.3: Communication Types
6.4: Communications Management Protocol
6.5: Leadership Skills
6.6: Leadership Styles and Servant Leadership
6.7: Creating a Project Culture
6.8: Developing and Managing a Project Team
6.9: Key Takeaways
6.10: Questions and Exercises
6.11: Attribution

This page titled 6: Communication Management, Leadership, and Project Team Management is shared under a CC BY-NC 4.0 license and was
authored, remixed, and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

1
6.1: Learning Objective and Overview
Learning Objectives
1. Evaluate the importance of good communication in project management
2. Create a communication management plan.
3. Describe the interpersonal and technical skills that project managers need to lead project teams and manage the projects
effectively.
4. Explain the methods of how project managers can cope with conflicts by utilizing interpersonal skills.
5. List the leadership styles, and define the servant leadership that is favored for project managers.
6. Explain how project managers can create a culture pertinent to a project.
7. Describe the processes to develop and manage project teams.
8. Describe the virtual project teams that are exponentially utilized worldwide by all types of organizations, and compare in-
person and virtual teams.

6.0 Overview
As highlighted in Chapter 5 “Stakeholder Management”, project managers and their teams spend most of their time communicating
and collaborating with the stakeholders. Indeed, project managers, themselves, spend 90% of their time communicating[1].
Therefore, most of this chapter addresses the aspects of communication which is necessary to sustain a healthy relationship with all
the stakeholders besides project team members. In this chapter, we are also focusing on the team management that elaborates on the
relationships between the project manager and other team members as well the relationships among all team members. Working
with people, inside and outside the project team, involves dealing with them both logically and emotionally. A successful working
relationship between individuals begins with appreciating the importance of emotions and how they relate to personality types,
leadership styles, negotiations, and setting goals.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 6.1: Learning Objective and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

6.1.1 [Link]
6.2: Communications Management
Projects require teamwork, and team members must communicate with each other in a variety of ways. The documents they
produce must be collected, distributed, and stored in an appropriate manner to assure timely and accurate communication between
team members. This process is often assisted by a variety of technologies including computer and smartphone software programs
and applications. The advent of the Internet accompanied by various ICTs (Information and Communication Technologies), and the
emergence of the COVID-19 pandemic by the end of 2019 accelerated the process of digitalization for people, and all organizations
including the companies, multinational corporates, non-governmental organizations, governments, and international bodies. Thus,
the adoption and spread of ICTs worldwide across organizations and countries increased exponentially. The utilization of global
virtual teams in organizations increased to unprecedented levels. 94% of the respondents of CultureWizard’s Global Virtual Work
Survey indicated that employees want to continue working from home—at least part time[1]. More virtual presence has brought
about new challenges as detailed in the “Virtual Teams” section in this chapter.
ICTs can facilitate faster and better communication, or they can become a barrier if they are not well understood and applied
appropriately. Besides, as detailed in Chapter 5, the project manager and the team should be in ongoing contact with all the
stakeholders based on their power and interest levels, and other factors such as influence, involvement, support required, and
interdependencies. This necessitates the manager to choose an optimal portfolio of communication technologies and
methodologies. Therefore, these issues should be well-thought by the project manager while preparing the project plan and its
subcomponent “Project Communications Management Plan”.

6.1.1 Communication Management Plan

Communications management is about keeping everybody in the loop. The communications planning process concerns defining the
types of information we will deliver, who will receive it, the format for communicating it, and the timing of its release and
distribution. Hence, it is of high importance to make sure everybody gets the right message at the right time.
As is the case for all knowledge areas (e.g., scope, schedule, cost, resource, risk, communication, stakeholder), the first step is to
plan so that we can delineate the guidelines that we should follow during the execution of the project activities, and while we
monitor and control them. This provides us a direction based on the information needs of each stakeholder, available organizational
assets, and the needs of the project[2]. All projects require a sound communication plan, but not all projects will have the same
types of communication or the same methods for collecting, analyzing, and distributing the information. The communication plan
documents the types of information needs the stakeholders have, when the information should be distributed, how the information
will be delivered with which frequency, who will receive it, and the format and technologies we will use to communicate.
First off, we should figure out what kind of communication our stakeholders (including the project team) need so they can make
good decisions and they are well-informed. This is called the communications requirements analysis. Our project will produce a lot
of information, so we don’t want to overwhelm the stakeholders with all of it. Our job is to figure out what they feel is valuable.
Therefore, the stakeholder power/interest grid (matrix) and the stakeholder engagement assessment matrix would be very helpful to
determine the priorities of each stakeholder, and how we can communicate with each of them (see Chapter 5), Communicating
valuable information doesn’t mean we always paint a rosy picture. Communications to stakeholders may consist of either good
news or bad news. The point is that we don’t want to bury stakeholders in too much information but we do want to give them
enough so that they’re informed and can make appropriate decisions. ICTs have a major impact on how we keep people in the loop.
Therefore, our analysis and the plan should include them.
We should answer the questions below in our communications management plan:
What are the methods of communicating that we need to consider? Which methods can we choose to transfer information?
It can take many forms, such as written reports, conversations, email, formal status reports, meetings, online databases,
online schedules, and project websites.
How should we arrange the timing of the information exchange or need for updates? What is the reporting frequency for each
stakeholder according to the expectations and concerns of stakeholders?
Based on the role and responsibilities of team members, and the interest and power levels of stakeholders, methods, and
frequency should be identified for each stakeholder.
In “Case Study 5.2” in Chapter 3 which created the stakeholder power/interest grid for Grocery LLC’s mobile-commerce
project, we indicated store managers in the inspection committee and online customers who are willing to do their shopping
through the mobile app. While we can communicate with these store managers more frequently (e.g., once a week) by in-

6.2.1 [Link]
 person and online meetings, and emails during the project, we can communicate with the customers less frequently by
sending them updates in a newsletter format every two weeks.
Who is the person responsible for communicating the information? Who authorizes the release of confidential information?
Who receives the information according to their needs, expectations, and concerns?
Do we need to procure new technology or systems, or are there systems already in place that will work?
This is also a part of enterprise environmental factors and organizational process assets to take into consideration while
planning any knowledge areas in project management[3].
The technologies available to us help plan how we will keep everyone notified of project status and issues.
What is the experience of our staff with the technology? Are there project team members and stakeholders experienced at using
this technology, or should we need to train them?
How does the project team function? Are they located together or spread out across several locations in a country or the world?
What are the resources, time, and budget allocated for communication activities?
The answers to these questions should be documented in the communication plan. Keep in mind that all the components of a
project management plan are interrelated. A communication plan cannot be prepared independently of other components such as
the plans for the scope, schedule, cost, risk, and stakeholders. For example, concerning ICTs, we should consider if the technology
we are choosing would work throughout the life of the project or we should upgrade or update it at some point.
The types of information we will communicate typically include project status, project scope statements and updates, project
baseline information, risks, action items, performance measures, project acceptance, and so on. We should also consider the
language, format, content, and level of detail. The information needs of the stakeholders must be determined as early in the
planning phase of the project management life cycle as possible so that as we develop project planning documents, we already
know who should receive copies of them and how they should be delivered.

1. CultureWizard. 2020 Trends in Global Virtual Work: Metamorphosis of the Global Workplace. 2020. [Link]
[Link]/virtual-teams-exec-report-2020↵
2. PMBOK 6th edition. ↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 6.2: Communications Management is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

6.2.2 [Link]
6.3: Communication Types
The communication management plan should address the needs, expectations, and concerns of the project team and the
stakeholders by considering the communication types. Completing a complex project successfully requires good communication
among team members. If those team members work in the same building, they can arrange regular meetings, simply stop by each
other’s office space to get a quick answer, or even discuss a project informally at other places like meeting rooms and even in the
kitchen and next to the coffee machine. Many projects are performed by teams that interact primarily through electronic
communication and are, therefore, called virtual teams (see 5.7). However, virtual interaction has been exponentially prevalent for
many organizations and collocated project teams. To avoid miscommunication that can harm trust and to include team members in
a project culture, the project team needs a plan for communicating reliably and in a timely manner. This planning begins with
understanding two major categories of communication – synchronous and asynchronous.

6.2.1 Synchronous Communications

If all the parties to the communication are taking part in the exchange at the same time, the communication is synchronous. The
following are examples of synchronous communications:
In-person meetings: This is the traditional meeting method utilized by collocated teams. Some virtual teams may also prefer in-
person meetings several times (e.g., kick-off and closing meetings) during the project life cycle to socialize and build trust.
One-on-one and conference phone (audio) calls: These calls would be effective if there is an urgent need to meet, and
participants are not available for video calls.
Video conferences: These meetings have prevailed with the widespread utilization of virtual teams and the emergence of the
COVID-19 pandemic. Online tools such as Skype, Zoom, Google Meet, and WhatsApp are used for video conferences.
Integrated solutions such as Microsoft Teams: Teams can use synchronous communication tools such as video conferences and
instant messaging, and they can share the files with other team members (asynchronous).
IM (instant messaging): Team members can exchange text or voice messages on computers and mobile devices. They can also
have group pages on which more than two members can chat and share documents, pictures, and videos. IM may not be
synchronous all the time, and it provides an opportunity for the team members to reply later, and keep the records of the chat
logs.

6.2.2 Asynchronous Communications

Getting a team together at the same time can be a challenge—especially if they are spread out across time zones. Many types of
communication do not require that the parties are present at the same time. This type of communication is asynchronous. There are
several choices of asynchronous communications such as mails and faxes. Recently, asynchronous communication has also been
transferred mostly to online communication. In many projects, there is a need to deliver mails and packages to other team members
or sub-teams, and stakeholders in different locations. Physical signatures can be still demanded to comply with the legal
requirements. However, online tools have been allowing people to sign electronically, which is also legally acceptable (e.g., Adobe
Acrobat, DocuSign). Therefore, this provides time and cost-saving opportunities to the project teams. Electronic mail (email) is
widely used to coordinate projects and for the communication and collaboration between team members and with stakeholders.
Emails have several valuable characteristics for project management. 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.

This page titled 6.3: Communication Types is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

6.3.1 [Link]
6.4: Communications Management Protocol
The communication management plan should include a protocol that delineates all the critical communication channels for the
team and stakeholders, such as the purpose of communication, ICTs utilized, frequency of communications, and types of
information to be communicated. An example of a Communications Management Protocol has been provided in Table 6.1 which
includes only four purposes of communication.
Table 6.1. Communications Management Protocol

Purpose of Schedule Frequency ICTs or Other Means Types of Information Participants: Team
Communication Utilized Members and
Stakeholders

Planning Every week on Monday Microsoft Teams Requirements All the team members
Zoom Project activities
OneDrive Schedule
Emails Cost
Risks and issues

Retrospective Every week on Friday Microsoft Teams Status updates All the team members
Zoom Lessons learned
OneDrive
Emails

Emergency As needed Zoom or In-person Depends on the reason All the team members
for emergency

Status updates Every week after the Emails Progress report Project sponsor
retrospective meeting Zoom or In-person Tracking Gantt Chart Client
Or as needed meetings Comparison of All team members
baselines with the latest
situation

This page titled 6.4: Communications Management Protocol is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated
by Abdullah Oguz (MSL Academic Endeavors) .

6.4.1 [Link]
6.5: Leadership Skills
Project managers, as leaders, spend 90% of their time communicating with team members and stakeholders. Therefore,
communication is the most important leadership skill a project manager should possess, but not the only one. Project managers
need a large number of skills which include administrative skills, organizational skills, and technical skills associated with the
technology of the project. The types of skills and the depth of the skills needed are closely connected to the size and complexity of
the project. This is why each project needs tailoring according to various factors including the purpose, objectives, business field,
size, complexity, and stakeholders. Although project managers always need to possess interpersonal skills to communicate and
collaborate effectively with the team members and stakeholders, on smaller, less complex projects, they need a greater degree of
technical skills. On larger, more complex projects, project managers need more organizational skills to deal with the complexity.
PMBOK Guide 6th Edition differentiates among three skill sets project managers should possess – technical project management,
leadership, and strategic and business management. Contrary to the name as is referred to as technical, it doesn’t indicate the skills
regarding product and industry expertise. This expertise is included inside strategic and business management skills. PMBOK
Guide highlights this skill set as “technical project management skills”, and defines them as the skills to effectively apply project
management knowledge to deliver the desired outcomes for projects and programs. Organizations look for project managers who
are competent in implementing a systematic project management approach applying the right artifacts and methods to achieve the
project objectives. Accordingly, project managers should be able to define critical success factors for the project, create plans for all
the knowledge areas (i.e., integration, scope, schedule, cost, quality, resource, communications, risk, procurement, stakeholders),
create, manage and monitor the project team, conduct all project management processes, monitor and control all the project work,
close out the project, and disband the team. Besides, project managers should have the capability to decide which development
approach would be the best for the project. Therefore, they should know the development approaches including traditional
(waterfall or predictive) and agile (adaptive) tools, techniques, and methods. As indicated, strategic and business management skills
include developing and applying pertinent product and industry expertise. They involve the ability to see the high-level overview of
the organization and effectively negotiate and implement decisions and actions that support strategic alignment and innovation.
This ability may include a working knowledge of other functions such as finance, marketing, and operations. This business
knowledge is also known as domain knowledge[1].
The third skillset, leadership skills, involves the ability to guide, motivate, and direct a team. Leadership is defined as a social
(interpersonal) influence relationship between two or more persons who depend on each other to attain certain mutual goals in a
group situation. Effective leadership helps individuals and groups achieve their goals by focusing on the group’s maintenance needs
(the need for individuals to fit and work together by having, for example, shared norms) and task needs (the need for the group to
make progress toward attaining the goal that brought them together)[2]. These skills include negotiation, resilience, communication,
problem-solving, critical thinking, and interpersonal skills.
Projects have become increasingly more complicated as more businesses execute their strategies through projects. Project
management is more than just working with numbers, templates, charts, graphs, and computing systems. Though they can be
counted, a common denominator in all projects is people. But they are not just numbers. A large part of the project manager’s role
involves dealing with people. Hence, project managers should study people’s behaviors and motivations. Project managers must be
perceived to be credible by the project team and stakeholders. They should detect and clarify the ambiguities effectively to remove
the obstacles. On projects, the environment changes frequently, and the project manager must apply the appropriate leadership
approach for each situation. They must have good communication skills. Lack of communication skills and team-building skills as
well as organizational skills would cause problems in a project and could lead to failure.
PMBOK Guide 6th Edition makes an analogy of a music conductor for the project managers. This analogy is a perfect example
describing the responsibilities and skills of project managers. An orchestra conductor coordinates a variety of performers who play
different instruments and should ensure that the audience enjoys the music on the day of the performance. It may be a chamber
orchestra composed of 25 musicians, or a large one like a symphony orchestra with up to 100 members. The conductor cannot
know how to play all the instruments in an orchestra, but only one of them or a few of them. However, the conductor must assure
that all the performers playing the instruments including but not limited to violins, violas, cellos, double basses, flutes, oboes,
clarinets, kettledrums, and harps must create a piece of music in harmony that the audience can enjoy. Conductors perform many
rehearsals with all the performers to achieve this harmony. During these rehearsals and the performance, most of the work of the
conductor would be regarding communication with all the performers.

6.5.1 [Link]
The project manager leads the project team during a project life cycle. As explained in Chapter 2, project managers may start
working in the pre-project phase (preparation of a need statement, business case, and benefits realization management plan) to
assess the feasibility of candidate projects, especially when the organization has a dedicated PMO (Project Management Office) or
has a strong matrix or project-oriented structure. However, in general, project managers are assigned in the initiation (starting,
conceptualization) phase, or the planning phase after the project charter is approved by the project sponsor. A project manager may
be involved after the project is closed out to evaluate the performance of the outcome, and more importantly to evaluate if the
outcome can generate the expected value (both tangible and intangible values as detailed in measurable project objectives).
Although we use the term “project manager” in this textbook, you can come across a variety of concepts such as project leader,
project lead, and project coordinator in other resources and also in this textbook in different sections. We assume in this textbook
that a project manager is also a project leader, and should possess interpersonal leadership skills.
In the following subsections, we will focus on leadership and interpersonal skills a project manager should possess.

6.4.1 Listening
One of the most important communication skills of the project manager is the ability to actively listen. Active listening is placing
oneself in the speaker’s position as much as possible, understanding the communication from the point of view of the speaker,
observing and paying attention to the 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 that
is being shared and to develop a more complete understanding of the information.
Example: Client’s Body Language [3]
We work with a client on a project. The person in charge of the project in the client company just returned from a trip to Australia
where he reviewed the progress of the project with his company’s board of directors. Then, he visited our office for a meeting with
our project team. The project manager listened and took notes on the five concerns expressed by the board of directors to him
during his visit to Australia.
Our team’s project manager observed that the client’s body language showed more tension than usual. This was a cue to listen very
carefully. The project manager nodded occasionally and clearly demonstrated he was listening through his posture, small agreeable
sounds, and body language. The project manager then began to provide feedback on what was said using phrases like “What I hear
you say is…” or “It sounds like.…” The project manager was clarifying the message that was communicated by the client.
The project manager then asked more probing questions and reflected on what was said. “It sounds as if it was a very tough board
meeting.” “Is there something going on beyond the events of the project?” From these observations and questions, the project
manager discovered that the board of directors meeting in Australia did not go well. The company had experienced losses on other
projects, and budget cuts meant fewer resources for the project and an expectation that the project would finish earlier than
planned. The project manager also discovered that the client’s future with the company would depend on the success of the project.
The project manager asked, “Do you think we will need to do things differently?” They began to develop a plan to address the
board of directors’ concerns.
Through active listening, the project manager was able to develop an understanding of the issues that emerged from the board
meeting and participate in developing solutions. Active listening and the trusting environment established by the project manager
enabled the client to safely share information he had not planned on sharing and to participate in creating a workable plan that
resulted in a successful project.
In the example above, the project manager used the following techniques:
Listening intently to the words of the client and observing the client’s 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
Therefore, as can be seen in the example above, active listening was important in establishing a common understanding from which
an effective project plan could be developed.

6.4.2 Negotiation
When multiple people are involved in an endeavor, differences in opinions and desired outcomes naturally occur. Negotiation is a
process for developing a mutually acceptable outcome when the desired outcome for each party conflicts. A project manager will

6.5.2 [Link]
often negotiate on different aspects of a project (e.g., scope, schedule, budget, quality, purchases, conflicts with stakeholders) with
the client, team members, vendors, and other project stakeholders. Negotiation is an important skill in developing support for the
project and preventing frustration among all parties involved, which could delay or cause project failure. Negotiation is used to
achieve support or agreement that supports the work of the project or its outcomes and to resolve conflicts within the team or with
other stakeholders.
Negotiations involve four principles:
1. Separate people from the problem:
Framing the discussions in terms of desired outcomes enables the negotiations to focus on finding new outcomes.
2. Focus on common interests:
By avoiding the focus on differences, both parties are more open to finding acceptable solutions.
3. Generate options that advance shared interests:
Once the common interests are understood, solutions that do not match with either party’s interests can be discarded, and
solutions that may serve both parties’ interests can be more deeply explored.
4. Develop results based on standard criteria:
The standard criterion is the success of the project. This implies that the parties develop a common definition of project
success.
For the project managers to successfully negotiate issues on the project, they should first seek to understand the position of the
other party. They should figure out the concerns and expectations of team members or stakeholders with whom they will negotiate,
as well as the business drivers and personal drivers that are important to them. Without this understanding, it is difficult to find a
solution that will satisfy them. Project managers should also seek to understand what outcomes are desirable to the project.
Typically, more than one outcome is acceptable. Without knowing what outcomes are acceptable, it is difficult to find a solution
that will produce that outcome.

6.4.3 Conflict Management

Conflict on a project can be expected because of a variety of reasons such as the level of stress, lack of information in particular
during the early phases of the project, personal differences, role conflicts, and limited resources. Although good planning, effective
communication, and healthy team building can reduce the amount of conflict, the conflict will still emerge. How the project
manager deals with the conflict results in the conflict being destructive or an opportunity to build energy, creativity, and innovation.
One of the well-known conflict management models is the Thomas-Kilmann Conflict Mode Instrument (TKI) which assesses an
individual’s behavior in conflict situations when the concerns of two people appear to be incompatible[4]. This model is based on
two dimensions that describe a person’s behavior in conflict.
1. Assertiveness: The extent to which the individual attempts to satisfy his or her own concerns.
2. Cooperativeness: The extent to which the individual attempts to satisfy the other person’s concerns.
According to different levels of these two dimensions, the model defined five methods of dealing with conflict (Figure 6.1).

6.5.3 [Link]
 Figure 6.1 Thomas-Kilmann Conflict Mode Instrument
Competing (forcing) is assertive and uncooperative. It is a power-oriented mode. An individual pursues his or her own concerns at
the other person’s expense, using whatever power seems appropriate to win his or her position.
Collaborating is both assertive and cooperative. An individual attempts to work with the other person to find a solution that fully
satisfies the concerns of both. It involves digging into an issue to identify the underlying concerns of the two individuals and to find
an alternative that meets both sets of concerns.
Compromising is intermediate in both assertiveness and cooperativeness. The objective is to find an expedient, mutually
acceptable solution that partially satisfies both parties. Compromising might mean splitting the difference, exchanging concessions,
or seeking a quick middle-ground position.
Avoiding is unassertive and uncooperative. When avoiding, an individual does not immediately pursue his or her own concerns or
those of the other person. He or she does not address the conflict. Avoiding might take the form of diplomatically sidestepping an
issue, postponing an issue until a better time, or simply withdrawing from a threatening situation.
Accommodating is unassertive and cooperative, which is the opposite of competing. An individual neglects his or her own
concerns to satisfy the concerns of the other person. Therefore, there is an element of self-sacrifice in this mode.
Each of these approaches can be effective and useful depending on the situation. Project managers will use each of these conflict
resolution approaches depending on the project manager’s personal approach and an assessment of the situation. Most project
managers have a default approach that has emerged over time and is comfortable. For example, some project managers find the use
of the project manager’s power the easiest and quickest way to resolve problems. “Do it because I said so” is the mantra for project
managers who use competing as the default approach to resolve conflict. The competing approach often succeeds in a situation
where a quick resolution is needed, and the investment in the decision by the parties involved is low. Some project managers find
accommodating with the client the most effective approach to dealing with client conflict.
Two examples have been provided below in order to elaborate on the conflict resolution methods in projects.
Resolving an Office Space Conflict [5]

6.5.4 [Link]
Two senior managers both want the office with the window. The project manager intercedes with little discussion and assigns the
window office to the manager with the most seniority. The situation was a low-level conflict with no long-range consequences for
the project and a solution all parties could accept. Therefore, the project manager applied the competing (forcing) method.
Sometimes office size and location are culturally important, and this situation would take more investment to resolve.
Conflict Over a Change Order [6]
In another example, the client rejected a request for a change order because she thought the change should have been foreseen by
the project team and incorporated into the original scope of work. The project controls manager believed the client was using her
power to avoid an expensive change order and suggested the project team refuse to do the work without a change order from the
client. This is a more complex situation, with personal commitments to each side of the conflict and consequences for the project.
The project manager needs a conflict resolution approach that increases the likelihood of a mutually acceptable solution for the
project.
One conflict resolution approach involves evaluating the situation, developing a common understanding of the problem, developing
alternative solutions, and mutually selecting a solution. Evaluating the situation typically includes gathering data. In this example,
gathering data would include a review of the original scope of work and possibly of people’s understandings, which might go
beyond the written scope.
The second step in developing a resolution to the conflict is to restate, paraphrase, and reframe the problem behind the conflict to
develop a common understanding of the problem. In our example, the common understanding may explore the change management
process and determine that the current change management process may not achieve the client’s goal of minimizing project
changes. This phase is often the most difficult and may take an investment of time and energy to develop a common understanding
of the problem.
After the problem has been restated and agreed on, alternative approaches are developed. This is a creative process that often
means developing a new approach or changing the project plan. The result is a resolution to the conflict that is mutually agreeable
to all team members. If all team members believe every effort was made to find a solution that achieved the project charter and met
as many of the team member’s goals as possible, there will be a greater commitment to the agreed-on solution.

6.4.4 Trust
Building trust in a project begins with the project manager. On complex projects, the assignment of a project manager with a high
trust reputation can help establish the trust level needed. The project manager can also establish the cost of lying in a way that
communicates an expectation and a value for trust in the project. Project managers can also assure that the official goals (stated
goals) and operational goals (goals that are reinforced) are aligned. The project manager can create an atmosphere where informal
communication is expected and reinforced.
Informal communication is important to establishing personal trust among team members and with the client and other
stakeholders. Allotting time during project start-up meetings to allow team members to develop a personal relationship is important
to establishing team trust. The informal discussion allows for a deeper understanding of the whole person and creates an
atmosphere where trust can emerge.
Small events that reduce trust often take place on a project without anyone remembering what happened to create an environment
of distrust. Taking fast and decisive action to establish a high cost of lying, communicating the expectation of honesty, and creating
an atmosphere of trust are critical steps a project manager can take to ensure the success of complex projects.
Project managers can also establish expectations of team members to respect individual differences and skills, look and react to the
positives, recognize each other’s accomplishments, and value people’s self-esteem to increase a sense of benevolent intent.

6.4.5 Emotional Intelligence (EQ)

Emotions are neither positive nor negative. Emotions are both a mental and physiological response to environmental and internal
stimuli. Project managers need to understand and value their emotions to appropriately respond to the client, project team,
stakeholders, and project environment. Daniel Goleman (Goleman, 1995) discussed emotional intelligence quotient (EQ) as a
factor more important than IQ in predicting leadership success[7]. Emotional intelligence is the ability to sense, understand, and
effectively apply the power and acumens of emotions as a source of human energy, information, connection, and influence (Cooper
and Sawaf, 1997)[8].
Emotional intelligence includes the following:

6.5.5 [Link]
 Self-awareness
Self-regulation
Empathy
Relationship management
Emotions are important to generating energy around a concept, building commitment to goals, and developing high-performing
teams. Emotional intelligence is an important part of the project manager’s ability to build trust among the team members and with
the client. It is an important factor in establishing credibility and open dialogue with project stakeholders. Emotional intelligence is
a critical ability for project managers, and the more complex the project profile, the more important the project manager’s EQ
becomes to project success.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Retrieved from the OER titled “Principles of Management” on [Link]
the-nature-of-leadership↵
3. Retrieved from the OER titled “Project Management” by Adrienne Watt on
[Link]
4. Thomas, K. W. (2008). Thomas-Kilman conflict mode. TKI Profile and Interpretive Report, 1-11. ↵
5. Retrieved from the OER titled “Project Management” by Adrienne Watt on
[Link]
6. Retrieved from the OER titled “Project Management” by Adrienne Watt on
[Link]
7. Goleman, D. (1996). Emotional intelligence. Why it can matter more than IQ. Learning, 24(6), 49-50. ↵
8. Cooper, R. K., & Sawaf, A. C. (1997). Executive EQ: Emotional intelligence in leadership and organization (No. 658.409
C7841c Ej. 1 000003). ↵

This page titled 6.5: Leadership Skills is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

6.5.6 [Link]
6.6: Leadership Styles and Servant Leadership
Leadership is a function of both the personal characteristics of the leader and the environment in which the leadership must occur.
Several researchers have attempted to understand leadership from the perspective of the characteristics of the leader and the
environment of the situation. These researchers described leaders as either autocratic or democratic (Tannenbaum & Schmidt,
1958)[1], as pathfinders (visionaries), problem solvers (analytical), or implementers (team-oriented) (Leavitt, 1986)[2], and as either
transactional (focused on actions and decisions) or transformational (focused on the long-term needs of the group and organization)
(Burns, 1978)[3].
Fred Fiedler introduced contingency theory and the ability of leaders to adapt their leadership approach to the environment (Fiedler,
1971)[4]. Most leaders have a dominant leadership style that is most comfortable. For example, most engineers spend years training
in analytical problem solving and often develop an analytical approach to leadership. A leadership style reflects personal
characteristics and life experiences. Although a project manager’s leadership style may be predominantly a pathfinder (using
Leavitt’s taxonomy), most project managers become problem solvers or implementers when they perceive the need for these
leadership approaches. The leadership approach incorporates the dominant leadership style and Fiedler’s contingency focus on
adapting to the project environment.
PMBOK Guide 6th Edition provides a list of leadership styles as below:
1. Laissez-faire: Leaders allow the team to make their own decisions and establish their own goals. It is also referred to as taking a
hands-off style.
2. Transactional: Leaders focus on goals, feedback, and accomplishment to determine rewards.
3. Servant: Leaders demonstrate a commitment to serve and put other people first. They focus on other people’s growth, learning,
development, autonomy, and well-being. They concentrate on relationships, community, and collaboration.
4. Transformational: Leaders empower followers through idealized attributes and behaviors, inspirational motivation,
encouragement for innovation and creativity, and individual consideration.
5. Charismatic: Leaders are able to inspire with high energy. They are enthusiastic and self-confident and hold strong convictions.
6. Interactional: This leadership style is a combination of transactional, transformational, and charismatic leadership styles.
Among them, the “Agile Practice Guide” accompanying PMBOK Guide Sixth Edition highlights the servant leadership style in
particular for the agile project management approach. Although servant leadership isn’t unique to agile, project managers and
organizations can observe and experience that this leadership style integrates into the agile mindset value. As the name refers,
servant leaders serve those on the team by promoting self-awareness, listening, helping team members and stakeholders improve
themselves, coaching rather than controlling, facilitating coordination, removing obstacles and organizational impediments in front
of the team, the members, and the project, promoting safety, respect, and trust, and promoting the energy and intelligence of
others[5]. We will discuss this leadership style more in Chapter 12 “Agile Project Management”.
No particular leadership approach is specifically appropriate for managing a project. Each project has a unique set of circumstances
because, by definition, projects are unique endeavors. The leadership approach and the management skills required to be successful
vary depending on the complexity profile of the project. The Project Management Institute published research that studied project
management leadership skills and concluded that project managers needed good communication skills and the ability to build
harmonious relationships and motivate others (Shi & Chen, 2006)[6]. Beyond this broad set of leadership skills, the successful
leadership approach will depend on the profile of the project.
A transactional project manager with a strong command and control leadership approach may be very successful on a small
software development project or a construction project, where tasks are clear, roles are well understood, and the project
environment is cohesive. This same project manager is less likely to be successful on a larger, more complex project with a diverse
project team and complicated work processes.
Each project phase may also require a different leadership approach. During the start-up phase of a project, when new team
members are first assigned to the project, the project may require a command and control leadership approach. Later, as the project
moves into the conceptual development phase, creativity becomes important, and the project management takes on a more
transformational type leadership approach. Most experienced project managers can adjust their leadership approach to the needs of
the project phase. Occasionally, on very large, complex projects, some companies will change project managers after the
conceptual phase of the project to bring in a different project leadership approach or change project managers to manage the
closeout of a project. Changing project managers may bring the right level of experience and the appropriate leadership approach

6.6.1 [Link]
but is also disruptive to a project. Senior management must balance the benefit of matching the right leadership approach with the
cost of disrupting the project.

1. Tannenbaum, R., & Schmidt, W. (1958). How to Choose a Leadership Pattern. Harvard Business Review 36, 95–101. ↵
2. Leavitt, H. (1986). Corporate Pathfinders. New York: Dow-Jones-Irwin and Penguin Books. ↵
3. Burns, J.M. (1978). Leadership. New York: Harper & Row. ↵
4. Fiedler, F.E. (1971). Validation and Extension of the Contingency Model of Leadership Effectiveness. Psychological Bulletin,
76(2), 128–48. ↵
5. Project Management Institute, & Agile Alliance. (2017). Agile practice guide. ↵
6. Shi, Q., & Chen, J. (2006). The Human Side of Project Management: Leadership Skills. Newtown Square, PA: Project
Management Institute, Inc. ↵

This page titled 6.6: Leadership Styles and Servant Leadership is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or
curated by Abdullah Oguz (MSL Academic Endeavors) .

6.6.2 [Link]
6.7: Creating a Project Culture
Project managers have a unique opportunity during the start-up of a project. They create a project culture, something organizational
managers seldom have a chance to do. In most organizations, the corporate or organizational culture has developed over the life of
the organization, and people associated with the organization understand what is valued, and what behaviors are expected. Edgar
Schein defined culture as a pattern of basic assumptions formed by a group on how to perceive and address problems associated
with both internal adaptation and external integration (Schein, 1990)[1]. While organizational culture constrains, stabilizes, and
provides structure to the organization, it is being constantly enacted, created, and shaped by leadership behavior.
A project culture represents the shared norms, beliefs, values, and assumptions of the project team. Understanding the unique
aspects of a project culture and developing an appropriate culture to match the project are important project management abilities.
Culture is developed through the communication of the priority, the given status, and the alignment of official and operational
rules. Official rules are the rules that are stated, and operational rules are the rules that are enforced. Project managers who align
official and operational rules are more effective in developing a clear and strong project culture because the project rules are among
the first aspects of the project culture to which team members are exposed when assigned to the project. In addition to official and
operational rules, the project leadership can communicate what is important by the use of symbols, storytelling, rituals, rewards or
punishments, and taboos.
6.6.1 Operational Rules on a Project in India [2]
During the initiation of a project in India, members of the project team were given a policy that stated all travel expense claims
must be submitted within three days of completion of travel. During the first few weeks, the administrative team began to
understand that this was a difficult policy to enforce without creating moral problems on the project. Instead of changing the
official rule, it was seldom enforced. The official rules and operational rules differed.
Later in the project, a worker was injured after crossing an area that was marked as unsafe. Workers indicated that they knew the
official rules but it took too much time to go around the unsafe area. They assumed that official rules could be ignored if they were
difficult to obey. The difference between official rules and operational rules of the project created a culture that made the
communication of the priorities more difficult.
6.6.2 Creating a Culture of Safety [3]
A project manager in South America who wanted to create a strong safety culture on a construction project with significant safety
concerns used several methods to create the desired culture. The very first meeting that project team members attended was a safety
orientation. Members were issued a card—a symbol—after the meeting granting permission to participate in the project. The
project leadership team told stories of previous projects where people were fired for breaking safety rules and often warned that the
fastest way to get fired on the project was to break a safety rule—an example of storytelling. Every project meeting started with a
discussion of a safety topic—a ritual—and any discussion of lessening the safety rules was forbidden—taboo—and was quickly
and strongly cut off by the project leadership if it occurred.
As can be seen in both examples above, culture guides behavior and communicates what is important and is useful for establishing
priorities. On projects that have a strong safety culture, team members feel free to challenge anyone who breaks a safety rule, even
managers. The safety aspects of culture are stronger than the cultural aspects of the power of management.

6.6.3 Culture of Stakeholders

When project stakeholders do not share a common culture, project management must adapt its organizations and work processes to
cope with cultural differences. Three major aspects of cultural difference that can affect a project are communications, negotiations,
and decision-making. Communication is perhaps the most visible manifestation of culture. Project managers encounter cultural
differences in communication in language, context, and candor. Language is clearly the highest barrier to communication. When
project stakeholders do not share the same language, communication slows down and is often filtered to share only information that
is deemed critical. The barrier to communication can influence project execution where quick and accurate exchange of ideas and
information is critical. The interpretation of information reflects the extent that context and candor influence cultural expressions of
ideas and understanding of information. In some cultures, an affirmative answer to a question does not always mean yes. The
cultural influence can create confusion on a project where project stakeholders share more than one culture. It is of high importance
to keep in mind that not all cultural differences are related to international projects. Corporate cultures and even regional
differences can create cultural confusion on a project.

6.7.1 [Link]
6.6.4 Culture Affects Communication in Mumbai [4]
A project management consultant from the United States was asked to evaluate the effectiveness of a U.S. project management
team executing a project in Mumbai, India. The project team reported that the project was on schedule and within budget. After a
project review meeting where each of the engineering leads reported that the design of the project was on schedule, the consultant
began informal discussions with individual engineers and began to discover that several critical aspects of the project were behind
schedule, and without a mitigating strategy, the project would miss a critical window in the weather between monsoon seasons. The
information on the project flowed through a cultural expectation to provide positive information. The project was eventually
canceled by the U.S.-based corporation when the market and political risks increased.

1. Schein, E. H. (1990). Organizational culture (Vol. 45, No. 2, p. 109). American Psychological Association. ↵
2. Retrieved from the OER titled “Principles of Management” on [Link]
the-nature-of-leadership↵
3. Retrieved from the OER titled “Principles of Management” on [Link]
the-nature-of-leadership↵
4. Retrieved from the OER titled “Project Management from Simple to Complex” on
[Link]

This page titled 6.7: Creating a Project Culture is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

6.7.2 [Link]
6.8: Developing and Managing a Project Team
A team is “a group of individuals who interact interdependently and who are brought together or come together voluntarily to
achieve certain outcomes or accomplish particular tasks” (Berry, 2011, p.136)[1]. Teams are utilized in organizations to establish
novel combinations of people who would work on unique problems and generate critical decisions as outcomes (Gersick, 1988)[2].
Much of the work that is performed today in organizations requires a focus on teamwork. The ability to work successfully as a
team member, as well as the ability to lead teams, is an ultimate advantage within the workforce. Teams themselves must be
managed, in addition to managing just the individuals, to be successful. We’ve all heard the quote originally coined by Aristotle
that states that “the whole is greater than the sum of its parts.” This captures the nature of the team perfectly—there is such a
synergy that comes from a team that the individuals alone are not able to create.
A team is a collaboration of people with different personalities that is led by a person with a favored leadership style. Managing the
interactions of these personalities and styles as a group is an important aspect of project management. The project team is made up
of people dedicated to the project. These people, team members, are generally borrowed from other departmental units in an
organization or are recruited from outside the organization. They may work full-time, part-time, or in some of the activities when
their skills are needed. As discussed in Chapter 3 “Project Initiation”, the formal organizational structure would have a substantial
impact on how project teams are created and managed. In a functional organization, project managers may have low authority and
control over the resources and budget. Besides, they may not work full time as a project manager as they may still carry out the
routine tasks of their functional unit. The main advantage of a functional organization type is that the project manager can acquire
qualified and experienced human resources from other functional departments. In a strong matrix organization type, a Project
Management Office (PMO) or a designated program management office is added besides functional departments. This department
employs full-time project managers with a designated job role. They manage the project budget, and their authority becomes
moderate to high. They can also have a full-time administrative staff. This organizational structure may be preferred by many
project managers since they can still acquire qualified and experienced team members from functional departments inside the
organization. Among functional, weak matrix, strong matrix, and project-oriented organization types, a strong matrix structure may
suggest more opportunities for a project manager. However, it is of high importance for a project manager to keep in mind and
consider various internal and external factors as well as organizational politics.
In particular, in the functional, weak matrix, and balanced matrix organization types, there may be some difficulties for project
managers while dealing with project team members. Since these members are borrowed from other units, they may work at the
project less than 100% of their working time, and project managers may not be their direct supervisors. Their priorities may be
elsewhere. Thus, their dedication to the project objectives and activities couldn’t reach the level project managers expect from them
to accomplish their tasks and responsibilities as desired. They may be juggling more than one project as well as their full-time job
and have difficulty meeting deadlines.
Project managers need to provide leadership, direction, and above all, support to team members as they go about accomplishing
their tasks. Working closely with the team to solve problems can help project managers learn from the team and build rapport. As
some of them have been explained above in the “Leadership Skills” section, managing project team members requires interpersonal
skills. Here are some suggestions that can help with more effective team management:
Involve team members in project planning.
Arrange to meet privately and informally with each team member at several points in the project, perhaps for lunch or coffee.
Be available to hear team members’ concerns at any time.
Encourage team members to pitch in and help others when needed.
Complete a project performance review for team members.

6.7.1 Team Development Stages

One of the models used to describe team development is the Tuckman ladder. According to Tuckman (1965), small groups go
through four stages of development which are forming, storming, norming, and performing[3]. As a result of a literature review of
fifty-five articles, Tuckman (1965) proposed a model of developmental stages for group settings over time. In respect to the group
structure, he labeled these stages as (1) testing and dependence, (2) intragroup conflict, (3) development of group cohesion, and (4)
functional role relatedness. Accordingly, he labeled the stages of task activity as (1) orientation to task, (2) emotional response to
task demands, (3) open exchange of relevant interpretations, and (4) emergence of solutions. An essential correspondence between
the perspectives of group structure and task activity caused Tuckman to summarize the group stages as “forming,” “storming,”

6.8.1 [Link]
“norming,” and “performing.” These four stages covered both group interpersonal and task activities. Tuckman and Jensen (1977)
added the fifth stage as adjourning after they reviewed twenty-two studies[4].
The first stage, forming, is characterized by orientation to the group setting, testing the boundaries of interpersonal and task
behaviors of other members, and a dependency relationship with the leader. The storming stage following the forming stage is
characterized by conflict and polarization around interpersonal issues, with concomitant emotional responses in the task sphere.
These behaviors with hidden agendas and prejudices serve as resistance to group influence and task requirements. In the third
stage, norming, resistance to authority is overcome, in-group feeling and cohesiveness develop, new standards evolve, and new
roles are adopted. In the performing stage, group energy is channeled into the task after the structural issues are resolved and the
structure becomes supportive of task performance. The last stage, adjourning, indicates the completion of the project where groups
disband, and team members are reassigned to other projects or tasks.
Although these classic stages in group development may not be apparent for all groups, and not all groups may follow them, they
would be useful for predicting team performance (Mannix and Jehn, 2004) as well as conflicts and harassment cases within an
organized framework[5]. Besides, not all the teams could experience all stages and they may spend different times in stages (Ayoko
et al., 2012)[6]. Some teams may also face challenges in the transition process from one stage to another, such as moving toward the
norming stage from the storming stage. Nevertheless, all teams can find themselves in the performing stage while some of them
would spend substantially longer times which could lead them to a higher achievement rating in the end. Johnson et al. (2002)
proposed an iterative group development model based on Tuckman’s model[7]. In their model based on student virtual learning
teams, there was no evidence of the storming stage for all student teams due to rapid movement between each stage given the
limited time in accomplishing assignments. Thus, teams moved along forming, norming, and performing stages and they resolved
the conflict when it arose among team members. After the conflict was resolved, teams continued the process of forming, norming,
and performing.

6.7.2 Virtual Teams

Advances in ICTs have enabled the creation and utilization of virtual teams (VTs) within organizations in the last three decades
(Alsharo et al., 2017)[8]. The advent of the Internet accompanied by various ICTs, and the emergence of the COVID-19 pandemic
by the end of 2019 accelerated the process of digitalization for people, organizations, and governments. Thus, the adoption and
spread of ICTs worldwide across organizations and countries increased exponentially. The utilization of global virtual teams in
organizations increased to unprecedented levels. 94% of the respondents of CultureWizard’s Global Virtual Work Survey indicated
that they want to continue working from home—at least part time[9]. These advances ensured the organizations to design their
teams composed of members from different geographic locations and organizations virtually beyond a setting of the same location
(Berry, 2011)[10]. Nevertheless, even though ICTs are prerequisites of VTs, other factors were also prominent in the process of
shifting from traditional face-to-face teams to VTs. Some of these factors could be listed as increased use of horizontal
organizational structure, the emergence of environments that require inter-organizational cooperation, continued shift from
production to service and knowledge-intense work environments, and increasing globalization of trade and corporate activity
(Townsend et al., 1998)[11].
Virtual interactions and virtual teams cannot be considered identical concepts. Virtual interactions also occur in collocated teams
extensively, such as the widespread exchange of emails in the same office (Berry, 2011). A VT can be distinguished from a face-to-
face team in terms of several factors. The most prominent factor would be the use of ICTs as the primary communication and
collaboration media. Taking into consideration the utilization of ICTs, VT members are less likely to observe physical behaviors
(e.g., gestures and intonation), which face-to-face team members rely upon to establish and sustain trust (Alsharo et al., 2017)[12].
Virtual teams have various benefits such as task, resource and schedule flexibility, access to and bringing specialized skills and
diverse experiences together in a relatively short time, enhanced knowledge sharing and repository, easier documentation of
performance outcomes, and opportunities for accelerated problem solving and solution finding (Jimenez et al., 2017)[13]. Virtual
teams employ experts who have acquired more flexibility in temporal and spatial aspects since they save time by not traveling to
meet their teammates. These time and cost-saving effects and flexible work schedule benefits are also commonly observed for the
teleworkers who work outside of the office by means of virtual communication tools such as teleconferences, videoconferences,
and intranets with remote log-in (Coenen and Kok, 2014)[14]. The ability to bridge time and space provides the team with the
capability to respond and adjust to new tasks more rapidly, and human resources can be distributed more efficiently without
physical relocation of employees thus leading to better utilization of human resources. Although flexibility is assumed to generate
positive outcomes, it may cause inherent obstacles for virtual teams. The lack of shared work history among team members as well
as less face-to-face interaction could bring about trust issues in virtual teams (Coenen and Kok, 2014).

6.8.2 [Link]
While virtual teams can be confined to a region in a country or the entire country, they can extend beyond national and continental
borders when members of VTs work and live in different countries (Pinjani and Palvia, 2013)[15]. One of the advantages of
flexibility in Global Virtual Teams (GVTs) is easier access to skilled experts all around the world. This ensures the availability of
resources in other parts of the world when scarcity exists in the organization’s or project’s geographical area. The dispersed
structure of GVT members around the globe allows a 24-hour relay workflow (Carmel et al., 2010)[16]. For instance, members
located in Asia and Australia can work on the project during their business hours. They can pass the work on to their colleagues in
Europe and Africa for further processing, and then, they can pass it on to the colleagues in the Americas, who can work on it while
their more eastern team members are asleep. This follow-the-sun approach creates a cycle of work through which GVT members
pass the work on to the members in Asia and Australia, where 24-hour relay starts again (Carmel et al., 2010).
Despite the unprecedented benefits mostly owing to the developments in ICTs, the virtual nature of these teams is not immune to
the challenges to effective collaboration and team outcomes (Alsharo et al., 2017). One of the essential challenges in virtual work is
the elimination of face-to-face meetings that would otherwise help team members build interpersonal relationships (Cummings and
Dennis, 2018)[17]. Lack of first impressions of other team members might have a substantial impact on the formation and
functioning of the team, and the outcome of the teamwork. Cummings and Dennis (2018) contended that virtual team members
examine each other’s profiles on enterprise social networking sites to get acquainted with them, otherwise not possible in a
dispersed team. Some of the problems that GVTs and their members might encounter can be enumerated as lack of trust, language
and time barriers, cultural differences, lack of onsite monitoring, lack of tone and body language, and different interpretations by
the members due to the lack of cues. Eventually, if these likely challenges are not addressed by the GVT leaders and upper
hierarchical levels in the organization, virtual teams may cause disadvantages to the team members’ well-being and job
satisfaction, and team performance.
Team diversity or heterogeneity might have either a positive or negative impact on a team’s performance. Although team diversity
could exacerbate the conflict and emotional reactions in GVTs (Ayoko et al., 2012)[18], and team members can build higher trust
and cohesiveness in homogeneous teams (Drescher and Garbers, 2016)[19], team diversity, on the contrary, could improve GVT
effectiveness (Jimenez et al., 2017). The diverse backgrounds of team members could provide representation and exchange of
different opinions and perspectives within the team. Hence, this process can create value by providing a more extensive range of
information sources and thus aiding creativity and problem solving, and a higher level of organizational learning and synergy
(Berry, 2011; Jimenez et al., 2017).
CultureWizard’s Global Virtual Work Survey pointed to complications in global virtual teams such as difficulty in building
relationships (37%), managing conflict (33%), and lack of responsiveness from team members (20%). The survey also highlighted
an issue with the technology as it cannot completely erase the barriers of miscommunication. The survey indicated that 75% of
respondents use webcams to compensate for lack of face-to-face contact, but webcams come with their complications, such as
ambient noise, feeling pressure to look attentive and professional on camera, and technical issues such as insufficient bandwidth or
difficulty in operating new software.

1. Berry, G. R. (2011). Enhancing effectiveness on virtual teams: Understanding why traditional team skills are insufficient. The
Journal of Business Communication (1973), 48(2), 186-206. ↵
2. Gersick, C. J. (1988). Time and transition in work teams: Toward a new model of group development. Academy of
Management Journal, 31(1), 9-41. ↵
3. Tuckman, B. W. (1965). Developmental sequence in small groups. Psychological Bulletin, 63(6), 384. ↵
4. Tuckman, B. W., & Jensen, M. A. C. (1977). Stages of small-group development revisited. Group & Organization Studies, 2(4),
419-427. ↵
5. Mannix, E., & Jehn, K. A. (2004). Let’s norm and storm, but not right now: Integrating models of group development and
performance. In Time in groups (pp. 11-37). Emerald Group Publishing Limited. ↵
6. Ayoko, O. B., Konrad, A. M., & Boyle, M. V. (2012). Online work: Managing conflict and emotions for performance in virtual
teams. European Management Journal, 30(2), 156-174. ↵
7. Johnson, S. D., Suriya, C., Yoon, S. W., Berrett, J. V., & La Fleur, J. (2002). Team development and group processes of virtual
learning teams. Computers & Education, 39(4), 379-393. ↵
8. Alsharo, M., Gregg, D., & Ramirez, R. (2017). Virtual team effectiveness: The role of knowledge sharing and trust. Information
& Management, 54(4), 479-490. ↵
9. Culture Wizard. 2020 Trends in Global Virtual Work: Metamorphosis of the Global Workplace. 2020. [Link]
[Link]/virtual-teams-exec-report-2020 ↵

6.8.3 [Link]
10. Berry, G. R. (2011). Enhancing effectiveness on virtual teams: Understanding why traditional team skills are insufficient. The
Journal of Business Communication (1973), 48(2), 186-206. ↵
11. Townsend, A. M., DeMarie, S. M., & Hendrickson, A. R. (1998). Virtual teams: Technology and the workplace of the future.
Academy of Management Perspectives, 12(3), 17-29. ↵
12. Alsharo, M., Gregg, D., & Ramirez, R. (2017). Virtual team effectiveness: The role of knowledge sharing and trust. Information
& Management, 54(4), 479-490. ↵
13. Jimenez, A., Boehe, D. M., Taras, V., & Caprar, D. V. (2017). Working across boundaries: current and future perspectives on
global virtual teams. Journal of International Management, 23(4), 341-349. ↵
14. Coenen, M., & Kok, R. A. (2014). Workplace flexibility and new product development performance: The role of telework and
flexible work schedules. European Management Journal, 32(4), 564-576. ↵
15. Pinjani, P., & Palvia, P. (2013). Trust and knowledge sharing in diverse global virtual teams. Information & Management, 50(4),
144-153. ↵
16. Carmel, E., Espinosa, J. A., & Dubinsky, Y. (2010). " Follow the Sun" Workflow in Global Software Development. Journal of
Management Information Systems, 27(1), 17-38. ↵
17. Cummings, J., & Dennis, A. (2018). Virtual First Impressions Matter: The Effect of Enterprise Social Networking Sites on
Impression Formation in Virtual Teams. MIS Quarterly, 42(3), 697-717. ↵
18. Ayoko, O. B., Konrad, A. M., & Boyle, M. V. (2012). Online work: Managing conflict and emotions for performance in virtual
teams. European Management Journal, 30(2), 156-174. ↵
19. Drescher, G., & Garbers, Y. (2016). Shared leadership and commonality: A policy-capturing study. The Leadership Quarterly,
27(2), 200-217. ↵

This page titled 6.8: Developing and Managing a Project Team is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or
curated by Abdullah Oguz (MSL Academic Endeavors) .

6.8.4 [Link]
6.9: Key Takeaways
Key Takeaways
Project managers spend 90% of their time communicating with team members and stakeholders.
ICTs (Information and Communication Technologies) can facilitate faster and better communication, or they can become a
barrier if they are not well understood and applied appropriately.
The communication management plan documents the types of information needs the stakeholders have, when the information
should be distributed, how the information will be delivered with which frequency, who will receive it, and the format and
technologies we will use to communicate.
If all the parties to the communication are taking part in the exchange at the same time, the communication is synchronous.
Many types of communication do not require that the parties are present at the same time. This type of communication is
asynchronous.
PMBOK Guide Sixth Edition differentiates among three skill sets project managers should possess – technical project
management, leadership, and strategic and business management.
Working with other people involves dealing with them both logically and emotionally.
Active listening is placing oneself in the speaker’s position as much as possible, understanding the communication from the
point of view of the speaker, listening to the body language and other environmental cues, and striving not just to hear, but to
understand.
Negotiation is a process for developing a mutually acceptable outcome when the desired outcome for each party conflicts.
Thomas-Kilmann Conflict Mode Instrument (TKI) defines five methods of dealing with conflict on a scale of assertiveness and
cooperativeness: (1) Competing, (2) Collaborating, (3) Compromising, (4) Avoiding, and (5) Accommodating.
Emotional intelligence is an important part of the project manager’s ability to build trust among the team members and with the
client. It is an important factor in establishing credibility and open dialogue with project stakeholders.
Servant leaders serve by promoting self-awareness, listening, helping team members and stakeholders improve themselves,
coaching rather than controlling, facilitating coordination, removing obstacles and organizational impediments in front of the
team, the members, and the project, and promoting the energy and intelligence of others.
Project culture is developed by communicating priority, status, and the alignment of official and operational rules. It is enforced
through the use of symbols, storytelling, rituals, rewards or punishments, and taboos.
A team is a collaboration of people with different personalities that is led by a person with a favored leadership style. Managing
the interactions of these personalities and styles as a group is an important aspect of project management.
According to the Tuckman Ladder, teams pass through five stages – forming, storming, norming, performing, and adjourning.
One of the essential challenges in virtual work is the elimination of face-to-face meetings that would otherwise help team
members build interpersonal relationships.

This page titled 6.9: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

6.9.1 [Link]
6.10: Questions and Exercises
There are 6 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 6.10: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

6.10.1 [Link]
6.11: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 6.11: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

6.11.1 [Link]
 CHAPTER OVERVIEW

7: Scheduling
7.1: Learning Objectives and Overview
7.2: Project Schedule Management Plan
7.3: Defining Activities
7.4: Estimating Activity Durations
7.5: Creating an Activity Network Diagram
7.6: Creating a Gantt Chart
7.7: Microsoft Project Tutorial
7.8: Key Takeaways
7.9: Questions and Exercises
7.10: Attribution

This page titled 7: Scheduling is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

1
7.1: Learning Objectives and Overview
Learning Objectives
1. Describe the process to create a project schedule.
2. Define activities based on Work Breakdown Structure (WBS).
3. Describe how activities can be sequenced.
4. Elaborate on the techniques to estimate activity duration.
5. Create a network diagram by identifying the early start and early finish times, late start and late finish times, floats (slacks), and
the critical path.
6. Practice on Microsoft Project to create a Gantt Chart and an Activity Network Diagram.

Overview
The project schedule is one of the triple project constraints besides scope and cost (budget). A project manager is responsible for
planning, developing, managing, monitoring, and controlling the project schedule to ensure that project objectives can be achieved,
and project outcomes can be delivered to the client and customers on time. Effective schedule management is integral to overall
project success. The objective is to create a schedule that effectively and efficiently uses allocated resources to complete the project
in the shortest amount of time possible. In order to develop a schedule, we first need to create a plan that will guide us during the
project. Afterward, we should define the activities based on the WBS, sequence them in the right order, estimate the time it will
take to complete these activities, and develop a schedule by creating a network diagram and Gantt chart.

This page titled 7.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

7.1.1 [Link]
7.2: Project Schedule Management Plan
As described in Chapter 4, project planning is at the heart of the project life cycle and tells everyone involved where we are going
and how we are going to get there. It involves creating a set of plans to help guide our team through the implementation and closure
phases of the project. The project schedule management plan is one of the sub-plans of our overall project plan. It provides the
guidelines to project managers on how to develop a project schedule by defining and sequencing project activities and milestones,
and by estimating activity durations. It is the process of establishing the policies, procedures, and documentation for planning,
developing, managing, executing, and controlling the project schedule[1].
A project schedule management plan can consist of the following:
Unit of measurement
Work hours, days, weeks, months
Daily working hours and shifts
Weekends and/or off-days
Local, national, and federal holidays
Creation of the activity list and attributes
Describe how activities and their attributes will be defined, and who will be involved in this process.
Level of accuracy
Acceptable range to ensure realistic activity duration estimates
Evaluation of the impact of risks on the overall project duration and each individual activity durations based on the project
risk management plan
Methods describing how the schedule contingencies will be assessed.
Activity duration estimates
Estimation methods (e.g., analogous, parametric, three-point, bottom-up)
Methods, tools, and software utilized to develop, manage, and monitor project schedule
Specify the organization’s procedures, policies, and resource calendars if they should be utilized.
Methods and tools such as Gantt Chart, WBS, project baseline, master and milestone schedule, Earned Value Management,
and critical path method
Software such as Microsoft Project Professional, Excel, Visio, and Jira (for Kanban and Scrum), and online collaboration
tools such as Monday, Trello, and Basecamp.
Rules and concepts to sequence activities and create an activity network diagram
Critical path method (Forward pass, backward pass, slacks)
Critical chain method
Predecessor dependencies (e.g., finish-to-start, start-to-start)
Rules for monitoring schedule performance
Earned Value Management (EVM)
Control thresholds for deviations from the parameters in the schedule baseline
Using software such as Microsoft Project
Reporting formats
Reporting formats and frequency should be in alignment with other project plans.
Approval of the schedule baseline
Who will be responsible for preparation and control?
Who will approve the schedule baseline?

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

7.2.1 [Link]
This page titled 7.2: Project Schedule Management Plan is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

7.2.2 [Link]
7.3: Defining Activities
In line with the project schedule management plan, we should start scheduling the whole project by defining activities based on the
WBS (Work Breakdown Structure). The activity definition process is a further breakdown of the work package elements of the
WBS. It documents the specific activities needed to fulfill the deliverables detailed in the WBS. These activities are not the
deliverables themselves but the individual units of work that must be completed to fulfill the deliverables. Activity definition uses
everything we already know about the project to divide the work into activities that can be estimated. We might want to look at all
the lessons learned from similar projects our organization has done to get a good idea of what you need to do on the current one.
Detailed planning begins by identifying all the tasks to be completed. The project team begins by reviewing the scope of the project
which is found in the project scope statement (predictive/waterfall projects) or the product backlog (see Chapter 12 for agile
projects). A WBS allows the team to have a visual representation of the forthcoming work. As discussed in Chapter 4, the WBS is a
powerful planning tool. By breaking the project down into smaller, more manageable components, the WBS assists project
managers in identifying the specific tasks. The team then determines how long it will take to complete the required tasks.
Expert judgment from project team members with prior experience and from stakeholders that can be consulted can help us define
activities while developing project scope statements and WBS. If we are asked to manage a project in a new domain, we could use
subject matter experts in that particular field to help define tasks so we can understand what activities are going to be involved. We
may want to create an activity list and then have the expert review it and suggest changes. Alternatively, we could involve the
experts from the very beginning. Please see “7.3: Estimating Activity Durations” for more explanation regarding expert judgment.
Sometimes we start a project without knowing a lot about the work that we will be doing later. Rolling-wave planning lets us plan
and schedules only the portion that we know enough about to plan well. When we don’t know enough about a project, we can use
placeholders for the unknown portions until we know more. These are extra items that are put at high levels in the WBS to allow us
to plan for the unknown.
When we identify activities for the work packages, we can detail the activities in a project activity list which is a list of everything
that needs to be done to complete the project, including all the activities that must be accomplished to deliver each work package
with activity attributes. This list can consist of, but is not limited to:
1. Activity identifier
2. WBS number
3. Activity title
4. Scope of Work
5. The person responsible (RACI chart can be used. See Chapter 5)
6. Related activities
1. Higher level activities (WBS number)
2. Lower level activities (WBS number)
3. Predecessors (including dependencies, that are FS, FF, SF, SS)
4. Successors (including dependencies, that are FS, FF, SF, SS)
7. Resource requirements
8. Activity location
9. Level of effort required
10. Activity assumptions
11. Activity constraints
The example in Table 7.1 is based on the project charter we developed in Chapter 3 (Case Study 3.1: Project Charter of Grocery
LLC’s Mobile-Commerce Project), and the WBS we developed in Chapter 4 (Case Study 4.1: WBS of Grocery LLC’s M-
Commerce Project). In Table 7.1, we focus on Activity 1.3 “Preparation of Project Charter” in the WBS. Under Activity 1.3, we
determined six activities that can serve as the lowest level of activities, which are work packages. That would make it possible for
us to allocate resources in Chapter 8.
Table 7.1: Activity List Template (Adapted from a template on [Link])

Activity List for Project “Grocery LLC’s M-Commerce Project”

7.3.1 [Link]
 Activity Activity title Scope of Work Person Responsible Predecessors
identifier

1.3 Preparation of Project The project charter that will Project 1.1
Charter authorize the project manager to Manager 1.2
undertake the responsibility of the 1.3
project and apply the resources to
project activities will be prepared.

1.3.1 Develop high-level The high-level scope consists of the Team 1.2
scope project purpose, measurable project Member 1
objectives, high-level requirements,
project description, boundaries, key
deliverables, and assumptions and
constraints.

1.3.2 Identify overall This includes the identification of Team 1.3.1

project risks the risks that affect the project in Member 2
general.

1.3.3 Develop high-level This includes the estimation of the Team 1.3.1
schedule overall schedule with summary Member 1
milestones.

1.3.4 Identify main This includes the initial estimation Team 1.3.3
resources and develop of all resources (human resources, Member 2
a high-level budget physical resources, and services),
and the budget.

1.3.5 Identify key Stakeholders with high-interest Team 1.3.1

stakeholders and levels and/or power levels will be Member 3 1.3.2
project team member identified.
roles The project team’s composition will
be created. The qualifications
required should be detailed.
The project sponsor’s authority will
be detailed.

1.3.6 Develop project Based on the project scope and Team 1.3.1
approval other sections of the project charter, Member 1, 1.3.2
requirements and project approval requirements and 2, 3 1.3.3
project exit criteria exit criteria should be detailed. 1.3.4
Exit criteria include the conditions 1.3.5
that describe the early termination
of the project.

We can explain each column available in Table 7.1 as below:

Activity Identifier: Once the WBS is created for the project, the list of activities required to complete each work package needs to
be developed by the project team. Each activity then needs to be assigned an Activity ID, which is placed in this column. The
activity ID serves as a reference identification number during planning, developing, and controlling the project schedule.
Activity List: The name/unique label for the activity (in brief) is placed in this column.
Scope of Work: The description of work required to be done to complete the activity is placed in this column (in as much detail as
possible).
Person Responsible: One person or more than one who will be responsible for delivering the activity must be mentioned in this
column. It is always good to have a primary and an alternate team member assigned to this responsibility.

7.3.2 [Link]
This page titled 7.3: Defining Activities is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

7.3.3 [Link]
7.4: Estimating Activity Durations
After we define the lowest level of activities in an activity list, each activity is reviewed and evaluated to determine the duration (how long it will take to accomplish from beginning
to end) and what resources (e.g., human resources, materials, facilities, and equipment) are needed. An estimate is an educated guess based on knowledge, experience, and inference
—the process of deriving conclusions based on assumptions. The accuracy of the estimate is related to the quality of the knowledge and how that knowledge is applied. The person
with the most knowledge may not be the most objective person to provide duration estimates. The person responsible for the work may also want to build in extra time. Therefore,
multiple inputs into the duration estimate and a more detailed WBS help reduce bias—the making of decisions based on a prejudged perspective.
It is of high importance here to highlight how a milestone is different from an activity. A milestone is a significant point or event in a project. Milestones have zero duration because
they represent a significant point or event. A milestone list identifies all project milestones and indicates whether the milestone is mandatory, such as those required by contract, or
optional, such as those based on historical information[1].
The unit of time used to develop the activity duration is a function of the level of detail needed by the user of the schedule. The larger and more complex the project, the greater the
need for detail, which usually translates into shorter durations for activities. However, it is common to use two types of units – one is days or weeks for activities, and hours to
display the work hours.
In this textbook, we can elaborate on five types of estimation methods:
1. Expert judgment: The project team consults domain and implementation subject matter experts who have technical knowledge and experience in the areas the project activities
are related to. If we are developing a new mobile application, we can consult software engineers, developers and testers, and systems analysts who were involved in activities to
develop other mobile applications. They can provide us with the information regarding scheduling estimates for each activity we are planning to carry out.
2. Appropriation method (Analogous estimating): Actual durations from similar projects are reviewed, and the same proportions are applied to the current project. However,
internal and external factors that affected the previous projects, and those that may affect the current project should be taken into account. Identified risks with their probability
and impact considered could have a significant influence on duration estimates for the current project.
3. Parametric estimating: In this estimation technique, we can use equations and algorithms to calculate the duration based on the resources we use and how many hours they need
to work, or how many of them we need to use. This method is quantitative. We can multiply the quantity of work to be performed by the number of hours per unit of work. If we
can estimate the amount of the work, we can divide it by the work that can be done in an hour. For example, let’s assume that, in our m-commerce project, we estimated that
software developers need to create 200 lines of code for a module. Based on the previous projects and the feedback we received from the subject matter experts, we have
estimated that a developer can finish 40 lines in an hour. Therefore, a developer needs 5 hours to finish all 200 lines. We can also add a one-hour break and two-hour review for
this task. Therefore, the total work hours amount to 8 hours which is translated to one day in our schedule. Another example can be regarding the installation of cables in an
infrastructure project. If workers can install 100 feet of cable per hour, the duration required to install 1,000 feet would be 10 hours (1,000 feet divided by 100 feet per hour). This
technique can produce higher levels of accuracy depending on the sophistication and underlying data built into the model. Parametric schedule estimates can be applied to a total
project or segments of a project, in conjunction with other estimating methods[2]. Entering data about the project into a formula, spreadsheet, or computer program produces a
duration estimate by extrapolating information from a database of actual durations from past projects.
4. Three-point estimates: Duration estimates are done based on three scenarios:
a. A realistic estimate (most likely to occur – m)
b. An optimistic estimate (best-case scenario – o)
c. A pessimistic estimate (worst-case scenario – p)
In the three-point estimation method, two distributions are possible – triangular and beta. In triangular distribution, all three duration estimates get the same weight. In a beta
distribution, the realistic estimate gets four-sixths of the weight whereas the other two estimates have one-sixth of the weight.
Triangular distribution:

Beta distribution:

Let’s estimate the duration of the “1.3 Preparation of Project Charter” sub-activities. Our team gathered together in a meeting to review and discuss alternative durations. We also
consulted subject matter experts who work in relevant departments in our organization and also external stakeholders who have an interest and/or power. Our organization and the
team had implemented software and website development projects as well as several mobile application development projects. Therefore, we have reports including information
regarding the realized durations and lessons learned. So, we can start with analogous estimating first. As we have already worked on similar projects, that would facilitate the
estimation process both for schedule and budget. We can place the historical information on the Most Likely column. Based on the expert judgment, lessons learned, and discussions
during our team meeting, we determined pessimistic and optimistic durations in Table 7.2.
Table 7.2: Estimating Activity Duration by Applying Three-Point Estimate Method

Duration Estimation (in business days)

Activity
Activity title Optimistic Most Likely Pessimistic Duration
identifier

1.3.1 Develop high-level scope 3 4 6 4.17

1.3.2 Identify overall project risks 3 5 9 5.33

1.3.3 Develop high-level schedule 4 6 10 6.33

7.4.1 [Link]
 1.3.4 Identify main resources and 1 2 5 2.33
develop a high-level budget

Identify key stakeholders

1.3.5 and project team member 5 7 12 7.50
roles

Develop project approval

requirements and project
1.3.6 3 5 9 5.33
exit
criteria

The computation of the duration for Activity 1.3.2 is shown below:

We can roll the duration estimates down or up to the nearest integral number.
5. WBS method (Bottom-up estimating): In this method, we start from the lowest level activities in the WBS – work packages. After we estimate the duration for all six activities
(Table 7.2), we can find the duration of the parent activity, 1.3 “Preparation of Project Charter”. The addition of duration for all six activities wouldn’t be an operation of adding
all numbers (4+5+6+2+8+5), which is equal to 30 days. We must consider the dependencies between the activities, which are detailed in sections numbered 7.4 and 7.5 of this
chapter. Hence, we can find 22 days for 1.3. The same bottom-up estimating is applied to the activities (1.1., 1.2, 1.3, 1.4, 1.5), and the duration for “1. Scope” is found as 35
days. “1.6 Completion of the Scope Phase” is a milestone and has a duration of zero. The overall duration for “1. Scope” is computed as 35 days as seen in Table 7.3.
Table 7.3. Schedule for Scope activities with durations rolled up in the higher levels

WBS Activity Name Duration Start Finish Predecessors

1 Scope 35 days Mon 5/2/22 Mon 6/20/22

1.1 Clarify project purpose and determine project scope 5 days Mon 5/2/22 Fri 5/6/22

1.2 Secure project sponsorship 1 day Mon 5/9/22 Mon 5/9/22 1.1

1.3 Preparation of project charter 22 days Tue 5/10/22 Wed 6/8/22

1.3.1 Develop high-level scope 4 days Tue 5/10/22 Fri 5/13/22 1.2

1.3.2 Identify overall project risks 5 days Mon 5/16/22 Fri 5/20/22 1.3.1

1.3.3 Develop high-level schedule 6 days Mon 5/16/22 Mon 5/23/22 1.3.1

1.3.4 Identify main resources and develop a high-level budget 2 days Tue 5/24/22 Wed 5/25/22 1.3.3

1.3.5 Identify key stakeholders and project team member roles Mon 5/23/22 Wed 6/1/22 1.3.1
1.3.2
8 days

1.3.6 Develop project approval requirements and project exit criteria Thu 6/2/22 Wed 6/8/22 1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
5 days

1.4 Approval of project charter by the sponsor 2 days Thu 6/9/22 Fri 6/10/22 1.3.6

1.5 Secure core resources 5 days Mon 6/13/22 Fri 6/17/22 1.4

1.6 Completion of the scope phase 0 days Mon 6/20/22 Mon 6/20/22 1.5

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute. ↵

7.4.2 [Link]
This page titled 7.4: Estimating Activity Durations is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

7.4.3 [Link]
7.5: Creating an Activity Network Diagram
After we define the activities and estimate their duration, we are ready to create an activity network diagram which is a graphical
representation of the logical relationship (i.e., dependencies) among the project activities[1]. Duration estimation can also
accompany the creation of an activity network. The process can be iterative, and the project team can move back and forth to refine
the activities, durations, and their relationships with other activities.
Activities are carried out in order. Therefore, they have predecessors and successors. They have logical relationships or
dependencies which show the sequence in which the activities are to be performed[2]. There are four relationships between
activities, which can be indicated as “Finish-to-Start” (FS), “Finish-to-Finish” (FF), “Start-to-Start” (SS), and “Start-to-Finish”
(SF). The most common relationship is Finish-to-Start at which we start a successor activity once we finish the predecessor
activity. Microsoft Project also uses FS as the default relationship. In the MS Project tutorial below, this topic has been also
discussed. A start-to-Finish relationship is very rarely used.
Showing the activities in rectangles or circles, and their relationships (dependencies) as arrows is called a precedence diagramming
method (PDM). This kind of diagram is also called an activity-on-node (AON) diagram (Figure 7.1). Another way to show how
tasks relate is with the activity-on-arrow (AOA) diagram (Figure 7.1). AOA diagram is traditionally drawn using circles as the
nodes, representing the beginning and ending points, and the arrows representing activities. AON is more commonly used and is
supported by all project management programs. In this textbook, as is also used by PMBOK Guide Sixth Edition, we are using
AON diagrams for creating activity network diagrams. Although we used circles in Figure 7.1 for AON, the most common
implementation is to use rectangles. Microsoft Project uses rectangles as well.

Figure 7.1: Activity Networks (either on Arc or Node)

7.4.1 Logical Relationships / Dependencies

As explained above, four logical relationships can be used in the precedence diagraming method while creating activity network
diagrams. Besides these relationships, we will also discuss lags and leads.
Finish-to-Start (FS) Relationship
In this relationship, a predecessor activity should be finished in order to start the successor activity. This is the most common
relationship between activities. As seen in Figure 7.2, Activity A must be finished to start Project B.

Figure 7.2: Finish-to-Start

Examples:
We need to assemble all hardware and network components of a laptop (predecessor) to install the operating system on this
laptop (successor).
We must finish cooking all our meals (predecessor) to start serving them in the dinner (successor).
We should finish packing all the luggage to start driving to the airport for the holiday.
Lag

7.5.1 [Link]
A lag is the amount of time a successor activity can be delayed with respect to a predecessor activity[3]. Consider that we should
paint one room in our house. We need to apply plaster to walls first (predecessor). When the walls dry, we can paint them
(successor). It is an FS relationship. However, we need to wait for two days for the walls to dry. This causes a two-day delay
between two activities which is called a lag (Figure 7.3).

Figure 7.3: Finish-to-Start with a Lag

Lead
A lead is the opposite of a lag. A lead is the amount of time a successor activity can be advanced with respect to a predecessor
activity[4]. In Figure 7.4, Activity B (successor) can start three days before Activity A (predecessor) finishes. For example, in the
project, we should elicit the requirements of stakeholders first. Then, we can start designing the product based on the requirements.
If we have ten stakeholder groups, and five of them are key stakeholders, we can start the design before we finish all the elicitation.

Figure 7.4: Finish-to-Start with a Lead

Finish-to-Finish (FF) Relationship
In this relationship, we cannot finish a successor activity (Activity B) if we don’t finish a predecessor activity (Activity A).
Therefore, Activity A must be finished to ensure that we can finish Activity B as well (Figure 7.5). These tasks can be carried out
in parallel. It is common to have a lag between the predecessor and successor.

Figure 7.5: Finish-to-Finish

Examples:
We are writing a new textbook, and it has 15 chapters. When we finish writing Chapter 15, we can complete the book.
The contractor is finishing the installation of gas lines and plumbing in our new house (predecessor – Activity A). Another
contractor who will install the kitchen appliances can finish the installation of these appliances (successor – Activity B) when
gas lines and plumbing are done. The second contractor will finish the installation of appliances five days after the predecessor
activity is completed. So, there is a lag of five days (Figure 7.5).
Start-to-Start (SS) Relationship
In this relationship, a successor activity (B) cannot start until we start the predecessor activity (A). Like a finish-to-finish
relationship, it is possible to see a lag between these two activities. In Figure 7.6, the relationship on the right illustrates a 5-day lag.
Activity B can start five days after Activity B starts.

7.5.2 [Link]
 Figure 7.6: Start-to-Start
Examples:
When developers start coding in a software project, testers may not need to wait until they finish all the coding. They can start
testing after the coding starts. However, they may need to wait for several hours or days to start testing since some of the coding
should be done so that the testers have an adequate number of lines to test. This delay is named “lag” as explained above and
also in the “Finish-to-Finish” relationship.
We are drafting a user manual for our product (predecessor). This manual must be also reviewed to make it ready for publishing
(successor). In order to start this review, we should start drafting the manual.
Start-to-Finish (SF) Relationship
This is the rarest relationship between project activities. Activity B (successor) cannot finish until Activity A (predecessor) activity
has started (Figure 7.7). Consider that we developed a new order processing software. In the meantime, we still need to use the
current software not to cause any interruptions in our operations. Activity A is “Shutting down the current software” while Activity
B is “Making the new software operational”. We can finish Activity B when we start Activity A.

Figure 7.7: Start-to-Finish

7.4.2 Exercise to Create an Activity Network Diagram

Our exercise to create an activity network diagram starts with Table 7.4 below. We are assuming that all the dependencies are
finish-to-start, and there are no lags or leads in this exercise. We will add other types of dependencies as well as lags and leads in
the 7.6 Microsoft Project Professional tutorial.
Table 7.4: Activities

Activity Duration (week) Predecessors

A 1 –

B 2 –

C 2 A

D 4 A

E 1 B

F 2 C, D

G 3 E

H 1 G

I 4 G

7.5.3 [Link]
 J 1 F

K 3 J, H

L 4 I

M 1 K, L

We are using rectangular nodes for each activity with labels on them. Different software programs can be utilized to create these
nodes. In this exercise, we are using Microsoft Visio. When we click “New” and search “PERT Chart” on Visio, we can select
“PERT Chart” to open a new sheet. PERT stands for “Program Evaluation Review Technique”. It was developed by Booz-Allen
and Hamilton as part of the United States Navy’s Polaris missile submarine program. PERT is a method for analyzing the tasks
involved in completing a project, especially the time needed to complete each task, the dependencies among tasks, and the
minimum time needed to complete the total project. Another method, CPM, the critical path method was developed in a joint
venture by DuPont Corporation and Remington Rand Corporation for managing plant maintenance projects. The critical path
determines the float, or schedule flexibility, for each activity by calculating the earliest start date, earliest finish date, latest start
date, and latest finish date for each activity. This will be discussed in detail in the following sections (7.4.3 and 7.4.4). Rather than
dealing with both methods separately, project managers use these methods together as they have been treated as a single method
over time.
On Microsoft Visio, from PERT Chart Shapes, we drag PERT 1 shape (node) to the blank page. Activities are named as tasks here
as is the case with Microsoft Project. We can choose the black color to fill and make the text white color for a good contrast. We
can copy this shape, and paste it as needed. In our exercise, we have 13 nodes in total.

Figure 7.8: Activity Node with Labels

An activity node includes the labels as seen in Figure 7.8.
Early Start (ES): The earliest time we can start an activity.
Duration: How long it takes to finish all the tasks in an activity. It can be hours, days, weeks, or months.
Early Finish (EF): The earliest time we can finish an activity.
Late Start (LS): The latest time we can start an activity. Some activities may have some flexibilities (slacks or floats) that allow
us to have some delay to start without affecting the overall project duration and other activities.
Late Finish (LF): The latest time we can finish an activity. Based on the slacks (floats), we can finish an activity later than its
scheduled completion time.
Slack (Float): It is the difference between LS and ES, or between LF and EF. Both subtractions generate the same result.
In order to connect nodes, we can drag a line connector to the Visio page and connect two activities (Figure 7.9).
Figure 7.9. Connecting a Predecessor to its Successor (FS dependency)

Figure 7.9. Connecting a Predecessor to its Successor (FS dependency)

7.5.4 [Link]
We should place each activity node on the diagram by adhering to their precedence relationships with other activities (Table 7.4).
After we connect all the nodes, we can type the duration for each activity as can be seen in Figure 7.10. All other parts in the nodes
are zero for now. Besides, as all the dependencies are finish-to-start, the arrows (connectors) start from the right side of a
predecessor activity and finish on the left side of a successor activity. For instance, when we finish Activity A, we can start both
Activity C and Activity D. When we finish both, we can start Activity F.

Figure 7.10: Activity Network Diagram with Durations

7.4.3 Forward Pass:

Now, we can start with a forward pass to determine the early start and early finish dates, and on the last activity, the overall time to
finish the whole project. It is an additive move through the network from start to finish.
1. For two starting activities (A and B), ES is marked zero, which means that it is the very first day of the project (Figure 7.11).

Figure 7.11: ES and EF times

2. We add ES to the duration for each activity to find EF. For A, EF is (0+1) = 1 week, and for B, it is (0+2) = 2 weeks. It means
that we can finish A at the end of the first week, and finish B at the end of the second week (Figure 7.11).
3. Then, we carry the EF time to the nodes immediately succeeding the recently completed nodes (predecessors). C and D inherit
1 (EF) from A, and it becomes ES for both successor activities. For E, we pass 2 (EF for B) to E as the ES time. Then, we add
new ES times to the duration of activities to find the EF for new successors (Figure 7.12).

Figure 7.12: Passing predecessor ES times to successors as EF times

7.5.5 [Link]
 4. At a merge point, as is the case when C and D merge at F, we pass the highest EF time of predecessors (C and D) to the
successor activity (F) (Figure 7.13). EF time of D becomes ES time for F.

Figure 7.13: Passing predecessor ES times at merge points

5. When the forward pass is done, we can generate all ES and EF times for all the activities. The EF of the last activity (M) gives
us the overall duration of the project which is 15 weeks (Figure 7.14).

Figure 7.14: Completion of the forward pass

7.4.4 Backward Pass

Before starting the backward pass process, we should explain the critical path which is the path through the network that results in
the latest completion date of the project. If any activity on the critical path is delayed, the completion of the project will be delayed
by an equal amount. It is the path with the greatest total duration. Therefore, we can add the amount of time estimated for the
duration of each activity to the previous activity to determine which path through the network has the longest total duration. As we
will explain below, slack will be zero for all the activities on the critical path.
After we complete the forward pass process for all the activities, we can start backward pass by moving from the last activity to the
starting activities. It is a subtractive move through the network from finish to the start. In our exercise, the last activity is M with a
one-week duration, an ES of 14 weeks, and an EF of 15 weeks which also indicates the overall duration of the project.
1. Late Finish (LF) for the last activity M is passed from EF (15 weeks). Then, we subtract LF from the activity duration to find
the Late Start (LS). It is (15-1) = 14 weeks (Figure 7.15).

Figure 7.15: Starting backward pass at the last activity

7.5.6 [Link]
 2. Now, it is possible to compute slacks for each activity. It is the difference between LS and ES, or between LF and EF. Both
calculations will generate the same result. For Activity M, it is (14-14) or (15-15), which is zero. Therefore, there are no slacks
for this activity. We don’t have any flexibility for this activity. We cannot have any delays to start the activity or to finish it. The
activities where slack is zero are critical.
3. Then, we carry back the LS time to the nodes immediately preceding the successor node. K and L inherit 14 (LS) from M, and
it becomes LF for both predecessor activities. Then, we subtract LF times from the duration of activities to find the LS for these
predecessors (Figure 7.16). The slack for L is (10-10) or (14-14), which is zero. Therefore, L is also a critical activity. The slack
for K is (11-8) or (14-11), which is 3. It means that we can wait for an additional three weeks to start K because we need to wait
until week 14.

Figure 7.16: Passing LS times to successors as LF times

Figure 7.16: Passing LS times to successors as LF times
4. At a burst point, as is the case when G is followed by two successors, H and I, we pass the lowest LS time of successors (H and
I) to the predecessor activity G as its LF time. Therefore, 6 becomes the LF for Activity G (Figure 7.17).

Figure 7.17: Passing successor LS times at burst points as LF times

5. When the backward pass is done for all the activities, we can generate all LS and LF times as well as slack times for all of them
(Figure 7.18). Thus, we can determine the critical path where the total slack is zero.

Figure 7.18: Completion of the backward pass

The critical path of this project is B – E – G – I – L – M. It is also the longest path. We need to start and finish all these six
activities on their scheduled time not to cause any delay in the overall project. Non-critical paths are:
1. A – C – F – J – K – M: 1+2+2+1+3+1=10 weeks
2. A – D – F – J – K – M: 1+4+2+1+3+1=12 weeks
3. B – E – G – H – K – M: 2+1+3+1+3+1=11 weeks

7.5.7 [Link]
We should always keep in mind that 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 key scheduling information that ultimately goes into user-friendly schedule formats, such as milestone
and Gantt charts. The network diagram provides important information to the project team. It provides information about how the
tasks are related, where the risk points are in the schedule, how long it will take as currently planned to finish the project, and when
each task needs to begin and end.
Schedules must be communicated to project stakeholders. Generally speaking, stakeholders want to know when the work will be
completed. Once the completion date is determined, it is important to confirm whether this date can meet the expectations of the
stakeholders, in particular the project sponsor, and internal or external clients. Once timeline commitments have been made,
stakeholders must be kept up to date on any delays that will cause deviation from the agreed-upon schedule.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
4. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 7.5: Creating an Activity Network Diagram is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated
by Abdullah Oguz (MSL Academic Endeavors) .

7.5.8 [Link]
7.6: Creating a Gantt Chart
A Gantt chart is a type of bar chart, developed by Henry Gantt, that illustrates a project schedule. Gantt charts are easy to read and
are commonly used to display scheduled activities. These charts display the start and finish dates of project activities. Gantt charts
also show the dependency relationships (i.e., precedence network) between activities.
Gantt charts show all the key 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 7.12). 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 that
it will take to complete the key tasks. The detailed Gantt chart is usually constructed after all WBS activities are identified, an
activity list is created, activity durations are estimated, and predecessors are determined.
Let’s continue with our example in table 7.3. The Gantt Chart for the Scope activities was created by using MS Project (Figure
7.19).

Figure 7.19: Gantt Chart for the “Scope” activities

In the Gantt chart in Figure 7.19, red bars show the critical tasks whereas blue bars illustrate the non-critical tasks. Dependencies
between all the activities are Finish-to-Start, which is the most common dependency and the default relationship in MS Project.

This page titled 7.6: Creating a Gantt Chart is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

7.6.1 [Link]
7.7: Microsoft Project Tutorial
The exercise in Table 7.5 has the same activities, durations, and predecessors as the exercise we used to develop a network diagram. In this exercise, we have added
different dependencies (not only F-S), lags (a positive number showing a delay), and leads (a negative number showing an earlier start).
Table 7.5: Activities

Activity Duration (week) Dependencies Lag Predecessors

A 1 F-S 0 –

B 2 F-S 0 –

C 2 F-S 0 A

D 4 S-S 0 A

E 1 F-S 0 B

F 2 F-S 0 C, D

G 3 F-S 0 E

H 1 F-S 2 weeks G

I 4 F-S 0 G

J 1 F-F -1 week F

F-S for H
K 3 5 days for J J, H
S-F for J

L 4 F-S 0 I

F-S for K
M 1 1 week for L K, L
F-F for L

When we start a new project on Microsoft Project, it is useful to check “Project Summary Task” under the “Format” tab. MS Project gives the row number zero to the
project summary task. The question mark at the end of the duration shows that the duration is estimated.

Figure 7.20: Project Summary Task

Besides, just in the very beginning, it is of high importance to check “Critical Tasks” and “Slack” under the “Format” tab (Figure 7.21). When we type the tasks
(activities), the Gantt Chart will start to highlight the critical and non-critical tasks in red and blue colors respectively.

Figure 7.21: Checked critical tasks and slack under the Format tab
As the durations are in weeks, we should change the settings in the Options under the “File” tab. “Duration is entered in” is changed to “Weeks” (Figure 7.22).

Figure 7.22: Changing the duration unit

First, we should type each activity on the “Task Name” column and durations on the “Duration” column. Then, we can select the predecessors from the dropdown
menu on the “Predecessors” column (Figure 7.23).

7.7.1 [Link]
 Figure 7.23: Selecting predecessors from the dropdown menu
When we finish typing all the activity predecessors, Gantt Chart will be completed on the right side of the window (Figure 7.24). As indicated above, red bars show
critical tasks (with zero slack) and non-critical tasks (with slacks). MS Project allows the users to change the colors of the bars.

Figure 7.24: Gantt Chart

For this exercise, we are not changing the “Task Mode”, which is either automatically scheduled or manually scheduled (Figure 7.25). Project summary task is
automatically scheduled since it adjusts the duration, and start and finish dates automatically when activity durations and predecessors are typed.

Figure 7.25: Task mode

When we double-click a task, the “Task Information” window opens (Figure 7.26). The dependency type is “Finish-to-Start (FS)” as default. Now we can change
dependencies as indicated in Table 7.5.

Figure 7.26: Task Information window

When we are done with predecessor types (dependencies), the predecessors with dependencies different from FS will appear on the “Predecessors” column for the
relevant activities (Figure 7.27). These dependencies are shown inside a red circle in Figure 7.27.

7.7.2 [Link]
 Figure 7.27: Predecessors and dependencies
After we change the dependencies, it is important to click “Respect Links” under the “Task” tab since the task mode is manually scheduled and the new dependencies
may affect the precedence relationships. As can be seen in Figure 7.28, MS Project highlights the boxes in light blue if there is a change.

Figure 7.28: Highlighted changes

As can be seen in Figure 7.29, the dependency between A and D is not FS anymore D. It is Start-to-Start (SS). Therefore, the arrow starts from the left side of A’s bar
on the Gantt Chart and connects to the left side of D’s bar. When it is FS, the arrow starts from the right side of the predecessor and connects to the left side of the
successor as can be seen in Figure 7.29 between A and C.

Figure 7.29: Start-to-Start dependency

In order to see the slacks for each activity, we can add a new column named “Free Slack” (Figure 7.30). The black underline attached to the left of Activity C in the
Gantt Chart also shows the slack (Figure 7.29).

Figure 7.30: Free Slack column

Now we can create an activity network diagram by selecting “Network Diagram” on the dropdown menu that appears when we click the Gantt Chart located on the far-
left part of the “Task” tab (Figure 7.31).

7.7.3 [Link]
 Figure 7.31: Selecting network diagram
Figure 7.32 displays the network diagram in a non-collapsed format. We should scroll toward the right to see other activities.

Figure 7.32: Network Diagram (Not collapsed)

In order to see the whole diagram without details, we should click “Collapse Boxes” and check “Straight Links” under the “Network Diagram Tools – Format” tab
(Figure 7.33). The network diagram in MS Project illustrates the links in FS dependency. Therefore, it is convenient to see other dependencies on the Gantt Chart view.

Figure 7.33: Network diagram (Collapsed)

This page titled 7.7: Microsoft Project Tutorial is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

7.7.4 [Link]
7.8: Key Takeaways
Key Takeaways
The project schedule management plan is one of the sub-plans of the overall project plan. It provides the guidelines on how to
develop a project schedule by defining and sequencing project activities and milestones, and by estimating activity durations.
The activity definition process is a further breakdown of the work package elements of the WBS which was created while
planning the scope.
After the lowest level activities are defined in the activity list, each activity is reviewed and evaluated to determine the duration.
An estimate is an educated guess based on knowledge, experience, and inference. Five types of estimation methods are expert
judgment, analogous estimating, parametric estimating, three-point estimates, and bottom-up estimating.
Showing the activities in rectangles or circles, and their relationships (dependencies) as arrows is called a precedence
diagramming method (PDM). This kind of diagram is also called an activity-on-node (AON) diagram.
Four types of logical relationships (dependencies) are “Finish-to-Start” (FS), “Finish-to-Finish” (FF), “Start-to-Start” (SS), and
“Start-to-Finish” (SF). The most common relationship is Finish-to-Start at which we start a successor activity once we finish the
predecessor activity.
The process to create an activity network diagram is composed of two main steps: (1) Forward pass, and (2) backward pass.
When these steps are completed, the critical path can be identified.
A Gantt chart is a type of bar chart that displays the start and finish dates of project activities, and their dependency
relationships with one another.

This page titled 7.8: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

7.8.1 [Link]
7.9: Questions and Exercises
There are 8 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 7.9: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

7.9.1 [Link]
7.10: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 7.10: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

7.10.1 [Link]
 CHAPTER OVERVIEW

8: Resource Management
8.1: Learning Objectives and Overview
8.2: Resource Management
8.3: Project Resource Management Plan
8.4: Estimating the Resources
8.5: Resource Allocation
8.6: Solving Resource Overallocation- Resource Leveling
8.7: Schedule Compression Techniques
8.8: Microsoft Project Tutorial
8.9: Key Takeaways
8.10: Questions and Exercises
8.11: Attribution

This page titled 8: Resource Management is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

1
8.1: Learning Objectives and Overview
Learning Objectives
1. Describe how to create a project resource plan.
2. Define the resources that will be utilized in a project, including the project team members.
3. Elaborate on resource loading, leveling, and crashing to conduct resource allocation effectively.
4. Practice on Microsoft Project to determine and allocate the resources, and solve resource overallocation and conflict problems
as well as scheduling issues.

Overview
A project manager is responsible for planning, developing, managing, and monitoring and controlling the resources to ensure that
project objectives can be achieved. Effective resource management is integral to overall project success. The objective is to identify
and allocate resources effectively and efficiently to project activities to complete the project to the satisfaction of the stakeholders,
in particular, clients and customers. Whereas scope, time, and cost are the main constraints of a project, they are tightly linked to
the resources. After the scope and schedule are delineated, the project manager can continue with the identification and allocation
of resources based on the scope (product requirements and project activities) and the schedule (how project activities are sequenced
on a timescale). Allocation of resources allows the project manager to determine the overall project budget most of which is spent
on resources.

This page titled 8.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

8.1.1 [Link]
8.2: Resource Management
Resource management is the efficient and effective deployment of an organization’s resources when they are needed. We can
classify the resources into three main categories:
1. Human resources (HRs)
a. Project team members (core team)
b. HRs outside the core team required for project activities
2. Physical resources
a. Equipment
b. Materials (Raw materials, supplies, consumables)
c. Inventory
d. Facilities
e. Infrastructure
f. IT hardware
g. IT software
h. Cloud computing resources
3. Services
a. Contractors and subcontractors
b. Consulting
Every activity in our activity list needs to have resources assigned to it. Before we can assign resources to the project, we need to
know their availability. To assess resource availability, a project manager needs information about what resources we can use on
our project when they’re available to us, and the conditions of their availability. This is why a WBS (see Chapter 4) and an activity
list (see Chapter 7) are critical in our project to plan for the resources.
The most important resource to a project is its people—the project team. We discussed the development and management of project
teams in section 6.7 of Chapter 6. Projects have a core team that includes a project manager and key members with functional
expertise. There may be also administrative personnel and members who assist the project manager. Core team members provide
continuity and “corporate memory” throughout the project, particularly to external hires who may not be as familiar with the
strengths and weaknesses of the organization’s previous projects. Projects require specific expertise at specific moments in the
schedule, depending on the milestones being delivered or the given phase of the project. An organization can host several strategic
projects concurrently over the course of a budget year, which means that its employees can be working on more than one project at
a time. Alternatively, an employee may be seconded away from his or her role within an organization to become part of a project
team because of particular expertise. Moreover, projects often require talent and resources that can only be acquired via contract
work and third-party vendors. Procuring and coordinating these human resources, in tandem with managing the time aspect of the
project, is critical to overall success.

This page titled 8.2: Resource Management is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

8.2.1 [Link]
8.3: Project Resource Management Plan
As described in Chapter 4, project planning is at the heart of the project life cycle and tells everyone involved where we are going
and how we are going to get there. It involves creating a set of plans to help guide the project team through the implementation and
closure phases of the project. The project resource management plan is one of the sub-plans of the overall project plan. It provides
the guidelines to project managers on how to estimate, acquire, manage and utilize physical and team resources[1]. It is the process
of establishing the policies, procedures, and documentation for planning, developing, managing, executing, and controlling the
project resources[2].
The resource management plan can consist of the following:
Project Organization Charts
Project team members and their reporting relationships are displayed in these charts.
A team charter is prepared to establish team values, agreements, communication guidelines, decision-making criteria and
processes, and operating guidelines for the team[3].
Resource requirements
Types of resources (e.g., human resources, physical resources, services)
Human resources (Core team members and people for all project activities)
Required skills and competencies
Roles and responsibilities
Authority level (e.g., decision-making, inspecting, and accepting deliverables)
Effort in hours (e.g., daily working hours – full-time or part-time, the total amount of work hours)
Source (e.g., PMO – Project Management Office, other functional units, regional offices, outsourcing, offshoring)
WBS activity link
Required features for physical resources (e.g., equipment, materials, facilities, infrastructure, supplies)
Project team resource management
Methods for developing and managing the project team
The decision criteria when to use project team human resources and the human resources outside the team.
Resourcing strategy
How will resources be acquired and released from the project?
Resourcing assumptions
Are there any assumptions about the resource requirement estimates?
Vacations, holidays, training, meetings, interruptions, sick leave.
Rewards and recognition
Define the criteria for rewarding project team members for the work that they have done.
Which rewards will be given and when?
How much money is set aside for the project?
Resource control
Which methods will be used to monitor and control the project resources?
Health and safety
Are there specific health and safety practices that will be followed on the project?
In the resource management plan, including a Resource Breakdown Structure would help the team substantially to illustrate the
needs in a hierarchical structure. An example is given in Figure 8.1 based on the case study regarding Grocery LLC’s M-Commerce
Project.

8.3.1 [Link]
 Figure 8.1: Resource Breakdown Structure (RBS) for M-Commerce Project

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 8.3: Project Resource Management Plan is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

8.3.2 [Link]
8.4: Estimating the Resources
The goal of activity resource estimating is to assign resources to each activity in the activity list. In order to estimate resources, we
can use the similar techniques that we utilized to estimate schedule (see Chapter 7) and cost (see Chapter 9). In this book, we will
describe four tools and techniques for estimating activity resources.
1. Expert judgment: The project team consults domain and implementation subject matter experts who have technical knowledge
and experience in the areas the project activities are related to. When we are developing a mobile application, we can consult
software engineers, developers and testers, and systems analysts who were involved in activities to develop other mobile
applications. They can provide us with information regarding resource requirements.
2. Alternative analysis: We can consider several different options for how we can assign resources. This includes varying the
number of resources as well as the kind of resources we use. Many times, there’s more than one way to accomplish an activity
and alternative analysis helps decide among the possibilities.
3. Analogous estimating: Information and lessons learned from previous projects, standards provided by the regulatory agencies,
government organizations, and occupational associations, and the data that rely on articles, books, journals, and periodicals can
be utilized to help us figure out what kind of and how many resources we need in our project activities.
4. Bottom-up estimating: We decompose our project activities by utilizing WBS. We break down complex activities into pieces.
Therefore, we can work out the resource assignments for each piece. It is a process of estimating individual activity resource
needs and then adding these up together to come up with a total estimate. Bottom-up estimating is an accurate means of
estimating, given that the estimates at the lower levels 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. An example is
provided in the sections “8.4 Resource Allocation” and “8.5 Solving Resource Conflicts”.
Project management software programs such as Microsoft Project often have features designed to help project managers estimate
resource needs and constraints and find the best combination of assignments for the project.

This page titled 8.4: Estimating the Resources is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

8.4.1 [Link]
8.5: Resource Allocation
Based on the Resource Management Plan and according to the estimation methods, the project team should identify the resources
necessary for the project activities and should allocate them to execute the project activities. Allocation of resources is named
“Resource Loading”. Then, the project team can have a resource usage calendar that exhibits the amounts of resources assigned to
each activity during the project. Let’s continue with “Table 7.1. Activity List Template” from Chapter 7, and load resources to the
activities of “1.3 Preparation of Project Charter”.
Table 8.2: Resource Loading for 1.3 “Preparation of Project Charter”

Activity List for Project “Grocery LLC’s M-Commerce Project”

Activity Person
Activity title Scope of Work Predecessors Resources
identifier Responsible

The project charter that will authorize

the project manager to undertake the 1.1
Preparation of Project Project
1.3 responsibility of the project and apply 1.2
Charter Manager
the resources to project activities will
be prepared.

The high-level scope consists of the

project purpose, measurable project
Develop high-level objectives, high-level requirements, Systems Systems
1.3.1 1.2
scope project description, boundaries, key Analyst 1 Analyst 1
deliverables, and assumptions and
constraints.

Identify overall This includes the identification of the Systems Systems

1.3.2 1.3.1
project risks risks that affect the project in general. Analyst 2 Analyst 2

This includes the estimation of the

Develop high-level Team Systems
1.3.3 overall schedule with summary 1.3.1
schedule Member 1 Analyst 1
milestones.

Systems
Identify main This includes the initial estimation of Analyst 1
resources and all resources (human resources, Team
1.3.4 1.3.3 Systems
develop a high-level physical resources, and services), and Member 2
budget the budget.
Analyst 2

1.3.5 Identify key Stakeholders with high-interest levels Team 1.3.1 Systems
stakeholders and and/or power levels will be identified. Member 3 1.3.2 Analyst 1
project team member
roles
The project team’s Systems
composition will be created. Analyst 2
The qualifications required Sales &
should be detailed. Marketing

8.5.1 [Link]
 The project sponsor’s Expert 1
authority will be detailed. Sales &
Marketing
Expert 2

Based on the project scope and other

sections of the project charter, project
approval requirements and exit criteria Systems
1.3.1
Develop project should be detailed. Analyst 1
Team 1.3.2
1.3.6
approval Exit criteria include the Member 1, 2, 1.3.3 Systems
requirements and
project exit criteria conditions that describe the 3 1.3.4 Analyst 2
1.3.5
early termination of the
project.

In Table 8.2, we only assigned human resources. We also assume that all the people work full-time, which is 8 hours a day. They work
during the weekdays, which makes the weekly total work hours forty. In Table 8.3, we can see how human resources are distributed to
the tasks by week.
Table 8.3: Resource Usage Calendar
Resource Name Work May 2 May 9 May 16 May 23 May 30 June 6

Systems Analyst 1 240 hrs 40 32 40 64 40 24

Clarify project purpose and determine 40

40 hrs
project scope

Develop high-level scope 32 hrs 32

Develop high-level schedule 48 hrs 40 8

Identify main resources and develop a 16

16 hrs
high-level budget

Identify key stakeholders and project 40 24

64 hrs
team member roles

Develop project approval 16 24

40 hrs
requirements and project exit criteria

Systems Analyst 2 200 hrs 40 0 40 56 40 24

Clarify project purpose and determine 40

40 hrs
project scope

Identify overall project risks 40 hrs 40

8.5.2 [Link]
 Resource Name Work May 2 May 9 May 16 May 23 May 30 June 6

Identify main resources and develop a 16

16 hrs
high-level budget

Identify key stakeholders and project 40 24

64 hrs
team member roles

Develop project approval 16 24

40 hrs
requirements and project exit criteria

Sales & Marketing Expert 1 104 hrs 40 0 0 40 24 0

Clarify project purpose and determine 40

40 hrs
project scope

Identify key stakeholders and project 40 24

64 hrs
team member roles

Sales & Marketing Expert 2 104 hrs 40 0 0 40 24 0

Clarify project purpose and determine 40

40 hrs
project scope

Identify key stakeholders and project 40 24

64 hrs
team member roles

Resource usage calendars help project teams evaluate whether resources are assigned without conflicts. As can be seen in Table 8.3,
System Analyst 1 (SA1) and 2 (SA2), both, have resource overallocation problems on May 23rd week. SA1 works 64 hours on that
week while SA2 works 56 hours. Both work more than 40 hours (8 hours per weekday) assuming that overtime work is not allowed.
In the next section, we will discuss how to solve this overallocation by means of resource leveling.

This page titled 8.5: Resource Allocation is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

8.5.3 [Link]
8.6: Solving Resource Overallocation- Resource Leveling
One of the techniques to solve resource conflicts is implementing resource leveling which is used to examine the unbalanced use of
resources (usually people or equipment) over time and for resolving overallocation or conflicts. When performing project planning
activities, the manager will attempt to schedule certain tasks simultaneously. When more resources 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.
Resource leveling during project planning is the process of resolving these conflicts. It can also be used to balance the workload of
primary resources throughout the project, usually at the expense of one of the triple constraints (scope, schedule, cost).
As we discussed briefly in the previous section, both systems analysts are overallocated. Therefore, we should correct this issue
since they cannot work more than 40 hours a week. Resource leveling would be one of the techniques to eliminate this problem. In
resource leveling, we still use the same resources without adding new resources. However, this comes with a risk of schedule delay.
Gantt Chart for the weeks of May 16, May 23, and May 30 is shown in Figure 8.2. As can be seen in the figure, 1.3.3 and 1.3.5
overlap on May 23, and SA1 works full time in two activities on the same day, which is not possible. Besides, 2-day activity 1.3.4
overlaps with 1.3.5, and both SA1 and SA2 work on both of the activities.

Figure 8.2: Gantt Chart before Resource Leveling

Since resource leveling utilizes the same resources, it may create schedule delays as seen in Figure 8.3. Activity 1.3.4 had to be
moved to June 2 from May 24 to prevent any conflicts with 1.3.3 and 1.3.5. Its duration was also increased to 3 days from 2 days.
Activity 1.3.5 starts on the same day, May 23. However, its duration was also increased to 9 days from 8 days. Therefore, it finishes
on May 2 instead of May 1. For these three activities, we have a three-day delay in total after resource leveling. Sometimes,
splitting the tasks could be another option if the activities allow us to do so. This resource leveling could also affect the following
activities, which may create a chain effect with more schedule slippages.

Figure 8.3: Gantt Chart after Resource Leveling

Another option to resolve conflicts would be assigning new resources to prevent schedule slippages. A third systems analyst can be
assigned to activity 1.3.3 by removing SA1. With the new SA3, we can reallocate SA1 and SA2 in 1.3.4 and 1.3.5 by replacing
them with SA3 for the days when SA1 and SA2 have conflicts with other activities. Apparently, this situation would impose
additional costs on the project by adding a new systems analyst. However, we can avoid schedule slippages. Thus, the project
manager should evaluate all the trade-off options between the schedule and the cost.

8.6.1 [Link]
This page titled 8.6: Solving Resource Overallocation- Resource Leveling is shared under a CC BY-NC 4.0 license and was authored, remixed,
and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

8.6.2 [Link]
8.7: Schedule Compression Techniques
While resource leveling is mostly implemented during the planning stage of activities, schedule compression techniques such as
crashing and fast-tracking are utilized during the execution of activities to accelerate the project. With crashing, the project
manager adds additional resources to the critical activities (zero-slack activities) and saves time by spending more money on the
additional resources. In this technique, existing resources can be asked to work overtime or we can add new resources. As seen in
Figure 8.4, we assigned new resources to the three activities. With the added resources, and accordingly with more cost, we now
had the opportunity to finish these activities in 8 days instead of 12 days.

Figure 8.4: Crashing

Project managers should ponder all the alternatives and outcomes before deciding on crashing since adding new resources may not
shorten the duration all the time. If overtime is approved, people who work overtime may be less productive after a while with
increased tiredness and less satisfaction. Besides, there may be internal and external dependencies. For example, we may be still
waiting for a material ordered from a supplier which cannot deliver earlier. Regarding the equipment, we may not be able to
increase the operating time if the equipment cannot work more than a certain number of hours a day. If the activities in which we
crash resources are not critical, we cannot shorten the duration. Let’s consider the project activity network diagram in Figure 7.14
from Chapter 7.

Figure 8.5: Activity Network Diagram from Chapter 7

Let’s perform crashing in Activity D and Activity K. Each of D and K has a three-day slack. Let’s assume that with additional
resources, we can finish D in 3 weeks instead of 4 weeks, and the K in 1 week instead of 3 weeks. The new activity network
diagram is in Figure 8.6. The total duration of the project remains the same, 15 weeks. D and K, the both, have one more day slack
while it hasn’t influenced the project duration. Therefore, we have just paid more for nothing.

8.7.1 [Link]
 Figure 8.6: Activity Network Diagram after Crashing D and K
If we crash critical activities, we can save time on the project. Let’s add new resources to Activity I and Activity L. The new
duration for I and L is 3 weeks for each. As seen in Figure 8.6, the total duration of the project was reduced to 13 days from 15
days.

Figure 8.7: Activity Network Diagram after Crashing I and L

Another option to shorten the duration of a project is to implement fast-tracking. If some parts of the activities can be carried out in
parallel, we can shorten the total duration. Let’s use the example in Figure 8.4. In fast-tracking, we don’t assign new resources.
With the same resources, we can execute some parts of three activities in parallel. Let’s assume that the first activity is coding and
HR1 is working in this activity. The second activity is testing and HR2 is working in this activity. We don’t need to wait for the first
activity to be completed to start the second activity. We can add two-day leads (negative lags) between activities (Figure 8.8). After
developers finish some of the codings, testers can start the testing. In this case, we can finish three activities in 8 days instead of 12
days as seen in Figure 8.8. However, using leads increases the coordination efforts. Therefore, the project manager should exert
more concentrated efforts for coordination to prevent any quality risks. It may be still possible to increase the project costs although
the probability is less when compared with crashing. It is of high importance to bear in mind that not all activities can be fast-
tracked. The sequencing of the activities should be such that fast-tracking is permissible.

8.7.2 [Link]
 Figure 8.8: Fast Tracking

This page titled 8.7: Schedule Compression Techniques is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

8.7.3 [Link]
8.8: Microsoft Project Tutorial
For the MS Project tutorial, let’s continue with our example of m-commerce project. Let’s focus on “1. Scope”. The WBS for the scope stage is in Table 8.4. This table also
includes the duration, start and finish dates, and predecessors.
Table 8.4: WBS for the Scope of the M-Commerce Project

WBS Task Name Duration Start Finish Predecessors

1 Scope 35 days Mon 5/2/22 Mon 6/20/22

1.1 Clarify project purpose and determine project scope. 5 days Mon 5/2/22 Fri 5/6/22

1.2 Secure project sponsorship 1 day Mon 5/9/22 Mon 5/9/22 2

1.3 Preparation of project charter 22 days Tue 5/10/22 Wed 6/8/22

1.3.1 Develop high-level scope 4 days Tue 5/10/22 Fri 5/13/22 3

1.3.2 Identify overall project risks 5 days Mon 5/16/22 Fri 5/20/22 5

1.3.3 Develop high-level schedule 6 days Mon 5/16/22 Mon 5/23/22 5

1.3.4 Identify main resources and develop a high-level budget 2 days Tue 5/24/22 Wed 5/25/22 7

1.3.5 Identify key stakeholders and project team member roles 8 days Mon 5/23/22 Wed 6/1/22 5,6

1.3.6 Develop project approval requirements and project exit criteria 5 days Thu 6/2/22 Wed 6/8/22 5,6,7,8,9

1.4 Approval of project charter by the sponsor 2 days Tue 6/9/22 Fri 6/10/22 10

1.5 Secure core resources 5 days Mon 6/13/22 Fri 6/17/22 11

1.6 Initiation stage complete 0 days Mon 6/20/22 Mon 6/20/22 12

Let’s identify the resources that we can use for the scope. We should enter them in the Resource Sheet after we click “Resource Sheet” in the dropdown menu (Figure 8.9).

Figure 8.9: Dropdown Menu for the Resource Sheet

In the Resource Sheet window, we can type the resources. There are three types of resources in MS Project:
1. Work: Work resources are people and equipment. They have a standard rate per hour.
2. Material: Material resources are consumable supplies. They have a unit of measurement such as tones, boxes, and cubic yards.
3. Cost: Cost resources are independent costs we want to associate with a task such as a plane ticket.
Let’s type all the resources as seen in Figure 8.10. In this chapter, we won’t write standard rates, overtime rates, and cost/use. We will detail them in Chapter 9. We are only
typing the human resources in this tutorial. Therefore, they are classified as “Work” type. We keep “Max” (Maximum units) 100% as they work full-time.

Figure 8.10: Resources in Resource Sheet

8.8.1 [Link]
After we type the resources, we can assign them to their tasks in the Gantt Chart window on the dropdown menu (Figure 8.9).

Figure 8.11: Assigning the Resources in the Tasks on Dropdown Menu

After we assign all the resources to their relevant tasks, we can see the information below as in Figure 8.12.

Figure 8.12: Assigning the Resources in the Tasks

The Gantt chart which is on the right side of the window would be as in Figure 8.13. The MS Project illustrates the Gantt chart with bars and the resources assigned to each task
to the right of each task bar. As explained in Chapter 7, the red bar displays a critical path, and the blue bar displays a non-critical path.

Figure 8.13: Gantt Chart for the Scope

As can be seen in Figures 8.12 and 8.13, there are three red people indicators in the first column. This is a warning for overallocated resources. We can investigate more to
understand which resources are overallocated. On the dropdown menu in Figure 8.9, we can select “Resource Graph”. Figure 8.14 shows us that Systems Analyst 1 is
overallocated on three days, which is more than 100%.

Figure 8.14: Resource Graph Displaying Overallocated Resources

We can implement resource leveling for these three activities. On the “Resource” tab, we can select “Level Resource” or “Level All” (Figure 8.15). Leveling options can also be
modified. For this tutorial, we are not changing the options.

Figure 8.15: Resource Tab

When we click “Level All”, MS Project levels the resources in these three activities with resource overallocation (Figure 8.16). Therefore, our resource overallocation is
resolved. The duration of 1.3 was 22 days before resource leveling. After the leveling, it is 25 days. Therefore, there is a 3-day slippage as we are using the same resources, and
aren’t allocating new resources. However, the total duration of “1. Scope” didn’t change, and stayed at 35 days after leveling.

8.8.2 [Link]
 Figure 8.16: Schedule before and after Resource Leveling

Figure 8.17: Gantt Chart before and after Resource Leveling

But we now experience a schedule slippage as seen in Figures 8.16 and 8.17. Besides, 1.3.6 and the following activities are affected. 1.3.6 has an underlined text for the Finish
Date, which means that there is a scheduling problem. After resource leveling, it is common to experience schedule problems in the following activities. To solve the scheduling
problem in 1.3.6 and the following activities, we can click “Respect Links” for 1.3.6 and all the following activities. Besides, MS Project gives some options when we right-click
on an underlined date as seen in Figure 8.18. When we right-clicked on the underlined finish date (Mon 6/13/22) of 1.3.6, it gave us the options “Fix in Task Inspector”,
“Respect Links”, and “Switch to Auto Scheduled”.

Figure 8.18: Solving Scheduling Problems

After all the scheduling problems are corrected, the total duration of Scope goes up to 39 days from 35 days (Figure 8.19).

Figure 8.18: Solving Scheduling Problems

This page titled 8.8: Microsoft Project Tutorial is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

8.8.3 [Link]
8.9: Key Takeaways
Key Takeaways
Resource management is the efficient and effective deployment of an organization’s resources when they are needed. These
resources can be classified as human resources, physical resources, and services.
Planning resource management is the process of establishing the policies, procedures, and documentation for planning,
developing, managing, executing, and controlling the project resources.
Resource Breakdown Structure helps the team to illustrate the resource needs in a hierarchical structure.
The techniques to estimate the resources are expert judgment, alternative analysis, analogous estimating, and bottom-up
estimating.
Allocation of the resources to the project activities is called “Resource Loading”.
Resource leveling is used to examine the unbalanced use of resources (usually people or equipment) over time and for resolving
overallocation or conflicts.
Schedule compression techniques such as crashing and fast-tracking are utilized to accelerate the project.

This page titled 8.9: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

8.9.1 [Link]
8.10: Questions and Exercises
There are 5 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 8.10: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

8.10.1 [Link]
8.11: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 8.11: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

8.11.1 [Link]
 CHAPTER OVERVIEW

9: Budget and Procurement

9.1: Learning Objectives and Overview
9.2: Project Costs
9.3: Project Cost Management Plan
9.4: Estimating Costs and Determining Budget
9.5: Establishing the Project Budget
9.6: Managing Project Costs
9.7: Project Procurement Management
9.8: Microsoft Project Tutorial
9.9: Key Takeaways
9.10: Questions and Exercises
9.11: Attribution

This page titled 9: Budget and Procurement is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

1
9.1: Learning Objectives and Overview
Learning Objectives
1. Define the project cost and explain its types.
2. Create a project cost plan to help guide the project team through the implementation and closure phases of the project.
3. Define the budget estimation techniques.
4. Describe the process of documenting project procurement decisions, specifying the approach, and identifying potential sellers.
Define the resources that will be utilized in a project, including the project team members
5. Practice the allocation of resources and calculation of their costs with Microsoft Projec

Overview
While performing the planning of all the knowledge areas (e.g., scope, schedule, cost, quality, stakeholders, risks), the project
manager should be aware of the fact that all knowledge areas are tightly linked to each other. That is, it is not possible to start with
cost or quality first. The scope is the starting point when project managers with the help of business analysts, subject matter
experts, clients, the project sponsor, and various stakeholders identify the project purpose, measurable objectives, requirements,
deliverables, and WBS activities. Whereas scope, time, and cost are the main constraints of a project, all three are tightly linked to
the resources, which are other constraints that include time and cost as critical resources. After the scope (see Chapters 3 and 4) and
schedule (see Chapter 7) are delineated, the project manager can continue with the identification and allocation of resources based
on the scope (requirements and project activities) and the schedule (how project activities are sequenced with duration for each of
them). Allocation of resources provides the project manager to determine the overall project budget most of which is spent on
resources (Chapter 8).
Every project boils down to money. If we had a bigger budget, we could probably get more people to do the project more quickly
and deliver more. That’s why no project plan is complete until we come up with a budget. But no matter whether the project is big
or small, and no matter how many resources and activities are in it, the process for figuring out the financial bottom line is always
the same. This chapter starts with defining the project cost and its types, then elaborates on the cost management plan, continues
with how to estimate costs and determine the budget, and ends with project procurement management. We will expand Microsoft
Project exercises in chapters 4 (scope), 7, (schedule), and 8 (resources) by specifying the cost for all the activities and the overall
project.

This page titled 9.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

9.1.1 [Link]
9.2: Project Costs
One of the criteria of project success is completing the project within budget. Developing and controlling a project budget that will
accomplish the project objectives is a critical project management skill. Although stakeholders expect the project to be executed
effectively and efficiently, pressures to remain within budget vary based on the unique constraints and priorities of the project. On
some projects, the project completion date is the highest priority leading to a more flexible budget to accommodate the inflexible
deadline. Moreover, the project’s scope may have to be scaled back if it is too ambitious to finish in time. On other projects, for
example, ones with limited funding available, remaining within budget is the highest priority. When this is the case, effective cost
management is imperative and trade-offs with scope, quality, and/or time may be required.

9.1.1 Boston’s Infamous Big Dig (Central Artery/Tunnel) Project

One of the notorious examples of project budget overrun is Boston’s Big Dig project[1] although its outcome had significant
benefits to the Boston residents by lowering traffic jams and pollution. Central Artery/Tunnel Project, the official name of the
project, was the largest, most challenging highway project in the history of the United States. This project’s objective was to reduce
traffic and improve mobility in one of America’s oldest, most congested major cities. Although the project had been planned in the
1980s, it was completed in 2007. Its original completion was scheduled in the late 1990s, and its original cost was estimated to be
about 3 million dollars[2]. However, including the interest to be paid, the total cost was estimated to be 24 million dollars[3]. As
listed by Greiman and Warburton (2009)[4], common causes for cost escalation on the Big Dig included: the failure to include a
cost for inflation in each contract; delays in project completion; and the actual rate of inflation being greater than the planned
estimate. Other factors that impacted the Big Dig were financing shortfalls and interest rates, scope changes, shortages of materials
and labor, price increases, and market changes, weak project managers, technical and design complexity, unexpected events and
force majeure, and political and legal risks.
The Big Dig project is considered a mega project, and unfortunately, many mega projects suffered a substantial cost overrun as well
as other problems regarding the scope, schedule, risks, and resources, which in turn, led to the cost overruns. However, smaller
projects, even our personal projects such as moving to another house and going on a summer vacation, may experience problems
with the cost. When problems start in a project, the sponsor, clients, and other stakeholders first realize the abnormality in the
budget which is an explicit reflection of something going bad. The more money we spend over the estimated budget, the more it
hurts the stakeholders since the financial assets of a project, organizations and individuals can be analogous to the blood of a living
thing.
Some of the reasons why projects fail to keep themselves on track with regard to their budget can be outlined below:
1. Project activities may not be identified in accordance with the project objectives and product scope. For example, if the project
manager doesn’t include the required travel and accommodation expenses that are required for the factory test in another city or
country.
2. The duration of project activities may not be estimated correctly, thus leading to shorter or longer duration. For example, if an
activity’s duration is determined as one week whereas it requires at least two weeks to complete all the tasks, an additional
week would lead to more labor and material costs.
3. Underestimation of costs per activity and resource. Let’s assume that the minimum hourly wage of a systems analyst is $30
currently, and it is difficult to find one who can accept a wage below $30. However, we take into account the costs in a similar
project which was completed two years ago. Thus, we estimated $20 per hour for a systems analyst. If two analysts work for
100 hours in total, this underestimation could cause us to spend an additional $1,000 in the best scenario.
4. Risk identification is an essential process during the planning phase. If risks cannot be identified properly (see Chapter 10), for
instance, if a risk that may put the project in jeopardy is overlooked, we will need to allocate an additional budget in case the
risk occurs. In a worse case, the project may fail, which cannot be even saved with an additional budget.

9.1.2 Project Cost Types

There are generally three different types of project costs:
1. Direct costs
2. Project-induced overhead costs
3. General administrative costs
The primary difference between these costs is how closely related they are to the specific activities of the project.

9.2.1 [Link]
Direct costs are directly related to specific project tasks. These costs represent the labor, time, and materials associated with
specific tasks. If a software developer works on our m-commerce project for 40 hours, each hour they work to code the mobile
application will be incurred as a direct cost. These are generally variable costs as is the case for the software developer cost.
Project-induced overhead costs are incurred as a result of the project’s existence, but they are not directly related to specific tasks.
These costs represent the compensation paid to individuals who are supporting the project in its entirety, such as the project leader
and their support staff (project analysts, coordinators, etc.). These costs also represent materials, facilities, and related equipment
that were purchased to support the project in general. The rental and maintenance of workspace for the project team members, as
well as their computers and related information technology, supplies, and lunch (if provided), are all examples of overhead costs. If
we rent an office for the developers and testers to work together, then this fixed cost would be also a direct cost.
Lastly, general administrative costs are indirectly related to a project, and they are incurred even if the project is not carried out.
Examples of this type of cost include marketing, human resources, and accounting department-related expenses. These departments
may provide ad-hoc and minimal support to the project teams and as a result, the project sponsors may want a portion of their costs
to be allocated to all projects underway in the organization. Allocating a portion of the costs to the project provides the executive
with a full picture of all costs incurred due to the implementation of strategic change initiatives in the organization. Since the
allocation methods are often very subjective, many organizations exclude general administrative costs from the project budget.
It is important to note that some projects require the direct involvement of these administrative functions. This should be clearly
identified in the project’s work breakdown structure. For instance, a project that involves the introduction of new technology will
alter the way people work and this may require members of the human resources department to reevaluate existing job descriptions,
compensation levels, and so forth. In this instance, the human resources function is a work package and the costs associated with
their work are direct costs.

1. The Big Dig: project background. (n.d). Highway Division - Massachusetts Department of Transportation. Retrieved from
[Link]
2. Retrieved from [Link]
3. Tran A.B. (2014). Federal spending on Massachusetts transportation over time. Retrieved from
[Link]
time/eIx7CAnnHS33eaIFbuinIM/[Link]↵
4. Greiman, V. & Warburton, R. D. H. (2009). Deconstructing the Big Dig: best practices for mega-project cost estimating. Paper
presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute.
↵

This page titled 9.2: Project Costs is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

9.2.2 [Link]
9.3: Project Cost Management Plan
As described in Chapter 4, project planning is at the heart of the project life cycle and tells everyone involved where we are going
and how we are going to get there. It involves creating a set of plans to help guide our team through the implementation and closure
phases of the project. The project cost management plan is one of the sub-plans of our overall project plan. It provides guidelines to
project managers on how to estimate, budget, manage, monitor, and control project costs[1].
A project cost management plan consists of similar items that we have in a schedule management plan. This plan can consist of the
following[2]:
Process descriptions [3]
What processes will be used for cost management?
These processes include planning, estimating costs, and establishing the overall budget.
Unit of measurement
Daily working hours and shifts for human resources and equipment
Weekends and/or off-days for especially human resources
Metric (e.g., meter, liter, kilogram) or imperial (e.g., inch, gallon, pound) system measurement units
Level of accuracy
Acceptable range to ensure realistic cost estimates (e.g., ±10%, ±20)
Evaluation of the impact of risks on the costs of each activity and overall project based on the project risk management plan
Methods describing how the cost contingencies will be assessed.
Procedure to account for fluctuations in currency exchange rates
Level of precision
The degree to which cost estimates will be rounded up or down (e.g., $95.55 to $96; $95.45 to $95; $495.75 to $496 or
$500)
Evaluated based on the scope, size, and complexity of the project.
Cost estimation methods
Estimation methods (e.g., expert judgment, analogous, parametric, three-point, bottom-up), and when they will be utilized.
Methods, tools, and software utilized to develop, manage, and monitor project cost
Specify the organizational procedures and policies if they should be utilized.
Methods and tools such as control accounts, WBS, project baseline, Earned Value Management, and critical path method
Reserve analysis to set aside some money for cost overruns due to risks in order to implement risk mitigation strategies.
Software such as Microsoft Project Professional, Excel, Visio, and Jira (for Kanban and Scrum), and online collaboration
tools such as Monday, Trello, and Basecamp.
Rules for monitoring cost performance
Earned Value Management (EVM)
Defining the points in the WBS at which measurement of control accounts will be performed
How strategic funding choices would be managed.
Control thresholds for deviations from the parameters in the cost baseline
Using software such as Microsoft Project
Reporting formats
Reporting formats and frequency should be in alignment with other project plans.
When, how frequently, and to whom are we reporting?[4]
Approval of the cost baseline
Who will be responsible for preparation and control?
Who will approve the cost baseline?

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

9.3.1 [Link]
 2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. Harrin, E. (2014) 7 Things for your cost management plan. Retrieved from [Link]
post/7645/7-things-for-your-cost-management-plan↵
4. Harrin, E. (2014) 7 Things for your cost management plan. Retrieved from [Link]
post/7645/7-things-for-your-cost-management-plan↵

This page titled 9.3: Project Cost Management Plan is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

9.3.2 [Link]
9.4: Estimating Costs and Determining Budget
As detailed in Chapter 2, financial indicators are commonly utilized in business cases and their accompanying benefits
management plan while selecting projects to continue with. Whereas financial indicators such as profitability, NPV (Net Present
Value), and payback period are helpful in the selection process to understand the economic feasibility of the projects, we should
emphasize again that there are multiple criteria besides financial indicators. During this selection process and when the project is
conceptualized to create a project charter, business analysts and project managers usually don’t have an adequate amount of
information to estimate an accurate cost. Therefore, estimation techniques such as expert judgment and analogous estimating could
be more helpful during the earlier stages. Expert judgment of experienced managers can help make more accurate estimates with
less detailed information. Estimates in the earliest stages also include information from previous projects (i.e., analogous
estimating) that can be adjusted and scaled to match the size and complexity of the current project. Besides standardized formulas
can be used (parametric estimating). When we 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
we learn more about the project. In a later stage, the planning phase, when we develop the WBS and activity list, bottom-up
estimating accompanied by three-point estimates can generate cost estimates with better accuracy.
The goal of estimating costs is to determine the monetary resources required for the project[i][1]. In order to estimate costs for
individual activities and the overall project, as explained above, we can use the techniques that we utilized to estimate schedule and
resources. In this textbook, we will describe five tools and techniques for estimating costs.

9.3.1 Expert Judgment

As discussed in Chapters 7 and 8, the project team consults domain and implementation subject matter experts who have technical
knowledge and experience in the areas the project activities are related. These experts are those who worked on previous similar
projects, and/or those who have information in the industry, discipline, and application area[2]. Experts in organizations’ finance,
accounting, and procurement departments are usually consulted. All these experts can be consulted during the pre-project work[3],
and also during the initiating and planning.

9.3.2 Analogous estimating

As discussed in Chapters 7 and 8, information and lessons learned from previous projects, standards provided by the regulatory
agencies, government organizations, and occupational associations, and the data that rely on articles, books, journals, and
periodicals can be utilized to estimate costs. If a similar project cost a certain amount, then it can be reasonable to assume that the
current project will cost about the same. However, many factors need to be taken into account since simply copying the costs from
previous projects and pasting them on the new project’s cost tables wouldn’t work for most of the projects. Few projects have the
same size and complexity. Therefore, estimates must be adjusted upward or downward to account for the differences. Inflation and
currency rates as well as socio-economic conditions are important indicators that would entail an adjustment. The selection of
projects that are similar and the amount of adjustment needed is up to the judgment of the person or the team who makes the
estimate. It should include the lessons learned from previous projects, both at an organizational level and individual level.
Therefore, this judgment is based on many years of experience comprised of successful and unsuccessful projects and their
estimates.

9.3.3 Parametric estimating

As explained in Chapter 7, in this estimation technique, we can use equations and algorithms to calculate the costs. This method is
quantitative. Estimates are calculated by multiplying measured parameters by cost-per-unit values. If the project consists of
activities that are common to many other projects, average costs are available per unit. For example, if we ask a construction
company how much it would cost to build a standard office building, they will ask for the size of the building in square feet and the
city in which the building will be built. From these two factors—size and location—the company’s estimator can predict the cost of
the building. Factors like size and location are parameters—measurable factors that can be used in an equation to calculate a result.
The estimator knows the average cost per square foot of a typical office building and adjustments for local labor costs. Other
parameters such as quality of finishes are used to further refine the estimate. Readers can visit Cost To Build’s website
[Link] to estimate the cost of their dream houses and garages. In Chapter 7, for Grocery LLC’s
m-commerce project, we calculated the time software developers need to create 200 lines of code for a module. Based on the
previous projects and the feedback we received from the subject matter experts, we have estimated that a developer can finish 40

9.4.1 [Link]
lines in an hour, and hence 200 lines in 5 hours. We also added a one-hour break and a two-hour review for this task. Therefore, the
total work hours amounted to 8 hours. If the average hourly rate of a software developer is $50, for this activity, we will pay $400
($50 x 8 hours). Project managers can also prefer deducting one hour of break time. This technique can produce higher levels of
accuracy depending on the sophistication and underlying data built into the model. Parametric estimates can be applied to the
whole project or segments of it, in conjunction with other estimating methods[4].

9.3.4 Three-point estimating

As is done for activity duration estimates (see Chapter 7), cost estimates can be also done based on three scenarios:
a. A realistic estimate (most likely to occur – m)
b. An optimistic estimate (best-case scenario – o)
c. A pessimistic estimate (worst-case scenario – p)
Please refer to the exercise inside the “7.3 Estimating Activity Durations” sections in Chapter 7. Furthermore, three-point
estimating is detailed in “9.3.1 Case Study 9.1: Estimating the Cost for M-Commerce Project’s Scope Component”.

9.3.5 Bottom-up estimating

As discussed in Chapters 7 and 8, we decompose our project activities through WBS by breaking down complex activities into
pieces – work packages. Cost estimation can be made more accurately after each activity duration is estimated, and the resources
required for each activity are identified. It is a process of estimating individual activity costs and then adding these together to
come up with a total estimate. 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. Parametric estimating and three-point estimating are commonly utilized together
with bottom-up estimating.

9.3.6 Case Study 9.1: Estimating the Cost for M-Commerce Project’s Scope Component
Let’s continue with our example in Chapter 8. Table 9.1 is the revised resource usage calendar (Table 8.3) after resources are
leveled.
Table 9.1: Resource Usage Calendar after Resource Leveling

Resource Name Work May 2 May May May May

9 16 23 30

Systems Analyst 1 168 hrs 40 32 40 24 32

Clarify project purpose and determine project scope 40 hrs 40

Develop high-level scope 32 hrs 32

Develop high-level schedule 48 hrs 40 8

Identify main resources and develop a high-level budget 16 hrs 16

Identify key stakeholders and project team member roles 16 hrs 16

Develop project approval requirements and project exit criteria 16 hrs 16

Systems Analyst 2 144 hrs 40 0 40 24 40

Clarify project purpose and determine project scope 40 hrs 40

Identify overall project risks 40 hrs 40

9.4.2 [Link]
 Resource Name Work May 2 May May May May
9 16 23 30

Identify main resources and develop a high-level budget 16 hrs 16

Identify key stakeholders and project team member roles 24 hrs 8 16

Develop project approval requirements and project exit criteria 24 hrs 24

Sales & Marketing Expert 1 64 hrs 40 0 0 8 16

Clarify project purpose and determine project scope 40 hrs 40

Identify key stakeholders and project team member roles 24 hrs 8 16

Sales & Marketing Expert 2 64 hrs 40 0 0 8 16

Clarify project purpose and determine project scope 40 hrs 40

Identify key stakeholders and project team member roles 24 hrs 8 16

To conduct a parametric estimating, we should know the hourly rates of these four human resources. In this example, we assume
that we only use these resources, and they work full-time in project activities. Their hourly rates are given in Table 9.2 below.
Besides these four human resources, we have the project manager who is always involved in all project activities to coordinate
them and ensure that all of them are smoothly performed and completed. Therefore, we won’t assign an hourly rate to the project
manager, but a weekly rate of $2,000. The duration of “Scope” is 6 weeks. Therefore, the cost of the project manager is $12,000 for
the “Scope”.
Table 9.2: Hourly Rates of Four Team Members

Human Resources Hourly Rate Total Work Hours Total Cost for the Scope

Systems Analyst 1 $30.00 168 $5,040.00

Systems Analyst 2 $30.00 144 $4,320.00

Sales and Marketing Expert 1 $20.00 64 $1,280.00

Sales and Marketing Expert 2 $20.00 64 $1,280.00

Project Manager $2,000.00 (Weekly rate) 6 weeks $12,000.00

TOTAL $23,920

As can be seen in Table 9.2, parametric estimating has been used to calculate the total costs for the scope. For instance, systems
analyst 1 will be paid $5,040 which is the result of a multiplication of $30 by 168 hours. We also added the project manager’s six-
week cost making the total cost for the “Scope” $23,920.
Table 9.3 details the costs by activity. As can be seen in this table, work packages under 1.3 are added to compute the total cost of
1.3, and all the activities are added to compute the total cost of the “Scope”.

9.4.3 [Link]
 Table 9.3: Bottom-Up Estimating for the “Scope”

WBS Activity Name Cost

1.1 Clarify project purpose and determine project scope $4,000.00

1.2 Secure project sponsorship $0.00

1.3 Secure project charter $7,920.00

1.3.1 Develop high-level scope $960.00

1.3.2 Identify overall project risks $1,200.00

1.3.3 Develop high-level schedule $1,440.00

1.3.4 Identify main resources and develop a high-level budget $960.00

1.3.5 Identify key stakeholders and project team member roles $2,160.00

1.3.6 Develop project approval requirements and project exit criteria $1,200.00

1.4 Approval of project charter by the sponsor $0.00

1.5 Secure core resources $0.00

1.6 Initiation stage complete $0.00

Project Manager’s Salary $12,000.00

TOTAL COST OF SCOPE $23,920.00

Let’s also assume that, first, we utilized a three-point estimation for the activities of 1.3 in the initiation phase, as seen in Table 9.4,
but then we had details of each activity (e.g., requirements to be met, hours that team members should work to finish the activities)
and recruited the people by signing contracts. Table 9.4 shows the three-point estimation in a beta distribution. The calculation
below is for activity 1.3.1. After all the costs are estimated, we can add all of them to compute the total cost of 1.3 (Bottom-up
estimating).
Beta distribution:

Table 9.4: Three-Point Estimating for 1.3 of the “Scope”

WBS Optimistic Most Likely Pessimistic Cost

1.3 $7,913.33

1.3.1 735 890 1500 $965.83

9.4.4 [Link]
 1.3.2 850 1150 1600 $1,175.00

1.3.3 925 1550 1945 $1,511.67

1.3.4 515 825 1600 $902.50

1.3.5 1450 2035 3250 $2,140.00

1.3.6 880 1165 1770 $1,218.33

Project management software such as Microsoft Project will often have features designed to help project managers estimate
resource needs and constraints, and accordingly compute the costs for each activity and the overall project. Please see 9.6
“Microsoft Project Tutorials”.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK Guide),
version 3.0. Toronto, Ont: International Institute of Business Analysis. ↵
4. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 9.4: Estimating Costs and Determining Budget is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or
curated by Abdullah Oguz (MSL Academic Endeavors) .

9.4.5 [Link]
9.5: Establishing the Project Budget
Once the cost of each activity is estimated, it is possible to determine how much money is needed for each activity and component,
and the whole project. The process of subtotaling costs by category or activity is called cost aggregation. PMBOK Guide Sixth
Edition defines this process as “Determine Budget” which is a process of aggregating the estimated costs of individual activities or
work packages to establish an authorized cost baseline[1]. This baseline is a time-phased budget that can be used to measure and
monitor cost performance after it has been approved by the key project stakeholders. The aggregated budget is integrated with the
project schedule in order to produce the time-phased budget. Costs are associated with tasks, and since each task has a start date
and a duration period, it is possible to calculate how much money will be spent by any particular date during the project.
Recognizing that all the money required to deliver the project is not needed upfront, allows the cash flow needs of the project to be
effectively managed. For smaller organizations facing cash flow challenges, this can result in significant savings as the money
required to pay for resources can be transferred to the project account shortly before it is needed.
Figure 9.1 illustrates the project budget components. While estimating the costs (see section 9.3), the project team should take into
account the uncertainties that may affect the costs. This requires a reserve analysis which is conducted in line with risk
management (See Chapter 10). Therefore, cost estimates are accompanied by contingency reserves for each activity and work
package, if applicable. As can be seen in Figure 9.1, contingency reserve is included within the cost baseline. Therefore, these
reserves must be incorporated into the baseline that ensures the monitoring and controlling of the project cost performance.

Figure 9.1: Project Budget Components. Adapted from PMBOK Guide Sixth Edition
Let’s elaborate more on the reserve analysis. Contingency reserves are determined according to the risks that can be identified by
the project team. Thus, they are called “known-unknowns”. In our m-commerce project, our team identified a risk regarding the
shortage of software developers. The demand for developers increased recently since the demand for online games and mobile apps
has been on a sharp rise after the emergence of the COVID-19 pandemic. Therefore, we may experience a shortage of developers in
the market. This risk can directly affect the activities under “2. Analysis/App Requirements” and “4. Development”. Therefore, it
would be appropriate to allocate contingency reserves to each affected activity. Unlike contingency reserve, management reserve is
determined based on “unknown-unknowns” and applies to the whole budget. One obvious risk that emerged at the end of 2019 and
has had a severe impact on all countries since March 2020 is the COVID-19 pandemic. This pandemic was an unknown-unknown
for all the projects across the world.
The amount of a contingency reserve for each activity or a higher WBS level is determined after the risks and the strategies are
identified and detailed (see Chapter 10). For instance, if an activity to test a website’s functions and security is estimated to cost
$10,000, the project team can put an additional budget of $2,000 to ensure an effective response to the security gaps if occurs.
Then, the cost baseline of this activity becomes $12,000 ($10,000 + $2,000). It can be adjusted when more information becomes
available as time passes and activities are conducted and completed. It is also possible that new risks may emerge which has not

9.5.1 [Link]
been forecasted while the project management plans were being prepared. This is why project teams have regular meetings at
which all the project components, issues, and risks are reviewed, which allows the team to take timely actions.
If we turn back to Table 9.3, we can see that the contingency reserves are not determined, therefore, the cost baseline includes only
the resource costs. Let’s assume that the project team agreed on contingency reserves for three activities as shown in Table 9.5.
Therefore, the cost baseline increases from $23,920 to $24,920.
Table 9.5: Cost Estimates and Contingency Reserves for “Scope” component

WBS Activity Name Cost Contingency Reserve Cost Baseline

1.1 Clarify project purpose and determine $4,000.00 $300.00 $4,300.00

project scope

1.2 Secure project sponsorship $0.00 $0.00 $0.00

1.3 Preparation of project charter $7,920.00 $0.00 $7,920.00

1.3.1 Develop high-level scope $960.00 $0.00 $960.00

1.3.2 Identify main resources and develop a high- $1,200.00 $0.00 $1,200.00
level budget

1.3.3 Develop high-level schedule $1,440.00 $0.00 $1,440.00

1.3.4 Identify main resources and develop a high- $960.00 $400.00 $1,360.00
level budget

1.3.5 Identify key stakeholders and project team $2,160.00 $300.00 $2,460.00
member roles

1.3.6 Develop project approval requirements and $1,200.00 $0.00 $1,200.00

project exit criteria

1.4 Approval of project charter by the sponsor $0.00 $0.00 $0.00

1.5 Secure core resources $0.00 $0.00 $0.00

1.6 Initiation stage complete $0.00 $0.00 $0.00

Project Manager’s Salary $12,000.00 $0.00 $12,000.00

TOTAL COST OF SCOPE $23,920.00 1,000.00 $24,920.00

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 9.5: Establishing the Project Budget is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

9.5.2 [Link]
9.6: Managing Project Costs
A key aspect of ongoing cost management is monitoring cost estimates. Projects seldom go according to plan in every detail.
Baseline budgets often change after they have been approved. Successful project leaders understand that estimates are just that,
estimates. As new information and real experience occur, it may be necessary to revise an estimate. In some cases, the revision is
minor and does not impact the achievement of the project’s total budget. In other instances, the necessary revisions are significant,
and a new baseline needs to be created. Project managers need to discuss the ongoing management of the schedule with key
stakeholders to understand their expectations of when/how they are informed of changes that need to be made. Stakeholders’
expectations for ongoing cost management can be documented in the Cost Management Plan.
The project manager must be able to identify when costs are varying from the budget and, thus, manage these variations. A project
manager must regularly compare the amount of money spent with the budgeted amount and report this information to managers
and stakeholders. It is necessary to establish an understanding of how this progress will be measured and reported. Earned Value
Management (EVM) is an effective tool used by project managers to monitor and control these variations. We will elaborate on
EVM in Chapter 11.
If the total amount spent on a project is equal to or less than the amount budgeted, the project can still be in trouble if the funding
for the project is not available when it is needed. There is a natural tension between the financial people in an organization, who do
not want to pay for the use of money that is just sitting in a checking account, and the project manager, who wants to be sure that
there is enough money available to pay for project expenses. The financial people prefer to keep the company’s money working on
other investments until the last moment before transferring it to the project account. The contractors and vendors have similar
concerns, and they want to get paid as soon as possible so they can put the money to work in their own organizations. The project
manager would like to have as much cash available as possible to use if activities exceed budget expectations.
As explained in section 9.4, project managers keep contingency and management reserves in case risks occur and activities need
more money. In practice, most projects face uncertainties that increase costs above the original estimates. Estimating the likelihood
of such uncertainties is part of risk analysis, which is discussed in more detail in Chapter 10.

This page titled 9.6: Managing Project Costs is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

9.6.1 [Link]
9.7: Project Procurement Management
The procurement effort on projects varies widely and depends on the type of project. The “procurement cycle” reflects all
procurement-related activities from when the decision is made to outsource equipment through to the payment of bills and closing
of procurement contracts.
In less complex projects, the project team performs the work associated with procurement management. The procurement cycle
includes:
Identifying the required materials, equipment, and supplies
Identifying the potential vendors
Preparing requests for quotes (RFQs) and requests for proposals (RFPs), which include product/service specifications and a
detailed delivery schedule
Evaluating RFQs and RFPs to select the most suitable vendors
Awarding and signing contracts
Administering the contract and monitoring vendors’ performance
Managing contract changes
Closing out the contract upon work completion
On more complex projects, procurement professionals may be assigned to assist the team throughout the project’s lifetime.

9.6.1 Procurement Management Plan

In order to manage the process effectively and efficiently, we need to plan as we did for all the other knowledge areas (i.e., scope,
schedule, cost, stakeholders, communication, resources). Therefore, we need to prepare a procurement management plan to
document project procurement decisions, specify the approach, and identify potential sellers[1]. We need to think about all of the
work that we will contract out before doing anything else. We will want to plan for any purchases and acquisitions. Here’s where
we take a close look at our needs, to be sure that we need to create a contract. Therefore, we should figure out what kinds of
contracts make sense for our project, and we try to define all of the parts of our project that will be contracted out. We work out
how we manage contracts, what metrics contracts should meet to be considered successful, how we will pick a seller, and how we
will administer the contract once the work is happening.
The procurement management plan details how the procurement process will be managed. It can include the following information:
Roles and responsibilities of the project team and procurement professionals
The types of contracts we plan to use, and any metrics that will be used to measure the contractor’s performance.
The planned delivery dates for the work or products we are contracting.
The organization’s standard procurement documents and processes that our project must use and comply with.
How many vendors or contractors are involved and how they will be managed.
How purchasing may impact the constraints and assumptions of the project plan.
Coordination of purchasing lead times with the development of the project schedule.
Identification of prequalified sellers (if known).
The procurement management plan like all other management plans becomes a subsidiary of the project management plan. Some
tools and techniques we may use during the procurement planning stage include make or buy analysis and defining the contract
type.

9.6.2 Make or Buy Analysis

This means figuring out whether or not we should be contracting the work or doing it ourselves. It could also mean deciding
whether to build a solution for the organization’s or client’s needs or buy one that is already available in the market. Most of the
same factors that help us make every other major project decision will help us with this one. How much does it cost to build it as
opposed to buy it? How will this decision affect the scope of the project? How about the project schedule? Do we have time to do
the work and still meet our commitments? As we plan out what we will and won’t contract, we need to have thought through our
reasoning pretty carefully.
There are some resources (like heavy equipment) that our company can buy, rent, or lease depending on the situation. We need to
examine leasing versus buying costs and determine the best way to go forward.

9.7.1 [Link]
9.6.3 Contract Types
We should know a little bit about the major kinds of contracts so that we choose the one that creates the fairest and most workable
deal for us and the contractor. Some contracts are fixed price. No matter how much time or effort goes into them, we always pay
the same (Figure 9.2). The cost (or revenue to the vendor) is constant regardless of the effort applied or the delivery date. Some
contracts are cost reimbursable also called cost plus (Figure 9.3). This is where the seller charges us for the cost of doing the work
plus some fee or rate. In a cost reimbursable or cost-plus contract, the seller is guaranteed a specific fee. The third major kind of
contract is time and materials (Figure 9.4). That’s where the buyer pays a rate for the time spent working on the project and also
pays for all the materials used to do the work. In a time and materials contract, the cost (or revenue to the vendor) increases with
increased effort.

Figure 9.2: A fixed-price contract

Figure 9.3: A cost reimbursable or cost plus

9.7.2 [Link]
 Figure 9.4: A time and materials contract
Contractual agreements with vendors often require partial payment of their 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.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 9.7: Project Procurement Management is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

9.7.3 [Link]
9.8: Microsoft Project Tutorial
For the MS Project tutorial, let’s continue with our example of the project for developing a mobile application. Here, we are
building upon the Chapter 8 tutorial. Therefore, we are working on “1. Scope” (Table 9.6). This table also includes the duration,
start and finish dates, and predecessors.
Table 9.6: WBS for the Scope Activities of the M-Commerce Project

WBS Task Name Duration Start Finish Predecessors

1 Scope 35 Days Mon Mon

5/2/22 6/20/22

1.1 Clarify project purpose and determine project scope 5 days Mon Fri 2
5/2/22 5/6/22

1.2 Secure project sponsorship 1 day Mon Mon 3

5/9/22 5/9/22

1.3 Preparation of project charter 22 days Tue Wed

5/10/22 6/8/22

1.3.1 Develop high-level scope 4 days Tue Fri 3

5/10/22 5/13/22

1.3.2 Identify overall project risks 5 days Mon Fri 5

5/16/22 5/20/22

1.3.3 Develop high-level schedule 6 days Mon Mon 5

5/16/22 5/23/22

1.3.4 Identify main resources and develop a high-level budget 2 days Tue Wed 7
5/24/22 5/25/22

1.3.5 Identify key stakeholders and project team member roles 8 days Mon Wed 5,6
5/23/22 6/1/22

1.3.6 Develop project approval requirements and project exit 5 days Thu Wed 5,6,7,8,9
criteria 6/2/22 6/8/22

1.4 Approval of project charter by the sponsor 2 days Thu Fri 10

6/9/22 6/10/22

1.5 Secure core resources 5 days Mon Fri 11

6/13/22 6/17/22

1.6 Initiation stage complete 0 days Mon Mon 12

6/20/22 6/20/22

We identified the resources in Chapter 8. Now, in the Resource Sheet, we can type the standard rates of resources (Figure 8.8).

9.8.1 [Link]
 Figure 9.5: Resource Sheet
In the Resource Sheet, there are three types of resources:
1. Work: Work resources are people and equipment. They have a standard rate per hour.
2. Material: Material resources are consumable supplies. They have a unit of measurement such as tones, boxes, and cubic yards.
3. Cost: Cost resources are independent costs we want to associate with a task such as a plane ticket.
In Table 9.5 (Section 9.4), we determined contingency reserves for three activities. As seen in Figure 9.5 above, contingency
reserves were indicated as a “Cost” type which is independent of hourly work. For activity 1.1, let’s double-click on the activity
row. The “Task Information” window will pop up. Then, let’s click the “Resources” tab. For the work type resources (i.e., Sales and
Marketing Experts and Systems Analysts), the cost is calculated automatically based on the hours worked. For the cost type, we
must type the cost on this window. For activity 1.1, the contingency reserve is $300 (Figure 9.6).

Figure 9.6: Resources tab on the Task Information window

When we finish typing the contingency reserves for the other two activities, the Gantt Chart will be as in Figure 9.7.

9.8.2 [Link]
 Figure 9.7: Gantt Chart with the resources indicated on the right of the bars
In this tutorial, we ignore the project manager’s salary. As seen in Figure 9.8, we can insert a new column “Cost” to the left of
Resource Names, and therefore, we can directly see the cost per activity on the main window (Gantt Chart view).

Figure 9.8: Adding a cost column to the right of Resource Names

This page titled 9.8: Microsoft Project Tutorial is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

9.8.3 [Link]
9.9: Key Takeaways
Key Takeaways
Allocation of resources provides the project manager to determine the overall project budget most of which is spent on
resources.
Three types of project costs are direct costs, direct overhead costs, and general administrative costs.
The project cost management plan is one of the sub-plans of our overall project plan, and it provides guidelines to project
managers on how to estimate, budget, manage, monitor, and control project costs.
The techniques to estimate costs are expert judgment, analogous estimating, parametric estimating, three-point estimating, and
bottom-up estimating. Generally, project managers utilize some of the techniques together to estimate the activity costs.
The process of subtotaling costs by category or activity is called cost aggregation. This process leads to the establishment of a
cost baseline which is a time-phased budget that can be used to measure and monitor cost performance after it has been
approved by the key project stakeholders.
Funds allocated to deal with known-unknowns are called contingency reserves. The monetary amount of contingency reserves
is determined after the risks and the strategies to mitigate risks’ impact are identified and detailed.
Projects seldom go according to plan in every detail. Baseline budgets often change after they have been approved.
A project procurement management plan documents project procurement decisions, specify the approach, and identify potential
sellers.
Project teams should figure out whether to build a solution for the organization’s or client’s needs or buy one that is already
available in the market.
The most common contract types are fixed-price, cost reimbursable or cost plus, and time and materials contracts.

This page titled 9.9: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

9.9.1 [Link]
9.10: Questions and Exercises
There are 7 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 9.10: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

9.10.1 [Link]
9.11: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 9.11: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

9.11.1 [Link]
 CHAPTER OVERVIEW

10: Project Risks

10.1: Learning Objectives and Overview
10.2: Project Risk
10.3: Risk Management Plan
10.4: Identifying Risks
10.5: Risk Assessment
10.6: Developing and Implementing Risk Responses
10.7: Key Takeaways
10.8: Questions and Exercises
10.9: Attribution

This page titled 10: Project Risks is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

1
10.1: Learning Objectives and Overview
Learning Objectives
1. Define project risks and differentiate between risk types.
2. Identify risks that may occur during the implementation of a project.
3. Describe the process to create a project risk management plan.
4. Conduct a qualitative risk analysis.
5. Develop and implement risk responses based on identification and analysis of risks.

Overview
Although project managers can prepare a well-thought-out and comprehensive project scope, schedule and cost management plans,
they cannot ensure that all these plans are free of problems that may occur due to numerous reasons during the project. Even the
most carefully planned projects can run into trouble. No matter how well we plan, our project can always encounter unexpected
problems. Team members get sick or quit, resources that we depend on turn out to be unavailable, even the weather can throw us
for a loop (e.g., a snowstorm). So, does that mean that we are helpless against unknown problems? No! We can use risk planning to
identify potential problems that could cause trouble for the project, analyze how likely they are to occur, take action to prevent the
risks we can avoid, and minimize the ones that we can’t. In this chapter, we will discuss both negative risks (i.e., threats) and
positive risks (i.e., opportunities). A project manager must always keep in mind that risks mean uncertainties, not solely problems
or threats all the time, since they are sometimes opportunities that we should consider exploiting. There are no risk-free projects
because there is an infinite number of events that can have a negative or positive effect on projects. Project managers must be
prepared to deal with uncertainties. Planning for events that can delay a project, decrease its quality, or increase its budget is a
necessary part of project planning.

This page titled 10.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

10.1.1 [Link]
10.2: Project Risk
Risks are an aspect of uncertainty [1]. Therefore, an uncertainty is not equal to a risk. Risks can be measured while uncertainties
cannot be. That is, potential outcomes of a risk can be described whereas it wouldn’t be possible to determine the outcomes for
uncertainties. Risks can be controlled if response strategies can be defined and monitored during the project. Project team can
respond to a risk if the risk triggers are identified and there is an owner of the risk who monitors the risk among other factors. Thus,
when the project teams discuss all possible uncertainties in the initiation and planning stages, they determine the occurrence
probability and the impact scale. For example, in our m-commerce project, testers may not determine some of the important code
errors, which might lead to rework, schedule slippage and cost overruns. Considering the previous projects and lessons learned, we
can predict the probability and how it may affect the project if the risk occurs. However, we can never be sure that this tester has
malicious intentions to help a strong competitor. This would be an uncertainty, not a risk.
Project risk is an uncertain event or condition that, if occurs, has a positive or negative effect on one or more project objectives [2].
Risks exist in all projects. It is of high importance to keep in mind that a risk does not always create negative outcomes, but can
lead to positive outcomes. The subsections 10.1.1 and 10.1.2 below elaborate on both types of risk with examples.

10.1.1 Negative Project Risks

It is the reality that project teams mostly encounter negative risks. These risks might jeopardize the well-being of a project’s
progress and lead to failure if they occur. Some examples of a negative project risk are:
Machines can fail in the middle of a critical activity.
A vendor may not dispatch raw materials on time, or they may be damaged during a long journey from the vendor’s or
supplier’s country to our project’s location.
A key human resource for an activity may become sick or may find a better job and leave the organization.
Projects that depend on good weather, such as road construction projects, face risk of delays due to exceptionally wet or windy
weather.
Safety risks are also common on construction projects.
Changes in the value of local currency during a project affect purchasing power and budgets on projects with large international
components.

A short example for negative risks:

A construction company is building a 20-storey building in a Northeastern state, and they are expected to finish it by February.
However, the project team is aware of the fact that winter is not a preferred season to carry out construction works, and the adverse
weather conditions may disrupt activities leading to schedule delays and cost overruns. This is why the project team should
evaluate all the possible risks that may result from inclement weather such as snowstorms. Project team can obtain the long-term
historical data and seasonal forecasts from the National Weather Service, and can monitor the daily and weekly weather forecast.
A short example for negative risks:
A construction company is building a 20-storey building in a Northeastern state, and they are expected to finish it by February.
However, the project team is aware of the fact that winter is not a preferred season to carry out construction works, and the adverse
weather conditions may disrupt activities leading to schedule delays and cost overruns. This is why the project team should
evaluate all the possible risks that may result from inclement weather such as snowstorms. Project team can obtain the long-term
historical data and seasonal forecasts from the National Weather Service, and can monitor the daily and weekly weather forecast.

10.1.2 Positive Project Risks

Some uncertainties that we are not 100% sure that they may be materialized can make it easier to achieve a project’s objectives.
When this type of uncertain happens, the risk is positive and is therefore referred to as an opportunity. Some examples for positive
risks can be described below:
The potential of finding an easier way to do a task
Acquiring some materials in exchange for lower prices than estimated
A potential change in organizational process that can accelerate the procurement of some materials
A new technology that has been developed and can be introduced to the market while we carry out the project
A grant our organization had applied, which can provide more funds to our project if accepted

10.2.1 [Link]
As for the five positive risks above, a project manager’s response strategy would be exploit or enhance (among five alternative
strategies in total – see 10.5.2) when they occur.
A short example for positive risks:
Company XYZ is thinking of developing a new electric toothbrush which customers are asking for according to the consumer
surveys across the USA. Project team prepared all the plans, and estimated that this project will take nine months to finish. At the
end of the project, the new toothbrush can be introduced to the market. During the development and testing of various toothbrush
types, project team will use a 3D printer to create prototypes. While working on the risk management plan, team has been aware of
ongoing research on a new 3D printer that is faster and can print more durable items with more details. Based on the analysis, team
found that this new printer can expedite the project. If this positive risk occurs during the project, it can expedite the project by one
month resulting in a 8-month project duration. So, project team decided to allocate a contingency reserve for this opportunity. If the
3D printing company can make this new printer available to the market around the fifth month of the project at the latest, project
team can purchase it. The estimated cost for this new printer was determined as $25,000. Therefore, this money will be placed as a
contingency reserve.

10.1.3 Known-Unknowns and Unknown-Unknowns

As discussed in Chapter 9 for contingency and management reserves, risks can be categorized as known-unknowns or unknown-
unknowns. As regards known-unknowns, we can identify these risks in the planning stage, and estimate costs, and additional
schedule and resources needed, if they occur. The costs allocated to compensate for managing these risks are named “contingency
reserve”. However, it is not always possible for project teams to predict all the risks. Therefore, a management reserve is assigned
besides the cost baseline (in which contingency reserves are accounted for). One obvious risk that emerged at the end of 2019 and
has had a severe impact on all countries since March 2020 is the COVID-19 pandemic. This pandemic was an unknown-unknown
for all the projects across the world. Some projects were able to overcome the issues by using their management reserves besides
contingency reserves. However, numerous projects failed although they had contingency and management reserves since the
impact of this pandemic exceeded the projects alone.

10.1.4 Individual and Overall Project Risks

Besides the categorization of risks as negative and positive, and as known-unknowns and unknown-unknowns, another
categorization would be individual and overall project risks. Individual risks can affect the achievement of project objectives, and
disrupt some activities, decisions, components, or deliverables. They can affect only one or some of the activities, but not always
the whole project. If a risk has an impact on the project as a whole, this risk is considered an overall project risk. Let’s consider the
case study of “Grocery LLC’s M-Commerce Project” (see 4.4.3 for the WBS). One project objective can be formulated as “to
complete the elicitation of mobile app requirements as well as budget, schedule and resource estimates on which all the key
stakeholders agree”. The activity 2.3 “Review specifications with team and stakeholders” is essential to identify the requirements
that address all stakeholders’ expectations and concerns. However, some of the stakeholders may not agree on some of the
requirements (see 5.2.2 for all the stakeholders in this project). Priorities of the top management, project sponsor, and product
owner might not always overlap with one another. When the project team and team members review risks, they need to consider all
possible risks that may affect the activity 2.3 and the overall project. If the conflict among stakeholders affects this objective, and
therefore the activity 2.3, this would be counted as an individual project risk. Project team should create a contingency budget and
schedule for this activity. If there is a risk of obtaining fund to conduct project activities, this would have an impact on the whole
project, and will affect the overall project objective that aims at creating a mobile app. Project team must also develop risk response
strategies to tackle with this risk. Besides, project team can determine an acceptable range of negative and positive variations for
overall risks.

1. Project Management Institute. (2021) PMBOK® Guide (7th ed). Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute ↵

This page titled 10.2: Project Risk is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

10.2.2 [Link]
10.3: Risk Management Plan
The risk management plan is a component of the project management plan that describes how risk management activities will be
structured and performed[1]. This plan tells us how we are going to handle individual and overall risks in our project. It documents
how we will identify and analyze risks, who will be responsible for doing it, and how often we will review the risks (since we have
to meet about risk planning with the project team throughout the project.)
This plan allows the project team to reduce the likelihood of negative surprises (problems, weaknesses, and threats), proactively
take advantage of positive risks (opportunities), and ensure risk management is considered when schedules, budgets, and other
management plans are developed. Creating and maintaining a risk management plan significantly increases the likelihood of
project success. The risk management plan identifies the processes and procedures to be used in managing risk throughout the life
of the project. It includes a number of key sections such as risk sources, categories, assessment definitions (e.g., very high to very
low), probability/impact assessment (matrix), roles and responsibilities, budget and schedule estimates for risk-related activities,
and the risk register. Like the other knowledge area (e.g., scope, schedule, stakeholder) management plans, the risk management
plan is integrated into the project management plan, and must be aligned with all the subplans and the project management plan.
The risk management plan can consist of some or all of the following items:
Methodology
What kind of approaches, tools, and data sources will be utilized to perform risk management activities (e.g., risk
identification, risk assessment, risk response strategies)?
g., checklists, risk indicator scales, probability-impact matrices, informal direct risk assessment, probabilistic modeling.
Risk strategy
Roles and responsibilities
The guidelines how identified risks will be assigned to team members, and how these risk owners will take care of risks, and
monitor them.
Risk categories
Risks can be grouped into high-level categories to facilitate the identification of individual risks. Some of the categories can
be technical, cost, schedule, client, contractual, weather, financial, political, environmental, and people.
Similar to a WBS (Work Breakdown Structure), RBS (Risk Breakdown Structure) would be a very helpful tool (Table 10.1).
Risk probability and impact
Level and percentage of probabilities and impact of negative and positive risks
Which project aspects will be included in the impact analysis (e.g., scope, quality, schedule, cost, safety, environment)?
Risk register
How will the risk register be structured?
Components such as risk ID, description, risk owner, probability, and impact (see 10.3)
Risk response plan
How will risk response plan be structured?
Strategies for negative and positive risks, and individual and overall project risks.
Funding of reserves
How will contingency and management reserves be determined and released?
Reporting formats
Reporting formats and frequency should be in alignment with other project plans.
Table 10.1: An Example of a Risk Breakdown Structure (RBS)
Adapted from Project Management Institute’s Learning website[2]

Level 0 Level 1 Level 2 Level 3

Project Risk Management Corporate History/experience/culture

Organizational stability

10.3.1 [Link]
 Financial

Team Management Poor team communication

Changes in the core team

Inadequate number of staff

Customer & Stakeholder Requirements

Communication issues

Contractual

External Environmental Physical environment

Facilities/site

Local services

Pollution risk

Community protests

Legal & Political Political

Legal/regulatory

Interest groups

Economic Labor market

Labor conditions

Currency

Inflation rate

Technical Requirements Scope uncertainty

Scope creep

Complexity

Issues with stakeholders

Performance Technical limits

Quality

10.3.2 [Link]
 Rework

Evaluation criteria

Application Organizational experience

HR skill sets and experience

Physical resources

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Retrieved from [Link]

This page titled 10.3: Risk Management Plan is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

10.3.3 [Link]
10.4: Identifying Risks
A more disciplined process involves using checklists of potential risks and evaluating the likelihood that those events might happen
on the project. Some companies and industries develop risk checklists based on experience from past projects. These checklists can
be helpful to the project manager and project team in identifying both specific risks on the checklist and expanding the thinking of
the team. The past experience of the project team, project experience within the company, and experts in the industry can be
valuable resources for identifying potential risk on a project.
When risks are identified, they are recorded in a risk register. It is a key tool that helps project teams keep track of the status of
risks, ensure response plans are effectively implemented, and new risks are managed. The register is an output of the process of
identifying project risks. The project charter can involve some of the risks, generally the overall risks. After the WBS and activity
list are created, and the schedule, resources and cost are estimated for all the activities, the project team can identify the risks more
easily. Project team must review this register periodically by assigning each risk to a team member.
Risk register can be composed of the items below:
Risk ID
Description
Related WBS activity or activities
Risk owner (Name of the team member who monitors the risk)
Risk trigger (How do we know the risk is becoming an issue or has reached a point that requires action?)
Risk category (based on RBS categories)
Probability (How likely does the risk occur?)
Impact (How will the risk affect the project if it occurs? E.g., schedule delay, budget overrun, quality issues)
Probability-Impact Score (Multiplying probability percentage by impact percentage)
Risk response strategy (see 10.5)
Description of the response (see 10.5)
Response owner (if different from the risk owner)
Expected impact of the response (What result do we expect from the response?)
Table 10.2 illustrates a short version of a sample risk register for Grocery LLC’s M-Commerce Project. Only six columns have
been included in this risk register.
Table 10.2: An Example of a Risk Register

ID Risk Category Related WBS Description Risk Owner Risk Trigger

Activity

1.0 Financial Overall project Cost estimates Systems Analyst 1 If the CPI (cost
may be exceeded performance
considering the index) drops below
factors of inflation 0.90, we will need
and foreign to seek additional
exchange currency funding from
rates. management.

2.2 Management 2.1 The demand on the Systems Analyst 2 Ten days before
2.2 developers the “Analysis/App
increased recently Requirements”
2.3 since the demand component starts,
2.4 for online games we must assure
2.5 and mobile apps that Developer 1
have been on a starts working in
sharp rise after the project activities.
emergence of
COVID-19
pandemic. We may
experience a
shortage of

10.4.1 [Link]
 developers in the
market.

2.5 Management & Technical Overall project Risk of building an Project Manager Project manager
app that our target should review each
users don’t want. activity’s tasks and
performance with
the core team and
the project sponsor
to detect any
potential risks.

Weekly risk
review meetings

This page titled 10.4: Identifying Risks is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

10.4.2 [Link]
10.5: Risk Assessment
After the potential risks have been identified, the project team evaluates the risks based on the probability of occurrence and impact
if they occur. This is a qualitative risk analysis method. In this textbook, we will not discuss quantitative risk analysis process.
Readers can check “11.4 Perform Quantitative Risk Analysis” in PMBOK Guide Sixth Edition for an overview of quantitative risk
analysis methods.
Not all risks are equal. Some risk events are more likely to happen than others, and the impact of a risk event can vary greatly.
Therefore, project teams perform qualitative risk analysis in order to prioritize individual project risks by assessing their probability
of occurrence and impact[1]. This assessment technique is conducted by the project team. Team members indicate their opinions
regarding each risk. Therefore, this kind of process introduces bias into the assessment. However, project manager assumes the role
of a facilitator or a moderator to minimize the bias by implementing techniques such as Delphi. Besides, in order to minimize the
bias and provide a consensus, the project manager should clarify the underlying mechanism of how each team member and expert
justify their perceptions as regards the probability and impact.
For the qualitative risk analysis, let’s use a five-scale measure: Very low, low, medium, high, and very high (Table 10.3). It is
always possible to have more and fewer number of scales. Each level may correspond with different percentage values depending
on the project, project manager, and organizational policies. Table 10.2 displays two different percentages of probability.
Organizations may have an overarching policy to implement levels, percentages, and risk categories. In this case, project manager
must comply with this policy.
Table 10.3: Risk Probability Levels

Level Names Level Values (%) Alternative Level Values (%)

Very low 5% 10%

Low 10% 30%

Medium 30% 50%

High 50% 70%

Very High 70% 90%

The probability, alone, wouldn’t make sense if we disregard the impact of the risk. Just think that our project is in an area where a
large earthquake hits every thirty years. Since the frequency doesn’t look high, we can give a very low probability level (5%).
However, we should consider the impact of an earthquake if it occurs. Although the probability may be 5%, the impact of an
earthquake to disrupt project activities would be high. Even in our m-commerce project, an earthquake would have a number of
negative effects such as power outages, water supply problems, transportation issues, supply chain problems, and in a worse
scenario, destroyed buildings and infrastructure, and fatalities. This is also the case for an epidemic or pandemic. Therefore, we can
decide on a very high impact value (0.9) while the probability is 0.05.
Table 10.4 displays the impact levels and values for the impact of risks on schedule. Project managers can use criteria for different
areas such as schedule, cost, safety, environment and quality to determine the impact of level. For each area, description for each
impact level should be described to eliminate ambiguities. According to Table 10.4, if an activity takes 10 days to finish, and we
found that a risk may add an additional 1 day, it means that we have a delay by 10%. Therefore, the impact is low, and its value is
0.3.
Table 10.4: Description of Impact Levels Regarding Schedule

Impact Description Value

Very low Delay by 5% 0.1

10.5.1 [Link]
 Low Delay by 10% 0.3

Medium Delay by 20% 0.5

High Delay by 40% 0.7

Very High Delay by 50% 0.9

When we use several areas besides schedule, we should formulate how to generate an overall impact level. We can use a non-
weighted or a weighted model to combine all areas’ values. Table 10.5 shows the impact levels regarding cost.
Table 10.5: Description of Impact Levels Regarding Cost

Impact Description Value

Very low Budget overrun by 5% 0.1

Low Budget overrun by 10% 0.3

Medium Budget overrun by 20% 0.5

High Budget overrun by 40% 0.7

Very High Budget overrun by 50% 0.9

Table 10.6 displays the risk severity score which is found by multiplying probability by impact percentages. In Table 10.6, there are
three severity levels: (1) Green indicates low-level severity, which is between 0% and 15%, inclusive, (2) Orange indicates
medium-level severity, which is between 16% and 40%, inclusive, and (3) Red indicates high-level severity, which is at 41% and
above.
Table 10.6: Probability – Impact (Severity) Score

Probability

Very low Low Medium High Very High

0.05 0.10 0.30 0.50 0.70

Impact Very Low 0.10 0.01 0.01 0.03 0.05 0.07

Low 0.30 0.02 0.03 0.09 0.15 0.21

Medium 0.50 0.03 0.05 0.15 0.25 0.35

High 0.70 0.04 0.07 0.21 0.35 0.49

Very High 0.90 0.05 0.09 0.27 0.45 0.63

Not all project managers conduct a formal risk assessment on projects. There may be barriers to identifying risks. David Parker and
Alison Mobey (Parker & Mobey, 2004)[2] found in a phenomenological study of project managers that there was a low
understanding of the tools and benefits of a structured analysis of project risks. The lack of formal risk management tools was seen

10.5.2 [Link]
as a barrier to implementing a risk management program. The level of investment in formal risk management was also associated
with managerial psychological dimensions.
Some project managers are more proactive and will develop elaborate risk management programs for their projects. Other
managers are reactive and are more confident in their ability to handle unexpected events without prior planning, while some
managers are risk averse and prefer to be optimistic and not consider risks or to avoid taking risks whenever possible.
In projects with low complexity, the project manager may informally track items that may be considered risk items. On more
complex projects, the project management team may develop a list of items perceived to be higher risk and track them during
project reviews. On projects with greater complexity, the process for evaluating risk is more formal with a risk assessment meeting
or series of meetings during the life of the project to assess risks at different phases of the project. On highly complex projects, an
outside expert may be included in the risk assessment process, and the risk assessment plan may take a more prominent place in the
project execution plan.
On complex projects, statistical models are sometimes used to evaluate risk because there are too many different possible
combinations of risks to calculate them one at a time. These are considered as quantitative risk analysis. One example of the
statistical model used on projects is the Monte Carlo simulation, which simulates a possible range of outcomes by trying many
different combinations of risks based on their likelihood. The output from a Monte Carlo simulation provides the project team with
the probability of an event occurring within a range and for combinations of events. For example, the typical output from a Monte
Carol simulation may reflect that there is a 10 percent chance that one of the three important pieces of equipment will be late and
that the weather will also be unusually bad after the equipment arrives.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Parker, D., & Mobey, A. (2004). Action Research to Explore Perceptions of Risk in Project Management. International Journal
of Productivity and Performance Management 53(1), 18–32. ↵

This page titled 10.5: Risk Assessment is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

10.5.3 [Link]
10.6: Developing and Implementing Risk Responses
After the risks are identified, described, and assigned to a team member to keep track, and their probability and impact scores are
produced, hence risks are prioritized, the project team can continue with planning the risk responses. Which strategy and the action
does the team have in order to respond to the risk’s negative or positive impact? These strategies depend on factors such as whether
the risk is negative or positive, and its severity or significance. Project managers can utilize mathematical optimization models or
real options analysis as a basis for a more robust economic analysis of alternative risk response strategies in projects with a greater
complexity[1].

10.5.1 Strategies Developed for Negative Risks (Threats)

The project team responds to negative risks in various ways:
1. Escalation
2. Avoidance
3. Transfer
4. Mitigation
5. Acceptance
Each of these responses can be an effective tool in reducing individual risks as well as the overall risk profile of the project. The
risk response plan captures the risk management approach for each identified risk event and actions the project management team
will take to manage the risk.
Escalation is implemented when the threat is outside of the scope of the project, and it is beyond the project manager’s control, that
is the project manager isn’t capable of developing and implementing a response to this threat. Therefore, project manager should
escalate the risk to a higher authority such as project sponsor, project steering committee, or the client. If there is a resource conflict
with another project in our organization, it would be a wise move to escalate this issue to the sponsor or top management so that it
can be solved at the program or portfolio level, or at the organizational level. Risks or issues related to project objectives, resource
and inter-group conflicts, ambiguous roles and responsibilities, scope disagreements, third party dependencies are some known
situations calling for escalations. Such issues require higher level intervention because many times the authority, decision making,
resources or effort required to resolve them are beyond a project manager’s horizon. At times, the project manager may want to
involve higher authorities for information-only escalations to keep them abreast of potential issues in the project. Escalation should
be treated as a professional act and should be done in an effective way. Project managers should escalate timely if something is
blocking the project and is beyond the project manager’s control. One should not hesitate to escalate within the performing
organization and in the client’s organization as well. A proactive escalation and risk communication is far better than unpleasant
surprises requiring costly fixes to the project[2].
Risk avoidance usually involves developing an alternative strategy with a higher probability of success, but, usually, the associated
cost of task completion also becomes higher. A common risk avoidance technique is using proven and existing technologies rather
than adopting new techniques, even though the new techniques may show promise of better performance and/or lower costs. A
project team may choose a vendor with a proven track record over a new vendor that is providing significant price incentives to
avoid the risk of working with a new vendor. Alternatively, a project team that requires drug testing for team members is practicing
risk avoidance by attempting to evade damage done by someone under the influence.
Risk mitigation is a response to a risk that cannot be avoided or if it is unwise to avoid it (due to risk avoidance strategies being too
expensive, too time-consuming, etc.). In this case, the project team is attempting to reduce the likelihood and impact of a risk. For
instance, assigning highly skilled resources to an activity or performing more tests to detect irregularities and problems reduces the
likelihood and impact of errors occurring. In product development projects, teams can develop prototypes to mitigate the risks by
obtaining early feedback on requirements by providing a model of the expected product before actually building it. These
prototypes can be small-scale products, computer generated 2D and 3D models, mock-ups, or simulations[3].
Risk transfer is a risk reduction method that shifts the ownership of a threat from the project to another party. The purchase of
insurance on certain items is a risk-transfer method. The risk is transferred from the project to the insurance company by paying a
risk premium to another party that takes on the risk. A construction project in the Caribbean may purchase hurricane insurance that
would cover the cost of a hurricane damaging the construction site. The purchase of insurance is usually connected to risks that can
significantly impact the project while being out of the project team’s control, such as weather, accidents, sharp fluctuations in

10.6.1 [Link]
currency, political unrest, and labor strikes. Using performance bonds, warranties and guarantee, and establishing agreements are
also considered as responses to transfer the risks.
The fifth strategy, risk acceptance, involves doing nothing in response to the risk. The acceptance response is a good one when the
likelihood and impact of a risk are low. In some cases, little else can be done about the risk, leading to acceptance being the only
feasible option. When this response is chosen, an active strategy to deal with the risk would be to establish a contingency reserve
that includes funds, time and/or resources to handle the threat.

10.5.2 Strategies Developed for Positive Risks (Opportunities)

As previously mentioned, positive risks (opportunities) are uncertainties that, if materialized, will have a positive impact on the
project. The strategies to deal with positive risks can be listed as follows:
1. Escalation
2. Exploitation
3. Sharing
4. Enhancing
5. Acceptance
Escalation of positive risks has the same process as is for negative risks. When the client tells the project manager that they are
considering adapting the product for a different market and asks if we are interested in bidding for the work, we can escalate this
opportunity to the project sponsor[4]. Another escalation strategy can be implemented when a team member identifies an
opportunity to create a new value stream for the business. This opportunity is escalated for senior management attention[5].
Risk exploitation can be considered analogous to risk avoidance strategy in negative risks. Risk exploitation strategy attempts to
eliminate the uncertainty and ensure the occurrence of the opportunity. An example of this could be pursuing a bonus that is
available only if an activity is completed early. In this case, the project team will reallocate resources in order to ensure the activity
finishes early and the bonus is obtained. Project managers can use new technologies or technology upgrades to reduce cost and
duration by means of this strategy.
Risk-sharing can be considered analogous to risk transfer strategy in negative risks. It involves partnering with others to share
responsibility for the risk. Partnering with another company via risk-sharing partnerships or joint ventures to share the risk is
advantageous when the other company has the expertise and experience that the project team lacks. This increases the likelihood of
the opportunity materializing and, if it does, both organizations share the gains.
Risk enhancement can be considered analogous to risk mitigation strategy in negative risks. This strategy attempts to increase the
probability and/or impact of an opportunity. However, it does not seek to ensure its occurrence. Project teams need to focus on the
causes of an opportunity to take the advantage of it. For one component of our project, we were aware of that an investor is
interested in the deliverables of this component since their non-profit organization can benefit from them. We can communicate
with this investor and their non-profit organization to learn more about their objectives.
The fifth strategy is the risk acceptance which is also used for negative risks. This risk strategy involves doing nothing in response
to the positive risk (opportunity). This acceptance response is a good one when the likelihood and impact of a risk is low, or taking
action is too costly or it needs a disproportionate amount of effort compared to the size of the work in the project and the benefit we
can have. For example, for an activity, we want to have two highly-skilled engineers who work at another project. If we can
convince them, we believe that we can have a better quality in our new product development, and we can finish this activity earlier.
However, their project manager isn’t willing to release them since they are key people in that project. Thus, we just accept this risk,
and decide to do nothing.

10.5.3 Contingency Plan

The project risk plan balances the investment of the risk response implementations against the benefit for the project. The project
team often develops an alternative method for accomplishing a project goal when a risk event has been identified that may frustrate
the accomplishment of that goal. These plans are called contingency plans. The risk of a truck drivers’ strike may be mitigated with
a contingency plan that uses a train to transport the needed equipment for the project. If a critical piece of equipment is late, the
impact on the schedule can be mitigated by making changes to the schedule to accommodate a late equipment delivery.
Contingency funds are funds set aside by the project team to address unforeseen events that cause the project costs to increase.
Projects with a high-risk profile will typically have a large contingency budget. Although the amount of contingency allocated in

10.6.2 [Link]
the project budget is a function of the risks identified in the risk analysis process, contingency is typically managed as one line item
in the project budget.
Some project managers allocate the contingency budget to the items in the budget that have high risk rather than developing one
line item in the budget for contingencies. This approach allows the project team to track the use of contingency against the risk
plan. This approach also allocates the responsibility to manage the risk budget to the managers responsible for those line items. The
availability of contingency funds in the line item budget may also increase the use of contingency funds to solve problems rather
than finding alternative, less costly solutions. Most project managers, especially on more complex projects, manage contingency
funds at the project level, with approval of the project manager required before contingency funds can be used.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Retrieved from [Link]
management/#:~:text=Project%20managers%20should%20escalate%20timely,the%20client's%20organization%20as%20well.
↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
4. Retrieved from [Link]
ID=350338&thisPageURL=/articles/350338/Risk-Escalation#_=_↵
5. Retrieved from [Link]
ID=350338&thisPageURL=/articles/350338/Risk-Escalation#_=_↵

This page titled 10.6: Developing and Implementing Risk Responses is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or
curated by Abdullah Oguz (MSL Academic Endeavors) .

10.6.3 [Link]
10.7: Key Takeaways
Key Takeaways
Project risk is an uncertain event or condition that, if occurs, has a positive or negative effect on one or more project objectives.
Contingency reserve is allocated for known-unknowns whereas management reserve is allocated for unknown-unknowns.
The risk management plan is a component of the project management plan that describes how risk management activities will
be structured and performed.
When risks are identified, they are recorded in a risk register. It is a key tool that helps project teams keep track of the status of
risks, ensure response plans are effectively implemented, and new risks are managed.
Project teams perform qualitative risk analysis in order to prioritize individual project risks by assessing their probability of
occurrence and impact.
The strategies to respond negative risks are escalation, avoidance, transfer, mitigation, and acceptance.
The strategies to respond positive risks are escalation, exploitation, sharing, enhancing, and acceptance.
The project team develops contingency plans as an alternative method for accomplishing a project goal when a risk event has
been identified.

This page titled 10.7: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

10.7.1 [Link]
10.8: Questions and Exercises
There are 11 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 10.8: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

10.8.1 [Link]
10.9: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 10.9: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

10.9.1 [Link]
 CHAPTER OVERVIEW

11: Monitoring and Controlling

11.1: Learning Objectives and Overview
11.2: Monitoring and Controlling Project Work
11.3: Qualitative Monitoring
11.4: Earned Value Management (EVM)
11.5: Change Control Process
11.6: MS Project Tutorial
11.7: Key Takeaways
11.8: Questions and Exercises
11.9: Attribution

This page titled 11: Monitoring and Controlling is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

1
11.1: Learning Objectives and Overview
Learning Objectives
1. Explain the monitoring and controlling process and differentiate between monitoring and controlling.
2. Describe qualitative monitoring for project management knowledge areas except for schedule and cost.
3. Describe Earned Value Management (EVM), a quantitative monitoring tool, to monitor and control of the progress of project
activities.
4. Define the change control process.

Overview
The monitoring and controlling process differentiates from other processes (i.e., initiating, planning, executing, and closing out), in
that, it spans throughout the whole project. Project managers should ensure that everything is on track (e.g., scheduled activities are
completed on time, there is no budget overrun), and take the project back on track if it deviates from its three main baselines, which
are triple (iron) constraints, scope, schedule and cost, and other constraints such as quality and resources, and the satisfaction of the
client and stakeholder eventually. Project managers implement a holistic approach by focusing on all the aspects of a project to
keep the project on track and accomplish a successful closeout where the client and stakeholders are satisfied with the project
outcomes. There are various techniques utilized to monitor and control the projects, which have been discussed in sections 11.2 and
11.3 in this chapter.

This page titled 11.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

11.1.1 [Link]
11.2: Monitoring and Controlling Project Work
Before the project gets approval to continue, business (or systems) analysts, or a team of analysts and product owners combined
with representatives of business units and other relevant stakeholders create a business case and benefits realization management
plan. Project managers may also participate in this process if the organization has a PMO (see Chapters 2 and 3). At the very
beginning of the project, that is the initiation phase, the project charter is prepared, and with the approval of the project sponsor and
the client, project plans are built upon those documents and processes in order to elaborate on the main pillars of the project (i.e.,
scope, schedule, cost, quality, risks, resources, and stakeholders). While establishing a strong baseline is a key factor in project
success, ineffective monitoring and controlling can spoil all the efforts that were done to establish this strong baseline. Let’s
remember the causes which lead to project failure to meet the project activities as discussed in Chapter 1 under “1.4 Project
Success”. According to the PMI 2020 Pulse of the Profession report[1], the factors responsible for the failure were listed as a lack of
clearly defined and/or achievable milestones and objectives to measure progress (37%), poor communication (19%), lack of
communication by senior management (18%), employee resistance (14%), and insufficient funding (9%). The monitoring and
controlling process relies on clearly defined milestones and objectives to measure progress. One of the key responsibilities of a
project manager is to monitor and control all the project work and ensure that everything is on track. This process consists of
tracking, reviewing, and reporting the overall progress to meet the performance objectives defined in the project management
plan[2].
It is important to note that it is much easier to monitor project success on small projects. Due to far fewer team members,
stakeholders, and complexities to consider, the project’s progress is more easily observed. However, on higher complexity projects
that require many people, who are often spread out over different locations, project leaders are unable to use simple observation to
assess progress. In these instances, it is important to have more robust tools and techniques (see sections 1.2 and 1.3 for qualitative
and quantitative monitoring tools) that monitor the success of the full project team.
The project team evaluates its performance against the plans that have been developed. Every project requires a monitoring and
control system. This system considers the following:
1. What information is needed and how should it be collected?
2. When (and with what frequency) should this information be collected?
3. Who should collect and analyze this information?
4. How should this information be represented from a reporting perspective?
5. Who should prepare the reports?
6. Who should receive the reports?
Monitoring and controlling project work allows stakeholders to understand the current state of the project, recognize the actions
taken to address any performance issues, and have visibility into the future project status with cost and schedule forecasts[3]. It is
important to note that it is much easier to monitor the progress and performance issues on small projects. Due to far fewer team
members, stakeholders, and complexities to consider, the project’s progress is more easily observed. However, in more complex
projects that require many people, who are often spread out over different locations, project leaders are unable to use simple
observation to assess progress. In these instances, it is important to have more robust tools and techniques that monitor the success
of the full project team (see Sections 11.1.2, 11.2, and 11.3 below).

11.1.1 The Difference between Monitoring and Controlling

Although the process is traditionally named “monitoring and controlling”, we should know that there are differences between these
two concepts. Controlling cannot be carried out by the project team if monitoring has not been done properly or at all. Thus,
monitoring leads to controlling while controlling may require more monitoring if controlling determines that sufficient information
couldn’t be derived from the monitoring process.
Let’s clarify the distinction between monitoring and controlling.
Monitoring [4]
Collecting project performance data
Producing performance measures
Reporting and disseminating performance information
Controlling [5] :

11.2.1 [Link]
 Comparing actual performance with planned performance
Analyzing variances
Assessing trends to affect process improvements
Evaluating possible alternatives
Recommending appropriate corrective action as needed
As seen above, we collect the data and analyze them to create performance measures. For example, our project dashboard can
indicate our current status regarding the schedule and budget. We can also have a detailed Excel file exhibiting our day-to-day
activities and actual costs. If this data is produced properly, we can continue with the controlling first by comparing the actual
performance with planned performance, that is the project baseline. After we evaluate the variances and trends, we can evaluate
possible alternatives to recommend corrective actions.
Monitoring and controlling process involves regularly measuring progress on a project to ensure it continues meeting objectives
and addressing current organizational needs. It involves determining what corrective action is required, when it must occur, and
who must do it. Monitoring begins at the very beginning of the project (initiation) and increases in density in the planning phase
because it is easy to get off track with planning efforts (Figure 11.1). Besides, the execution of project activities would need a
considerable amount of attention from the project manager and team to monitor and control activities and performance measures
(Figure 11.1). When the traditional predictive/waterfall development methodology is used, the team monitors performance against
the timeline, budget, scope, and quality objectives for the entire project. When an adaptive approach is used, progress within the
iteration is assessed (see Chapter 12).

Figure 11.1: Project Management Process Groups . (Adapted from PMBOK Guide 6th Edition)

11.1.2 Tools Utilized to Conduct Effective Monitoring

Effective monitoring requires an effective system that allows the project team to collect performance data accurately and with
minimum errors. The commonly collected information includes the status of the project budget and the project schedule. The work
completed to date, what has yet to be completed, and the likelihood of completing the project on time and within budget are of
particular interest. How this monitoring is performed quantitatively will be detailed below in 11.3 “Earned Value Management”. In
addition, it is important to identify the risks and issues that require attention. Whenever possible, information technology should be
used to collect and analyze the information and distribute the reports. Different organizations require different roles to collect and
analyze the project information. In organizations with a project management office (PMO), PMOs may be accountable for progress
reporting in an “end-to-end” way, meaning they would be involved from information collection all the way to report distribution.
Organizational policies (from a formal perspective) and organizational culture (from an informal perspective) influence who and
how progress monitoring is performed.
One of the common methods used to monitor progress is team meetings. Team meetings are highly collaborative and serve many
purposes, including information sharing and team development. Depending on the nature of the project, these meetings may be

11.2.2 [Link]
focused exclusively on sharing the status of tasks underway. It is also possible for status discussions to lead to team planning. The
individuals who participate in these meetings vary depending on many factors, such as development methodology in use,
organizational culture, project complexity, and status of the overall project. The frequency of team meetings is pretty higher in agile
(adaptive) projects than the traditional (predictive/waterfall) projects in order to ensure agility, flexibility, on-time interventions,
and timely feedback from team members and the product owner. For example, agile teams, in particular Scrum teams, have daily
standups to discuss what has been completed since the last standup meeting, what is planned to complete until the next meeting,
and what the impediments, risks, and problems that members may encounter are (see Chapter 12, Section 12.2.2).
Project teams typically develop different reports for different stakeholders. Stakeholders who have a high interest and high
power/influence will receive more information, more frequently (recall the stakeholder power/interest grid presented in Chapter 5).
Depending on the priority and duration of the project, the reporting frequency could be daily, weekly, monthly, or quarterly.
We can mention three different types of project reports as follows:
1. Status reports – where the project stands at a specific point in time
2. Progress reports – what the project team has accomplished during a certain period
3. Forecast reports – future project status based on current project status and known trends
Tables 11.1, 11.2, and 11.3 exhibit short examples of status, progress and forecast reports, respectively, based on our example of the
overall case discussed throughout the book (see Section 1.2.4 “Case Study 1.2: Characteristics of Another Project Undertaken by
Grocery LLC (M-Commerce Project)”).
Table 11.1: An Example of an Overview based on a Status Report [6]

Period May 27, 2022 – July 7, 2022

Team Name Grocery LLC M-Commerce Project Team

Status Report Prepared by: Project Manager

Overall Status: Green — On Track Yellow — Caution Red – Problem

Table 11.2: An Example of a Progress Report [7]

Activities/Deliverables Completed Since Last Reporting Period

WBS Activity Name Duration Date Comments

# Completed

2.1 Review needs analysis based on the 3 days Tue 5/31/22 The review has some issues due to the missing
business case key points in the preceding activities. However,
the team worked very well to compensate for the
delay. No delay was experienced.

2.2 Elicit requirements from stakeholders 10 days Sun 6/10/22 It finished two-day earlier than its planned 6/14
schedule.

2.3 Draft preliminary stakeholder 7 days Tue 6/21/22 An additional two days were added from 2.2.
specifications

2.4 Review specifications with team and 5 days Tue 6/28/22 Finished on time.
stakeholders

2.5 Incorporate feedback on the 3 days Fri 7/1/22 Finished on time.

specifications

2.6 Develop a preliminary budget and 3 days Wed 7/6/22 The one-day delay was experienced due to the

11.2.3 [Link]
 delivery timeline absence of a representative from the budget
department.

2.7 Obtain approvals to proceed (concept, 1 day Wed 7/6/22 The meeting with the sponsor took 3 hours. The
timeline, budget, resources) sponsor was convinced that we could proceed
with the activities under the third component
“Design”.

2.8 Analysis complete 0 days Thu 7/7/22 Milestone achieved.

Table 11.3: An Example of a Forecast Report [8]

Activities & Deliverables for the Next Reporting Period

WBS# Activity Name Duration Date to be Comments

Completed

3.1 Review preliminary stakeholder 3 days Mon 7/11/22 Stakeholder Z (high power, high interest)
specifications notified us of some serious conflicts in the
preliminary stakeholder specifications. We
may expect a 2-day delay. The sponsor
should be informed immediately.

3.2 Develop solution (functional and non- 5 days Mon 7/18/22 Developer 1 may not be available during
functional) specifications this activity. Therefore, a developer must be
kept as a substitute to ensure attendance.

3.3 Develop transition requirements 2 days Wed 7/20/22 No delay is expected.

3.4 Develop design mockups based on 5 days Wed 7/27/22 Stakeholder Z may have some objections.
specifications Project member 2 will be assigned to
communicate with this stakeholder.

3.5 Review specifications 2 days Fri 7/29/22 The same issue with Stakeholder Z.

3.6 Incorporate feedback into specifications 2 days Tue 8/2/22 The same issue with Stakeholder Z.

3.7 Finalize project management plan 8 days Fri 8/12/22 Based on the stakeholders’ feedback, we
may experience delays.

3.8 Design complete 0 days Mon 8/15/22 No comments.

1. PMI (2020). Ahead of the Curve: Forging a Future-Focused Culture. Pulse of the Profession. Retrieved from
[Link]
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
4. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
5. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

11.2.4 [Link]
 6. Interthink. (n.d.). Project HEADWAY Project Team Status Report. Retrieved from
[Link]
7. Interthink. (n.d.). Project HEADWAY Project Team Status Report. Retrieved from
[Link]
8. Interthink. (n.d.). Project HEADWAY Project Team Status Report. Retrieved from
[Link]

This page titled 11.2: Monitoring and Controlling Project Work is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or
curated by Abdullah Oguz (MSL Academic Endeavors) .

11.2.5 [Link]
11.3: Qualitative Monitoring
Qualitative monitoring, as its name implies, involves measuring quality rather than quantity. In the context of project management,
qualitative monitoring addresses the following questions:
Scope: Is the team delivering on the intended scope in order to fulfill the project’s objectives and organizational needs?
Quality: Is the quality of the deliverables meeting stakeholder expectations?
Stakeholders: Are stakeholders engaged?
Communications: Are project communications effective?
Risks: Are risks and opportunities being effectively managed by the team?
Resources: Are resources being effectively managed and available as expected?
Procurement: Are the expectations outlined in procurement contracts being adhered to by vendors?
Team Management: Has the team become high-performing and are individual team members meeting performance
expectations?

11.2.1 Validating and Controlling Scope

The approach taken to monitor and control scope depends on the development methodology used. The predictive/waterfall
approach involves a sequential definition of requirements and scope, which then leads to solution development. This approach is
commonly utilized when the organization has a clear vision of the project’s end outcome. Given this, monitoring and controlling
scope occurs with the premise that significant scope changes are not expected. Validating scope involves formal acceptance of the
completed project deliverables by the project sponsor and their assigned designates. Acceptance often requires deliverable reviews
where the quality of the work is inspected before sign-off is provided. Changes may be required. These changes can be a result of
poor quality (which leads to re-work) or new requirements intended to improve the organizational value of the project’s outcomes.
New requirements are carefully controlled. This is necessary because once solution development begins, the project’s resources,
timelines, and budget were all defined with a specific scope in mind. A scope change may mean those resources, timelines, and
budgets are now insufficient to deliver on the increased scope. Controlling scope in this situation requires the project team to assess
the impact of the new requirement on all the project’s constraints. If necessary, the team will seek approval for additional funding,
time, and/or resources to pursue the new requirement. Project leaders need to reserve judgment on scope changes until the impact
and benefits are clearly understood. The term “scope creep” refers to the poorly controlled expansion of scope over time. This
means that the scope expands, perhaps unintentionally, without an understanding of its impact on the project’s other constraints,
such as time and budget. Therefore, utilizing an integrated approach for change management is a critical success factor for projects
using the predictive/waterfall approach.
Projects that follow an adaptive development methodology, such as agile, view scope change very differently. Scope definition, as
well as solution development and testing, occur in an iterative or incremental fashion. As new requirements are identified, they are
evaluated from a cost/complexity and benefit perspective, and if worth pursuing, they will be scheduled into a future iteration. A
continuous improvement mindset encourages scope definition to occur in cycles.

11.2.2 Controlling Quality

Quality is about ensuring the expectations of the project sponsor have been met. This involves ensuring the expectations of the end-
user community are well understood. High quality is achieved by planning for it (proactive) rather than by reacting to problems
after they are identified (reactive).
Standards are chosen and processes are established to achieve those standards in the planning phase. Project quality focuses on the
end deliverables that reflect the purpose of the project. The project leader is responsible for developing a quality management plan
that defines the quality expectations and for ensuring the specifications and expectations are met. In the execution phase, the
project team attempts to prevent quality issues from occurring with the use of quality management techniques, such as checklists,
assessments, and lean six-sigma tools. Lean six-sigma tools are focused on creating efficient and effective processes that involve
error-proofing methods.
In the monitoring and control phase, the project team reviews the project deliverables to ensure they are ready for review and sign-
off. Ideally, this review leads to deliverable acceptance. However, the team may encounter problems that they are unable to prevent.
When this occurs, the team’s objective is to determine how to fix these problems. One of the most effective ways to address a

11.3.1 [Link]
problem is to begin by understanding its root cause(s). Cause-and-effect diagrams, which are also referred to as fishbone or
Ishikawa diagrams, are very effective for this purpose.

11.2.3 Monitoring Stakeholder Engagement

Project teams cannot control stakeholders. However, they can significantly influence their level of engagement. During the
planning phase of a project, the stakeholder register is created (see Chapter 5) which is an effective tool for keeping track of a
project’s stakeholders, their relative interest in the project, and their level of power/influence over the project’s outcomes. The
register provides an effective starting place for determining how to engage stakeholders according to their power and interest levels
if a Power/Interest Grid is used.
During the monitoring and control phase, the project team looks for new stakeholders and monitors the engagement level of
existing stakeholders. Engagement techniques will vary from one organization to another as their respective cultural norms and
values influence how individuals work together. Some organizations prefer face-to-face interaction while others prefer the use of
electronic messaging and project team websites. Whatever the methods are used to engage stakeholders, it is important to keep
stakeholders informed of the project’s progress and to find the right approaches for meaningfully involving stakeholders throughout
the life of the project.
A project leader’s interpersonal skills are critical in stakeholder management (See Chapters 5 and 6). Some stakeholders may have
become unresponsive to the project team’s requests. When this occurs, the project leader’s relationship-building skills will be put to
the test as they attempt to understand the stakeholder’s actions. Conflict resolution skills, such as negotiating, are vital because
stakeholders are very likely to have differing priorities, and successfully navigating these conflicts can be the difference between
project success and project failure.

11.2.4 Monitoring Communications

Communication is one of the most effective ways to keep team members and all other stakeholders engaged. In order for this
communication to be effective, it must be developed and delivered in ways that consider stakeholder roles and communication
preferences. During the planning phase, a communication plan would be created to guide the project team’s communication efforts
throughout the project (See Chapter 6). It is important for project leaders to proactively determine if the selected communication
methods will be suitable for the key stakeholders. This is done by directly asking them and monitoring their responsiveness to the
communication delivered. Another important way to determine if project stakeholders are well-informed is to pay careful attention
to the questions they ask. Questions about project progress that have been addressed in recent project communications are a good
sign that the communication techniques may not be effective for a particular stakeholder. When this occurs, it is time to revisit the
communication plan and make the appropriate adjustments.

11.2.5 Controlling Procurements

Monitoring procurement includes ensuring the vendors’ performance meets the agreed-upon, often contractual, requirements. The
complexity of the project determines the number and type of vendors procured. This, in turn, determines the nature of the
monitored activities. For instance, projects that only require supplies to be purchased externally will have much simpler vendor
management processes than projects that had to outsource the completion of some of the work to external consultants.
Key tools and techniques that may be used in procurement management include inspections, audits, formal change control
methods, vendor-produced performance reports, payment systems, and contract administration.

11.2.6 Monitoring Risks

Monitoring and controlling risks involves implementing a risk management plan. A key aspect of this plan is often the risk register,
which helps the team keep track of the project risks, triggers (early warning signs), and risk responses (See Chapter 10). Risk
responses can be implemented in any phase of the project as long as documentation is kept up to date.
Many project teams establish contingency plans and contingency funds to account for all types of risks (e.g., negative and positive
risks, individual and overall project risks). When these risks materialize, the project team determines if the contingency plans
and/or funds will address these risks and, if so, they will be implemented. If contingency plans/funds don’t suffice, the project team
must identify workarounds. Contingency plans and workarounds are then monitored to determine if they were effective.
Additional corrective action may be required.

11.3.2 [Link]
11.2.7 Controlling Resources
Projects require human resources, physical resources, and services in order to produce the desired outcomes (See Chapter 8).
During monitoring and controlling, the project leader assesses the effectiveness of all types of resources.
With respect to the project team, effective project managers continuously assess the performance of the team and its members.
Effective coaching and mentoring skills are essential and can be the difference between project success and failure (See Chapter 6).
In addition, a project leader must sometimes make the difficult decision to replace team members when they are not able to perform
as expected or the ensuing conflicts cannot be resolved. Conflict management skills are important in this regard (See Chapter 6).
Proactive conflict management requires the project leader to continuously monitor stress levels in the team in an attempt to
anticipate the likelihood of rising conflict. Monitoring resource utilization levels in the project schedule and staying connected to
project team members are also critical activities that the project leader must perform. Lastly, many projects require people with
different skills at different times. Project leaders should be actively monitoring when these skills will be required and ensuring
people join/transition off the project at the appropriate times.
The availability and effectiveness of physical resources are also closely monitored. In some instances, faulty or ineffective
equipment has to be replaced. If the scope of the project changes, new equipment and technology may be required, which, in turn,
may lead to additional work in procurement management.
Monitoring and controlling is about integrating all the teams while assuring that work is being completed at a steady rate to keep
the project on track. This phase is vital to the overall success of the project. Thus, requiring additional, highly-skilled resources, is a
key consideration during the planning phase.

This page titled 11.3: Qualitative Monitoring is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

11.3.3 [Link]
11.4: Earned Value Management (EVM)
A project manager must regularly compare the amount of money spent with the budgeted amount and report this information to key
stakeholders. In addition, project managers must also compare the progress of the actual work completed with the estimated
durations in the project schedule. One of the quantitative monitoring techniques project managers utilize is Earned Value
Management (EVM) which combines scope, schedule and cost baselines to determine the project’s well-being and to decide
whether an action is required in case of problems. EVM is essential to project success. It is used extensively in many business
fields and organizations such as the Department of Defense (DOD) and construction industries while the IT industry has not due to
the reasons such as practicing agile (adaptive) project management and hence lack of a fixed baseline[1].
EVM is a quantitative monitoring technique that uses metrics and indexes to assess project performance. Earned value analysis
compares the performance measurement baseline to the actual schedule and cost performance. EVM integrates the scope baseline
with the cost baseline and schedule baseline to form the performance measurement baseline [2][ii]. The application of earned value
in the early initiation and planning phases of a project increases the validity and usefulness of the cost and schedule baseline and is
an excellent verification of the project scope assumptions and the scope baseline. Once established, these baselines become the best
source for understanding project performance during execution. A comparison of actual performance (both cost and schedule)
against this baseline provides feedback on project status and data, not only for projecting probable outcomes but also for
management to make timely and useful decisions using objective data[3]. EVM, known as “management with the lights on”, is
based on the principle that past patterns and trends can indicate future conditions. EVM helps us clearly and objectively see where
our project is headed compared to where it’s supposed to be[4].
EVM can help answer the questions below[5]:
Are we delivering more or less work than planned?
When is the project likely to be completed?
Are we currently over or under budget?
What is the remaining work likely to cost?
What is the entire project likely to cost?
How much will we be over or under budget at the end of the project?
What is driving the significant cost and/or schedule variances?
In EVM, there is an important point that must be clarified. We will always see monetary amounts even though we are measuring
the scope or schedule performance. The denominator for all of them is the currency we are using for our project. If we are using the
US dollar, the denominator would be the US dollar. The analogy for EVM would be doing shopping in a market. We buy different
items such as olive oil, cookies, milk, eggs, and laundry detergent. All these items are converted to a monetary value, and it allows
us to compare the prices between different brands. In the end, we know the total amount in dollars. This is exactly what is
happening for EVM. Therefore, when we see a result showing dollars, it doesn’t necessarily mean that it is related to the cost. It
can indicate a problem in scope (e.g., not all planned activities have been completed) or schedule (e.g., the project is behind
schedule).

11.3.1 Main EVM Parameters

To start with EVM, we should elaborate on three key dimensions. They are:
1. Planned Value (PV) is the amount of work that is estimated and planned to be done by a particular date in the project. This
work is measured by the cost of planned work by a specific date. As explained above, EVM measures all the values with
monetary units to create a common measurement scale. PV includes contingency reserve while excluding management reserve.
Microsoft Project also uses the term BCWS (Budgeted Cost of Work Scheduled) besides PV. Total PV can be referred to as
Performance Measurement Baseline (PMB) or Budget at Completion (BAC).
Let’s consider our Grocery LLC’s m-commerce project. Let’s assume that we outsourced the development component to a software
company. Therefore, this component would be a project for this company. They divided the development of the mobile app
interface and the backend part into ten activities (e.g., user profile and settings, items to purchase with pictures, features and prices,
payment, order tracking, databases, etc.). There are ten activities to finish the development of the mobile app (scope baseline).
Then, we can continue with the testing of the mobile app. Each development activity was scheduled to be three days. In total, the
mobile app will be ready to test in thirty days (schedule baseline). Let’s also assume that we need to pay $2,000 for each phase.

11.4.1 [Link]
Total cost baseline for all ten activities is $20,000 ($2,000 x 10). For earned value analysis, we consider $20,000 as our total
planned value which is also named BAC (Budget at Completion).
2. Earned Value (EV) is the amount of work that has been completed by a particular date in the project. This work is measured by
the cost of work performed and completed by a specific date. Microsoft Project also uses the term BCWP (Budgeted Cost of
Work Performed) besides EV.
Let’s assume that the company we outsourced the development component finished five activities at the end of the eighteenth day.
The planned value by that day was 6 activities, which amounts to $12,000 ($2,000 x 6). However, only five activities were
completed, which is 50% of the planned work. This is our earned value which can be measured as $10,000 ($2,000 x 5).
3. Actual Cost (AC) is the sum of the amounts which has been spent on the project so far. Microsoft Project also uses the term
ACWP (Actual Cost of Work Performed) besides AC.
For the five activities completed, we paid $11,200. This is the actual cost at the end of the eighteenth day (the status date).

11.3.2 Variance Analysis

After we calculate PV, EV, and AC, we can conduct variance analysis to figure out if we are on, over, or under budget, and if we
are on, behind, or ahead of the schedule.
Cost Variance (CV) and Cost Performance Index (CPI)
The difference between EV and AC is the cost variance (CV).
CV = EV – AC
If the cost variance is negative, we can conclude that the project as of the status date is over budget. If the cost variance is positive,
this indicates that the project is under budget. IF CV is zero, it means that the project is on track in terms of the budget.
In our example, at the end of the eighteenth day, we could finish five activities. EV is $10,000, and AC is $11,200.
CV = 10,000 – 11,200 = -1,200
It means that our project stands over the budget.
Instead of CV, we can also use CPI (Cost Performance Index) which gives us a ratio instead of an absolute number. CPI uses the
same variables as CV but expresses them as a ratio. CPI is calculated as follows:
CPI = EV / AC
CPI = 10,000 / 11,200 = 0.89
CPI is a measure of the cost efficiency of budget resources[6]. When CPI is less than 1.0, it indicates a cost overrun. When CPI is
greater than 1.0, it indicates a cost underrun for the work completed. If it is 1.0, it indicates that the project budget is on track.
Schedule Variance (SV) and Schedule Performance Index (SPI)
The difference between planned value and actual progress (earned value) is the schedule variance (SV).
SV = EV − PV
If less value has been earned than was planned, the schedule variance is negative, which means the project is behind schedule. If
there is a positive variance, it indicates that the project is ahead of its planned schedule. If SV is zero, it means that the project
schedule is on track.
In our example, at the end of the eighteenth day, we could finish five activities. EV is $10,000, and PV is $12,000.
SV = 10,000 – 12,000 = -2,000
It means that our project is behind its schedule. -$2,000 does not indicate a number related to the cost. As mentioned above, the
monetary unit is the common measure we are using for the schedule baseline and variance as well.
Instead of SV, we can also use SPI (Schedule Performance Index) which gives us a ratio instead of an absolute number. SPI uses
the same variables as SV but expresses them as a ratio. SPI is calculated as follows:
SPI = EV / PV
SPI = 10,000 / 12,000 = 0.83

11.4.2 [Link]
SPI is a measure of schedule efficiency. It measures how efficiently the project team is accomplishing the work[7]. When SPI is less
than 1.0, it indicates that the project is behind schedule while an SPI that is greater than 1.0 indicates that the project is ahead of
schedule. If it is 1.0, it indicates that the project schedule is on track.

11.3.3 Trend Analysis

After PV, EV, and AC values are generated, and variance analysis is performed, we can conduct trend analysis to predict how our
project may perform during the rest of the project, and when the project is completed.
Trend Analysis for Schedule
We can estimate the new project completion time. In our example, the project is behind schedule. Let’s figure out if we may have a
delay if the SPI remains the same. We had scheduled to finish the development component in 30 days. The current SPI is 0.83. If
we cannot improve the SPI, we will end up with a delay.
Adjusted schedule estimate = Original schedule estimate (schedule baseline) / SPI
Adjusted schedule estimate = 30 days / 0.83 = 36.14 days
Therefore, we may have a delay of 6 days in this component.
Trend Analysis for Budget
We can estimate the new project budget. In our example, the project is over budget. Therefore, may we expect to spend more than
what we estimated in our cost baseline (BAC – budget at completion which is the total PV)? If we assume that CPI won’t change
during the rest of the project, we can use the formula below:
EAC (Estimate at Completion) = BAC / CPI
EAC = $20,000 / 0.89 = $22,472
Therefore, we can estimate that we may find ourselves spending $22,472 instead of $20,000 which was our cost baseline. The
difference between BAC and EAC gives us VAC (Variance at Completion).
VAC = BAC – EAC
VAC = $20,000 – $22,472 = -$2,472
Thus, if we cannot improve the current CPI, we may spend an additional $2,427 when the project is completed.
Another parameter that we can generate is ETC (Estimate to Complete).
ETC = EAC – AC
ETC = $22,472 – $11,200 = $11,272
Thus, we expect to spend $11,272 during the rest of the project.
The third parameter we can use is TCPI (To-Complete Performance Index). Project managers use TCPI to calculate the CPI that is
required to get back the project on budget.
TCPI = (BAC-EV) / (BAC-AC)
TCPI = ($20,000 – $10,000) / ($20,000 – $11,200) = 1.14
The project manager should assess the CPI (1.14) required to get the project back on track with its cost baseline. This assessment
would be based on various factors such as the availability and quality of resources for the remaining activities, and the project
team’s commitment and performance.

1. Ayers, J. (2021). Earned Value Management (EVM) Applied to Large IT Project. Retrieved from
[Link]
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. Project Management Institute. (2011). Practice Standard for Earned Value Management – Second Edition. ↵
4. Retrieved from [Link] ↵
5. M. T. Cox MBA, D. (2013). Project Management at Work: Practical, Relevant Results. United States: iUniverse. ↵

11.4.3 [Link]
 6. Project Management Institute. (2011). Practice Standard for Earned Value Management – Second Edition. ↵
7. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 11.4: Earned Value Management (EVM) is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

11.4.4 [Link]
11.5: Change Control Process
The monitoring and controlling process is a constant process starting at the very beginning of the project, and it finishes when the
project is closed out. As detailed in Section 11.1, monitoring and controlling involves regularly measuring progress on a project to
ensure it continues meeting objectives and addressing current organizational needs. Project managers monitor the project work by
collecting project performance data, producing performance measures, and reporting and disseminating performance information.
Then, they compare actual performance with planned performance, analyze variances and assess trends to affect process
improvements (see Section 11.3), and finally evaluate possible alternatives and recommend appropriate corrective action as
needed[1].
In order to manage the control process effectively, projects must have a change management plan and a configuration management
plan which are sub-plans of the overall project management plan. A change management plan provides the direction for managing
the change control process and documents the roles and responsibilities of the approval authority or the change control board if
available. The configuration management plan describes the configurable items of the project and identifies the items that will be
recorded and updated so that the product of the project remains consistent and operable[2]. Therefore, these plans guide project
managers and teams while they need to make a change in the project, and configure primarily the product scope.
When we find a problem, we can’t just make a change since we should evaluate possible alternatives and consider risk response
strategies and the availability of contingency reserves (see Chapter 10). What if corrective actions exceed our schedule or budget
constraints? We need to evaluate triple constraint elements (scope, schedule, and cost) and other constraints such as resources and
quality. Compromising the quality of the outcomes and deliverables would endanger the approval process, and hence lead to a
project failure. Therefore, we have to figure out if it is worth making the change. Change control is a set of procedures that let us
make changes in an organized way.
Anytime we need to make a change to our project management plan, we need to start with a change request. This request is
generally in the form of a document (Table 11.4). Any change to the project needs to be documented so we can figure out what
needs to be done, by when, and by whom. Any stakeholder can request a change. Once the change request is documented, it is
submitted to a change control board, in particular, if the project is within a program or portfolio, and this necessitates the
submission of change requests exceeding a specified cost. A change control board is a group of people who consider changes for
approval. Not every change control system has a board. The change control system is designed based on various factors such as the
size and complexity of the project, organizational policies, business field, and contract requirements. The change requests are
generally submitted to the project sponsor by the project manager for review and approval. The project manager is responsible to
monitor the change process from the very beginning to the very end. Putting the recommended changes through change control will
help us evaluate the impact and update all the necessary documents. Not all changes are approved, but if the changes and repairs
are approved, we send them back to the team to put them in place.
Table 11.4: Change Request Form Template

Project Name:

Project Number:

Project Manager:

Requestor Name:

Request Date:

Resolution Requested

Description of Change:

11.5.1 [Link]
 Reason for Change:

Impact on Scope and/or Deliverables:

Impact on Resources and Quality:

Impact on Time and Cost:

Disposition of Change Resolution: Accepted: Denied:

Project Manager
Name & Signature Date:______________

Project Sponsor Date:______________

Name & Signature

Change requests are made to modify documents, deliverables, and baselines. They are issued to expand, adjust, or reduce project
scope, product scope, or quality requirements and schedule or cost baselines. They can include corrective actions, preventive
actions, defect repairs, and updates[3]. Project teams may need to assess the product and project scope, and this may require the
teams to discuss the issues with stakeholders to determine if there is a need to revise requirements or add new ones.
In order to keep the track of change requests and actions taken, a “Project Change Request Tracking Log” (Table 11.5) can be held
along with an “Issue Log”.
Although monitoring and controlling process is performed throughout the project, most of the effort would be expended especially
during the execution (implementation) phase. Resources outside the core project team are assigned, and costs are usually the
highest during this phase. Besides, scheduling issues would arise in this phase as project activities are carried out and human and
physical resources are assigned. Project managers experience the greatest conflicts over the schedule in this phase. Some activities
may take longer than estimated. Some risks may occur creating schedule slippages. Project managers first apply techniques without
the need for a change request if triple constraints aren’t affected. Nevertheless, project managers should implement a holistic
approach by taking into account all constraints and knowledge areas.

Table 11.5: Project Change Request Tracking Log Template

Project Change Request Tracking Log

Project Name:

Project Manager

Submission Data Impact Analysis PM Review and Approval

Request# Submitted Date Date Assigned Date Date Committee Date Date
By: Assigned to Analysis Reviewed Decision Approved Request
to Completed Integrated
Analyst into
Project
Plan

11.5.2 [Link]
 1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
2. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
3. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 11.5: Change Control Process is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

11.5.3 [Link]
11.6: MS Project Tutorial
This MS Project tutorial will elaborate on how to conduct an EVM analysis. Table 11.6 provides a project with 15 activities.
Table 11.6: Project Activities

Activity Duration (weeks) Predecessors

A 2 —

B 3 —

C 1 A, B

D 3 C

E 2 C

F 2 D, E

G 3 E

H 4 F, G

I 2 H

J 6 I

K 4 J

L 3 J

M 2 J

N 2 K, L, M

O 1 N

Figure 11.2: WBS, Schedule, and the Gantt Chart

In this project, the resources that are assigned to each activity are given in Table 11.7. All the resources are “Work” type resources
which means that they are either people or equipment.

11.6.1 [Link]
 Table 11.7: Resources and Costs

Resource Name Standard Rate Activities

a $20.00/hr A

b $40.00/hr B

c $30.00/hr C

d $15.00/hr D

e $35.00/hr E

f $50.00/hr F

g $30.00/hr G

h $25.00/hr H

i $40.00/hr I

j $40.00/hr J

k $25.00/hr K

l $25.00/hr L

m $20.00/hr M

n $35.00/hr N

o $50.00/hr O

Additional Cost 1 $35.00/hr C

Additional Cost 2 $25.00/hr F

Under the View tab, we click the “Resource Sheet”. Then, we can type the resource names and costs as seen in Table 11.7. The
Resource Sheet on MS Project is given in Figure 11.3.

11.6.2 [Link]
 Figure 11.3: Resource Sheet
Let’s select all the resources except additional costs from the drop-down menu for each resource on the Gantt Chart view. Besides,
we add a new column “Cost” to the left of “Resource Names”. As can be seen in Figure 11.4, the total estimated cost of the project
is $52,400. This figure would be also our BAC (Budget at Completion).

Figure 11.4: Gantt Chart View with the Resources Selected

Under the “Task” tab, we can select “Tracking Gantt” from the drop-down menu (Figure 11.5).

Figure 11.5: Selecting Tracking Gantt View

In order to create schedule and cost baselines, we must create a baseline by clicking “Set Baseline” under the “Project” tab. We can
click OK as shown in Figure 11.6.

11.6.3 [Link]
 Figure 11.6: Set Baseline Window
The Tracking Gantt Chart is shown in Figure 11.7. As we haven’t indicated any progress yet, all the progress percentages are zero
percent. Each bar is now composed of two horizontal parts. The lower part which is darker displays the baseline.

Figure 11.7: Tracking Gantt Chart

The project started on June 6, 2022. The estimated completion date is December 30, 2022. Let’s assume that some time passed in
the project. Let’s make the current date September 18, 2022. Under the “Project” tab, click “Project Information”. Changing the
current date won’t suffice (Figure 11.8). It will help us to see the date on the Gantt Chart. Rather, we need to change the status date
to create a scenario as of September 18, 2022.

Figure 11.8: Project Information Window

Now, we can change the completion percentages for each activity, and add “Additional Resources” to create the impression as if we
made some progress on activities, and spent more money on some of the activities. As indicated in Table 11.7, additional costs are
added to activities C and F (Figure 11.9). The project cost changed to $55,800 with the additional costs from its cost baseline of
$52,400.

11.6.4 [Link]
 Figure 11.9: Additional Costs added to activities C and F
As shown in Table 11.8, we will also change the completion percentages for each activity.
Table 11.8: Completion Percentages for the Activities

Activity Completion Percentage

A 100

B 100

C 100

D 100

E 100

F 100

G 100

H 50

I 0

J 0

K 0

L 0

M 0

N 0

O 0

We can use the shortcuts for completion percentages (0%, 25%, 50%, 75%, 100%). Or double-clicking a task opens the “Task
Information” window. From the “Percent complete” on this window, we can type any percentage (Figure 11.10).

11.6.5 [Link]
 Figure 11.10: Shortcuts for Completion Percentages
After we mark the completion percentages for each task, we can see the percentages to the left of each bar on the Gantt Chart
(Figure 11.11). Besides, the upper horizontal section of each bar will get darker for 100% completion, and the “Indicators” column
will place ticks for these activities. Activity H has a 50% completion. Therefore, its upper horizontal section turned darker red for
half of the activity. We should remember that weekends are considered holidays on Microsoft Project (default setting). Therefore,
the coverage area may not necessarily display a 50% area on a bar.

Figure 11.11: The Percentages marked to the right of each bar on the Gantt Chart
So, our scenario dictates that we finished 100% of activities A, B, C, D, E, F, and G, and 50% of activity H. Besides, we spent more
money on activities C and F.
Now, we can open the EVM table. In the View tab, we click Tables and select More Tables. In the new menu window, we choose
Earned Value. In the new sheet, we should insert SPI as a new column to the right of the existing “SV” column, and CPI as a new
column to the right of the existing “CV” column. Figure 11.12 displays the Earned Value table view as of September 18, 2022. An
SPI value of 0.92 indicates that our project is behind schedule. A CPI value of 0.88 indicates that our project has an overrun budget
issue. Microsoft Project provides EAC, BAC, and VAC values (Figure 11.12). Our cost baseline was $52,400. If we assume that the
CPI value of 0.88 doesn’t change during the rest of the project, we can estimate to pay $59,761 (EAC – Estimate at Completion) by
the end of the project, which is $7,361 (VAC – Variation at Completion) more than our cost baseline.

Figure 11.12: Earned Value Table View

Our schedule baseline was 30 weeks (Figure 11.2). SPI is 0.92 as of September 18, 2022. If we cannot improve this SPI and it
remains the same during the rest of the project, there may be a delay of 2.6 weeks [1 – (30 weeks / 0.92)].

This page titled 11.6: MS Project Tutorial is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

11.6.6 [Link]
11.7: Key Takeaways
Key Takeaways
The monitoring and controlling process consists of tracking, reviewing, and reporting the overall progress to meet the
performance objectives defined in the project management plan.
Project managers monitor the project work by collecting project performance data, producing performance measures, and
reporting and disseminating performance information. Then, they compare actual performance with planned performance,
analyze variances and assess trends to affect process improvements, and finally evaluate possible alternatives and recommend
appropriate corrective action as needed.
Qualitative monitoring involves measuring quality rather than quantity, and it focuses on the scope, quality, stakeholders,
communications, risks, resources, procurement, and team management.
Earned Value Management (EVM) is a quantitative monitoring technique that uses metrics and indexes to assess project
performance. Earned value analysis compares the performance measurement baseline to the actual schedule and cost
performance.
The main EVM parameters are planned value (PV), earned value (EV), and actual cost (AC).
CPI is a measure of the cost efficiency of budget resources. When CPI is less than 1.0, it indicates a cost overrun.
SPI is a measure of schedule efficiency. When SPI is less than 1.0, it indicates that the project is behind schedule.
After PV, EV, and AC values are generated, and variance analysis (e.g., CPI and SPI) is performed, we can conduct trend
analysis to predict how our project may perform during the rest of the project, and when the project is completed.
In order to manage the control process effectively, projects must have a change management plan and a configuration
management plan which are sub-plans of the overall project management plan.
Any change to the project needs to be documented so we can figure out what needs to be done, by when, and by whom. Any
stakeholder can request a change.

This page titled 11.7: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

11.7.1 [Link]
11.8: Questions and Exercises
There are 10 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 11.8: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

11.8.1 [Link]
11.9: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 11.9: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

11.9.1 [Link]
 CHAPTER OVERVIEW

12: Agile (Adaptive) Project Management

12.1: Learning Objectives and Overview
12.2: Introduction to Agile
12.3: Adopting and Creating an Agile Environment
12.4: Common Agile Framework and Methods
12.5: Recent Trends in Agile Project Management
12.6: Key Takeaways
12.7: Questions and Exercises
12.8: Attribution

This page titled 12: Agile (Adaptive) Project Management is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

1
12.1: Learning Objectives and Overview
Learning Objectives
1. Recognize and describe the evolution and founding principles of agile project management approach.
2. List and describe the factors to consider when adopting an agile approach.
3. Identify the elements of an agile environment.
4. Recognize the most common agile methods and scaling frameworks.
5. Describe the recent trends in agile project management.

Overview
In the previous chapters, we discussed all the project management concepts and methods by mostly referring to the waterfall
(predictive, traditional) project management approach implicitly or explicitly. Although all these concepts and methods are
applicable to agile (adaptive) projects, these projects are developed on evolving requirements accompanied by an upfront planning
which is not as comprehensive as it is in waterfall approach. Rather, the planning in agile approach is spread throughout the
projects over separate iterations, sprints, or timeboxes. Each short iteration allows the project team to refine the requirements in
accordance with the uncertainties, risks, technological changes, and stakeholder expectations and concerns. This chapter will first
discuss the historical background of agile project frameworks and methods, and their key principles. Then, it will describe the
factors to consider when adopting an agile approach, identify the elements of an agile environment, and elaborate on the most
common agile methods and scaling frameworks. Finally, this chapter will address the recent trends in agile project management
according to the 15th State of Agile Report[1].

1. [Link]. (2021). 15th State of Agile Report. [Link]

This page titled 12.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

12.1.1 [Link]
12.2: Introduction to Agile
1980s and 1990s were the years software development teams started to have serious problems with developing and finishing their
software projects which were getting more complex with more computer power and digitalization of businesses and
organizations[1]. Project managers and developers faced more and more problems when they were using the traditional waterfall
approach (Figure 12.2 in the section 12.1.2). The development of software necessitated more collaboration among the project
manager, developers, testers and users, and constant feedback from the users. Besides, new requirements were emerging while the
software was being developed, and the client and end users were not always happy with the final product when they had the chance
to see it after some time passed. Therefore, new methods started to emerge among software developers who lead this type of
projects. Lean methodology created by Toyota for their production system, and utilized by many manufacturers was an inspiration
for many of these software developers. In addition to the lean manufacturing process, just-in-time process and total quality
management movement were other influencers of agile project management[2]. Furthermore, Kanban which is a process
improvement method in manufacturing was adapted to the software development life cycle.
As indicated above, new methods began to emerge in the 1980s and mostly in the 1990s as a response to some of the challenges
that developers faced when using a waterfall approach.
One of the first to become popular was Rapid Application Development (RAD). James Martin, an IT consultant, developed an
approach through which he divided the process into four distinct phases, namely, (1) requirements planning phase, (2) user design
phase, (3) construction phase, and (4) cutover phase[3]. It involved creating prototypes and using them to elicit requirements,
validate designs and evolve toward usable solutions (Figure 12.1). RAD, itself, led to the development of alternative approaches as
well.

Figure 12.1: Rapid Application Development (RAD) Phases[4]

Before Agile Alliance had their first meeting in 1999, there had been a diversification of agile methods which were called as
lightweight methods as compared to the heavyweight waterfall models. The most popular methods were Crystal methods (1992),
Dynamic Systems Development Model (DSDM) (1995), Scrum (1995), Feature Driven Development (FDD) (1997), Extreme
Programming (XP) (1999), and Adaptive Software Development (ASD) (2000). Through the 1990s, a number of alternative ways
to organize and structure the development of software products emerged as mentioned above, and they eventually evolved into the
“agile” in 2001 with “Agile Manifesto”.

12.1.1 Agile Manifesto

At their initial meeting in 1999, the pioneers of agile methods discussed the similarity of XP with other methods and decided to
meet again, with a broader range of people, to explore common ground. In 2001, a group of 17 people met at Snowbird Ski Resort
in Utah to talk, ski, relax and try to find common ground between their thoughts on software development[5]. They represented the
leading thinkers from XP, Scrum, DSDM, ASD, Crystal, FDD and Pragmatic Programming, along with others who wanted a viable
alternative to traditional heavyweight and documentation-driven development processes. They published the “Agile Manifesto”
that embodied the values they all believed in and a set of guiding principles (Figure 12.2). Thus, the Agile Alliance was born.

12.2.1 [Link]
 Figure 12.2: Agile Manifesto
Twelve Agile Principles behind the Agile Manifesto are listed below[6]:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter
timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant
pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements and designs, emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

12.1.2 Differences between Waterfall and Agile Methods

As can be seen in Figure 12.3, in the waterfall (predictive, traditional) project management approach, the process is linear and
sequential. Project teams should finish one stage to proceed with the following stage. As seen in Figure 12.3, the agile (adaptive)
project management approach compresses the sequential phases in small timeboxes. Therefore, agile teams work on a limited

12.2.2 [Link]
number of requirements (i.e., user stories) at a time, and they can receive frequent stakeholder feedback at the end of each timebox
when they create a partial working product.

Figure 12.3: Waterfall Project Management

Figure 12.4: Agile Project Management

The frequent interaction with the client and stakeholders offers an environment where the frustration level of stakeholders is
minimized. Nevertheless, agile methods may not be appropriate for all projects. Waterfall project approach may work better when:
Requirements are very well understood and can be fixed before the implementation begins.
Client’s and customers’ expectations from the product is stable and substantial changes can be avoided.
Technology and the tools utilized are understood very well by the stakeholders, and changes that may affect the project’s
progress are not expected.
The duration of the project is relatively short.
The uncertainty is at a low level.
Resources are available, and easy to acquire.
Therefore, we can implement a waterfall project when we expect low uncertainty and define the project and product scope, and
project constraints easily with clear and unambiguous procedures. The production domain and processes involved are usually well
understood and there are typically low levels of execution uncertainty and risk[7]. However, if we cannot define the product scope,
and uncertainty level is high, an agile approach would be better to move gradually by clarifying the requirements and uncertainties
with the active involvement of clients and stakeholders.
In agile projects, client and stakeholder involvement can be provided constantly since product owners are a part of the team, and
the increments are reviewed by the product owner and the client frequently. In waterfall projects, the interaction with the client is
deferred to the end of a phase, for instance, when the software coding and testing are complete. However, in real life projects,
teams often implement a hybrid approach which is a blend of waterfall approach and some principles of agile such as client
involvement and feedback.

12.2.3 [Link]
12.1.3 An Example: Grocery LLC Decides on the Project Approach for the “Self-Checkout
Stations Project”
As discussed in section 1.2.3 titled “Case Study 1.1: Characteristics of a Project Undertaken by Grocery LLC”, the grocery chain,
Grocery LLC, considers establishing self-checkout station areas in all fifty branches to find a solution to long lines in front of the
current checkout stations where the cashiers work. The project selection committee discussed the solution and decided to
implement this project. As part of requirements elicitation, business analysis team surveyed managers and employees, and
interviewed customers. Besides, the team visited the competitors’ markets and made market research to have a better understanding
of possible solutions in the market. The team concluded that self-checkout has been increasingly deployed in many grocery store
and pharmacy chains (e.g., Walmart, Target, CVS) across the United States, and the manufacturers and service providers are
experience. Therefore, the sponsor, project manager, and relevant departments had a meeting to discuss the project management
approach. They decided to implement a waterfall approach supported by continuous stakeholder interaction as is done in agile
methods.
Managers, employees, and customers conveyed their requirements. The analysis revealed that requirements are consistent with
the current implementations and the research consultancy company’s report. Therefore, it was concluded that requirements are
very well understood and can be fixed to a large extent before the implementation begins. However, in order to keep up with the
technological advancements and to be prepared for the risks such as new waves of pandemic, it was decided to establish a
continuous interaction and feedback system with the stakeholders.
There are experienced companies which provide competitive prices to acquire the systems. They implemented numerous
projects across the United States. They have comprehensive knowledge of the current and upcoming technologies.
The duration of the project is 8 months.

12.1.4 An Example: Grocery LLC Decides on the Project Approach for the “M-Commerce
Project”.
As discussed in section 1.2.4 titled “Case Study 1.2: Characteristics of Another Project Undertaken by Grocery LLC (M-Commerce
Project)”, the grocery chain, Grocery LLC, considers having a better online presence by creating a mobile app and optimizing the
website for mobile devices in particular due to the negative effects of pandemic on the number of in-store customers, hence
significantly decreased revenue and profit. In the initiation stage, project manager prepared a report justifying the need for
conducting an agile methodology, i.e., Scrum, during this project in order to accelerate the pace and achieve the outcome in a
relatively shorter time, receive constant and timely feedback from the employees and customers, keep a healthy interaction with the
stakeholders, and adjust the specifications to the fast and unprecedented changing technologies and socioeconomic conditions.
Since it was not easy for the project manager and the team to oversee the near future in a turbulent environment (e.g., Covid cases
and hospitalizations rocketing to the peak in a very short time), the sponsor and the project steering committee supported the
project manager’s decision to implement an agile method. The Scrum cycles (sprints) were set as two weeks so that a working app
and mobile website can be developed gradually with some of the requirements and functions at the end of each sprint, which can
allow frequent end-user feedback and interaction.

1. Rothman, J. (2017). Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. Pragmatic Bookshelf. ↵
2. Cobb, C. G. (2015). The project manager's guide to mastering Agile: Principles and practices for an adaptive approach. John
Wiley & Sons. ↵
3. Martin, J. (1991). Rapid application development. Macmillan Publishing Co., Inc. ↵
4. Martin, J. (1991). Rapid application development. Macmillan Publishing Co., Inc.. ↵
5. Retrieved from [Link] ↵
6. Retrieved from [Link] ↵
7. Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵

This page titled 12.2: Introduction to Agile is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

12.2.4 [Link]
12.3: Adopting and Creating an Agile Environment
12.2.1 A Case Study of the Penta Transformations
A Six-Month Cultural Transformation: The Penta Story [1]
Penta Technologies, a family-owned construction software company in Wisconsin, developed and provided customized accounting
and finance ERP systems, labor productivity suites, and payroll tools for construction back-office services. However, the
convenience of customization led to more complicated workload for the project teams and employees while it was a relief for the
clients. Rather than focusing on the effectiveness of projects and their outcomes, the company dealt mostly with the contract
negotiation and customer emergencies. The main issues were the implementation of a traditional project management approach that
made the frequency of delivery slow and inconsistent. However, the solution was not that easy just by switching to an agile
structure. The president and the COO figured out that there are organizational and cultural barriers that need to be overcome first.
First of all, they reduced the number of executives to three, which simplified the decision making and allowed space for the team to
identify the most urgent issue, optimizing the product development teams. But this was only the initial step to transition to a more
agile structure. The COO announced that they were going to partner with everyone in the organization to figure out the best
structure for the business. As a result, employees’ feedback was aggregated in five areas that need attention: (1) Remove functional
silos, (2) more ownership in the work, (3) remove unnecessary and complex processes, (4) stop micromanagement and improve
trust, and (5) more focus on value. Based on this valuable employee feedback, a team conducted research on different
organizational structures. The team suggested a transition to the Scrum framework which a team-based and servant-leadership
organizational structure. This was just the beginning for Penta. However, this case showed that organizations need to evaluate the
current organizational structure and culture, and develop a novel background and mindset over which they can build the new agile
structure. A new house cannot be constructed over an old and torn foundation. We need to ensure that the foundation is so strong
that it can bear

12.2.2 Creating a Novel Mindset: Agile

As can be seen in the case study of Penta Technologies above, organizations don’t start creating, adopting and implementing an
agile project approach in one day as is the case for all the actions organizations should take. A long and well-thought-out process is
inevitable to generate ideas effectively, which can benefit the organization in the long term. As for the agile environment, the
challenging process requires adoption of an agile mindset that spans throughout the organization including the executive team,
managers, supervisors, and all other employees. At the very beginning, organizations and their project teams and leaders should
answer many questions, some of which are provided below, to develop an implementation strategy[2]:
How can organizations, their employees, and project teams and in particular, their members, act in an agile manner?
Are there organizational impediments that we need take care of (e.g., issues in formal structure such governance and
policies, and informal structure such as organizational culture)?
What are the levels of acceptance and resistance that we may expect from the executives, managers, employees, project
managers, and team members?
How can we measure these levels (e.g. survey, interviews, focus group meetings) so that we can create an action plan?
What kind of activities (e.g., seminars, webinars, training, social events) do we need to organize?
What can our teams deliver quickly and obtain early feedback to benefit the next delivery cycle?
Are our products appropriate for quick incremental deliverables?
How can the teams act in a transparent manner?
What works can be avoided in order to focus on high-priority items?
How can a servant-leadership approach benefit the achievement of the team’s goals and project objectives?

12.2.3 Benefits and Challenges of Agile Project Management

When organizations start utilizing agile project management approach and principles, they can expect to see the benefits below:
They can find opportunities to deliver business benefits at an early stage through addressing straightforward problems.
They can shorten the time to introduce new products and services to the markets and customers.
They can increase and maintain the adaptability to changing needs of customers.

12.3.1 [Link]
 They can achieve an improved quality of products and services through short cycles and constant client and stakeholder
interaction and feedback.
Ultimately, they can maximize the return on investment.
Gustavsson (2016)[3] examined the literature to list the common benefits of implementing agile project management in a non-
software development context. Top ten benefits indicated by Gustavsson (2016) are listed below:
Better collaboration in the team
Increased customer interaction
Increased productivity and speed
Increased flexibility in coping with the change
Better understanding of goals/tasks/requirements
Increased transparency and visibility
Increased quality
Customer-centered value adding priority process
Increased knowledge sharing
Increased cross-organizational collaboration
However, Gustavsson (2016) also examined the problems and challenges while adopting and implementing agile approach, and
outlined eleven challenges as below:
Changing mindset to allow flexibility
Lack of process visibility
Buy-in from managers
Difficult to see benefits early in the project
Inadequate knowledge sharing
Individual work, lack of communication
Long-term planning
Lack of stakeholder engagement
Scope creep (uncontrolled expansion of the scope with product requirements and project activities)
Insufficient resource allocation
Redundant work
These results demonstrate that no one system, approach, or methodology is alone perfect. Project managers and team members
always need to take into account the coexistence of pros and cons of anything used in a project by incorporating the cost-benefit
analysis. While increased knowledge sharing was indicated as a benefit, challenges presented a challenge of inadequate knowledge
sharing. Thus, decision-makers and project managers should consider the factors that may cause inadequate knowledge sharing in
an agile environment. This is also valid for other elements such as flexibility, communication, early delivery, and resources as well
as triple constraints (i.e., scope, schedule, and budget).
Regarding the project success, Serrador and Pinto’s (2015) quantitative analysis of 1.002 projects across multiple industries and
countries concluded that agile methods have a positive impact on two dimensions of project success which are efficiency and
overall stakeholder satisfaction against organizational goals.

12.2.4 The Elements of an Agile Environment

Although the roles and the practices of each agile method and framework vary from one to another, there are common roles and
practices across them. In this section, we will elaborate on these.

[Link] Common Agile Roles and How Agile Team Works

There are three main roles in agile teams.
1. Cross-functional and self-organizing teams and their members
2. Product owner
3. Team facilitator
Considering the self-organizing structure of agile teams and the role of project manager as a team facilitator and servant leader, we
can first focus on the team members who form the agile teams. Cross-functional teams consist of members with various skills from

12.3.2 [Link]
different areas. If it is a software development team, it can be composed of designers, systems analysts, developers, testers, and
business unit representatives. Team members discuss the tasks and pick the ones they think would fit the best. Team facilitator (or
the project manager) doesn’t tell who should do what, but acts as an obstacle remover and a coordinator. Agile teams generally
work during short cycles (i.e., iterations) to release a working product, an incomplete but a testable partial product, which is named
as increments. Rather than creating the whole website with its all backend features in three months, these teams create a number of
web pages with some of the properties and functions in a short time (e.g., a two-week iteration). In the end of each iteration, the
team presents the increment in the form of a partial product (e.g., three web pages). The product owner representing the client and
the end-users provide the feedback about what they think of these three web pages. They may say “We want the navigation bar at
the top with that size and those colors” or “The pictures should not cover more than one third of the row while not zoomed in”.
These increments help the team receive feedback constantly. Therefore, they can work on each increment based on the feedback,
and they can improve the product. This provides the team with the opportunity to make timely and effective interventions which
otherwise would cause serious problems at the end of the project. So, when the team receives the feedback as regards the
navigation bar’s position and color, they apply the request to the current and future web page layouts. However, another feedback
may still want the team to change the position and color. This is an ongoing process with constant interaction with the client, end
users, and stakeholders. In a waterfall project management approach, the team finishes the development of the whole website, and
submit it to the client for the inspection of the client and its end users. However, in the meantime, a three-month duration passes,
and the possibility of receiving feedback from the client that can lead to a serious rework could be high.
As is discussed above, these teams are self-organizing teams, which means that team members decide on the tasks that each will
work during an iteration, rather than a team facilitator tell them what they need to do. Agile teams are generally small teams
smaller than 10 members. These teams use techniques to collaborate more effectively such as pairing, swarming, and mobbing.
Pairing is generally utilized by XP (Extreme Programming) teams when software developers write codes. While one member
works on coding, the second member checks the quality of the coding made by the first member. Another collaboration technique is
swarming through which multiple team members focus collectively on resolving a specific impediment.
A second agile role is the product owner who is responsible for guiding the direction of the product. Product owners can be a
representative of the internal or external client, or a person who represents the client and the stakeholders. Product owners keep a
constant daily communication with the agile team. They provide the product backlog which includes the user stories
(requirements), and prioritize the user stories. Product owners are the bridge between the clients (and their end-users, customer and
stakeholders) and the agile team. The feedback conveyed by the product owner is used to develop the increments at each cycle.
Product owners communicate with subject matter experts to produce good-quality user stories (requirements) and offer effective
feedback. Recently, IIBA (International Institute of Business Analysis) have offered a new certificate, “Certificate in Product
Ownership Analysis”, which integrates product ownership and business analysis[4].
The third and the final role is a team facilitator which can be also named as project manager, scrum master, project team lead, or
team coach based on the method or framework utilized, and/or the organization’s guidelines. In agile teams, project managers’ role
is different from the traditional role they play in waterfall (predictive) project management. Generally, in traditional approach,
project managers are the ultimate authority in a team who decides which tasks are carried by which member. Their authority with
respect to the control is high. However, in agile teams, project managers should be the facilitators and coaches, and they need to
adopt a servant leadership approach. Team members organize the tasks that needs to be carried out during a cycle. Project managers
help them in removing the impediments, overcoming the conflicts inside the team or with stakeholders, and coaching the members
to allow them to improve their skills. For example, if team members find themselves in a conflict with a stakeholder and cannot
solve the issue themselves, the project manager gets involved to resolve the conflict. Or developers in the team may ask the project
manager to buy a license for a software which can help them produce a better quality IT solution or complete the activities earlier.
Servant leaders empower their teams and facilitate their teams’ success by promoting self-awareness, listening, helping people
grow, coaching, promoting safety, respect and trust, and promoting the energy and intelligence of others[5]. They practice their
leading through service to the team focusing on understanding and addressing the needs and development of team members. Hence,
interpersonal skills such as team building, motivating, communicating, influencing, decision making, political and cultural
awareness, negotiating, facilitating, managing conflict, and coaching are more important than the technical skills[6].

[Link] Common Agile Practices

Agile teams utilize various artifacts and events to conduct their tasks and achieve project objectives. Although they are used in
different agile methods with same or different names, the Scrum framework which is the most common agile method make use of
all of these artifacts and events. They are:

12.3.3 [Link]
 1. Team charter
2. User stories and backlog
3. Planning of each iteration or cycle (Not a comprehensive upfront planning)
4. Daily standups
5. Demonstration or reviews
6. Retrospectives
7. Backlog refinement
A team charter is necessary for all types of projects. It consists of team values, working agreements, ground rules, and group
norms. It is a social contract which indicates how the team members interact with each other. The primary objective of a team
charter is to create an agile environment where project managers, team members, and product owner can work to the best of their
ability. In agile projects, the team charter has to define what “ready” and “done” mean. In particular, when teams use a Kanban
board (see Figure 12.5), tasks are organized on a timebox (i.e., cycle, iteration, Scrum sprint) to display and monitor their status
such as to-do, doing (in progress), and done. Teams can assess the completeness of user stories and tasks according to the definition
of “done”. Therefore, they can evaluate the completed tasks consistently.
User stories are requirements presented in a story form for the team to understand the needs of the client and stakeholders. They,
together, establish the product backlog, the basis of the plan and each iteration. The structure of a user story is given below. These
stories don’t only convey what a stakeholder expects from a product or service, but also includes the reason why that stakeholder
needs. The project team can better understand why the stakeholder asks for a requirement. It can give a clue to the team if the
requirement is a must or not, or if it is possible to incorporate into the product.
As a “user/stakeholder”, I want to “perform a function / an action / an app feature” so that I can “acquire a benefit / an expected
outcome”.
Let’s consider that our grocery chain’s m-commerce project is conducted as an agile project. Therefore, we have created some of
the user stories. It is of high importance to keep in mind that product owner doesn’t need to list all the user stories since one of the
advantages of agile projects is that a product evolves throughout the project based on the feedback of the end-users. Three user
stories are provided below as examples that can be used in this m-commerce project:
As a customer, I want to browse all the items under relevant categories (e.g., bakery, beverages, laundry and cleaning,
electronics) so that I can find the items I am looking for and view all the related items on a single window or page, or more than
one page with the page numbers displayed at the bottom of each page.
As an administrator, I want to disable accounts which are not valid anymore so that we can manage the active accounts and
archive the disabled accounts.
As a shopper (or a store employee who is picking up the ordered items from the shelves), I want to view all the online orders
assigned to me on my mobile device so that I can start shopping two hours before the delivery begins.
Table 12.1 exhibits four user stories selected from our m-commerce project. In order to keep the user story column shorter, we
removed the “so that” part which provides the reasoning of why the stakeholder needs this requirement.
Table 12.1: A Backlog composed of Four User Stories

User Story Estimation Priority

As a customer, I want to log on the mobile app with the same username and password that I 2 1
use to log on the website.

As a customer, I want to create an account in three minutes. 5 2

As an administrator, I want to see all the orders on my dashboards, and filter and sort them 2 3
according to various criteria.

As a store shopper, I want to view all the online orders assigned to me in my mobile device. 3 4

12.3.4 [Link]
Product owners prioritize the user stories. Before each cycle starts, sufficient numbers of user stories with the highest priority are
pulled from the backlog so that the team can work on these user stories. Let’s assume that the user stories in Table 12.1 were
selected for the first cycle / timebox since the team decided to pull the highest priority user stories for the first cycle. Priority is
only one factor to consider while selecting the user stories. Teams also estimate the story size taking into account the estimated
time to finish and other criteria such as the effort and resources required to complete these tasks. Analogous estimating technique
that takes into account the information from other projects, experience of project managers and team members from previous
projects, and lessons learned helps the teams to create these estimates. Estimations are very important to make a better planning if
the team can complete them in one cycle or iteration. While scrum teams set a specific time to finish each iteration (e.g., 1 week, 2
weeks, 30 days), Kanban teams focus on the user stories by means WIP (Work in Progress) limits. Therefore, Kanban teams don’t
necessarily set a timebox, but they commit to completing an increment of work by focusing on a limited number of manageable
tasks.
Instead of carrying out an overall project planning and trying to predict all the aspects of a project (e.g., scope, requirements,
schedule, cost) as is done in waterfall project before the implementation phase starts, agile projects work on a limited number of
requirements. Thus, planning can be done at the beginning of each cycle, which allows the team to adjust itself according to the
feedback from end-users, and changing requirements and conditions. As the project progresses, agile teams generally spend less
time in the initial phases (e.g., requirements, planning, design as exhibited in Figure 12.4). Hence, they can focus more on
implementation.
Another practice in agile projects is the daily standup meetings which occur mostly in the early morning before starting the daily
tasks. They are called standup meetings since members generally stand up instead of sitting so that they can accelerate the meetings
by avoiding the comfort of sitting. Although team members don’t meet in person at the collocated offices as it used to be due to the
wider utilization of virtual teams recently and because of the Covid-19 pandemic measures that mandated to stay at home, agile
teams continue holding these standup meetings, being the mostly utilized agile practice[7], in online platforms such as Microsoft
Teams and Zoom. The project leader or a team member can take the lead in standup meetings. In general, team members discuss
the three questions below:
1. What have I completed since the last standup meeting?
2. What am I planning to complete until the next standup meeting?
3. What are the impediments, risks and problems that I may encounter?
When teams create an increment (e.g., a website with three web pages, an EPR module for accounting with limited functions, a
prototype of a machine that is intended to manufacture spare auto parts) at the end of a cycle, they can demonstrate how this
increment works. The product owner assesses the demonstration and collects the feedback from end-users. Therefore, the team can
continue building upon the increment according to the feedback. Although negative feedback from the product owner may lead to a
frustration for the team, frequent feedback in earlier stages prevents the team from heading in a wrong direction. The team leader’s
servant leadership role as a coach can help the team enable frequent delivery.
At the end of each cycle, agile teams discuss what worked and what could have been better in that cycle. These retrospectives help
the teams learn from their previous work. The lesson learned process becomes more frequent in line with the review and feedback
from the product owner and end-users. As one of the agile principles indicate, “at regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its behavior accordingly.[8]” Teams may also decide to retrospect at different times,
not only limited to the end of the cycles. For example, the project manager may call for a retrospective meeting when the team is
stuck and cannot complete the work. Therefore, this meeting can help the team determine the underlying reason of the bottleneck
and find a solution with a facilitated brainstorming session.
The last common agile practice to mention is the backlog refinement process which occurs generally in the middle of iterations.
In this refinement meetings, product owners present story ideas to the team and the team learns about the potential challenges or
problems in the stories[9].

1. [Link]. (2020). A Six-Month Cultural Transformation: The Penta Story. Retrieved from
[Link]
2. Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵
3. Gustavsson, T. (2016). Benefits of agile project management in a non-software development context: A literature review. In
Fifth International Scientific Conference on Project Management in the Baltic Countries, April 14-15, 2016, Riga, University of
Latvia (pp. 114-124). Latvijas Universitate. ↵

12.3.5 [Link]
 4. Information is available on [Link]

product-ownership-analysis-iiba-cpoa/#get-cpoa-certified. ↵
5. Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵
6. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵
7. [Link]. (2021). 15th State of Agile Report. [Link]
8. Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵
9. Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵

This page titled 12.3: Adopting and Creating an Agile Environment is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or
curated by Abdullah Oguz (MSL Academic Endeavors) .

12.3.6 [Link]
12.4: Common Agile Framework and Methods
Although there are many agile approaches, only several of them are utilized commonly by organizations. The Agile Practice Guide by PMI (Project Management Institute) lists the single-team agile
methods as below:
1. Scrum
2. Extreme Programming (XP)
3. Kanban
4. Crystal methods
5. Scrumban
6. Feature-Driven Development (FDD)
7. Dynamic Systems Development Method (DSDM)
8. Agile Unified Process (AgileUP)
Besides single-team agile approaches, higher-than-single-team level (e.g., enterprise-level) scaling frameworks are provided below:
1. Scrum of Scrums
2. Scaled Agile Framework (SAFe®)
3. Large Scale Scrum (LeSS)
4. Enterprise Scrum
5. Disciplined Agile (DA)

12.3.1 Scrum
Scrum is the most utilized single-team agile method. It consists of roles, events, artifacts, and rules. Scrum events are sprints, sprint planning, daily scrum, sprint review, and spring retrospective.
Scrum artifacts are product backlog, sprint backlog, and increments. It uses an iterative approach to deliver a working product (i.e., an increment) at the end of each timebox. These timeboxes are
called sprints which last generally for one month, or four weeks, or shorter with consistent durations. When a two-week sprint duration is determined, all the sprints are set at two weeks. At the end
each sprint, a potentially releasable increment of product is produced. A scrum team is composed of product owner, development team, and scrum master. The scrum master is responsible for ensuring
the Scrum process is upheld and works to ensure the Scrum team adheres to the practices and rules as well as coaches the team on removing impediments[1].

12.3.2 Kanban
The Japanese word “kanban” means “visual board” or a “sign”. It was first developed and applied by Toyota as a scheduling system for just-in-time manufacturing[2]. The workflow is visualized on a
Kanban (Figure 12.5). The Kanban board is also used by Scrum teams.

Figure 12.5: A task board in Kanban

(Retrieved from [Link]
The work is split into pieces, and each item is written on a card. Then, they are put on the wall, or it can be visualized in a software program or a website such as Jira. Explicit limits are assigned in
Kanban projects so that each workflow state can have limited number of in-progress items (Work in Progress – WIP). The team tries to finish these tasks in the shortest possible time. This lead time is
measured so that the team can optimize the process to make the lead time as small and predictable as possible.

12.3.3 Scrumban
Scrumban is an agile approach originally designed as a way to transition from Scrum to Kanban[3]. Scrumban teams use Scrum as a framework and Kanban for process improvement. It uses the
prescriptive nature of Scrum to be agile, and uses the process improvement of Kanban to allow the team to continually improve its process. In Scrumban, the work is organized into small “sprints” and
leverages the use of Kanban boards to visualize and monitor the work. There are no predefined roles in Scrumban as is the case in Kanban. However, the Scrumban teams generally retain the Scrum
roles.

12.3.4 eXtreme Programming (XP)

As the name implies, XP is utilized by software teams. It is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team.
XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development[4]. This method does not only focus on project management like other methods
and frameworks do, but also focuses on how teams actually build code. Like Scrum, it has practices and values that help teams get into an effective mindset. One of the primary practices of XP is pair
programming through which coding process is conducted by two developers working together at a single computer[5]. While one member works on coding, the second member checks the quality of
the coding made by the first member. Another unique XP practice is the coding the unit test first. Before writing the code, a unit test is created so that new codes are automatically tested[6].

12.4.1 [Link]
12.3.5 SAFe® (Scaled Agile Framework)
The SAFe is the most common scaling framework according to the 15th State of Agile Report published in 2021[7]. Thirty-seven percent of respondents indicated that their organization applies SAFe
while 9% uses scrum of scrums and 6% uses enterprise scrum. The SAFe focuses on providing a knowledge base of patterns for scaling development work across all levels of the enterprise (Figure
12.6). It also focuses on detailing practices, roles, and activities at the portfolio, program, and team levels[8]. SAFe organizes the enterprise around value streams that focus on providing continuous
value to the customer.

Figure 12.6: SAFe 5 for Lean Enterprises

(Retrieved from [Link]

1. Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵
2. Retrieved from [Link] ↵
3. Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵
4. Retrieved from [Link] ↵
5. Retrieved from [Link] ↵
6. Retrieved from [Link] ↵
7. [Link]. (2021). 15th State of Agile Report. [Link]
8. Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵

This page titled 12.4: Common Agile Framework and Methods is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

12.4.2 [Link]
12.5: Recent Trends in Agile Project Management
Organizations, whether they are multinational corporations, non-profits, government agencies, or international organizations, often
make use of agile project methods and frameworks. Although agile started with the software development projects (see Section
12.1), its utilization has become common in other IT projects, and eventually non-IT projects such as new product development
projects have practiced agile methods increasingly. A survey conducted by PMI (Project Management Institute) found that 23% of
the organizations worldwide utilized agile techniques whereas 47% used predictive approach. However, another 23% also used
hybrid approaches (e.g., using waterfall’s sequential and linear project life cycle stages while establishing a more frequent
communication and feedback system with the client and stakeholders).
A recent study is the 15th State of Agile Report conducted in 2021 by [Link][1]. Their data is up-to-date and reflect the impact of
COVID-19 pandemic. Their sample is dominantly composed of people who work in agile teams or in organizations which
implement agile approach. This report highlights salient insights from the practice as detailed below:
The most popular agile approach is Scrum. 66% of the respondents identified Scrum as the methodology they follow most
closely. Besides, 9% indicated that they use ScrumBan and 6% blends the Scrum with XP. Therefore, Scrum’s share is 81% in
total.
The most popular scaling approach is SAFe with 37%. SAFe was followed by Scrum@Scale / Scrum of Scrums (9%) and
Enterprise Scrum (6%).
The top five agile techniques and practices used by the organizations are daily standups (87%), retrospectives (83%),
sprint/iteration planning (83%), sprint/iteration reviews (81%), and short iterations (63%).
The top five agile planning and delivery tools are Kanban boards (77%), taskboards (67%) spreadsheets (66%), agile project
management tools (64%), and bug trackers (62%).
The top five reasons to adopt agile are “enhance ability to manage changing priorities”, “accelerate software delivery”,
“increase team productivity”, “improve business and IT alignment”, and “enhance software quality”.
The top five challenges in organizations regarding agile practices are “inconsistent processes and practices across teams”,
“organizational culture at odds with agile values”, “general organization resistance to change”, “lack of skills/experience with
agile methods”, and “not enough leadership participation”.
Eighty-one percent of the respondents recommended Jira as a software tool in agile planning and management. Jira was
followed by [Link] agility (formerly VersionOne) and Azure DevOps. Thirty-five percent recommended Microsoft Project.

1. [Link]. (2021). 15th State of Agile Report. [Link]

This page titled 12.5: Recent Trends in Agile Project Management is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or
curated by Abdullah Oguz (MSL Academic Endeavors) .

12.5.1 [Link]
12.6: Key Takeaways
Key Takeaways
Agile project management approach has been utilized by project teams since 1990s when it started to emerge among software
developers.
In 2001, agile practitioners published a manifesto named “Manifesto for agile software development” that put forward a set of
guiding principles for agile project management.
Agile manifesto highlights the importance of “individuals and interactions”, “working software”, “customer collaboration”, and
“responding to change” to distinguish itself with the traditional waterfall project management approach.
While waterfall approach is linear and sequential, agile approach compresses the sequential phases in small timeboxes
(iterations) to create increments at the end of each timebox.
There main agile roles are cross-functional teams and their members, product owners, and team facilitators.
Common agile practices are team charter, user stories and backlog, planning of each iteration or cycle, daily standups.
demonstration or reviews, retrospectives, and backlog refinement.
The structure of a user story is generally in a format as follows: As a “user/stakeholder”, I want to “perform a function / an
action / an app feature” so that I can “acquire a benefit / an expected outcome”.
The Agile Practice Guide by PMI (Project Management Institute) lists the single-team agile methods as Scrum, Extreme
Programming (XP), Kanban, Crystal methods, Scrumban, Feature-Driven Development (FDD), Dynamic Systems
Development Method (DSDM), and Agile Unified Process (AgileUP).
The SAFe® (Scaled Agile Framework) is the most common scaling framework according to the 15th State of Agile Report
published in 2021. It focuses on providing a knowledge base of patterns for scaling development work across all levels of the
enterprise.

This page titled 12.6: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

12.6.1 [Link]
12.7: Questions and Exercises
There are 10 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 12.7: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

12.7.1 [Link]
12.8: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 12.8: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

12.8.1 [Link]
 CHAPTER OVERVIEW

13: Closing the Project

13.1: Learning Objectives and Overview
13.2: Closing the Project
13.3: Activities to Close a Project
13.4: Post Implementation Reviews and Archiving Documents
13.5: Validating the Realization of Business Benefits
13.6: Key Takeaways
13.7: Questions and Exercises
13.8: Attribution

This page titled 13: Closing the Project is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

1
13.1: Learning Objectives and Overview
Learning Objective
1. Explain the importance and benefits of the project closure.
2. Elaborate on the activities conducted by the project team while closing a project.
3. Explain the post-implementation review.
4. Describe how the benefits realization is monitored and validated following the closing phase of a project.

Overview
As discussed in Chapter 1 “Introduction to Project Management”, projects are temporary. They have a definite beginning and
ending date. Projects finish when their unique outcomes (i.e., results, deliverables) are produced and become available for the client
and its end users as well as the customers to use. Once the project deliverables are approved by the internal or external client (or an
inspection and acceptance committee), the project manager can start the closing phase. Although closing a project might seem
easier compared with the implementation phase, this process still requires delicate attention as detailed in the following sections.

This page titled 13.1: Learning Objectives and Overview is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

13.1.1 [Link]
13.2: Closing the Project
All projects end. Some of them are completed successfully when their triple constraints are within the acceptable ranges (e.g.,
budget is overrun by 7% when the range is 10%), project objectives are accomplished, and the stakeholders, in particular the client,
are happy with the outcome. However, as discussed in Chapter 1 (see 1.4 Project Success), it is not uncommon for many projects to
underperform due to various factors such as scope creep (i.e., uncontrolled expansion of product requirements and project
activities), schedule delays, budget overruns, and miscommunication with stakeholders, or to fail that leads to early termination. In
both cases, whether they are successful or not, projects need to be closed. Therefore, project managers must lead the process to
formally close the project. This process helps project managers, teams, project sponsors, and internal and external stakeholders
evaluate the project performance, and assess what went right and wrong. Figure 13.1, which is originally available in Chapter 1,
exhibits the project life cycle if the project follows all the phases, and can make it to the end of the project by producing the
deliverables.

Figure 13.1: Project Life Cycle Phases (including the pre-project and post-project works)
Project completion is often the most neglected phase of the project life cycle. Once the project is over, it’s easy to pack things up,
throw some files in a drawer, and start moving right into the initiation phase of the next project. Hold on. We are not done yet.
When closing the project, the project manager reviews the project management plan to ensure that all project work is completed
and that the project has met its objectives[1]. It is of high importance here to highlight that project closure cannot start unless the
deliverables (e.g., a new mobile application for online shopping, a new data center for an insurance company, a newly developed
diabetics medication, an apartment complex that is ready to accept new tenants, an improved business process, etc.) are ready to
use. Therefore, the implementation phase in the project life cycle is completed with the acceptance of these deliverables (Figure
13.1) and signals that it is time to close the project.

13.1.1 Case Study: Closing out the Grocery LLC’s M-Commerce Project
Grocery LLC’s M-Commerce Project started on May 2, 2022, and the deployment was completed on November 3, 2022. The
mobile app was subject to alpha testing first. Then, beta testing was carried out during the “Pilot” phase, where customers installed
the beta version on their smartphones and did their online shopping. During the implementation of the beta version, all the feedback
from customers and their mobile devices was evaluated and the bugs and problems were corrected. The inspection and acceptance
committee was composed of Grocery LLC’s three representatives from the IT department, two representatives from the Operations
department, and two store managers. The committee checked the final version and didn’t find a problem that may hinder the launch
of the mobile app. The sponsor approved the sign-off after they received the inspection and acceptance report. Finally, the mobile
app was introduced to Android and Apple online stores and is ready to use by online customers. Now, customers can log in with
their usernames and passwords, browse items, add them to their carts, proceed to checkout, and complete their payments. We can
start the closing phase since the deployment has been completed. As seen in Figure 13.2, “Closeout & Project Implementation
Review” can start as the deployment is completed.

13.2.1 [Link]
 Figure 13.2: Project Life Cycle Phases of M-Commerce Project
The project’s closeout activities are given in Table 13.1.
Table 13.1: Closeout Activities of Grocery LLC’s M-Commerce Project

WBS Number Activity & Pot Implementation

10 Closeout & Post Implementation Review

10.1 Document lessons learned

10.2 Archive all documents

10.3 Complete all pending payments

10.4 Final meeting with stakeholders to close the project

10.5 Disband the team

We will refer to this case study in the following sections when needed.

13.1.2 Key Activities to Consider while Closing the Project

The key activities when we close out the project can be listed below:
1. Ensuring that all tasks are completed, and the deliverables have been checked and approved by the client (or its inspection and
acceptance committee).
2. Collecting project reports and documents and making sure that all project documents and deliverables are up-to-date.
3. Making sure that all issues (e.g., disputes with vendors, conflict with stakeholders, legal issues, issues in compliance with
standards) are resolved.
4. Ensuring that all costs are charged to the project.
5. Releasing the final deliverables to the project sponsor, the internal and external client, and appropriate stakeholders.
6. Disseminating information to all the stakeholders to formalize acceptance of the project, and its deliverables (products or
services).
7. Notifying all the stakeholders of the project completion.
8. Terminating supplier and vendor contracts.

13.2.2 [Link]
 9. Consulting with the legal department to ensure that there are not and won’t be any legal issues that may result from the
contracts and legally binding documents.
10. Releasing project resources (e.g., team members, facilities, equipment, materials).
11. Conducting a post-implementation review including a discussion about the lessons learned.
12. Finishing the paperwork, archiving, and storing all the project information including the lessons learned document in an
organizational repository.
13. Ensuring that all the project information can be accessed easily (e.g., cloud storage, physical files) by the current project team
and future project managers and teams.

1. Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.).
Project Management Institute. ↵

This page titled 13.2: Closing the Project is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

13.2.3 [Link]
13.3: Activities to Close a Project
The following sub-sections elaborate on the activities to close a project.

13.2.1 Ending the Implementation Phase

After we ensure that all the project activities are completed and the deliveries have been accepted by the client (the product owner
and end users), we can start the activities to close the project. Once the project activities are completed in the implementation
phase, we need to request the project sponsor to initiate a formal acceptance process through which the internal or external client
(or the inspection/acceptance committee) is involved. They’re interested in knowing if the product or service of the project meets
the objectives the project set out to accomplish. If our documentation is up-to-date, we will have the project results at hand to share
with them.
In this phase, it is also of high importance to make sure that the implementation phase covered the post-project work composed of
operation and maintenance. The project manager should ask the questions below to make sure that the project deliverables can be
maintained and supported effectively after the deliverables are handed over to the client[1].
Let’s consider the questions below for our m-commerce project:
Does the vendor offer 24/7/365 support for the mobile app? Are the rates for such support acceptable to the client?
Has a formal service level agreement been developed and put into effect between the organization and vendor to maintain
continued support and service?
What provisions have been made for future upgrades and enhancements of the mobile app?
Does the necessary cloud capacity and storage exist for the future expansion of the system?
Has Grocery LLC’s IT support staff been trained in supporting the technology? Can they resolve technical issues, or are they
able to contact the vendor or third-party suppliers for further support?
Has the help desk staff been trained to identify and log calls from users of the solution?
Is the help desk number clearly displayed on the mobile app, so our in-store shoppers and customers know whom to contact?
Has the project manager provided the help desk with a script of possible problems that users of the new solution could
encounter?

13.2.2 Contract Closure

Contracts come to a close just as projects come to a close. Contracts are different from project charters and project management
plans (Figure 13.3). They are legally binding documents with the client and the contractors or subcontractors. If the client is
internal which means that it is a functional unit of our organization, we won’t need a contract. In this case, the project charter and
the plans will act as formal documents that keep the project sponsor and the project manager accountable.

13.3.1 [Link]
 Figure 13.3: The Relationships Among the Project Sponsor, Project Manager, Internal and External Clients, Customers, and
Stakeholders
Contractors and subcontractors may be still present if some project activities or the overall project is outsourced to them. Therefore,
not all projects require a contract closure process. Contract closure is concerned with completing and settling the terms of the
contracts. In M-Commerce Project, as mentioned in Chapter 11, we outsourced the development component to a software company.
We assumed that we need to pay $2,000 for each phase. Total cost baseline for all ten activities was $20,000 ($2,000 x 10).
Therefore, our planned value was $20,000. When we finished five activities, the actual cost was $11,200. When closing the
contracts, we should pay attention to the actual costs and the terms and conditions of the contract. The project manager should ask
questions such as “Did the contractor finish all the activities and meet the requirements as indicated in the contract?”, “Are all the
cost calculations correct?”, “Did we make all the payments?”, and “Do we need to wait for a while to make some payments as
stipulated in the contract?”
The contract closure process supports the project completion process because it determines if the work described in the contracts
was completed accurately and satisfactorily. Obviously, this process applies only to those phases, deliverables, or portions of the
project that were performed under the contract. Contract closure updates the project records, detailing the final results of the work
on the project. Contracts may have specific terms or conditions for completion. We should be aware of these terms or conditions so
that project completion isn’t held up because we missed an important detail. If we are administering the contract ourselves, we
should be sure to ask our procurement department if there are any special conditions that we should be aware of so that the project
team doesn’t inadvertently delay contract project closure.
One of the purposes of the contract closure process is to provide formal notice to the seller, usually in written form, that the
deliverables are acceptable and satisfactory or have been rejected. If the product or service does not meet the expectations, the
vendor will need to correct the problems before we issue a formal acceptance notice. Before the contract is closed, any minor items
that need to be repaired or completed are placed on a punch list, which is a list of all the items found by the client or team, or
manager that still remain to be done. Hopefully, quality audits have been performed during the project, and the vendor was allowed
to make corrections earlier in the process than the closing phase. It’s not a good idea to wait until the very end of the project and
then spring all the problems and issues on the vendor at once. It’s much more efficient to discuss problems with the vendor as the
project progresses because it provides the opportunity for correction when the problems occur.
The project team will then work on all of the items on the punch list, building a small schedule to complete the remaining work. If
the number of items on the punch list is too large or the amount of work is significant, the project team continues to work on the

13.3.2 [Link]
project. Once the punch list becomes smaller, the project manager begins closing down the project, maintaining only enough staff
and equipment to support the team that is working on the punch list.
If the product or service does meet the project’s expectations and is acceptable, formal written notice to the seller is required,
indicating that the contract is complete. This is the formal acceptance and closure of the contract. It’s the project manager’s
responsibility to document the formal acceptance of the contract. Many times, the provisions for formalizing acceptance and
closing the contract are spelled out in the contract itself.
If we have a procurement department handling the contract administration, they will expect us to inform them when the contract is
complete and will in turn follow the formal procedures to let the seller know the contract is complete. However, we will still note
the contract completion in our copy of the project records.

13.2.3 Disbanding the Project Team and Reassigning All Project Resources
Project managers need to consider in an earlier stage what project team members would do after the project ends. If they are the
employees of our organization, project managers should provide sufficient and early notification to the team members to relieve
them of future concerns. They may go back to their functional departments to continue with their operational tasks or get assigned
to a new project. If the organization has a Project Management Office (PMO), and these members work at this PMO, they will
continue working on other projects. Project managers should keep their managers, or other project managers, informed as the
project gets closer to completion, so that they have time to adequately plan for the return to their departments or transfer to other
projects. Project managers should let them know a few months ahead of time what the schedule looks like and how soon they can
plan on using the team members on new projects. This gives the other managers the ability to start planning activities and
scheduling activity dates.
Besides the team members, we also need to consider other resources such as physical resources, facilities, materials, and equipment
used by the team. If there are unused materials that cannot be returned to the supplier, and also consumables, they can be
transferred to other projects or relevant departments so that they can use them and save some money. If the project team used office
space, a manufacturing facility, or a lab, the facilities department of the organization must be notified. Timely notifications would
help the organization plan in advance for the utilization of these resources by other projects and units, or if they need to be sold or
released.

13.2.4 Final Payments

The final payments are usually more than a simple percentage of the work that remains to be completed. Completing the project
might involve fixing the most difficult problems that are disproportionately expensive to solve, so the final payment should be large
enough to motivate the vendor to give the project a high priority so that the project can be completed on time.
If the contractors, subcontractors, suppliers, and vendors have met all the contractual obligations, including fixing problems and
making repairs as noted on a punch list, which lists the work that doesn’t conform to contract specifications, the project team signs
off on the contract and submits it to the accounting department for final payment. They are notified that the last payment is final
and completes the contractual agreement with the project. Besides, the performance of suppliers and vendors is reviewed to
determine if they should still be included in the list of qualified suppliers or vendors.
In some cases, there may be a provisional acceptance instead of a final acceptance. Thus, the final acceptance may take place later
(e.g., one year after the provisional acceptance). A small amount of payment may be held for the final acceptance. Or the contract
may contain fines in case of problems that may occur until the final acceptance.

13.2.5 Administrative Closure & Archiving of Project Documents

The project manager must ensure that all the administrative tasks required to close the project have been completed. Thus, the
project manager can use a checklist as shown in Table 13.2.
Table 13.2: A Checklist for the Administrative Closure [2]

Item Completed

Project Team

13.3.3 [Link]
 Performance reports shared with functional managers

One-on-one debriefs completed

Coaching plans updated

Resources released to functional units and/or other projects

Project completion party completed

Project documents

All inspection and acceptance reports received

Lessons learned report filed, uploaded to the online repository for the access of all project teams

Contract closure completed

Final project report completed

All project documents archived

Project manager

Wrap-up meeting with the sponsor, client, key stakeholders, etc. completed

Personal development plan updated

The following are some of the project documents that are archived:
Business case, needs assessment, and project benefits management plan
Project charter
Project management plan and its sub-plans (e.g., plans for scope, requirements, schedule, cost, quality, resources,
communication, risks, procurement, stakeholders, change, and configuration)
Scope, schedule, and cost baselines
Basis of estimates
Team charter
Risk register
Issue log
Quality reports
Test and evaluation documents

13.3.4 [Link]
 Inspection and acceptance reports
All financial documents (e.g., pay stubs, invoices)
Lessons learned register
Final project report
The documents associated with the project must be stored in a safe location where they can be retrieved for future reference. Signed
contracts or other documents that might be used in tax reviews or lawsuits must be stored. Organizations have legal document
storage and retrieval policies that apply to project documents and must be followed. Generally, organizations and Project
Management Offices (PMOs) store all the project documents in an electronic folder and/or a software program.
Care should be taken to store documents in a form that can be recovered easily. If the documents are stored electronically, standard
naming conventions should be used so documents can be sorted and grouped by name. If documents are stored in paper form, the
expiration date of the documents should be determined so they can be destroyed at some point in the future.

13.2.6 Sample Sponsor Project Closure Letter

A sample letter a project sponsor can write has been provided below[3]:
Dear <Salutation>,
Thank you for allowing us the honor of working on <Project X>. We found working with both yourself and your organization to
be a fruitful experience and are pleased to present the following results:
The successful outcome of <Project X>
<Deliverable 1>
<Deliverable 2>
<Deliverable 3>
The expected delivery date of<MM/DD/YYYY> was met
The project came in at <percent over/under budget>
Surveyed stakeholder approval was <#> out of <#>
At this time, we consider <Project X> to be completed and are submitting our final invoice for $<XX,XXX> to your accounts
receivable department under your purchase order number <P.O. Number>. Your help in securing payment for our services will be
appreciated.
Additionally, during the project, we identified the following potential opportunities for your review:
<Improvement A>
<Improvement B>
<Improvement C>
Should you be interested in pursuing any of these options and/or additional opportunities, please consider utilizing our organization
so we can leverage our skills and experience with you. Again, thank you for selecting us to work on your project. If you have any
questions or comments, please do not hesitate to contact me.
Sincerely,
Project Sponsor

1. [Link]. (n.d). Checklist for Support After Project Closure. Retrieved from
[Link]
2. Jordan, A. (n.d.). Project Closure Report. Retrieved from [Link]
closure-report↵
3. [Link]. (n.d). Sponsor Project Closure Letter. Retrieved from
[Link]

This page titled 13.3: Activities to Close a Project is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by
Abdullah Oguz (MSL Academic Endeavors) .

13.3.5 [Link]
13.4: Post Implementation Reviews and Archiving Documents
13.3.1 Lessons Learned
Regular reviews are made during the project in the presence of team members and other stakeholders if needed. These reviews help
the project manager and the team review the current situation, determine if there is a need to revise the project documents and
plans, and take timely actions to prevent any problems that may occur later in the project. After the implementation of project
activities is finalized and the deliverables are inspected and accepted by the client, the project team reviews all the documents and
meets to discuss what went well and wrong during the project, and what could have been done to avoid the problems that occurred.
It is of great importance to remember here that the lesson learned process doesn’t start in the close-out phase. As can be recalled
from Figure 13.4 (also see Chapter 1), the closing process starts before the closing phase of the project life cycle starts. The project
team has already produced many documents, reports, logs, and registers, and they have been edited and numerous new records
have been added in parallel with project activities in the implementation phase. Therefore, some aspects of the closing process such
as keeping the lessons learned register can start during the implementation when the project team learns from their experience and
add them into the lessons learned register after a thorough discussion and assessment.

Figure 13.4 Project Management Process Groups (Adapted from PMBOK Guide 6th Edition) (Have you gotten permission from
PMI to use this graph?)
If the project is considered a success, the discussion can center on why the project was successful and the challenges that had to be
overcome in order to achieve success. Lessons learned meetings are often quite enjoyable when the project was successful. If the
project was unsuccessful, the conversation centers on the causes of failure. Table 13.3 provides two lessons from the M-Commerce
project.
Table 13.3: Lessons Learned Register for M-Commerce Project

Lessons Learned Recommendation for Future Projects

Although our Risk Register identified a risk stating that “Cost In future projects, it is of high importance to determine the risk
estimates may be exceeded considering the factors of inflation and owner as the project manager, not another member. Besides, a
foreign exchange currency rates.” the risk trigger was indicated as second person can be assigned to assist the project manager.
“If the CPI (cost performance index) drops below 0.90, we will
need to seek additional funding from management.”, the Systems
Analyst 1 did not notify the project manager and the team of the
problem when CPI decreased to 85%. An unexpected spike in the
inflation rate in the USA increased the activity costs.

Our mobile app had serious issues regarding the bugs, and the app In future projects, in the recruitment process, the developers and
stores notified us of the deficiencies in the field of privacy. The testers should be asked to include their experience in previous
developers and testers didn’t respond on time. mobile app projects in detail in their job applications. A minimum

13.4.1 [Link]
 of three years of experience should be required. Besides, they
should explain how they solved problems.

Many project leaders request external facilitation in this situation so they can fully
participate in the discussions. In addition, an external facilitator can help ensure the
conversations remain objective and avoid tones of blame. A common approach is to
identify, all in the context of the project’s objectives, what should be continued, what
should be started, and what should be stopped. This is often referred to as the
start/stop/continue approach.
Quality management is a process of continual improvement that includes learning from past projects and making changes to
improve the next project. This process is documented as evidence that quality management practices are in use. Some organizations
have formal procedures for changing work processes and integrating the lessons learned from the project so future projects can
benefit. Some organizations are less formal in the approach and expect individuals to learn from the experience, take the experience
to their next project, and share what they learned with others in an informal way.

13.3.2 Trust and Alignment Effectiveness

The project leadership reviews the effect of trust—or lack of trust—on the project and the effectiveness of alignment meetings in
building trust. The team determines which problems might have been foreseen and mitigated and which ones could not have been
reasonably predicted. Project stakeholder register, change log, issue log, and risk register can help the team in this assessment.
Other questions that can be asked in this assessment are:
What were the cues that were missed by the team that indicated a problem was emerging?
What could the team have done to better predict and prevent trust issues?

13.3.3 Schedule and Budget Management

The original schedule of activities and the network diagram is compared to the actual schedule of events. Earned Value
Management (EVM) tools can help the team a lot while making this comparison (see Chapter 11). Events that caused changes to
the schedule are reviewed to see how the use of contingency reserves and slacks (floats) mitigated the disruption caused by those
events. The original estimates of contingency time are reviewed to determine if they were adequate and if the estimates of duration
and float were accurate. These activities are necessary for the project team to develop expertise in estimating schedule elements in
future projects—they are not used to place blame. As discussed in Chapter 7, this can be significantly helpful in analogous
estimating of activity durations in future projects. Besides, a review of budget estimates for the cost of work scheduled is compared
to the actual costs. If the estimates are frequently different from the actual costs, the choice of estimating method is reviewed. In a
similar vein, the results of the budget review would be an important input to future projects through analogous estimating (see
Chapter 9). In this analysis, EVM is again an effective tool to compare the earned value to the actual cost.

13.3.4 Risk Response Strategies

After the project is finished, the estimates of risk can be reviewed and compared to the events that actually took place. The risk
register, qualitative and quantitative risk assessment tools, risk response strategies, issue log, and stakeholder register will be of
significant help to the project team to conduct this review. The following questions can help the team assess the risk management
process during the project:
1. Did the risks identified in the planning phase occur?
2. If an identified risk occurred, was the response strategy sufficient to deal with the risk? Was the contingency reserve sufficient?
3. Did events occur that were unforeseen (e.g., unknown unknowns)?
4. What cues and triggers existed that may have allowed the team to predict these events?
5. Was the management reserve sufficient to cover unforeseen risks?
Let’s assume that, in our M-Commerce Project, the second risk with the ID number 2.2 in Table 10.2 “An Example of a Risk
Register” occurred (Table 13.4). Systems Analyst 2 (SA2) monitored the risk effectively, and checked with Developer 1 if they can
work on the five activities under “2. Analysis/App Requirements”. Developer 1 notified SA2 of their absence. Therefore, SA2

13.4.2 [Link]
asked Developer 2 to attend the activities. While the hourly rate of Developer 1 was $35, Developer 2 asked for $45. This caused
an additional cost of $1,840. However, as can be recalled from Chapter 9 and the second question above, contingency reserve can
be allocated in the budget within the cost baseline if the response strategy requires additional funds to deal with the risks. In this
case, let’s consider that the project team included a $2,000 contingency reserve to cover the absence of Developer 1 (Table 13.5).
Thus, this contingency reserve was sufficient, and it didn’t hurt the project. Eventually, this situation is recorded as a lesson
learned.
Table 13.4: Risk 2.2 of M-Commerce Project

ID Related WBS Description Risk Owner Risk Trigger Contingency

Activity Reserve

2.1 The demand for Systems Analyst 2 Ten days before $2,000
2.2 2.2 developers the “Analysis/App
2.3 increased recently Requirements”
since the demand component starts,
2.4 for online games we must assure
2.5 and mobile apps that Developer 1
has been on a starts working on
sharp rise after the project activities.
emergence of the
COVID-19
pandemic. We may
experience a
shortage of
developers in the
market.

Table 13.5: Costs of “Analysis/App Requirements” Stage of M-Commerce Project

WBS Activity Name Duration Cost

2 Analysis/App Requirements 29 days $31,960.00

2.1 Review needs analysis based 3 days $2,760.00

on the business case

2.2 Elicit requirements from 10 days $10,000.00

stakeholders

2.3 Draft preliminary stakeholder 5 days $5,000.00

specifications

2.4 Review specifications with 5 days $8,600.00

team and stakeholders

2.5 Incorporate feedback on the 3 days $2,160.00

specifications

2.6 Develop a preliminary budget 2 days $1,440.00

and delivery timeline

2.7 Obtain approvals to proceed 1 days $0.00

(concept, timeline, budget,
resources)

2.8 Analysis complete (Milestone) 0 days $0.00

13.4.3 [Link]
 Contingency Reserve $2,000

13.3.5 Client and Stakeholder Satisfaction

Relationships with the client are reviewed by the team and the relevant internal stakeholders such as the project sponsor, project
steering committee, and functional departments. In the meetings held with the client, they are given the opportunity to express
satisfaction and identify areas in which project communication and other factors could be improved. Often a senior manager from
the organization interviews the client to develop feedback on the project team’s performance. An internal or external audit also
helps the team and the organization evaluate the relationships with the client and stakeholders, and assess the overall satisfaction of
the client.
A general report that provides an overview of the project is created to provide stakeholders with a summary of the project. The
report includes the original goals and objectives and statements that show how the project met those goals and objectives.
Performance on the schedule and budget are summarized and an assessment of client satisfaction is provided.
This report is also submitted to the senior management as an executive summary containing all the information provided to the
stakeholders. The report identifies practices and processes that could be improved or lessons that were learned that could be useful
for future projects.

This page titled 13.4: Post Implementation Reviews and Archiving Documents is shared under a CC BY-NC 4.0 license and was authored,
remixed, and/or curated by Abdullah Oguz (MSL Academic Endeavors) .

13.4.4 [Link]
13.5: Validating the Realization of Business Benefits
All projects are initiated as a way to create value for the organization. This value may be expressed in many different ways. For
instance, it can be a tangible benefit such as incremental sales associated with launching a new product or service, or an intangible
benefit such as increased employee satisfaction associated with introducing time-saving technology. Further, the project may result
in streamlining business processes, which will ultimately result in less staff required to complete the work. There are many more
possibilities.
Many organizations create a business benefits realization plan, whereas other organizations include the business benefits realization
approach as part of their project management plan. Either way, the following should be considered:
1. What are the benefits? In stating the benefits, the SMART principle should be used (see Chapter 2).
2. How will the business benefits be tracked? This should be a consideration during solution design as it may be necessary to
create the mechanisms for the collection of the required information.
3. Who is accountable for tracking and communicating the business benefits?
4. Who is accountable for taking the appropriate actions to realize the business benefits? For instance, in projects involving
productivity improvements, if the business benefits involve the release of staff, who will be accountable for making this
happen?
5. When are the business benefits expected to be fully realized?

This page titled 13.5: Validating the Realization of Business Benefits is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or
curated by Abdullah Oguz (MSL Academic Endeavors) .

13.5.1 [Link]
13.6: Key Takeaways
Key Takeaways
Projects finish when their unique outcomes (i.e., results, deliverables) are produced, and become available for the client and/or
customers to use. Some projects are completed successfully, but it is not uncommon to see that many projects fail. In both cases,
projects need to be closed, and the activities and procedures must be carried out in the closing phase.
When closing the project, the project manager reviews the project management plan to ensure that all project work is completed
and that the project has met its objectives.
Once the project outcomes are documented, the project manager needs to request formal acceptance from the client (or the
inspection/acceptance committee).
The contract closure process supports the project completion process because it determines if the work described in the
contracts was completed accurately and satisfactorily. One of the purposes of the contract closure process is to provide formal
notice to the seller, usually in written form, that the deliverables are acceptable and satisfactory or have been rejected.
Disbanding the project team and reassigning team members should be finalized in the closeout phase. Besides, project managers
deal with releasing other resources such as physical resources, facilities, materials, and equipment used by the team.
The documents associated with the project must be stored in a safe location where they can be retrieved for future reference.
After the implementation of project activities is finalized and the deliverables are inspected and accepted by the client, the
project team reviews all the documents and meets to discuss what went well and wrong during the project, and what could have
been done to avoid the problems that occurred. This leads to the finalization of a lesson learned register.
Post-implementation reviews include the lesson learned process, reviewing trust and alignment effectiveness, evaluating the
schedule and budget management by utilizing various tools such as EVM, reviewing the risks, strategies, and responses,
discussing client and stakeholder satisfaction, and producing a final report for the client, senior management, and other
stakeholders.
The performance of the project outcomes is monitored according to the benefits realization plan.

This page titled 13.6: Key Takeaways is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz
(MSL Academic Endeavors) .

13.6.1 [Link]
13.7: Questions and Exercises
There are 3 questions for this chapter. As you submit each answer, you will get immediate feedback and be taken to the next
question.

An interactive or media element has been excluded from this version of the text. You can view it online here:
[Link]

This page titled 13.7: Questions and Exercises is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah
Oguz (MSL Academic Endeavors) .

13.7.1 [Link]
13.8: Attribution
This chapter is a derivative of the following texts:
1. Project Management by Adrienne Watt. © CC BY (Attribution).
2. Project Management from Simple to Complex. © CC BY (Attribution).
3. Project Management by Florence Daddey. © CC BY (Attribution).
4. Project Management Fundamentals by Shelly Morris. © CC BY (Attribution).
5. Project Management by Merrie Barron and Andrew R. Barron. © CC BY (Attribution).
6. Principles of Management © CC BY (Attribution).

This page titled 13.8: Attribution is shared under a CC BY-NC 4.0 license and was authored, remixed, and/or curated by Abdullah Oguz (MSL
Academic Endeavors) .

13.8.1 [Link]
Index
Glossary
Sample Word 1 | Sample Definition 1
Detailed Licensing
Overview
Title: Project Management: Navigating the Complexity with a Systematic Approach (Oguz)
Webpages: 143
Applicable Restrictions: Noncommercial
All licenses found:
CC BY-NC 4.0: 93% (133 pages)
Undeclared: 7% (10 pages)

By Page
Project Management: Navigating the Complexity with a 3.3: Project Environment - CC BY-NC 4.0
Systematic Approach (Oguz) - CC BY-NC 4.0 3.4: Organizational Dimensions and the Structure -
Front Matter - Undeclared CC BY-NC 4.0
TitlePage - Undeclared 3.5: Project Management Office (PMO) - CC BY-NC
InfoPage - Undeclared 4.0
Table of Contents - Undeclared 3.6: Key Takeaways - CC BY-NC 4.0
Licensing - Undeclared 3.7: Questions and Exercises - CC BY-NC 4.0
3.8: Attribution - CC BY-NC 4.0
1: Introduction to Project Management - CC BY-NC 4.0
4: Project Planning and the Project Scope - CC BY-NC
1.1: Learning Objectives and Overview - CC BY-NC
4.0
4.0
4.1: Learning Objectives and Overview - CC BY-NC
1.2: Definition and Key Concepts of Project
4.0
Management - CC BY-NC 4.0
4.2: Project Planning - CC BY-NC 4.0
1.3: Project Characteristics - CC BY-NC 4.0
4.3: Eliciting Requirements - CC BY-NC 4.0
1.4: Project Constraints - CC BY-NC 4.0
4.4: Requirements Traceability Matrix - CC BY-NC
1.5: Project Success - CC BY-NC 4.0
4.0
1.6: Project Management Life Cycle and Process
4.5: Project Scope Management - CC BY-NC 4.0
Groups - CC BY-NC 4.0
4.6: Microsoft Project Tutorial - CC BY-NC 4.0
1.7: Project Management Knowledge Areas - CC BY-
4.7: Key Takeaways - CC BY-NC 4.0
NC 4.0
4.8: Questions and Exercises - CC BY-NC 4.0
1.8: Key Takeaways - CC BY-NC 4.0
4.9: Attribution - CC BY-NC 4.0
1.9: Questions and Exercises - CC BY-NC 4.0
1.10: Attribution - CC BY-NC 4.0 5: Stakeholder Management - CC BY-NC 4.0
2: Strategy, Objectives, and Project Selection - CC BY- 5.1: Learning Objectives and Overview - CC BY-NC
NC 4.0 4.0
2.1: Learning Objectives and Overview - CC BY-NC 5.2: Identifying Stakeholders and Managing Their
4.0 Expectations - CC BY-NC 4.0
2.2: Business Strategy and Goals - CC BY-NC 4.0 5.3: Stakeholder Analysis - CC BY-NC 4.0
2.3: SMART Objectives - CC BY-NC 4.0 5.4: Managing and Monitoring Stakeholder
2.4: Business Case - CC BY-NC 4.0 Engagement - CC BY-NC 4.0
2.5: Project Selection Process - CC BY-NC 4.0 5.5: Key Takeaways - CC BY-NC 4.0
2.6: Key Takeaways - CC BY-NC 4.0 5.6: Questions and Exercises - CC BY-NC 4.0
2.7: Questions and Exercises - CC BY-NC 4.0 5.7: Attribution - CC BY-NC 4.0
2.8: Attribution - CC BY-NC 4.0 6: Communication Management, Leadership, and Project
3: Project Initiation - CC BY-NC 4.0 Team Management - CC BY-NC 4.0

3.1: Learning Objectives and Overview - CC BY-NC 6.1: Learning Objective and Overview - CC BY-NC
4.0 4.0
3.2: Project Charter - CC BY-NC 4.0 6.2: Communications Management - CC BY-NC 4.0

1 [Link]
 6.3: Communication Types - CC BY-NC 4.0 9.7: Project Procurement Management - CC BY-NC
6.4: Communications Management Protocol - CC BY- 4.0
NC 4.0 9.8: Microsoft Project Tutorial - CC BY-NC 4.0
6.5: Leadership Skills - CC BY-NC 4.0 9.9: Key Takeaways - CC BY-NC 4.0
6.6: Leadership Styles and Servant Leadership - CC 9.10: Questions and Exercises - CC BY-NC 4.0
BY-NC 4.0 9.11: Attribution - CC BY-NC 4.0
6.7: Creating a Project Culture - CC BY-NC 4.0 10: Project Risks - CC BY-NC 4.0
6.8: Developing and Managing a Project Team - CC 10.1: Learning Objectives and Overview - CC BY-NC
BY-NC 4.0 4.0
6.9: Key Takeaways - CC BY-NC 4.0 10.2: Project Risk - CC BY-NC 4.0
6.10: Questions and Exercises - CC BY-NC 4.0 10.3: Risk Management Plan - CC BY-NC 4.0
6.11: Attribution - CC BY-NC 4.0 10.4: Identifying Risks - CC BY-NC 4.0
7: Scheduling - CC BY-NC 4.0 10.5: Risk Assessment - CC BY-NC 4.0
7.1: Learning Objectives and Overview - CC BY-NC 10.6: Developing and Implementing Risk Responses -
4.0 CC BY-NC 4.0
7.2: Project Schedule Management Plan - CC BY-NC 10.7: Key Takeaways - CC BY-NC 4.0
4.0 10.8: Questions and Exercises - CC BY-NC 4.0
7.3: Defining Activities - CC BY-NC 4.0 10.9: Attribution - CC BY-NC 4.0
7.4: Estimating Activity Durations - CC BY-NC 4.0 11: Monitoring and Controlling - CC BY-NC 4.0
7.5: Creating an Activity Network Diagram - CC BY-
11.1: Learning Objectives and Overview - CC BY-NC
NC 4.0
4.0
7.6: Creating a Gantt Chart - CC BY-NC 4.0
11.2: Monitoring and Controlling Project Work - CC
7.7: Microsoft Project Tutorial - CC BY-NC 4.0
BY-NC 4.0
7.8: Key Takeaways - CC BY-NC 4.0
11.3: Qualitative Monitoring - CC BY-NC 4.0
7.9: Questions and Exercises - CC BY-NC 4.0
11.4: Earned Value Management (EVM) - CC BY-NC
7.10: Attribution - CC BY-NC 4.0
4.0
8: Resource Management - CC BY-NC 4.0 11.5: Change Control Process - CC BY-NC 4.0
8.1: Learning Objectives and Overview - CC BY-NC 11.6: MS Project Tutorial - CC BY-NC 4.0
4.0 11.7: Key Takeaways - CC BY-NC 4.0
8.2: Resource Management - CC BY-NC 4.0 11.8: Questions and Exercises - CC BY-NC 4.0
8.3: Project Resource Management Plan - CC BY-NC 11.9: Attribution - CC BY-NC 4.0
4.0 12: Agile (Adaptive) Project Management - CC BY-NC
8.4: Estimating the Resources - CC BY-NC 4.0 4.0
8.5: Resource Allocation - CC BY-NC 4.0 12.1: Learning Objectives and Overview - CC BY-NC
8.6: Solving Resource Overallocation- Resource 4.0
Leveling - CC BY-NC 4.0 12.2: Introduction to Agile - CC BY-NC 4.0
8.7: Schedule Compression Techniques - CC BY-NC 12.3: Adopting and Creating an Agile Environment -
4.0 CC BY-NC 4.0
8.8: Microsoft Project Tutorial - CC BY-NC 4.0 12.4: Common Agile Framework and Methods - CC
8.9: Key Takeaways - CC BY-NC 4.0 BY-NC 4.0
8.10: Questions and Exercises - CC BY-NC 4.0 12.5: Recent Trends in Agile Project Management -
8.11: Attribution - CC BY-NC 4.0 CC BY-NC 4.0
9: Budget and Procurement - CC BY-NC 4.0 12.6: Key Takeaways - CC BY-NC 4.0
9.1: Learning Objectives and Overview - CC BY-NC 12.7: Questions and Exercises - CC BY-NC 4.0
4.0 12.8: Attribution - CC BY-NC 4.0
9.2: Project Costs - CC BY-NC 4.0 13: Closing the Project - CC BY-NC 4.0
9.3: Project Cost Management Plan - CC BY-NC 4.0
13.1: Learning Objectives and Overview - CC BY-NC
9.4: Estimating Costs and Determining Budget - CC
4.0
BY-NC 4.0
13.2: Closing the Project - CC BY-NC 4.0
9.5: Establishing the Project Budget - CC BY-NC 4.0
13.3: Activities to Close a Project - CC BY-NC 4.0
9.6: Managing Project Costs - CC BY-NC 4.0

2 [Link]
13.4: Post Implementation Reviews and Archiving Back Matter - Undeclared
Documents - CC BY-NC 4.0 Index - Undeclared
13.5: Validating the Realization of Business Benefits Glossary - Undeclared
- CC BY-NC 4.0 Detailed Licensing - Undeclared
13.6: Key Takeaways - CC BY-NC 4.0 Detailed Licensing - Undeclared
13.7: Questions and Exercises - CC BY-NC 4.0
13.8: Attribution - CC BY-NC 4.0

3 [Link]
Detailed Licensing
Overview
Title: Project Management: Navigating the Complexity with a Systematic Approach (Oguz)
Webpages: 143
Applicable Restrictions: Noncommercial
All licenses found:
CC BY-NC 4.0: 93% (133 pages)
Undeclared: 7% (10 pages)

By Page
Project Management: Navigating the Complexity with a 3.3: Project Environment - CC BY-NC 4.0
Systematic Approach (Oguz) - CC BY-NC 4.0 3.4: Organizational Dimensions and the Structure -
Front Matter - Undeclared CC BY-NC 4.0
TitlePage - Undeclared 3.5: Project Management Office (PMO) - CC BY-NC
InfoPage - Undeclared 4.0
Table of Contents - Undeclared 3.6: Key Takeaways - CC BY-NC 4.0
Licensing - Undeclared 3.7: Questions and Exercises - CC BY-NC 4.0
3.8: Attribution - CC BY-NC 4.0
1: Introduction to Project Management - CC BY-NC 4.0
4: Project Planning and the Project Scope - CC BY-NC
1.1: Learning Objectives and Overview - CC BY-NC
4.0
4.0
4.1: Learning Objectives and Overview - CC BY-NC
1.2: Definition and Key Concepts of Project
4.0
Management - CC BY-NC 4.0
4.2: Project Planning - CC BY-NC 4.0
1.3: Project Characteristics - CC BY-NC 4.0
4.3: Eliciting Requirements - CC BY-NC 4.0
1.4: Project Constraints - CC BY-NC 4.0
4.4: Requirements Traceability Matrix - CC BY-NC
1.5: Project Success - CC BY-NC 4.0
4.0
1.6: Project Management Life Cycle and Process
4.5: Project Scope Management - CC BY-NC 4.0
Groups - CC BY-NC 4.0
4.6: Microsoft Project Tutorial - CC BY-NC 4.0
1.7: Project Management Knowledge Areas - CC BY-
4.7: Key Takeaways - CC BY-NC 4.0
NC 4.0
4.8: Questions and Exercises - CC BY-NC 4.0
1.8: Key Takeaways - CC BY-NC 4.0
4.9: Attribution - CC BY-NC 4.0
1.9: Questions and Exercises - CC BY-NC 4.0
1.10: Attribution - CC BY-NC 4.0 5: Stakeholder Management - CC BY-NC 4.0
2: Strategy, Objectives, and Project Selection - CC BY- 5.1: Learning Objectives and Overview - CC BY-NC
NC 4.0 4.0
2.1: Learning Objectives and Overview - CC BY-NC 5.2: Identifying Stakeholders and Managing Their
4.0 Expectations - CC BY-NC 4.0
2.2: Business Strategy and Goals - CC BY-NC 4.0 5.3: Stakeholder Analysis - CC BY-NC 4.0
2.3: SMART Objectives - CC BY-NC 4.0 5.4: Managing and Monitoring Stakeholder
2.4: Business Case - CC BY-NC 4.0 Engagement - CC BY-NC 4.0
2.5: Project Selection Process - CC BY-NC 4.0 5.5: Key Takeaways - CC BY-NC 4.0
2.6: Key Takeaways - CC BY-NC 4.0 5.6: Questions and Exercises - CC BY-NC 4.0
2.7: Questions and Exercises - CC BY-NC 4.0 5.7: Attribution - CC BY-NC 4.0
2.8: Attribution - CC BY-NC 4.0 6: Communication Management, Leadership, and Project
3: Project Initiation - CC BY-NC 4.0 Team Management - CC BY-NC 4.0

3.1: Learning Objectives and Overview - CC BY-NC 6.1: Learning Objective and Overview - CC BY-NC
4.0 4.0
3.2: Project Charter - CC BY-NC 4.0 6.2: Communications Management - CC BY-NC 4.0

1 [Link]
 6.3: Communication Types - CC BY-NC 4.0 9.7: Project Procurement Management - CC BY-NC
6.4: Communications Management Protocol - CC BY- 4.0
NC 4.0 9.8: Microsoft Project Tutorial - CC BY-NC 4.0
6.5: Leadership Skills - CC BY-NC 4.0 9.9: Key Takeaways - CC BY-NC 4.0
6.6: Leadership Styles and Servant Leadership - CC 9.10: Questions and Exercises - CC BY-NC 4.0
BY-NC 4.0 9.11: Attribution - CC BY-NC 4.0
6.7: Creating a Project Culture - CC BY-NC 4.0 10: Project Risks - CC BY-NC 4.0
6.8: Developing and Managing a Project Team - CC 10.1: Learning Objectives and Overview - CC BY-NC
BY-NC 4.0 4.0
6.9: Key Takeaways - CC BY-NC 4.0 10.2: Project Risk - CC BY-NC 4.0
6.10: Questions and Exercises - CC BY-NC 4.0 10.3: Risk Management Plan - CC BY-NC 4.0
6.11: Attribution - CC BY-NC 4.0 10.4: Identifying Risks - CC BY-NC 4.0
7: Scheduling - CC BY-NC 4.0 10.5: Risk Assessment - CC BY-NC 4.0
7.1: Learning Objectives and Overview - CC BY-NC 10.6: Developing and Implementing Risk Responses -
4.0 CC BY-NC 4.0
7.2: Project Schedule Management Plan - CC BY-NC 10.7: Key Takeaways - CC BY-NC 4.0
4.0 10.8: Questions and Exercises - CC BY-NC 4.0
7.3: Defining Activities - CC BY-NC 4.0 10.9: Attribution - CC BY-NC 4.0
7.4: Estimating Activity Durations - CC BY-NC 4.0 11: Monitoring and Controlling - CC BY-NC 4.0
7.5: Creating an Activity Network Diagram - CC BY-
11.1: Learning Objectives and Overview - CC BY-NC
NC 4.0
4.0
7.6: Creating a Gantt Chart - CC BY-NC 4.0
11.2: Monitoring and Controlling Project Work - CC
7.7: Microsoft Project Tutorial - CC BY-NC 4.0
BY-NC 4.0
7.8: Key Takeaways - CC BY-NC 4.0
11.3: Qualitative Monitoring - CC BY-NC 4.0
7.9: Questions and Exercises - CC BY-NC 4.0
11.4: Earned Value Management (EVM) - CC BY-NC
7.10: Attribution - CC BY-NC 4.0
4.0
8: Resource Management - CC BY-NC 4.0 11.5: Change Control Process - CC BY-NC 4.0
8.1: Learning Objectives and Overview - CC BY-NC 11.6: MS Project Tutorial - CC BY-NC 4.0
4.0 11.7: Key Takeaways - CC BY-NC 4.0
8.2: Resource Management - CC BY-NC 4.0 11.8: Questions and Exercises - CC BY-NC 4.0
8.3: Project Resource Management Plan - CC BY-NC 11.9: Attribution - CC BY-NC 4.0
4.0 12: Agile (Adaptive) Project Management - CC BY-NC
8.4: Estimating the Resources - CC BY-NC 4.0 4.0
8.5: Resource Allocation - CC BY-NC 4.0 12.1: Learning Objectives and Overview - CC BY-NC
8.6: Solving Resource Overallocation- Resource 4.0
Leveling - CC BY-NC 4.0 12.2: Introduction to Agile - CC BY-NC 4.0
8.7: Schedule Compression Techniques - CC BY-NC 12.3: Adopting and Creating an Agile Environment -
4.0 CC BY-NC 4.0
8.8: Microsoft Project Tutorial - CC BY-NC 4.0 12.4: Common Agile Framework and Methods - CC
8.9: Key Takeaways - CC BY-NC 4.0 BY-NC 4.0
8.10: Questions and Exercises - CC BY-NC 4.0 12.5: Recent Trends in Agile Project Management -
8.11: Attribution - CC BY-NC 4.0 CC BY-NC 4.0
9: Budget and Procurement - CC BY-NC 4.0 12.6: Key Takeaways - CC BY-NC 4.0
9.1: Learning Objectives and Overview - CC BY-NC 12.7: Questions and Exercises - CC BY-NC 4.0
4.0 12.8: Attribution - CC BY-NC 4.0
9.2: Project Costs - CC BY-NC 4.0 13: Closing the Project - CC BY-NC 4.0
9.3: Project Cost Management Plan - CC BY-NC 4.0
13.1: Learning Objectives and Overview - CC BY-NC
9.4: Estimating Costs and Determining Budget - CC
4.0
BY-NC 4.0
13.2: Closing the Project - CC BY-NC 4.0
9.5: Establishing the Project Budget - CC BY-NC 4.0
13.3: Activities to Close a Project - CC BY-NC 4.0
9.6: Managing Project Costs - CC BY-NC 4.0

2 [Link]
13.4: Post Implementation Reviews and Archiving Back Matter - Undeclared
Documents - CC BY-NC 4.0 Index - Undeclared
13.5: Validating the Realization of Business Benefits Glossary - Undeclared
- CC BY-NC 4.0 Detailed Licensing - Undeclared
13.6: Key Takeaways - CC BY-NC 4.0 Detailed Licensing - Undeclared
13.7: Questions and Exercises - CC BY-NC 4.0
13.8: Attribution - CC BY-NC 4.0

3 [Link]