Project Management Fundamentals

Project Management Fundamentals

SHELLY MORRIS

SENECA COLLEGE
TORONTO
Project Management Fundamentals by Shelly Morris is licensed under a Creative Commons Attribution-NonCommercial 4.0
International License, except where otherwise noted.
Contents

Acknowledgements 1

Overview and Preface 2

1. Introduction 5
2. Project Selection 24
3. Project Structures and Organizational Culture 31
4. Project Initiation 40
5. Project Planning 52
6. Project Execution 112
7. Monitoring and Controlling 136
8. Project Closure 151
9. Appendix 154
Acknowledgements
This book is an adaptation of Project Management from Simple to Complex originally published by the
University of Minnesota Libraries Publishing, as well as Project Management by Adrienne Watt, published
by BCcampus Open Education.

Project Management Fundamentals: Adapted for Seneca College for use in introductory project management
courses is licensed under a Creative Commons Attribution-Non-Commercial 4.0 Share-alike International
license, except where otherwise noted.

This adaptation was sponsored by Seneca’s Open Text Adaptation Grant Program. Resources and support were
also provided by the Teaching & Learning Centre at Seneca.

The author would like to acknowledge the contributions of several important individuals, whose efforts made
this text possible.

Karla Murtescu, whose editorial and graphic design skills were invaluable, surpassed all expectations,
and immersed herself in the text’s content.

Isaac Sethian, dearly remembered by many of his Seneca colleagues, for helping to shape the initial
vision of this text.

Cawder Andrews is the author of Section 1.4, Digitization of Project Management and his enthusiasm for
this text is much appreciated.

Acknowledgements | 1
Overview and Preface
Overview

Project management is not just for project managers anymore. Organizations of all shapes and sizes continue
to transform the ways they innovate and deliver on their promise to continuously improve customer satisfaction
levels. When an organization introduces change, it is crucial for it to be done correctly the first time. However,
disruption is the new normal. Succeeding in such turbulent times means organizations cannot afford to waste
precious resources on failed projects. This has led to a recognition that the tools, techniques and processes
associated with project management can help organizations be successful. Within this context, this text refers
to the leader of a project as a “project leader.” This is a generic term to recognize that the title given to the
individual that is responsible for project success is often not “project manager”.
Project management is an ancient practice. People have been undertaking projects since the earliest days
of organized human activity. The hunting parties of our prehistoric ancestors were projects. Large complex
developments, such as the Giza Pyramid Complex and the Great Wall of China, were also projects. Planning a
vacation, getting married, and achieving a degree, diploma or certificate are all projects as well. All of us are
engaged in projects on a regular basis in our daily lives.
Projects are unique. Although all of us are engaged in projects, each project requires a unique approach
based on the objectives to be achieved, the complexity of the work required, the nature and number of
stakeholders involved, and the clarity of the solutions being pursued. Those skilled in the art and science of
project management have the capacity to tailor the use of tools, techniques, and processes in order to maximize
the value delivered to and by the organization.
In our rapidly changing world, organizations need an agile mindset in order to thrive. Similarly, project
management professionals need an agile mindset to deliver value to an organization. Agility is one of the
most commonly used terms of the 21st century. It has a different meaning to different people. In this text, an
important distinction will be made between organizational agility and agile as a development methodology.
American software engineer Jim Highsmith, who is one of the 17 original signatories of the Agile Manifesto,
defined organizational agility as “the ability to adapt and respond to change.” Highsmith also noted that
agile organizations “view change as an opportunity, not a threat.” In development methodology, “agile” is
used to refer to an overarching term for a family of delivery frameworks and practices that promote adaptive,
incremental development.

All organizations must be agile. The pursuit of organizational agility requires people to shift the way they think
about measuring success. Success measurement shifts from a focus on results in terms of effort and output to a
focus on outcomes and value delivered. Successful project leaders have embraced this mindset shift and no longer
require solutions to be well-defined up front.

However, this does not mean that all organizations must use an agile delivery framework when introducing
change. Agile has become much more than a delivery framework. It is now an imperative leadership
philosophy, mindset, and approach. This text will introduce students to the predictive (also known as waterfall)
approach and the adaptive delivery approach since both frameworks are used in organizations pursuing agility.

2 | Overview and Preface

Preface

The primary purpose of this text is to provide professors and students with an open-source textbook that can
be used in introductory project management courses. The objective is to develop a concise, widely applicable
open-source textbook that can be used in the for-profit and non-profit sectors. For this reason, the term
“organization” is used instead of “business” and “corporation.” In addition, the author has intentionally left out
examples from fields of practice, such as business, engineering, and information technology, in order to ensure
this text has universal applicability. The intention is to provide an overview of the fundamentals that will allow
students and instructors to work with their own program-specific case studies, exercises, and assessments to
fulfil the appropriate learning objectives.
The material in the text was obtained from a variety of sources. Sources are found in the reference section at
the end of each chapter as well as in the Acknowledgement section.

I welcome your feedback and would love to know how you are using the materials. I remain committed to
continuous improvement and welcome all feedback.
Please send your feedback to Professor Shelly Morris, Faculty of Business at Seneca College:
[email protected].

Overview and Preface | 3

1. Introduction
1.1 Overview of Management

Management is about achieving results through people. This involves the processes of planning, organizing,
and directing the activities of employees, in combination with other resources, to accomplish organizational
goals. Understanding the fundamentals of managing and leading people is an important place to begin the
study of project management.
Depending on the nature of the organization and the industry in which it operates, managerial
responsibilities can vary widely. However, general managerial responsibilities typically include long-range
planning, environmental scanning, supervision, coordination, customer relations, community relations, internal
consulting, and monitoring of products and services. As seen in Exhibit 1.1, these responsibilities are best viewed
by considering the three major types of roles managers play within organizations:
1) informational, 2) interpersonal, and 3) decisional roles.

1. Introduction | 5
 Exhibit 1.1: The roles managers play (accessible version)
Rice University, OpenStax

The extent of each of these roles depends on the manager’s position within the organizational hierarchy. As
shown in Exhibit 1.2, different skills (conceptual, human, and technical) are required for different levels of the
managerial hierarchy. Success in executive positions requires far more conceptual skills and less use of technical
skills in most (but not all) situations. In contrast, first-line managers generally require more technical skills
and fewer conceptual skills. Lastly, middle managers may require to be well-rounded in all three skills. Note,
however, that human relations skills, or “people skills,” remain important for success at all three levels in the
hierarchy.

Exhibit 1.2: Difference in skills required for successful

management according to level in the hierarchy
Rice University, OpenStax

In addition, the extent of the roles also varies by department and function. Significant differences can be
found in accounting, human resources, manufacturing, and sales, just to name a few. A key differentiator is the
emphasis of each role. For instance, managers in the accounting function spend little time, if any, resolving
customer service issues. However, managers in the sales, marketing, and service functions spend a considerable
amount of their time ensuring those issues are effectively and efficiently resolved.
A lot has changed in the field of management. 21st-century managers differ from their predecessors in four
key ways. They have become global strategists, masters of technology, good internal/external advocates, and
premier leaders-motivators.
The focus in this text is on the role of the project, program, and/or portfolio manager. The unique emphasis
of these roles naturally leads to a discussion of what a project, program, and/or portfolio are and why a focused
emphasis on leading change is required. In addition, we will look at the unique technical and soft skills that
successful project management professionals must possess.

6 | 1. Introduction
1.2 What is a Project?

A project is a temporary endeavour undertaken to create a unique product, service, or result.1

Organizations often choose to manage a related group of projects in a coordinated way to obtain benefits
and control unachievable by managing projects individually. When this occurs, it is known as program
management.1
As an organization grows and matures, change becomes necessary to its sustained viability. Understanding
the drivers of a change is the first step in understanding how the project should be managed. Some changes
are mandatory. This is often the case with changing legislation and regulations. Mandatory changes often have
compliance deadlines and penalties for non-compliance. Operational changes seek to address deficiencies in
the day-to-day operations of an organization and can involve repairing or replacing equipment and facilities.
Lastly, strategic changes are optional but once pursued, help take the organization to the next level of
performance in the marketplace.
Regardless of the underlying driver(s) for a project, all projects have unique objectives. These unique
objectives lead to specific and measurable time, as well as cost and performance requirements. Projects end
when their objectives have been met, as well as when they are no longer desirable and/or achievable. In
contrast, operational work is not temporary. Operational activities are ongoing and are performed to sustain the
organization. The daily processing of sales transactions is a good example of an operational activity. In contrast,
replacing the system that processes daily sales transactions is a project.

1.3 How is Project Management a Unique Discipline?

Disruption is the new normal. At the time of writing this open educational resource, humans were experiencing
life in the midst of a pandemic. The impact of the pandemic has been profound and prolonged. The pandemic
began against a backdrop of extraordinary change driven by new technologies, a push for governments and
organizations to demonstrate a deeper commitment to social accountability, and rapidly evolving customer
expectations. So much is at stake and unfortunately, many organizations have not survived the economic
conditions brought about by these forces of change.
Government, non-profit, and business leaders alike know that continued success depends on an agile
mindset. Organizations need highly adaptive people to deliver on bold ideas with equally bold and big projects.
Before we examine why project management is a unique discipline, it is time for an introduction to the two
major organizations with worldwide impact on the practice of project management: Project Management
Institute (PMI), with world headquarters in the United States, and the International Project Management
Association (IPMA), with world headquarters in Switzerland. This text follows the approach taken by PMI and will
remain aligned with PMI as their best practices evolve.

1. Introduction | 7
 Exhibit 1.3: PMI is a global organization consisting of over 300 local chapters
Map template: Nicolas Raymond, Flickr

PMI is a non-profit project management professional association. It is the most widely recognized association
for those who consider a project, program, or portfolio management as their profession. Founded in 1969, PMI
works in nearly every country around the world to advance careers, improve organizational success,and further
the project management profession through globally recognized standards, certifications, communities,
resources, tools, academic research, publications, professional development courses,and networking
opportunities. With a membership of more than three million people, it has proven its ability to help
organizations deliver successful change initiatives.
PMI defines project management as the application of knowledge, skills, tools, and techniques to project
activities to meet project requirements.1 Project leaders are evaluated on how effectively they apply their project
management knowledge, skills, tools, and techniques to a change in a functional area(s) and how effectively
they prepare the functional area(s) to sustain the change. They ask themselves questions such as, “Will this
change add value to the organization?” As a team, they may ask, “Will we deliver solutions when they are
needed, within the funding parameters available in the organization, and will we meet the expectations of
the end–user community?” They also frequently ask, “Are the stakeholders, including the impacted functional
leaders, still supportive of the changes to be delivered?” Answers to these questions guide the project team’s
work.
To help keep project management terms and concepts clear and consistent, PMI introduced the book “A
Guide to the Project Management Body of Knowledge” (PMBOK Guide) in 1987. It was updated in 1996, 2000,
2004, 2009, 2013, and most recently in 2017 as the sixth edition. A seventh edition is on the way in 2021.
PMI’s 2020 Pulse of the Profession2 revealed that in organizations with mature project delivery practices, an
average of 11 percent of the investments made in change was wasted due to poor project performance. Further,
organizations that undervalue project management as a strategic competency for driving change report an
average of 67 percent more of their projects failing outright.2 On a global scale, this translates into billions
of dollars wasted. In these turbulent times, failures of this magnitude can lead to disastrous outcomes for
organizations already struggling to survive. For those that do survive their failed change attempts, many find
themselves forced to reimagine what they do and how they do it.
This new decade has introduced us to the “Project Economy.”2 Organizations are constantly searching for

8 | 1. Introduction
ways to adapt and thrive. This means high-stakes projects are frequently launched with a variety of titles,
executed through a variety of approaches, and are focused on delivering financial and societal value.

A YouTube element has been excluded from this version of the text. You can view it online here:
https://pressbooks.senecacollege.ca/projectmanagementfundamentals/?p=5

In the Project Economy, change is introduced rapidly, and some organizations call upon their functional
managers to deliver low complexity change into their environments. These functional managers are often
successful in leading these change initiatives when they have the needed skills and capacity to apply the
appropriate project management tools and techniques while overseeing the daily operational activities of their
teams. In addition, simple changes with a well-defined solution and a low level of complexity can be successfully
introduced using predictive (also known as waterfall)development approaches.

However, if a functional manager lacks the skills required to manage a project or finds themselves frequently
putting out fires started by product/service performance issues, unreliable suppliers, aggressive
competitors, and/or ongoing human resource issues, a project management professional is often asked to lead
the change. Furthermore, when the change requires cross-functional teams to understand the needs of the
end customer and deeply explore these needs before building a solution, project management professionals
are better suited for these types of change initiatives.
In the Project Economy, a growing number of executives are embracing professional project
management. According to PMI’s 2020 Pulse of the Profession, these 21st-century leaders know that
technologies like artificial intelligence (AI) and machine learning can be “the difference between a
breakthrough year and just an okay one.” However, these leaders also know that these technologies are only
as smart as the people behind them. Successful project leaders of the 21st century truly understand that their

1. Introduction | 9
people skills are just as valuable as their technical skills. PMI’s research on the skills most valued by employers
has led to the creation of the Talent Triangle.

Exhibit 1.4: PMI’s Talent Triangle. The three points of the triangle (which represents the ideal triad of skills) are
technical project management, strategic and business management, and leadership.
PMI

Additional reading:

2020 Pulse of the Profession

Talent Triangle
Thought Leadership

Technical project management skills:

Technical project management skills are about successfully tailoring the tools, techniques and processes used.
This domain also includes the ability to thoroughly plan, prioritize and effectively manage the scope, schedule,
budget, resources and risks associated with a project.
This text explores the technical management skills that are required for project management. The required
knowledge varies by process group, and this will be highlighted as we explore how projects are initiated,
planned, executed, monitored, and ultimately closed.

Strategic and business management skills:

Strategic and business management skills are about communicating a project’s organizational aspects,
develop delivery strategies and maximize business value.

Some projects require specific organizational and/or industry knowledge. This knowledge can be defined by
industry group (pharmaceutical, financial, etc.), department (accounting, marketing, legal, etc.), technology
(software development, engineering, etc.), or management specialty (procurement, research and development,

10 | 1. Introduction
etc.). These application areas are usually concerned with disciplines, regulations, and the specific needs of the
project, the customer, or the industry.
It is important for project leaders to embrace a life-long learning mindset as internal and external
environments often change very quickly. During the first phase of a project’s life cycle, known as the “initiation
phase,” project leaders assess the strategic and business management knowledge they have and its value to
the new project underway. If necessary, effective project leaders seek to close their knowledge gaps through
their own research and by seeking the support of mentors.
Lastly, it is important for project leaders to understand the organization’s vision, mission, and strategies. The
importance of this will be discussed in Section 2.1.

Leadership skills:

Leadership is about using one’s interpersonal skills in order to guide, motivate and direct a team.

In the sixth edition of the PMBOK Guide, PMI identified a very comprehensive list of the skills and attributes
needed by project leaders. All the skills and attributes are important. For purposes of this text, the following key
skills and attributes will be highlighted:

1. Introduction | 11
 Exhibit 1.5: The key skills good project leaders possess (accessible version)
This is by no means a complete list of all the skills and attributes required to be a successful
project leader. Moreover, the nature and complexity of a project can help identify which of these skills will be
more instrumental to project success than others. PMI is committed to helping project management
professionals develop their skills in all the key areas. One of the ways this is done is by encouraging certification.

12 | 1. Introduction
There are many certification opportunities, including the PMP (Project Management Professional) and the
CAPM (Certified Associate in Project Management). Once certified, project management professionals have
access to a wealth of ongoing professional development resources aligned to all areas of the Talent Triangle.

Additional reading:

PMI certifications

Successful project leaders know how to uniquely apply the knowledge and skills they have learned to each
project by tailoring the tools and techniques they use. The complexity of a project has a big impact on the tools
and techniques required throughout the project lifecycle. PMI has identified five phases in the project lifecycle
and offers the following definitions of each phase:

Exhibit 1.6: Project phases (accessible version)

In addition, project management tools and techniques have been developed from the 10 different
knowledge. These knowledge areas reflect the cross-functional skills and teams required to deliver
transformational change in an organization. These knowledge areas are applicable to solutions developed using

1. Introduction | 13
a predictive (waterfall) delivery framework and an adaptive delivery framework. Depending on the delivery
framework used, the knowledge and skills applied may be for the entire project or for a particular release/phase.
The sixth edition of the PMBOK offers the following definitions for each of these knowledge areas:

1. Integration management

“The processes and activities to identify, define, combine, unify and coordinate the various processes and
activities with the process groups.”
Projects involve all types of different synchronous and asynchronous tasks.
Project leaders rely on their soft skills to facilitate activities and keep all the project teams moving forward
together.

2. Scope management

“The processes required to ensure the project includes all the work required, and only the work required, to
complete the project successfully.”

3. Schedule management

“The processes required to manage the timely completion of the project.”

Projects have a definite beginning and end.
Managing the time dimension of a project is about defining the activities, sequencing them, identifying
resource needs, estimating activity durations, and maintaining the schedule as changes occur.

4. Cost management

“The processes involved in planning, estimating, budgeting, financing, funding, managing, and controlling
costs so the project can be completed within the approved budget.”

Projects consume resources.

It is important to understand the financial benefits of the project and compare them to the costs incurred.
If the costs (representing the organization’s investment in transformation) are greater than the benefits, the
project may not be financially justified.

5. Quality management

“The processes for incorporating the organization’s quality policy regarding planning, managing, and
controlling project and product quality requirements in order to meet stakeholders’ expectations.”

6. Resource management

“The processes to identify, acquire and manage the resources needed for the successful completion of the
project.”

Resources include the people, supplies, and materials required to produce the outcomes.

14 | 1. Introduction
7. Communications management

“The processes involved to ensure timely and appropriate planning, collection, creation, distribution,
storage, retrieval, management, control, monitoring and ultimate disposition of project information.”
Projects typically impact a lot of people.
Ensuring everyone is aware of what is happening and their continued role in achieving project success is
often one of the most difficult, and time-consuming, aspects of project management.

8. Risk management

“The processes of conducting risk management planning, identification, analysis, response planning,
response implementation and monitoring risk on a project.”
Projects are a discovery-driven process; uncovering new customer needs and identifying critical issues
not previously disclosed often occur during a project’s lifetime.
This creates a lot of uncertainty and uncertainty creates risk; when unexpected events occur, risk
becomes an issue.
Successful project teams are able to proactively identify what can go wrong on a project and put
appropriate response plans in place to deal with these risks.

9. Procurement management

“The processes necessary to purchase or acquire products, services, or results needed from outside the
project team.”
When outside vendors are engaged in a project, there is a need to determine how these vendors are
selected and effectively managed throughout the project’s duration.
This work also includes contract development and administration.

10. Stakeholder management

“The processes required to identify the people, groups, or organizations that could impact or be impacted
by the project, to analyze stakeholder expectations and their impact on the project, and to develop
appropriate management strategies for effectively engaging stakeholders in project decisions and
execution.”
Along with communication, stakeholder management is a critical success factor in project management.
If stakeholders are not satisfied with the outcomes of a project, the project will not be successful.

Lastly, project leaders who are able to effectively understand the environment in which they are operating can
not only refine their approach to tailoring the tools and techniques required, they can also significantly increase
the likelihood of successfully delivering change.
There are many factors that need to be understood within a project environment.

1. Introduction | 15
 Exhibit 1.7: The important factors to consider within the project environment (cultural, social, international,
political, and physical)
The cultural and social environments consider people, demographics, and education. The international and
political environment is about understanding the cultural differences of unique countries and the impact that
local and national governments have on organizations. The physical environment is about working conditions
and locations. Delivering a project that has global impacts is much more challenging than delivering a project
that only impacts the local environment.
Of all the factors, the physical ones are the easiest to understand, and it is the cultural and global factors
that are often misunderstood or ignored. How we deal with clients, customers, or project members from
other countries can be critical to the success of the project. For example, North American cultures value
accomplishments and individualism, and tend to be more informal, calling each other by first names, even if
having just met. Europeans tend to be more formal, using surnames instead of first names in a business setting,
even if they know each other well. In addition, their communication style is more formal than in the North
American setting, and while they tend to value individualism, they also value history, hierarchy, and loyalty.
How a product is received can be very dependent on international cultural differences. For example, in
the 1990s, when many large American and European telecommunications companies were cultivating new
markets in Asia, their customers’ cultural differences often produced unexpected situations. Western
companies planned their telephone systems to work the same way in Asia, as they did in Europe and the United
States. But the protocol of conversation was different. Call-waiting, a popular feature in the West, is considered
impolite in some parts of Asia. This cultural blunder could have been avoided had the team captured the project
environment requirements and involved the customer.
Project leaders in multicultural projects must appreciate the cultural dimensions and try to learn relevant
customs, courtesies, and business protocols before taking responsibility for managing an international project.

16 | 1. Introduction
A project leader must take into consideration these various cultural influences and how they may affect the
project’s completion, schedule, scope, and cost.
PMI also identifies another key consideration in understanding project environments – organizational process
assets (OPAs). OPAs include operational and project management processes, policies, procedures, success
metrics, and knowledge repositories. The degree to which they are utilized in a project, as well as the
expectations surrounding their use, have a big impact on how projects are delivered.

1.4 Digitization of Project Management

The Digital Age

We live in an era characterized by accelerating exponential change driven by a cluster of technologies, such as
the internet, social media, mobile, big data/analytics, artificial intelligence, automation, and robotics. Beginning
with the introduction of the very first personal computer in the seventies, today, with an Internet connection,
one can use video and audio to communicate and transact anytime, anywhere, and anyplace. We live in a
digital realm in what is loosely described as “cyberspace,” in which information is exchanged and shared in a
space that is virtual. Though these digital technologies have been developing for many years, it is only in the
past decade or so that their cumulative impacts have become so deep-rooted, extensive, fast-changing, and
profoundly impactful as to herald the dawn of a new age – the “Digital Age” or the Digital Economy. The cluster
of technologies driving this is varyingly referred to as digital technologies or digital forces.
The role of digital technologies will continue to expand. This will occur because more devices are accessing
the Internet; an ever-increasing number of people are using digital services and more value chains are being
digitally connected. Therefore, access to digital technologies is a source of major competitive advantage for
organizations, particularly when paired with the ability to use them to transform the way value is delivered
to the market. In the education sector for instance, despite the challenges due to COVID-19, virtual learning
environments have made it possible for academic institutions to continue seamlessly with their academic
programmes.

1. Introduction | 17
 A YouTube element has been excluded from this version of the text. You can view it online here:
https://pressbooks.senecacollege.ca/projectmanagementfundamentals/?p=5

The Organizational Response – Digitization, Digitalization, and Digital Transformation

The onset of the Digital Age and the availability of new technologies have been the enabling factor in
organizational change and innovation. Organizations have been putting in place strategies and launching
projects to become agile, profitable, and smart in order to cope with an increasingly competitive environment
and the unpredictability of markets.
Given this, companies have been in a rush to become digital and they are going about it in different ways.
Some of them are implementing digital technologies to engage in new ways with customers and others are
completely transforming their way of doing business or creating an entirely new business model. To understand
this, let us consider a simple process like performance reporting. Such reporting systems have moved from
paper to spreadsheets to smart applications with digital technologies such as artificial intelligence (AI) and data
analytics.
However, to reach the maturity of “smart reporting,” one would have to reimagine the way reporting is done in
terms of the reporting formats, the periodicity, the flexibility in the use of variables, the application on which the
reports are developed, and finally, the way the reports are presented. Such a move in reporting systems would
also mean new ways in which we engage our customers who would be receiving, in real-time, such reports all
laden with infographics.
To elaborate this further, historically, businesses kept handwritten or typed paper-based records. During this
time, business data was in a stage which is referred to as analog, and if you wanted to move or share this data
or information it was done through the physical movement of papers and documents.
When computers went mainstream, most businesses started converting all those paper records to digital

18 | 1. Introduction
computer files. This stage was called digitization, which is the process of converting information from analog
to digital. Through the process of digitization, finding and sharing information became much easier, but the
ways in which businesses used their new digital records largely imitated the old analog methods. Computer
operating systems and thumbnails were even designed around icons of file folders to feel familiar and less
intimidating to new users. Digital data was exponentially more efficient for businesses than analog had been,
but business systems and processes were still largely using analog-era ideas about how to find, share, and use
information.
Then organizations began the process of digitalization, which is the use of digital data to simplify the way
work is done. A good example would be how call centres would use digitized data and information to provide
customer service. Digitalization would enable call centres to provide better service by making customer records
easily and quickly retrievable via multiple devices. The basic methodology of customer service did not change,
but the process of fielding an inquiry, looking up the relevant data, and offering a resolution became much
more efficient. In summary, digitalization is about the way business operations employ transformative digital
technologies and information.
With digital technologies continuing to evolve and newer technologies becoming available, strategists have
started generating ideas for using these digital technologies to improve existing ways of doing business, but
more importantly, new ways of doing business. That is when the concept of digital transformation began to take
shape. Organizations were now able to change their fundamental business models. Uber, for example, heavily
incorporated digital transformation to change the way we rideshare.
Digital transformation is about changing the way business gets done and, in some cases, creating entirely
new classes of businesses. With digital transformation, organizations are taking a step back and revisiting
everything they do, from internal systems to online and in-person customer interactions. The questions being
asked are, “Can we change our processes in a way that will enable better decision-making, increase efficiencies,
enhance customer experience, empower personalization, and, most importantly, boost profits?”

Therefore, the organizational response to the capabilities provided by the Digital Age is to embark on a strategy
of digital transformation of their businesses. Most organizations are integrating their digital strategy with their
overall strategy to disrupt the marketplace.

Digital Transformation in the Educational Sector

Digital transformation has impacted every industry. The education industry is also realizing the benefits of
technology through digital transformation and the rise of educational technology. The way instruction is
delivered, the assessments, the physical make-up of the classrooms – all of these and more have undergone a
transformation.
Educational technology is succeeding in making virtual learning collaborative and interactive. Augmented,
virtual, and mixed reality are examples of transformative technology that enhance teacher instruction while
simultaneously creating immersive lessons that are exciting and engaging for the student. Virtual reality has
the capability of bringing the outside world into the classroom and the other way around. Chromebook sales
now account for more than half of all devices sold for U.S. classrooms. The onboarding of technology has
enabled the use of SMARTboards instead of chalkboards and pods of SMARTdesks instead of individual seating.
The use of AI in higher education has already proven useful. In one university, IBM Watson was used to create a
virtual student advisory service that was available 24-hours a day, seven days a week. Watson’s virtual advisors
fielded more than 30,000 questions in the first trimester, freeing up the actual advisors to handle more
advanced issues.
Another use for AI includes chatbots which have been deployed to clear queries around assignments, help
students through a paperwork process, such as financial aid or paying bills, and ease the workload of the

1. Introduction | 19
people who would normally serve these roles. Other applications of AI in education include personalizing
learning, evaluating the quality of curriculum and content, and facilitating one-on-one tutoring with the use of
Intelligent Tutoring Systems. Gaming technology is another area that makes learning difficult subject matter
more exciting and interactive.3

Impact on Project Management

With a major percentage of organizations embarking on a strategy of digital transformation and disruption
being the new norm, project leaders are becoming even more essential as organizations recognize that strategy
is implemented through projects and programs.
So how exactly are the Digital Age and digital transformation changing project management? The impact is
seen broadly at three levels in terms of skills, approaches to the delivery of projects, and the use of next-level
tools and approaches that work. This creates both challenges and opportunities for project management and
those who manage projects.
According to a recent PMI survey and subsequent study called, “The Project Manager of the Future –
Developing Digital-Age Project Management Skills to Thrive in Disruptive Times,” project management will
require organizations and individuals alike to embrace a full spectrum of competencies and approaches, along
with a wide range of titles and methodologies.
From a skills and competencies perspective, project leaders will continue to need a thorough combination
of technical and project management skills, leadership skills, and strategic and business management skills,
which are already part of the PMI Talent Triangle introduced earlier in this chapter. In addition to this important
triad of skills, organizations will need project leaders to learn and keep pace with existing and emerging
technology. In the reality of the “Digital Age,” a new digital overlay has been given to the PMI Talent Triangle to
emphasize how digital transformation is impacting every aspect of our work.
Success in today’s digital environment requires a combination of skills, some of which include data science
(data management, analytics, big data), an innovative mindset, security and privacy knowledge, legal and
regulatory compliance knowledge, the ability to make data-driven decisions, and collaborative leadership. The
crux of it is that technical skills are not enough on their own and must be paired with leadership, as well as
strategic and business management, in order to support the longer-term strategic objectives of organizations.
With regard to project delivery, organizations have been using a spectrum of approaches— predictive,
iterative, incremental, agile, hybrid, and whatever approach will come next to change how work is carried out.
Most organizations have embraced the entire value delivery landscape to deliver their projects and programs.
Project leaders in organizations see disciplined agile delivery and design thinking as the growing approaches
or processes that will be needed.

20 | 1. Introduction
 Exhibit 1.8: Approaches currently used or being considered by project leaders to manage disruptive
technologies
PMI

The cluster of technologies available in the Digital Age is cutting-edge and disruptive. Organizations must be
able to not only understand these technologies, but also to integrate these technologies and tools into their
organization. Regarding projects being carried out, leaders and team members must embrace the next-level
tools and technologies, applying and integrating them into their project work.

