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

- Overview and Preface

- 1. Introduction

- 2. Project Selection

- 3. Project Structures and Organizational Culture

- 4. Project Initiation

- 5. Project Planning

- 6. Project Execution

- 7. Monitoring and Controlling

- 8. Project Closure

- 9. Appendix

1

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.

2

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.

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: shelly.morris@senecacollege.ca.

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.

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.

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.

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  i s 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 l eaders  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, “ W ill this change add value to the organization ? ” As a team,  they may ask ,  “ W ill 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 ? ” T hey also frequently ask,  “ A re 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 Profession 2 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 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  w aterfall) 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, t hese 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 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, 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:

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 p roject  l eader .  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. 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  p roject  l eaders  know how to  uniquely  apply the knowledge and skills they  ha ve 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 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.

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.

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

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

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

In addition to these tools and technologies, p roject  l eader s 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   n o t 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, c ollaborative 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   a re able to spend more time talking about project strategy — which is precisely where the bulk of your team’s conversation need s  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 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

3Newman, 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/

4Project 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

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

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

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:

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

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

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

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 Google^3, 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

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

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.

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.

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

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

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

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:

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

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

5. Project Planning

Overview

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

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

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

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

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

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

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

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

1.1 Eliciting Project Requirements

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

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

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

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

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

The Nature of Requirements

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

The End-User Community

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

Technical Requirements

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

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

Regulatory or Industry-Specific Requirements

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

Elicitation Techniques

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

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

- Process flows for the “as is” environment

- Policies and procedures

- Problem/issue logs (including customer complaint logs)

- User cases/stories created for technological implementations

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

- Interviews

- Focus groups

- Facilitated group sessions

- Group creativity techniques, such as:

- Brainstorming

- Mind-mapping

- Observation of clients, customers, and/or end-users

- Questions and surveys

- Group decision-making techniques, such as:

- Seeking consensus (among experts, the project team, the end-user community and so forth)

- Majority rule voting

- Dictatorship (project sponsor or product owner decides)

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

Requirements Traceability Matrix

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

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

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

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

2. Supports effective stakeholder management by understanding a requirement’s source

3. Aids in tracking the status of each requirement, specifically ensuring that requirements are considered in the product or service design and delivered by the end of the project

4. Provides a structure for managing changes, if necessary, to a requirement’s scope

An effective requirements traceability matrix includes the following information:

- Requirements to organizational value and project objectives

- High-level requirements to more detailed requirements

- Requirements to project scope/work breakdown structure

- Requirements to product/service design

- Requirements to product/service development

- Requirements to test strategy and test scenarios

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

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

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

5.2 Scope Management

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

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

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

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

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

Work Breakdown Structure

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

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

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

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

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

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

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

WBS Formatting

Project Name

1.0 Major Deliverable

- 1.1 Sub Deliverable

- 1.2 Sub Deliverable

- 1.3 Sub Deliverable

2.0 Major Deliverable

- 2.1 Sub Deliverable

- 2.1.1 Work Package

- 2.1.2 Work Package

- 2.1.3 Work Package

- 2.1.4 Work Package

- 2.2 Sub Deliverable

- 2.3 Sub Deliverable

3.0 Major Deliverable

- 3.1 Sub Deliverable

- 3.1.1 Work Package

- 3.1.2 Work Package

- 3.1.3 Work Package

- 3.2 Sub Deliverable

- 3.2.1 Work Package

- 3.2.2 Work Package

- 3.3 Sub Deliverable

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

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

1. Confirm who must be involved in the work

2. Identify the tasks to be performed

3. Create a detailed schedule for the tasks, including identifying all the required resources, durations, sequencing, and key monitoring points for measuring success.

4. Identify the cost of completing the work

5. Identify specific assumptions, risks, and issues

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

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

5.3 Resource management

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

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

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

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

Resource Planning

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

5.4 Schedule management

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

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

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

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

Defining Tasks

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

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

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

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

A Case Study: “John’s Move”

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

***

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

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

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

Top-Level Deliverables in Move Planning

1. Plan move

2. Pre-packing

3. Packing

4. Moving

5. Unpacking

6. Project closeout

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

Major Deliverable Decomposed into Smaller Activities

3. Packing

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

- 3.2. Pick up donuts and coffee