These tools and technologies are a combination of collaborative work management tools, as well as traditional
tools, including spreadsheets and traditional project management tools (e.g., Microsoft Project and Portfolio
Management, Accolade, etc.), collaboration platforms (e.g., IBM Watson Workplace, Slack, etc.), agile planning
tools (e.g., Atlassian, CollabNet, VersionOne, etc.), and collaborative work management tools (e.g., Smartsheet,
Trello, etc.).4

Exhibit 1.10: Tools project leaders use to deliver disruptive technology initiatives
PMI

1. Introduction | 21
 In addition to these tools and technologies, project leaders are also relying heavily on technologies that
enable effective cross-team communication. Traditional tools, such as email, are cumbersome when it comes
to collaboration, as they are not designed for real-time dialogue. Important information is easily buried within
endless email chains, and constant email overload negatively affects productivity. On the other hand,
collaborative work management software allows team members and co-workers across departments to
engage, connect, and interact in real-time, significantly cutting down on email clutter and saving loads of time
in the process. But more than just increasing the efficiency of intra-work communication, these technologies
are improving its effectiveness as well. When team members are freed from filtering through hundreds of
emails a day just to keep up with a project’s status, they are able to spend more time talking about project
strategy — which is precisely where the bulk of your team’s conversation needs to be focused.

Along with facilitating more efficient, strategy-focused communication, modern work management
technologies are making it easier for teams to truly collaborate. With the right platform in place, executives,
project leaders, and team members can add comments, assign tasks, organize dashboards, approve assets,
and handle just about everything else related to the project all in one convenient solution. This deep level
of collaboration inevitably leads to a greater sense of shared ownership from teammates and helps foster a
cooperative, synergistic environment. Workers who feel they are part of a collaborative effort have been shown
to have greater engagement, lower fatigue, and higher success rates than those who are isolated from peers.

As digital transformation automates workflows and coordinates traditional project management tasks like
scheduling, Project leaders are getting more time to focus on strategy optimization and project delivery. In
fact, the PMI predicts that as digital transformation continues to touch companies across every industry and
vertical, Project Leaders will be viewed more as strategic leaders in their organizations: With more digital tools
and automated processes at their disposal, Project leaders are homing in on the best ways to align each project
with the business’ strategies and goals — and delivering more successful outcomes in the process.
Digital transformation is providing project leaders with the analytical technology to make data-driven
decisions, break down patterns and trends, and ultimately enhance project outcomes and success rates. This
access to deep data also assists executives and managers in making better-informed decisions faster and easier
than ever before. Robust analytic reports help managers keep projects on track and on budget with real-time
cost and labour analyses. In-depth data sets can also be easily broken down for stakeholders and executives,
giving them precise insight into business impact and return on investment (ROI) on every project and helping
them strategically plan future initiatives.
As technology continues to advance at exponential rates, organizations must adapt to the digital landscape or
risk getting left behind. Companies that have implemented a digital transformation strategy have been shown
to increase performance and revenues. A project leader who is mandated to deliver projects for organizations
carrying out digital transformation would need to focus on streamlining communication, improving
collaboration, and shifting focus from project processes status to strategy and outcomes.5

Future Scenario – Industry 4.0

In a sense, the Digital Age is spilling over and building up into the early stages of what is termed as the “Fourth
Industrial Revolution” or “Industry 4.0.” We are on the cusp of another technological revolution – one that
will fundamentally alter the way we live, work, and relate to one another. In its scale, scope, and complexity,
the transformation will be unlike anything humankind has experienced before and we do not yet know just
how it will unfold. The First Industrial Revolution used water and steam power to mechanize production. The
Second used electric power to create mass production. The Third used electronics, information technology,
and digitalization to automate production. Now, a Fourth Industrial Revolution is building on the Third and is

22 | 1. Introduction
characterized by a fusion of technologies that are blurring the lines between the physical, digital, and biological
spheres.
There are three reasons why today’s transformations represent not merely a prolongation of the Third
Industrial Revolution, but rather the arrival of a Fourth and distinct one: velocity, scope, and systems impact.
The speed of current breakthroughs has no historical precedent. When compared with previous industrial
revolutions, the Fourth is evolving at an exponential rather than a linear pace. Moreover, it is disrupting
almost every industry in every country. The possibilities of billions of people connected by mobile devices,
with unprecedented processing power, storage capacity, and access to knowledge, are unlimited. And these
possibilities will be multiplied by emerging technology breakthroughs in fields such as artificial intelligence,
robotics, the Internet of Things, autonomous vehicles, 3-D printing, nanotechnology, biotechnology, materials
science, energy storage, and quantum computing.

References

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. (2020). Ahead of the curve: Forging a future-focused culture. www.pmi.org/
learning/thought-leadership/pulse/pulse-of-the-profession-2020

3
Newman, D. (2017, July 18). Top 6 digital transformation trends in education. Forbes. www.forbes.com/sites/
danielnewman/2017/07/18/top-6-digital-transformation-trends-in-education/
4
Project Management Institute. (2018). Developing digital-age project management skills: The project
manager of the future. www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/
digital-pm-skills.pdf?sc_lang_temp=en
5
McAbee, J. (2019, October 9). 4 ways digital transformation is changing project management. Wrike.
www.wrike.com/blog/digital-transformation-changing-project-management

1. Introduction | 23
2. Project Selection
2.1 Why Project Leaders Need to Understand Business Strategy and Goals

Organizations exist to fulfill a purpose. This purpose is expressed in an organization’s vision statement. The
vision statement is often very broad, describing what the leaders want the organization to accomplish. The
mission statement is more specific, describing how the organization is going to fulfill its vision.

.
Exhibit 2.1: The strategy cycle
Rice University, OpenStax

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. An organization also must analyze and work with its
strengths and weaknesses. These analyses can be used to inform the decision-making that follows. In particular,
the organization must develop objectives. These objectives are usually some sort of performance goal.
Examples of performance goals include increasing market share for a product/service, improving profitability,
and improving client satisfaction. For an objective to be effective, it has to be “SMART.”

24 | 2. Project Selection
 .Exhibit 2.2: The “SMART” criteria acronym.

• Specific

◦ Get into the details.

◦ Objectives are specific and written in clear, concise, and understandable terms.
• Measurable

◦ Use quantitative language.

◦ Outline the criteria that must be met in order to achieve the objectives.
• Acceptable

◦ All stakeholders must understand the organizational value of the objectives and accept them.
◦ Objectives can then be assigned to and completed by specific team members.
• Realistic

◦ Objectives must be centred in reality.

◦ Objectives that are impossible to accomplish are unattainable.
• Time-based

◦ Objectives have time frames and end dates assigned to them.

Once the objectives are developed, the organization determines how they will be achieved. This leads to the
creation of specific strategies. These strategies are directly linked to the objectives being pursued and will vary
widely depending on the industry and maturity of the organization. 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/or employee development initiatives.
Then, organizations move into the strategy implementation stage. Depending on the complexity of the
changes being introduced, the strategies may be implemented as individual projects or integrated programs.
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 leaders 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. A simple example of how this alignment is maintained
relates to decisions about project scope. If an organization is attempting to increase its market share in
a particular product or service, the project leader should ensure that information related to customer’s
preferences with features/functionality is shared with the project team and included in the solution design.
Organizations often consider the project and program leader’s organizational knowledge when making
resource assignment decisions. This knowledge can include an understanding of the particular industry/sector
that the organization is operating in, the products and services provided by the organization, the existence
of competitors and allies, and/or the expectations of clients/customers. Understanding customer/client

2. Project Selection | 25
expectations are particularly helpful because project/program success often contains measures of customer/
client success. Project and program leaders need to ensure that the solutions are very customer-centric.
Project and program leaders often lead change in a variety of industries/sectors throughout their professional
careers. A commitment to life-long learning and a willingness to seek out formal and informal mentors help
ensure project and program managers are able to gain the organizational knowledge needed to keep their
change initiatives aligned with their organization’s strategies and objectives.
Lastly, project and program leaders are increasingly part of project selection decisions. They offer unique and
valuable knowledge about what it takes to implement strategic initiatives. In particular, project and program
leaders are able to assess the complexity of a change initiative. Generally, more complex initiatives are risker.
They also require a longer implementation and business benefit realization period. Therefore, project selection
decisions will weigh the benefits offered with the timeframe required to realize these benefits. Projects that
offer significant benefits that can be realized in a relatively short time period are more likely to be approved.
These considerations can be viewed as selection criteria in the project portfolio management process. Section
2.2 will examine project selection criteria and decision-making models more closely.

.
Exhibit 2.3: Balancing these two variables (benefits of change and realization time) is crucial. If the benefits do
not outweigh the realization time period, project and program leaders will not initiate the change effort. This is
especially true today given the disruptive pace of advancements in technology.
Pixabay

26 | 2. Project Selection
2.2 Project Portfolio Creation and Ongoing Management

A portfolio is “projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic
objectives.”1
Portfolio management is defined as “the centralized management of one or more portfolios to achieve
strategic objectives.”1
Understanding why change initiatives were selected is helpful because it guides future decision-making.
These reasons can be non-financial and financial in nature. The non-financial reasons are often viewed as
strategic considerations; they include everything from ending a dependency on an unreliable vendor to
restoring the image of an organization. Many organizations also use financial criteria to ensure that an
investment will deliver value to the organization. Three common financial criteria used are net present value
(NPV), return on investment (ROI), and payback period. Since little may be known about the specific solution
at the time of project selection, financial evaluations are based on high-level estimates only. Once a project is
selected, a more detailed financial analysis is often performed. Project justification will be discussed further in
Section 4.1.
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, therefore, allows decision-makers to structure the decision-making

process by:

1. Specifying and prioritizing needs by identifying decision-making criteria; then

2. Evaluating, rating, and comparing different alternatives; and
3. 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 in order to identify important factors.
As previously discussed, this is 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 is evaluated against the
weighted criteria and given a score. Weighted scoring models have lots of applicability in everyday life.
Let us see how a weighted scoring model can help us introduce more objectivity into our decision-making
with a real-life example. Imagine you have decided to take a vacation and want to get away to a gloriously warm
and welcoming resort outside of your home country. The options are endless! How do you decide? For some,
things like a sandy beach, diverse food and drink options, and a rich nightlife are the most important factors in
their decision. For others, the length of the airplane trip and the cost are the most important factors. The length
of the airplane trip is particularly important to those who have limited time for a vacation. Attempting to weigh
all these factors into our decision can be overwhelming. We can simplify our decision-making by turning this
into a weighted scoring model. All the things we deem important will become our criteria. Recognizing that
some of the criteria are more important than others, we assign weights to the criterion. For example, we assign
the following weights using a 5-point scale:

2. Project Selection | 27
 Criterion Importance Weight Assigned
Sandy beach Very important 5

Diverse food and drink Somewhat important 3

Rich nightlife Very important 5

Airplane duration Important 4

Cost Somewhat important 3

Our list of resort destinations is very long. After considering our criteria, we were able to narrow it down to 5
locations. Here is the list:

1. Dassia, Greece
2. San Jose del Cabo, Mexico
3. Serra Negra, Brazil
4. Nabq Bay, Egypt
5. Sanya, China

Let us build our weighted scoring model (accessible versions of the three tables below can be found here). It
could look like this:

.
Now we have to evaluate each of these locations according to our criteria. These evaluations are somewhat
subjective. We assign each location a score between 1 and 10, with 1 being the lowest and 10 being the highest.
These scores could result in the following matrix:

.
Evaluating vacation alternatives is a matter of personal taste. For instance, those who enjoy the foods of
the Mediterranean are more likely to rate locations like Greece higher than the locations where the food
is spicy. In addition, the cost is also dependent on the activities someone would choose to pursue while
on vacation. Scuba diving, mountain climbing, and shopping excursions may have greater appeal to some
travellers and lesser appeal to others. If you were to use the weighted scoring model in your own vacation

28 | 2. Project Selection
planning, you would have the opportunity to assess your chosen locations from the perspective of your own
personal taste.
The last step is to calculate the weighted score for each location. As an example, when considering the Dassia,
Greece vacation, we would multiply the score of 8 for Sandy Beach by the weight of this criterion which is 5
since this criterion was of the utmost importance. We would then multiply the score of 7 for Food & Drinks by
the weight of this criterion which is 3. This continues for all 5 criteria and would result in the following equation:
The Weighted Score for Dassia, Greece =
(8×5) + (7×3) + (8×5) + (4×4) + (6×3) = 40 + 21 + 40 + 16 + 18 = 135
The completed weighted scoring model would appear as follows:

In this case, our traveler may choose San Jose del Cabo in Mexico as this location is best able to meet their
personal tastes. The second choice would be Serra Negra in Brazil.

A word of caution on the use of these weighted scoring models: this tool is meant to add objectivity to our decision-
making process; it is not meant to replace our own judgment.

This is particularly important when several of the options have very similar weighted scores. 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.

2.3 The Project Management Office

Many large and medium-sized organizations have created a department to oversee the project selection
process and support project delivery throughout the organization. This is an attempt to reduce the high
number of failed projects. These offices are usually called the project management office or PMO.
The PMO may be the home of all the project leaders in an organization, or it may simply be a resource for all
Project Leaders, who reside in the functional departments.
Typical objectives of a PMO are:

• Help ensure that projects are aligned with organizational objectives

• Provide effective templates and procedures to project teams
• Provide training and mentorship to Project Leaders
• Provide facilitation in stakeholder meetings
• Stay abreast of the latest trends in project management
• Serve as a repository for project reports and lessons learned

The existence and role of PMOs tend to be somewhat fluid. If greater success is not experienced as a result
of the PMO’s efforts, it is at risk of being disbanded as a cost-saving measure. If you are a project leader or a

2. Project Selection | 29
project team member in an organization with a PMO, try to make good use of the resources available. If you are
employed as a resource person in a PMO, remember that your role is not to get in the way and create red tape,
but to enable and enhance the success of project leaders and their projects within the organization.

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

30 | 2. Project Selection
3. Project Structures and Organizational
Culture
3.1 Introduction to Project Structures

Many organizations determine who should lead a change initiative by evaluating its complexity before
resources are assigned. Complexity can be assessed in many ways. Many organizations consider the number
and nature of people impacted, the priority and urgency of the change being introduced, and the degree of risk
associated with the change. Examples of risks:

1. The potential to lack the necessary resources and skills to support the project.
2. The potential that the cost of materials may increase past what is allocated in the budget.

There are three primary organizational structures used in project delivery: functional, dedicated, and matrix.

Functional Project Team Structures

Small, low complexity change initiatives are often delivered by departmental resources. These resources may be
department managers (e.g. marketing manager, manufacturing manager) or individual contributors carrying
out the day-to-day work of the department. Regardless of their role, it is important to note that these individuals
are participating in a change initiative in addition to fulfilling their day-to-day responsibilities. In this case, a
professional project leader is not assigned to lead the change initiative. Since the change is being delivered by
a particular department (function), it is commonly referred to as the functional project structure.
Functional project structures are effective ways to introduce change into an organization when the change
primarily impacts one function and the skills required to deliver the change are available in the department.
This becomes an efficient use of resources because the organization does not have to incur the cost of hiring
people to work on the project or fill in for functional resources temporarily re-assigned to a dedicated project
team. In addition, the team of individuals working on the project will have existing relationships with each other
and their leader. When these relationships are good, this can accelerate the effectiveness of the team.
However, the functional project structure comes with its own unique set of challenges. The first relates to the
potential for loosely defined accountabilities on the project. When it comes to decision-making, a lack of clear
authority can be particularly problematic. Functional project teams are often informally created and managed.
As a result, roles and responsibilities are often implied versus formally defined. It is important that the sponsor
of the change initiative clearly establishes accountabilities and responsibilities in order to facilitate effective
decision-making and reduce the likelihood of team conflict.
Secondly, the members of the functional project team may face an unrealistic workload when expected to
maintain their day-to-day accountabilities and complete project deliverables. This can lead to conflict and
burnout. In selecting people to work on a project in a functional structure, it is important that individual
capacity and skill are considered. Furthermore, the impact of these workload challenges often appears as
project delays occur. When faced with a choice of what to work on, functional project team members often
select their day-to-day accountabilities over the work of the project. This occurs because an individual’s
compensation and performance evaluation are often more directly influenced by the quality of the work

3. Project Structures and Organizational Culture | 31

performed in their functional positions. As a result, functional structures can be the slowest method of
introducing change into an organization.
Lastly, given the insular nature of a project delivered in a functional structure, it may be difficult for the team
to get the support they need from people outside of their functional team. This occurs because the project is a
priority for the functional team but rarely for other departments outside of the particular function. In addition,
technical resources may be focused on the delivery of high-visibility projects with organizational-wide benefits.
In conclusion, functional project structures work well for change initiatives that primarily involve a single
department and are not highly complex. When these conditions are not present, other project structures are
more appropriate.

Exhibit 3.1: Functional team structure diagram illustrating project coordination occurring within a department
(function).

Dedicated Project Team Structures

The opposite of a functional project team structure is the dedicated project team structure. In this
organizational model, all members of the project team are working exclusively on the project. Members of
these teams have either been hired specifically for the project, perhaps externally, or have been temporarily
reassigned from an existing functional team. This structure, although the most expensive, can be the fastest
way to introduce change into an organization. There are several reasons for this. Firstly, dedicated project team
structures are often more formally approved and recognized. The recognition often creates a greater sense
of urgency and this, in turn, may result in the leaders of the organization allocating the necessary supports
required for successful project delivery, such as timely reviews of project deliverables. Secondly, unlike the
functional project team structure, a project leader is assigned to lead the project team. The project leader may

32 | 3. Project Structures and Organizational Culture

be full-time or part-time, depending on the size and complexity of the change initiative. The project leader
ensures that the project team is aware of the project’s objectives, stays focused on the project’s deliverables,
and clarifies the accountabilities of the various team members. In turn, the project team members do not have
to balance their day-to-day work like members of project teams do in a functional project structure. This alone
can allow for faster completion of the project work as compared to the functional project structure.
Despite all the advantages of this structure, an organization may not be able to afford the dedicated model.
In addition, if the project team is not carefully selected, it may lack the subject matter expertise required to
successfully introduce change into the function(s) impacted. When an organization chooses to hire people
from outside the organization, they are unlikely to be familiar with the culture, processes, and procedures
of the organization. When this happens, the dedicated project team needs to include a sufficient number
of internal subject matter experts who bring this knowledge to the team. If this is not possible, the project
team needs timely access to these experts as required. This is a critical success factor of this model. Resource
constraints are a reality for many organizations, often leading to the use of the third project structure – the
matrix organizational model.

Exhibit 3.2: Dedicated team structure diagram illustrating project coordination occurring within a dedicated
project team that may report back to a department (e.g. marketing manager), which is typically the case in
lower complexity projects, or directly the chief executive officer (CEO), which is more likely to occur in higher
complexity projects.

Matrix Project Team Structures

As the name implies, the matrix project structure is a mix of the functional and dedicated structures. Projects
are delivered by resources that remain in their functional structures. However, they also report to a project
leader. By assigning a project leader, the organization attempts to ensure the project’s objectives are
formalized and progress is monitored. In addition, the project leader will use their project management and
leadership skills to increase the likelihood of project success. Having a project leader who is accountable for
the work helps ensure that best practices are followed, individual team member responsibilities are clear, and

3. Project Structures and Organizational Culture | 33

the team remains committed to the project’s deliverables and objectives. This structure seems like the ideal
model to deliver change – subject matter experts (engineers, manufacturers, marketers) carry out the work
and they have the benefit of a skilled project leader to mentor them along the way. However, this structure
can be stressful for all parties involved. From the project team’s perspective, reporting to two people can be
really challenging, especially if their functional manager and project leader are not effective communicators.
From the project leader’s perspective, despite being accountable for project success, they may have little
influence over who does the work and when it is done. This is because they have to negotiate with the
functional manager(s) in order to obtain the resources they need when they need them. On the other hand,
functional managers must balance allocating resources to achieve their operational targets as well as to
ensure the project’s success. If a functional manager does not share accountability for project success
alongside the project leader, they are unlikely to be willing to free up the needed resources if it means their
operational targets may become harder to achieve. From the perspective of the functional manager, a project
may offer them numerous future benefits, such as improved productivity or the potential for greater client
satisfaction. However, these benefits may seem too far in the future and may not be fully considered if their
immediate operational targets are difficult to achieve. Naturally, the project leader and the functional
manager will attempt to negotiate for the outcomes most desirable to them. Power struggles can lead to
unhealthy conflict, leaving the project team members in stressful situations. Much of this can be avoided if the
priority of a project has been clearly communicated by the organization’s executive team, and the
performance of the project leader and functional manager(s) are appropriately linked in order to encourage an
environment of cooperation.

Exhibit 3.3: Matrix team structure diagram illustrating project coordination occurring in a way where an
employee is reporting to a project manager for their project team duties while also reporting to a department

34 | 3. Project Structures and Organizational Culture

 manager for their departmental duties. In some instances, project managers may report to their own
“department manager,” the director of projects.

Determining which organizational structure to use at any given time often involves a mix of practical
and strategic considerations. From a practical perspective, if the organization lacks the financial
resources required to set up a dedicated project team, this leaves two alternatives – the functional or
matrix structures. A key strategic consideration is the importance of the project. High-priority projects
with aggressive timelines are not well suited to the functional project team model because it is the
slowest of the three. In situations where funds are limited, the matrix structure is preferred over the
functional model.

Some organizations carry out a lot of projects. This is often the case in rapidly changing markets and
in organizations going through significant internal transformation. In these cases, investments are
often made to establish permanent project teams that are able to lead the organization’s various
change initiatives. In extreme cases, organizations that view project delivery as a core aspect of their
day-to-day activity can adopt a projectized environment. In projectized environments, the traditional
hierarchal and function-based management structure gives way to a flatter team-oriented structure
which is often more agile in nature.

3.2 Introduction to Organizational Culture

Organizational culture refers to the beliefs, attitudes, and values that are shared by the organization’s members.
Organizational culture sets one organization apart from another and dictates how members of the organization
see, interact, and (sometimes) judge other employees. Often, project teams have a specific culture, work norms,
and social conventions.
Some aspects of organizational culture are easily observed; others are more difficult to discern. You can easily
observe the office environment – where people work (closed versus open spaces), how people dress, and how
people speak. The subtler components of corporate culture, such as the values and overarching philosophy,
may not be readily apparent, but they are reflected in the behaviours, symbols, and conventions used by
members.

3. Project Structures and Organizational Culture | 35

Exhibit 3.4: Consider these two different office environments. How do closed vs. open spaces reflect corporate
culture?
Pixabay, Unsplash

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.”1 By this, Drucker meant that corporate culture is more influential than strategy in terms of
motivating employees’ beliefs, behaviours, relationships, and ways they work since corporate culture is based
on corporate values. Strategy and other internal dimensions of the 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 the right values to respond to external threats and opportunities.
Secondly, culture creates internal unity by bringing members together so that 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, modelling how other executives 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 (CVF).
The CVF is one of the most cited and tested models for diagnosing an organization’s cultural effectiveness
and examining its fit with its environment. The CVF, shown in Exhibit 3.5, has been tested for over 30 years;
the effectiveness criteria offered in the framework were discovered to have made a difference in identifying
organizational cultures that fit with particular characteristics of external environments.2

36 | 3. Project Structures and Organizational Culture

 Exhibit 3.5: The competing values framework.
.
The two axes in the framework, external focus versus internal focus, indicate whether or not the
organization’s culture is externally or internally oriented. The other two axes, flexibility versus stability and
control, determine whether a culture functions better in a stable, controlled environment or a flexible, fast-
paced environment.
Combining the axes offers four cultural types:
1. The dynamic, entrepreneurial adhocracy culture – an external focus with a flexibility orientation

• Emphasizes creating, innovating, visioning the future, managing change, risk-taking, rule-breaking,
experimentation, entrepreneurship, and uncertainty
• Found in fast-paced industries, such as filming, consulting, space flight, and software development
• In larger organizations with adhocracy culture, such as Facebook and Google3, a different subculture may
evolve within one department (e.g., marketing or finance) of an organization, and it may be quite different
than the larger, dominant culture of the organization

2. The people-oriented, friendly clan culture – an internal focus with a flexibility orientation

• Emphasizes relationships, team building, commitment, empowering human development, engagement,

mentoring, and coaching
• Found in human development, team building, and mentoring organizations, such as the Olympians of
Team Canada, which has strived to form respectful relationships with employees, customers, suppliers, and
the physical environment

3. The process-oriented, structured hierarchy culture – an internal focus with a stability/control orientation

3. Project Structures and Organizational Culture | 37

 • Emphasizes efficiency, process and cost control, organizational improvement, technical expertise,
precision, problem-solving, elimination of errors, logical and conservative management and operational
analysis, and cautious decision-making
• Found in bureaucratic and structured organizations, such as the military and other government agencies

4. The results-oriented, competitive market culture – an external focus with a stability/control orientation

• Emphasizes competing and delivering results, delivering shareholder value, goal achievement, speedy
decisions, hard-driving through barriers, directive, commanding, and getting things done
• Found in marketing-and-sales-oriented organizations that work on planning and forecasting, but also
getting products and services to market and sold, such as Oracle and its dominating, hard-charging
executive chairman Larry Ellison

Working Within a Culture

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. Consider the following scenario:
Assume 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.
Furthermore, 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 this organization on this issue? Will your project decisions
and documentation have to go up through several layers to get approval? If so, what are the criteria and
values that may affect acceptance there? For example, is cost, quality, or being on schedule the most
important consideration?
• What type of communication among and between stakeholders is preferred? Do they 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 or ask others in the
organization.

References
1
Hyken, S. (2015, December 5). Drucker said culture eats strategy for breakfast. Forbes.

38 | 3. Project Structures and Organizational Culture

https://www.forbes.com/sites/shephyken/2015/12/05/drucker-said-culture-eats-strategy-for-breakfast-
andenterprise-rent-a-car-proves-it/#7a7572822749
2
Cameron, K., Quinn, R., Degraff, J., & Thakor, A. (2014). Competing values leadership (2nd ed.). Edward
Elgar Publishing; Cameron, K., & Quinn, R. (2006). Diagnosing and changing organizational culture: Based
on the competing values framework. https://www.ocai-online.com/blog/2016/09/Organizationalculture-Create-
Collaborate-Control-Compete
3
Yu, T., & Wu., N. (2009). A review of study on the competing values framework. International Journal of
Business Management, 4(7), 37-42.

3. Project Structures and Organizational Culture | 39

4. Project Initiation

4.1 Statement of Project Justification

All projects are created for a reason. 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.
Miscommunication is a common occurrence in our everyday lives. Even something as simple as ordering
food can lead to misunderstandings. For instance, a waiter brings us our dinner and we note that the baked
potato is filled with sour cream, even though we expressly requested no sour cream. Misunderstandings are not
intentional; they simply speak to the challenges associated with effective communication.
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 opportunity. A needs analysis is
often conducted to better understand the underlying organizational needs and how meeting these needs
would help the organization increase its success. Once alternative solutions are identified, each 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. A final recommendation is determined
after all solutions and issues are assessed. It is important to note that project justification is a key part of
the project initiation phase. If issues of justification are not adequately addressed, the project will lack the
required organizational support and, therefore, will ultimately be unsuccessful. An effective project justification
document contains the following:

• A detailed description of the problem or opportunity with headings such as introduction, business
objectives, problem/opportunity statement, assumptions, and constraints
• A list of the alternative solutions available
• An analysis of the business benefits, costs, risks, and issues
• A description of the preferred solution (if possible)
• Main project requirements
• A summarized plan for implementation that includes a schedule and financial analysis

In low complexity projects, this document may be a few pages in length. In higher complexity projects, this
document may be 10 or more pages long and referred to as a business case. Regardless of the format, the
project sponsor must approve the project justification document. Project justification and feasibility analyses
are most effective when they are performed jointly by the functional managers who will maintain a project’s
solution post-launch and the project team members who will perform the work. Realism is introduced when
both parties are involved upfront in the project selection process. In addition, this collaborative process assures
some level of commitment on all sides which may enhance accountability among team members. Lastly, it may
become apparent that the project is not worth pursuing at any stage in the justification process. If this is the
case, the project is terminated; thus, the next phase never begins. In situations where sponsor approval does
occur, the required funding to proceed is provided.

40 | 4. Project Initiation
 It is important to note that not all projects proceed with a clear view of the solution in mind. Solutions can be
created in an iterative or incremental fashion by using an adaptive development methodology. In these cases, it is
important to understand what the project is striving to achieve in terms of value for the organization as this will
shape the development efforts.

Often, the project leader is part of the project justification work. If not, a project leader is appointed shortly
after this work has been completed. The project leader then begins to develop the project infrastructure to
support all the activities associated with planning, executing, monitoring, and closing the project. The project
leader conducts 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, the project leader is learning to
identify the appropriate means of communicating with key stakeholders. Effective communication with project
stakeholders is another critical success factor so this work must begin early.
Team building begins and collaborative approaches for working together are discussed. During these
meetings, the project leader will share:

• The project’s objectives

• Known priorities and success measures
• Organizational constraints and related trade-offs
• A high-level description of the project scope
• Key milestones
• An initial list of project risks
• Key stakeholders

This information and the decisions that go along with it are often captured in a document referred to as 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, who specifically detail
their respective roles and responsibilities, and project success measures.
Similar to the project justification document, the project charter must also be approved by the project
sponsor. This document 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 in order to achieve the project’s objectives. Once it 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. The
title and form of the document are not important. Approval of this document, whether a letter of agreement or
a project charter, signals the transition into the planning phase of the project.

4.2 Assessing Organizational Constraints and Trade-Offs

Projects have unique constraints which are often defined by the organizational objectives that drive the
change. The interdependency of scope, time, and cost and the related implications for quality is of primary
interest. Many project leaders refer to this as the triple constraints. Organizations face limitations that are often
most apparent in the amount of work (scope), the amount of time available, and the required costs.

4. Project Initiation | 41
 Exhibit 4.1: In this diagram, each circle represents one of the constraints wherein any changes to one of the
constraints can cause a change to one or more constraints.

• Scope encompasses the work involved in delivering on the project’s objectives and the processes used to
complete the work.
• Schedule encompasses the time available to complete the project.
• Cost encompasses the amount of money available to complete the project and includes support for the

42 | 4. Project Initiation
 resources, supplies, and other materials required to produce the project outcomes.
• Quality encompasses the standards and criteria the project’s deliverables must meet in order for them to
perform effectively. The end outcomes must meet stakeholders’ expectations and performance
requirements, and service levels, such as availability, reliability, and maintainability, as well as deliver on its
anticipated organizational benefits/value.

Scope, schedule, and cost are defined at the outset of the project for its entirety when the
predictive/waterfall development methodology is used. Alternatively, when an adaptive
methodology is used, the triple constraints may be stated as broad parameters which are later
refined and affirmed as the project’s solution is developed. For instance, the organization may have
a fixed budget and target launch date. Based on those two parameters, decisions about scope will
be made.

Project management has many practical applications for everyday life and a great way to highlight this is to
look at the triple constraints for planning a vacation. Unfortunately, it is very unlikely that we can spend as
much money as we want, stay for as long as we want, and travel any place we want. We must decide what
our priorities are. If we treat the budget (cost) as our priority, it will have implications for how long we can stay
(schedule) as well as the nature (scope) and overall quality of the accommodations, flight, and/or food we select.
In this example, we achieve our budget objective (fixed at $2,000) by making trade-offs with our vacation
schedule and the destination (scope). If your circumstances change and you happen to have more money
available for your vacation, you can evaluate the implications this has on the other constraints. For instance,
you may choose to stay longer (modify your schedule), book more day trips throughout your stay (modify your
scope) and/or select a hotel with more amenities (modify the quality). The opposite could be true as well. If
you discover that the cost of the flight has just gone up, you would have to identify ways to reduce the costs
associated with other aspects of your vacation. You could decide to shorten your stay (reduce your schedule),
eliminate some of your day trips (cut scope), and/or select a hotel with fewer amenities (reduce quality).
In organizations, the circumstances surrounding project delivery may also change. For instance, if your
project sponsor requests more features/functionality in the product, service, or result delivered by the project
(scope modification), this may require more money and/or more time. The decisions we make about the triple
constraints have broader implications. We need to consider the resource requirements and the uncertainties
(risks) associated with our plans to achieve the project outcomes.
These examples effectively highlight the interdependencies between cost, schedule, and scope, and their
implications on quality. It all starts with understanding the organization’s priorities. This gives the project leader
and development teams the guidance needed to make effective recommendations and decisions.

4.3 Stakeholder Identification and Management

A project is successful when it achieves its objectives. The objectives need to be clear, measurable statements
of organizational value. Ultimately, a project’s stakeholders will determine if the expected value was delivered.
Stakeholders are individuals who are impacted by the project or who are impacting the project. They are
the people who are actively involved in carrying out the work of the project and/or have something to either
gain or lose as a result of the project. The project sponsor is typically the most powerful stakeholder. They
often initiate the project and as such, are often referred to as the “initiating sponsor.” They have the authority

4. Project Initiation | 43
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. Many project sponsors 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.
A successful project leader will identify all stakeholders. The project sponsor and the sustaining sponsor(s) are
very helpful in identifying additional project stakeholders and often consulted early in the project. Depending
on the nature of the project, departments such as information technology, human resources, finance &
accounting, engineering, manufacturing, and marketing are also considered to be project stakeholders. In
addition, external stakeholders often include customers, suppliers, and regulatory bodies. During project
initiation, it is important to effectively identify a comprehensive list of project stakeholders. This will allow the
needs of these stakeholders to be identified and considered throughout the project. The stakeholders are then
included in the project charter which must be approved by the project sponsor before the planning phase can
begin.
For high complexity projects, it may often be challenging to maintain an accurate picture of all the
stakeholders. New stakeholders can arise at any time, and the needs and interest levels of a particular
stakeholder may change through the course of the project. A stakeholder register is a powerful tool and it is
specifically designed to assist in stakeholder management.

44 | 4. Project Initiation
 Exhibit 4.2: Example of a stakeholder register. (accessible version)
In addition, it is important to prioritize stakeholders. Some stakeholders have little interest and little influence
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 power/influence of project stakeholders by researching their position, their actions in previous change
initiatives, and by directly speaking with them about the project. Let us delve into how the assessment is done.
When considering a stakeholder’s interest, assess the following:

• How is their performance evaluated?

• Will their performance be impacted by the project and/or the project’s outcomes?
• Are they (or individuals on their team) needed to help produce the project’s outcomes?

When considering a stakeholder’s influence/power, assess the following:

• What position do they currently hold in the organization?

• How much authority does this position afford them over the project?
• Do they have influence over people in positions of high power?

After the initial assessment has been completed, stakeholder prioritization can occur. A power/interest grid

4. Project Initiation | 45
is a very helpful tool for prioritization. It helps project leaders categorize stakeholders and create effective
communication strategies for each category of stakeholder on the project.
Thinking back to our vacation project, the following individuals could be our stakeholders:

1. Spouse (assuming they join you)

◦ High interest
◦ High influence/power

2. Neighbour (volunteered to watch over your house)

◦ Medium interest
◦ Low influence/power

3. Airline company (a vendor; critical in helping you reach your destination)

◦ High interest
◦ High influence/power

4. Hotel (a vendor; critical in achieving your quality expectations)

◦ High interest
◦ High influence/power

5. Insurance company (a vendor; critical in providing peace of mind for travel-related risks)

◦ Medium interest
◦ Medium influence/power

As Exhibit 4.3 depicts, prioritizing our stakeholders helps us ensure we develop appropriate stakeholder
management strategies.

46 | 4. Project Initiation
 Exhibit 4.3: The five stakeholders in the example above superposed on a power/influence and interest matrix.
Project leaders need strong soft skills to carry out this work effectively. Project leaders generally have little or
no direct authority over any of these individuals, making stakeholder management particularly challenging.

4.3 Selecting the Right Development Methodology

Determining which development methodology to use is one of the key decisions project leaders must make.
Generally speaking, projects with a clear vision of the solution(s) are implemented using the predictive
(waterfall) methodology. Note: for the purposes of this text, we will consider the terms “predictive” and
“waterfall” as interchangeable. Since the solution(s) are well defined, it is possible to define all the requirements

4. Project Initiation | 47
upfront. In situations where the solution(s) can not be well defined, adaptive development methodology is
used. This allows the requirements to evolve over time. Instead of working with end-users to define what is
required before development begins, development occurs in an iterative or incremental cycle. There are several
adaptive development methodologies. Predictive and adaptive development methodologies are very different.
It is important for project leaders to clearly communicate how the work will be managed depending on the
selected approach.
When the adaptive development methodology is used, a much higher degree of stakeholder involvement is
required. This is not always seen as a positive because many stakeholders face competing demands for their
time and change initiatives. Moreover, despite the priority of the project, key stakeholders may be unable to
dedicate an adequate amount of time to the project. In addition, the organization requires clear “product/
process owners” to be involved in the planning of each adaptive release as the project’s solutions are defined.
Organizations that lack this type of ownership structure are likely to struggle with the use of an adaptive
methodology.
Lastly, it is possible for some projects to use a combination of the approaches in situations where some
of the solutions are well-defined while others remain unclear. This is referred to as the hybrid approach. For
instance, a project may involve the deployment of new technology, the move to a new office location, and
a reorganization of staff reporting relationships. It is possible for the new technology to not be well-defined
while the requirements associated with the new location and organizational structure are well-defined. In this
circumstance, the adaptive approach would be used to develop solutions for the technological aspects of the
project and the predictive approach would be used to define and implement the transition to a new office
location and organizational structure.
In summary, project leaders need to be able to highlight the pros/cons of each approach. In situations where
the organization runs the risk of developing solutions that do not deliver the expected organizational value
because the requirements are not fully known, project leaders who are able to effectively communicate this risk
are likely to gain stakeholder support to use the adaptive approach.

Agile

Agile is here to stay. Scott Ambler, VP and Chief Scientist of Disciplined Agile at PMI, believes, “Agile isn’t
just a trend, it’s here to stay…especially as we better learn how to effectively yield its benefits.”1 Agile is an
overarching term. It refers to a family of project delivery frameworks that promotes adaptive, incremental
solution development versus sequential solution development. Exhibit 4.3 depicts the agile approach as a
series of smaller iterations; this is in contrast to the single development effort used in predictive development
methodology.

48 | 4. Project Initiation
 Exhibit 4.4: The adaptive nature of Agile
Tricentis

Agile is no longer just used on technology projects. In addition, there are now a number of different types of
agile methodologies. These methodologies guide development teams in identifying user requirements and
creating manageable chunks of development effort. In addition, there are numerous testing methodologies
to chose from. Recognizing that “one size does not fit all,” it is important to consider organizational size,
organizational culture, and the needs/preferences of stakeholders when deciding if agile will be used in a
project. Some of the external factors to consider include the maturity of the industry, competitive forces, and
current customer satisfaction levels. Agile as a development methodology could easily become a textbook and
course all on its own. Listed below are various agile frameworks and practices.
Frameworks:

• Scrum
• SAFe
• Crystal
• Kanban
• eXtreme Programming (XP)
• Feature-driven programming

Practices:

• Timeboxing
• User stories
• Daily stand-ups
• Frequent demonstrations
• Test-driven development
• Information radiators
• Retrospectives
• Continuous integration

Since the goal of this textbook is to provide an overview of the fundamentals of project management, an
overview of one of the most popular methodologies, Scrum, will be provided.

Scrum

Scrum is a product development methodology and part of agile project management. Scrum is a term from
rugby (scrimmage) that refers to a way of restarting a game. It is like restarting the project efforts every few
weeks. It is based on the idea that you do not really know how to plan the whole project upfront, so you start
with what you know and then re-plan/iterate from there.
Scrum uses sequential sprints for development. Sprints are like small project phases (ideally two to four
weeks). The idea is to take one day to plan for what can be done now, then develop what was planned for,
and demonstrate it at the end of the sprint. Scrum uses a short daily meeting of the development team to
check what was done yesterday, what is planned for the next day, and what (if anything) is impeding the
team members from accomplishing what they have committed to. At the end of the sprint, what has been
demonstrated can then be tested, and the next sprint cycle starts.
Scrum methodology defines several major roles. They are:

4. Project Initiation | 49
 • Product manager/owner: essentially the business owner of the project who knows the industry, the
market, the customers, and the business goals of the project.

◦ Builds consensus within the end-user community

◦ Communicates end-user expectations to the development team
◦ Provides acceptance on completed feature definitions in the solutions and the completed user stories
◦ Usually accountable to the project sponsor. If the project has two project sponsors (one from the
business and the other from IT), the product managers would report to the business sponsor.
◦ “Owns” the content (what is built and in what sequence)
• Business area lead (AKA subject matter expert or SME): is from a particular business unit and may be an
end-user or directly represents the end-users.

◦ Works very closely with the product manager/owner to develop the vision for the solution
◦ Helps clarify business needs and expectations
• Scrum master:

◦ Removes barriers that impede the progress of the development team

◦ Helps the product owner maximize return on investment (ROI) in terms of development effort
◦ Facilitates creativity and empowerment of the team
◦ Improves the productivity of the team, as well as engineering practices and tools
◦ Runs daily stand-up meetings
◦ Tracks progress
◦ Ensures the overall health of the team
• Development team: a highly empowered group that participates in planning and estimating for each
sprint.

◦ Develops the solution in sprints

◦ Demonstrates the results at the end of the sprint
◦ Sometimes (depending on the organization) involved in testing, including functional testing
(confirming the software requirements have been met) and non-functional testing (security, usability,
performance)

The role of the project manager varies by organization. Some organizations using scrum give some of the
project manager’s accountabilities (particularly arranging for project funding, risk management, and iteration
planning) to the product owner. However, the team management aspects are less likely to be assigned to the
owner because they often require significant time commitment if the project has a large cross-functional team.
In these cases, a project manager may be assigned not only to lead the project team but also to manage the
budget and schedule commitments of the project. This frees the product owner to focus on what is being built
as well as the end-user community. When all three roles – product owner, scrum master, and project manager
– are present on the project, they all must work toward project success in a highly collaborative fashion.
Solutions developed with agile methodology typically start with an epic. An epic is the rough outlines and
boundaries of the solution. It frames the organizational value to be delivered by the project. It serves as the
starting place for analyzing what is required. Through analysis, the required capabilities and enablers are
identified. The features (deliverables that will fulfill stakeholder needs) of each capability are then identified.
These features can then be further broken down into user stories to represent smaller pieces of the
functionality. The user stories go into a product backlog. Lastly, each story is then broken down into tasks. The
tasks are what the team members would complete in order to define, build, and test a user story.
Iteration planning is very important in agile methodologies. This is where the scope of the iterations is
determined. Ultimately, iterations representing about two weeks’ worth of effort are formed and referred to as
sprints. As one sprint is developed, it is tested then shared with the end-user community for feedback. Further
iterations are implemented as required.

50 | 4. Project Initiation
 Planning meetings for each sprint require participation by the product owner, the scrum master, and the
development team. In these meetings, goals are set for the upcoming sprint and a subset of the product
backlog (proposed user stories) is selected to be worked on. The development team decomposes stories into
tasks which are then estimated. The product owner then finalizes the backlog for the following sprint. The
planning cycle continues until the solution has been completed in its entirety.

Additional resources:

The Home of Scrum

Project Management Institute

References
1
Ambler, S. (2019). The Most Important Agile Trends to Follow in 2020. Information Week.
https://www.informationweek.com/strategic-cio/enterprise-agility/the-most-important-agile-trends-to-follow-
in-2020/a/d-id/1336550

4. Project Initiation | 51
5. Project Planning
Overview

After the project has been approved and the project team has been appointed, you are ready to enter the
second phase in the project management life cycle: project planning. This phase involves creating a set of
plans to help guide your team through the execution, monitoring, and closure phases of the project. The plans
created during this phase will help you manage time, cost, scope, quality, changes, risk, and other related issues.
They will also help you lead staff and work with external suppliers to ensure that you deliver the project on time,
within budget, and with the desired feature/functionality.
The planning phase is often the most challenging phase for a project leader because they must make
educated guesses about the staff, resources, and equipment required to complete the project.
In collaboration with the project sponsor(s), the project leader identifies the work to be done for the project or
the iteration (depending on the development methodology used). Once the major components of the project
(or iteration) are known, the project leader will identify team leaders to carry out the detailed planning of the
project’s sub-components. These components are often called “work packages” in predictive methodology and
“sprints” in agile’s adaptive methodology.
Also, at this stage, resource requirements are identified in whole or in part (depending on the development
methodology used). A strategy is developed for accomplishing the work. Then, the timeframes, dependencies,
and resources required for work packages or sprints are documented in a project schedule. In addition, the
project leader coordinates the preparation of a budget by providing cost estimates for the labour, equipment,
and materials. The budget is monitored during the implementation and closure phases.
Once the project team has identified the work, prepared the schedule, and estimated the costs, the three
fundamental components of the planning process are complete. This is an excellent time to identify and try to
deal with anything that might pose a threat or an opportunity to the successful completion of the project. This
is called risk management. In risk management, the threats and opportunities are identified along with the
action that is to be taken as a response in order to optimize the likelihood of project success. In the initiation
phase, a preliminary list of project stakeholders was identified. During the planning phase, the list is reviewed
to ensure that it remains current and stakeholders continue to be prioritized. Stakeholder engagement is a
critical success factor. An effective communication plan is one of the tools used to ensure stakeholders remain
informed and supportive of the project’s objectives. Effective project leaders spend about 90% of their time on
a project communicating with stakeholders.1
In some instances, organizations need to obtain products and utilize services from outside of the
organization. Overseeing these transactions is known as procurement management. During the planning
stage, it involves identifying the type of vendors required and the selection criteria to be used. Finally, project
leaders ensure that the team understands the quality expectations of the stakeholders. In order to fulfill
these expectations, a quality management plan is developed (identifies quality targets, assurance, and control
measures), along with an acceptance plan (lists the criteria to be met in order to gain stakeholder acceptance).
The project leader integrates the team’s planning efforts. Various tools and techniques are used to effectively
perform integration management. A comprehensive project plan may be created to ensure all the various
management plans identified above are cohesive and well-aligned. Project plans are typically created for
projects with a medium-to-high level of complexity and rarely for low complexity projects. Determining the
need for a project plan is part of the tailoring work done by the project leader at the outset of each new project.
The planning phase refines the project’s objectives, which were identified during the initiation phase. This
phase also includes planning the steps necessary to meet those objectives by further identifying the specific

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

1.1 Eliciting Project Requirements

After the objectives of the project are identified, the project leader needs to better understand the solution’s
requirements. Requirements describe the characteristics of the final outcome, which may be a product, service,
or result of the project. Moreover, requirements describe the functionality that the final outcome must possess
and specific conditions that must be met in order to satisfy the objectives of the project.
It is important to start defining requirements at the project level. Project requirements describe what the
project is supposed to accomplish. This gives the project team a clear understanding of the required outcomes
and their corresponding organizational value. These outcomes often describe the transformation that will occur
within the organization as a result of the project’s implementation. A clear picture of the current state (the “as-
is”) and the desired future state (the “to-be”) is an effective way to help the team determine what the solution
must achieve. Teams that lack an understanding of the project requirements are unlikely to deliver solutions
that provide organizational value.
Solution requirements are developed after the project requirements. When the adaptive development
methodology is used, the requirements are developed in an iterative or incremental fashion. As previously
mentioned, in agile, solution development begins with an epic, which are the rough outlines and boundaries
of the solution. The end-user community is involved in numerous requirement development sessions. These
sessions determine the required capabilities, enablers, and features of the solution. Features are written as
user stories which are then compiled in a product backlog that becomes the basis of iteration planning. The
iterations are referred to as sprints, each containing a set of requirements that guides the development and
testing efforts.
In contrast, when the predictive development methodology is used, the end solution is clear, allowing
the requirements to be completed upfront. The end-user community participates in far fewer requirement
development sessions than when an adaptive approach is used.
In general, solution requirements may include attributes such as dimensions, ease of use, colour, specific
ingredients, and so forth. Requirements must be measurable, testable, related to identified organizational
needs or opportunities, and defined to a level of detail sufficient for solution design.

The Nature of Requirements

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

5. Project Planning | 53
The End-User Community

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

Technical Requirements

Technical requirements emerge from an understanding of the end users’ requirements. Functional
requirements provide answers to questions such as: how will the problem be solved this time, and will it be
solved technologically and/or procedurally? These requirements specify how the system must be designed and
implemented in order to provide the required functionality and fulfill quality expectations.
For example, in a software project, the functional requirements may stipulate that a database system will
be developed to allow access to financial data through a remote terminal. The corresponding technical
requirements would spell out the required data elements, the language in which the database management
system will be written, the hardware on which the system will run, the telecommunication protocols that should
be used, and so forth. Similarly, end-users may require the solution to be functional and accessible 95% of the
time. The technical requirements will identify how this will be done using backup power supplies and so forth.

Regulatory or Industry-Specific Requirements

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

Elicitation Techniques

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

• Process flows for the “as is” environment

• Policies and procedures
• Problem/issue logs (including customer complaint logs)

54 | 5. Project Planning
 • User cases/stories created for technological implementations

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

• Interviews
• Focus groups
• Facilitated group sessions
• Group creativity techniques, such as:

◦ Brainstorming
◦ Mind-mapping
• Observation of clients, customers, and/or end-users
• Questions and surveys
• Group decision-making techniques, such as:

◦ Seeking consensus (among experts, the project team, the end-user community and so forth)
◦ Majority rule voting
◦ Dictatorship (project sponsor or product owner decides)

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

Requirements Traceability Matrix

Keeping track of the requirements is important for many reasons. Firstly, tracking the source of the requirement
is helpful in resolving issues of prioritization. It may not be possible to develop a solution with all the requested
requirements due to a lack of feasibility, time, and/or money. Consultation with stakeholders becomes critical
in these situations. In addition, difficulties may arise during development, requiring the input and review
of specific stakeholders depending on whether their requirements have been affected. These situations
underscore the importance of knowing which stakeholders have requested which requirements.
There is an arguably more important reason to track requirements; it ensures that each requirement can be
efficiently traced back to the objectives of the project. This allows the team to constantly reflect on whether
specific requirements add value.

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

1. Supports requirement prioritization by linking value to implementation effort (“must have”

versus “nice to have”)
2. Supports effective stakeholder management by understanding a requirement’s source

5. Project Planning | 55
 3. Aids in tracking the status of each requirement, specifically ensuring that requirements are
considered in the product or service design and delivered by the end of the project
4. Provides a structure for managing changes, if necessary, to a requirement’s scope

An effective requirements traceability matrix includes the following information:

• Requirements to organizational value and project objectives

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

Additionally, attributes associated with each requirement can be recorded in the requirements traceability
matrix. These attributes help to define key information about each requirement. Typical attributes used in the
requirements traceability matrix may include a unique identifier, a textual description of the requirement, the
rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added,
approved), date completed, and acceptance criteria, which ensure that the requirement has met stakeholders’
satisfaction.
Once the requirements are documented, the appropriate stakeholders sign off to confirm their needs have
been accurately recorded. The project leader then ensures that the requirements are incorporated into the
overall project plan (for predictive approaches) or iteration plans (for adaptive approaches).
The effective specification of requirements is one of the most challenging undertakings tackled by project
teams. Inadequately specified requirements will guarantee poor project results. Excellent communication and
negotiation skills are critical as project leaders often need to educate stakeholders about the organizational
impacts and implementation complexity of some of their requirements. In addition, when elaborate
requirements introduce additional complexity in a project, more staff, time, and/or money may be required. The
added complexity may also have an impact on project quality. Furthermore, some aspects of the project may be
unfeasible. If this is the case, there must be transparency with stakeholders so they can adjust their expectations
and/or prepare for future organizational challenges.

5.2 Scope Management

Requirements assist project teams in making scope decisions. During the initiation phase, the scope is often
broadly defined. High-complexity projects are more likely to have broad definitions of scope, describing the
desired outcomes of the project, since the availability of information regarding the solution may have been
minimal. However, as more information is obtained, the scope begins to be further refined in the planning
phase.
Scope statements identify the product and project deliverables that will be produced during the project or
the iteration. Deliverables are tangible outcomes that must be produced created in order for the project or the
iteration to be completed. This includes the project management deliverables and the product/service/result
deliverables, which are features that characterize the solution. In essence, the project scope denotes what work
will be done whereas the other project plans denote how the work will be done.

56 | 5. Project Planning
 When the predictive/waterfall development methodology is used, a scope statement representing the full
scope of the project is created. Then, the development team uses this scope statement to design and develop
the end solution in its entirety. When the adaptive development methodology is used, all the user stories
contained in the product backlog represent the scope of the project. The development team does not work on
the entire backlog at once. During iteration planning, the backlog is prioritized into small “sprints.” The scope of
these small sprints usually represents a few weeks of development effort. The results of each sprint are reviewed
with the end-user community and adjustments are made as appropriate. The scope of the sprints may change
as the team learns more about the end users’ requirements and the effort required in each sprint.
One of the most common challenges in projects following a predictive (waterfall) development methodology
is the unintentional expansion in the project scope. This is referred to as scope creep. Sometimes this occurs
because the scope was poorly defined at the onset. Perhaps the scope statement was poorly developed and/
or lacked the necessary stakeholder input and approval. Furthermore, the project team may have chosen
the wrong development methodology. For instance, if the team knew that the outcome of the project was
unclear and chose the predictive (waterfall) methodology regardless, scope management will prove to be very
challenging for the project team and stakeholders. This is because the stakeholders are likely to advocate for
the preservation of timeline and budget commitments. This leaves the project team with the chaotic task of
figuring out how to deliver on these commitments while the scope remains fluid.
This is not to say that scope should never be expanded. The key is how the scope is changed. When scope
changes are analyzed and formally approved (versus automatically or unintentionally pursued), project leaders
can determine the impact of this change on the project’s timelines, budget, and quality constraints (recall
the triple constraints theory). Communicating the impact of scope expansion on these constraints allows
stakeholders to make effective decisions about project priorities.

Work Breakdown Structure

The work breakdown structure (WBS) is a powerful communication tool. It is a visual depiction of the work
(scope) to be completed during a project by breaking the project down into smaller, more manageable
components.
When the predictive (waterfall) methodology is used, a deliverable-oriented WBS is often used to identify the
relationship between the deliverables, sub-deliverables, and, ultimately, the work packages associated with the
project. Each level of the WBS hierarchy represents a more detailed breakdown of the project work wherein the
top of the hierarchy represents broad categories and the lower levels represent increasing amounts of detail,
with work packages always being the lowest level of the WBS. Some project teams prefer to use a phase-
oriented WBS to depict the deliverables of each phase. For instance, the phases could be initiation, planning,
development, testing, rollout and closure. Both are acceptable forms of the WBS. The project leader is free to
determine the number of levels in the WBS based on the complexity of the project. It is important to include
enough levels to accurately estimate project time and costs, but not so many levels that it becomes too detailed
and difficult to read.
When an adaptive methodology such as agile is used, the WBS depicts the relationship between the project
(an “epic”), the capabilities of the solution, the features/enablers of the solution, the user stories, and the sprints
that contain the development teams’ tasks.
It is very important to note that the WBS defines what needs to be done, not how. The how is developed
by the work package leaders once the WBS has been completed and it is depicted using tools like the project
schedule and project budget.
A WBS can be structured in a graphical form where boxes represent the major deliverables, sub deliverables
and work packages. The individual boxes cascade in a hierarchy, illustrating the relationship of the underlying

5. Project Planning | 57
work. Exhibit 5.1 depicts the WBS language used in predictive (waterfall) and adaptive (specifically agile)
methodologies.

Exhibit 5.1: The WBS for Predictive and Adaptive development methodologies. In predictive methodology,
the sequence is as follows: project, major deliverables, sub-deliverables, and work packages. In the case of
iterative/agile methodology, the sequence is: project (may be referred to as an ‘epic’), capabilities, features/
enablers, and sprints.
It is also possible that the list format is used. This format simply lists the deliverables and the underlying work
in a list format. The list format below uses terminology from the predictive methodology.

WBS Formatting

Project Name

1.0 Major Deliverable

• 1.1 Sub Deliverable

• 1.2 Sub Deliverable
• 1.3 Sub Deliverable

2.0 Major Deliverable

• 2.1 Sub Deliverable

58 | 5. Project Planning
 ◦ 2.1.1 Work Package
◦ 2.1.2 Work Package
◦ 2.1.3 Work Package
◦ 2.1.4 Work Package

• 2.2 Sub Deliverable

• 2.3 Sub Deliverable

3.0 Major Deliverable

• 3.1 Sub Deliverable

◦ 3.1.1 Work Package

◦ 3.1.2 Work Package
◦ 3.1.3 Work Package

• 3.2 Sub Deliverable

◦ 3.2.1 Work Package

◦ 3.2.2 Work Package

• 3.3 Sub Deliverable

Each level of a WBS can be assigned a unique identifier. This unique identifier is typically a number that is used
to track costs, durations and resources associated with WBS elements. These identifiers are usually associated
with an organization’s chart of accounts, which is used to track costs by category. In addition, these identifiers
are often referred to in a project schedule and a project budget as this allows the project team to ensure all the
project work has been properly scheduled and resourced.
Work packages and sprints are components that are easily assignable to a team of people, providing clear
accountability and responsibility for detailed planning and ultimately implementation. It is important to ensure
that individuals with the appropriate skills, experience, and capacity are assigned to manage the delivery of this
work. They collaborate with the appropriate stakeholders to:

1. Confirm who must be involved in the work

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

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

5. Project Planning | 59
5.3 Resource management