- 3.3. Pack apartment

- 3.3.1. Pack kitchen

- 3.3.2. Pack living room

- 3.3.3. Pack bedroom

- 3.3.3.1 Pack closet

- 3.3.3.2 Pack drawers

- 3.3.3.3 Pack blankets

- 3.3.4. Pack remaining items

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

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

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

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

Estimating the Resources

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

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

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

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

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

Estimating Activity Durations

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

In the top-down approach, high-level estimates are created. These estimates can be +/- 50% in terms of the accuracy level. There are three commonly used techniques for top-down estimating:

1. Apportion method – reviewing actual durations from similar projects and applying the same proportions to the current project.

2. Expert judgement – settling on a high-level estimate for overall project duration based on input from experts who have previously participated in similar projects.

3. Ratio method – identifying and applying significant determining factor(s) to estimate the project’s overall duration.

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

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

Exhibit 5.2: Apportion method

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

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

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

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

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

- WBS method – producing an estimate of the work package’s or iteration’s duration based on duration estimates of the tasks within each work package or iteration. These summary estimates are then rolled up to the major deliverable or capability level in order to produce an estimate for the project as a whole.

- Parametric estimating – entering data about the project into a formula, spreadsheet, or computer program that produces a duration estimate by extrapolating information from a database of actual durations from past projects.

- Three-point estimates – basing duration estimates on three scenarios: a realistic estimate (most likely to occur), an optimistic estimate (best-case scenario), and a pessimistic estimate (worst-case scenario). The final duration estimate is the average of the three.

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

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

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

1. Planning horizon – tasks to be completed in the distant future are more difficult to estimate accurately as the future can be very unpredictable.

2. Project complexity – the more complex the work, the harder it is to create accurate estimates.

3. People – the skill and experience levels of the people creating the estimates will have a big impact on estimate accuracy.

1. If the individuals involved have skills and experiences from similar past projects, they are likely to produce estimates with a higher degree of accuracy.

4. Project structure – dedicated team structures tend to produce the most accurate estimates, assuming the team members have the required skills and experience.

- Since project team members in functional environments must balance the needs of the project and their day-to-day work, it often is more difficult to find the time and focus required to produce accurate estimates.

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

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

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

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

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

Resource Allocation and Calendars

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

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

Resource Leveling

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

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

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

Task Sequencing

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

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

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

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

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

Sequencing for John’s Move

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

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

Predecessor Relationships in John’s Move

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

Outline of Activities in John’s Move with Predecessors Identified

1. Plan Move

- 1.1 Contact Dion and Carlita

- 1.2 Host planning lunch (1.1)

- 1.3 Develop and distribute  move schedule (1.2)

- 1.4 Make hotel arrangements in Atlanta (1.1)

2. Pre-packing

- 2.1 Gather packing material

- 2.2 Select moving van company and sign contract

- 2.2.1 Contact three moving van companies and get bids (1.3)

- 2.2.2 Select company and negotiate a final price (2.2.1)

- 2.2.3 Sign moving contract (2.2.2)

- 2.3 Pack small delicate items (2.1)

Network Diagrams

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

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

Lag and Lead Times

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

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

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

Lead Time in John’s Move

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

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

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

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

Exhibit 5.9: Table of attributes (accessible version)

Milestones

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

Milestones in John’s Move

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

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

Graphic Representations: Gantt Charts

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

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

Critical Path and Float

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

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

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

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

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

Total Float

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

Total Float in John’s Move

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

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

Ongoing Schedule Management

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

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

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

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

5.5 Cost Management

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

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

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

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

Once the project cost has been estimated, the actual cost of executing the required work is tracked and compared to the approved estimates. This tracking is done during the monitoring and control phase of the project (covered in Chapter 7). If the actual costs are significantly higher or lower, the project team explores reasons for the difference and takes appropriate action to successfully manage future costs.

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

Effective project leaders understand the importance of revising cost estimates as new information becomes available. Analytical skills are helpful in this regard as the project leader is routinely assessing the overall impact of modified project costs on the project’s objectives. Stakeholders expect to be kept informed of significant changes. Most organizations require project leaders to obtain approval for changes to the existing project estimates. In very large complex projects, a cost management plan, which identifies who will provide approval, will be created through conversation with the appropriate stakeholders. The project leader will use this plan to guide their efforts around when and how to communicate changes to project costs. Approval thresholds are typically established. For instance, the project leader may proceed with changes at their own discretion if the changes are not greater than 2% of the overall budget, while project sponsor approval would be required if the changes are beyond this threshold.

Types of Project Costs

There are generally three different types of project costs:

1. Direct costs

2. Direct overhead costs

3. General administrative costs

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

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

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

Lastly, general administrative costs are indirectly related to a project and they are incurred even if the project is not carried out. Examples of this type of cost include marketing, human resources, and accounting department-related expenses. These departments may provide ad-hoc and minimal support to the project teams and as a result, the project sponsors may want a portion of their costs to be allocated to all projects underway in the organization. Allocating a portion of the costs to the project provides the executive with a full picture of all costs incurred due to the implementation of strategic change initiatives in the organization. Since the allocation methods are often very subjective, many organizations exclude general administrative costs from the project budget. The time it takes to come to a consensus about the proposed subjective estimates may not be worth the benefit they provide in terms of organizational and project-related decision-making.

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

Estimation Techniques

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

In the top-down approach, high-level estimates are created. These estimates can be +/- 50% in terms of the accuracy level. There are three commonly used techniques for top-down estimating:

1. Apportion method – reviewing actual costs s from similar projects and applying the same proportions to the current project.

2. Expert judgement – consulting with experts who have done similar work before in order to settle on a high-level estimate for the project’s overall cost

3. Ratio method – identifies a significant determining factor and applies this factor to estimate the project’s overall cost. For instance, a website development project could estimate the project cost based on the number of web pages to be developed and an approximate cost to develop each page. Assuming it cost $1,000 to create one web page, a 20-page website project could cost $20,000.

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

Exhibit 5.12: Ratio Method

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

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

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

1. WBS Method – the cost of the tasks within each work package or iteration are estimated and rolled up to produce an estimate for the work package or iteration as a whole. These summary estimates are then rolled up to the major deliverable or capability level in order to produce a cost estimate for the project as a whole.

2. Parametric estimating – entering data about the project into a formula, spreadsheet, database, or computer program that comes up with an estimate. The software or formula that you use for parametric estimating is based on a database of actual durations from past projects.

3. Three-point estimates – works with three estimates: a realistic estimate that’s most likely to occur, an optimistic one that represents the best-case scenario, and a pessimistic one that represents the worst-case scenario. The final cost estimate is the average of the three.

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

Additional considerations:

- Labour costs: The people who will be working on the project are often also the largest cost component of it. Taking the time to estimate the labour rates is important and may require market analysis.

- Vendor bid analysis: Sometimes external organizations are required on the project. The project may send out RFQs (Request for Quotations) or RFPs (Request for Proposals). RFQs are used when the project team knows the required solution but is unable to provide it internally. RFPs are used when the project team does not know the required solution and requests proposals from organizations with relevant expertise. In both instances, the bids must be analyzed and evaluated in order to determine which is best for the project.

- Cost of quality: Many project teams overlook the costs associated with the quality-related tasks for a project. This includes measures to error-proof solutions, create checklists, and inspect deliverables before they are presented to stakeholders for review and sign-off. Since it is cheaper to identify flaws earlier than later in the project, there are always quality costs associated with everything a project produces. Cost of quality is a way of tracking the cost of those tasks. It is the amount of money it takes to assure that the project is executed efficiently.

- Reserve analysis: It is important to set aside some money for cost overruns. Higher-risk projects require more reserve than lower-risk projects. The reserve is intended to assist the project team with managing risks by putting mitigating strategies in place.

There are two types of reserves:

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

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

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

Apportion Estimate for John’s move

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

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

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

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

Parametric Estimate for John’s move

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

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

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

Bottom-up estimate for John’s move

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

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

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

Category

Description

Activity

Quantity

Unit Price

Cost

Packing Materials

Small Boxes

2.1

10

$1.70

$17.00

Packing Materials

Medium Boxes

2.1

15

$2.35

$35.25

Packing Materials

Large Boxes

2.1

7

$3.00

$21.00

Packing Materials

Extra-Large Boxes

2.1

7

$3.75

$26.25

Packing Materials

Short-Hanger Boxes

2.1

3

$7.95

$23.85