Resources are people, equipment, space, money, and anything else needed to produce the project’s
deliverables. Staffing the project with the right skills, at the right place, and at the right time is an important
responsibility of the project leader. The project usually has two types of team members: functional participants
and process participants. The titles and roles given to these functional resources may vary by organization
and/or the development methodology chosen. For instance, some organizations refer to their functional
representatives as business owners and business SMEs (subject matter experts). High-complexity projects
often involve people who are gifted in project management processes. These individuals would have process
expertise in estimating, cost tracking, planning, and scheduling. In projects involving the launch of a new
product, functional team members would include sales and marketing representatives from their respective
departments. The functional representatives will play a vital role in ensuring the project team understands the
requirements of the solutions to be developed. The project leader requires functional and process experts to
work together in the planning and execution of a successful project.
Exact start and end dates for team members are often negotiated to best meet the needs of individuals
and the project. Projects typically have a core team that includes members of the project management team
(project leader, project coordinator, and so forth) and key members with functional expertise. Core team
members provide continuity and “corporate memory” throughout the project, particularly to external hires who
may not be as familiar with the strengths and weaknesses of the organization’s previous projects.
The staffing plan is determined by the different phases of the project. Team members who are utilized in the
early or conceptual phases of the project are often not needed during the later phases, such as project closeout.
Each phase has staffing requirements; the staffing of a complex project requires detailed planning to have the
right skills, at the right place, and at the right time.
Project team members may be acquired from outside the organization. This occurs when specific expertise
is required on a project that the organization lacks internally. Alternatively, it may be necessary to temporarily
replace internal staff with the required project expertise with temporary resources to perform their day-to-
day function while assigned to the project. These temporary resources may have been sourced from agencies
specializing in temporary staffing. Many projects use a combination of these staffing options.

Resource Planning

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

5.4 Schedule management

Developing and managing a project schedule that will deliver on the timeline objectives is the primary
responsibility of the project leader. Effective schedule management is integral to overall project success. The
objective is to create a schedule that effectively and efficiently uses allocated resources to complete the project
in the shortest amount of time possible.
Schedules must be communicated to project stakeholders. Generally speaking, stakeholders want to know

60 | 5. Project Planning
when the work will be completed. A technique called the critical path is used to determine the earliest date
by which a project or iteration can be completed. Once the completion date is determined, it is important to
confirm whether this date is able to meet the expectations of the project sponsor (and appropriate designates).
Once timeline commitments have been made, stakeholders must be kept up to date on any delays that will
cause deviation from the agreed-upon schedule.
If the project sponsor requires completion sooner than initially determined by the schedule, the team will
identify what can be done to bring the completion date in line with stakeholder expectations. Many options are
available and the brainstorming begins by examining the tasks on the critical path. Everything from changing
resource assignments to completing more tasks in parallel is discussed.
If the schedule indicates that the project will be completed sooner than expected, this creates additional
contingency (a buffer) and increases the likelihood that the overall project will be delivered on time. We will
explore the critical path in greater detail in the section below.

Defining Tasks

Detailed planning begins by identifying all the tasks to be completed. The project team begins by reviewing
the scope of the project which is found in the project scope statement (predictive projects) or in the product
backlog (agile projects). A work breakdown structure (WBS) allows the team to have a visual representation of
the forthcoming work. As discussed in the scope management section, the WBS is a powerful planning tool. By
breaking the project down into smaller, more manageable components, the WBS assists work package leaders
(predictive methodology) and scrum masters (adaptive methodologies) in identifying the specific tasks. The
team then determines how long it will take to complete the required tasks.
Sequencing is important. Sequencing defines the order in which tasks must be completed. Network
diagrams can be used to determine the sequencing of tasks. Network diagrams are similar to flow charts in
that they graphically depict which tasks must be completed before other tasks can begin and which tasks can
be done in parallel. Some teams chose to create these diagrams by using software such as Microsoft Project. In
smaller, simpler projects, brainstorming the sequence of tasks can be done using digital whiteboards or with
sticky notes.
If an organization maintains a project repository, it may offer examples of task lists, how tasks were sequenced
in past similar projects, and task duration estimates. When a project repository is not available, expert
judgement may be used. Expert judgment draws on the knowledge of project team members with prior
experience in developing an activity list using a WBS. One approach could be to draft a task list which is then
reviewed by the expert(s) who may suggest improvements. Alternatively, depending on available resources, the
expert(s) can be involved in creating the first draft of the activity list.
Once the work package leader(s) or scrum master have developed a schedule for the work they are
accountable for, it is given to the project leader, who then develops an integrated schedule for the whole
project.

A Case Study: “John’s Move”

Schedule development involves a lot of new terms and concepts. In order to effectively illustrate
the use of these terms and concepts, a simple example from everyday life has been selected. The

5. Project Planning | 61
 example involves moving from one city to another. The simplicity of this example is intended to
make it easier to learn new concepts. In addition, a physical move is something that many
students are familiar with and the familiarity should further support the learning process. It is
important to note that a project of this size would typically not require all the tools and techniques
described in the following examples.

***

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

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

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

Top-Level Deliverables in Move Planning

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

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

62 | 5. Project Planning
 Major Deliverable Decomposed into Smaller Activities

3. Packing

• 3.1. Confirm Dion’s and Carlita’s help

• 3.2. Pick up donuts and coffee
• 3.3. Pack apartment

◦ 3.3.1. Pack kitchen

◦ 3.3.2. Pack living room
◦ 3.3.3. Pack bedroom

▪ 3.3.3.1 Pack closet

▪ 3.3.3.2 Pack drawers
▪ 3.3.3.3 Pack blankets

◦ 3.3.4. Pack remaining items

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

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

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

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

Estimating the Resources

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

5. Project Planning | 63
 Expert judgment is when input is requested from experts, especially ones who have previously participated
in similar projects, on the required resources.
Alternative analysis is when several different options and possibilities for how you assign resources are
considered and examined, such as adjusting the number of resources as well as the kind of resources utilized;
oftentimes, there is more than one way to accomplish an activity.
Published estimating data is when project leaders collect and analyze data from articles, books, journals, and
periodicals, as well as other people’s projects, to aid in more accurate resource estimation. This is a very useful
tool for project leaders because published data is abundant and field-specific.
Project management software is when project leaders employ the use of programs, such as Microsoft
Project, to estimate resource needs and constraints, and find the best combination of assignments for the
project.

Estimating Activity Durations

There are two fundamentally different ways to estimate – top-down and bottom-up.
In the top-down approach, high-level estimates are created. These estimates can be +/- 50% in terms of the
accuracy level. There are three commonly used techniques for top-down estimating:

1. Apportion method – reviewing actual durations from similar projects and applying the same proportions
to the current project.
2. Expert judgement – settling on a high-level estimate for overall project duration based on input from
experts who have previously participated in similar projects.
3. Ratio method – identifying and applying significant determining factor(s) to estimate the project’s overall
duration.

◦ For instance, a website development project could estimate the project duration based on the
number of web pages to be developed and the approximate time to be spent per page. Assume the
project is the development of a 20-page website and it is determined that one webpage takes five
days to create; the estimated project duration would be 100 days.

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

64 | 5. Project Planning
 Exhibit 5.2: Apportion method
Top-down estimating is simple and inexpensive. Because of this, it is often used at the project selection stage
and for small internal projects.
In contrast, bottom-up estimating is a technique that estimates project duration at the task level.
Once activity resource estimating is complete, it is possible to estimate how long each task will take. With this
approach, estimating the duration of a task is based on the information available about that specific task and
the resources that have been assigned to it.
Bottom-up estimating occurs when accuracy is a higher priority, for example, if project stakeholders have an
inflexible launch deadline. This approach takes a considerable amount of time to perform and tends to produce
estimates that are +/- 30% accurate.
Some of the common methods for creating a bottom-up estimate of project duration include:

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

The unit of duration is typically working days but could include other units of time, such as hours, weeks, or
months. The unit is chosen by understanding the level of detail needed to effectively manage the complexity of
the project and must be used consistently throughout the schedule.
It is imperative to distinguish between effort and duration. Effort is the time required to complete a task.
It only includes the time spent on the task. Wait time, often associated with the time it takes to receive an
approval, is part of duration but not effort. For instance, it may take John two hours to put his clothes in boxes,
but his friends may not be able to assist him with moving these boxes to a central room for loading until the
following day. Assuming it takes his friends 15 minutes to move his boxes to the central location, the duration
of “pack bedroom” is two days while the effort is two hours and 15 minutes. Duration is used for scheduling
purposes. Effort is used for budgeting in order to track labour costs.
A final consideration is the factors that impact estimate accuracy. In top-down estimating, the estimates
are inaccurate and this is appropriate for the circumstances. In bottom-up estimating, an attempt is made to
produce an accurate estimate, but a number of factors can impede this. Clifford Gray and Erik Larson (2021)2
identified seven factors that impact estimate accuracy. They are:

1. Planning horizon – tasks to be completed in the distant future are more difficult to estimate accurately as
the future can be very unpredictable.
2. Project complexity – the more complex the work, the harder it is to create accurate estimates.
3. People – the skill and experience levels of the people creating the estimates will have a big impact on
estimate accuracy.

1. If the individuals involved have skills and experiences from similar past projects, they are likely to
produce estimates with a higher degree of accuracy.
4. Project structure – dedicated team structures tend to produce the most accurate estimates, assuming the
team members have the required skills and experience.

◦ Since project team members in functional environments must balance the needs of the project and

5. Project Planning | 65
 their day-to-day work, it often is more difficult to find the time and focus required to produce accurate
estimates.

5. Human tendency to pad – it is human nature to overestimate time and costs in order to increase the
likelihood of being successful. If this is common practice throughout the organization, estimate quality will
suffer as a result of actual duration and cost being significantly overstated by team members.

◦ A better approach is to add contingencies at the project level and base these contingencies on the
degree of risk associated with the change initiative.

6. Organizational culture – the value placed on accuracy has a big impact on the level of accuracy provided.

◦ In some cultures, accuracy is not viewed as worthwhile (causing estimates to be high-level) and in
others, it is seen as an important way of doing business (causing estimates to be meticulously
calculated).

7. Other non-specific project factors – many factors are difficult to estimate. For instance, equipment
downtime and staff illness are generally not very predictable. Vacation periods are generally more
predictable and should be considered for duration estimates.

Resource Allocation and Calendars

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

66 | 5. Project Planning
 Exhibit 5.3: An example of a resource calendar for John’s move.

Resource Leveling

Resource levelling is a tool for examining the unbalanced use of resources (usually people or equipment) over
time and resolving over-allocations and/or conflicts.
When performing project planning activities, the project leader will attempt to schedule certain tasks
simultaneously. When resources, such as people or equipment, are needed more than they are available, or
perhaps a specific person is necessary for numerous tasks, the tasks will have to be rescheduled sequentially
to manage the resource constraint. Resource levelling can also be used to balance the workload of primary
resources over the course of the project. When this occurs, it often impacts the project’s overall timeline,
budget, and/or scope (the triple constraints).
When using specially designed project software, such as MS Project, levelling typically means resolving
conflicts or over-allocation in the project schedule by allowing the software to automatically schedule the to-
be-completed tasks as resources become available. Project management software levelling requires tasks to be
delayed until the necessary resources are made available. In more complex environments, resources may be
allocated across multiple, concurrent projects, thus requiring the process of resource levelling to be performed
at the company level. Resource levelling could result in a later project completion date if the tasks affected are
on the critical path.

5. Project Planning | 67
Task Sequencing

It is important to determine the relationship of an activity to other activities. Sometimes, certain activities must
begin before others can commence. Understanding the order in which activities need to be completed is an
important step in building a realistic schedule. Sequencing involves determining the predecessors (activities
that come before) and successors (the activities that come after). These terms describe a relationship similar to
a family relationship, such as a parent and child. The parent exists in time before the child. However, oftentimes,
a schedule has much more complex predecessor-successor relationships, just like families are composed of
several generations. Additionally, activities can have more than one predecessor, just like a child may have a
parent and a step-parent.
The relationship between a predecessor activity and a successor activity is called a dependency. Since the
successor activity starts after, it is dependent on the predecessor activity. In the context of our case study, since
a conversation with Dion and Carlita must take place before a meeting can be scheduled, the meeting has
a natural dependency on it because it can only occur once the predecessor has been completed. Activities
with predecessor-successor relationships occur sequentially—one after the other. Another term for this type of
relationship is finish-start, which means the first activity must finish before the next one can start.
Some activities take place concurrently—at the same time. Concurrent activities must be scheduled to start
or finish at the same time depending on their nature. If they must start at the same time, they have a start-
start relationship. If the activities can start at different times but they must finish at the same time, they have a
finish-finish relationship.

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

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

Sequencing for John’s Move

In our case study of John’s move, “Contacting Dion and Carlita” (Activity 1.1) comes before the
lunch meeting is scheduled. You must logically contact Dion and Carlita before you schedule

68 | 5. Project Planning
“Planning Lunch” (Activity 1.2). As a reminder, all activities that begin with the same number (e.g. 1)
are part of the same major deliverable (e.g. “Plan Move”). Your conversation with Dion and Carlita will
provide you with their availability and confirm their commitment to helping John move. Therefore,
the conversation with Dion and Carlita is a predecessor to the Planning Lunch. This relationship is
diagramed below.

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

Predecessor Relationships in John’s Move

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

Outline of Activities in John’s Move with Predecessors Identified

1. Plan Move

• 1.1 Contact Dion and Carlita

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

2. Pre-packing

5. Project Planning | 69
 • 2.1 Gather packing material
• 2.2 Select moving van company and sign contract

◦ 2.2.1 Contact three moving van companies and get bids (1.3)
◦ 2.2.2 Select company and negotiate a final price (2.2.1)
◦ 2.2.3 Sign moving contract (2.2.2)

• 2.3 Pack small delicate items (2.1)

Network Diagrams

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

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

Lag and Lead Times

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

70 | 5. Project Planning
 Exhibit 5.7: The time required to allow the concrete to rest before further construction can begin is
considered to be lag time.
In some cases, the successor task can overlap the end of its predecessor task and begin before the
predecessor is finished. This is called lead time.

Lead Time in John’s Move

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

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

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

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

Exhibit 5.9: Table of attributes (accessible version)

Milestones

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

Milestones in John’s Move

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

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

Graphic Representations: Gantt Charts

Relationships between activities are easier to recognize if they are presented using graphics, such as bar charts
or a network of connected boxes.
The type of bar chart used to illustrate task relationships is the Gantt chart. The Gantt chart was developed by
Henry Gantt and has been used on major projects, including building the Hoover Dam and the U.S. interstate
highway system. The Gantt chart, also called a bar chart, is a time-scaled graphic representing each task with a
bar that reflects its duration, start, and finish time, as was also shown in Exhibit 5.3.

Critical Path and Float

The critical path is the longest series of activities that results in the earliest completion date of the project,
phase, or iteration. In order to identify the critical path, the duration of each activity must be calculated.
If any activity on the critical path is delayed, the completion date of the project, phase, or iteration will be
delayed by an equal amount. It is important to note that the critical path contains the tasks with the greatest
total duration and the least amount of slack. To determine the critical path, add the duration of each successor

5. Project Planning | 73
activity to the duration of the previous activity to determine which series of activities has the longest total
duration, as shown below in Exhibit 5.10. In this example, durations are indicated in days (d) and tasks on the
critical path appear in red. The critical path through these tasks will take at least eight days. Notice the project
duration in the Gantt chart depicted above is also eight days as it is driven by the critical path.

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

When the team has identified the project’s critical path, they can carefully monitor the tasks that, if
individually delayed, could lead to delays in the project’s completion date. These tasks will receive the needed
resources and support to ensure they stay on track as much as possible due to their role within the critical path.
Float, sometimes called slack, is the amount of time a task, network path, or phase/iteration/project can be
delayed from the early start without changing the completion date of its successor task(s) or phase/iteration/
project.

Total Float

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

Total Float in John’s Move

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

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

Ongoing Schedule Management

As previously mentioned, the schedule should be approved and signed off by key stakeholders. The functional
managers who have been asked to provide subject matter experts to participate in the project are particularly
important. Giving functional managers the project schedule ensures that they have read the schedule,
understand the dates and resource commitments, and will be supportive of the project’s resource needs.
The schedule cannot be finalized until the project leader receives approval and commitment for the resource
assignments outlined in it. Once the schedule is approved, it becomes the baseline for the remainder of the
project, phase, or iteration. Progress and task completion will be monitored and tracked against the project
schedule to determine if the project as a whole is staying on course as planned.
Another key aspect of ongoing schedule management and monitoring is duration estimates. Baseline
schedules often change after they have been approved. Successful project leaders understand that estimates
are just that – estimates. As new information and real experience occur, it may be necessary to revise an
estimate. In some cases, the revision is minor and does not impact the achievement of any of the milestones
or the project’s completion date. In other instances, the necessary revisions may be significant, leading to the
calculation of a new baseline. It is important for project leaders to discuss the ongoing schedule management
with key stakeholders to understand their expectations of when/how they want to be informed of any necessary
changes. Very higher-complexity projects may document stakeholders’ expectations for ongoing schedule

5. Project Planning | 75
management in a formal schedule management plan. On lower-complexity projects, stakeholder expectations
regarding schedule communication can be documented in the stakeholder register.
There are two key schedule compression techniques that can be used when teams discover they are running
behind schedule. One technique is called crashing. This involves adding more resources to critical path tasks or
reassigning resources from non-critical path tasks as a way to create more focus on critical path tasks. The goal
is to realign the schedule with commitments and stakeholder expectations. Crashing can be very expensive
and it does not always work. If the budget is limited, this is not an effective technique.
The other technique is called fast-tracking. Sometimes the project team realizes that two tasks, which were
originally planned to occur sequentially (e.g., finish-start), can occur concurrently (e.g. start-start, finish-finish).
However, this can be risky to implement as there is a possibility that some of the work will have to be redone if
issues are discovered. These issues may have been easily identifiable if the tasks occurred sequentially as initially
planned.

5.5 Cost Management

One of the components of project success is completing the project within budget. Developing and controlling
a project budget that will accomplish the project objectives is a critical project management skill. Although
stakeholders expect the project to be executed efficiently, pressures to remain within budget vary based on the
unique constraints and priorities of the project. On some projects, the project completion date is the highest
priority leading to a more flexible budget to accommodate the inflexible deadline. Moreover, the project’s scope
may have to be scaled back if it is too ambitious to finish in time. On other projects, for example, ones with
limited funding available, remaining within budget is the highest priority. When this is the case, effective cost
management is imperative and trade-offs with scope, quality, and/or time may be required.
During the project selection phase, the information needed to develop an accurate and detailed budget is
often unknown. As a result, a rough order of magnitude (ROM) is developed using the information available at
the time. Expert knowledge and/or past experience are often used to develop the ROM estimate. When using
past experience, estimates from previous projects are often scaled to match the size and complexity of the
current project. Although the ROM is not accurate due to insufficient information, it does help the organization
determine if the project should be approved.
During the initiation phase, more information may be available, allowing the newly assigned project leader
to refine the ROM from the previous phase. In some instances, however, the project’s end solution cannot be
clearly defined at this point and, therefore, the cost estimates remain vaguely defined.
As the project moves into the planning phase, the development methodology is selected and this determines
how the project budget is created. When the solution cannot be clearly defined upfront, this often leads to the
use of an adaptive development methodology, such as agile, which accepts a loosely defined ROM since the
focus is on the cost of the iterations (sprints) as a way of refining the total cost of the entire project. Additionally,
it takes time to fully understand the end users’ expectations, so project leaders are often careful to not commit
to a project budget until more is known about the end solution. Project leaders also must ensure that the
budget is developed collaboratively with the product owner(s) and the scrum master(s). The cost estimates
for the product backlog are ultimately integrated with the cost of each iteration, leading to the creation of a
detailed project budget. As previously mentioned, when the predictive (waterfall) development methodology
is used, the project’s end outcome is clear and can be defined upfront. The outcome can be broken down into
smaller work packages. Then, the work package leaders estimate the cost of their work. Lastly, the cost of all
work packages is integrated to create the detailed project budget.
Once the project cost has been estimated, the actual cost of executing the required work is tracked and
compared to the approved estimates. This tracking is done during the monitoring and control phase of the

76 | 5. Project Planning
project (covered in Chapter 7). If the actual costs are significantly higher or lower, the project team explores
reasons for the difference and takes appropriate action to successfully manage future costs.
Project costs may deviate from the approved estimate for various reasons. For instance, the actual price
for materials in the marketplace may differ from what was expected. Project costs may also deviate based
on project performance. In particular, more materials may be required to complete the work than what was
expected. Additionally, the effort required may be different than initially estimated. When trends emerge
indicating variance between actual versus planned project costs (due to consistent over- or underestimating),
future estimates are revised and corrective action may be required.
Effective project leaders understand the importance of revising cost estimates as new information becomes
available. Analytical skills are helpful in this regard as the project leader is routinely assessing the overall impact
of modified project costs on the project’s objectives. Stakeholders expect to be kept informed of significant
changes. Most organizations require project leaders to obtain approval for changes to the existing project
estimates. In very large complex projects, a cost management plan, which identifies who will provide approval,
will be created through conversation with the appropriate stakeholders. The project leader will use this plan to
guide their efforts around when and how to communicate changes to project costs. Approval thresholds are
typically established. For instance, the project leader may proceed with changes at their own discretion if the
changes are not greater than 2% of the overall budget, while project sponsor approval would be required if the
changes are beyond this threshold.

Types of Project Costs

There are generally three different types of project costs:

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

The primary difference between these costs is how closely related they are to the specific activities of the
project.
Direct costs are, as the name implies, directly related to specific project tasks. These costs represent the
labour, time, and materials associated with specific tasks.
Direct overhead costs are incurred as a result of the project’s existence, but they are not directly related to
specific tasks. These costs represent the compensation paid to individuals who are supporting the project in its
entirety, such as the project leader and their support staff (project analysts, coordinators, etc.). These costs also
represent materials, facilities, and related equipment that were purchased to support the project in general. The
rental and maintenance of workspace for the project team members, as well as their computers and related
information technology, supplies, and lunch (if provided), are all examples of direct overhead costs.
Lastly, general administrative costs are indirectly related to a project and they are incurred even if the
project is not carried out. Examples of this type of cost include marketing, human resources, and accounting
department-related expenses. These departments may provide ad-hoc and minimal support to the project
teams and as a result, the project sponsors may want a portion of their costs to be allocated to all projects
underway in the organization. Allocating a portion of the costs to the project provides the executive with a full
picture of all costs incurred due to the implementation of strategic change initiatives in the organization. Since
the allocation methods are often very subjective, many organizations exclude general administrative costs from
the project budget. The time it takes to come to a consensus about the proposed subjective estimates may not
be worth the benefit they provide in terms of organizational and project-related decision-making.
It is important to note that some projects require the direct involvement of these administrative functions.

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

Estimation Techniques

There are two fundamentally different ways to estimate – top-down and bottom-up.
In the top-down approach, high-level estimates are created. These estimates can be +/- 50% in terms of the
accuracy level. There are three commonly used techniques for top-down estimating:

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

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

Exhibit 5.12: Ratio Method

Top-down estimating is simple and inexpensive. It is often used at the project selection stage and for small
internal projects.
In contrast, bottom-up estimating is a technique that is used when accuracy is valued. This is especially the
case when project stakeholders place a high priority on the project cost. In these instances, the project may

78 | 5. Project Planning
have a fixed budget. This approach takes a considerable amount of time to perform and tends to produce
estimates that are +/- 30% accurate.
Some of the common methods for creating a bottom-up estimate of project duration include:

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

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

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

There are two types of reserves:

• Contingency reserves are funds set aside to manage the identified risks. Because there is a chance that
these funds will be required, the contingency reserve is incorporated into the project budget. If this fund is
adequate to meet the project’s unplanned expenses, then the project will be complete within the budget.
• Management reserves are funds set aside to manage situations that are not anticipated. These situations
can be positive and negative. An example of a positive situation is the discovery of new technology that
will revolutionize the way the project objectives are achieved. The necessary funds can be made available

5. Project Planning | 79
 to take advantage of this opportunity at the project sponsor’s discretion. If such an opportunity were
pursued, it would result in a significant change in the project’s scope, especially if the predictive/waterfall
development methodology was used. Unlike contingency reserves, management reserves are unlikely to
be spent and are not part of the project’s cost baseline. However, they may be included in the funding
made available to the project.

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

Apportion Estimate for John’s move

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

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

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

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

Parametric Estimate for John’s move

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

80 | 5. Project Planning
parameters, such as the quality of finishes, are used to further refine the estimate. Parametric
estimates are calculated by multiplying measured parameters by cost-per-unit values.

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

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

Bottom-up estimate for John’s move

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

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

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

5. Project Planning | 81
 Category Description Activity Quantity Unit Price Cost

Packing Materials Small Boxes 2.1 10 $1.70 $17.00

Packing Materials Medium Boxes 2.1 15 $2.35 $35.25

Packing Materials Large Boxes 2.1 7 $3.00 $21.00

Packing Materials Extra-Large Boxes 2.1 7 $3.75 $26.25

Packing Materials Short-Hanger Boxes 2.1 3 $7.95 $23.85

Packing Materials Box Tape 2.1 2 $3.85 $7.70

Packing Materials Markers 2.1 2 $1.50 $3.00

Packing Materials Mattress/Spring Bags 2.1 2 $2.95 $5.90

Packing Materials Life Straps per Pair 2.1 1 $24.95 $24.95

Packing Materials Bubble Wrap 2.1 1 $19.95 $19.95

Packing Materials Furniture Pads 2.1 4 $7.95 $31.80

Truck Rental 2.2 – – $400.00

Truck Gas at 10mpg 2.2 200 $2.25 $45.00

Total Cost $661.25

Exhibit 5.15: Bottom-up cost estimates

Cost Budgeting

The main goal of the cost budgeting process is to produce a cost baseline. This baseline is a time-phased
budget that can be used to measure and monitor cost performance after it has been approved by the key
project stakeholders. The aggregated budget is integrated with the project schedule in order to produce the
time-phased budget. Costs are associated with tasks, and since each task has a start date and a duration period,
it is possible to calculate how much money will be spent by any particular date during the project. Recognizing
that all the money required to deliver the project is not needed upfront, allows the cash flow needs of the
project to be effectively managed. For smaller organizations facing cash flow challenges, this can result in
significant savings as the money required to pay for resources can be transferred to the project account shortly
before it is needed. These transfers must be timed so that the money is there to pay for each task without
causing a delay in the start of the task. If the money is transferred too far in advance, the organization will lose
the opportunity to use the money somewhere else, or they will have to pay unnecessary interest charges if the
money is borrowed.

Managing the Budget

A key aspect of ongoing cost management is monitoring cost estimates. Baseline budgets often change after
they have been approved. Successful project leaders understand that estimates are just that, estimates. As new

82 | 5. Project Planning
information and real experience occur, it may be necessary to revise an estimate. In some cases, the revision
is minor and does not impact the achievement of the project’s total budget. In other instances, the necessary
revisions are significant and a new baseline needs to be created. It is important for Project leaders to discuss the
ongoing management of the schedule with key stakeholders to understand their expectations of when/how
they are informed of changes that need to be made. Very large complex projects may document stakeholders’
expectations for ongoing cost management in a formal Cost Management Plan. In addition, there are a number
of tools and techniques that help project leaders monitor and control project budgets.

5.6 Risk and Issue Management

Risks are the uncertainties that exist in all projects. A risk can be positive or negative. Some uncertainties, such
as the potential of finding an easier way to do a task and/or lower prices for certain materials, can make it
easier to achieve a project’s objectives. When this type of uncertain happens, the risk is positive and is therefore
referred to as an opportunity. Examples of negative risks are the potential for technology to fail and/or a vendor
missing an important delivery.
The role of the project management team is to understand the types and severity of risks on the project, and
then develop and implement plans in response to these risks. The type and severity of risk vary by industry,
project complexity, and project phase. The human tolerance for risk varies significantly from one person or
organization to another. Due to this, it can be difficult for project team members to reach a consensus on
the riskiness of an activity and overall project. Understanding the risk tolerance of a project’s stakeholders is a
critical success factor in risk management.
There are four steps in risk management:

1. Identifying the uncertainties. Some uncertainties are easy to identify, such as the potential for a
damaging storm in the Caribbean, while others are less obvious, such as the potential for a project team to
experience poor health. Many industries or companies have risk checklists developed from past
experience. The value of a checklist is the stimulation of discussion and thought among team members
about the potential risks of a particular project.
2. Assessing each identified risk by estimating its likelihood (probability of occurrence) and impact on
project goals.. The outcome from this process is a prioritized list of project risks with values (e.g. high,
medium, low) that represent the likelihood and potential impact. The probability/impact matrix is a key
tool in risk assessment.
3. Developing risk responses, such as accepting the risk (do nothing to prevent it from happening),
eliminating it (change something in the project to avoid its occurrence), transferring it (to a third party by
purchasing insurance), or mitigating it (reduce its likelihood and/or impact).
4. Implementing and monitoring the response. After selecting the appropriate response for a particular risk,
the project team must balance the cost of the response against the anticipated benefit for the project.
Monitoring is important because new risks emerge and understanding the effectiveness of implemented
risk response strategies ensures project risks are effectively managed throughout the project’s lifecycle.

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

Risk Management Plan

By the time a risk turns into an issue on a project, it is often too late to effectively respond to it. The risk
management plan allows the project team to reduce the likelihood of negative surprises, proactively take

5. Project Planning | 83
advantage of positive risks (opportunities), and ensure risk management is considered when schedules,
budgets, and other management plans are developed. Creating and maintaining a risk management plan
significantly increases the likelihood of project success.
The risk management plan identifies the processes and procedures to be used in managing risk throughout
the life of the project. It includes a number of key sections: risk sources, categories, assessment definitions (e.g.
very high to very low), probability/impact assessment (matrix), roles and responsibilities, budget and schedule
estimates for risk-related activities, and the risk register. The risk management plan is integrated into the
project management plan (or, in the absence of this plan, into the execution approach for the project) and the
response strategies are assigned to the appropriate individuals in the organization.
A risk register is a key tool that helps project teams keep track of the status of risks, ensure response plans are
effectively implemented, and new risks are managed. The register is often created during the initiation phase
of a project’s life and it is maintained throughout the remaining phases