Packing Materials

Box Tape

2.1

2

$3.85

$7.70

Packing Materials

Markers

2.1

2

$1.50

$3.00

Packing Materials

Mattress/Spring Bags

2.1

2

$2.95

$5.90

Packing Materials

Life Straps per Pair

2.1

1

$24.95

$24.95

Packing Materials

Bubble Wrap

2.1

1

$19.95

$19.95

Packing Materials

Furniture Pads

2.1

4

$7.95

$31.80

Truck

Rental

2.2

–

–

$400.00

Truck

Gas at 10mpg

2.2

200

$2.25

$45.00

Total Cost

$661.25

Exhibit 5.15: Bottom-up cost estimates

Cost Budgeting

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

Managing the Budget

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

5.6 Risk and Issue Management

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

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

There are four steps in risk management:

1. Identifying the uncertainties. Some uncertainties are easy to identify, such as the potential for a damaging storm in the Caribbean, while others are less obvious, such as the potential for a project team to experience poor health. Many industries or companies have risk checklists developed from past experience. The value of a checklist is the stimulation of discussion and thought among team members about the potential risks of a particular project.

2. Assessing each identified risk by estimating its likelihood (probability of occurrence) and impact on project goals.. The outcome from this process is a prioritized list of project risks with values (e.g. high, medium, low) that represent the likelihood and potential impact. The probability/impact matrix is a key tool in risk assessment.

3. Developing risk responses, such as accepting the risk (do nothing to prevent it from happening), eliminating it (change something in the project to avoid its occurrence), transferring it (to a third party by purchasing insurance), or mitigating it (reduce its likelihood and/or impact).

4. Implementing and monitoring the response. After selecting the appropriate response for a particular risk, the project team must balance the cost of the response against the anticipated benefit for the project. Monitoring is important because new risks emerge and understanding the effectiveness of implemented risk response strategies ensures project risks are effectively managed throughout the project’s lifecycle.

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

Risk Management Plan

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

The risk management plan identifies the processes and procedures to be used in managing risk throughout the life of the project. It includes a number of key sections: risk sources, categories, assessment definitions (e.g. very high to very low), probability/impact assessment (matrix), roles and responsibilities, budget and schedule estimates for risk-related activities, and the risk register. The risk management plan is integrated into the project management plan (or, in the absence of this plan, into the execution approach for the project) and the response strategies are assigned to the appropriate individuals in the organization.

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

Risk Identification

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

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

The third source of risk is risk checklists developed from past projects. These checklists can be helpful to the project team in identifying specific risks on the checklist and expanding the thinking of the team. Some industries publish their own risk management checklists that, when feasible, should be utilized. Checklists are often organized by risk category. The categories themselves can add helpful insights during brainstorming sessions. Examples of common risk categories include:

- Technical (related to technology and equipment)

- Cost (specific labour and non-labour estimates)

- Schedule (activity durations and methods of completing work)

- Client/Customer (their willingness to use a new product/service)

- Procurement (vendor performance)

- Weather (adverse weather can impede progress)

- Financial (related to funding sources)

- Environmental (new/changing government regulations)

- Resources (skills, availability, and effectiveness of teamwork on the project)

- Stakeholders (fulfilling expectations of specific stakeholders)

- Communications (related to its effectiveness)

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

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

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

Task

Risk

Contact Dion and Carlita

•     Dion backs out

•     Carlita backs out

•     No common date available

Host planning lunch

•     Restaurant full or closed

•     Wring choice of ethnic food

•     Dion or Carlita may have food allergies or preferences

Develop and distribute schedule

•     Printer out of toner

•     Out of paper

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

Risk Assessment

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

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

Exhibit 5.16: Risk and impact matrix
Project Management from Simple to Complex

There is a positive correlation between project complexity and project risk. This means that both variables increase or decrease together. A project with new and emerging technology will have a high complexity rating and a correspondingly high project risk. The project management team will assign the appropriate resources to the technology managers to ensure the accomplishment of project goals. The more complex the technology, the more resources the technology manager typically needs to meet project goals, and each of those resources could face unexpected problems.

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

Risk Responses

…To Negative Risks

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

- Risk avoidance

- Risk mitigation

- Risk transfer

- Risk acceptance

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

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

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

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

Risk acceptance involves doing nothing in response to the risk. The acceptance response is a good one when the likelihood and impact of a risk are low. In some cases, little else can be done about the risk, leading to acceptance being the only feasible option. When this response is chosen, many project leaders have developed a strategy to deal with the risk if it does materialize. This often involves setting aside funds (contingency reserves) in the project budget.

…To Positive Risks

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

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

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

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

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

Project Risk by Phases

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

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

Initiation

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

Risk Identification by Phase in John’s Move

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

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

1.

His new employer might change his mind and take back the job offer after John has given notice at his old job

LOW

2.

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

MEDIUM

3.

The movers might lose his furniture

LOW

4.

The movers might be more than a week late delivering his furniture

MEDIUM

5.

He might get in an accident driving from Chicago to Atlanta and miss his first day of work

LOW

John then considers appropriate responses for each of the risks.

1. During his job hunt, John received more than one offer, so he is confident that he could get another job if this risk occurs, however, he would likely lose the deposit money on the apartment and the mover. He would also lose wages during the time it took to find another job. John’s risk management strategy is to mitigate the risk of his new employer changing his mind by making sure that he keeps his relationship with his new employers cordial and writes to each of them thanking for their consideration in his recent interviews.

2. In accepting this risk, John checks the market in Atlanta to determine the weekly cost and availability of extended-stay motels.  If this proves to be too expensive, John could try to mitigate the risk. A strategy to reduce the likelihood of this risk occurring would be to ask his new landlord to introduce him to the current tenants in his new apartment. This would allow John to get to know the existing tenants and express his gratitude for a timely move.  Further, John could offer to buy them dinner on their moving day as further incentive to vacate the apartment on time.

3. John checks the mover’s contract to confirm that they carry insurance against lost items, but they require the customer to provide a detailed list with value estimates and they limit the maximum total value. John decides to pursue the risk transfer approach by going through his apartment with his digital camera and taking pictures of all of his possessions that will be shipped by truck. The pictures provide John with a visual record so he will not have to rely on his memory to make a list. He seals and numbers the boxes so he can tell if a box is missing.

4. John can accept this risk and use his research on extended-stay motels to arrange for temporary accommodation while he waits for his furniture to arrive. . He checks the moving company’s contract to see if they compensate the owner for late delivery, and he finds that they do not. This means that he would have to cover the cost of temporary accommodations. If John preferred to transfer this risk, he could approach his insurance company to see if coverage is available.

5. John checks the estimated driving time from Chicago to Atlanta and gets an estimate of 11 hours of driving time. He decides that it would be too risky to attempt to make the drive by himself in one day, especially if he is unable to leave until after the moving truck is packed. John plans to spend one night on the road in a motel to reduce the risk of an accident caused by driving while too tired. John’s overnight stay is an effective risk mitigation strategy.

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

Planning Phase

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

Risk Identification in John’s Move

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

Legend:

- RA: Risk avoidance

- RS: Risk sharing

- RM: Risk mitigation

- RT: Risk transfer

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

Implementation, and Monitoring and Control Phases

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

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

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

Closing Phase

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

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

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

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

Contingency Plan

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

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

5.7 Procurement management

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

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

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

- Identifying the required materials, equipment, and supplies

- Identifying the potential vendors

- Preparing requests for quotes (RFQs) and requests for proposals (RFPs), which include product/service specifications and a detailed delivery schedule

- Evaluating RFQs and RFPs to select the most suitable vendors

- Awarding and signing contracts

- Administering the contract and monitoring vendors’ performance

- Managing contract changes

- Closing out the contract upon work completion

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

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

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

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

- Roles and responsibilities of the project team and procurement professionals

- Vendor selection criteria and the selection process

- The identification of prequalified sellers (if known)

- The types of contracts to use and any metrics that will be used to measure the vendors’ performance

- The requirements and specifications of the necessary products, services, and equipment

- The planned delivery dates for the work or products being contracted

- The company’s standard documents to be used on the project

- The number of vendors involved and how they will be managed

- How purchasing may impact the constraints and assumptions of the project management plan

- The coordination of purchasing lead times with the development of the project schedule

- Closing contracts

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

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

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

Lease-or-Buy Analysis

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

Some of the key questions answered include:

1. How long does the organization need to use the equipment for the project?