Risk Identification

Since risks are uncertainties, a good place to start in identifying risks is the assumptions that have been made
in the project justification document and project charter. Project teams hope the proposed assumptions will
materialize, but this is not certain. Often, these assumptions represent significant risks.
Another important method for identifying project risks is the project team itself. The individuals responsible
for specific components of the work are in the best position to identify the risks and opportunities associated
with the task(s). Risk management should be a standing agenda item during project status meetings
The third source of risk is risk checklists developed from past projects. These checklists can be helpful to
the project team in identifying specific risks on the checklist and expanding the thinking of the team. Some
industries publish their own risk management checklists that, when feasible, should be utilized. Checklists are
often organized by risk category. The categories themselves can add helpful insights during brainstorming
sessions. Examples of common risk categories include:

• Technical (related to technology and equipment)

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

Notice that the categories are broad. Successful project delivery is a multi-disciplinary approach.
Risks can also be categorized according to the deliverables of the work breakdown structure (WBS). This is
commonly referred to as a risk breakdown structure (RBS).

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

Task Risk

• Dion backs out

• Carlita backs out
Contact Dion and Carlita
• No common date available

• Restaurant full or closed

• Wring choice of ethnic food
Host planning lunch
• Dion or Carlita may have food allergies or
preferences

• Printer out of toner

Develop and distribute schedule
• Out of paper

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

Risk Assessment

After the potential risks have been identified, the project team evaluates each risk based on the probability that
the risk event will occur and the potential impact (cost/benefit) associated with it. Not all risks are equal. Some
risk events are more likely to happen than others and the cost/benefit of a risk can vary greatly. Risk assessment
often occurs in a workshop setting.
Having criteria to determine high-impact risks can help narrow the focus on a few critical risks that require
responses. For example, suppose high-impact risks are those that could increase the project costs by 5% or
more. Similarly, high-probability risk events are those that carry a likelihood of occurrence of 50% or more. Only
a few potential risk events are likely to be high-impact and high-probability. These risks become the “critical
few” and, therefore, promptly identifying the risks within this category is helpful in deciding early on where the
funds and time should be allocated for risk-related activities. See Exhibit 5.16.

5. Project Planning | 85
 Exhibit 5.16: Risk and impact matrix
Project Management from Simple to Complex

There is a positive correlation between project complexity and project risk. This means that both variables
increase or decrease together. A project with new and emerging technology will have a high complexity rating
and a correspondingly high project risk. The project management team will assign the appropriate resources to
the technology managers to ensure the accomplishment of project goals. The more complex the technology,
the more resources the technology manager typically needs to meet project goals, and each of those resources
could face unexpected problems.
On projects with a low-complexity profile, the project leader may informally track items with risk potential.
On more complex projects, the project management team may develop a list of items perceived to be higher
risk and track them during project reviews. On projects of even greater complexity, the process for evaluating
risk is more formal with risk assessment meetings occurring throughout the project’s lifecycle to assess relevant
risks during different project phases. On highly complex projects, an outside expert may be included in the
risk assessment process, leading to the risk assessment plan taking a more prominent place in the project
implementation plan. In addition, statistical models are sometimes used to evaluate risk because there may be
too many possible combinations of risks to calculate them one at a time. One example of the statistical model
used on highly complex projects is the Monte Carlo simulation, which simulates a possible range of outcomes

86 | 5. Project Planning
by evaluating many different combinations of risks based on their likelihood. The output from a Monte Carlo
simulation provides the project team with the probability of a risk event successively occurring with other
combinations of risk events. For example, the typical output from a Monte Carlo simulation may indicate a 10%
chance that a key piece of equipment will be late and that the weather will be unusually bad upon equipment
arrival.

Risk Responses

…To Negative Risks

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

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

Each of these responses can be an effective tool in reducing individual risks as well as the overall risk profile of
the project. The risk response plan captures the risk management approach for each identified risk event and
actions the project management team will take to manage the risk.
Risk avoidance usually involves developing an alternative strategy with a higher probability of success, but,
usually, the associated cost of task completion also becomes higher. A common risk avoidance technique is
using proven and existing technologies rather than adopting new techniques, even though the new techniques
may show promise of better performance and/or lower costs. A project team may choose a vendor with a
proven track record over a new vendor that is providing significant price incentives to avoid the risk of working
with a new vendor. Alternatively, a project team that requires drug testing for team members is practicing risk
avoidance by attempting to evade damage done by someone under the influence.
Risk mitigation is a response to a risk that cannot be avoided or if it is unwise to avoid it (due to risk avoidance
strategies being too expensive, too time-consuming, etc.). In this case, the project team is attempting to reduce
the likelihood and impact of a risk. For instance, assigning highly skilled resources to an activity reduces the
likelihood and impact of errors occurring.
Risk transfer is a risk reduction method that shifts the risk from the project to another party. The purchase
of insurance on certain items is a risk-transfer method. The risk is transferred from the project to the insurance
company. A construction project in the Caribbean may purchase hurricane insurance that would cover the cost
of a hurricane damaging the construction site. The purchase of insurance is usually connected to risks that can
significantly impact the project while being out of the project team’s control, such as weather, political unrest,
and labour strikes.
Risk acceptance involves doing nothing in response to the risk. The acceptance response is a good one when
the likelihood and impact of a risk are low. In some cases, little else can be done about the risk, leading to
acceptance being the only feasible option. When this response is chosen, many project leaders have developed
a strategy to deal with the risk if it does materialize. This often involves setting aside funds (contingency
reserves) in the project budget.

5. Project Planning | 87
…To Positive Risks

As previously mentioned, positive risks (opportunities) are uncertainties that, if materialized, will have a positive
impact on the project. Project teams have other alternatives to deal with opportunities:
Risk-sharing involves partnering with others to share responsibility for the risk. Partnering with another
company to share the risk associated with a portion of the project is advantageous when the other company
has the expertise and experience that the project team lacks. This increases the likelihood of the opportunity
materializing and, if it does, both organizations share the gains.
Risk exploitation attempts to eliminate the uncertainty and ensure the occurrence of the opportunity. An
example of this could be pursuing a bonus that is available only if an activity is completed early. In this case, the
project team will reallocate resources in order to ensure the activity finishes early and the bonus is obtained.
Risk enhancement attempts to increase the probability of the opportunity materializing but it does not seek
to ensure its occurrence. This requires less investment than the exploitation response and is appropriate when
the positive impact is not as great.
Risk acceptance involves doing nothing in response to the risk. This acceptance response is a good one when
the likelihood and impact of a risk is low.

Project Risk by Phases

Another effective way to manage risks is to consider the project lifecycle. Risk management techniques can
vary by project phase. In the simplest of terms, the initiation phase usually involves simply assessing overall
project risk by identifying the key risks. During the planning phase, the team is able to identify, assess, and
respond to many more risks. During the implementation phase, previously identified response strategies
require modification if they have been deemed ineffective or significant new risks emerge. During the closure
stage, contractual arrangements related to risk management are terminated and risk management
documentation is updated.
Let us look at the core principles of risk management using our case study. We will examine these principles
from a phase-by-phase approach

Initiation

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

Risk Identification by Phase in John’s Move

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

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

88 | 5. Project Planning
 1 His new employer might change his mind and take back the job offer after John
LOW
. has given notice at his old job

2 The current tenants of his new apartment might not move out in time for John to MEDI
. move in by the first day of work at his new job UM

3
The movers might lose his furniture LOW
.

4 MEDI
The movers might be more than a week late delivering his furniture
. UM
5 He might get in an accident driving from Chicago to Atlanta and miss his first day
LOW
. of work

John then considers appropriate responses for each of the risks.

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

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

5. Project Planning | 89
Planning Phase

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

Risk Identification in John’s Move

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

Legend:

• RA: Risk avoidance

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

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

90 | 5. Project Planning
Implementation, and Monitoring and Control Phases

As more information becomes available to the team and tasks are performed without loss, the overall project
risk typically reduces. As the project progresses, the risk management plan must be updated with new
information and risks related to the completed tasks must be checked off.
As the project’s progress is monitored, the need to make changes may arise. Sometimes, these changes
occur as a result of risk management strategies that have been pursued in response to newly identified risks.
For instance, in order to avoid a failed move when John discovers his rental van is not big enough to carry all
his possessions, he could decide to immediately sell or give away some of his furniture, thereby reducing the
scope/complexity of his move. In some situations, the project timeline may need to be extended or the project
budget may need to be increased (or the timeline/budget may need to be reduced if an opportunity has been
discovered!).
Understanding where or when risks occur in a project is important information for managing the project’s
contingency funds. Most organizations develop a plan for financing the project from the existing organizational
resources, including financing the project through a variety of financial instruments. In most cases, there is a
cost to the organization to keep these funds, including the contingency budget, available to the project. As the
risks decrease over the length of the project, if the contingency is not been used, then the funds set aside by
the organization can be allocated for other purposes.

Closing Phase

During the closing phase, agreements for risk-sharing and risk transfer must be concluded and the risk
management plan must be examined to ensure all the risk events have been effectively managed. If a risk
register was used to track risks and their respective response strategies, a final update should be composed
in order to ensure the register can be shared with and easily understood by future project teams in order to
improve their likelihood of success. Similarly, identifying how much of the contingency funds were required is
an important project closure step. This allows future teams to understand how much funds they may have to
set aside to manage similar risks on their projects. Lastly, if a Monte Carlo simulation was done, the predicted
result can be compared to the realized result.

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

5. Project Planning | 91
 Exhibit 5.18: Table denoting closeout activities associated with risk response strategies (accessible
version)

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

Contingency Plan

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

5.7 Procurement management

The procurement effort on projects varies widely and depends on the type of project. The “procurement cycle”
reflects all procurement-related activities from when the decision is made to outsource equipment all the way
through to the payment of bills and closing of procurement contracts.
A note about terminology: this text will be using the terms suppliers and vendors interchangeably.
In less complex projects, the project team performs the work associated with procurement management.
This includes:

• Identifying the required materials, equipment, and supplies

• Identifying the potential vendors
• Preparing requests for quotes (RFQs) and requests for proposals (RFPs), which include product/service

92 | 5. Project Planning
 specifications and a detailed delivery schedule
• Evaluating RFQs and RFPs to select the most suitable vendors
• Awarding and signing contracts
• Administering the contract and monitoring vendors’ performance
• Managing contract changes
• Closing out the contract upon work completion

On more complex projects, procurement professionals may be assigned to assist the team throughout the
project’s lifetime.
Procurement management follows a logical order. First, determine what the project needs to contract; then
plan to do it. Next, send out contract requirements (solution specifications and timeline requirements) to
potential vendors. These vendors bid for the chance to work on the project. The project team selects the best
vendor and then signs a contract to formalize acceptance of the terms. Once the work begins, the supplier’s
performance is monitored to make sure that the contract is being followed. When the work is done, the contract
is closed out.
It is important to start with the plan for the whole project. Before doing anything else, consider all of the work
that needs to be contracted out for the project. Ensure the project’s needs are closely examined to confirm if
contracting is even necessary.
A procurement management plan is used in projects with high complexity as it details how the procurement
process will be managed. It includes the following information:

• Roles and responsibilities of the project team and procurement professionals

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

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

5. Project Planning | 93
Lease-or-Buy Analysis

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

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

A simple example will help illustrate how this analysis is performed. Let us assume a project team needs a
3-D printer. The printer would cost about $15,000 to purchase and require about $200 per month to maintain.
Alternatively, the project could lease the printer for $600 a month. The monthly lease rate includes all associated
expenses like maintenance.
The first step is to determine when the cost to buy becomes equal to the cost to lease. This can be expressed
mathematically as follows:
Cost to lease = Cost to purchase
Assume M is the number of months.
$600 x M = $15,000 + ($200 x M)
($600 – $200) x M = $15,000
$400 x M = $15,000
M = $15,000 ÷ $400 = 37.5
If the project is considerably longer than 37.5 months, it makes sense to buy the equipment. The organization
could choose to reassign the printer to future projects or sell it using a very low-cost online alternative.
Conversely, if the project is considerably less than 37.5 months, it makes more sense to lease the equipment. If
the project’s duration is very close to 37.5 months, this becomes a judgement call and the project leader may
wish to consult with others in the organization to determine if there is a need for this type of equipment in other
areas.
After the analysis is complete, the project team will be able to determine the nature of the contractual
relationship needed with a vendor. It is then time to identify potential vendors. Once the potential vendors have
been identified, the project team will move on to bid solicitation. Once the bids come in, they are evaluated.
Once the successful vendor has been selected, a contract is awarded. Let us look at each of these steps more
closely.

Qualifying Bidders

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

94 | 5. Project Planning
quality specifications and the project schedule. During times when economic activity is high in a region, many
suppliers become busy and stretch their resources. Before they are included on the bidder’s list, the project
team investigates the potential suppliers to ensure that they have the capacity and track record to meet
deadlines and quality expectations.
The potential supplier must also be financially stable to be included on the bidder’s list. A credit check or a
financial report from a reputable credit rating agency (e.g. Dun and Bradstreet, Equifax) will provide the project
team with information about the potential bidder’s financial status.

Solicitation

A solicitation is the process of requesting a price and supporting information from bidders. The solicitation
usually takes the form of either a request for quotation (RFQ) or a request for proposal (RFP).
An RFQ focuses on price. The product, service, and/or materials are well-defined and can be obtained from
several sources. The bidder that can meet the project quality and schedule requirements usually wins the
contract by quoting the lowest price.
An RFP is issued when the project team does not know the required solution. The RFP is intended to solicit
ideas on how to fulfill the project’s objective with specific solutions. This approach is used in projects utilizing
the predictive (waterfall) and adaptive (agile) methodology. For instance, consider a project with the objective
of streamlining a service process. The project will involve the introduction of a new service request application.
In addition, since the existing desktop computers are too old to run the new application, the project team
must upgrade all desktop computers. Since the project team does not know which desktop computer is most
appropriate, they issue an RPP to three companies. This project could be following a predictive or an adaptive
methodology. The key is that the project team needed assistance in defining an aspect of the full solution.
The RFP considers price, but it is more focused on meeting the project’s objective by selecting the appropriate
solution. If several vendors have submitted proposals that successfully illustrate how they would be able to
support the project’s objective, price can become one of the deciding factors. The process of developing a
proposal in response to an RFP can be very time-consuming and expensive for the bidder, and the project team
should not issue an RFP to a company that is not eligible to win the bid.
A final consideration is logistics. Equipment and materials that are purchased for use on the project must be
transported, inventoried, warehoused, and often secured. This area of expertise is called logistics. The logistics
for the project can be managed in many different ways. It can be managed within the project team if they have
the needed expertise and access to the required facilities. On larger, more complex projects, a member of the
organization’s procurement department may assume accountability for logistics. Lastly, if the organization does
not have the required skills and facilities, it will be managed externally, and potentially part of the RFP or RFQ
process.

Evaluating Bids

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

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

Awarding the Contract

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

Contract Types

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

Fixed-Price Contracts

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

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

The fixed-price contract is a legal agreement between a client (the organization leading the project) and a
vendor (person or company) that will provide goods or services for the project at an agreed-on price. The vendor
is responsible for incorporating all costs, including profit, into the agreed-on price. The vendor also assumes the
risks for unexpected increases in labour and materials that are needed to provide the service or materials and,
in the materials, and timeliness needed.
The contract usually details the quality of the goods or services, timing needed to support the project, and
price for delivering goods or services. There are several variations of the fixed-price contract. For commodities,
goods, and services where the scope of work is very clear and unlikely to change, the fixed-price contract offers
a predictable cost. The responsibility for managing the work to meet the needs of the project is focused on the
vendor. The project team tracks the quality and schedule progress to ensure the vendor(s) will meet the project
needs. Contracts carry a degree of risk. For fixed-price contracts, the risks are the costs associated with project
change. If a change occurs on the project that requires a change order from the vendor, the price of the change
is typically very high.
Fixed-price contracts require the availability of vendors with appropriate qualifications and performance
histories to ensure that the needs of the project can be met. The other requirement is a scope of work that is
most likely not going to change. Developing a clear scope of work based on good information, creating a list
of highly qualified bidders, and developing a clear contract that reflects that scope of work is critical aspects
of a good fixed-priced contract. As a result, solutions that are developed in an iterative fashion (like agile) are
generally more challenging to manage with fixed-price contracts.
The fixed-price contract with price adjustment is used for unusually long projects that span years. The main
difference is that it considers inflation-adjusted prices. In some countries, the value of its local currency can vary
greatly in a few months, which affects the cost of local materials and labour. In periods of high inflation, the
contract price is adjusted accordingly. If the adjustment is determined upfront and included in the fixed price,
the project accepts the risk that the actual inflation rate is lower than stipulated in the contract and the vendor
runs the risk that the actual inflation is higher than stipulated. The volatility of certain commodities can also be

5. Project Planning | 97
accounted for in a price adjustment contract. For example, if the price of oil significantly affects the costs of the
project, the contract can allow for an adjustment based on a change in the price of oil.
The fixed-price contract with incentive fee provides an incentive for performing better than stipulated in the
contract. A common example is delivering ahead of schedule.
If the service or materials can be measured in standard units, but the amount needed is not known accurately,
the price per unit can be fixed—a fixed-unit-price contract. The project team assumes the responsibility of
estimating the number of units used. If the estimate is not accurate, the contract does not need to be changed,
but the project will exceed the budgeted cost.

Incentive for Meeting Predictability of

Known Milestones Cost
Type Share of Risk
Scope

Fixed total cost Very High All vendor Low Very high

Fixed unit price High Mostly project Low Medium

Fixed price with

High All vendor High Medium-high
incentive fee

Depends on how the adjustment will

Fixed fee with
High occur (before or after the trigger for Low Medium
price adjustment
adjustment arises)

Cost-Reimbursable Contracts

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

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

98 | 5. Project Planning
 In a cost-reimbursable contract, also known as cost-plus contracts, the organization agrees to pay the
vendor for the cost of performing the service or providing the goods. Cost-reimbursable contracts are most
often used when the scope of work or the costs for performing the work are not well known. The project uses a
cost-reimbursable contract to pay the contractor for allowable expenses related to performing the work. Since
the cost of the project is reimbursable, the vendor has much less risk associated with cost increases. When the
costs of the work are not well known, a cost-reimbursable contract reduces the amount of contingency the
bidders place in their bid to account for the risk associated with potential increases in costs. This type of contract
is often well-suited to projects using the agile development methodology.
This is quite different than fixed-price contracts where vendors try to include as much contingency as possible
in their bids as a way to protect their profit margin. In these types of contracts, the vendor is less motivated
to find ways to reduce the cost of the project as there is no incentive to do so – the client will reimburse
costs incurred by the vendor, even if they are unnecessarily high, as the work is completed. One way to limit
exorbitant costs imposed by vendors is to include incentives for supporting the accomplishment of project
goals.
Cost-reimbursable contracts require good documentation of the costs that occurred on the project to ensure
that the vendor receives payment for all the work performed and that the organization is not paying for
something that was not completed. The vendor is also guaranteed a profit over and above cost reimbursement.
There are several ways to compensate the vendor:

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

Cost Reimbursable (CR) Incentive for Meeting Milestones Predictability of Cost

Known Scope Share of Risk
CR with fixed fee Medium Mostly project Low Medium-high

CR with percentage fee Medium Mostly project Low Medium-high

CR with incentive fee Medium Mostly project High Medium

CR with award fee Medium Mostly project High Medium

Time and Materials Low All project Low Low

Time and Material Contracts

In a time and materials contract, the client pays a rate for the time spent working on the project and also pays

5. Project Planning | 99
for all the materials used to do the work. Exhibit 5.21 demonstrates that as costs to the client increases, so does
the profit for the vendor.

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

For project activities with a high level of uncertainty, the vendor might charge an hourly rate for labour, the
cost of materials, plus a percentage of the total costs. This type of contract is called time and materials (T&M).
Time is usually contracted on an hourly rate and the vendor would oftentimes be required to submit timesheets
and receipts for items purchased for the project. The project reimburses the vendor for the time spent at the
agreed-on rate and the actual cost of the materials. The fee, which becomes the vendor’s profit margin, is
typically a percentage of the total cost.
T&M contracts are used on projects for work that is smaller in scope and has uncertainty or risk. This is often
well suited to projects following the agile development methodology. The project, rather than the vendor,
assumes all the risk. However, this can be particularly challenging if there are no limits to the amount of effort
and materials that can be applied.
To minimize the risk to the project, the vendor typically includes a not-to-exceed amount, which means the
contract can only charge up to the agreed amount. The T&M contract allows the project to adjust the contract
as more information about the project’s end solution becomes available. The final cost of the work is not known
until sufficient information is available to complete a more accurate estimate.
Since there are numerous contract type alternatives, deciding which type is appropriate for any given project
can be challenging. The following considerations can help project teams identify the best alternative for the
project:

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

100 | 5. Project Planning

5. How important is it to be sure of the cost in advance?

Progress Payments and Change Management

Vendors usually require payments during the life of the contract. On contracts that last several months, the
vendor will incur significant costs and will want the project to pay for these costs as early as possible. Rather
than wait until the end of the contract, a schedule of payments is typically developed as part of the contract
and is connected to the completion of a defined amount of work or project milestones. These payments made
before the end of the project and based on the progress of the work are called progress payments. For example,
the contract might develop a payment schedule that pays for the design of the solution, then the development
of the solution, and then a final payment is made when the solution is completed and accepted. In this case,
there would be three payments made. There is a defined amount of work to be accomplished, a time frame for
accomplishing that work, and a quality standard the work must achieve before the vendor is paid for their work.
Just as the project has a scope of work that defines what work will be done by the project team and what
will be outsourced, vendors and suppliers have a scope of work that defines what they will produce or supply to
the company. Often changes occur on the project that require adjustments to the vendor’s scope of work. How
these changes will be managed during the life of the project is typically documented in the contract. Capturing
these changes early, documenting what changed and how the change impacted the contract, and developing
a change order (a change to the contract) is important to maintaining the progress of the project. Conflict
among team members may arise when changes are not documented or when the team cannot agree on the
change. Developing and implementing an effective change management process for vendors will minimize
this conflict and the potential negative effect on the project.

Managing the Contracts

The contract type determines the level of effort and the skills needed to manage the contract. The individual
responsible for managing the contracts develops detailed specifications and ensures compliance with these
specifications. They track the vendor’s performance against the project needs, as outlined in measurable
performance evaluation criteria, supplying support and direction when needed.
Items that take a long time to acquire—long-lead items—receive early attention from the project team. An
example of a long-lead item is equipment that must be designed and built specifically for the project. The
equipment might require weeks, months, or years to develop and complete.
Occasionally, vendors do not perform to project expectations. Some project leaders will refer to the contract
and impose penalties in an attempt to persuade the vendor to improve performance. Other project leaders
will first brainstorm ways that the vendor could improve performance and meet project requirements before
penalties are imposed. Both approaches to deal with non-performing vendors can work, and the project team
must assess what method is most likely to work in each situation.
Managing vendor performance on a project is as important to the overall project outcomes as the work
performed by the project team.

5.8 Quality Management

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

5. Project Planning | 101

 High quality is achieved by planning for it rather than by reacting to problems after they are identified.
Standards are chosen and processes are put in place to achieve those standards. Similar to the triple constraints
(scope, cost, and schedule), quality is managed on a project by setting goals and taking measurements. It is
important to understand the quality levels stakeholders believe are acceptable and ensure that the project
meets those targets.
When the project team gathers requirements for the solution, they identify all of the specifications that
stakeholders want in the product so they know how to define and measure quality. “Fitness to use” is about
making sure that the product has the best design possible to fit the customer/client’s needs. For example, you
could pound in a nail with a screwdriver, but a hammer is a better fit for the job. Conformance to requirements
is the core of both customer satisfaction and fitness to use and is a measure of how well the solution meets
expectations. Above all, the solution must fulfill the requirements established by the users.
On large complex projects, the team may decide a formal quality management plan is necessary. This plan
should be developed with key stakeholders, including the end-user community. The plan will not only identify
what the quality expectations are, but it will also identify the work required to ensure these expectations
are fulfilled. Just as the project budget and completion dates may change over the life of a project, the
project specifications may also change. The approach to managing change is dependent on the development
methodology chosen. When the requirements for the solution are being defined upfront, as is the case with the
predictive/waterfall methodology, formal change control processes are important as commitments regarding
project duration and/or project cost have likely already been established. Formally assessing changes in quality
specifications allows the team to understand the impact on the commitments. In these situations, the impacts
are communicated and approvals are sought before implementation occurs. In projects using an adaptive/
agile approach, the end solution cannot be clearly defined. The quality expectations will be defined when the
capabilities, features, and user stories are developed in cycles.
Project management organizations that execute several similar types of projects may find process
improvement tools useful in identifying and improving the baseline processes used on their projects. Process
improvement tools may also be helpful in identifying cost and schedule improvement opportunities. Students
wishing to learn more about these tools can begin by reading about Lean Six Sigma practices for products and
their applicability to service organizations. Ideally, opportunities for improvement are to be quickly identified
in order to influence project performance. This is particularly true when the predictive/waterfall development
methodology is used since planning is completed upfront. During later project stages, as pressures to meet
project schedule goals increase, the culture of the project is less conducive to making changes in work
processes.
Many organizations have a quality policy that states how it measures quality across the organization. When
planning quality in the project, project leaders must ensure that the project follows the company policy and any
government rules or regulations.
Part of good quality planning includes identifying the tasks that need to be performed in order to measure
the quality of the project’s solution. These specific tasks will be part of the scope and considered when
schedules and budgets are developed.

Techniques

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

• Cost-benefit analysis is looking at how much the quality activities will cost versus how much will be

102 | 5. Project Planning

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

Example: Diagramming Quality Problems

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

• Low-quality raw materials

• Power fluctuation
• Ambient temperature
• Worker absenteeism
• Poor training
• Old equipment

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

5. Project Planning | 103

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

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

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

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

Check sheets, histograms, and Pareto charts are also used to solve several quality problems. When a quality-
control issue occurs, a project leader must choose which problem to address first. One way to prioritize quality
problems is to determine which ones occur most frequently. These data can be collected using a check sheet,

104 | 5. Project Planning

which is a basic form on which the user can make a check in the appropriate box each time a problem occurs,
or by automating the data collection process using the appropriate technology.

Exhibit 5.22: Example of a check sheet

DanielPenfield, Wikimedia

Once the data are collected, they can be analyzed by creating a type of frequency distribution chart called a
histogram. A true histogram is a column chart where the widths of the columns fill the available space on the
x-axis axis and are proportional to the category values displayed on that axis, while the height of the columns
is proportional to the frequency of occurrences. Most histograms use one width of the column to represent a
category, while the vertical axis represents the frequency of occurrences.
A variation on the histogram is a frequency distribution chart invented by economist Vilfredo Pareto known
as a Pareto chart, in which the columns are arranged in decreasing order with the most common on the left
and a line added that shows the cumulative total. The combination of columns and a line allows the user to
tell at a glance which problems are most frequent and what fraction of the total they represent. For instance,
in Exhibit 5.24, there are six reasons why travellers arrive late at the airport. Traffic is the number one reason
and it was reported by 55 participants. Approximately 154 people participated in this study. Traffic represents
approximately 36% of the total late arrivals (55/154). The second highest cause, child care issues, represents
26% of the total. Cumulatively, traffic and child care issues represent 62% of the total. The third cause, public
transportation issues brings the cumulative total to approximately 80% of the total. Understanding what causes
the majority of the issues allows a team to prioritize and focus on these key factors. In this case, if the airport
wanted to significantly reduce the number of late arrivals, they could focus on traffic, child care and public
transportation issues.

5. Project Planning | 105

 Exhibit 5.24: Example of Pareto chart
Dense2013, Wikimedia

Quality and Grade

According to the International Organization for Standardization (ISO), quality is “the degree to which a set of
inherent characteristics fulfill requirements.” The requirements of a product or process can be categorized or
given a grade that will provide a basis for comparison. The quality is determined by how well something meets
the requirements of its grade.
For most people, the term quality also implies good value—getting your money’s worth. For example, even
low-grade products should still work as expected, be safe to use, and last a reasonable amount of time.
Thinking back to our case study, John has antique furniture in excellent condition that he inherited from his
grandmother. Since the pieces are valuable to John for sentimental reasons, he decides to hire movers (“high-
grade professionals”) to load his furniture into the truck using appropriate padding, and restraints to prevent
dents or scratches during the move. John’s standard for high quality is that no observable damage occurs to
his large pieces of furniture, especially the antiques. If the furniture arrives in his new apartment without a
single dent, scratch, or other damage, the activity will be of high quality. On the other hand, since John’s dishes,
glassware, and utensils are old and cheap, his standard for packing his kitchen is lower. Therefore, he decides
to trust his inexperienced friends (“low-grade amateurs”) to help him pack his kitchen. If a few of the dishes or
glassware are chipped or broken in the process, the savings in labour cost will more than makeup for the loss
and will still produce good value.

106 | 5. Project Planning

Measurement Terminology

During implementation, services and products are sampled and measured to determine if the quality is within
control limits for the requirements and to analyze possible causes for any quality variations. This evaluation
is often done by a separate quality control group, and knowledge of a few process measurement terms
is necessary to understand their reports. Several of these terms are similar, and it is valuable to know the
distinction between them.
Project teams can identify the control limits of the product or process. The size of the range between those
limits is the tolerance. Tolerances are often written as the mean value, plus or minus (±) the tolerance.
Tools are selected that can measure the samples closely enough to determine if the measurements are within
control limits and whether any trends emerge. Each measurement tool has its own tolerances.
The choice of tolerance directly affects the cost of quality (COQ). In general, it costs more to produce and
measure products that have small tolerances. The costs associated with making products with small tolerances
for variation can be very high and not proportional to the gains. For example, if the cost of evaluating each
screen as it is created in an online tutorial is greater than delivering the product and fixing any issues after the
fact, then the COQ may be too high and the instructional designer will tolerate more defects in the design.

Statistics

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

If a process is designed to produce a product of a certain size or another measured characteristic, it is

impossible to control all the small factors that can cause the product to differ slightly from the desired
measurement. Some of these factors will produce products that have measurements that are larger than
desired, and some will have the opposite effect. If several random factors are affecting the process, they tend to
offset each other, and the most common results are near the middle of the range; this phenomenon is called
the central limit theorem.
If the range of possible measurement values is divided equally into subdivisions, referred to as bins, the
measurements can be sorted, and the number of measurements that fall into each bin can be counted. The
result is a frequency distribution that shows how many measurements fall into each bin. If the effects that are
causing the differences are random and tend to offset each other, the frequency distribution is called a normal
distribution, which resembles the shape of a bell with edges that flare out. The edges of a theoretical normal
distribution curve get very close to zero but do not reach zero.

Quality Assurance

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

5. Project Planning | 107

Process Analysis

The flowcharts of quality processes are compared to the processes followed during actual operations. If the
plan was not followed, the process is analyzed and corrective action is taken. The corrective action could be to
educate the people involved on how to follow the quality plan, or, alternatively, it could be to revise the plan.
The experiments that sample products/processes and collect data are examined to see if they are following
statistically valid sampling techniques and that the measurement methods have small enough tolerances to
detect variation within control limits.
Because projects are temporary, there are fewer opportunities to learn and improve within a project,
especially if it has a short duration. But even in short projects, the quality manager should have a way to learn
from experience and change the process for the next project of a similar complexity profile.
The purpose of quality assurance is to build confidence in the user that quality standards and procedures are
being followed. This is done by an internal review of the plan, testing, and revision policies or by an audit of the
same items performed by an external group or agency.

5.9 Stakeholder and Communications management

Achieving a project’s objectives requires a focused, well-organized project leader who can engage with a
committed team and gain the support of all stakeholders. Building strong, trusting relationships with interested
parties from the start can make the difference between project success and failure.
Stakeholder management is one of the most important and challenging aspects of successful project
management. Project leaders must rely on their soft skills to be effective in this area. Effective project leaders
spend a significant amount of time building relationships with stakeholders.
Understanding a stakeholder’s interest is about understanding “what is in it for them?” In addition, asking
stakeholders how they define project success is a powerful way of identifying their expectations. Knowing what
each stakeholder needs or wants from the project will enable the project leader to anticipate the stakeholder’s
level of support and identify any potential conflicts that may arise. Conflicts are common and often healthy for
projects. When managed effectively, conflicts lead to good decisions that optimize the value of the project. At
the outset, conflicts often arise when prioritizing project constraints. For instance, one stakeholder may believe
it is more important to complete the project with an aggressive timeline while another may feel minimizing
project cost is the priority. Another common example is in defining solution requirements. Project leaders need
to ensure the voice of their stakeholders is continuously heard during solution design and development. This
may lead to differences of opinion and these differences need to be resolved in a respectful, timely fashion.
Depending on the development methodology chosen, resolving these differences may be part of the product
owner, business subject matter expert, scrum master, business analyst, and/or project leader’s accountabilities.
When project leaders are accountable for resolving these differences, interpersonal skills are key. Active
listening and a clear willingness to facilitate relationship-building between stakeholders are important. In
addition, staying “passionately neutral” in the eyes of stakeholders is important. As a project leader, it is not
about what is best for you, it is about identifying what is best for the project and the organization, and
passionately pursuing that with stakeholders. Resolving conflicts in respectful ways is a skill that can be
developed over time.
In some cases, project leaders will be working with stakeholders that are not supportive of the project. They
may feel the project is not going to benefit them and their team in the ways it should. They may also resist
making the changes that are necessary to support the project’s outcomes. Some stakeholders are very upfront
about their resistance and others are not. In these situations, the project Sponsor may be integral to winning
these stakeholders over. Knowing when to tactfully involve others in stakeholder management is another key
success factor for effective project management.

108 | 5. Project Planning

 Building trust and maintaining an open line of communication is critical in working with all stakeholders.
Keeping stakeholders involved is essential and it requires more than simply sharing information. The project
leader must ask for their input and demonstrate an understanding of a stakeholder’s unique business
challenges. This level of understanding is often done through simple and regular check-ins with stakeholders.
Lastly, project leaders who are successful in relationship building understand each stakeholder’s capacity to
participate and honour their time constraints.
As mentioned in Chapter 4, the stakeholder register is an effective tool for project leaders to use throughout
the project. It allows the project team to keep track of all the stakeholders and ensure their needs are
represented in the communications plan.

Let us look more closely at the communication techniques project leaders use to ensure the right information
is reaching the right audience at the right time and in the right mediums.
There are two types of communications: synchronous and asynchronous. If all the parties to the
communication are taking part in the exchange at the same time, the communication is synchronous. There
are many examples of synchronous communications: conference calls, live meetings, and instant messaging.
There are many ways to conduct conference calls: telephone, computer-assisted conference audio, and/or video
calls. Platforms such as Skype, Zoom, and Microsoft Teams have made virtual collaboration so much more
effective.
Getting a team together at the same time can be a challenge, especially if they are spread out across
time zones. Many types of communication do not require that the parties are present at the same time. This
type of communication is asynchronous (the letter “a” at the beginning of the word means not.) There are
several choices of asynchronous communications. Some methods are very traditional, such as mailing legal
documents, while others are much more innovative, such as web-based collaboration platforms. Global projects
need to consider the availability of collaboration technology for all participants as it can vary significantly by
country. Web-based platforms have transformed the way people communicate. However, some organizations
still use email to manage projects.
Some messages are best conveyed through synchronous methods while others are well suited to
asynchronous methods. For instance, conflict resolution is often more effective when done synchronously as it
is much easier to understand other people’s perspectives when body language is observable. Communicating
large amounts of technical information are best done asynchronously as this gives the reader the opportunity
to review, process, and respond to the information after they have had a chance to absorb it in written form.
Project leaders are much more likely to be successful when they have strategically considered and documented
how and when project information will be communicated. This is the role of the communications plan.
Communication plans answer the following questions:

1. What information do stakeholders need?

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

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

5. Project Planning | 109

analysis is complete, common information needs emerge. Common needs include project objectives, scope,
milestones, budget, risks, issues, action items, performance measures, approvals required, and so forth.
The types of communication technology present on the project heavily influences the approaches taken in
answering the remaining questions about how information is communicated, when it is communicated, and
who is responsible for developing/delivering the communications. In some cases, the project team will already
have the information technology needed to create and deliver effective communications. When this isn’t the
case, it’s time to assess new communications technologies.

Assessing New Communication Technologies

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

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

Communication Plan Templates

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

1. Who the stakeholders are (individuals and groups)

2. The communications necessary to satisfy stakeholder expectations
3. The timeframe and/or frequency of communication messages
4. The tools/applications used to communicate the messages
5. Roles and responsibilities for creating and disseminating the messages

110 | 5. Project Planning

 Exhibit 5.25: Communications plan template
Inte5160, Wikispaces

References
1
Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK
guide) (6th ed., p. 61). Project Management Institute.
2
Larson, E. W., & Gray, C. (2021). Project management: The managerial process. (8th ed.). McGraw Hill
Education.

5. Project Planning | 111

6. Project Execution
Overview

Each project is unique because they come in all different shapes and sizes. During implementation, the unique
product/service/result is created. The nature of the work carried out during implementation is very different
for each project. For instance, in technology projects, the phase involves developing, testing, and deploying a
new application. Implementation may occur through a single release or multiple releases. Projects intending to
identify new potential export markets will carry out their research plans during the implementation phase. The
result of such work may be a research report with recommendations for the organization’s senior executives.
Similarly, a project seeking to develop new employee orientation materials may develop an orientation manual
and/or a training program during implementation. Naturally, the tools and techniques used for these two
projects will be very different. Rather than attempting to describe all the potential tools and techniques that
could be used during implementation of different projects, an overview of the nature of this phase will be
discussed.
The plans developed by the project team are put into motion during implementation. The team is drawing on
the plans they created to design their solution(s), manage project resources, timelines, costs, risks, procurement,
quality, stakeholders, and communications.
Project implementation is usually where the project team spends most of their time. As a result, this is
typically where the majority of the project’s budget is spent. Effective communication is critical during
implementation as there are many small teams focused on producing deliverables which often have many
team interdependencies. The deliverables of the project include all of the products, services, and results created
to fulfill the project’s objectives, including all the project management documents.
During implementation, as tasks are carried out, progress information is being reported through regular team
meetings. Again, effective communication becomes critical. Depending on the nature of the project, these
team meetings could be daily, weekly, or monthly. Team meeting frequency is a decision made by the project
leader based on which is the most effective at keeping everyone informed and aligned with the work underway.
The project leader uses performance information to ensure communication channels remain open, issues
are identified, and corrective action is taken as needed. When predictive/waterfall development methodology
is used, the implementation phase may identify the need for a number of change requests. Change requests
occur when the project team discovers a new requirement and/or a way to improve the project’s outcomes.
Lastly, one of the universal factors associated with successful project implementations is successful team
management. The key tools and techniques used in team management will be explored in detail in the section
below.

6.1 Managing Teams

The project team is often made up of people supporting the project on a full-time and part-time basis. The team
members may be temporarily assigned to the project from other internal functions within the organization or
brought into the organization specifically for the project. Regardless of their source, it is critical to invest time
and effort into developing a high-performing project team composed of skilled and motivated individuals who
can contribute to the project’s success. One of the many responsibilities of a project leader is to enhance the
abilities of each project team member by fostering individual growth and accomplishment. At the same time,
everyone must be encouraged to share ideas and work with others toward a common goal.

112 | 6. Project Execution

 Determining when a team is needed is an important first step. Assigning a team is a better approach than
assigning individuals when:

• When no single person has the knowledge, skills, and abilities to either understand or solve the problem
• When innovation is important
• When multiple individuals must be committed to identifying and implementing a solution (commonly
referred to as “getting buy-in”)
• When the problem and solution cross-project/organizational functions

Individuals can outperform teams on some occasions. An individual tackling a problem consumes fewer
resources than a team and can operate more efficiently—as long as the solution meets the project’s needs. A
person is most appropriate in the following situations:

• When a single person has the knowledge, skills, and resources to solve the problem
• When speed is important
• When the activities involved in solving the problem are very detailed
• When documents need to be written (teams can provide input, but writing is a solitary task)

In addition to knowing when a team is appropriate, the project leader must also understand what type of team
will function best for the project’s needs.

Functional Teams

A functional team refers to one of the project’s functions, such as the engineering team, the procurement team,
and the communications team. Any one of these teams may be tasked with solving a nuanced problem on a
project. For example, low stakeholder engagement may be a problem addressed by the communications team.
Another example would be the procurement team initiating a resolution with a vendor who is not meeting the
expectations of a contract.
When a functional team is assigned to lead the resolution of a problem or the pursuit of an opportunity, they
are likely to do some initial analysis internally and then share it with the broader project team. This is often
necessary because the work on a project must be integrated and a single functional team is unlikely to resolve
complex issues and/or pursue opportunities on their own.

Cross-Functional Teams

Cross-functional teams are utilized when issues and/or work processes require collaboration between two or
more of the project’s functional teams. The team members are selected to bring their functional expertise to
address project challenges and opportunities. Given the far-reaching nature of change initiatives today, most
projects require cross-functional teams. This is true regardless of the development methodology used. More
information on the nature of an agile team’s composition will be covered later in the chapter.

Problem-Solving Teams

Problem-solving teams are assigned to address specific issues that arise during the life of the project. The
project leadership includes members with the expertise required to address the problem. The team is chartered
to address that problem and then disband. As such, they are more temporary than functional and cross-
functional teams.

6. Project Execution | 113

 Projects are unique and temporary. The staffing model employed is also unique and temporary. This
gives rise to a number of unique challenges:

• Project team members who are “borrowed” and do not report to the project leader in the long
term may have their priorities elsewhere

◦ They may be juggling many projects as well as their full-time functional job, causing them
difficulty in meeting deadlines
◦ Project leaders may find out about missed deadlines after it is too late to recover

• Personality conflicts may arise (e.g. differences in social style/values, bitterness between team
members who have worked on past projects together, etc.)

◦ Since team members know the project team is not their long-term “home,” conflict
resolution can be more challenging

Leadership Styles

Just as organizations rise and fall on the capabilities of their leaders, projects rise and fall on the capabilities of
project leaders.

“Leader” versus “Manager”

The two dual concepts, leader and manager, are not interchangeable, nor are they redundant. The
differences between the two can, however, be confusing. In many instances, in order to be a good
manager, one also needs to be an effective leader. Many people hope that their leadership skills, their
ability to formulate a vision and get others to “buy into” that vision, will propel the team forward.
However, effective leadership often necessitates the ability to manage—to set goals; plan, devise, and
implement strategy; make decisions and solve problems; organize and control. Essentially, project
leaders need to be effective managers and effective leaders.

Much research has been published about leadership due to how crucial competent leaders are to
organizational success. Leadership will continue to be in the spotlight for the foreseeable future. Disruptive
technology, such as artificial intelligence, challenges our notions of what leaders are and what they do. Further,
economies and societies continue to be deeply challenged by health, political, and environmental crises. When
a crisis strikes, we look to leaders to help us navigate the ensuing chaos. With so much focus on leadership,
studying leadership styles is a helpful starting place for students seeking to understand how successful people
can introduce change into an organization. As we reflect on the various leadership styles, it also provides the
student with an opportunity for self-reflection.

114 | 6. Project Execution

 It is important to begin by noting that no particular leadership approach is appropriate for managing
all projects. Due to the unique circumstances inherent in each project, the leadership approach and the
management skills required for success will vary.
In addition, throughout a project, each stage may require a different leadership style. For instance, during
the start-up phase of a project when new team members are first assigned to the project, a more command-
and-control leadership style may be most effective. This is because the team is looking for direction about their
roles and responsibilities, as well as clarity about the objectives of the project. Later, as the project moves into
the planning stage where more conceptual work is being carried out causing creativity to become crucial, a
transformational leadership style may be appropriate.
Many organizations are no longer seeking a fixed recipe for achieving organizational success. Agility is critical
for organizations to survive and thrive in these unpredictable, turbulent times. Given this, a growing emphasis
is being placed on the agile leader. “Agile” is a development methodology, but it is also a way of leading people
and organizations.
Let us further define these leadership styles in order to understand their nature. This can lead to thought-
provoking classroom discussions about the style of some of today’s most well-recognized leaders who have
served as catalysts for change. In addition, by examining the nature and complexity profiles of different projects
appropriate for each program of study, students can reflect on the application of various leadership styles in
these projects.

Transactional Leaders:

Leaders who subscribe to the notion that “if it ain’t broke, don’t fix it” are often described as transactional
leaders. They are extremely task-oriented in their approach, frequently looking for incentives that will induce
their followers into a desired course of action.1 These reciprocal exchanges take place in the context of a
mutually interdependent relationship between the leader and the follower, frequently resulting in interpersonal
bonding.2 The transactional leader moves a group toward task accomplishment by initiating structure and by
offering an incentive in exchange for desired behaviours.

Transformational Leaders:

The transformational leader, on the other hand, moves and changes (fixes) things “in a big way!” Unlike
transactional leaders, they do not cause change by offering incentives. Instead, they inspire others to action
through their personal values, vision, passion, and belief in and commitment to the mission.3 Transformational
leaders move others to follow through charisma (influence), individualized consideration (a focus on fostering
personal growth in the follower), intellectual stimulation (questioning assumptions and challenging the status
quo), and/or inspirational motivation (articulating an appealing vision). The transformational leader is a visionary
leader. In short, leaders who are visionary are those able to influence followers through an emotional and/or
intellectual attraction to the leader’s dreams for the future. Vision links a present and future state, energizes
and generates commitment, provides meaning for action, and serves as a standard against which to assess
performance.4 Evidence indicates that vision is positively related to follower attitudes and performance.5
Warren Bennis, widely regarded as a pioneer in the field of leadership, notes that a vision is effective only
to the extent that the leader can communicate it in such a way that others come to internalize it as their
own.6 Transformational leaders have engaging personalities characterized by extroversion, agreeableness, and
openness to experience.7 They energize others. They increase followers’ awareness of the importance of the
designated outcome.8 They motivate individuals to transcend their own self-interest for the benefit of the team
and inspire organizational members to self-manage (become self-leaders).9 Transformational leaders move
people to focus on higher-order needs (self-esteem and self-actualization). When organizations face a turbulent

6. Project Execution | 115

environment, such as intense competition or products that may quickly fall out of favour, they must act quickly.
Since managers cannot rely solely on organizational structure to guide organizational activity, transformational
leadership motivates followers into being fully engaged and inspired, internalize the goals and values of the
organization, and move forward with dogged determination. Transformational leadership is positively related
to follower satisfaction, performance, and acts of citizenship because transformational leaders’ behaviours elicit
trust and perceptions of procedural justice (see Footnote 8). As noted by Pillai, Schriesheim, and Williams when
followers perceive that they can influence the outcomes of decisions that are important to them and that they
are participants in an equitable relationship with their leader, their perceptions of procedural justice [and trust]
are likely to be enhanced (see Footnote 8).

Agile Leaders:

Note: Agile leadership should not be confused with agile development methodology.

A YouTube element has been excluded from this version of the text. You can view it online here:
https://pressbooks.senecacollege.ca/projectmanagementfundamentals/?p=147

Aaron De Smet, Michael Lurie, and Andrew St. George wrote in their 2018 McKinsey & Company article that
agile leadership is about co-creation10. Agile leaders have made a fundamental shift by moving away from a
reactionary approach and adopting a creativity-driven approach. At the heart of this shift in mindset is customer
value, which is why agile leaders teach their teams how to focus on value creation. Agile leaders make the
following shifts in mindset (see Footnote 10):
From certainty to discovery: fostering innovation

• A reactionary mindset of certainty is about playing not to lose, being in control, and replicating the past.

116 | 6. Project Execution

 Today, some leaders have shifted to a creativity-driven mindset of discovery which is about playing to win,
seeking diversity of thought, fostering creative collision, embracing risk, and experimenting.

From authority to partnership: fostering collaboration

• This requires an underlying creativity-driven mindset of partnership and of managing by agreement based
on freedom, trust, and accountability.

From scarcity to abundance: fostering value creation

• To deliver results, leaders must view the organization’s external environments with a creativity-driven
mindset of abundance which recognizes the unlimited resources and potential available to their
organizations in addition to enabling customer-centricity, entrepreneurship, inclusion, and cocreation.

One of the ways that project leaders can adopt an agile leadership style is by keeping the customer/user at the
centre of the design. In addition, project success is dependent on value creation. Lastly, diverse opinions can be
proactively sought out and the proposed value can undergo cost-benefit analysis.
As you reflect on the various leadership styles, keep in mind that project leaders must be able to adjust their
leadership style to the needs of the organization and the project.

Leadership Skills

Project leaders require a diverse skill set, such as administrative skills, organizational skills, and any technical
skills associated with accomplishing the project’s solution. In addition, a successful project leader has very
strong problem-solving, negotiation, conflict management, and delegation skills. They possess a high degree
of tolerance for ambiguity, utilize active listening techniques to promote healthy two-way communication, and
are able to adjust their leadership style based on the state of affairs in the ever-changing project environment.
The types of skills and their respective depths are closely connected to the size and complexity profile of
the project. Typically, on projects will smaller teams, project leaders require a greater degree of technical
skill because they often have to be more hands-on in developing the schedule, cost estimates and quality
standards. When these smaller teams are tackling complex solutions, the project leader needs to have a deeper
level of technical understanding as they will be expected to guide the teams in this aspect. On projects with
larger teams, a greater degree of organizational skills is required to ensure that the large number of project
resources remain connected and aligned.

Problem-solving

In section 5.8, the cause-and-effect/fishbone diagram was introduced as a very effective quality management
tool that can aid in the identification of the root cause of a problem. Project leaders who know how to use this
tool are much more likely to identify why the team has run into problems and what should be done to resolve
the issues permanently. This tool is most effective when used in team settings where people with subject
matter expertise (relating to the problem) are the ones brainstorming the underlying drivers. For example,
marketing experts analyzing why a promotional campaign failed to generate the expected level of incremental
sales.
When the project team is underperforming, identifying the root causes is also important. This is more
challenging for the project leader to do because the team’s performance problems may be a result of the
project leader’s own skill deficiencies. For instance:

6. Project Execution | 117

 • Breakdown in team communication could represent a project leader’s lack of communication skills
• Uncommitted team members could represent a project leader’s lack of team-building skills
• Role confusion within the project team could represent a project leader’s lack of organizational skills

When these types of problems arise, project leaders must assess the performance of the team and their own
performance. Seeking feedback from the team and other key stakeholders is an effective way to obtain the
information required for root cause identification and self-reflection. Confidential surveys can be very helpful in
this instance. In addition, high-performing project leaders often have a mentor that they go to for advice and
support.

Negotiation

When multiple people are involved in an endeavour, differences in opinions and desired outcomes naturally
occur. Negotiation is a process for developing a mutually acceptable outcome among parties in the presence of
conflicting desired outcomes. A project leader will often negotiate with the project sponsor, resource managers,
project team members, vendors, and other project stakeholders. Negotiation is an important skill when
developing support for the project and preventing frustration among all parties involved, which could result in
project failure.
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 solutions versus blaming.
2. Focus on common interests. By avoiding the focus on differences, both parties are more open to finding
solutions that are mutually beneficial.
3. Seek options that advance shared interests. Once the common interests are understood, solutions that do
not match with either party’s interests can be disregarded, while solutions that may serve both parties’
interests can be more deeply explored.
4. Develop results based on standard criteria (for example, a standard criterion for a project developing a
mobile application may be reaching 100,000 downloads in the App Store)Assuming that the parties have
agreed on a common definition of project success, the selected criterion becomes a measure of when
project success has been achieved.

For the project leader to successfully negotiate the project’s issues, they should be cognizant of the other party’s
position. When negotiating with a key stakeholder, what is their concern or desired outcome? What are the
important professional and personal factors for this stakeholder? Without this understanding, it is difficult to
find a solution that will satisfy the stakeholder. While doing this, the project leader must also keep in mind
which outcomes are desirable for the project. Typically, more than one outcome is acceptable. Successful
negotiation starts with the desired outcomes. The interpersonal skills of the project leader are then put to the
test as they work to reach a final agreement from all stakeholders on the most favourable outcomes.

Conflict Management

Counterintuitively, conflict on a project is necessary. There are many reasons why conflict occurs, such as
ambiguity due to lack of information, personality differences, role confusion, differing ideas, timeline pressures,
and clashes between individual versus team goals. Although good planning, communication, and team
building can reduce the amount of conflict, conflict will still emerge. However, not all conflict is bad. A key
benefit or outcome of conflict is that a team can learn to trust each other. Many teams are stronger because

118 | 6. Project Execution

they have been able to successfully navigate conflict. In his bestselling book, The Five Dysfunctions of a Team,
Patrick Lencioni writes11:

“The first dysfunction is an absence of trust among team members. Essentially, this stems from their
unwillingness to be vulnerable within the group. Team members who are not genuinely open with one
another about their mistakes and weaknesses make it impossible to build a foundation for trust. This
failure to build trust is damaging because it sets the tone for the second dysfunction: fear of conflict.
Teams that lack trust are incapable of engaging in unfiltered and passionate debate of ideas. Instead,
they resort to veiled discussions and guarded comments.”

Lencioni also asserts that, if a team does not work through its conflict and air its opinions through debate, team
members will never really be able to buy in and commit to decisions (lack of commitment being Lencioni’s third
dysfunction). Teams often have a fear of conflict to avoid hurting any team members’ feelings. The downside
of this avoidance is that conflicts still exist under the surface and may resurface in more insidious and back-
channel ways that can severely derail a team.
When conflict does arise on a project, project leaders must decide how to manage it. In their book Project
Management: The Managerial Process, Erik Larson and Clifford Gray distinguish between functional and
dysfunctional conflict12. Functional conflict helps the project team achieve the project objectives. Project
leaders who want to harness the power of conflict for greater team effectiveness and productivity can
intentionally invite functional conflict. They can do this by intentionally asking for diverse opinions, ensuring
everyone participates in safe and open discussion spaces, and finding people willing to openly identify reasons
why something may fail. As its name implies, dysfunctional conflict prevents the team from achieving project
objectives. A common example of dysfunctional conflict is when personalities clash and the individuals are
unable to communicate with each other and/or work together. Larson and Gray proposed five possible
strategies for managing dysfunctional conflict:

• Mediating is the best approach when a conflict has turned into a “lose/lose” situation and the affected
parties require assistance in facilitating a resolution. The project leader intervenes and tries to negotiate a
resolution with the parties involved. This approach works well when the project leader has the time
required to facilitate discussions and there is a chance that conflict resolution will serve as a learning
opportunity for all parties involved.
• Arbitrating is the best approach when the project leader no longer believes that the parties can achieve
resolution on their own and/or within the time available, so they must impose a solution. The project
leader listens to the involved parties and then selects a solution that is in the best interest of the project
and organization.
• Controlling the conflict is the best approach when parties will be able to attempt conflict resolution after
they have had a chance to work through strong emotions. The project leader utilizes tactics to de-escalate
the conflict’s intensity. For example, the affected parties may be asked to temporarily cease
communication to allow each individual time for reflection and an opportunity to calm. If the parties are
still unable to initiate conflict resolution, another strategy would be required.
• Accepting the conflict is the best approach when the relationship between the affected parties does not
have long-term importance and/or the issue is of little significance to project success. In this situation, the
project leader acknowledges the presence of conflict and intentionally allows it to continue.
• Eliminating the conflict is the best approach when all other approaches have failed. It requires one or all of
the affected parties to be removed from the project team.

In conclusion, each of these approaches can be effective and useful depending on the situation. Project leaders
will use each of these conflict resolution approaches depending on their personal approach and an in-depth
assessment of the situation.

6. Project Execution | 119

 Project leaders will encounter a variety of individual responses to conflict within their team. Hanna Inam, a
thought leader in transformational and agile leadership, purports that the basis of our reactions is often the
only thing that can be seen.13 This includes an individual’s behaviours and the point of view/positions they
take during discussions. However, it is important to learn about an individual’s underlying assumptions and
aspirations (what they deem important) before jumping to conclusions and engaging in dysfunctional conflict.
Inam advocates for effective team building early on in a project and recommends that individuals take the
time to get to know each other. She offers five simple questions to facilitate meaningful dialogue:

1. What are your most important goals?

2. How do you like to communicate?
Note: this goes beyond the devices one uses to communicate; it encompasses how a person verbalizes
and understands information
3. What energizes you?
4. What frustrates you?
5. How can we best work together?

Notice how the first four questions are not about the project or teamwork, it is about life in general. Successful
teams consist of members who understand their teammates’ personal and professional styles.
Inam also recommends that individuals learn their default conflict style and recognize that the same style
does not work in every situation. The figure below is a summary of the five conflict styles:

Avoiding You decide that staying engaged in the conflict will not result in a good outcome

Accommodating You view support towards others as low-cost to you and high-benefit to them

Competing You view yourself as possessing greater expertise or better information than others

You realize that each team member has to give something up because getting everyone’s needs met
Compromising
is unrealistic

Collaborating You have needs that you want met but you also want to make sure the needs of others are met

Note: the primary difference between compromising and collaborating is that collaboration does not result
in having to give things up. The best outcome is achievable because there has been an open flow of
communication and idea-sharing from the onset of the project or task.

120 | 6. Project Execution

 Exhibit 6.1: A matrix displaying where the different conflict styles fall based on the importance they place on
relationships versus achieving goals.
In summary, conflict can be uncomfortable and awkward, but it is important. Surfacing areas of conflict and
differing perspectives can have a very positive impact on the growth and future performance of the team, and
it should be managed constructively.

Delegation

Many people new to leadership have a difficult time entrusting others with work. Oftentimes, this occurs
because the individual prefers to do the tasks independently as it may give them a sense of accomplishment.
Regardless of the reason, it is disastrous for them and the team. 21st-century leadership requires leaders to

6. Project Execution | 121

determine which skills and experiences are required and when they are required. Delegation is also about
setting up autonomous teams in a clear, empowering structure that facilities collaborative approaches to
getting the work done. When the right people have been recruited for the project, it is critical that the project
leader empowers people to take accountability and work collaboratively.
If the project leader delegates too little accountability to others to make decisions and act, the lack of
creativity in the solution and lags in decision-making may prevent the project from delivering organizational
value. On the other hand, delegating too much authority to others without the required knowledge, skills, or
information will set them up for failure. When team members do not have what it takes to complete the work,
effective project leaders rectify this situation very clearly by finding ways to transfer the knowledge or reassign
the work. The rhythm and flow of a high-performing team can be irreparably damaged by project leaders who
fail to act in these situations.