2. What will the organization do with the equipment after the project is complete?

3. How will this decision affect the scope of the project?

4. How will it affect the project schedule?

5. How will it affect the stakeholders’ expectations of quality?

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

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

Cost to lease = Cost to purchase

Assume M is the number of months.

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

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

$400 x M = $15,000

M = $15,000 ÷ $400 = 37.5

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

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

Qualifying Bidders

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

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

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

Solicitation

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

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

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

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

Evaluating Bids

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

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

Awarding the Contract

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

Contract Types

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

Fixed-Price Contracts

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

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

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

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

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

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

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

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

Type

Known Scope

Share of Risk

Incentive for Meeting Milestones

Predictability of Cost

Fixed total cost

Very High

All vendor

Low

Very high

Fixed unit price

High

Mostly project

Low

Medium

Fixed price with incentive fee

High

All vendor

High

Medium-high

Fixed fee with price adjustment

High

Depends on how the adjustment will occur (before or after the trigger for adjustment arises)

Low

Medium

Cost-Reimbursable Contracts

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

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

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

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

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

- A cost-reimbursable contract with a fixed fee provides the vendor with a profit amount, often referred to as a fee, that is determined at the beginning of the contract and does not change.

- A cost-reimbursable contract with a percentage fee provides the vendor with a percentage of the allowable costs as profit. For instance, the fee could be 5% of total allowable costs. The vendor is reimbursed for allowable costs and is compensated with a fee that changes as the costs change.

- A cost-reimbursable contract with an incentive fee is used to encourage performance in areas critical to the project. Often the contract attempts to motivate vendors to save or reduce project costs. For instance, in addition to being reimbursed for allowable costs, the vendor (a talent scout) receives a predetermined bonus fee for each musician who signs on with the record label at a very attractive price.

- A cost-reimbursable contract with award fee reimburses the vendor for all allowable costs plus a fee that is based on performance criteria. The fee is typically based on goals or objectives that are more subjective. An amount of money is set aside for the vendor to earn through excellent performance, and the decision on how much to pay the vendor is left to the judgment of the project team. The amount is sufficient to motivate excellent performance. For instance, in addition to being reimbursed for allowable costs, a music producer receives an award fee from the record label based on the rating of the album.

Cost Reimbursable (CR)

Known Scope

Share of Risk

Incentive for Meeting Milestones

Predictability of Cost

CR with fixed fee

Medium

Mostly project

Low

Medium-high

CR with percentage fee

Medium

Mostly project

Low

Medium-high

CR with incentive fee

Medium

Mostly project

High

Medium

CR with award fee

Medium

Mostly project

High

Medium

Time and Materials

Low

All project

Low

Low

Time and Material Contracts

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

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

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

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

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

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

1. Is the required work or materials a commodity, customized product or service, or unique skill or relationship?

2. How well-known is the scope of work?

3. What are the risks and which party should assume which types of risk?

4. Does the procurement of the service or goods affect activities on the project schedule’s critical path and how much float is there on those activities?

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

Progress Payments and Change Management

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

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

Managing the Contracts

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

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

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

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

5.8 Quality Management

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

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

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

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

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

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

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

Techniques

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

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

- Cost-benefit analysis is looking at how much the quality activities will cost versus how much will be gained from doing them. Typical cost considerations include the effort and resources required to carry out the quality activities. Typical benefit considerations include greater user satisfaction, less reworking, and greater productivity.

- Benchmarking is using the results of quality planning from other projects to set goals for the current project. If the last project in the organization had 20% fewer defects than the one before it, the project team should learn from a project like that and put in practice any of the ideas the previous project used to make such a great improvement. Benchmarks can serve as reference points for evaluating a project before the work begins.

- Design of experiments is the list of the array of tests to be run on the product. It might list all the kinds of test procedures, the approaches to be taken, and even the tests themselves. (In the software world, this is called test planning.)

- Cost of quality is obtained by adding up the cost of all the prevention and inspection activities to be performed on the project. This includes many different activities, such as testing, time spent writing standards, reviewing documents, meeting to analyze the root causes of defects, and reworking to fix the defects identified by the team… in other words, absolutely everything that is done to ensure quality on the project. The cost of quality can be compared from one project to another in order to identify innovative ideas and best practices.