High-Performing Teams

Effective project leaders create high-performing teams. According to Katzenbach and Smith in their Harvard
Business Review (HBR) article “The Discipline of Teams,” the five elements that make teams function are:14

1. Common commitment and purpose

2. Specific performance goals
3. Complementary skills
4. Commitment to how the work gets done
5. Mutual accountability

Further, according to Katzenbach and Smith, who have observed successful teams in action, there are a number
of practices that make teams truly effective. These practices include:

• Establishing urgency
• Demanding performance standards
• Providing direction

Teams work best when they have a compelling reason for being, and it is thus more likely that the teams
will be successful and live up to demanding performance expectations. When teams are brought together to
address an “important initiative” for an organization, they require clear direction and a truly compelling reason
to prevent them from losing momentum and withering. Let us examine some of the methods used to create
high-performing teams.
Teams have a much better chance of being high-performing when members are selected based on their
skills and ability to collaborate with others. This is not always as easy as it sounds for several reasons. Firstly,
most individuals would prefer to have people they like on their team, especially when they have fun, positive
personalities. This will translate into an enjoyable work environment. However, it can turn into a frustrating
environment if those individuals do not have the required skillset (or the potential to acquire knowledge) to
contribute towards the project’s deliverables. It is important that the project leader spends time thinking about
the purpose of the project and the anticipated deliverables. This will allow the project leader to identify the
specific skills needed on the team.
Once the team is assembled, it is important to pay particular attention to the first meetings and actions.
Project teams will interact with many different people, such as functional subject-matter experts and senior
leadership, which is why the team must look and be perceived as competent. Further, project leaders who pay

122 | 6. Project Execution

attention to their team’s emotional intelligence and find ways to enhance it are much more likely to successfully
navigate stakeholder expectations.
Project leaders that take the time to find early quick wins for their team will prepare them for the more
challenging tasks and goals that will occur later in the project. These quick wins build team rapport by fostering
feelings of team accomplishment and cohesion.
Introducing change into an organization is challenging. It is important to be continuously researching and
questioning the assumptions the team is making about the project. Sometimes the team’s expectations are
proven to be unfeasible aspirations, and, if detected too late, can lead to poorly designed solutions or even
project failure. Project leaders can encourage their teams to identify and challenge their own assumptions
by teaching them how to scan for new information in the environment. Staying curious and inquisitive are
mindsets that can be modelled by the project leader. Teams that take on these mindsets are much more likely
to be able to keep up with global change and understand how this change affects their project.
It is also important to spend time together. Teams are so busy that they can overlook the importance of
bonding. Time in person, on the phone, in meetings—all of it counts and helps to build camaraderie and trust.
In turn, this leads to better collaboration among team members. Many project leaders assume people are
naturally good collaborators, but this is often not the case. However, relationship-building skills and effective
collaboration techniques can be taught. Project leaders who provide training for their teams in this area
are more likely to create a high-performance team. Furthermore, as team members demonstrate effective
collaboration skills, it is important that project leaders share positive feedback, provide recognition, and link
the team’s performance to rewards. These are key performance management tools that build high-performing
teams by reinforcing desired behaviours.
Formal performance review processes are critical to project success. Although some of the project team
members will return to their functional teams upon project closure, project leaders are accountable for
individual performance during the life of the project. Performance reviews are important to keep projects on
track and they represent an investment in the continued development of an organization’s human resources.
Project leaders should consider how they will evaluate individual performance and share this with the team
in order to ensure transparency in expectations. Performance is a function of what is delivered and how it
is delivered. High-performing teams consider both, not just the results. This is because team members who
produce the best results but cause negativity in their team environment can prevent the entire team from
reaching its full potential.

Team Development

Most of us have been part of a team. Reflecting on our experiences, we can recall what it felt like when the team
first came together, when challenges emerged, and when it was time to part ways. All teams have different
“stages” of team development. Team members often start from a position of friendliness and excitement about
a project, but the mood can sour, causing the team dynamics to worsen very quickly once the real work begins.
In 1965, educational psychologist Bruce Tuckman at Ohio State University developed a four-stage model to
explain the complexities that he had witnessed in team development. The original model was called Tuckman’s
Stages of Group Development and he worked with Mary Ann Jensen to add the fifth stage of “Adjourning” in
1977 to explain the disbanding of a team at the end of a project15. The five stages of the Tuckman model are:

1. Forming

◦ Begins with the introduction of team members

◦ Known as the “polite stage” in which the team is mainly focused on similarities and the group looks to
the leader for structure and direction

6. Project Execution | 123

 ◦ Team members at this point are enthusiastic, and issues are still being discussed on a global,
ambiguous level
◦ Informal leadership order begins to develop, but the team is still friendly

2. Storming

◦ Begins as team members begin vying for leadership and testing the group processes
◦ Known as the “win-lose” stage, as members clash for control of the group and people begin to choose
sides
◦ A period of high conflict
◦ The attitude about the team and the project begins to shift to negative, and there is frustration around
goals, tasks, and progress
◦ Can be a very long and painful process

3. Norming

◦ The team is slowly starting to work well together, and buy-in to group goals occurs
◦ They begin establishing and maintaining ground rules and boundaries, and there is a willingness to
share responsibility and control
◦ At this point in the team formation, members begin to value and respect each other and their
contributions

4. Performing

◦ The team builds momentum and starts to get results

◦ The team is self-directed and requires little management direction
◦ The team has confidence, pride, and enthusiasm, and there is a congruence of vision, team, and self
◦ As the team continues to perform, it may succeed in becoming a high-performing team.

▪ High-performing teams have optimized both task and people relationships—they are maximizing
performance and team effectiveness

5. Adjourning

◦ The goal or project has been completed

◦ If the team was successful, this can be a time of celebration. If the team was not successful, the failures
can make it difficult for individual members to move on to their next assignment as they process what
led to the failures and take stock of what they’ve learned on an individual level
◦ Can be difficult as team members have to let go of the solutions they’ve developed and potentially the
relationships they have enjoyed building

124 | 6. Project Execution

 Exhibit 6.2: Tuckman’s Model of Team Development
Rice University, OpenStax

Katzenberg and Smith, in their study of teams, have created a “team performance curve,” graphing the
journey of a team from a working group to a high-performing team. The team performance curve is illustrated
below.

6. Project Execution | 125

 Exhibit 6.3: Team Performance Curve
Rice University, OpenStax

Evolving into a high-performance team is not a linear process. Similarly, the stages of team development in
the Tuckman model are also nonlinear, and there are even factors that may cause the team to regress to an
earlier stage of development. When a team member is added to the group, this may cause enough disruption in
the dynamic that the team does a backwards slide into an earlier stage of development. Similarly, a backwards
slide can occur if a new project task is introduced and it causes confusion or anxiety for the group. These events
can cause the team to have to re-form, re-storm and re-norm before getting back to the performing stage
as a team. Project leaders who understand the natural stages of team development are much more likely to
mentor their teams into becoming high-performing. Leadership is not a spectator sport. Project leaders cannot
stand by and watch their teams flounder as they struggle through the unique challenges of each stage. Project
leaders should be regularly assessing which stage their teams are in and proactively assisting them to move
through each stage on their journey to becoming high-performing.

Creating a Project Culture

Project leaders have a unique opportunity to create a project culture during its start-up, which is something
organizational managers seldom have a chance to do. As discussed in Chapter 3, 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, what has status, and what behaviours are expected.

126 | 6. Project Execution

Characteristics of Project Culture

A project culture encompasses 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
complexity profile of the project are important project management abilities.
Culture is developed through the communication of:

• The priority
• The given status
• 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 leaders
who set 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.
Culture guides behaviour, communicates what is important, and is useful for establishing priorities. On
projects with a strong culture of trust, team members will not hesitate to challenge anyone who betrays
confidence, even managers. In this example, the project’s culture of integrity is stronger than the organization’s
culture of power and authority.

Team Diversity

Decision-making and problem-solving can be much more dynamic and successful when they materialize in a
diverse team environment. The diversity in perspectives can enhance both the understanding of the problem
and the quality of the solution. Diversity is a word that is very commonly used today, but the importance of
diversity and building diverse teams can sometimes wane in the normal processes of doing business.
David Rock and Heidi Grant’s research in the Harvard Business Review article Why Diverse Teams Are Smarter
has shown that diverse teams are better at decision-making and problem-solving because they tend to focus
more on facts.16 A study published in the Journal of Personality and Social Psychology exhibited that people
from diverse backgrounds “might actually alter the behaviour of a group’s social majority in ways that lead
to improved and more accurate group thinking.” (see Footnote 16). The study concluded that the diverse
committees raised more facts related to the case than homogenous committees and made fewer factual
errors while discussing available evidence. The article noted another research paper demonstrating that diverse
teams are “more likely to constantly re-examine facts and remain objective. They may also encourage greater
scrutiny of each member’s actions, keeping their joint cognitive resources sharp and vigilant. By breaking up
workforce homogeneity, employees become more aware of their own potential biases, which are entrenched
ways of thinking that can otherwise blind them to key information and even lead them to make errors in
decision-making processes.” (see Footnote 16)
When people are among homogeneous and like-minded (nondiverse) teammates, the team is susceptible to
groupthink and may be reticent to think about opposing viewpoints since all team members are in alignment.
In a more diverse team with a variety of backgrounds and experiences, the opposing viewpoints are more likely
to come out and the team members feel obligated to research and address the questions that have been raised.
Again, this enables a richer discussion and a more in-depth fact-finding and exploration of opposing ideas and
viewpoints in order to solve problems.
Project leaders need to reflect upon these findings during the early stages of team selection so that they can
reap the benefits of having diverse voices and backgrounds.

6. Project Execution | 127

Multicultural Teams

As globalization has increased over the last decades, workplaces have felt the impact of working within
multicultural teams. The earlier section on team diversity outlined some of the highlights and benefits of
working on diverse teams, and a multicultural group certainly qualifies as diverse. However, there are some key
recommended practices for those who are leading multicultural teams to highlight the advantage of diversity
rather than viewing it as an obstacle.
People may assume that communication is the key factor that can cause derailment of a multicultural
team, citing different languages and communication styles among members as the problems. However, in the
Harvard Business Review article Managing Multicultural Teams, Jeanne Brett, Kristin Behfar, and Mary Kern
point out four key cultural differences that can cause destructive conflicts in a multicultural team.17

1. The first cultural difference is direct versus indirect communication. Some cultures are very direct and
explicit in their communication, while others are more indirect and ask questions rather than pointing out
problems.

◦ May cause conflict because, at the extreme, the direct style may be considered offensive by some,
while the indirect style may be perceived as unproductive and passive-aggressive in team interactions.

2. The second cultural difference is trouble with accents and fluency. When team members do not speak the
same language, there may be one language that dominates the group interaction, causing team
members who are not as fluent to feel excluded.

◦ May cause conflict due to the withdrawal of non-fluent speakers, leading the speakers of the primary
language to feel that non-fluent team members are not as valuable to the team or are less competent.

3. The third cultural difference is the presence of differing attitudes toward hierarchy. Some cultures are very
respectful of the hierarchy and will treat team members based on where they fall within that hierarchy.
Other cultures are more egalitarian and do not observe hierarchical differences to the same degree.

◦ May cause conflict if some people feel that they are being disrespected and not treated according to
their status.

4. The fourth cultural difference is conflicting decision-making norms. Different cultures make decisions
differently, and some will apply a great deal of analysis and preparation beforehand.

◦ May cause conflict because the cultures that make decisions more quickly (and need just enough
information to make a decision) may be frustrated with the slow response and relatively longer
thought process.

These cultural differences are good examples of how everyday team activities (decision-making,
communication, interaction among team members) may become points of contention for a multicultural team
if there is not an adequate understanding of everyone’s culture.
In their article, Brett, Behfar, and Kern propose that there are several potential interventions to try if these
conflicts arise.

• Adaptation is working with or around differences. This technique is best used when team members are
willing to acknowledge the cultural differences and learn how to work with them.
• Structural intervention is the reorganization of the team’s composition in an attempt to reduce friction.

128 | 6. Project Execution

 This technique is best used if there are unproductive subgroups or cliques within the team that need to be
moved around.
• Managerial intervention is allocating decision-making to management, thereby removing the team’s
involvement. This technique is one that should be used sparingly, as it implies to the team that they need
guidance and cannot move forward without management getting involved, which can reduce their
morale and lead to further issues.
• Exit is the voluntary or involuntary removal of a team member and should only be used as a last resort. If
the differences and challenges have proven to be so great that an individual on the team can no longer
work productively with the team, it may be necessary to remove the team member in question.

There are some people who seem to be innately aware of and able to work with cultural differences on teams
and in their organizations. These individuals might be said to have cultural intelligence. Cultural intelligence
is a competency and a skill that enables individuals to function effectively in cross-cultural environments.
It develops as people become more aware of the influence of culture and more capable of adapting their
behaviour to the norms of other cultures. In the IESE Insight article Cultural Competence: Why It Matters and
How You Can Acquire It, the authors, Yih-teen Lee and Yuan Liao, assert that multicultural leaders may relate
better to team members from different cultures and resolve conflicts more easily.18
As a project leader of a multicultural team, there are a few best practices that the authors recommend for
honing cross-cultural skills.
The first is to broaden your mind—expand your own cultural channels (travel, movies, books) and surround
yourself with people from other cultures. This helps to raise your own awareness of the cultural differences and
norms that you may encounter.
Another best practice is to develop your cross-cultural skills through practice and experiential learning. You
may have the opportunity to work or travel abroad, but if you do not, then familiarizing yourself with the
company’s cross-cultural members or foreign visitors will help you to practice your skills.

Virtual Project Teams

Virtual project teams are comprised of people that are not co-located in the same physical environment.
All the work produced by the team is done through the use of information technology that facilities virtual
collaboration. There are many advantages and disadvantages of virtual project teams. Some of the key
advantages and disadvantages are listed below:

Advantages Disadvantages

Cost savings Social isolation of team members who work virtually

Greater access to a diverse labour force not encumbered by Potential for lack of trust among team members and the
8-hour workdays organization when communication is limited

Reduced collaboration among separated team members

Decreased response time to customers
due to lack of social interaction

Less harmful effects on the environment

The advantages create compelling benefits that are easy to accept. However, the disadvantages require very
intentional planning and frequent team-building activities to overcome. During project initiation, when the
infrastructure of the project is being developed, the project team should identify their collaboration
requirements and select information technology that will be adequate in fulfilling their needs. The technology
must be widely accepted and easy to use. Training should be provided to all members of the project team,
including stakeholders who are not involved in the day-to-day activities associated with producing the
deliverables. Training can help overcome individual resistance to new technology. Lastly, it is very easy for team

6. Project Execution | 129

members to “disappear” in the vastness of virtual communication. Successful project leaders leading virtual
teams regularly schedule short but impactful team connection sessions that help the team build trust and
overcome feelings of isolation.

Working with Individuals

Project leaders that have been successful in creating a high-performing team not only have the skills needed
to lead groups of people, they are also effective in working intimately with individuals. Working with individuals
involves dealing with them both tactically (task-oriented) 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.

Emotional Intelligence

Emotions are both a mental and physiological response to environmental and internal stimuli. Leaders must
understand and value their emotions to appropriately respond to the Project Sponsor, project team, and project
environment.
Emotional intelligence includes the following:

• Self-awareness
• Self-regulation
• Empathy
• Relationship management

Emotions are important in generating energy around a concept, building commitment to goals, and
developing high-performing teams. Emotional intelligence is an important part of the project leader’s ability to
build trust, and establish credibility or open dialogue with project stakeholders. Emotional intelligence is critical
for project leaders, which is why the more complex the project profile, the more important the project leader’s
emotional intelligence becomes to project success.

Personality Types

Personality types refer to the differences among people in such matters as motivation, information processing
(for example, how experiences influence the way people perceive the environment and how people develop
filters that allow certain information to be retained while other information is excluded), conflict styles, and so
forth. Understanding the differences among people is a critical leadership skill. Understanding your personality
type as a Project leader will assist you in evaluating your tendencies and strengths in different situations.
There are many personality-type tests that have been developed to explore different aspects of people’s
personalities. Some project leaders use these tests as a team-building tool during project start-up. This is
typically a facilitated work session where team members take personality inventories, such as the Myers-
Briggs Type Indicator, and share with the team how they process information, their preferred communication
approaches, and the decision-making style they possess. This allows the team to identify potential areas of
conflict, develop communication strategies, and build an appreciation for the diversity of the team before the
difficult work begins. Two commonly used personality assessment tools will be explored below.
The Myers-Briggs Type Indicator (MBTI) is one of the most widely used tools for exploring personal
preference. It is often referred to as simply the Myers-Briggs. Based on the theories of psychologist Carl Jung,

130 | 6. Project Execution

the MBTI uses a questionnaire to gather information on the ways individuals prefer to use their perception and
judgment. Perception represents the way people become aware of people and their environment. Judgment
represents the evaluation of what is perceived. People perceive things differently and reach different
conclusions based on the same environmental input. Understanding and considering these differences is
critical to successful project leadership.
The MBTI identifies 16 personality types based on four continuums. The preferences are between pairs of
opposite characteristics and include the following dichotomies:

• Extroversion (E) — Introversion (I)

◦ Describes a preference for focusing on the outer (E) or inner (I) world
• Sensing (S) — Intuition (N)

◦ Describes a preference for approaching and internalizing information

• Thinking (T) — Feeling (F)

◦ Describes a preference for decision making

• Judging (J) — Perceiving (P)

◦ Describes a preference for planning

For example, an ISTJ is a Myers-Briggs type who prefers to focus on the inner world, prefers logic, and likes to
decide quickly. It is important to note that there is no “best” type and that effective interpretation of the Myers-
Briggs requires training. The purpose of the Myers-Briggs is to understand and appreciate the differences
among people. It is important to note, however, that people do not neatly fall into these dichotomies. Many
Myers-Briggs tests provide percentages for the traits; for example, someone who is an ISTJ may receive 99% on
introversion and 1% on extroversion, while another receives 51% on introversion and 49% on extroversion.
Another theory of personality typing is the DISC method, which rates people’s personalities by testing a
person’s preferences in word associations in the following four areas:

• Dominance/Drive —relates to control, power, and assertiveness

• Inducement/Influence —relates to social situations and communication
• Submission/Steadiness —relates to patience, persistence, and thoughtfulness
• Compliance/Conscientiousness —relates to structure and organization

Remember: personality traits reflect an individual’s preferences, not their limitations. It is important
to understand that individuals can still function in situations for which they are not best suited
according to their personality assessment results. It is also important to realize that you can change
your leadership style according to the needs of your team and the particular project’s attributes and
scope.

For example, a project leader who is more “thinking” than “feeling” in MBTI would need to work
harder to be considerate of how team members who are more “feeling” may react if they were singled
out in a meeting because they were behind schedule.

In evaluating these tools, there a number of important considerations. The first is how willing the
project team is to participate. Does the project team see value in understanding the personality types
of their colleagues? Are they willing to share information about themselves? How long does the
assessment take to complete? Before purchasing one of the available tools, project leaders should

6. Project Execution | 131

 discuss the benefits of using this approach with their team and then select the tool that is most
beneficial for the team.

Motivation
Understanding what motivates people is another critical leadership skill. In the early 1900s, Fredrick Winslow
Taylor was a mechanical engineer widely known for his methods of improving worker productivity. He became
one of the first management consultants and his views were based on an underlying theory that work consists
mainly of simple, not particularly interesting, tasks. The only way to get people to do them is to incentivize them
properly and monitor them carefully.19
His management philosophy became known as Taylorism. His philosophy may have been appropriate in
the early 1900s, but the nature of work is fundamentally different in the 21st century. Thankfully, mechanical
engineers have found ways to automate many mundane physical tasks while information technology frees us
from manually “crunching” tons of data. Work is now much more interesting and challenging.
In Drive: The Surprising Truth About What Motivates Us, Daniel Pink argues that rewards based on an “if/then”
approach (if you do this, then you get that) can produce the opposite outcome of what we are striving for.20 If/
then thinking is also referred to as a “carrot-and-stick” philosophy where carrots are incentives and sticks are
punishments. Pink suggests that the reason why this approach does not work is because rewards, by their very
nature, narrow our focus. (see Footnote 20). He concludes that simple monetary rewards can be helpful if there
is a “clear path to a solution” as they help us “race ahead and race faster”. However, many of today’s challenges
lack clear definitions and certainly lack clear simple solutions.
In order for project leaders to effectively motivate people into successfully introducing organizational change
initiatives, they must let go of the use of authority, money, and penalties (extrinsic motivation), replacing them
with autonomy, mastery, and purpose (intrinsic motivation). The purpose behind this shift in motivation is about
helping people discover the inherent satisfaction associated with the activity itself versus external rewards that
can only fuel short-term performance at best.
Autonomy is about trusting individuals to be self-directed. From a project perspective, asking individuals to
help identify and shape the way work will be done is much more likely to lead to project success. Telling people
what to do, when to do it, and how to do it will crush their creativity and can diminish their performance. Giving
people autonomy will significantly improve their motivation.
Mastery is about becoming better at something that matters. Since mastery is impossible to fully realize, it
can be frustrating and alluring at the same time. Ask any professional and they will easily be able to share
the next big “thing” they are trying to master. Think about this in the context of a hobby or sporting activity.
Speak with an avid golfer and they are likely to tell you that landing a 20-foot putt or a 400-yard drive is enough
to keep them coming back the next day, despite missing three easy putts in previous holes. From a project
perspective, it is important for project leaders to be aware of the skills their team members are working towards
mastering. Finding ways to allow them to work on their mastery in this area is another great way to improve
their motivation.
Purpose involves identifying the value of the “cause” people are working toward. It puts the “why” back into
our day-to-day lives. As Daniel Pink succinctly stated in his book, “humans, by their nature, seek purpose.”
Purpose is about contributing and being part of a cause greater than ourselves. More and more people are
no longer motivated by profit maximization. Purpose maximization has become extremely important. In the
context of project management, project leaders must ensure that their teams have a clear understanding of the
value and impact of their project on the organization’s success, on customers, and on the employee experience.

132 | 6. Project Execution

6.2 Scope Validation

The objective of validating scope is to ensure that the project team is meeting stakeholder expectations.
This occurs when the project sponsor (and appropriate designates) formally accepts a deliverable. Obtaining
acceptance (sign-off) can be challenging because it must happen at the deliverable level and at the project
objective level. As outlined in Section 5.2, the approach taken to plan a project’s scope depends on the
development methodology being used.
If the solution can be well-defined upfront, the predictive/waterfall development methodology would be
used and a detailed scope statement can be produced to guide the development efforts of the whole project.
In contrast, some project teams know that the end solution is unclear and, therefore, the scope is unclear.
Project teams would use an adaptive development approach in these situations. The end solution, and hence
the scope, is defined in an iterative or incremental fashion. By definition, scope is very fluid.
Aside from the unique timing differences of when the scope is determined and validated, both development
methodologies require the project team to confirm stakeholder expectations are being met. This occurs by
reviewing the deliverables produced by the project with the project sponsor (and appropriate designates).
These reviews may be held through live demonstrations of what has been built, depending on the nature of the
project. Before the formal deliverable review occurs, project teams will have assessed the quality of the work
performed to confirm it is ready for stakeholder review.
As each deliverable is reviewed, it is also important for the project leader to confirm the project team has
the necessary resources and time to develop the remaining work that is expected in the future. Further, it
is possible that deliverable reviews will result in the identification of new requirements. When this occurs,
this is considered a “change request” if the predictive/waterfall approach was used. In adaptive development
methodologies, such as agile, new requirements are expected.

6.3 Dealing with Change

Change is a common occurrence on projects. Since projects require the integration of many different
components, such as human resources, communication, and vendor management, change in one of these
components often has a ripple effect throughout the entire project. Effective change management addresses
the full effect of change and allows the project leader to understand the impact of change on the project’s
objectives.
Duration and cost estimates can frequently change. Despite best efforts to estimate as accurately as possible,
things can and do go wrong. Resource shortages are difficult to anticipate but are common. In addition,
collaboration time (time for input/discussion) can be very challenging to estimate because stakeholders are
often busy people with conflicting schedules. When this collaboration time finally occurs, it may be much later
than the project team hoped for and this would be largely out of their control. As such, it is important to update
original estimates to reflect the new reality.
Project leaders must be constantly examining for what has changed or what should change in order to
successfully achieve the project’s objectives. When the need for change is discovered, it is important that its
full impact is assessed and the appropriate team communication occurs as quickly as possible. In addition,
the project team must understand the priorities and trade-offs in a project. These priorities will impact how
and when change is introduced. For instance, on projects where the timeline is the most important constraint,
project teams will attempt to protect the schedule by making trade-offs with the budget, scope, and/or quality.
An impact assessment is done before actions are taken. The assessment would lead to recommendations which
are then provided to the project sponsor (and appropriate designates) in order for decisions to be made with
stakeholder involvement.

6. Project Execution | 133

 It is important to note that the development methodology used also has a big impact on how change is
introduced. Change is more difficult to manage when predictive/waterfall methodologies are used because it is
often not expected or considered when commitments have already been made. Change is expected when an
adaptive approach was selected for the project.
When the predictive/waterfall development methodology is used, it is critical for the project team to discuss
change management processes with the project sponsor during the planning phase. High-complexity projects
will often document these decisions in a project management plan. Plans of this nature facilitate decision-
making with project sponsors around thresholds, approval requirements, and communication preferences. If
the change will alter the project’s duration, budget, scope, and/or quality, most project sponsors will want to
ensure their approval to proceed is obtained before the change is made.. This approach is largely unnecessary
when an adaptive methodology is being used. This is because the product owner is involved in the planning
of every iteration. In fact, the product owner decides the scope of each iteration while trying to maximize
organizational value and adhering to scheduling and budget constraints.
When the predictive/waterfall) development methodology is used, the change process is initiated with a
change request. This is a document that identifies what the change is about, its impact on the project, the
organizational value, and what would be required to implement it. Not all changes are approved as they may
not provide enough organizational value, be affordable, and/or be feasible from a scheduling perspective. If the
change is approved, it is sent back to the project team for implementation.

References
1
Yukl, A. (1981). Leadership in organizations. Prentice-Hall.
2
Kellerman, B. (1984). Leadership: Multidisciplinary perspectives. Prentice-Hall; Landy, F. L. (1985). Psychology
of work behavior. Dorsey Press.
3
Burns, M. (1978). Leadership. Harper & Row; Bass, B. M. (1985). Leadership and performance beyond
expectations. Free Press.
4
Daft, L. (2018). The Leadership Experience (7th ed.). Cengage Learning.
5
Baum, R., Locke, E. A., & Kirkpatrick, S. A. (1998). A longitudinal study of the relation of vision and vision
communication to venture growth in entrepreneurial firms. Journal of Applied Psychology, 83, 43-54.
6
Bennis, W. (1989). On becoming a leader. Addison-Wesley Pub. Co.
7
Judge, A., & Bono, J. E. (2000). Five-factor model of personality and transformational leadership. Journal of
Applied Psychology, 85, 751-765.
8
Pillai, R., Schriesheim, C. A., & Williams, E. S. (1999). Fairness perceptions and trust as mediators for
transformational and transactional leadership: A two-sample study. Journal of Management, 25, 897-933.
9
Manz, C., & Sims, H. P. Jr. (1987). Leading workers to lead themselves: The external leadership of self-managed
work teams. Administrative Science Quarterly, 32,106-129.
10
De Smet, A., Lurie, M., & St George, A. (2018, October). Leading agile transformation: The new capabilities
leaders need to build 21st-century organizations. McKinsey & Company.
11
Lencioni, P. (2002). The five dysfunctions of a team (p. 188). Jossey-Bass.
12
Larson, E. W., & Gray, C. (2021). Project management: The managerial process (8th ed.). McGraw Hill
Education.
13
Inam, H. (2018). Managing team conflict. LinkedIn Learning. https://www.linkedin.com/learning/managing-
team-conflict/welcome?u=2169170
14
Katzenbach, J. R., & Smith, D. K. (2005). The discipline of teams. Harvard Business Review.
15
Scholtes, P. R., Joiner, B. L., & Streibel, B. J. (2018). The team handbook (3rd ed.). GOAL/QPC.
16
Rock, D., & Grant, H. (2016, November). Why diverse teams are smarter. Harvard Business Review.
17
Brett, J., Behfar, K., & Kern, M. (2007). Managing multicultural teams. Harvard Business Review.

134 | 6. Project Execution

18
Lee, Y., & Liao, Y. (2015). Cultural competence: Why it matters and how you can acquire it. IESE Insight.
19
Kanigel, R. (2005). The one best way: Fredrick Winslow Taylor and the enigma of efficiency. MIT Press.
20
Pink, D. H. (2009). Drive: The surprising truth about what motivates us (pp. 22-57). Riverhead Books.

6. Project Execution | 135

7. Monitoring and Controlling
7.1 What is Monitoring and Controlling?

Monitoring and controlling 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 should begin in the planning phase because it
is easy to get off track with planning efforts. When the predictive/waterfall development methodology is used,
the team is monitoring 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.
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 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 report?
6. Who should receive the reports?

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
on budget are of particular interest. 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), they 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 culture influences 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 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.
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 4). Depending on the priority and duration of the project, the reporting
frequency could be daily, weekly, monthly, or quarterly.
There are three different types of project reports:

1. Status reports – where the project stands at a specific point in time

136 | 7. Monitoring and Controlling

2. Progress reports – what the project team has accomplished during a certain period
3. Forecasts – future project status based on current project status and known trends

A common and simple approach to sharing project status is the stoplight. Red means the project will not
accomplish its objective(s). Yellow means the project may not accomplish the objective(s). Green means the
project is on track to accomplish its objectives.

Exhibit 7.1: Example of a project status report utilizing stoplight symbology.

The status of a project is subject to change very quickly because unexpected risks can surface at any moment
and new opportunities may be discovered.
Project leaders will develop a reporting format that meets the needs of the stakeholders and quite likely
includes a combination of the above types.
Experienced project leaders know that project success is much more than delivering on time, on budget, and
within the defined scope and quality parameters. This is not enough. A project that fulfills those parameters
while failing to address the organizational need that led to its initiation would be considered unsuccessful. This
is an extremely important concept to understand as it widens the lens of what project leaders monitor and how
they respond to change. This leads to an important distinction – qualitative versus quantitative monitoring.

7. Monitoring and Controlling | 137

7.2 Qualitative and Quantitative Monitoring

Qualitative monitoring, as its name implies, involves measuring quality rather than quantity. Quantitative
monitoring uses metrics and indexes to assess project performance.
In the context of project management, qualitative monitoring addresses the following questions:

• Is the team delivering on the intended scope in order to fulfill the project’s objectives and organizational
needs?
• Is the quality of the deliverables meeting stakeholder expectations?
• Are stakeholders engaged?
• Are project communications effective?
• Are the expectations outlined in procurement contracts being adhered to by vendors?
• Are risks and opportunities being effectively managed by the team?
• Has the team become high-performing and are individual team members meeting performance
expectations?
• Are resources being effectively managed and available as expected?

Project leaders use a variety of monitoring tools and techniques. The complexity of the project is a key
consideration in determining the required tools and techniques.

Scope monitoring and control

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 scope
change is 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. It is possible that changes will 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. It is important for
project leaders to reserve judgement 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.

138 | 7. Monitoring and Controlling

Quality monitoring and control

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 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 is reviewing 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 problem is to begin by understanding its root cause(s). Cause-
and-effect diagrams, also referred to as fishbone or Ishikawa diagrams, are very effective for this purpose.
Section 5.8 provides an example of a cause and effect diagram.

Stakeholder management

Project teams can not control stakeholders. However, they can significantly influence their level of engagement.
During the planning phase of a complex project, the stakeholder register may have been created. A stakeholder
register 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. The emphasis is on keeping high interest, high power/influence
stakeholders very informed of the project’s progress.
During the monitoring and control phase, the project team is looking for new stakeholders and is monitoring
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. Some stakeholders may have
become unresponsive to the project team’s requests. When this occurs, the project leader’s relationship-
building skills will 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.

Communications management

Communication is one of the most effective ways to keep 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

7. Monitoring and Controlling | 139

project team’s communication efforts throughout the project. 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.

Procurement management

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.

Risk management

Monitoring and controlling risks involves implementing the risk management plan identifying during the
planning phase. 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. Risk responses can be implemented in any phase of the
project as long as documentation is kept up to date.
Many project teams established contingency plans and contingency funds to account for risks that cannot
be anticipated. When these unanticipated risks materialize, the project team will determine if the contingency
plans and/or funds will address these risks and, if so, they will be implemented. If contingency plans/funds
will not 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.

Resource management

Projects require labour and non-labour resources in order to produce the desired outcomes. During monitoring
and controlling, the project leader is assessing the effectiveness of both types of resources.
With respect to the project team, efficient project leaders are continuously assessing 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. 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. 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.

140 | 7. Monitoring and Controlling

 The availability and effectiveness of non-labour 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, which is a key consideration during the planning phase.
Qualitative monitoring is also very important to the overall success of the project. Earned value management
(EVM) is a key technique used in this type of monitoring and will be examined in further depth in Section 7.3.

7.3 Introduction to Earned Value Management (EVM)

Monitoring the Schedule and Budget During the Project

A project leader must regularly compare the amount of money spent with the budgeted amount and report
this information to key stakeholders. In addition, project leaders must also compare the progress of the actual
work completed with the estimated durations in the project schedule.
The value of EVM can be highlighted through a few scenarios.
Let us assume that a project leader of a medium complexity project is reviewing the schedule with their
team and concludes that they are achieving the project’s milestones. The team feels they are on track as a
result. Therefore, the project leader confirms the project is on track.
Is the project on track?
We cannot truly know upfront if a project is on track. It may appear that milestones are being achieved, but
perhaps this is so because the external resources on the team are spending a considerable amount of time
outside their regular business hours to achieve these milestones. This would only become evident if the project
leader reviewed the invoices paid to date.
Now, let us assume that the same project leader is reviewing the budget with their team and concludes that
the invoices received are for the expected amounts. The team feels they are on track as a result. Therefore, the
project leader confirms the project is on track.
Is the project on track?
Again, we cannot truly know if the project is on track. It is possible that actual costs incurred are as expected,
but perhaps the work is not being completed as planned. This would become evident if the project leader
reviewed the schedule.
It is important to integrate our schedule and budget and this is the value of the EVM approach.

Reporting Budget Progress on John’s Move

John estimated that the move would cost about $1,500 and take about 16 days. However, eight
days into the project, John has spent $300. John reports to his friends that the project is going well
because he is halfway through the project while only having spent 20% ($300/$1,500) of his budget.
John’s friend, Carlita, points out that his report is not sufficient because he did not compare the
amount spent to the budgeted amount for all the activities that should be done by the eighth day.

7. Monitoring and Controlling | 141

 A budget report must compare the amount spent with the amount that is expected to be spent
by that point in the project. Basic measures, such as percentage of activities completed, percentage
of budget spent, and percentage of material units consumed, are adequate for less complex
projects, but more sophisticated techniques, such as EVM, are used for projects with higher
complexity.

Let us assume John’s move was a medium complexity project, so John has decided that EVM was
required to truly understand whether his project is on track.

Description Quantity Total Item Cost (Planned Value)

Lunch 3 $45.00

Small Boxes 10 $17.00

Medium Boxes 15 $35.25

Large Boxes 7 $21.00

Extra Large Boxes 7 $26.25
Short Hanger Boxes 3 $23.85
Box Tape 2 $7.70
Markers 2 $3.00

Mattress/Spring Bags 2 $5.90

Life Straps per Pair 1 $24.95
Bubble Wrap 1 $19.95
Furniture Pads 4 $31.80
Total: $261.65

Table 7.4.1: Planned Value for Lunch and Packing Materials

If you sum the budgeted cost of work performed (BCWP) values up to a specified point in the project schedule,
you have the earned value (EV). Due to the fact that projects occur in ever-changing environments, the amount
spent on an item is often more or less than its estimated budgeted amount. The actual cost (AC) is the sum of
the amounts actually spent on the items as opposed to their planned value (PV).

Comparing PV, EV, and AC in John’s Move on Day Six

John decided to offer to buy Dion and Carlita lunch. Although this was not part of his original plan,
he believed it would be a nice gesture of gratitude. He estimated lunch would cost $45. As it turns
out, Dion and Carlita only wanted a nice salad. Consequently, the lunch cost less than expected.
John makes a stop at a store that sells moving supplies at discount rates. They do not have all the
items he needs, but the prices are lower than those quoted by the moving company. They have a
very good price on lifting straps, so he decides to buy an extra pair. He returns with some of the

142 | 7. Monitoring and Controlling

 items on his list, but this phase of the job is not complete by the end of day six. John bought half of
the small boxes, all of five other items, twice as many lifting straps, and none of four other items.
John is only six days into his project, and his costs and performance are starting to vary from the
plan. As demonstrated below, earned value analysis provides the project with a method for reporting
variations in the progress. Note: quantity of each item is in brackets in the cost column.

Planned Value Earned Value Actual Cost (AC)

Description Cost Cost Cost

Lunch $45.00 (3) $45.00 (3) $35.00 (3)

Small Boxes $17.00 (10) $8.50 (5) $9.50 (5)

Medium Boxes $35.25 (15) $35.25 (15) $28.00 (15)

Large Boxes $21.00 (7)

Extra-Large Boxes $26.25 (7)

Short-Hanger Boxes $23.85 (3)
Box Tape $7.70 (2) $7.70 (2) $5.50 (2)

Markers $3.00 (2) $3.00 (2) $2.00 (2)

Mattress/Spring Bags $5.90 (2) $5.90 (2) $7.50 (2)
Life Straps per Pair $24.95 (1) $24.95 (1) 38.50 (2)
Bubble Wrap $19.95 (1)
Furniture Pads $31.80 (4) $31.80 (4) 28.50 (4)

$261.65 $162.10 $154.50

Table 7.4.2: Planned Value, Earned Value, and Actual Cost

Note: a time-phased budget is often created to depict the project’s expenditures over time. The
time-phased budget for John’s move could depict daily costs leading up to the completion of the
move. The time-phased budget is created by combining the duration of the tasks with their cost.
The cost of the task would be spread out over the duration of the task. However, for the purposes of
this course, the table above is sufficient.

The original schedule called for spending $261.65 (PV) by day six. Based on the estimates, the
value of work completed was $162.10 (EV), but the actual cost was only $154.50 (AC).

Using the above analysis, John can now determine how far off he is from his original plans. Let us
examine how variances are determined in EVM.

Schedule Variance

The difference between planned and actual progress is the schedule variance. The schedule variance (SV) is
the difference between the EV and the PV. It can be expressed as a formula:

SV = EV − PV

If less value has been earned than was planned, the schedule variance is negative, which means the project

7. Monitoring and Controlling | 143

is behind schedule. Negative numbers indicate a negative situation whereas a positive variance indicates a
positive situation (ahead of schedule).

The Schedule Variance on John’s Move

Planning for John’s move calls for spending $261.65 by day six, which is the PV. The difference
between the PV and the EV is the SV.

Therefore, John’s SV = $162.10 – $261.65 = -$99.55

Since a negative schedule variance indicates the project is behind schedule, John’s move is behind
schedule.

Cost Variance

The difference between EV and AC is the cost variance (CV). It can be expressed as a formula:

CV = EV – AC.

If the cost variance is a negative number, this indicates a negative situation or quite simply, the project is over
budget. If the cost variance is a positive number, this indicates a positive situation and the project is under
budget.

The Cost Variance on John’s Move:

The difference between the EV of $162.10 and the AC of $154.50 is the CV.

Therefore, John’s CV = $162.10 – $154.50 = $7.60

Since this is a positive number, John’s move is under budget.

When significant variances occur, this signals that corrective action is required from the project leader to bring
the project back on track, and deliver it within the original schedule and budget. When presenting the results
of EVM to key stakeholders, they are less interested in the numbers themselves and more interested in their
meaning. Due to this, summarizing data succinctly is an important skill for the project leader. In addition, the
project leader must be able to provide recommendations to get the project back on track.
The schedule variance provides the team with the amount of time that the project activities are behind (or
ahead of) schedule while the cost variance provides the team with the amount that the project is exceeding (or
not fully using) its budget. However, these variances do not provide the team with an idea of how the amounts
compare to the total budget and total project duration. Let us examine the role of indexes in EVM.
Cost and Schedule Performance Indexes

144 | 7. Monitoring and Controlling

 Indexes measure efficiency. In the context of project budgets, the cost performance index (CPI) measures
the cost efficiency of the work accomplished to date. The schedule performance index (SPI) measures the
scheduling efficiency. Indexes are expressed as ratios.
The CPI uses the same variables as the CV but expresses them as a ratio. The ratio of EV to AC gives an
indication of how much of the budget has been consumed.

CV = EV – AC
CPI = EV/AC

The SPI uses the same variables as the SV but also expresses them as a ratio. The ratio of EV to PV gives an
indication of how much of the project is completed.

SV = EV – PV
SPI = EV/PV

Since indexes are a measure of efficiency, once the indexes have been calculated, we will be able to
draw the following conclusions:

Index Cost Performance Index (CPI Performance Index (SPI)

> 1.00 Under budget Ahead of schedule

1.00 On budget On schedule

<1.00 Over budget Behind schedule

The Cost Performance Index on John’s Move

In the John’s move example, at the end of day six, EV = $162.10 and AC = $154.50.

CPI = $162.10 ÷ $154.50 = 1.05. Since the value is greater than one, John is more efficient than
planned and, as a result, the project is under budget. This is aligned with the conclusion from the CV
which was $7.60 (recall that a positive number means a positive outcome and in this case, it means
under budget). John is getting more value for his money than planned for the tasks scheduled by
day six.

The Schedule Performance Index on John’s Move

At the end of day six, PV is $261.65.

SPI = EV/PV or $162.10 ÷ $261.65 = 0.62. Since it is less than one, this indicates the project is behind

7. Monitoring and Controlling | 145

 schedule. This also aligns with the conclusion from the SV which was -$99.55, (recall that a negative
number signals a negative situation and in this case, it means behind schedule).

Exhibit 7.2: Graph representing that the variance between PV and EV is the SV while the variance between
AC and EV is the CV.

Estimated Cost to Complete the Project

Partway through the project, the project leader evaluates the accuracy of the cost estimates for the completed
activities and uses that experience to predict how much money will be required to complete the unfinished
activities. This is called the estimate to complete (ETC).
To calculate the ETC, the project leader must decide whether the CVs observed in the estimates to date
are representative of the future. For example, if unusually bad weather causes increased cost during the first
part of the project, the same weather patterns may not be expected for the remainder of the project. If the
project leader decides that the cost variance up to a certain point in the project is atypical (not typical), then the
estimate to complete is the difference between the original budget for the entire project, known as budget at
completion (BAC) and the EV up to that point. It can be expressed as a formula:

ETC = BAC − EV.

146 | 7. Monitoring and Controlling

 Estimate to Complete John’s Move

For his move, John was able to buy most of the items at a discount house that did not have a
complete inventory, and he chose to buy an extra pair of lift straps. He knows that the planned
values (PVs) for packing materials were obtained from the price list at the moving company where
he will have to buy the rest of the items, so those two factors are not likely to be typical of the
remaining purchases. The reduced cost of lunch is unrelated to the future costs of packing materials,
truck rentals, and hotel fees. John decides that the factors that caused the variances are atypical.

In Section 5.5, John used the bottom-up method to estimate the total cost of the project at $661.25
(the BAC). The estimate to complete (ETC is the BAC minus the EV after 6 days.

Expressed as a formula:

ETC = BAC – EV

ETC = $661.25 − $162.10 = $499.15

If the project leader decides that the CV is caused by factors that will affect the remaining activities, such as
higher labour and material costs, then the ETC must be adjusted by dividing it by the CPI.
In John’s move example, if we concluded the factors leading to the CV were typical, we would adjust the ETC
by dividing it by the CPI, the formula is ETC = (BAC − EV) ÷ CPI.

Adjusted ETC for John’s Move

($661.25 – $162.10) ÷ 1.05 = $475.38Since we determined the project was trending under budget
with a CPI of 1.05, if we expect the factors causing the project to be under budget to continue, we
expect the adjusted ETC to be lower than the unadjusted ETC. In our John’s move example, the
adjusted ETC is $23.77 lower ($499.15 – $475.38).

Estimating Final Project Cost

The estimate to complete (ETC) can be used to determine the new final project cost, which is the estimate at
completion (EAC). This is done by adding the actual costs (AC) incurred to the ETC. It can be expressed as a
formula: EAC = AC + ETC.

7. Monitoring and Controlling | 147

 Estimate at Completion for John’s Move

The revised EAC for John’s move after 6 days is:

EAC = $154.50 + $499.15 = $653.65.

This is good news for John as his move will cost less than originally planned.

Estimating Final Project Completion Date

Let us assume John’s detailed planning work led to the conclusion that his move would take 15 days. After day
six, he used EVM to determine that he is behind schedule. As noted above, the SPI is 0.62. If we assume that the
lost time cannot be recovered, a simple way to predict the project’s new duration is to use the SPI as a measure
of future schedule efficiency and apply it to the project’s original duration.
New time estimate = original time estimate (15 days) ÷ SPI (0.62) = 24 days

John’s
Term Description Formula
Move

Actual Cost (AC) The money actually spent on projects up to the present. –
$154.50

Budget at Completion Original budget for the entire project (same as the total
–
(BAC) BCWS)
$661.25

Planned Value (PV) Sum of the estimates for work done up to the present –
$261.65

Earned Value (EV)* Sum of estimates for work actually done up to the present –
$162.10

Cost Variance (CV) Difference between earned value and actual cost EV − AC $7.60

Cost Performance Index

Ratio of earned value to actual cost EV ÷ AC 1.05
(CPI)

Schedule Variance (SV) Difference between earned value and planned value EV − PV -$99.55

Schedule Performance
Ratio of earned value to planned value EV ÷ PV 0.62
Index (SPI)

Estimate to Complete Money to complete the project if early cost variance is (BAC − EV) ÷
$499.15
(ETC) atypical CPI

Estimate at Completion
Revised estimate of total project cost AC + ETC $653.65
(EAC)

148 | 7. Monitoring and Controlling

 Table 7.4.4: Summary of Terms and Formulas for Earned Value Analysis
—
* Earned Value is the % complete (for the task) multiplied by the total planned value (for the task)
To summarize the table above:

• Extra money is allocated in a contingency fund to deal with activities where costs exceed estimates. These
overruns may have been identified while creating the risk management plan. Funds are allocated in a
management reserve in case a significant, unanticipated opportunity or challenge occurs that requires
change of scope, but funds are needed immediately before a scope change can typically be negotiated.
• Schedule variance (SV) is the difference between the part of the budget that has been spent at a specific
point in time (EV) versus the part that was planned to be spent at that point in time (PV). Similarly, the cost
variance is the difference between the EV and the actual cost (AC).
• The schedule performance index (SPI) is the ratio of the earned value and the planned value. The cost
performance index (CPI) is the ratio of the earned value (EV) to the actual cost (AC).
• The formula used to calculate the amount of money needed to complete the project (ETC) depends on
whether or not the cost variance to this point is expected to continue (typical) or not (atypical). If the cost
variance is atypical, the ETC is simply the original total budget (BAC) minus the earned value (EV). If they
are typical of future cost variances, the ETC is adjusted by dividing the difference between BAC and EV by
the CPI.
• The final budget is the actual cost (AC) to this point plus the estimate to complete (ETC).

Corrective action on John’s Move:

EVM is a means to an end. The end is knowing which action needs to be taken as a result of the
analysis performed. For example, John’s move is behind schedule and under budget. Before any
action is taken, it is important to understand the priorities of the project. In this case, John would like
to be in his new home in advance of beginning his new job. Therefore, he would prioritize the
schedule over the budget if a trade-off was essential. Fortunately, in his current situation, since he is
under budget, he could use some of the savings he has generated to make up for the schedule
delays. His first step would be to revisit his future estimates and confirm whether he should
anticipate any further delays and/or cost savings. Revising his estimates based on the new
information he has received in the first six days of his move allows him to maintain realistic plans.

John has options. For instance, he may decide to use the existing savings he has generated and
hire an assistant to help him buy the remaining items needed. The assistant would help him get
things done much faster. Since he has not generated much savings, he may decide that it is
worthwhile to spend more on his move than initially planned in order to achieve his timeline
objective. In this case, he would be intentionally be planning to go over budget. Since he is only
accountable to himself, gaining stakeholder approval would be easy. This is often not the case, so
project leaders must use effective change management processes when similar situations occur.

In conclusion, earned value management gives project teams the ability to take corrective action before it is
too late.

7. Monitoring and Controlling | 149

7.4 The Importance of Soft Skills in Keeping Projects on Track

Discenza and Forman’s research identified seven common issues that may cause project failure1:

1. Lack of focus on business value

2. Lack of accountability for clear, measurable results
3. The wrong methodology was used
4. The customer only engaged upfront
5. Project leadership failed to engage and motivate the project team
6. Team members lacked access to the tools, techniques and subject matter experts required
7. Inconsistent project check-ins that lack qualitative and quantitative measures

The interpersonal skills of the project leader are critical to project success. Effective and timely communication
is the underlying theme.

References
1
Discenza, R., & Forman, J. B. (2007). Seven causes of project failure: how to recognize them and how to
initiate project recovery. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Project
Management Institute.

150 | 7. Monitoring and Controlling

8. Project Closure
Overview

During the final closure, or completion phase, the emphasis is on releasing the final deliverables to the project
sponsor (and appropriate stakeholders), submitting necessary project documentation to the department(s)
accountable for maintaining the solution(s), terminating supplier contracts, and releasing project resources. If
the predictive/waterfall methodology was used, the documentation required to effectively support the solution
will likely be shared in the closure phase. However, if an adaptive methodology was used, essential
documentation may be released as the solution’s capabilities are developed.
Formally communicating the closure of the project to all stakeholders is a vital task for the project leader and
project sponsor. The last remaining step is to conduct a post-implementation review, including a discussion
about the lessons learned. Through this type of analysis, the wisdom of experience can be shared with future
project teams, just as this team may have used lessons learned from past projects as a guide during their own
planning phase.

8.1 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, perhaps the benefit is the incremental sales associated with launching a new
product or service, or it may be the increased employee satisfaction associated with introducing of 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.
In all cases, the organization has greatly deliberated how the business benefits will be realized. Many
organizations create a business benefit realization plan, whereas other organizations include the business
benefit realization approach as part of their project management plan. Either way, the following should be
considered:

• What are the benefits? In stating the benefits, the SMART principle should be used in that they should be
specific, measurable, acceptable (and therefore assignable), realistic and time-bound (covered in Chapter
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 required information.
• Who is accountable for tracking and communicating the business benefits?
• 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?
• When are the business benefits expected to be fully realized?

8.2 Closure activities

Project completion is often the most neglected phase of the project life cycle. Once the work is complete, it is
easy to pack things up, throw files in a drawer, and move right into the initiation phase of the next project. Many

8. Project Closure | 151

organizations re-assign people before they have fully completed their duties on a project. This makes it even
more challenging to finalize the project closure activities effectively.
The key activities in project completion are gathering project records, disseminating information to formalize
acceptance of the product, service, or result, and performing project closure. The project leader must review
project documents to assure they are current. This is commonly overlooked. For example, perhaps some
scope change requests were implemented that altered some of the characteristics of the final product. If so,
the project information should be updated to reflect this. In addition, it is important to update the resource
assignments as well. Some team members will have come and gone over the course of the project. Since
many project team members return to their respective functional departments upon project completion,
maintaining an accurate list of resources, their roles and responsibilities, and any confidential performance
information can be helpful to the functional manager when future performance evaluations are conducted.
Once the project deliverables have been completed and the appropriate documentation transferred to the
appropriate functional teams maintaining the solution(s), formal acceptance is requested from the project
sponsor and any designated key stakeholders.

Contract Closure

Contracts end just as projects end. Contract closure is concerned with completing and settling the terms of
the contracts in place during the project. It supports the project completion process because it determines if
the work described in the contracts was actually completed accurately and satisfactorily. Keep in mind that not
all projects are performed under contract so not all projects require the contract closure process. Obviously,
this process applies only to those phases, deliverables, or portions of the project that were performed under
contract.
Contract closure updates the project records, detailing the results of the work performed by vendors on the
project. Contracts may have specific terms or conditions for completion. Reviewing these terms or conditions
before closing out vendor contracts prevents delays in the closure process.
One of the purposes of the contract closure process is to provide formal notice to the vendor, seller, usually in
writing, that the deliverables are acceptable and satisfactory.. If rejection occurs because the product or service
does not meet the expectations, the vendor must correct the problems before a formal acceptance notice is
issued to them. During the planning phase, the payment system developed for each vendor should allow for
the possibility that rework may be required and as such, withholding some of the contract’s value will assure
the project leader that this work is completed in accordance with the agreed-upon terms.

Releasing the Project Team

Releasing project team members is not an official process. However, it should be noted that at the conclusion of
the project, team members will go back to their functional managers or get assigned to a new project. Project
leaders must keep their managers or other project leaders informed as they move towards project completion
so there is adequate time to prepare for the return (or transfer) of the employee.

Archiving of Documents

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 subject to potential tax reviews or lawsuits must be kept

152 | 8. Project Closure

in accordance with the organization’s record-keeping policy. Organizations will have legal document storage
and retrieval policies that apply to project documents and these policies must be followed.
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, their expiration date should be determined so they can be
destroyed at some point in the future.

8.3 Project Reviews and Lessons Learned

Post Implementation Reviews

Before the team is dissolved and begins to focus on their next assignment, a review is conducted to capture
the lessons that can be learned from this project, often called a lessons-learned meeting. It can occur in many
different formats. In order to make the most of the meeting, project leaders should begin the discussion by
reviewing the project’s objectives and concluding if these objectives were successfully met. The context for a
post-implementation review meeting is the success or failure of the project. If the project was a success, the
discussion can centre 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 centres on the causes of failure. 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.

8. Project Closure | 153

9. Appendix
9.1 Project management mathematics

Financial Calculations used in Project Selection

In many new project endeavours, determining if a project is financially feasible is an important first step. Three
common financial calculations are used to do this: net present value (NPV), rate of return (ROI), and payback
analysis.

NPV

A dollar earned today is worth more than a dollar earned one or more years from now. The NPV of a time series
of cash flows considers both the incoming and outgoing streams of money. The incoming streams represent
the benefits associated with the project. The outgoing streams represent the costs or investments made in the
project. Each cash inflow/outflow is discounted back to its present value (PV) and then summed. Net present
value is the sum of the discounted cash inflows minus the sum of the discounted cash outflows.
NPV is a standard method for using the time value of money to appraise long-term projects. The discount
rate is the rate of return that money could earn elsewhere. As such, it is often referred to as the hurdle rate.
Expressed as a formula, it is as follows:

Rt
———-
(1 + i)t

where:

• t is the time of the cash flow

• i is the discount rate (the rate of return that could be earned on an investment in the financial markets
with similar risk; the opportunity cost of capital)
• Rt is the net cash flow (i.e., cash inflow − cash outflow, at time t)

NPV is an indicator of how much value an investment or project adds to an organization. With a particular
project, if NPV is a positive value, the project is generating a positive cash inflow. If NPV is a negative value, the
project investment exceeds the return. In financial theory, if there is a choice between two mutually exclusive
alternatives, the one yielding the higher NPV should be selected.

154 | 9. Appendix
If… It means… Then…

The investment
NPV
would add value The project may be accepted.
>0
to the firm.
The investment
NPV would subtract
The project should be rejected.
<0 value from the
firm.

We should be indifferent in the decision whether to accept or reject the project. This project
The investment adds no monetary value. The decision should be based on other criteria (e.g., mandatory
N would neither requirements to complete the project, strategic positioning or other factors not explicitly
PV gain nor lose included in the calculation).
=0 value for the firm.

Table 9.1: Net present value

Periods (years) 6% 8% 10% 12% 14%

1 0.943 0.926 0.909 0.893 0.877

2 0.890 0.857 0.826 0.797 0.769

3 0.840 0.794 0.751 0.712 0.675
4 0.792 0.735 0.683 0.636 0.592
5 0.747 0.681 0.621 0.567 0.519
6 0.705 0.630 0.564 0.507 0.456

7 0.665 0.583 0.513 0.452 0.400

8 0.627 0.540 0.467 0.404 0.351
9 0.592 0.500 0.424 0.361 0.308
10 0.558 0.463 0.386 0.322 0.270

(Take note of the decreasing value of money as the period increases from 1 to 10 years.)
Table 9.2: Net present value

NPV Example

The following example is calculating the NPV of a project at a discount rate of 12%. The project takes five years
to complete with given benefits and costs for each year. In Year 0, there is no benefit to the organization, just an
initial cost of $75,000 with no discount rate. In Year 1, the discount rate is 89%. This means that at 12% assumed
interest, the time value of money says that the $1 today is worth $0.89 in one year, $0.80 in two years, etc. By
calculating the NPV for the benefits and the costs, you subtract the NPV of all costs from the NPV of all benefits.
The final result is a positive value of $105,175.

9. Appendix | 155
 Table 9.3: Table of NPV of costs and benefits (PV factors come from Table 9.2) (accessible version)

Return on Investment

Return on investment (ROI) is a performance measure used to evaluate the efficiency of an investment or to
compare the efficiency of a number of different investments. It is one way of considering profits in relation to
capital invested.
This is calculated by subtracting the project’s costs from the benefits and then dividing by the costs. For
example, if you invest $100 and your investment is worth $110 next year, the ROI is (110 − 100) ÷ 100 = 0.1 or a 10%
return.
In our example above, the investment is $306,425 and the total costs are $201, 175. The ROI calculation would
be ($306,425 − $201,175) ÷ 201,175 = 0.52, or a 52% return. That is considered a nice return on investment.

Payback Analysis

Payback analysis is important in determining the amount of time it will take for a project to recoup its

156 | 9. Appendix
investments. This is the point at which the benefits start to outweigh the costs. The best way to see that is by
charting the cumulative benefits and costs. As you can see in the example in Exhibit 9.1, the cumulative benefits
outweigh the cumulative costs in the second year.

Exhibit 9.1: Payback analysis chart

9. Appendix | 157