- Control charts can be used to define acceptable limits. If some of the functions of a project are repetitive, statistical process controls can be used to identify trends and keep the processes within control limits. Part of the planning for controlling the quality of repetitive processes is to determine what the control limits are and how the process will be sampled.

- Cause-and-effect diagrams can help in discovering problems. When control charts indicate an assignable cause for a variation, it is not always easy to identify the cause of a problem. Discussions that are intended to discover the cause can be facilitated using a cause-and-effect, or fishbone diagram, where participants are encouraged to identify possible causes of a defect.

Example: Diagramming Quality Problems

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

- Low-quality raw materials

- Power fluctuation

- Ambient temperature

- Worker absenteeism

- Poor training

- Old equipment

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

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

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

- Utility reliability

- Personal space heaters and large motor start-up leading to overloaded circuits

- Lighting

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

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

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

Exhibit 5.22: Example of a check sheet
DanielPenfield, Wikimedia

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

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

Exhibit 5.24: Example of Pareto chart
Dense2013, Wikimedia

Quality and Grade

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

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

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

Measurement Terminology

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

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

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

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

Statistics

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

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

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

Quality Assurance

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

Process Analysis

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

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

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

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

5.9 Stakeholder and Communications management

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

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

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

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

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

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

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

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

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

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

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

1. What information do stakeholders need?

2. When is this information needed?

3. How should this information be collected and analyzed? (systems and/or people?)

4. How and when should this information be distributed? (technology platforms and/or people?)

5. How will the project team ensure the communication is effective? (feedback loops)

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

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

Assessing New Communication Technologies

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

- Does the new tool/application provide a benefit for the project by increasing access to information, reducing the cost and time associated with creating and disseminating information and/or preventing mistakes?

- Does the project team have the expertise and capacity to learn new technology quickly?

- Does the company offer support such as a help desk to assist team members to use new communication technology?

- Does the organization, and in particular, the project, have the money needed to acquire new tools/applications?

Communication Plan Templates

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

1. Who the stakeholders are (individuals and groups)

2. The communications necessary to satisfy stakeholder expectations

3. The timeframe and/or frequency of communication messages

4. The tools/applications used to communicate the messages

5. Roles and responsibilities for creating and disseminating the messages

Exhibit 5.25: Communications plan template
Inte5160, Wikispaces

References

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.

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.

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.

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.

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 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-creation^10. 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. 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:

- 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 they have been able to successfully navigate conflict. In his bestselling book, The Five Dysfunctions of a Team, Patrick Lencioni writes^11:

“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 conflict^12.  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.

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

Compromising

You realize that each team member has to give something up because getting everyone’s needs met 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.

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 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 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 project^15. 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

- 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

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.

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.

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.

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. 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 8-hour workdays

Potential for lack of trust among team members and the organization when communication is limited

Decreased response time to customers

Reduced collaboration among separated team members 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 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, 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 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.

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.

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.

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.

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

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

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

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.

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

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

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.

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

Term

Description

Formula

John’s Move

Actual Cost (AC)

The money actually spent on projects up to the present.

–

$154.50

Budget at Completion (BAC)

Original budget for the entire project (same as the total 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 (CPI)

Ratio of earned value to actual cost

EV ÷ AC

1.05

Schedule Variance (SV)

Difference between earned value and planned value

EV − PV

-$99.55

Schedule Performance Index (SPI)

Ratio of earned value to planned value

EV ÷ PV

0.62

Estimate to Complete (ETC)

Money to complete the project if early cost variance is atypical

(BAC − EV) ÷ CPI

$499.15

Estimate at Completion (EAC)

Revised estimate of total project cost

AC + ETC

$653.65

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.4 The Importance of Soft Skills in Keeping Projects on Track

Discenza and Forman’s research identified seven common issues that may cause project failure^1:

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.

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

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.

If…

It means…

Then…

NPV > 0

The investment would add value to the firm.

The project may be accepted.

NPV < 0

The investment would subtract value from the firm.

The project should be rejected.

NPV = 0

The investment would neither gain nor lose value for the firm.

We should be indifferent in the decision whether to accept or reject the project. This project adds no monetary value. The decision should be based on other criteria (e.g., mandatory requirements to complete the project, strategic positioning or other factors not explicitly included in the calculation).

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.

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