Project Management for Project Managers:

according to the international standard ISO 21502

Preface

Welcome to “Project Management for Project Managers – according to the international standard ISO 21502.” This book is specifically designed to empower project managers with practical insights into applying the global standard for project management.

At the heart of this journey are five essential processes – Initialization, Planning, Execution, Controlling, and Closing. These processes are not isolated entities; they are intricately interconnected, forming the foundation of effective project management.

Throughout the book, you’ll find an ongoing case study that serves as a practical illustration of the concepts discussed. This approach enhances your understanding of the subject matter and its real-world applications.

Project management is the vehicle of change, and this book is your toolkit for mastering it. By equipping you with global best practices, it enables you to navigate projects with precision and excellence.

 

 

0.0 Introduction

The general model follows the logic of Initializing, Planning, Executing, Controlling and Closing activities that result in deliverables to be transitioned to users and knowledge transitioned to organizations involved. Not only work within the framework of projects is initialized, planned, executed, controlled, and closed. These management functions are universal, and every manager performs them in their daily work.

Within the realm of project management, the initial question to be answered is whether a project should be initialized and why. Typical reasons for initializing a project include the existence of a business opportunity, a problem to be solved, or the need to comply with regulations.

If the required solution is time-constrained, organizing the upcoming work as a project or a group of related projects, known as a program, is a viable option if the intended scope exceeds the capabilities of a single project. This may be the case when the demonstration of benefits is necessary, but these benefits emerge after the project delivers the solution to end users. The rationale behind organizing the work as a project or program is that project management has developed a set of tools and techniques specifically aimed at delivering solutions on time and within budget.

At this pre-project stage, project inception methods are employed, such as a business case or a feasibility study. These methods may be part of a more comprehensive process governed by corporate management known as portfolio management, which helps in selecting which initiatives will be pursued. If the outcome of the inception process is positive, then the project is initialized. However, it is not yet planned; it is simply initialized.

Project Initialization

At this stage, the project manager may have been informally nominated. A formal nomination is one of the outputs of the initialization process. However, it is considered good practice to involve the future project manager during the initialization process, even if this stage falls under the responsibility of the project initiator or sponsor. It is only upon the conclusion of the initialization activities that the new temporary organization, called Project X, will be officially created, including the name and level of authority of the nominated project manager.

A good starting point for the project initialization activities is the identification of key stakeholders. By working with them, the project manager determines which aspect of the problem or opportunity the project will address, as well as the purpose and goal of the project. The sponsor plays a leading role in this phase. The two critical questions that need to be answered are “what do we want to achieve and why?” The “why” refers to the purpose, and the “what” pertains to the goal.

While formulating the purpose and goal statements, it is highly beneficial to agree on the business requirements for the project. Business requirements refer to the new capabilities that the organization aims to obtain as a result of the project. It is important not to confuse business requirements with functional requirements and quality attributes for the solution, which come later during the planning stage.

Before formulating functional requirements for a solution, the team must first identify, analyze, and select the most appropriate strategy to achieve the goal. There are always multiple solutions to achieve a goal, and the key deliverable, the solution, depends on which strategy is chosen.

During this stage, it is essential to define project success criteria, high-level risks, initial assumptions, and existing constraints. All these elements of project definition should be appropriately documented in a document usually referred to as the project charter or project brief. This document officially creates the new temporary organization called “Project X,” which did not exist before and therefore must be approved by the corporate management and communicated to stakeholders.

Planning Activities

Any work involves planning before implementation, even if the planning is only done mentally without any written documentation. This principle applies equally when work is organized as a project.

The project management team begins by gathering requirements from key stakeholders regarding the management of the project. They also review the constraints and assumptions gathered during project initialization to check for any changes.

This is the appropriate time to define SMART objectives that will lead to the project goal established in the project charter.

The project management team needs to determine the type of development lifecycle the team will use to create the solution. This includes identifying the phases and/or iterations to be pursued.

Special attention should be given to the development of the project baseline, which encompasses the approved project scope, budget, and schedule. This baseline defines what the project will deliver, when it will be delivered, and at what cost.

Based on the elicited requirements for project management, the team can determine how things will be managed.

During the planning stage, the team will identify risks, analyze them to determine the most critical ones, and develop appropriate responses.

Once all these elements are well combined and balanced, approval from the governing body, typically the project sponsor or customer (if they are different individuals), should be obtained. Subsequently, the project manager informs stakeholders about the approved Project Management Plan, and a second kick-off meeting can be conducted to inform everyone about the final plan and transition from the planning phase to the execution phase.

Managing Execution Works

Now it is time to create the key deliverable, starting with the acquisition of human and physical resources and participating in the associated acquisition processes.

A significant portion of managing execution entails authorizing, delegating, reviewing, and accepting work packages. Simultaneously, the project manager leads, manages, and develops teams using coaching techniques, manages communications, and engages stakeholders through various means.

Ensuring quality during project execution involves more than just auditing the application of standards and policies; it also involves generating quality throughout all project phases.

Implementing approved changes and corrective measures resulting from controlling activities is part of managing execution, as well as implementing responses to identified risks.

Lastly, while the project work is being executed, the project manager ensures that the team leverages existing knowledge and creates an environment conducive to the generation of new knowledge, including process improvements through lessons learned in team retrospectives.

Controlling a Project

The purpose of controlling a project is to understand its current state, have visibility into its future status with cost and schedule forecasts, and initiate corrective and preventive actions.

The controlling processes encompass all areas of the project management plan, including the project baseline, as well as risks, effectiveness of communications, stakeholder engagement, material resources, and procurements.

Part of the controlling work involves addressing issues and the need for changes that arise during project execution. This is done by employing problem-solving and other techniques to evaluate and determine the most appropriate resolution, initiating corresponding corrective measures and changes that feed back into the planning and execution processes.

As most projects are structured into phases, it is essential to control phase boundaries. This involves evaluating ending phases and providing the project board with relevant information to decide whether to proceed to the next phase, including planning for the next phase. Controlling phase gates also includes ensuring that phase closing activities have been performed, such as transitioning phase deliverables, releasing no longer needed resources, and conducting administrative phase closure activities like updating logs and registers, collating lessons learned, and more.

Closing Activities

Controlling phase gates overlaps with closing activities, which occur at each phase’s end, not just at the end of the project.

Closing activities encompass ensuring the evaluation, acceptance, and transition of accomplished deliverables have taken place, as well as evaluating the performance of team members and suppliers.

Closure activities are performed at the end of each phase. However, at the end of the last phase, when it is also the end of the project, many of the phase closure activities are combined with the project closure. This includes the aforementioned administrative closure activities, along with project-specific end activities such as determining project success using the project success criteria defined in the project charter and preparing a project closeout report.

Predictive, iterative, incremental, Agile and hybrid approaches

A final note on the applicability of the ISO 21502 standard: The project management guidance it provides is applicable to any organization, project type, or delivery approach.

If the project’s scope can be reasonably determined at the beginning, a more predictive delivery approach can be employed. On the other hand, if the scope is unknown, unpredictable, or the customer lacks clarity regarding their requirements, and the project involves a discovery journey during execution, a gradual formulation of requirements is more suitable. Delivery approaches for gradual requirement formulation include incremental methods, delivering functionalities in increments, or iterative approaches, gradually improving already built functionalities. Alternatively, a combination of both incremental and iterative methods, known as the Agile approach, can be utilized. The Agile approach encompasses various useful practices detailed in different Agile methodologies, including specific ceremonies.

In many cases, organizational practices require establishing a budget and timeframe upfront to approve an initiative and allocate a specific budget, even when certain parts of the solution have significant unknown factors and may be developed using Agile approaches. This often involves attempting to predict unpredictable aspects upfront, working with assumptions, and consequently managing numerous change requests since changes are inevitable in projects due to their unique nature. In frequent hybrid scenarios, certain sections of the project are more predictable than others, and some components of the overall solution may have a predominant Agile character. Suppliers of Agile components view their part in the project as “the project” itself. However, from the perspective of the final customer, that Agile project is essentially a work package, a component of a larger project. Therefore, the management of the project may not be entirely or predominantly Agile.

 

Conclusion

Irrespective of the prevailing management philosophy and the chosen delivery approach, any type of work necessitates the management activities of initialization, planning, execution, control, and closure. By utilizing the international standard ISO 21502 as a framework, it ensures the effective and consistent implementation of these essential project management activities, leveraging a globally recognized standard.

 

 

0.1 Project Management Standards

This section explains the advantages of using a recognized standard for project management.

Project management methods have existed for centuries. Think of projects like the Golden Gate Bridge, the Eiffel Tower, and even the invention of smartphones. Techniques of project management can also be used for lesser known but important endeavors, such as building or remodeling a house.

Whether it’s large or small projects, as the project management profession has been established, so has the need for a documented guide to practice the profession.

From this need, professional association guides emerged starting in 1995, such as the PMBOK Guide from the Project Management Institute (PMI) in the United States, the ICB from the International Project Management Association (IPMA), and the Prince2 from the British government, to name the most important ones.

In the search for a suitable conceptual framework for this course, the author decided to use the ISO 21502 international standard published in December 2020 because the International Organization for Standardization (ISO) is the preeminent international organization responsible for international standards and has become famous for the ISO 9000 family of standards. Therefore, everyone knows and recognizes the authority of the ISO institution. This way, the uncertainties of private associations are avoided. Additionally, all the previously mentioned institutions participated in the development of ISO 21502, as did representatives from the national standardization bodies of numerous states. Thus, we can say that the ISO 21502 standard is the consensus-based foundation of the most recognized conceptual frameworks in project management.

To facilitate understanding, we have organized the practices described in ISO 21502 according to the process groups proposed in its Annex A. These process groups refer to the activities of initiation, planning, execution, monitoring and control, and closure, which we will explain in detail throughout the course.

What is the importance of using a globally recognized standard?

First, an international standard can serve as a basis for any organization, whether public or private, for-profit or non-profit, and for any type of project, regardless of its complexity, size, cost, duration, or approach, including predictive, iterative, incremental, or a combination of both, i.e., the Agile approach.

If you are managing a small project, you could use a simplified version of the standard by applying only some of the described practices.

On the other hand, if you are building a bridge, you would probably follow most, if not all, of the practices described in the ISO standard. Project managers who are familiar with the standard can customize their management process to better suit the specific needs of the project and organization. There is an old saying: “To break the rules, first you have to know them.” When project managers invest time in learning the rules, they also invest time in understanding which practices can and should be customized to fit the specific organization and project.

Another advantage of using a recognized standard for your project is that it allows you to use the standardized vocabulary of the discipline, which will facilitate understanding with other stakeholders.

Like any recognized standard, it enables companies to standardize practices across different departments. This means that people in the development area, for example, manage projects in a similar way to those in the distribution area.

It can also help project managers collaborate beyond their own organization. If you work for Company A and collaborate with Companies B and C, such as suppliers, collaboration can be improved by applying similar management practices.

In summary, we can say that using a recognized standard for your project allows you to leverage existing techniques and lessons learned from many projects worldwide, use a common vocabulary that can be understood by your colleagues, standardize practices across various departments within your organization, or even across multiple organizations or companies.

 

 

 

0.2 What is a project?

This section aims to provide a clear understanding of the concept of a project and how it sets itself apart from other types of work.

Before delving into project management strategies, let’s establish a shared understanding of what constitutes a project.

Here’s a concise definition: A project is a time-limited endeavor with a unique goal and often a financial allocation.

But what does this definition truly entail?

Let’s begin with the notion of a time-limited endeavor.

Unlike routine operations, a project has a definite commencement and conclusion. For instance, if a project involves creating a social center for teenagers, it concludes when the center is fully operational and ready to serve its intended purpose.

What if a project seems to stretch on endlessly? In such cases, it is likely that the intended outcome has not been clearly defined.

This brings us to the project’s goal.

Each project generates a unique result, which may manifest as a product, service, capability, or any other desired outcome. In the case of establishing a social center for teenagers, the goal could be to provide a safe and engaging space for young individuals to socialize, learn, and participate in various activities.

Numerous organizations embark on similar endeavors, but each project is distinguished by its specific goals, constraints, and challenges. For example, the social center project might face obstacles such as securing funding, finding suitable premises, and designing programs that cater to the diverse needs and interests of teenagers in the community.

Lastly, projects typically operate within predefined budgets.

While budgets are commonly associated with financial aspects, project management also entails managing other available resources. For instance, a project may be constrained by limited staffing resources or a specific timeframe for completion.

It is important to recognize that projects differ from routine operations, which involve repetitive tasks generating consistent outcomes. For instance, operating a community library represents an operational process. Although visitors may have different reading preferences, the library staff follows established procedures and utilizes standard practices for lending books and providing assistance.

Conversely, establishing a social center for teenagers is a project. It possesses a specific start and concludes when the center is fully operational, offering a range of programs and services to benefit the target demographic.

This project serves the unique goal of creating a supportive and inclusive space where teenagers can connect, explore their interests, and receive guidance. Its execution necessitates financial and resource allocations to ensure the successful realization of the social center.

Throughout your life, you have likely engaged in numerous projects, both in professional and personal contexts. A project, by definition, is a temporary endeavor characterized by a unique goal and often involving budgetary considerations.

With these defining characteristics in mind, reflect upon your recent months and identify the projects you have been involved in. Analyze the timeframe, unique aspects, and budgetary implications of each project to gain a deeper understanding of your own experiences.

 

 

0.3 What is project management?

This section will help you understand the concept of project management.

Many project managers begin their journey because they have a knack for getting things done. However, project management entails more than just showcasing organizational skills and overseeing others. It involves applying knowledge, skills, tools, and techniques to achieve the objectives of their project. Project management can be summarized by addressing a few crucial questions.

The first question to answer is: What problem are you solving? Clearly defining the project’s intended outcome is a significant step towards ensuring its success. If you don’t know where you’re headed, you may incur costs and invest time in reaching a destination that may not align with your desired outcome.

The second question is: How are you going to solve this problem? Whether you’re addressing a problem or pursuing an opportunity, you may need to choose from various potential strategies.

Once you have selected your strategy, it’s time to delve into your solution by gathering requirements, identifying deliverables, and defining the project scope.

The next question is: What is your plan? Planning plays a significant role in project management. You must identify the work packages that need to be accomplished, estimate timeframes, determine resource requirements, and assess associated costs. Armed with this information, you can create a schedule that outlines when the work should occur. Additionally, it’s crucial to establish guidelines for project processes such as communication, risk, and change management.

While some projects may seem never-ending, there will eventually come a point where someone decides to pull the plug if they are not completed. That’s why it is essential to answer the question: How will you know when you are done? Clearly defined goals, objectives, requirements, and deliverables help address this question. However, you can reduce uncertainty by defining success criteria, which are quantifiable and measurable indicators that demonstrate project completion. For example, success criteria could include achieving a specific revenue target for a marketing campaign or increasing the efficiency of a process to a certain number of transactions per minute. These measurable indicators provide a tangible benchmark for project completion, enabling project teams to assess their progress and determine if the project’s objectives have been successfully achieved.

When reaching the conclusion of a project, it is of utmost importance to address the final question: How well did the project perform? Unfortunately, this crucial step is often neglected as there is a natural inclination to swiftly transition to the next undertaking. However, it is vital to allocate time for a comprehensive project review. This evaluation process involves carefully assessing the project’s outcomes, analyzing what aspects were successful and what fell short, and understanding the underlying reasons behind these outcomes. Furthermore, it entails reflecting on the project’s execution and identifying areas where improvements could have been made to enhance the overall process. By engaging in this reflective practice, project teams can gain valuable insights, learn from their experiences, and apply these lessons to future endeavors, ultimately fostering continuous improvement and growth within the organization. Emphasizing the significance of this evaluation stage ensures that valuable knowledge is captured and leveraged, contributing to the enhancement of project management practices and the overall success of future projects.

In summary, project management involves addressing fundamental questions that shape the project’s trajectory. These questions include identifying the problem to be solved, devising an approach to address it, formulating a project plan encompassing all key aspects, establishing criteria to determine project success, and evaluating project performance.

 

 

 

0.4 Organizational structure as project environment

This section aims to provide a comprehensive understanding of the various types of organizational environments for projects and their implications for project management. Organizations and projects can be structured in several ways, each of which has a distinct impact on how projects are carried out.

The classic functional hierarchy is one such structure, where individuals report to a single functional supervisor. In this setup, project management is integrated within the functional departments. It works well for smaller projects that mainly impact a single department. The project team members are also involved in day-to-day operations, allowing for efficient communication and control. However, challenges may arise when projects span multiple departments, causing delays and resource constraints.

Matrix organizations, on the other hand, blend elements of both functional and project-based structures. Resources in a matrix structure report to both functional managers and project managers. The degree of authority given to project managers varies based on the type of matrix organization—weak, balanced, or strong. Matrix organizations enable better coordination across departments and provide greater project support compared to pure functional hierarchies. However, managing resources with dual reporting lines and resolving conflicting priorities can be a challenge.

In contrast, projectized organizations are dedicated solely to projects. Project managers hold significant authority over their projects, including budget control. Resources are assigned exclusively to project work and report directly to the project manager. This structure allows for focused project management but may pose challenges in determining the future roles of team members once the project is completed.

It is important to note that hybrid organizational structures combining different approaches can also exist. Real-world scenarios often involve a mix of organizational models. Some projects may be executed within a single department using a functional structure, while others, particularly those spanning multiple departments, may require a matrix organization. Large-scale strategic initiatives often benefit from a projectized structure with dedicated full-time resources.

In summary, understanding the various types of organizational structures for projects is essential as they significantly influence project execution, the authority of project managers, and the overall likelihood of project success. The classic functional hierarchy integrates project management within functional departments, while matrix organizations provide greater project support but entail dual reporting lines. Projectized organizations focus solely on projects, granting project managers significant authority. Additionally, hybrid organizational structures combining different approaches are common in practice. By considering the organizational structure and its implications, project managers can make informed decisions, adapt their approach accordingly, and optimize project outcomes.

 

 

 

0.5 Organizational culture as project environment

This section aims to provide insights into the impact of organizational culture on projects by exploring its various facets and implications. Organizational culture is widely recognized as a significant environmental factor that shapes project outcomes. But what exactly does it entail, and how does it affect project management?

To begin, let’s establish a clear understanding of organizational culture. It encompasses shared values, beliefs, assumptions, habits, norms, and practices within an organization. This collective mindset molds individuals’ behaviors, attitudes, and interactions, shaping the overall work environment. Often referred to as the “personality” or “DNA” of an organization, it profoundly influences its identity and dictates how tasks and operations are carried out.

Organizational culture encompasses several elements that create a unique cultural environment, influencing work conduct and interpersonal dynamics. These elements include shared values that provide a common decision-making framework, underlying beliefs, and assumptions that shape perception and understanding, norms and practices that define behavior patterns and work interactions, communication patterns that determine information flow, rituals and traditions that reflect and reinforce culture, and symbols and artifacts that represent the organization’s identity.

Understanding and managing these elements are crucial for leaders and managers to cultivate a positive and effective organizational culture aligned with the organization’s goals. A favorable organizational culture fosters a supportive and productive work environment, enhancing employee satisfaction, retention, and long-term success.

The impact of organizational culture extends to various aspects of project management:

• Project Alignment: Organizational culture shapes project alignment by influencing the organization’s strategic goals and priorities. Projects that align with the organization’s mission and vision receive greater support, resources, and attention, increasing their chances of success.
• Decision-Making: Organizational culture influences decision-making processes within projects, including the level of autonomy granted to project teams and the extent of collaboration and innovation encouraged. Understanding the cultural context helps project managers navigate decision-making effectively, considering factors such as hierarchy and approval processes.
• Communication and Collaboration: Organizational culture strongly impacts communication and collaboration within projects. Cultures that promote open and transparent communication create an environment where project teams freely exchange ideas, provide feedback, and innovate. In contrast, cultures emphasizing hierarchical communication can hinder effective collaboration, requiring project managers to bridge gaps and foster a culture of trust and open dialogue.
• Risk Tolerance: Organizational culture influences the organization’s approach to risk tolerance and management, directly impacting project management. Risk-averse cultures tend to be cautious and conservative in decision-making, resulting in stringent change management processes and resistance to risks. In contrast, cultures that embrace experimentation and learning from failures foster a more adaptive and resilient project environment.
• Adaptability: Organizational culture affects project adaptability. Cultures that embrace change create an environment receptive to new ideas, evolving circumstances, and innovation. Conversely, cultures resistant to change may impede project adaptability, requiring project managers to navigate and overcome resistance when introducing new approaches or implementing changes.
• Team Dynamics and Motivation: Organizational culture significantly influences team dynamics and motivation within projects. Positive cultures that promote collaboration, recognition, and personal growth foster high team morale and motivation, leading to improved project outcomes. In contrast, negative or toxic cultures can hamper team dynamics, resulting in demotivation, conflicts, and reduced productivity. Project managers must actively address and mitigate such challenges to ensure effective team performance.

To further illustrate the impact of organizational culture on project management, let’s consider some examples:

• Example 1: Let’s say a tech startup has a mission to revolutionize the education sector through innovative digital solutions. However, the organizational culture is conservative and resistant to change. In this case, there is a misalignment between the mission and the prevailing culture. This misalignment may hinder the adoption of new ideas and innovative approaches in project execution.
• Example 2: In a healthcare organization, the mission is to provide compassionate and patient-centered care. Organizational culture emphasizes teamwork, empathy, and collaboration. In this case, the mission and vision align closely with the existing culture, reinforcing the values and behaviors that contribute to successful project outcomes. The culture promotes effective communication and collaboration among healthcare professionals, leading to improved patient care.
• Example 3: A large multinational corporation has a mission to be an industry leader in sustainability and environmental responsibility. However, the organizational culture is primarily focused on short-term profitability and cost-cutting measures. Here, there is a significant misalignment between the mission and the prevailing culture, which may lead to challenges in implementing sustainable practices and achieving the desired environmental goals.
• Example 4: Imagine a multinational company operating in multiple countries, with a project team composed of members from diverse cultural backgrounds. In this scenario, cultural differences regarding adherence to rules can significantly impact project management. Team members from rule-adherence cultures may prioritize following established processes and guidelines, while those from innovation-focused cultures may challenge existing norms.

By recognizing and leveraging the impact of organizational culture on project management, project managers and stakeholders can navigate complexities, optimize team dynamics, and create an environment conducive to project success.

In summary, organizational culture is a powerful and influential factor in project management. It encompasses shared values, beliefs, norms, and practices that shape the work environment and influence various aspects of projects. From project alignment to decision-making, communication, risk tolerance, adaptability, and team dynamics, organizational culture plays a significant role in project outcomes. By recognizing and leveraging the impact of organizational culture, project managers and stakeholders can navigate complexities, optimize team dynamics, and create an environment that fosters project success.

 

 

 

 

0.6 The role of a project manager

This section will help you understand the requirements of being a project manager.

Many people perceive project managers as highly organized individuals who excel at achieving goals. However, project managers also rely on a diverse set of skills and knowledge to successfully complete projects.

Firstly, project management involves technical skills specific to the field. This includes understanding the components of a project plan, creating and refining project schedules, interpreting Gantt charts, utilizing critical path analysis, and measuring performance.

Additionally, business expertise is crucial. As a project manager, it is your responsibility to ensure that your project delivers value. Familiarize yourself with your organization’s business operations, objectives, and priorities. This understanding enables you to assess how your project aligns with the overall goals and make informed decisions to facilitate its success.

Problem-solving is another vital skill for project managers. Projects rarely proceed exactly as planned, and it is your role to navigate obstacles, find solutions, and achieve project objectives within the established schedule and budget.

Interpersonal skills are indispensable in a project manager’s toolkit. Projects involve collaboration among individuals from diverse groups, departments, and even different companies. As the leader of this collective, it is your duty to foster teamwork, facilitate effective communication, and ensure that everyone works together to accomplish the project’s goals.

Undoubtedly, strong leadership is the most critical characteristic of an exceptional project manager. You should inspire your team members, nurture their unity, guide them towards the right actions, hold them accountable, and motivate them to perform at their best.

If managing work packages, overseeing projects, and potentially leading other project managers resonate with you, then project management could be a fulfilling path to pursue.

 

 

0.7 Project management software options

This section provides an overview of software options for project management, ranging from basic to advanced.

The most fundamental software option is a package that facilitates text processing, calculations, presentations, and email communication. These tasks are common to various job roles, including project management. Microsoft Office, or its open-source counterpart Open Office, is a widely used standard option.

For managing project schedules, specialized software packages are beneficial. While it is possible to create a Gantt-style chart using a spreadsheet, a dedicated tool is necessary to link bars and visualize how delays in work packages impact the overall project. Some options include Microsoft Project, Oracle Primavera, Monday, Smartsheet, and others. Most of these options are cloud-based, enabling seamless collaboration.

Since projects involve collaborative efforts, having a tool that facilitates teamwork beyond emails and phone calls is highly practical. Microsoft Teams, Basecamp, Asana, and Wrike are examples of cloud-based collaboration tools that enable group or individual chat messaging, file sharing, task delegation and tracking, and calendar sharing. Microsoft Teams offers additional features such as video conferencing, shared notes, surveys, videos, and more. It is often included in the Office 365 suite, which is commonly used in many companies.

For organizations managing multiple large-scale projects simultaneously, enterprise-level software packages for project, program, and portfolio management are worth considering. These tools help identify available resources with the required skills, particularly in large organizations where not all potential resources are known to the project manager. They facilitate end-to-end management of initiatives, from the initial business case to benefits realization, while viewing individual projects as components of larger aggregates like programs and portfolios. Implementing these tools can be challenging and require a significant investment. Well-known packages in this category include Microsoft Portfolio Management, Primavera Enterprise, Clarity, Planview, and others.

These are just a few examples of available software options. When selecting software to support project implementation, it is crucial to consider not only the functionality of the package but also the organization’s culture, work environment, available budget, the number and complexity of projects to be managed, as well as the effort and duration associated with tool adoption.

1.0 Why a project?

Need to Change – Problem, Opportunity, Regulation

To survive and thrive, organizations must balance two competing imperatives simultaneously.

The first imperative is to maintain current business operations, as it is through these operations that the organization generates revenue. By selling existing products and services to current customers, the organization secures the financial resources necessary to sustain its operations.

However, in a competitive environment, relying solely on selling the same products to the same customers and following unchanged production methods is not sustainable. Without improvement, competitors will outperform us.

Hence, the second imperative is to continually transform business operations, enhancing value creation capabilities to ensure long-term survival.

How do we achieve this? Projects are a traditional means of effecting the necessary changes by creating the artifacts and conditions required.

• Changes are necessary to address existing or future problems, such as improving production methods, reducing costs, or enhancing service quality.
• Changes are also necessary to seize opportunities and foster growth, such as entering a new market territory or targeting a different market segment.
• Finally, changes may be necessary due to the introduction of new regulations that must be complied with, whether we agree with them or not. Examples include workforce regulations or environmental mandates.

Regardless of the trigger for change, transitioning an organization from its current state to a desired future state necessitates new processes, capabilities, services, products, and even shifts in attitudes, beliefs, and behaviors.

Thus, temporary organizations called “projects“ are established to create these unique business elements. They are temporary because once the desired business outcome has been delivered, the specific project concludes, and project participants can move on to other assignments.

The justification for undertaking a project is typically compiled in a Business Case. This document provides management with the necessary information to assess whether a project is desirable, feasible, achievable, and therefore worth investing in.

 

 

 

1.2 Project Selection 1 – Portfolio management overview

This section will help you understand how project selection fits into a broader portfolio management process and how projects align with the organization’s strategy.

Let’s begin by clarifying what a portfolio of projects and programs entails.

Some individuals perceive a portfolio of projects simply as a collection of projects and programs approved by the organization. For instance, all IT projects and programs for the year. While this perspective is not incorrect, it falls short.

A portfolio of projects and programs should not be a random assortment. It has the potential to be the ultimate strategic vehicle through which an organization accomplishes its goals and objectives.

For instance, if the IT objectives for the year revolve around cost reduction, increased security, and minimized system downtime, then IT leaders should curate a portfolio of projects and programs capable of achieving those objectives.

Connecting the organization’s strategy with projects:

Organizations achieve their goals by effectively combining current business operations with activities that transform those operations.

To ensure that the projects in the portfolio are the ones that bring about the necessary changes to achieve the organization’s goals and objectives, and to ensure that these projects are appropriately intertwined with current operations in terms of proportion and timing, a selection process for project and program candidates must be implemented.

During this selection process, some projects and programs will be approved, others will be discarded, and some may be deferred. The reason is simple: there is always more work than can be feasibly accomplished. Therefore, priorities must be set, and decisions must be made accordingly.

Additionally, the composition of the portfolio needs to be regularly reviewed. If a project in the portfolio fails, it can be canceled and removed from the portfolio. The resources allocated to that project can be redirected to a new project or assigned to other ongoing projects, thus modifying the portfolio’s composition to align with the organization’s goals.

It is evident that the portfolio of projects and programs requires active management. Regular review and adjustment are necessary to ensure that the projects and programs it contains are appropriate and capable of achieving the organization’s business goals.

How many portfolios does an organization have?

At any given time, a company undergoes various operational changes through projects. Some projects contribute to the goals and objectives of the entire organization and form part of what is often referred to as the organization’s strategic portfolio.

However, the company does not solely have goals and objectives to achieve through a specific composition of current operations, projects, and programs.

Each department within the company also has its own goals and objectives, as each department functions as its own organization within the larger organizational structure of the company. Consequently, projects that align with the goals and objectives of a specific department must also be undertaken, although they are managed with more independence within the respective departments.

Therefore, it is common for a company to have multiple portfolios of projects and programs. There is typically an IT portfolio that supports the objectives of the IT department, a marketing portfolio for marketing objectives, and so forth for other departments within the company.

Each department contributes resources to the projects in the strategic portfolio that impact the entire organization, likely as a top priority. Simultaneously, they also need to execute the departmental portfolio with the remaining resources. All of this occurs alongside the execution of current operations, which generates the revenue required to sustain the entire system.

As we can see, the matter becomes complex, and the competition for resources is inherent. Hence, it is sensible to establish a role and a process to assist the organization’s leadership in managing the portfolio of projects and programs.

In summary, effective management of the portfolio of projects and programs is the key to aligning the organization’s strategy with its execution. This is achieved by combining operations, projects, and programs in an appropriate manner, ensuring that the company undertakes the right work in the right way at the right time to achieve its established goals.

Components of Managing a Portfolio of Projects and Programs

Managing a portfolio of projects and programs is a business leadership approach with seven distinct components.

The first component is the generation and capture of ideas about project candidates that the various areas of the company consider important. This is where the seeds of the future portfolio are planted. One must reach out to all areas of the organization, bring up and collect the ideas and suggestions that will help achieve the organization’s objectives, identifying the best obvious candidates which will be the subject of a more detailed selection.

The second component is building business cases for candidates retained during phase one to allow for more in-depth analysis. A standardized business case for all proposals allows their analysis and comparison, using rough estimates of expected costs and benefits. In a later lesson, we will delve into the notion of a “business case” as it forms the basis for project selection.

The third component is the assessment and modeling of capabilities. The projects being considered for approval are evaluated from the perspective of their feasibility for execution. It is assessed to what extent the people and necessary skills required for carrying out the projects are available or can be obtained, both individually for each project and as a whole for the combination of all projects, considering that day-to-day operations must continue. This is because there are resource constraints. The organization has a limited number of personnel and other resources, and current operations cannot be suspended to allow everyone to dedicate themselves solely to project execution.

The fourth component is selection and prioritization. This phase utilizes the results of phases one to three and considers other parameters to achieve a balanced portfolio. Additional selection parameters may include the risk level of each initiative, the positive and negative cash flows they generate, and the timing of these cash flows, among other criteria that the organization decides to include in a decision matrix to create a well-balanced composite. Some initiatives that are deemed important or profitable may need to give way to other initiatives considered more crucial, even if they are less profitable, but more feasible, less risky, or for other reasons determined by the selection parameters. The goal is to establish a rational selection process and avoid conflicts between different areas of the organization, each pursuing their own specific objectives.

The fifth component is the implementation of the strategy by executing the projects and programs in the portfolio, which occurs in parallel to current operations. The project management course delves into this aspect of the portfolio, providing detailed best practices for managing each project.

It is important to note that the inclusion of a project in the portfolio is not necessarily permanent since priorities may change, and projects in execution may progress differently than expected when they were selected and approved. This may necessitate adjustments or even the removal of a project from the portfolio. For example, if a project initially estimated to cost one million and be completed in 15 months shows during its execution that it will cost two million and take 30 months to complete, it may lose priority and require modification or removal from the portfolio.

The sixth component, change management, accompanies the entire portfolio management cycle. Change management is a complex aspect that deals with human behavior and factors that influence the ability to change, such as culture, values, and style. Depending on the change management model used, this component includes elements such as assessing readiness for change, measuring the adoption of deliverables, tracking results, and realizing benefits. It involves activities at the organizational level to identify factors that hinder change and eliminate or mitigate them, while enhancing factors that support change through communication and consultation activities to create understanding and gain support from stakeholders.

The seventh component deals with harvesting benefits and managing variations between the actual benefits achieved and the planned benefits. Portfolio management validates achievements, identifies what was not accomplished, and provides feedback to the portfolio management cycle described above, which starts again from step one, defining new initiatives to address the identified gaps.

Deliverables, outcomes, benefits, and goals: Three integrated perspectives in portfolio, program, and project management.

When a company decides to develop a new product, system, or process, it is not simply seeking those elements for their own sake but for the results they are expected to generate. For example, a new product allows a company to increase sales, gain new customers, and enter a specific market. This improvement in revenues and profits is what the company truly seeks, which is why the product is developed. However, “increasing company profits” is too broad of a goal for a single project or even a program.

To address this, an integrated vision of projects, programs, and portfolios is necessary.

Projects deliver products and can also encompass the generation of outcomes from using those products. It is important to note that if outcomes are included within the project scope, activities must be carried out within the project to validate the use of the created product and verify the outcomes. In recent years, project management has emphasized the importance of the outcomes that the delivered product should generate. For example, if the product is a new system, the expected outcome might be an increase in the number of transactions per hour of work.

Programs, which include projects and operations, go even further and must demonstrate that the collective set of projects and operations included in the program achieve the expected benefits. Continuing with the previous example, the increase in the number of transactions per hour contributes to higher customer satisfaction. However, achieving increased customer satisfaction likely requires more than just the project that creates and implements the new system. Therefore, to generate the benefit of increased customer satisfaction, the program must incorporate other necessary projects, such as changes in logistics to support increased transactions and a marketing project that emphasizes speed as a contributor to greater customer satisfaction. The program must also integrate operational activities, as it is the current operations that must adopt the new system and demonstrate through its use that the number of transactions per hour of work increases. Together with other outcomes from other projects in the program, this should lead to the expected benefit of increased customer satisfaction.

Lastly, the portfolio goes even further and aims to achieve the goals of the organization, which, if done correctly, should be the result of the benefits delivered by programs. Using the previous example, the portfolio management ensures that the benefits provided by programs, such as increased customer satisfaction, translate into the organization’s goals and objectives. Ultimately, the goal might be to increase the volume of sales per existing customer, attract new customers, and improve the company’s overall profitability.

As we can see, the portfolio management process is a comprehensive approach that extends beyond the management of individual projects or programs. It requires an integrative perspective that considers the interconnectedness of projects, programs, and portfolios. For example, if an organization initiates more projects than it can handle in a given period, leading to some projects not receiving the necessary resources, the root cause of the difficulties faced by those projects lies in inadequate portfolio preparation. Although the negative effects are felt by the project managers responsible for the resource-constrained projects, the real issue lies in portfolio management.

Summary

• The purpose of managing a portfolio of projects and programs is to achieve the goals and objectives of the organization.
• The composition of the portfolio changes not only due to the outcomes of the projects within it but also because of shifts in business priorities, emerging opportunities and challenges, and updates to the organization’s strategic plan.
• Managing a portfolio of projects and programs involves gathering ideas, analyzing them, selecting and prioritizing projects, executing them, reaping benefits, managing change, and incorporating feedback to initiate the portfolio management life cycle. Each of these elements is crucial for enhancing organizational performance, and together, they serve as a catalyst for achieving strategic excellence.
• The management of projects, programs, and portfolios must be integrated to ensure effective coordination and alignment.

 

1.3 Project Selection 2 – The Business Case

This section aims to provide an understanding of what a business case is and how it is used to justify a project proposal.

Let’s begin by clarifying the concept of a business case. In simple terms, a business case is a proposal that outlines the potential impact on the business if a proposed project is approved or rejected. The goal is to prevent the organization from investing resources in unfavorable projects and to prioritize those with better prospects for advancement in the selection process.

The development of a business case builds upon the ideas generated and captured during the initial step of portfolio management. Project proponents are required to create a business case for their proposed ideas. This serves as an initial filter: if the initiator doesn’t invest the time to articulate a business case in writing, detailing the idea, its costs, benefits, risks, and alternatives, it suggests that the idea lacks sufficient priority even for the person proposing it.

What elements should be included in a business case? There isn’t a universal rule. The breadth and depth of a business case depend on the organization’s specific policies, the size of the investment involved, and the available time. Let’s examine an extensive example of a business case, which can be simplified or shortened depending on the circumstances.

A good starting point is justifying the project by explaining the problem you aim to solve or the opportunity you intend to seize, along with the underlying reasons for undertaking the project. What is the problem, and what are its effects? Every problem has causes and consequences.

Do we truly want to address all the causes of the problem? Or only some of them? Which ones? Do we also want to address some of the most pressing effects? Which ones? For instance, if we have osteoarthritis causing severe knee pain, and the cause is a deteriorated joint, the solution may involve implanting an artificial prosthesis to address the root cause of the problem. Simultaneously, existing pain can be alleviated with analgesics to provide immediate relief from the problem’s effect. Alternatively, we may choose to live with the cause for a longer period and focus on treating the effects with pain relievers. These are aspects that the business case should clarify: the problem, its causes, effects, and which aspects we aim to address through the proposed project.

The project team then demonstrates that they have considered alternatives, evaluated them, and explains why the proposed solution is superior to other alternatives. The list of alternatives should always include the option of doing nothing, that is, not proceeding with the project. Another alternative is to implement a minimum solution that mitigates the negative effects. Additional alternatives can explore various approaches to addressing the causes or a combination of causes and effects.

The next element is the economic-financial calculation, providing rough estimates of costs, benefits, and timelines.

It’s important to clarify the risks involved, the assumptions made for the estimates, and any existing constraints. Risk identification and analysis are also integral parts of a business case. However, explaining risk analysis techniques and differentiating risks from assumptions goes beyond the scope of this section. To delve into these explanations, please refer to the lessons on risks within the contents dedicated to the initialization and planning processes, where such analyses are also conducted.

Estimates

When developing business cases, it is necessary to make estimates based on experience and assumptions. These estimates help determine the required financial resources, personnel, and other resources, as well as the projected timeline and expected benefits of the project. It’s important to note that during the business case development phase, these estimates are approximations. They acknowledge the inherent uncertainty in any project and the fact that they are not the result of detailed planning but rather an initial approximation. As a result, these estimates should not be used as the final project budget if it is approved. Instead, a “rough order of magnitude” (ROM) estimate should be used at this stage, which allows for a significant range of possible variation, sometimes even exceeding 100%, depending on assumptions and scenarios. The range of variation to be estimated should be greater for projects with more unknown factors, especially for unique or complex projects.

It’s important to remember that the business case development phase is not the same as project planning. At this point, it is still uncertain whether the proposed project will progress to the subsequent initialization and planning phases. No specialist team or project manager has been assigned yet. The initiator, likely the future sponsor, is responsible for creating the business case to propose to the organization. If the initiator intends to conduct a detailed study of the idea, they should propose a separate feasibility study project. If the organization approves this project, a dedicated team will be appointed to carry it out. This practice is typically followed for large investment projects that require technical, environmental, and financial feasibility studies. These preliminary projects are treated as separate endeavors. Once completed successfully, they provide a solid foundation for initiating the main project. However, for most projects, a business case is sufficient. Even in smaller project cases, the business case may be condensed into a concise narrative justification spanning a few paragraphs.

Parameters for Economic and Non-economic Analysis

Project executives typically utilize two types of parameters for project analysis: financial parameters and non-economic parameters, sometimes referred to as qualitative parameters. Financial analysis focuses on economic profitability and often carries more weight in project evaluation, particularly for for-profit entities. The parameters used to calculate project profitability include costs, benefits, and the timeline for cost and benefit realization.

Non-economic analysis incorporates “soft” elements and subjective judgment to assess intangible and difficult-to-measure information. Later, we will explore how this type of information can be quantified and integrated into a multi-criteria decision matrix, enabling a combination of both approaches. The goal is to identify the best proposals by considering all relevant factors.

Return on Investment (ROI)

Let’s begin with the economic-financial analysis by examining one of the most commonly used metrics for evaluating project financials: return on investment (ROI). The purpose of calculating ROI is to measure the return on the money invested in an economic entity over a specific period. It helps determine the viability of an investment.

ROI also enables financial comparisons between projects, even if they differ in nature. Generally, projects with higher ROI are prioritized. In a more sophisticated version, ROI calculations discount future cash flows to their present value, facilitating comparisons between projects with different payback periods. For example, if one project generates a €100,000 return in three years, while another generates €120,000 but in four years, it is unclear which is better. By converting those future cash flows to their present value, a meaningful comparison can be made. The mathematical calculations may not be evident to everyone, but common sense provides a guideline: Would you prefer to receive €1,000 within 12 months or within 24 months? Obviously, the sooner, the better. Consequently, the present value of €1,000 in one year is greater than the present value of €1,000 two years from now.

Let’s illustrate the calculation of ROI.

Non-economic Analysis

Now, let’s delve into non-economic analysis, also known as qualitative analysis.

Non-economic analysis involves the collection, analysis, and interpretation of data that goes beyond financial aspects, including subjective perceptions. For instance, within the business case, we might include parameters such as risk level, the impact on brand image through equipment’s contribution to decarbonization efforts, accessibility for individuals with disabilities, and the avant-garde image associated with the use of artificial intelligence in the equipment. Additionally, we can assess the project’s alignment with strategic objectives, such as promoting a technology deemed crucial.

When comparing a project with a 16% return on investment to another project with a 20% return, assuming that the 16% project contributes more to qualitative parameters, how do we make a decision?

To address this situation, we can employ a multi-criteria decision matrix, which we will discuss in more detail in the strategy evaluation section. However, here’s a brief preview.

		Project 1 (ROI 16%)		Project 2 (ROI 20%)
	Weight	Accomplishment (Scale 1 to 10)	Score	Accomplishment (Scale1 to 10)	Score
ROI	50	8	400	10	500
Risk	20	8	160	5	100
CO2	5	10	50	0	0
Social	10	7	70	0	0
Image	15	10	150	4	60
Contribution to strategic objective X	50	8	400	5	250
			1230		910

The first step involves defining the weights assigned to each parameter. Let’s assume that ROI carries a relative importance of 50 points in the total weight. The risk level is assigned a weight of 20, the effect on decarbonization contributes 5 points, the social factor carries 10 points, and artificial intelligence has a weight of 15. Additionally, we assign a weight of 50 to the contribution to strategic objective X, matching the importance of return on investment. As we can see, the sum of weights does not necessarily have to be 100.

Next, we convert the respective rates of return to a scale of 1 to 10, representing the fulfillment of each parameter. The first project with a 16% ROI receives a score of 8, while the second project with a 20% ROI receives a score of 10. Similarly, we assign scores to the risk level, with 8 for the less risky first project and 5 for the riskier second project. We proceed in a similar manner for the remaining parameters. By multiplying the weights by the parameter fulfillment scores, we obtain comparable scores for each parameter in both projects. The sum of these scores provides an overall evaluation of both alternatives. In this example, project 1, despite having a lower ROI, achieves a higher rating when considering the other parameters. This is because project 1 is less risky and contributes more to the non-economic parameters considered in the multi-criteria decision matrix.

Using the multi-criteria decision matrix technique allows us to compare parameters that are inherently difficult to compare. It accommodates subjective parameters like risk assessment or parameters with a high level of subjectivity such as the impact on company image resulting from social behavior and contribution to decarbonization. Subjectivity can be reduced by averaging the assessments made by a panel of individuals when evaluating compliance with non-economic parameters.

The multi-criteria decision matrix is also utilized during step four of the portfolio management process. This step involves the selection and prioritization of projects that have passed through the preceding filters to create a balanced portfolio, taking into account other parameters as explained in the section providing an overview of portfolio management.

Apart from ROI, assessing risk levels is the second crucial component of the business case that contributes to the composition of a balanced portfolio.

Another example of a non-economic or qualitative parameter could be the desire to prioritize a technology believed to be pivotal in the future of the business.

Including non-economic evaluation parameters has the potential to reshape the strategic positioning of an organization, giving rise to radically new products and services. All companies should allocate a portion of their budget to projects of this nature, even if they entail high-risk ventures, similar to the historical decision to embark on a journey toward India through the Atlantic, which ultimately led to the discovery of America.

Assembling the Whole Picture

Thus far, we have covered the elements typically included in a sophisticated and comprehensive business case, which encompass:

• The project justification, presenting various options to address the problem or seize the opportunity at hand.
• Financial assessment comprising costs, benefits, and timelines.
• Assumptions made and potential constraints.
• Identified risks at this stage.
• Possibly, qualitative selection parameters within a multi-criteria decision matrix.

If the resulting business case is extensive, which is likely when incorporating all the mentioned elements, it is advisable to include two additional points to facilitate decision-making for executives: an executive summary and recommendations.

 

 

Summarizing Key Points:

• A business case provides a summary of the potential impact on a business if the proposed project is approved or rejected.
• A business case includes project justification, options, cost and benefit estimates, timeline, identified risks, assumptions, constraints, and may feature an executive summary and recommendations.
• Business cases employ rough estimates with a wide range of variation to account for the level of uncertainty associated with the specific project.
• A business case does not entail project planning but rather serves as a preliminary step to determine whether investing resources in initiating and planning the project is worthwhile.
• Return on investment (ROI) calculation indicates the return on capital invested in an entity as a percentage per year, with a higher ROI indicating better returns.
• Besides financial evaluation, qualitative parameters can be incorporated and combined within a multi-criteria decision matrix.

 

 

 

 

 

1.4 Initializing a project – Overview

This section provides an overview of the activities required to initiate a project.

Initiating a project involves defining a new project or a new phase of an existing project by obtaining authorization to commence the project or phase. The purpose of initialization is to align stakeholders’ expectations with the project’s objectives. It informs stakeholders about the project’s goals and objectives and discusses how their involvement in the project and its phases can help ensure their expectations are met.

During initialization, the initial scope is defined, and the initial financial resources are committed. Stakeholders who will have an impact on the project’s overall outcome are identified. If not already assigned, a project manager is appointed. These details are recorded in the project charter and stakeholder register. Once the project charter is approved, the project is officially authorized, and the project manager gains the authority to allocate organizational resources to project activities.

Typically, the first step in project initialization is to assign the project manager, who will guide the project through the rest of the initialization process. Sometimes the project manager is appointed after the project has been approved. In such cases, it is essential to review the activities completed during initialization and ensure any skipped or unfinished tasks are addressed.

During initialization, you identify, analyze, and categorize stakeholders. You clarify which aspect of the problem or opportunity the project will address, define the purpose and goal of the project, identify and assess strategies to achieve the goal, and select the most appropriate approach. Additionally, you identify key deliverables, high-level risks, assumptions, and constraints. If a business case was created earlier, this is the point to revisit it.

Once you have an initial project definition, it is time to prepare the project charter. This document formally authorizes the project and outlines the project manager’s authority. In the following sections, we will describe the key elements involved in defining a project and the contents of a project charter.

 

 

 

 

1.5 Identify, Analyze and Classify project stakeholders

This section provides an overview of the activities required to identify, analyze, and classify project stakeholders.

Identify Project Stakeholders

As a project manager, it is crucial to know who has a stake in the outcome of your project – these individuals or groups are called stakeholders. They include the customer, project sponsor, departments involved in the project, and the people working on project activities. Understanding their expectations and contributions to the project is vital. It is important to recognize the stakeholders’ significance, influence, and interest in the project. This allows you to build relationships with influential stakeholders and ensure their satisfaction with the project’s results. Let’s begin by identifying the major roles of stakeholders.

The project customer is the individual or group with a problem to solve. They play three crucial roles in the project. Firstly, the customer funds the project. Secondly, they have a significant say in what the project will accomplish. Lastly, they approve deliverables throughout the project’s lifecycle.

The project sponsor is another stakeholder role. The sponsor is someone who wants the project to succeed and possesses the necessary formal authority to make it happen. For instance, an executive who believes in the project can act as a sponsor. The sponsor can assist in prioritizing objectives, engaging with unsupportive stakeholders, and suggesting improvements to the project plan.

The third type of stakeholder is a functional or line manager. These managers oversee departments and are responsible for achieving their department’s goals. They are also in charge of the personnel within their departments, whom you may need to staff your project.

Some organizations have a specialized department known as the Project Management Office (PMO), also referred to as the Project Office, Head of Project Management, or a similar title. The primary function of the PMO is to support project managers in various ways, such as developing an organizational project management method, monitoring project compliance, and providing training, coaching, and mentoring to project managers. If your organization has a PMO, it is naturally considered a stakeholder as well.

Team members are also stakeholders. While they are assigned to your project, their job security may depend on their performance and adherence to their assignments.

Lastly, there are departments or individuals who impact the project and those who are affected by it. Both groups are considered project stakeholders.

As a project manager, understanding stakeholders is crucial for keeping them satisfied. The first step is knowing who they are.

Analyze and Classify Project Stakeholders

Identifying stakeholders for your project, determining their importance, and finding the best way to collaborate with them can be challenging. This is where the stakeholder analysis document becomes valuable. You can store information in this document as you identify stakeholders and learn about their involvement in your project.

Identifying stakeholders and understanding their roles in the project is an ongoing process that unfolds throughout project definition. To begin, you need to know how each stakeholder is connected to the project and what motivates them. Include their department, business unit, or company affiliation, as well as their position within the organization.

Next, determine who the stakeholder listens to. This knowledge can be helpful when figuring out how to effectively engage with that stakeholder. You can seek guidance from the person they listen to or request their direct assistance.

Identify the project objectives, requirements, and expectations that matter to each stakeholder and assess how they prioritize those elements. This information helps you identify which stakeholders to consult if issues arise regarding objectives or requirements.

Categorize each stakeholder based on their influence and interest in the project. This allows you to prioritize stakeholders and manage the time you allocate to working with them effectively.

Finally, document the stakeholder’s contributions to the project, so you know what to expect from them or who to approach when specific needs arise.

Managing stakeholder satisfaction can become overwhelming and time-consuming if you lack knowledge about their desires and involvement in the project. That is why identifying, analyzing, and classifying project stakeholders is a crucial task during project initialization.

 

 

 

 

 

1.6 Identify which part of the problem / opportunity the project will address

This section focuses on the identification and agreement of the specific aspect of a problem or opportunity that the project will address.

Big Problems

One of the most common reasons for project failure is the scope being too large. A large project scope requires significant time and poses challenges in terms of planning and execution.

One might argue that if the organization is facing a massive problem or opportunity, the project to address it should also be substantial. However, the same principle applies to big problems as it does to elephants. The only way to approach an elephant is one bite at a time.

Organizational goals are like elephants, and their achievement often surpasses the capabilities of a single project. To achieve organizational goals, a portfolio of projects and programs collectively works towards the desired outcome.

To avoid projects that seem to never end, the key lies in program-level management. A program comprises a group of related projects and operations. Projects within the program deliver the components necessary for change, while operations within the program utilize those components, effectively bringing about the desired change. If the program is well-defined, the expected benefits outlined in the business cases and portfolio management selection phase should be realized. However, adjustments may be necessary by introducing new or modified projects and programs to account for variances between expected and realized benefits.

For instance, instead of defining a five-year project to assess the success or failure of new equipment that costs €100,000 and reduces operating costs by €45,000 per year, a program approach can be adopted. The program can consist of a one-year project to install the new equipment, followed by four years of operating the equipment to demonstrate the annual savings of €45,000. The program, as a whole, would deliver the envisaged benefits outlined in the business case, while the individual project would have its own success criteria, such as timely delivery, adherence to scope and budget, satisfaction with the project team, and ease of operation of the new equipment.

Big Problems. Multiple Problems

Let’s consider a more complex example to highlight the importance of defining the specific aspect of the problem that a single project will solve.

Suppose an organization’s goal is to double the overall customer retention rate within three years. This objective may stem from a profitability issue, which is a significant problem that cannot be solved in a single effort. To address such problems, it is necessary to break them down into smaller components.

In the case of a profitability problem, two components arise: declining revenues or rising costs, or possibly a combination of both. For the sake of illustration, let’s focus on the revenue aspect and further break it down. Revenue issues can be attributed to sales volumes or realized prices. Let’s concentrate on the volume of sales, which remains a substantial issue. Within the volume of sales, there may be challenges in acquiring enough new customers and/or existing customers not making sufficient purchases. In this scenario, the focus is on existing customers.

Through problem-solving techniques, it may be revealed that the primary cause of customer attrition lies in dissatisfaction with customer handling, rather than the quality or price of existing products. Consequently, the strategic goals for the next three years include increasing customer retention from the current 35% to 50% within one year and to 85% within three years.

Analysis shows that customers are dissatisfied with the prolonged order delivery times and lack of transparency regarding the progress of their orders. They feel uncertain about when they will receive their goods. Additionally, the customer service desk experiences constant phone congestion, and when customers do reach an operator, there are often unnecessary questions to identify the customer and track their order’s status. Furthermore, responses to customer complaints are defensive and occasionally unfriendly. Inconsistencies in accounts receivable management are also noticeable.

The low customer retention rate of 35% is a cumulative effect of several problems across different areas. By breaking down the cumulative problem into its individual sources or causes, each smaller problem can be addressed through a single project or sub-program. Assuming a thorough job in identifying the sources of the problem, resolving these smaller problems should result in the desired outcome—an increased customer retention rate. Over time, this should contribute to higher turnover with existing customers and improved profitability. It is important to note that additional projects and programs may be necessary at other levels of the organization, such as cost management, pricing adjustments, and new customer acquisition.

Lastly, it is worth considering the notion of defining individual projects of a manageable size. Managing projects requires time, and a project manager typically has around 2,000 working hours in a year (50 weeks x 40 hours per week) when working full-time. The rule of thumb has been consistent since ancient times: approximately 1 manager or coordinating person for every 6 full-time equivalents (FTEs) to be coordinated. With six FTEs, each working 2,000 hours per year, a total effort of approximately 12,000 hours is collectively produced.

This means that if a project’s estimated effort exceeds 12,000 hours in a year, the project manager will require additional support to manage the initiative. This support may come in the form of suppliers who not only provide their teams but also their team leaders. The same principle applies if the suppliers are internal, as the project manager can delegate the execution of work packages to a team leader.

The key takeaway is that there is a limitation on the project manager’s capacity to manage 12,000 hours of work. However, if the project manager is overseeing six team leaders, each managing a sub-team of six individuals, the project manager’s capacity can expand to 72,000 hours of work, equivalent to 36 full-time persons. It is crucial to recognize that, like everyone else, project managers have limitations on the amount of work they can manage.

This limitation serves as a parameter to consider when determining which part of the problem the project will address. Other parameters include:

• Breaking down big problems into smaller ones.
• Establishing manageable individual projects to address those smaller problems.
• Combining those projects into programs for coordinated management and benefit delivery.

 

 

 

 

 

1.7 Define purpose and goal

This section will explain why defining the problem or opportunity and, from there, the purpose and the goal is the best start for any project.

The first step toward project success is finding out what the project will try to accomplish and why. The answers to the “why question” are the purpose. The “what you are trying to accomplish” is the goal. Objectives are more specific than the goal and come later, after deciding on the selected strategy.

Let’s focus first on purpose and goal. Both are distilled from the problem statement, which is the very first step. You want or need to accomplish a specific goal BECAUSE there is a problem or an opportunity, so you start by putting together a problem or opportunity statement with two sections.

First, a description of the current state as it is today, mentioning the pain points expressed by stakeholders and the consequences in areas such as money, time, productivity, or competitive advantage. This section helps formulate the purpose statement, the reason why the organization will execute a project.

Second, a description of the ideal future state, illustrating what the matter would look like once a solution is implemented. This section helps define the goal to be attained.

Developing a problem statement can be challenging because people often jump straight to solutions. But solutions describe outputs, items supposed to solve the problem. This is not what we are seeking at this stage. We are trying to understand and get agreement on the problem to be solved.

The process of defining the problem is often a group effort. It starts with meeting with the stakeholders and learning about their pain points. It is helpful to ask a series of “why” questions until the underlying reasoning is identified. This method, known as the “5 Whys,” helps drill down to the core problem, as many of the experienced frustrations could be mere symptoms of the actual problem.

In the example about low profitability, using the method of the 5 Whys, we have decomposed the problem of the low customer retention rate into its root causes, the drivers of the problem: long delivery times, lack of transparency of the status of transactions, inefficiency in the handling of customers at the customer desk, and inconsistencies in accounts receivable.

When going deeper into the problem of “lack of transparency of the status of transactions” and continuing to ask “why” questions, the answers might be: “we do not inform customers of the status of orders because the information is spread across several systems and not all products have a clear workflow, depending on which supplier is involved in production.” You see that this type of answer is getting us closer to objectives leading to the goal of increasing transparency of transactions. We are getting hints at “consolidating information in one system” and “defining workflows, including participating suppliers,” things that the upcoming project will need to solve.

But we are still defining the purpose and the goal from the problem statement with its two sections: first, the current state and consequences, and second, the future state. From this, you can distill the purpose statement and the goal statement.

A project to improve the “lack of transparency of the status of transactions” could formulate a purpose statement such as: “we should be able to provide an accurate status of customer transactions because the current lack of transparency is making us lose customers that have been acquired with considerable effort, costing us x amount of money per year.”

This is the answer to the purpose question, the “why” we are doing the project. The purpose statement can be extremely helpful, providing guidance when some decisions must be made and recalling all stakeholders why we are doing the project, including the consequences of not doing it.

With the purpose statement in hand, you are in a better position to define the project goal, and you can reuse the second part of the problem statement, describing the future state, which becomes the result of the upcoming project, the “what” the project should deliver and is now linked to solving the situation that motivates the project.

The goal should be specific and easy for everyone to understand. That way, you can use it to get buy-in and guide the team to a successful conclusion. In our example, the project goal might be “provide transparency of the status of all transactions along the entire workflow.”

A final word about the difference between goals and objectives. Many people use those terms as synonyms, but in fact, they are not the same. Goals are the outcome you intend to achieve, whereas objectives are the actions that help you achieve a goal and are defined a bit later, after deciding on the strategy to solve the problem, for which there is normally more than one option.

In our example, being the goal “provide transparency of the status of all transactions along the entire workflow,” associated objectives to attain this goal could be: “consolidate information in one system” and “define and implement workflows for all products, including participating suppliers.” If you consolidate information in one system AND define and implement workflows for all products, including suppliers, we can assume that we would achieve the goal of providing transparency of the status of all transactions along the entire workflow (perhaps more objectives need to be defined to attain the transparency goal).

However, in the project management process explained here, we do not try to define specific, time-based objectives yet. Instead, we are still working at a higher level, using purpose and goal definition as part of initiating a project. We think that the objectives definition comes later or might need to come later because objectives are actions leading to the goal and depend on the strategy that needs to be selected first. For example, to attain the goal of providing transparency to the status of transactions, you could theoretically decide to hire 10 new admin persons to gather manually the information spread out in several systems without a clear workflow. The result would be transparency as well, but the deliverables and actions to be undertaken are completely different if you are hiring and training 10 new admin people than if you are consolidating information in one system and creating workflows involving suppliers.

Let’s summarize by saying that the best way to start a project is knowing what you are trying to accomplish and why. This is done using the techniques explained, but it is also an “art,” and – like any art – one needs practice to master it.

 

 

 

 

1.8 Elicit business requirements

This section is about eliciting business requirements during project initialization.

According to the International Institute of Business Analysis, a requirement is a documented representation of a condition or capability.

There are business and functional requirements. Business requirements describe the new capabilities the organization will have as a result of the project. On the other hand, functional requirements specify how the solution will satisfy these needs. They will be defined during the planning stage when a team of subject matter experts will be available.

Now, during the initialization stage, we focus on business requirements and stay at a high level since we are not yet describing the details of a specific solution.

Let’s reuse the example of the project with the goal of “improving the transparency of the status of all transactions.” Let’s assume that the strategy definition finally selected the online solution as the key deliverable.

Which new capabilities does the organization strive to achieve with this goal and building this solution?

These new capabilities could include, for instance:

• Allowing customers to place, follow-up, and change orders online without the intervention of the customer service department.
• Allowing the company to invoice customers without human intervention from the accounting department.
• Allowing customers and the company to have a summary and the status of all orders and invoices, including all past transactions.
• Allowing customers and the company to have access to all past communications between the customer and the company.
• Allowing the customer service department, during phone calls, to identify the calling customer immediately and have all related information at hand.

These high-level business requirements are outcomes of the project, new capabilities that will be enabled once the key deliverables are handed over to operations. They are not yet the benefits, which are expected to result, over time, from these outcomes.

In our example, the benefit will be a higher customer retention rate, assumed to be achieved through the envisaged transparency of transactions, which is the summary outcome of the new capabilities. However, we have identified during the problem analysis that transparency of transactions alone will not be enough since there are other sources of dissatisfaction. Therefore, the outcome of the transparency project needs to be combined, in a program, with the outcomes from other projects addressing the other causes of dissatisfaction. Remember that our case study shows customer dissatisfaction originating from several root causes, including the lack of transparency of transactions, errors in invoices, long wait times on the phone, unfriendly answers, and long delivery times.

During the meetings to gather high-level business requirements (which is what we are doing in the initialization of a project), keep in mind to focus on getting agreement on the new capabilities the business seeks to have once the key deliverable is in place. Avoid trying to describe how these capabilities will be implemented from a technical point of view. Statements that include information about files, feeds, tables, flags, indicators, architecture, and so on are solution-oriented statements and do not belong here and now.

To summarize, high-level business requirements are not technical requirements, but rather the new capabilities the business seeks to acquire through the project. They are part of the definition work that goes into the project charter.

 

 

1.9 Identify and assess strategies; select the most appropriate

This section will show you techniques to identify and select the right strategy to achieve the goal of your project.

You will likely find that there is more than one way to achieve your project goal. Let’s look at how you can evaluate alternative strategies and select the most appropriate one.

First, gather a small group of people familiar with the project to brainstorm strategies. As a group, read the statements about the problem, purpose, and goal, and then begin generating possible strategies. Brainstorming should be a free flow of ideas. The goal is to get as many ideas written down as possible before you begin evaluating them.

Once the group has identified possible strategies, they collectively evaluate them using a decision matrix to compare the options. This evaluation involves assessing how well each alternative satisfies the selection criteria.

Using our example of the goal “increase the transparency of transactions for all products along their entire workflow,” let’s say the group has identified three possible alternative strategies:

• An automated online system
• A server system with batch overnight processing
• A manual process using more administrative personnel

To evaluate these potential strategies, we need to define the selection criteria.

Let’s say the group establishes the following selection criteria:

• The speed and accuracy of the information generated by the solution
• The level of the initial investment
• The costs per year of the solution
• How quickly the solution would be available
• The possibility to implement it with internal resources

The next step is to weight the importance of each aspect, known as their weighting. When some aspects are more important than others, we assign them a higher weight. For instance, 1 is the lowest level of importance, and 5 is the highest level of importance.

We also need to establish the scale used to assess the degree of fulfillment of a criterion. Let’s say the group decides to use a scale of 1 to 5, with 1 being the lowest level of fulfillment and 5 being the highest.

Then, the alternatives and the weighted criteria are placed in a matrix. Let’s assume that speed and accuracy of the information and speed of availability of the solution are the most important, with a weight of 5. Cost per year has a weight of 4, initial investment has a weight of 3, and the possibility to implement it with internal resources has a weight of 2.

Criterium	Weight	Online		Batch night		Manual
		Fulfillment	Score	Fulfillment	Score	Fulfillment	Score
Speed and accuracy of the information	5
Initial investment	3
Cost per year	4
Speed of availability of the solution	5
Implementation with internal resources	2

Next, the group proceeds to numerically evaluate the fulfillment of each criterion for each alternative. The result could be as follows: In this example, the batch overnight solution gets the highest score of 69. Speed and accuracy of the information are lower than the online alternative, but the score for the initial investment is higher (score 9 compared to 3 for the online alternative), and especially the score for speed of availability doubles the score of the online solution.

Criterium	Weight	Online		Batch night		Manual
		Fulfillment	Score	Fulfillment	Score	Fulfillment	Score
Speed and accuracy of the information	5	5	25	4	20	2	10
Initial investment	3	1	3	3	9	3	9
Cost per year	4	5	20	4	16	1	4
Speed of availability of the solution	5	2	10	4	20	4	20
Implementation with internal resources	2	1	2	2	4	4	8
			60		69		51

To improve the accuracy of the evaluation, we can further define each criterion. For example, we could establish more precise values for different levels of “speed” and “accuracy” of the information. Here is an example: You can assign the highest score of 5 to very accurate answers within 1 to 10 seconds. And allocate a low score of 1 to any answer that is expected to be inaccurate, regardless of speed. Intermediate values can be populated with a reasonable distribution in the middle areas.

	Level of precision of the answer
	Unprecise 1				Very precise 5
1-5 seconds	1	3	4	5	5
6-10 seconds	1	3	4	4	5
11-15 seconds	1	2	3	4	4
16-20	1	2	2	3	3
21-25	1	2	2	3	3

Following a similar logic, we can define more precise values for the other criteria. For example, we can define further ranges for “initial investment” and assign a value of 5 to an investment of 10 to 20 thousand, a score of 4 to an investment of 21 to 50 thousand, and so on, down to a score of 1 for an investment of 200 to 500 thousand. That means: The higher the required investment, the fewer points the alternative receives.

Initial investment	200 k – 500 k	101 – 200 k	51-100 k	21- 50 k	10-20 k
	1	2	3	4	5
Cost per year	200 k – 500 k	101 – 200 k	51-100 k	21- 50 k	10-20 k
	1	2	3	4	5
Speed of availability	18-24 months	12-18 months	7-12 months	4-6 months	1-3 months
	1	2	3	4	5
Implementation with internal resources	Very unlikely	Rather unlikely	Somehow likely	likely	Almost certain
	1	2	3	4	5

We continue with the same logic, defining numerically different ranges of performance for costs per year, speed of availability, and likelihood of implementation with internal resources. The result could be as follows: A level of running costs per year of 10 to 20,000 gets the highest value of 5, while running costs of 200,000 to 500,000 get a value of 1. Other possible running costs per year in the middle range receive values between 1 and 5.

Initial investment	200 k – 500 k	101 – 200 k	51-100 k	21- 50 k	10-20 k
	1	2	3	4	5
Cost per year	200 k – 500 k	101 – 200 k	51-100 k	21- 50 k	10-20 k
	1	2	3	4	5
Speed of availability	18-24 months	12-18 months	7-12 months	4-6 months	1-3 months
	1	2	3	4	5
Implementation with internal resources	Very unlikely	Rather unlikely	Somehow likely	likely	Almost certain
	1	2	3	4	5

The same approach is applied to the speed of availability of the solution, where a solution available within 1 to 3 months receives the maximum value of 5, and a solution taking 18 to 24 months to implement gets a low score of 1. Other durations would receive different gradations between the maximum and minimum values.

Initial investment	200 k – 500 k	101 – 200 k	51-100 k	21- 50 k	10-20 k
	1	2	3	4	5
Cost per year	200 k – 500 k	101 – 200 k	51-100 k	21- 50 k	10-20 k
	1	2	3	4	5
Speed of availability	18-24 months	12-18 months	7-12 months	4-6 months	1-3 months
	1	2	3	4	5
Implementation with internal resources	Very unlikely	Rather unlikely	Somehow likely	likely	Almost certain
	1	2	3	4	5

Likewise, the likelihood of implementing the solution with internal resources can be evaluated, assigning a score of 5 to “almost certain” and a score of 1 to “very unlikely.”

Initial investment	200 k – 500 k	101 – 200 k	51-100 k	21- 50 k	10-20 k
	1	2	3	4	5
Cost per year	200 k – 500 k	101 – 200 k	51-100 k	21- 50 k	10-20 k
	1	2	3	4	5
Speed of availability	18-24 months	12-18 months	7-12 months	4-6 months	1-3 months
	1	2	3	4	5
Implementation with internal resources	Very unlikely	Rather unlikely	Somehow likely	likely	Almost certain
	1	2	3	4	5

It is possible that when the group uses more precise values to define each criterion, they arrive at different scores, reducing discussions about whether one alternative receives a 5 or a 3 for a criterion.

Let’s assume that using numerically defined ranges for each criterion, the group now arrives at a different score, giving the alternative “batch overnight” a 3 for cost per year and another 3 for the speed of availability of the solution, considering the more precise values.

Criterium	Weight	Online		Batch night		Manual
		Fulfillment	Score	Fulfillment	Score	Fulfillment	Score
Speed and accuracy of the information	5	5	25	4	20	2	10
Initial investment	3	1	3	3	9	5	15
Cost per year	4	5	20	3	12	1	4
Speed of availability of the solution	5	2	10	3	15	4	20
Implementation with internal resources	2	1	2	2	4	4	8
			60		60		51

The result would be that in this example, both the online and batch overnight alternatives receive the same scores of 60 each.

The team could then reevaluate the relative weights assigned to each criterion and reconsider whether speed and accuracy of the information (which initially had a weight of 5) are as important as the “speed of availability of the solution.” Let’s say the group decides that the speed of availability is ultimately more important, and the weight of the criterion is changed from 5 to 4. Now, the most important criterion is the speed of availability of the solution with a weight of 5.

The result would be the following, indicating that the best strategy is to first implement a solution with batch overnight.

Criterium	Weight	Online		Batch night		Manual
		Fulfillment	Score	Fulfillment	Score	Fulfillment	Score
Speed and accuracy of the information	4	5	20	4	16	2	8
Initial investment	3	1	3	3	9	5	15
Cost per year	4	5	20	3	12	1	4
Speed of availability of the solution	5	2	10	3	15	4	20
Implementation with internal resources	2	1	2	2	4	4	8
			55		56		51

In summary, the strategy with the highest overall rating is most likely the winner. You can include other criteria in the matrix, such as how risky or feasible the alternatives are. For example, strategies that use new technologies or unproven methods might receive lower scores for this criterion. If the feasibility of the best alternative appears to be an issue, the group can decide to perform a feasibility study to explore whether the strategy will work without committing too much time or money. This is what Agile development methods refer to as a “spike” — investigating or experimenting with one idea to see if and how it works before moving to development, avoiding speculation about the outcome of a solution.

Depending on the type of alternatives, another criterion could be whether the strategy fits the culture of the organization. Trying to force a strategy that does not align with the culture might be a losing battle. Alternatively, you might need to include a project within the program to change the organization’s culture in this aspect, although it is a challenging task. It is important to note that if you don’t have the commitment you need from management and team members, you will face difficulties.

In summary, evaluating alternative strategies helps you select the right solution for your project. This is a group exercise that should be done before diving into detailed planning for any solution, ensuring that you are not only doing your work well but also doing the right work.

 

 

 

 

1.10 Identify key deliverables

This section is about identifying key deliverables.

A deliverable is anything that is produced or provided as a result of a process. To achieve goals and objectives, you must produce deliverables. When the project is accomplished, you must have produced and handed over the key deliverable, and this key deliverable must have been accepted or signed off.

The key deliverable, tangible or intangible, is the item that satisfies or should satisfy the main goal. Intermediate deliverables are needed to satisfy objectives leading to the goal or to manage the project.

Project deliverables vary greatly from project to project and from company to company.

Deliverables could be big or small: a product, a prototype, the capability to provide a consultation service, an app, test results, a contract, etc.

They can be tangible, like a magazine or a phone, or intangible, like a cultural change or the decrease in errors in a process.

Commonly, deliverables depend on the completion of other deliverables. For example, houses are developed and built for external customers. The house is the key deliverable, the end result or output of a housing project. The architectural design to create the house is created by an architect as an internal deliverable for the builders. The architectural design is not the key deliverable from the end customer’s point of view, nor for the housing project manager. From their point of view, it is an intermediate deliverable, an enabler to another deliverable. But from the point of view of the architect charged with the architectural design, this is his key deliverable, the end result of what is, for him, a project and is from the point of view of the overall project manager, a sub-project or a work package.

In our example with the goal to increase the transparency of transactions along their workflow, the key deliverable would be the system up and running, as well as the associated processes and capabilities to operate it.

Intermediate deliverables associated with objectives leading to the goal could be a transparent workflow for each product, an integrated IT system and the associated subsystems, training for operators, a handbook, etc. It could also include new capabilities on the side of participating suppliers and a marketing campaign to announce to the public the new way to process transactions, and more items that still need to be identified when detailed requirements will be gathered during project planning and the scope definition will be done. But it is too early for that at this stage. As explained in the module about purpose and goal, we think that the project initialization is too early for the definition of objectives and intermediate deliverables.

Much depends on how much work was done in a pre-project. If the project selection work included not only a superficial financial appraisal but also produced a deep analysis of alternatives and perhaps a technical feasibility study of a selected alternative, i.e. the project was divided into two projects, the first one having as a key deliverable a selected option including a technical study of its feasibility, then you would initiate the subsequent project to implement this solution with an already selected alternative and a detailed work that could allow you to define during initialization not only the purpose and the goal but also specific objectives linked to intermediate deliverables.

Finally, if you are the project manager, then your list of deliverables will also include project management plans and documents that help manage the project, such as a project charter, a project management plan and subsidiary plans, reports, etc. These are also deliverables, internal management deliverables, and not all of them are shared with the final customer.

 

 

1.11 Define project success criteria

This section is about defining project success criteria.

A significant problem with assessing project success is that it is often imprecise. Different interpretations from different viewpoints are allowed. This can be crucial since project success is a springboard to career advancement.

Is there a definition of project success?

Well, over the years, the predominant definitions of project success have changed.

In the early days of project management, project success was measured entirely in technical terms: either the key deliverable worked, or it did not.

Later, this view was expanded to encompass other aspects: completion on time, within budget, and at an acceptable level of quality. These elements are known as the triple constraint. This definition of project success has been and continues to be widely used as the predominant project success definition in many projects.

More recent understandings of project success include an even broader view. It expands the criteria to include customer satisfaction with the project team. For instance, how problems were solved, how well communications worked, and similar factors.

In recent years, additional soft criteria are being added, such as “not disturbing the main workflow of the organization” or “not stressing the corporate culture.”

Also, the rise of the disciplines of program and portfolio management has provided new insights into the considerations of what constitutes project success. They direct attention to benefit realization (program management) and the achievement of corporate goals (portfolio management). Both views are driven by a focus on business policy and organizational strategy.

So, you might think it is becoming more and more difficult to be successful, and you are right.

 

 

How do we define project success?

Some people tend to define it via benefit realization. Benefit delivered means the project is successful. But, as we have seen, the benefit is not there at the end of the project. It results from project outcomes over time, after the project is completed. This is a post-mortem definition of success.

Should we wait two years after delivering the online solution to increase transparency and see if the customer retention rate has indeed increased? This would be too late for a project team that dissolves after handing over the solution to operations.

We want and need a declaration of project success (or failure) at the end of the project. After all, the declaration of success or failure should be part of a good project closing.

Here is a solution. As part of the project definition during initialization, we can create a composite of success criteria using the classical triple constraint: delivery on time, within budget, and with an acceptable level of quality. We can combine this with a few other indicators, such as customer satisfaction with the product and the project team. You can also consider some of the more sophisticated criteria mentioned above, but try not to overload the project scorecard. Remember that if you define metrics, you will have to collect them.

Here is an example of a project scorecard that can be defined at project initialization and used to clearly measure project success:

• Delivery on time: measured by the planned end date (in the last approved version of the PM Plan) versus the actual delivery date or final acceptance.
• Within budget: measured by planned costs versus actual costs.
• Acceptable level of quality: This needs further definition, for instance: all “must be” requirements met, as well as 80% of all “should be” requirements. You could also include, for example, 20% of all “can be” requirements. Note that we do not yet know what the functional requirements and specific quality attributes of the solution and its components will be, but we know that we will be able to classify them as “must be,” “should be,” “can be,” and “won’t be,” whatever they may be. The business requirements would be part of the “must be” list.

With those elements, we would have the classical components of the triple constraint covered. And this is considered more than sufficient for many projects.

If you want to be more sophisticated, you can include elements of customer satisfaction not only with the solution but also with the project team.

You can possibly assign different weights to each criterion.

Is “within budget” or “on time” as important as “good quality”? And should these criteria have the same weight? Perhaps yes, perhaps not.

Is overall customer satisfaction with the team more important than the other criteria? Perhaps yes, perhaps not.

It depends on your project and your organization, and you need to agree on that with stakeholders.

In summary, you should define clear, quantifiable success criteria for the project ahead of time and not wait until the project ends, hoping it will be considered successful.

 

 

 

 

1.12 Identify high level risks, assumptions and constraints

This section is about identifying high-level risks, assumptions, and constraints.

Let’s recap where we are in the process.

At this stage, we are not yet planning the project. We are initiating a project, gathering the elements that will populate the project charter to seek project approval before moving on to detailed planning.

Before detailed planning, we will need to work extensively with assumptions. It is also time to identify any existing constraints that future planning will have to consider. We should also identify at least high-level risks, even if we can’t yet pinpoint specific risks related to items that have not yet been defined. However, we can certainly identify risks that are typical for the type of project we are initiating.

First, let’s understand what risks, assumptions, and constraints are.

Risks and Assumptions

A risk is a potential future problem that has not yet occurred. Some methods also refer to “positive risks,” which we prefer to call “opportunities.”

Risk refers to future conditions or circumstances that exist and could have an adverse impact on the project, with a certain degree of uncertainty regarding their occurrence. If they are 100% certain, they are not risks but facts.

Assumptions are statements believed to be true. In other words, you are not 100% sure that they are true or will happen, but you assume them to be true for the purposes of planning your project. You might assume that certain things the project needs to happen will indeed happen or that certain things that could harm the project will not occur.

As you can see, assumptions and risks can overlap. If you categorize a future event as an assumption (“we assume that a certain negative event will not happen”), and if this negative event does occur, it turns out that the event was indeed a risk for which you might have needed to do more than assume it wouldn’t happen.

Let’s consider an example of a common statement included in many Project Charters – that “the resources needed for this project will be available when needed.” What kind of statement is this? Most people would say it’s an assumption. After all, when a project starts, you always assume that you will obtain the necessary resources.

However, is it truly an assumption? Can you imagine starting a project without the assurance that the required people and equipment will be available and that there is a realistic possibility they won’t be ready when needed, perhaps because another project needs to finish first? It’s not too difficult to envision such a scenario. In that case, the same statement would definitely be a risk, not an assumption.

The key point is that the same statement can be an assumption or a risk depending on the circumstances of your particular project. The distinction between an assumption and a risk lies in whether the combination of probability and impact is acceptable to you or not. If the event is negative, and the combination of probability and impact is not acceptable (that is, the combination is too high), it should be stated as a risk. If the event is negative and the combination of probability and impact is acceptable, it can be classified as an assumption.

Let’s consider an example. Are the following statements assumptions or risks?

The project sponsor will provide strong, active support to the project.

The online infrastructure will be installed by the supplier in time, before we are ready for final testing.

In both cases, depending on the project, there could be a high degree of risk in each statement, with a significant impact or a low probability. Therefore, they can be classified as assumptions.

Since we are initiating the project and there are many unknowns handled as assumptions, we are not yet able to perform a detailed risk analysis. However, we can certainly identify some risks that are typical for the type of project we are initiating, and we should identify them.

Inherent Risks

Inherent risks are those that exist based on the general characteristics of the project.

For instance,

Characteristic	High Risk	Low Risk
Total effort hours	Large project, for instance > 20.000 person/hours work	Small project < 250 hours
Duration	Longer than 12 months	Less than 3 months
Team size	Over 25 members	Fewer than 5
Number of organizations involved	More than three	One
Project scope / deliverables	Poorly defined	Well-defined
Business benefit	Not clear	Well-defined
Requirements	Complex, hard for customer to define	Clear, easy for customer to define
Dependency on other projects or outside teams	Dependent on three or more outside projects or teams	No more than one dependency on an outside project or team
Project sponsorship	Unknown, passive	Identified and enthusiastic
Changes required to existing procedures, processes, and policies	Large amount of change	Little change
Project manager experience	Little experience on similar projects	Similar experience on multiple projects
Physical location of team	Team is dispersed at several sites	Team is located together
Technology	New technology is being used for critical components	No new technology required
Supplier	Have not worked with the supplier before	Proven supplier

Depending on this initial high-level analysis, the sponsor can make informed decisions regarding the overall project design, including the project goal or strategy, if the level of risk appears to be too high.

Constraints

Now, let’s discuss constraints for a moment.

Constraints are limitations that are beyond the control of the project team and need to be managed accordingly.

They are not necessarily problems. Unlike risks, they are not uncertain; they are facts. For example, date constraints dictate that certain events, such as milestones or project phases, must occur by specific dates. Consider a project aiming to participate in an international fair or exhibition with a new product. The fair will not wait; the exhibition date serves as a constraint.

There can also be resource constraints, such as a maximum number of people available for the project. Additionally, specific requirements may exist, such as half of the team needing to be French speakers or of a particular gender, or Fridays being designated as holidays. All of these are examples of constraints.

Budget constraints may also be present, where the project cannot exceed a certain amount of funding. This means that the scope of the project must be planned within this financial limitation. However, if, during the planning stage, the team determines that the required scope exceeds the budget constraint, negotiations will be necessary. Either the budget constraint, the scope, or both will need to be reviewed.

In summary, identifying high-level risks, assumptions, and constraints is an essential step in defining your project before seeking approval and proceeding to detailed planning.

 

 

1.13 Participate to the development of the project charter and obtain sponsor approval

This section focuses on the contents of a project charter. Once you have completed the process of defining the project, it is time to consolidate all the information into a single document known as the project charter. When approved, it officially authorizes the project, announces it to the world, and paves the way for the planning stage.

The purpose of defining a project and capturing it in a charter is to provide the project customer or management team with the necessary information to approve the project. There are three potential outcomes of the charter approval process: the project candidate is approved and can proceed to planning, it is denied, or it is sent back for revisions.

Here are the typical elements included in a project charter:

• Project name
• Purpose and goal of the project, explaining what the project aims to achieve and why
• Key deliverable(s), describing what the project will create to accomplish the goal
• High-level project description
• Initial high-level requirements and project success criteria
• High-level risks, assumptions, and constraints
• Possibly a high-level milestone schedule
• Allocated funds or budget constraints, if applicable
• List of stakeholders
• Organizational structure depicting how the project organization fits into the overall structure of the organization

It is important to note that the project charter is not a project management plan, which comes in the next phase. The charter consolidates the information and decisions made during the initialization stage, establishing the foundation of the project and transforming it from an idea into a formally established temporary organization. More information and decisions required to execute the project will be developed during project planning. However, the charter serves as a critical step, defining the central parameters of the endeavor and designating a project manager in charge.

Therefore, the charter includes the name of the project manager and their responsibilities. It outlines the extent of the project manager’s authority, such as leading a core team that reports to them throughout the project, requesting resources from functional departments, and making decisions regarding contracts and supplier orders.

Lastly, the charter is signed by the sponsor, signifying official support for the project. Think of the project charter as a power of attorney granted to the project manager by the sponsor or customer. Some organizations even require the co-signature of the project manager alongside the sponsor’s signature, treating it as a contractual agreement between the sponsor/customer and the project manager.

You may wonder why the project charter specifies the project manager’s authority. This is because project managers do not possess the same authority as functional managers within the permanent organizational structure. A project manager’s authority begins with the project, extends throughout its duration, and applies solely to that specific project. Therefore, it is essential for people to understand what the project manager is authorized to do, particularly in the context of their project. The level of authority can vary depending on the type of project and organization.

Once the project charter is signed, the project sponsor distributes it to the relevant stakeholders. This signifies that the project manager has officially been authorized to oversee the project, and their authority as the project manager becomes common knowledge. They are now ready to commence the management of the planning stage.

 

 

1.14 Inform Stakeholders about the Charter – Kickoff meeting

This section focuses on informing stakeholders about the approved project charter and commencing the planning stage with a kickoff meeting.

The objectives of the kickoff meeting are to officially announce to all stakeholders that the project has started, highlight the existence of the new temporary organization, and ensure everyone has a shared understanding of the project and their respective roles. Bringing together team members, customers, and key stakeholders in a kickoff meeting sets the stage for the upcoming planning stage, which requires organizational resources.

Similar to any formal meeting, the kickoff meeting should have an agenda. There are several specific items that should be covered during this meeting:

• Introduce stakeholders to each other, as not all participants may be acquainted.
• Recap the information outlined in the project charter.
• This is an opportune time to emphasize the project’s organigram, which illustrates the structure of the new organization established by the charter. While people may be familiar with the existing functional organization and its reporting lines, they may not be acquainted with the roles defined for this specific project, including the responsibilities of the sponsor, project manager, team members, customer, PMO, and any additional roles created for the project, such as a steering committee, change control board, or quality assurance instance.

It is important for as many project team members as possible to attend the kickoff meeting. Any uncertainties regarding individual roles or organizational aspects should be discussed and clarified at this time.

Additionally, the general approach of the project should be reviewed, and if available, the high-level milestone schedule should be discussed. This provides participants with an understanding of how the project will unfold, and it ensures that everyone comprehends their short-term tasks in support of the project.

The kickoff meeting should confirm that the project is now in progress. It should also provide an opportunity for attendees to ask any remaining questions or express concerns as the project begins. The purpose of the discussion is not to reiterate the project’s purpose but to address specific queries or issues raised by the participants.

Other considerations for the kickoff meeting include:

• Attendees: Generally, the project team, sponsor, and other key stakeholders should be present. If the number of attendees becomes overwhelming, it may be necessary to have only the major players attend. In such cases, subsequent mini-kickoff meetings can be held for others or the relevant meeting information can be shared with those unable to attend.
• Duration: While most kickoff meetings can be completed within an hour or two, complex or controversial projects may require a longer timeframe, which is a worthwhile investment of time.
• Preparation: The kickoff meeting serves as the first impression for the project, and it is essential to make a good one. The meeting should be well-organized, efficient, and productive. The project manager should prepare for the meeting carefully and ensure its smooth execution. As part of the preparation, the project manager should also collaborate with the sponsor to establish agreement on how the meeting will proceed.

With a clear understanding of the project charter, an engaged sponsor, an appointed project manager, and aligned roles and expectations, the transition from the initialization stage to the planning stage is progressing well.

2.1 Planning a project – Overview

This section provides an overview of what goes into a project management plan.

Planning is an essential part of any work, even if it’s just mental planning without writing anything down. The same principle applies when work is organized as a project.

A project management plan is a comprehensive compilation of subsidiary plans that should be aligned with each other. Planning a project is not a solo endeavor; it involves the project manager, a core team, and subject matter experts who possess detailed knowledge of what needs to be done to create the specific product the project aims to deliver.

The project management team begins by gathering requirements from key stakeholders regarding project management and reviewing the constraints and assumptions collected during project initialization to check for any changes. This is the time to define SMART objectives that lead to the project goal established in the charter.

The team must determine the development lifecycle to be used for creating the solution, including the phases and/or iterations to be pursued. Special attention should be given to the development of the project baseline, which encompasses the approved project scope, budget, and schedule. This defines what the project will deliver, when, and at what cost.

Furthermore, plans need to be developed for managing various aspects of the project. The quantity and level of detail of these plans depend on the project’s size, complexity, and the project management methodology employed by the organization. For a large project, plans may be developed for scope management, requirements management, schedule management, cost management, quality management, communications management, resource management, risk management, procurement management, and stakeholder engagement.

During the planning stage, the team identifies risks, analyzes their criticality, and develops strategies to address them. Once all these elements are well integrated and balanced, approval from the governing body, usually the project sponsor or customer (if they are not the same person), should be obtained.

Finally, the project manager informs stakeholders about the approved project management plan, and a second kickoff meeting can be conducted to brief everyone on the final plan and transition from the planning phase to the execution phase.

It’s important to note that the completed project plan is not simply shelved and forgotten. It is utilized throughout the project’s lifecycle to guide the work, monitor project progress, make course corrections, and communicate with stakeholders.

In the subsequent sections, we will delve into each component of a project plan in detail.

 

 

2.2 Requirements for Project Management, Assumptions, and Constraints

This chapter aims to explain the requirements for managing the project, as well as revisit the section on assumptions and constraints.

Requirements refer to conditions requested by stakeholders for a specific item to fulfil their needs. During the initialization stage, the project definition work primarily focused on capturing “business requirements.” These requirements represent the capabilities that the business seeks to acquire and expects the project to deliver.

A significant part of the planning stage revolves around defining functional requirements for the solution being developed, along with its quality attributes. More details about these requirements can be found in the section on developing the scope baseline.

In this section, we discuss the characteristics of project management that are required or expected by stakeholders. For instance, we explore how the sponsor or customer wants the project to be managed, the project team’s expectations, and whether there is a Project Management Office (PMO) or a specific project management method within the organization that needs to be followed. We also consider which aspects of the project should be planned and which should be managed in an ad-hoc manner. Gathering requirements from stakeholders regarding project management helps us understand these aspects.

Here are some areas that may result in requirements for project management: scope, resources, schedule, cost, risk, issues, quality, communications, change, reporting, information and document management, and procurement.

Let’s consider some examples:

• Human resources: Are there any project management requirements and attributes to consider when managing the team, such as factors related to origin, gender, or culture?
• Planning effort: How progressive and iterative, or how predictive, should the planning effort be? While some stakeholders may prefer a purely agile approach, others, like the finance department, may request a more predictive approach. Managing scope, schedule, and other areas of project management depends on the overall approach being predictive or progressive and iterative.
• Procurement: Does the project involve a procurement department that has a say in how project procurements are managed?

If the organization utilizes a standard project management method, things might be clearer, but even then, customization of the company method may be necessary. The less documented the project management guidance, the more crucial it is to elicit requirements for managing the project effectively.

The results of this elicitation process provide the project manager with necessary inputs to create plans for managing different aspects of the project.

Now, let’s briefly revisit assumptions and constraints. These were captured during project initialization. However, depending on the time that has passed and the differences in stakeholders between initialization and planning (our current stage), it may be necessary to revisit the “Assumptions Log” and the list of constraints.

Assumptions are statements believed to be true about necessary elements, events that we assume will occur, or potential risks that we assume will not happen. The rounds of eliciting project management requirements present a suitable opportunity to update these statements. It’s possible to discover that some items previously classified as assumptions are, in reality, risks and should be moved from the assumptions log to the risk log for further analysis.

Regarding constraints, remember that they are limitations beyond the control of the project team that need to be managed. Initial constraints were identified during project initialization, but it’s time to update them. Some constraints may no longer exist, while new constraints may become apparent. As we define the product and plan the project in detail, it may become evident that certain milestones must be achieved by specific dates or that particular technologies must be used or avoided. These are all constraints that need to be captured.

For more details about risks, assumptions, and constraints, please refer back to the corresponding section in the “Initializing a Project” phase.

In summary, eliciting requirements for project management is a crucial input for planning how the project should be managed, thereby contributing to the project’s overall success. Assumptions and constraints should be captured and regularly updated throughout the entire project lifecycle. As we transition from project initialization to planning, it is an ideal time to review and revise them.

2.3 Defining SMART objectives leading to the goal

This section provides an explanation of SMART objectives.

A goal serves as an excellent means to unite stakeholders and align everyone toward a common direction. It represents a broad statement focusing on the desired outcome, without delving into the specific ways to achieve it. This is why, during project initialization, it is often preferable to remain at the goal level.

Some individuals use the terms “goals” and “objectives” interchangeably. Various goal methodologies differentiate between two levels of goals, such as upper-goals and under-goals, or higher-goals and operational goals. Others employ the pair “Goals and KPIs” to decompose the overall goal and ensure measurable compliance.

Our preferred terminology is “goals and objectives,” where the goal represents the overarching statement, and the objectives denote more detailed and specific statements. Accordingly, goals are general statements that define what is to be accomplished, while objectives encompass the bundled actions leading to the achievement of the goal.

To illustrate, let’s consider our example of developing an online system to increase transparency. The desired outcome or goal is enhanced transparency. To attain this goal, we decided to create a key deliverable, namely an online system that tracks and displays the status of transactions.

When performing initialization activities, we needed to verify the alignment between the goal and the key deliverable. We asked ourselves: If we were to use an online system that shows the status of all transactions, would we achieve the desired level of transparency? And our answer was a resounding “yes.” If not, we would have had to revise either the goal or the key deliverable until the answer became affirmative.

When we initialized the project, we chose the option of an online system after comparing it with other available means of achieving transparency. Do you recall the other options we considered? They were an overnight patch system and increased administrative personnel, which we evaluated and ultimately discarded for this particular example.

Now, let’s descend to a more detailed level for both the goal and its corresponding key deliverable. For the goal, we define bundled actions that lead to its achievement, and these actions result in “intermediate deliverables” as well.

Continuing with our previous example, what would these bundled actions leading to the goal entail? Some possible objectives could include:

• Explicitly defining the workflows of all products, including the stages involving suppliers, by xx date.
• Establishing a database or integrating existing databases to track the statuses of all products in different stages of the defined workflows by xx date.
• Implementing an online application, either through an existing software package or a custom-made solution, by xx date.
• Conducting training sessions for the organization’s personnel and suppliers’ staff to use the solution effectively by xx date.

The intermediate deliverables resulting from these specific objectives include workflows for all products, a consolidated database, an online application, and training sessions.

We must also remember that objectives need to be SMART. Let’s assess them accordingly.

Firstly, they are all time-based (as indicated by “xx date” in this example). Secondly, they appear to be realistic and achievable. Realism and achievability depend greatly on the capabilities of the specific organization and the available resources. For instance, sending a person to the moon and safely returning them was achievable for NASA but not for other organizations. Similarly, making all written knowledge in the world accessible to everyone might be achievable for Google but not for other organizations. Obtaining a project management certification is achievable for you, but it may not be for everyone. Objectives should be challenging enough to motivate the team, yet attainable. Setting unachievable objectives can be demotivating.

Now, let’s evaluate how specific and measurable these objectives are. This is where defining key performance indicators (KPIs) can be helpful.

For example, the objective of “training the organization and suppliers” could be made more specific and measurable by formulating it as follows: “Train the organization’s personnel as well as suppliers’ staff to use the solution by xx date, as measured by a capability test with a minimum score of x%.” The other objectives seem sufficiently specific as they are currently formulated in this example. Defining KPIs for the online system, databases, and workflows will be part of establishing functional requirements and quality attributes for the solution.

To summarize, during the planning phase, we must transform the overall project goal into actionable objectives. These objectives should be Specific, Measurable, Achievable, Realistic, and Time-based (SMART).

 

 

 

 

2.4 Defining the development lifecycle to create the solution: phases, iterations

This section explains the major types of development lifecycles used to create a solution resulting from a project: predictive, iterative, incremental, and agile lifecycles or approaches. The project life cycle refers to the set of phases or iterations into which a project is organized. Depending on the organization and the type of product to be developed, various types of project life cycles can be defined:

• Predictive life cycles define the requirements for the product and the scope to be delivered as part of the project planning. Changes are exceptions to the plan.
• Iterative and incremental life cycles gradually improve or expand the product, allowing for a gradual definition of requirements.
  • An iterative approach gradually improves the entire scope, gathering feedback before continuing to the next iteration.
  • An incremental approach adds functionalities one by one, finishing each one at each iteration.
• Agile life cycles are both iterative and incremental at the same time.

Let’s illustrate this with an example:

Predictive

Assume a project is initiated to fill a pothole. If we know the exact dimensions of the pothole and can establish the requirements, the work becomes predictable. It follows a sequence of steps, such as designing and preparing the mold, putting the concrete material, finishing the block, and filling the pothole. This is called the waterfall approach or predictive approach. It works best when all requirements are known and clearly understood from the beginning.

Iterative solution

In the same example, if we don’t know the dimensions of the pothole, we can take an iterative approach. We start by chiseling out the shape to fill the gap, refining it through carving and cutting until it fits perfectly into the pothole. We iterate on the shape until the carved block aligns with the pothole. Even without knowing the dimensions or requirements initially, we can fill the gap through multiple iterations. This is known as the iterative approach.

Incremental solution

Another way to solve the problem is through an incremental approach. We create a square block and deliver it to the customer, who places it in the pothole and provides feedback on the remaining unfilled parts. Based on the feedback, we create more incremental blocks and continue filling the pothole. This approach allows the customer to receive value early on and provide continuous feedback throughout the project. Even without knowing the dimensions initially, we can fill the gap using an incremental approach.

Agile way

When facing a complex problem with unknown or unclear requirements, we can use the agile approach. In this scenario, smaller bricks are delivered to the customer, and based on their feedback, we adjust the size and shape of the bricks. The customer determines the priority of reworking already delivered bricks versus adding new ones. This approach combines both incremental and iterative elements, providing flexibility in the face of unknowns and changing requirements.

To summarize, we have discussed the predictive approach, the iterative approach, the incremental approach, and the agile approach. These different lifecycles can be applied to develop solutions based on the specific project requirements.

Online system example

Now, let’s apply these insights to the example of developing an online solution to increase transparency in transactions.

Predictive life cycle (also known as “waterfall” or “cascade”):

When all requirements are known and understood at the beginning, we can follow a predictive approach. The project progresses through sequential phases, leading to the delivery of a complete online solution at the end.

Iterative life cycle

When requirements are not known initially, the iterative approach comes into play. We start by creating a basic design and drafts of desired functionalities for the entire online solution. Through subsequent iterations, we refine and chisel out the online solution until the final product is ready. The iterative approach allows for simultaneous work on multiple processes and ensures integration and coherence among different aspects of the solution, such as logistics management and accounting system functionalities.

Incremental life cycle

Using the incremental approach, we deliver a functional online system with limited but fully working capabilities. For example, we might implement full visibility of statuses for one product or product line with similar characteristics, allowing the customer to start using it earlier. We then add new functionalities to other products or product lines in subsequent increments. Each increment adds more features and expands the coverage. The final product is delivered through multiple increments.

Agile approach

In an agile lifecycle, we combine both iterative and incremental elements. We deliver a functional online system with limited but fully working capabilities as the first increment, allowing the customer to start using it. We then continue adding new functionalities or additional products in subsequent increments based on customer feedback and evolving requirements. The customer has the flexibility to decide whether to continue with new functionalities or refine existing ones. The process of iterations and increments continues until the final product is ready. The agile approach accommodates upfront unknowns and changing requirements, allowing for greater adaptability.

It’s important to note that not all products are suitable for incremental approaches, especially those involving physical items or large-scale production. The choice of lifecycle depends on the specific project requirements and constraints.

In summary, we have explored the predictive approach, iterative approach, incremental approach, and agile approach. This graphical representation will help you remember the different types of lifecycles available for developing your solution.

 

 

 

 

2.5 Develop the project baseline – Overview

This is an overview of the following sections, which will explain in detail how to create a project baseline.

All projects are governed by strict rules such as scope, deadlines, and budget. These elements form the project baseline, which is essential for establishing a clear project plan. Without a project baseline, you have an endless and uncertain journey.

The project baseline serves as a cornerstone of your project plan. Once established, it allows you to determine if you are delivering what is expected within the designated timeframe and budget.

The project baseline typically consists of three interconnected elements:

• The scope baseline.
• The schedule baseline.
• The cost baseline.

These three elements are interrelated and often referred to as the triple constraint. When one element is affected, it inevitably impacts at least one or both of the others.

• Expanding the scope of delivery without considering the impact on time and cost can be challenging.
• Reducing the available time may limit the scope that can be delivered within the shortened timeframe, and the acceleration of work may also affect costs.
• Similarly, reducing the budget will likely impact the scope or quality of the deliverables. It may also prolong the project duration if the reduced budget is spread over an extended period.

By integrating all three elements effectively, you gain better oversight of the project’s core aspects in an integrated manner.

In the upcoming sections, we will provide a detailed explanation of how to build an integrated project baseline. This will include defining the scope of delivery (what is envisioned to be delivered), establishing the expected timeframe for completion, and estimating the associated costs.

 

 

2.5.1 Functional requirements and quality attributes for the solution

This section deals with functional requirements and quality attributes for the solution.

In previous sections, we have covered other types of requirements, such as business requirements during initialization and project management requirements at the beginning of the planning stage. Now, as we continue the planning stage, our focus shifts to defining the functional requirements and quality attributes for the solution the project aims to create.

Let’s start by revisiting what requirements are: they are characteristics and conditions requested by stakeholders to satisfy their needs regarding a particular item.

Creating a comprehensive list of requirements for the solution is a challenging task and forms an essential part of the business analyst’s profession. There are several challenges involved in dealing with requirements:

• Firstly, ensuring the reliability and completeness of the initial requirement list, especially considering that some requirements may be discovered later after the project baseline has been established.
• Secondly, recognizing that not all requirements carry the same level of importance, as some may be essential while others could be optional.
• Thirdly, since stakeholders have different interests and needs, their requests may be multiple and potentially contradictory. Part of the project management work involves reaching a common ground and achieving an acceptable level of collective agreement on the solution’s characteristics.
• Fourthly, ensuring effective implementation of the wish list and avoiding the discovery of forgotten requirements when it is too late.

The process of distilling the functional requirements and quality attributes for the solution is often iterative. It begins with high-level requirements and progressively refines them into more detailed specifications. A high-level definition should provide enough information to create a scope statement, work breakdown structure, and estimates for effort, costs, and durations. Changes to the baseline are handled through a change management process or through versioning of the solution, particularly if an incremental approach is possible for the type of product.

The technical term for gathering requirements from stakeholders is called “elicitation.” According to Wikipedia, elicitation is the process of obtaining information from people. To elicit accurate requirements, team members playing the role of a business analyst must ask the right questions, listen carefully, and document the answers.

Eliciting requirements

Eliciting requirements through interviews is a commonly used technique, but there are other methods available as well. For example, when dealing with a large number of end users, it may not be feasible to interview each one individually. In such cases, conducting interviews with a representative sample and supplementing it with an online survey for others can be a preferred approach.

The following are some of the most common techniques used for requirements elicitation: In addition to one-on-one interviews, group interviews can be conducted, and professional group facilitators can provide valuable assistance. Sometimes, group work evolves into a Joint Application Development (JAD) session, which is a facilitated group session that concludes only when a comprehensive set of requirements is documented and approved by the group.

Questionnaires are also an effective means of gathering requirements from remote stakeholders who have minimal input or involvement.

Prototyping is a relatively modern technique that aligns with Agile principles for requirements gathering. In this approach, the team elicits initial requirements and uses them to create a prototype of the solution. The prototype is then shared with the customer, who provides additional requirements based on this tangible representation. The team continues this iterative and incremental process, as explained in the section on iterative and incremental lifecycles, until a sufficient number of requirements are fulfilled or for a predetermined number of iterations.

Observing people is a helpful technique when the team is gathering information about a process in use and needs to gain an understanding of how the process can be improved.

Traceability is another crucial aspect, referring to the ability to track requirements throughout the development lifecycle of a larger solution. In an incremental lifecycle, complete cycles of requirements, design, production, and testing are performed for each smaller increment, minimizing the risk of forgetting any requirement within the limited scope of each increment. However, in a more predictive approach with an upfront requirements phase followed by design, development, testing, and implementation phases, it is important to ensure that no requirements are overlooked.

To achieve this, a traceability matrix can be used to demonstrate that each requirement has corresponding design elements, and that those elements are indeed produced, tested, and implemented. This matrix also ensures that no functions are designed and built if they are not part of the agreed-upon requirements. An example of how a traceability matrix could look like is provided.

Note that the matrix should also identify the sources of the requirements.

Requirement	Source	Design Components	Build Components	Test Components
R-001	Sales Group xx	Dxx1-R001	Bxx1-R001	Txx1-R001
R-002	Finance Group xy	Dxy1-R002	Bxy1-R002	Txy1-R002 Txy2-R002
R-003	Sponsor	Dxz1-R003 Dzz1-R003	Bxz1-R003 Bzz1-R003	Txz1-R003

Fortunately, there are specialized software packages specifically designed for tracking requirements.

Selection/Prioritization of Requirements:

The MoSCoW method is an effective prioritization technique. MoSCoW stands for Must have, Should have, Could have, and Won’t have, with each category representing a different level of priority.

• Must-have requirements are critical for the success of the solution or iteration. If any Must-have requirement is not included, the delivery is considered a failure. Must-have requirements can be downgraded by agreement with relevant stakeholders, particularly when new requirements are deemed more important.
• Should-have requirements are important but not essential for the delivery or the current timebox.

In our previous example, we used the MOSCOW technique to define project success criteria as “100% of all Must-Have requirements and 80% of all Should-Have requirements” without knowing the specific requirements that would fall into each category.

• Could-have requirements are desirable but not essential. They can enhance the user experience with a minimal development cost. If time and resources permit, these requirements are typically included.
• Won’t-have or Won’t-have-this-time requirements have been agreed upon by stakeholders as the least critical or lowest-payback items, or they may not be suitable for the current development cycle. These requirements are either dropped or considered for inclusion in a future timebox.

A final point regarding functional requirements and quality attributes (also known as non-functional requirements).

Functional requirements refer to the actions or processes that a system should perform.

Quality attributes (non-functional requirements) refer to how a system should be or the constraints for its functions.

Examples

Functional requirements	Quality attributes (non-functional requirements)
The user SHALL be able to log in through a web interface.	The system MUST respond to log in requests within 1 second (performance)
The system should present the user all past and current transactions	The status of current transactions must be updated within 10 ms. (performance)
When a customer registers to the system, the system should send an email	The email to new registered users must be sent 2 seconds after registration (performance)
	The system must run on Android, Windows and IOS (operational) The system should connect with printers wirelessly (operational)
	Only sales manager can approve customer’s offers (security)

In summary, the list of functional requirements (what the system should do) and quality attributes (how the system should be) should be agreed upon by relevant stakeholders using a prioritization method such as the MoSCoW method. Various techniques are available for eliciting requirements, and the reliability of the upfront gathered requirements can influence the need for a less predictive and more iterative or incremental approach for the entire project. It is crucial to ensure that the elicited requirements are effectively implemented.

 

 

 

 

2.5.2 Scope statement

This section focuses on the scope statement.

A scope statement is a detailed description of the product and the project, including the necessary work to create the product. It serves as one of the key components of the project management plan. The scope statement answers the question: what will be done, and it enables further planning of costs, effort, and time associated with the defined scope.

At this stage, you have already identified important elements needed to create a scope statement. One source of information is the project charter, which gathered inputs from the initialization stage. The updates made to assumptions and constraints during the planning stage also provide valuable information. Additionally, you will utilize the requirements documentation created earlier to determine which requirements will be implemented and clearly define what is “in scope” and what is “out of scope.” Anything out of scope will not be pursued.

If you are using a predictive approach, the scope statement can be detailed. In contrast, if you are utilizing an iterative life cycle, the scope statement will likely represent a high-level vision of the overall project and provide a detailed scope for the next iteration only.

The following elements should be included in a scope statement:

• A detailed description of the product the project will create, including major deliverables and their respective acceptance criteria.
• Exclusions, explicitly stating what is out of scope to manage stakeholder expectations and avoid misunderstandings.
• Updated assumptions and constraints: Incorporating the revised assumptions and constraints from the planning stage, along with any additional management requirements.
• A description of the work required to accomplish the defined product.

Example of a scope statement

Product Scope

Description

The project involves developing a web system with dedicated hosting capable of handling xxx users simultaneously. The system will provide real-time information on the status of transactions based on a status scheme created by the “Status Definition” project. Each customer and order will be assigned unique identifiers, and customers can recover their IDs using their email addresses. End users will be able to place orders, track transaction statuses (including payment and delivery), and access details of past transactions. The project will initially focus on implementing the online solution for a specific product line, which will be determined during the analysis phase at the beginning of execution. Other product lines will be addressed in subsequent projects. The first release of the online system will support German and English languages only.

Major Deliverables

• Interface with the upgraded finance system to be released by the “Project Finance System”
• Upgrades to the customer relationship management (CRM) system and sales system
• Integration with the order management system of suppliers within the scope
• Automation of manual logistics handling processes
• Integration tasks
• Creation of a new home page for customers
• Development of performance reports

Acceptance Criteria

• 100% completion of all Must-Have Requirements for the product and each component
• 80% completion of all Should-Have Requirements for the product and each component

Exclusions

• Marketing campaign targeted at end users
• Other products or product lines, except for those selected during the analysis phase at the beginning of project execution
• Languages other than German and English

 

Project Scope (Work Needed)

• Analysis, design, and implementation of interfaces with the finance, CRM, and sales systems
• Analysis of the CRM and sales systems to determine whether an upgrade of the current systems or the implementation of new systems is preferable
• Implementation of either an upgrade to the CRM and sales systems or migration to new CRM and sales systems, including data conversion and migration
• Definition of selection criteria for a logistics system, selection of a logistics management package, customization, and deployment
• Analysis of products and product lines to select the ones within the project’s scope
• Analysis of suppliers to determine which ones fall within the project’s scope
• Integration with the selected suppliers’ systems for the selected product line
• Creation of a new customer homepage
• Definition and creation of performance reports

Assumptions

• Strong and supportive sponsorship by XZ direction will be granted
• Strong and supportive collaboration with Finance, Sales, and Suppliers will be granted, with subject matter experts from these areas available as per the approved schedule baseline
• Supportive collaboration with selected suppliers will be granted, and subject matter experts from their side will be available as per the approved schedule baseline
• The “Finance System” and “Status Definition” projects will deliver their results on time as defined in the approved schedule baseline of this project

Constraints

• The online system must be compatible with iOS, Android, and Windows platforms
• The logistics system’s external costs, in terms of money outflows, should not exceed xx Euros.
• IT-Consulting XX will be used as the consulting provider

In summary, the scope statement includes both the product scope, which describes the capabilities of the product, and the project scope, which outlines the work required to deliver that product. It establishes clear project boundaries by stating what is out of scope and documents the current assumptions and constraints.

 

 

2.5.3 Work Breakdown Structure-WBS

This section provides an explanation of what a work breakdown structure (WBS) is and provides guidance on how to create one.

A Work Breakdown Structure (WBS), also known as hierarchical decomposition, breaks down the work to be executed by the project team into smaller, manageable components. It is an essential project management document that helps in organizing and understanding the project’s scope.

There are two types of WBS: Deliverable-Based and Phase-Based. The most common approach is the Deliverable-Based method, which focuses on identifying the deliverables. The main difference between the two approaches lies in the elements identified at the first level of the WBS.

Here is an example of a Deliverable-Based WBS where the Level 1 elements provide summary descriptions of deliverables, and the Level 2 elements represent the specific deliverables required to create the corresponding Level 1 summary deliverable.

In contrast, a Phase-Based WBS organizes the work based on project phases. The Level 1 elements represent the phases, and the Level 2 elements are the deliverables associated with each phase.

A well-constructed WBS is one that makes the project more manageable. Since every project and project manager are unique, each WBS will vary. Therefore, the right WBS is the one that effectively captures all the work to be done.

Building a WBS is a collaborative process that involves starting with the top-level summary deliverables and progressively breaking them down. It is not solely the responsibility of the project manager but a team effort that leverages the subject matter expertise of team members who possess the knowledge specific to each deliverable. This approach minimizes the chances of overlooking important work and increases team buy-in.

As a team, you identify the top-level summary deliverables and then assign smaller groups to further break down these deliverables. Finally, the entire team comes together to review and address any issues. If the entire team is not yet assembled, you can begin by working with the initial team to brainstorm an initial WBS, and later, as more team members join, you can revise and add more detail.

To start building the WBS, refer to the scope statement and the deliverables outlined in the project documentation to identify the top-level summary deliverables. Then, continue breaking down each summary deliverable into smaller components.

For instance, let’s consider the example of the summary deliverable “Logistics,” which currently does not have an existing system and needs to be created from scratch. Based on input from subject matter experts, the decomposition might involve obtaining a vendor and following the vendor’s proposed life cycle. Additionally, the purchase department suggests adopting their standard process for new vendors.

Level of detail of the WBS

It is generally recommended to aim for work packages that require between 40 and 80 hours of effort to complete. The level of detail in the decomposition should align with your ability and desire to manage it. Different parts of the project may require varying levels of decomposition, and the initial organization of the WBS can be adjusted as more information becomes available.

WBS and Agile

It’s worth addressing a misconception about the WBS and agile lifecycles. Some believe that a WBS is unnecessary in agile projects since the scope is not fully known. However, even in agile projects, there is a product vision, and the backlog, which represents all the work to be done including requirements, can serve as an implicit WBS. As items in the backlog are prioritized and developed, they are further decomposed. This is similar to the rolling wave planning in traditional project management, where a more granular decomposition of deliverables occurs as the project progresses.

To summarize, the creation of a Work Breakdown Structure involves:

• Decomposing the entire work into phases or deliverables, or a combination of both.
• The important aspect is to ensure all the work is identified.
• Different levels of decomposition can be used, and more detail can be added as the project progresses and more information becomes available.
• The lowest level of the WBS consists of work packages that can be delegated to a specific team under the guidance of a work package leader.

 

 

 

 

2.5.4 Work packages

This section focuses on work packages and the associated responsibilities.

Let’s begin with some definitions:

• According to the methodology of the British Government, Prince2, a work package is “a set of information about one or more required products. This information is collated by the project manager to formally pass responsibility for work or delivery to a team manager or team member.”
• The standard ISO 21502 defines a work package as “a group of activities that have a defined scope, deliverable, timescale, and cost.”
• The Project Management Institute, in the PMBOK Guide v6, defines a work package as “the work defined at the lowest level of the work breakdown structure for which cost and duration are estimated and managed.”

So, what elements should be included in this set of information? The definition of work packages shares similarities with defining a project. What may be a work package for the requesting organization could be a project for a sub-team or sub-contractor. The work package should clearly define and be agreed upon by the project manager and the work package leader regarding the scope of work, delivery dates, and costs. It should also address how various aspects will be managed, such as communication, reporting, issues, and changes.

Here is a sample template for the definition of work to be completed within a work package.

Please pause the video to review the provided work package definition template.

Work Package Definition
Project Name:					Account Nr:
Work Package Name:					Work Package ID:
Work Package Leader:					Work Package Team Members:
Product: Description of work:
Assumptions:					Constraints:
Milestones:					Due dates: Progress reporting:
Acceptance criteria
Completeness criteria: the work package is complete if it contains the following elements:					Correctness criteria: the work package is correct if it fulfills the following criteria:
ID	Activity	Resource	Labor			Material			Total
			Hrs.	Rate	Total	Units	Cost	Total
Totals

Using the example of our online solution to track transactions, let’s assume that the task of obtaining a vendor is delegated as a work package to a project team member in the functional procurement department. The work package definition would appear as follows.

Please pause the video to review the provided example of a Work Package Definition.

Work Package Definition
Project Name: Online Solution to Track Transactions					Account Nr: 3.2
Work Package Name: Obtain vendor					Work Package ID: 3.2.1
Work Package Leader: John Purchase					Work Package Team Members: (t.b.d. by John Purchase) a)  Mary Pur b)  John Chase
Product: selected vendor for the online solution to track transactions Description of work: run vendor selection process VSP 10.2021
Assumptions: 1)  The project team provides functional requirements and quality attributes in time for the vendor to define technical specifications as defined in constraints.					Constraints: 1)  Vendor must have passed the “vendor qualification process xx » 2)  Technical specifications of the vendor must be available before date xx
Milestones: 1)   Short list by date xx -30 days 2)   Contract signed by date yy					Due dates: Technical specifications to be used for the selection and should be available before date xx. Progress Reporting: weekly status report and biweekly status meeting
Acceptance criteria
Completeness criteria: the work package is complete if it contains the following elements: ·    Multicriteria selection matrix ·    Recommendation about a vendor ·    Rationale					Correctness criteria: the work package is correct if it fulfills the following criteria: ·    At least 3 weighted selection criteria agreed with project manager ·    At least 3 potential vendors
ID	Activity	Resource	Labor			Material			Total
			Hrs.	Rate	Total	Units	Cost	Total
3.2.1.1	Define selection criteria	Mary Pur PM	10	100	1000				1000
3.2.1.2	Contact potential vendors	John Chase	5	100	500				500
3.2.1.3	Obtain proposals	John Chase	20	100	1000				1000
3.2.1.4	Select vendor	John Purchase Project Manager	10	150	1500				1500
Totals			45		4000				4000

Note that the work package is the result of decomposing a deliverable and is further broken down into the activities necessary to create or build that specific work package.

Depending on the work package, it also follows a lifecycle. For example, the purchase department has a standard lifecycle or process in place to generate a vendor, which will be reused. However, if the product associated with the work package doesn’t have a predefined lifecycle, the work package leader will need to collaborate with the team to brainstorm and determine the necessary activities. This is a similar process to what was described in the previous section for generating the first level of the WBS.

The detailed definition of work packages is typically not done for all work packages at the beginning of the project. It is more common to define in detail only those work packages that will be created in the next stage. This is known as rolling wave planning. Similarly, in Agile teams, they refine the backlog by prioritizing and decomposing requirements (referred to as “user stories” in Agile) waiting in the backlog. Eventually, even an Agile team reaches the level of executable activities.

The Work Package Leader

A work package leader, also known as a team leader, is responsible for leading, managing, and delivering the assigned outputs or outcomes as defined in a work package. The work package leader may belong to the same company as the project manager or another company, such as a subcontractor, which is common in many projects.

The responsibilities of the work package leader mirror those of the project manager for the entire project and include:

• Leading the work package team to complete and deliver the product with the required quality, on schedule, and within budget.
• Planning, controlling, and reporting on work progress to the project manager.
• Managing risks and issues, including escalation when necessary.
• Controlling changes to the work scope and requesting approval for changes outside their authority.

In smaller projects, the project manager may assume the role of the work package leader and directly oversee a sub-team of technicians responsible for producing different parts of the solution.

However, the project manager cannot simply delegate work packages and expect them to run on automatic pilot. The responsibilities of the project manager in relation to work packages are an essential part of project management and include:

• Initiating work packages in accordance with the project plan or in response to risks or issues.
• Assigning responsibility for each work package to a work package leader.
• Verifying and approving the plan for each work package, ensuring it is consistent and integrated with the overall project plan and respective phase.
• Ensuring that integration work and deliverables between work packages are planned and executed to meet the requirements.
• Monitoring progress of the work, addressing risks, issues, or change requests.
• Verifying the quality of the deliverables.
• Confirming completion and closure of each work package.

In cases where the project manager and work package leader belong to different organizations, particularly different companies, things can become more complicated. Some subcontractors prefer to keep everything secret until the final delivery date, but this approach often leads to unpleasant surprises. It is the responsibility of the project manager to set expectations and establish agreed-upon rules. The best time to do this is during the negotiation of work package assignments.

In summary, in smaller projects, the project manager may assume the dual role of project manager and work package manager, directly overseeing the technical work to create deliverables. In more complex projects, it is common to delegate work to various sub-teams under the guidance of work package leaders who report to the project manager. Defining, delegating, verifying, assuring integration, and accepting work packages are essential responsibilities of the project manager.

 

 

 

 

2.5.5 Scope baseline

This section provides a summary of the work done to create the “scope baseline.”

A “baseline” refers to the approved version of a work product that can only be changed through formal change control procedures. It serves as a reference point for comparing actual results. The “scope baseline” consists of the scope statement and the WBS, including the work packages. It represents the approved version of these project management documents and can only be modified through formal change control procedures. Neither the project manager nor team members can alter the approved scope of work without following the formal process of change control.

Once you have the scope statement, WBS, and work packages, you have established the scope baseline, which defines “what” will be done in the project. It is important to remember that the scope baseline is one of the three core baselines. In addition to the scope baseline, we also define the “schedule baseline” (the approved version of the project schedule) and the “cost baseline” (the approved version of the budget).

If necessary, please review the sections on the scope statement, WBS, and work packages.

 

 

 

 

2.5.6 Estimate duration and costs

This section provides an explanation of techniques for estimating duration and cost, as well as guidance on selecting a reliable estimate.

The two questions you are often asked about a project are: “How much time will it take?” and “How much will it cost?” Estimating accurately is crucial because it determines the feasibility of the project and serves as a basis for measuring performance once the estimates are approved and incorporated into the project plan.

You begin by estimating time since it impacts both the project schedule and cost. Additionally, you estimate non-time-based costs such as materials and ancillary expenses like travel. During the initialization and planning phases, a core planning team can develop initial estimates. As the project progresses, more accurate estimates can be obtained from the individuals assigned to work packages and activities. They have a better understanding of the required tasks and can provide estimates based on their experience, while also being motivated to meet those estimates.

Estimates do not have to be perfect from the start. For project selection purposes, an estimate with a variance of plus or minus 75% might suffice. As you gather more information during the planning phase, your estimates become more precise, ideally within plus or minus 10%.

Various techniques can be used for estimating at the project, work package, or activity level. Top-down techniques, such as estimating by analogy or in proportion to past projects or work packages, are suitable for rough estimates. These techniques enable quicker estimation of entire projects or phases but with lower accuracy. Bottom-up techniques, on the other hand, involve estimating individual components of the Work Breakdown Structure (WBS) and summing up the results. While more time-consuming, this method provides greater accuracy and allows for adjustments to the plan based on precise estimates.

Combining top-down and bottom-up techniques can refine estimates by involving work package leaders and their expert teams to estimate at the work package level. It is beneficial to use multiple estimating techniques to validate the results and take an average of the estimates obtained. This can help address stakeholder doubts or questions about the validity of the estimates.

With parametric modeling, you can estimate work and cost by leveraging a known parameter and extrapolating it for a larger scale. For example, in construction, if one square meter costs €1,000, then 100 square meters would cost €100,000.

When it comes to estimating, having experts who are familiar with the work involved is beneficial. If you have experts within your project team, you can rely on their expertise. However, if not, you may need to seek input from consultants or vendors. Expert opinion is always a valuable estimating technique. You can consult with a single expert or gather estimates from multiple experts, employing the so-called Delphi technique.

Let’s consider an example related to our online tracking system aimed at increasing transaction transparency. If we take the implementation of the sales system as a reference point, which took 8 months and €1,000,000 to complete, we can use these figures as a rough top-down estimate for the tracking system. If we anticipate that the tracking system will be twice as complex due to involving suppliers, we could estimate 16 months and €2 million as a rough top-down estimate.

For estimating a work package using parametric modeling, let’s say that implementing one online report required 10 hours of work, 2 days, and cost €2,000. Extrapolating this, we can estimate that implementing 5 online reports would take 50 hours of work, 10 days, and cost €10,000.

The Delphi technique relies on the principle that several heads are better than one. In this technique, you ask multiple experts to independently provide estimates. Then, you share the results with the group while keeping the estimates anonymous. This anonymity ensures that no expert is influenced by the reputation or authority of another expert. After sharing the estimates, you ask everyone to estimate again. This process is repeated several times, and the average of the last round is used as the final estimated value.

The more unreliable your estimate is, the greater the need for contingencies. Adding a 10% reserve for contingencies indicates that you have 90% confidence in delivering within the estimated time and cost.

How to compose a good estimate

Estimates are similar to your morning commute, as you need to choose a duration that allows you to reach your destination on time. Some days your commute may be smooth, taking around 30 minutes, while most days it might take 45 minutes. However, unexpected incidents can extend the duration to an hour. To account for unforeseen circumstances, you select a drive time that provides some flexibility, ensuring you arrive at work on schedule.

We will explore a similar but systematic approach to selecting estimate values for project estimates. If we were to plot the probability of your commute times, it would resemble a Bell Curve, also known as a “normal distribution.” This distribution has certain characteristics that assist in choosing a reliable estimate for your customers. In a Bell Curve, 50% of the possible values are lower than the average, and 50% are higher. Therefore, the average value gives you a 50-50 chance of your actual results matching or being below your estimate.

However, relying solely on the average estimate presents equal chances of success and failure, which is not an ideal position. Conversely, the worst-case estimate provides the highest chance of success, but the number may be so high that it risks project cancellation. Customers often inquire about the best-case scenario, assuming everything goes perfectly. However, presenting the best-case estimate and describing an ideal outcome may lead to unrealistic expectations and project failure. Consequently, the best, worst, and most likely values are eliminated as reliable estimates.

So, what number should you use for your estimate? The answer lies approximately midway between the average and worst-case values. By choosing a value between these two points, you increase the probability of making an accurate estimate. Although not delving into the mathematical intricacies of the PERT-Analysis, a simple approach can yield a high probability of success. This value is easy to calculate, and you can adjust it higher to reduce the chance of missing the deadline, similar to leaving early for a job interview. When aiming to secure a project, you may add less reserve for contingencies, accepting more risk by using a smaller value.

In essence, the key is to select an estimate that provides an acceptable probability of success. Let’s consider an example from our case of the online tracking system, which aims to enhance transaction transparency. During discussions with various system vendors, you requested estimated durations and costs for implementing their tracking systems. Each vendor provided three values: one for a standard implementation, one for a typical customization, and one for extensive customization. Please refer to the table, which compares these three estimates. (Please pause the video to review the table.)

	Cost in €			Duration in months
Vendor	No Customization	Typical Cust.	Extensive Cust.	No Cust.	Typical Cust.	Extensive Cust.
Vendor 1	800.000	900.000	1.100.000	8	10	12
Vendor 2	600.000	750.000	1.000.000	8	11	13
Vendor 3	500.000	650.000	900.000	7	11	15
Average values for vendors 1   and 2		825.000	1.050.000		10,5	12,5
Estimate halfway between the average and worst-case values		937.500			11,5
Reserve for contingency of 15%		140.625			1,725
Estimate including 15% reserve for contingency		1.078.125			13,225
Estimate rounded up/down including reserve for contingency		1.000.000			13
Thereof reserve for contingency		62.500			1,5

Let’s assume that Vendor 3 lacks built-in functionality and customization, making it unlikely to meet the functional requirements. As a result, we will only consider the estimates from the two higher-end vendors in our calculations.

Here’s how you can proceed:

First, calculate the average duration and cost for a typical implementation from Vendor 1 and Vendor 2. The average duration is 10 and a half months, while the average cost is 825,000 €.

Next, calculate the average duration and cost for extensive customization from Vendor 1 and Vendor 2. The average duration is 12 and a half months, and the average cost is 1,050,000 €.

The next step is to calculate the duration halfway between the average typical and worst-case values. The resulting duration is 11 and a half months, and the cost is 937,500 €.

Finally, include a reserve for contingencies, such as 15%, and round the values accordingly. This results in an estimated duration of 13 months and a cost of 1,000,000 €, including a contingency reserve of 1.5 months and 62,500 €.

 

Now, let’s discuss Agile teams briefly.

Agile teams use similar estimation techniques but employ different terminology. For instance, they may classify requirements using relative size estimation with T-shirt sizes (extra small, small, medium, large, extra-large). The smallest group is assigned a value of 1, and subsequent groups follow the Fibonacci sequence (2, 3, 5, 8). If a requirement exceeds the extra-large size, it needs further decomposition. The estimation process is easier for smaller components compared to larger ones. For example, it may take one week to complete an extra-small element but eight weeks for the largest one.

Regardless of the approach, the project sponsor will likely want to know the estimated duration in traditional time measurement, using specific dates instead of Agile story point units.

In summary, it’s important to remember that estimates don’t have to be perfect from the start. You can begin with rough top-down estimates and refine them bottom-up as more information becomes available and experts weigh in. Accurate estimation is crucial as it can determine whether the project is feasible, and the estimates form the foundation for performance measurement once they become part of the project baseline. The duration estimates become the schedule baseline, and the cost estimates become the cost baseline.

 

 

 

 

2.5.7 Develop a project schedule

This section provides a six-step guide to creating a project schedule.

Step 1: Define activities

To start building a schedule, refer to the Work Breakdown Structure (WBS) where the team has already identified the work to be done, including the work packages. Work packages should be further decomposed into activities necessary for creating the specific deliverables within those work packages.

However, if the project is large or the project manager prefers managing work at the work package level, the decomposition of work packages into activities can be left to the discretion of work package leaders. In this case, the project schedule will show detail up to the work package level. On the other hand, if the project is smaller or the project manager prefers a more granular approach, the decomposition of work packages into activities can be reflected in the overall project schedule. The schedule management plan, which will be discussed in the section on subsidiary management plans, determines the level of detail used for developing the schedule.

The following explanations assume that the project schedule shows activities, but the same logic can be applied if the level of detail is maintained at the work package level.

Regardless of the approach chosen, it is essential to first identify the work to be done before scheduling it. This can be achieved through the WBS or a product backlog in Agile projects. Keep in mind that additional work may be identified as the project progresses. It’s important to emphasize that the more unknown the work is, the more reserves should be allocated to account for unidentified work.

The identification of activities for creating the deliverables described in a work package is best accomplished through teamwork involving subject matter experts in the respective field. Brainstorming sessions can be an effective way to gather their insights and determine the necessary sequence of activities to produce the desired deliverable.

For further guidance, refer to the section on defining work packages, which provides an example of decomposing a work package into activities using our online solution for tracking transactions as a case study.

Step 2: Sequence activities

Once you have decomposed the deliverables listed in the WBS and identified the necessary activities, the next step is to sequence these activities and establish dependencies between them in the project schedule.

The most common type of relationship is “finish-to-start,” which means that an activity must be completed before another activity can start. For example, you must finish building a wall before you can start painting it.

However, other relationship types exist, such as “start-to-start,” where the start of one activity is linked to the start of another, and “finish-to-finish,” where the completion of two activities is linked, not necessarily simultaneously, but with a connected conclusion. For instance, item A should finish two weeks before item B concludes.

Step 3: Estimate activity resources

In this step, you determine the number and types of resources required for the activities identified in the schedule. These resources can include human resources, as well as equipment and supplies needed to carry out the project work.

After completing the next step of calculating durations, you may revisit this step and allocate additional resources if the resulting duration is not feasible. It’s important to note that not all types of work necessarily shorten their duration with increased resource allocation.

Estimating activity resources is closely tied to cost estimation. For example, in a construction project, the team may need to be knowledgeable about local building codes. If the internal labor pool lacks experience in specific construction techniques, hiring a consultant might be the most effective way to ensure compliance with local codes. Similarly, an automotive design team might require expertise in the latest automated assembly techniques, which could be acquired by hiring a consultant, sending a designer to a robotics seminar, or including a manufacturing representative in the project team.

Step 4: Estimate activity durations

After assigning resources to the activities, the next step is to estimate the duration for each item in the schedule. Duration refers to the number of working periods required to complete the activity, and it can be expressed in days, weeks, or even months, depending on the project’s scale.

Effort-driven work is influenced by resource allocation. If you allocate more resources to a task, it will generally take less time to complete. For example, if you have one interviewer and 100 people to interview, it will take longer compared to allocating five interviewers.

On the other hand, non-effort-driven work has a fixed duration that does not change with additional resources. For instance, if an activity involves transporting an item on a vessel and it takes 20 days, assigning more people or resources won’t accelerate the transport time.

It’s important to consider that not all team members will be 100% available to the project, and no one is 100% productive even when working full time. Experienced project managers account for a productivity rate of around 70% in highly productive environments. This means that if a task is estimated to take 40 hours of effort, its duration would be 57 hours (40 divided by 0.7). This translates to 7 working days of 8 hours each. Taking into account factors like holidays, vacations, and possible disruptions, accounting for effective productivity provides a more realistic estimate.

Some studies on productivity have shown rates as low as 50% or even lower, depending on the working environment. If past projects have taken double the time originally estimated, it may indicate a lower effective productivity rate. It’s important to consider these factors to ensure realistic estimations and avoid unrealistic expectations.

Step 5: Model a schedule

Once all the work items are linked, resources are assigned, and durations are estimated, you can create the initial version of the project schedule.

The next step involves analyzing and modeling the schedule. You may identify situations where resources are allocated unevenly across different weeks, leading to under- or overallocation of workload. This imbalance needs to be addressed through resource leveling, which may involve adjusting activity durations, reallocating resources, or making other necessary changes.

Reviewing the draft schedule is crucial to ensure it aligns with the constraints identified and reviewed during the planning stage. If the schedule indicates completion in November, while a constraint specifies the project must end by the international fair in September, adjustments are required. This may involve exploring alternatives such as adding resources, considering overtime work, reviewing dependencies (are all dependencies truly “finish-to-start” or can some work be done in parallel?), or, as a last resort, removing some work defined in the WBS if the constraint outweighs the scope mandate.

Ultimately, the estimate of project duration should have an approximate 85% certainty level, allowing for a reserve of 15% for contingencies. Others may question the numbers, so it’s crucial to be able to defend and explain the estimations. If confidence in the estimate is lacking, more time should be dedicated to creating a reliable estimate.

Step 6: Establish milestones and gate reviews

Take a closer look at the draft schedule and identify the scheduled completion dates for key deliverables. Assign milestones to these events. A milestone is an activity with zero duration that serves to signify the completion of deliverables and is used for management purposes. By generating a summary report that only shows project milestones, which is typically the level of detail desired by project boards, you can easily determine whether you are on schedule, ahead of schedule, or behind schedule at a high-level milestone view without delving into the details of individual activities.

You can plan project reviews to coincide with major milestones. This practice, known as a “phase gate review,” will be further explained in the section on “Managing Phase Gates” as part of project control.

Save this version of the schedule as an advanced draft. As you proceed with risk analysis, communication planning, quality management planning, team building activities, and other project-related tasks, you will need to add additional items to the schedule before it becomes a fully integrated project management plan. This plan, developed step by step, will include the final version of the schedule and serve as the “schedule baseline.”

Lastly, it’s worth mentioning scheduling tools. For most projects, it is beneficial to utilize scheduling software to aid in the construction and management of the project schedule. Numerous tools are available, such as Microsoft Project, Oracle Primavera, Liquid Planner, Smartsheet, and more. Some individuals opt for using an Excel spreadsheet with macros. Research and explore different options to find a tool that suits your specific needs and fits within your budget.

Let us summarize the steps outlined for creating a schedule:

• Step 1: Define activities
• Step 2: Sequence activities
• Step 3: Estimate activity resources
• Step 4: Estimate activity durations
• Step 5: Model a schedule
• Step 6: Establish milestones and gate reviews

 

 

 

 

2.5.8 Develop a project budget

This section provides guidance on creating a project budget.

Project cost is one of the three critical constraints that must be managed, and the project budget serves as the starting point for cost control. The project budget should be a realistic estimate of the cost required to complete the project work. If the estimate is unrealistically high, the project may face the risk of cancellation. Conversely, if the estimate is too low, the project will exceed the budgeted cost and could prove to be a poor decision.

To begin, you can start with rough estimates for the initial levels of your work breakdown structure (WBS). As you gather more information about the project, you can refine your estimates to be more accurate. Similar to the project schedule, the WBS serves as the foundation for the budgeting process, including the work packages. The level of detail in the budget depends on the project manager’s preferred level of granularity for managing the project. Some work packages may be decomposed into activities under the supervision of a work package leader, such as a supplier. Thus, the budget may show activity-level details for certain work packages while others remain aggregated under the supervision of a work package leader.

The process of determining a budget involves consolidating the partial cost estimates into a unified budget. Additionally, it is crucial to define cost reserves to account for potential contingencies that may impact costs, similar to what was done for schedule contingencies.

Finally, it is important to determine the timing and allocation of the total budget. The entire budget amount, for example, $1,000,000, is not required on the first day of the project but is spread out over the project timeline. Therefore, it is essential to answer questions such as: When does the project require specific portions of the budget? This is why it is advisable to first develop the project schedule before creating the project budget.

The representation of cost estimates for various project activities, along with any contingency reserves, provides an overview of the cost breakdown. These activity cost estimates are then aggregated into the associated work package costs. Work package cost estimates, along with any contingency reserves, are further consolidated into control accounts. Some project managers oversee cost control for multiple work packages under a single control account, which represents their level of responsibility.

The sum of all control accounts forms the cost baseline. However, the final budget approval is not obtained at this stage, as additional costs may still be determined when defining project management plans and addressing risks, which are also part of the step-by-step project management plan development. Once all expected costs have been captured and appropriate contingencies have been established, a final version of the budget is obtained. When approved as part of an integrated project management plan, this budget becomes the cost baseline.

In some cases, a project budget may also include “Management Reserves,” which are outside the direct control of the project manager. In an ideal scenario, the organization’s management would allocate management reserves as a precautionary measure for potential future issues and changes that are unknown at the project’s outset. The project manager is responsible for managing the project within the defined cost baseline.

Since the cost estimates comprising the cost baseline are directly linked to the schedule activities, it allows for a time-phased perspective of the cost baseline. BAC, which stands for “Budget At Completion,” represents the total project budget.

This time-phased view of the project budget is important to prevent cash flow issues by ensuring that Project Governance provides the necessary funds according to the expected expense schedule. If needed, please review the section on estimating durations and costs to refresh your knowledge on various estimating techniques.

Now, let’s discuss different types of costs that can be associated with a project and how they can be grouped:

• Labor cost: This typically represents a significant portion of the project’s expenses and includes the payment for the people working on the project. If you hire vendors or contractors, their charges are directly accounted for in the project’s labor costs. For employees, you usually consider the burdened cost, which includes all personnel-related expenses, such as fringe benefits and a portion of fixed costs associated with the company. It’s important to consult your accounting or HR department to determine the appropriate rate for personnel within the organization working on the project.

Note that internal costs may or may not be accounted for, depending on the project. Some projects only include external costs, which result in an outflow of funds when invoices are paid. While this approach is easier to manage, it does not provide a complete picture of the project’s total cost, including the effort contributed by internal staff.

• Material cost: This refers to the expenses related to purchasing or renting items like computers, servers, networks, and other equipment required for the project. The cost management plan should specify how these purchases should be accounted for. Some projects allocate the entire purchase value to the project, while others consider depreciation rates, which adds complexity to the calculation. Additionally, there may be time-based resources, such as office space that needs to be rented specifically for the project.
• Other costs: This category includes expenses that do not fit into the labor or material cost categories. For example, it encompasses travel expenses, training costs, and various fees.

In summary, it is crucial to identify and estimate the labor, material, and other costs expected for the project, utilizing the estimating techniques discussed in a previous section. These cost estimates should be aggregated from activities to work packages, work packages to control accounts, and ultimately to the cost baseline. It’s essential to include reserves for contingencies at all levels, making them explicit. Finally, the organization’s management should incorporate a management reserve to address potential unknowns in the future.

 

 

2.6 Develop subsidiary management plans

This section provides an overview of subsidiary management plans, which are integral components of the overall project management plan.

Planning is an essential part of any work, even if it is only done mentally without much documentation. Determining the tools to be used is a crucial aspect of planning for any type of work. Preparation is also necessary before execution. Even if you’re inclined to skip planning and preparation and dive straight into action, you’ll quickly realize the need to identify and make available the required tools.

By this stage, you have addressed important questions such as the problem or aspect you aim to solve, the project’s objectives, and the chosen strategy. You have defined the solution based on the received requirements, identified deliverables, and developed a schedule and budget.

Now, it’s time to determine how you want things to happen in your project. This includes aspects like communication, issue and change management, the level of detail in your work breakdown structure (WBS), defining risk probabilities, establishing criteria for addressing severe risks, ensuring acceptable quality levels, engaging stakeholders, and collaborating with the purchasing department.

The subsidiary management plans are designed to answer these questions. They are referred to as “subsidiary” because they are part of the overall project management plan. Depending on your project’s requirements and organizational rules, these plans can be formal or informal, detailed or high-level.

To avoid overwhelming this section with exhaustive explanations of detailed management plans that may only apply to specific projects, we have provided an annex that outlines detailed management plans for reference as needed. The following explanations will focus on the most important aspects of these subsidiary management plans.

Let’s begin with the communications management plan.

Effective communication is a critical success factor for any project. If key stakeholders are not kept well-informed about the project’s progress, there is a higher likelihood of encountering problems.

All projects require effective communication of progress. Common means of communication include meetings and reports. A simple communications plan should outline when and how the team will meet and report progress. If you are utilizing a collaboration tool, particularly in Agile projects where teams are co-located, communication is facilitated. When planning communications, it is beneficial to prepare report formats and make the collaboration tool readily available.

Larger projects or those involving a cultural shift may necessitate a multi-faceted communication approach. This can be outlined in a communications plan, which may include additional means of communication such as a project website, regular communication events for a wider audience, and other initiatives to foster goodwill. Think of it as running a marketing campaign for your project.

In a risk management plan, it is crucial to establish a common ground for evaluating risks and aligning individual perceptions. Different team members and stakeholders may have varying views on what is considered acceptable or likely. The plan should define degrees of probability and impact to be used in analyzing future risks. Additionally, it should address how to compare the effects of different types of events, such as a schedule delay versus a cost increase or a potential quality issue. This can be achieved through a scoring system that assigns values to events and effects, making them comparable. We will delve into this in more detail in the section on risk analysis, as it is an integral part of the “plan risk management” process and one of the subsidiary management plans.

A quality management plan should outline the standards that will be applied to develop the solution. While acceptance criteria are defined for each work package, there may be overarching standards applicable at the project level. For example, if the project involves developing windows, specific standards for windows would come into play.

Here is a link to a list of British standards for windows https://www.bsigroup.com/en-GB/our-services/product-certification/industry-sector-schemes/construction/windows-and-doors/Standards-for-windows-and-doors

It is important to determine which standards will be utilized in the project. As part of this course, we implement the global standard ISO 21500 for project management.

We previously discussed defining quality in the management of the project in the section on “eliciting project management requirements.” A quality management plan should reference these requirements when establishing the desired level of quality for the project management itself.

A resource management plan can address how the project intends to acquire specialized resources, such as utilizing LinkedIn or advertising in newspapers, or engaging the services of an agency. It should also outline what will happen to full-time resources upon project completion. Will the team be recognized and rewarded for completing the project on time, within budget, and with a high level of quality? If so, the resource management plan is an appropriate place to document this.

A scope management plan may define the level of detail required for decomposing the WBS. This plan establishes upfront how detailed the breakdown should be.

A cost management plan would define the currency in which costs will be calculated and determine when a cost overrun triggers a special report to project governance.

A schedule management plan establishes the level of detail to be used for the schedule and integrates with the communication plan to determine if reports will be issued upon completion of major milestones, such as phase gates.

An issue and change management plan or procedure should outline how to handle these situations that will inevitably arise. It should specify how changes to scope, schedule, and budget will be managed. These processes can be explained in the respective management plans or in a unified procedure that governs changes to the project baseline.

Typically, issues requiring escalation to project governance and changes to baselined elements require approval from the project board and potentially from higher levels of corporate authority if the issue or change exceeds project-level authority limits. It is essential to analyze possible alternatives before presenting problems or requesting significant changes to the board. Issues and change management procedures typically establish a process for brainstorming options, analyzing their impact on scope, schedule, budget, quality, and risks, and proposing the best alternative. When the board approves a suggestion, they are also approving a change to the scope, schedule, and budget as proposed in the change or issue resolution proposition.

There may be additional subsidiary management plans, such as those for procurement, process improvement, and requirements, among others. However, one common criticism of strongly plan-driven frameworks, as noted by Agile practitioners, is the excessive use of these subsidiary management plans.

Indeed, in Agile projects where the team is small, working in close proximity, holding daily stand-up meetings, and delivering functional increments every two weeks, many of these plans may not be necessary. The close collaboration and constant communication among team members allow for real-time issue resolution and informed decision-making.

It is important to acknowledge that these management plans can have an impact on the scope, budget, and schedule of the project. As we continue to refine and gather inputs from the subsidiary management plans, elements such as costs and activities related to communication events, travel, marketing, quality assurance audits, risk coverage, or team incentives may need to be incorporated. Consequently, it is likely that updates to the current versions of the scope, budget, and schedule will be required.

In summary, proper organization of communications in a project is paramount. When communication flows smoothly, it sets the foundation for the successful operation of other project areas. Conversely, if communication is lacking, it can hinder the progress of the entire project.

Please refer to the supplementary material attached to this section for detailed descriptions of the various subsidiary management plans.

 

 

2.7.1 Plan risk management

This section provides an overview of the project management activities involved in planning risk management. As you’ve dedicated significant effort to planning your project, it is crucial to identify potential risks that could arise. While it’s inevitable that something will go wrong, we aim to prevent or mitigate any risks that could hinder the timely delivery, budget adherence, and desired level of quality. Let’s explore the concept of risks in more detail.

A risk can be defined as a potential future problem or threat that has not yet occurred. It refers to future conditions or circumstances that may adversely impact the project, and there is a level of uncertainty surrounding their likelihood of occurrence. It’s important to differentiate risks from problems:

• A problem is an event that has already taken place and requires resolution.
• A risk, on the other hand, has not yet occurred but possesses the potential to impact project objectives.

Additionally, risk management can also focus on positive risks, which we prefer to refer to as “opportunities.” This perspective aims to identify and leverage beneficial circumstances. However, our current focus lies on negative risks, also known as threats.

Managing risks or threats involves several steps:

• Prepare risk management: This entails creating a risk management plan, which we will discuss in this section.
• Risk identification: Here, you determine which risks could potentially affect your project.
• Risk analysis: Once identified, you assess the criticality of each risk and evaluate their combined effect on project objectives.
• Risk response: Based on the identified risks, you decide on appropriate measures to prevent threats or reduce their probability or impact.
• Implementation: The chosen risk response strategies are executed during the project’s execution phase.
• Risk control: Continuously monitor the risk exposure at regular intervals, such as at the start of new project phases, to identify new risks and assess the effectiveness of the implemented risk strategies.

To commence planning risk management, you need to establish three essential components for identifying and analyzing risks:

• A risk register: This document captures and maintains an inventory of identified risks throughout the project.
• A list of generic risks or risk categories: These predefined categories serve as a starting point for recognizing potential risks.
• A definition of probabilities and impacts: This framework assists the team in assessing risks consistently based on predefined criteria.

Please take a moment to review the example of a list of generic risks or risk categories.

Technical	Scope definition Requirements definition Estimates, assumptions, and constraints Technical processes Technology Technical interfaces	Management	Project management Program/Portfolio management Operations management Resourcing Organization Communication
Commercial	Contractual terms Internal procurement Suppliers Subcontracts Customer Partnerships	External	Legislation Exchange rates Sites, facilities Weather, environment Competition

A template of generic risk categories or risk sources is highly valuable in assisting the project team in identifying risks that are commonly associated with the specific type of project you are undertaking. This template provides a much more structured starting point compared to beginning a brainstorming session with a blank page. If your organization collects lessons learned from past projects, there may be a repository of information regarding risks encountered in similar projects. This resource can further enhance the customization of your list of generic risks to align with the specific risks your project may face at its outset.

The second essential component is the risk register. Initially, it can be a simple spreadsheet with a few columns. The purpose is to create a designated space, whether it be a document or a database, where risks are recorded as soon as they are identified. This register serves as a central location for capturing additional information that will be further developed during the risk analysis and response processes. A basic risk register may have the following format.

Risk Name	Risk Nr	Probability 1 to 5	Impact 1 to 5	Strategy type	Measure	Risk owner

A crucial aspect of risk management is defining the probabilities and impacts associated with risks, which ensures that the project team assesses risks using a consistent basis. Recall the example provided in a previous section: Is a cost overrun of 10,000 € more critical than a delay of 2 weeks?

To facilitate risk assessment, a matrix that outlines degrees of probability and impacts on project objectives can be used. The format of such a matrix could be as follows:

Scale	Probability	Impact
		Time	Cost in €	Quality
5 Very High	>70%	> 6 months	> 500K	Very significant impact on overall functionality
4 High	51% – 70%	3 ~ 6 months	100K ~ 500K	Significant impact on overall functionality
3 Medium	31% – 50%	1 ~ 3 months	50K ~ 100K	Some impact on key functional areas
2 Low	11%-30%	1 ~ 4 weeks	10K ~ 50K	Minor impact on overall functionality
1 Very low	1% – 10%	1 week	<10K	Minor impact on secondary functions

The definitions of probability and impact levels depend on the risk tolerance and acceptance criteria within your organization and specific project context. In a time-sensitive project, a one-month delay may be considered “high” or “very high” in terms of impact. Conversely, in a cost-critical project or a smaller-scale project, a cost impact of 200,000 Euros could be deemed as very high. These scales and definitions should be tailored to your project and may have already been established within your organization.

In summary, prior to identifying and analyzing risks, it is essential to prepare the necessary elements, including an initial risk register, a list of generic risks or risk categories, and well-defined gradations of probability and impact. Armed with these three components, your project team can effectively identify and classify potential negative events that may pose obstacles to achieving project objectives.

 

 

2.7.2 Identify risks

This section outlines the project management activities required to identify threats to project objectives, commonly known as risks.

In the case of small projects, the level of risk is typically lower due to their shorter duration, limited scope, and fewer stakeholders. The project manager can identify any obvious risks, define countermeasures for the most critical ones, and allocate a contingency reserve for the remaining risks. However, if a more rigorous process is desired or necessary, larger project guidelines should be followed.

A good starting point for risk identification is to conduct a risk assessment with the initial project team. Involving the sponsor in this process is often beneficial as their perspective expands the project’s view within the wider organizational context. The sponsor can help identify potential obstacles that may be more apparent from their viewpoint than from the project manager’s or team’s perspective. The risk assessment is typically performed in two parts.

First, consider inherent risks. Inherent risks are based on the project’s characteristics, regardless of the specific deliverables being produced. Generic risk categories or an organization-specific checklist based on past projects can be used to identify inherent risks, as outlined in the risk planning process.

Second, identify risks that are specific to your project. These risks cannot be found on a generic list as they are unique to your project’s context. Examples could include the risk of a key supplier going out of business, weather-related shipping delays, or challenges in finding resources with specific skills. To identify these project-specific risks, it is recommended to conduct brainstorming sessions with key stakeholders, utilizing the risk planning tools that have been developed.

It may be beneficial for the team to group related risks before entering them into the risk register for better organization and management.

Let’s take our example of an online solution to improve transaction transparency and select some deliverables from the WBS while reusing the draft versions of the schedule and project budget.

Assuming these are some of the work packages:

• Functional specifications for the entire solution
• User interface
• Workflows
• Status tracking tool
• e-Payment
• Online help
• Training sessions

Let’s assume that the risk brainstorming sessions have identified the following risks. Please take a moment to review the list of detected risks.

• Functional requirements for the entire solution look fine at a high level, but the team has doubts if this set of requirements is sufficient for each work package.
• Status tracking tool: The selected supplier is based in country Z, and we have no prior experience with them. They were chosen primarily for their low price, which aligns with the budget constraints set by the finance department. However, there are concerns about their unfamiliarity and whether they can deliver the required quality. On the positive side, the vendor’s sales representative is fluent in our language and presents themselves professionally.
• e-Payment: A significant portion of our customers is located in region X, where e-Payment solutions face challenges due to strict authorization processes for payments in hard currencies. This could impact the implementation and adoption of the e-Payment feature.
• Online help: All estimates for the project are based on providing online help in English. However, there are rumors circulating within the organization that the sales department finds this unacceptable and insists on having online help available in French, Spanish, German, and Arabic as well. This potential requirement change could impact the project’s scope and resources.
• Training sessions: The budget estimates for traveling to locations A, B, and C for conducting training sessions seem overly optimistic. There is a concern that the allocated budget may not be sufficient to cover the actual costs of travel and accommodations.
• The sponsor is heavily occupied with other projects, which may limit their availability and involvement in this project. This could potentially delay decision-making and hinder effective project governance.

The next step is to enter these identified risks into the risk register for further analysis and management.

Risk Name	Risk Nr	Probability 1 to 5	Impact 1 to 5	Criticality
Functional requirements	1
Status tracking tool	2
e-Payment	3
Online help	4
Training sessions	5
Sponsor	6

Let’s summarize by stating that the level of formality in your risk management approach should align with the size and complexity of your project. Larger and more complex projects typically require a more formal approach to risk management.

Risk identification is a collaborative effort, and it is important to involve the sponsor in this process. The sponsor’s perspective and experience can provide valuable insights during risk identification.

The process of risk identification can be divided into two steps:

• Step one involves identifying the generic risks that are typically associated with projects of this type. These risks can be derived from past projects or industry knowledge.
• Step two involves identifying the specific risks that are unique to your project. These risks may arise from project-specific factors, such as stakeholders, technology, or external influences.

Once risks are identified, they should be recorded in the risk register for further analysis and management. The risk register serves as a central repository for capturing and tracking identified risks throughout the project.

 

 

 

 

2.7.3 Analyze risks

This section outlines the project management activities required to analyze and classify risks before developing risk responses.

Once risks have been identified, the next step is to determine their significance and the potential impact they may have on project objectives. This is accomplished through risk analysis.

To analyze the identified risks, you refer to the risk register, which now contains a list of identified risks. You consult the definitions of probability and impact that were developed during risk management planning to assess each individual risk and assign a risk score.

Scale	Probability	Impact
		Time	Cost in €	Quality
5 Very High	>70%	> 6 months	> 500K	Very significant impact on overall functionality
4 High	51% – 70%	3 ~ 6 months	100K ~ 500K	Significant impact on overall functionality
3 Medium	31% – 50%	1 ~ 3 months	50K ~ 100K	Some impact on key functional areas
2 Low	11%-30%	1 ~ 4 weeks	10K ~ 50K	Minor impact on overall functionality
1 Very low	1% – 10%	1 week	<10K	Minor impact on secondary functions

Let’s take risk number 1 as an example. The risk is related to the functional requirements for the entire solution, which appear to be fine at a high level, but the team has doubts about whether these requirements are sufficient for each work package.

If the functional requirements are vague, there is a high probability that the company’s needs will not be met. The team classifies the probability of the risk occurring as higher than 70%, a value that has been defined as “very high” level and is assigned a score of 5. They estimate that the impact on the schedule could result in a delay ranging from 3 to 6 months, an interval that has been defined as “high” level and is assigned a score of 4. Regarding the costs, the team considers that the impact could fall within a range of €50,000 to €100,000, an interval that has been defined as “medium” level and is assigned a score of 3. However, concerning the quality, they believe that the potential impact of vague requirements could significantly affect overall functionality, which has been defined as a “very high” level impact and is assigned a score of 5.

Based on these assessments, the resulting scores are as follows:

• Probability score: 5
• Impact scores: 4 + 3 + 5 = 12
• Therefore, the resulting criticality score for the risk is calculated as 5 multiplied by 12, equaling 60.

Risk Name	Risk Nr	Probability 1 to 5	Impact 1 to 5	Criticality
Functional requirements	1	5	12	60
Status tracking tool	2
e-Payment	3
Online help	4
Training sessions	5
Sponsor	6

Risk number 2 pertains to the status tracking tool. The selected supplier is based in country Z and is unfamiliar to us. They were primarily chosen for their exceptionally low price, which allows the project to align with the budget constraints set by the finance department for this year. On the positive side, the sales representative of the vendor communicates fluently in our language and creates a professional impression.

The team believes that if the vendor proves to be unreliable or if significant communication issues arise, it could potentially jeopardize a core functionality of the project.

Using the definitions of probability and impact, the team considers that this event has a probability of occurrence ranging from 51% to 70%, an interval that has been defined as “high” level and is assigned a score of 4. The impact of this circumstance is considered to potentially involve a delay ranging from 3 to 5 months, an interval that has been defined as “high” level and is assigned a score of 4. However, due to negotiated contractual clauses, the estimated impact on costs would be lower than €10,000, a value that has been defined as “low” level and is assigned a score of 1. Finally, the impact on the quality of an unreliable supplier could have a very significant effect on overall functionality, which has been defined as a “very high” level impact and is assigned a score of 5.

Scale	Probability	Impact
		Time	Cost in €	Quality
5 Very High	>70%	> 6 months	> 500K	Very significant impact on overall functionality
4 High	51% – 70%	3 ~ 6 months	100K ~ 500K	Significant impact on overall functionality
3 Medium	31% – 50%	1 ~ 3 months	50K ~ 100K	Some impact on key functional areas
2 Low	11%-30%	1 ~ 4 weeks	10K ~ 50K	Minor impact on overall functionality
1 Very low	1% – 10%	1 week	<10K	Minor impact on secondary functions

The resulting scores for Risk Nr 2, the status tracking tool, are as follows:

• Probability score: 4
• Impact scores: 4 + 1 + 5 = 10
• Criticality score: 40

Risk Name	Risk Nr	Probability 1 to 5	Impact 1 to 5	Criticality
Functional requirements	1	5	12	60
Status tracking tool	2	4	9	40
e-Payment	3
Online help	4
Training sessions	5
Sponsor	6

And we continue using the same logic for risks 3, 4, and 5. The results are as follows:

Risk Number 3, e-Payment: A significant portion of our customers is located in region X where e-Payment solutions are challenging or impossible due to the authorization process required for payments in hard currencies.

• Probability score: 5
• Impact score: 1 + 1 + 3 = 5
• Criticality score: 25

Risk Number 4, Online help: All estimates are based on online help in English, and other languages have been explicitly declared as “out of scope.” However, there are rumors circulating that this is unacceptable for the sales department, which desires French, Spanish, German, and Arabic languages as well.

• Probability score: 3
• Impact score: 2 + 2 + 3 = 7
• Criticality score: 21

Risk Number 5, training sessions: The budget estimates for traveling to locations A, B, and C appear to be overly optimistic.

• Probability score: 4
• Impact score: 1 + 2 + 1 = 4
• Criticality score: 16

Risk Number 6, the sponsor is too busy with other projects.

Let’s examine this risk more closely. If the project has a less committed sponsor, there is a high probability of encountering issues in all areas. The team estimates that there is a probability exceeding 70% that the sponsor will not be sufficiently involved in the project, which has been defined as a very high level of probability and is assigned a score of 5. The team also estimates that without a committed sponsor, it will be difficult to obtain the necessary internal resources, and this could lead to delays ranging from 3 to 6 months, an interval that has been defined as a high level and is assigned a score of 4. Additionally, the team is skeptical about the quality of the commercial requirements hastily expressed by the sponsor, which could result in additional costs ranging from €100,000 to €500,000, an interval that has been defined as a high level and is assigned a score of 4. Finally, concerning the quality, the team believes that the potential lack of support from the sponsor to acquire adequate internal resources could have a significant impact on the overall functionality of the solution, which has been defined as a high level and is assigned a score of 4.

The resulting scores are:

• Probability score: 5
• Impact score: 4 + 4 + 4 = 12
• Criticality score: 5 multiplied by 12 equals 60

The updated risk register would appear as follows, ordered in descending order of criticality:

Risk Name	Risk Nr	Probability 1 to 5	Impact 1 to 5	Criticality
Sponsor	6	5	12	60
Functional requirements	1	5	12	60
Status tracking tool	2	4	10	40
e-Payment	3	5	5	25
Online help	4	3	7	21
Training sessions	5	4	4	16

As a result of analyzing risks, we now have a clear understanding of which risks are the most critical and require our attention when developing active responses.

To summarize, we assign each risk a single score by multiplying its probability score with its impact score. This qualitative risk analysis helps us prioritize risks effectively. However, when we estimate the financial and temporal impact of these risks on project objectives, we perform a quantitative risk analysis.

 

 

 

 

2.7.4 Plan risk responses

This section explains the different types of responses available to address risks.

Once you have identified the most critical risks, you can proceed to develop appropriate responses based on their level of criticality. The risk management plan should specify the criticality level at which the project management team needs to develop active responses to individual risks. Let’s assume that the risk management plan states that active responses should be developed for risks with a criticality level of 25 or higher. In that case, we would address the following risks:

• Risk number 6: Unengaged sponsor
• Risk number 1: Vague functional requirements
• Risk number 2: Supplier of the tracking tool
• Risk number 3: e-Payment difficulties in certain countries

For the remaining risks, number 4 and number 5, we will define an “acceptance strategy” and allocate reserves of time and money to monitor them as long as they remain at that criticality level.

Typical risk response strategies include:

• Avoid
• Mitigate
• Transfer
• Accept

When employing an “avoid” strategy, the goal is to eliminate the risk by addressing its root cause. This may involve changing a project objective or modifying the project management plan. However, this approach can be quite drastic. For example, eliminating an entire portion of the scope of work or changing suppliers would be considered examples of an “avoid” strategy. In the case of the language issue for the online help, it was addressed in the scope statement by declaring languages other than English as out of scope. However, it appears that expectations were not effectively managed as a key stakeholder does not accept this response.

In contrast, a “mitigate” strategy focuses on actions aimed at reducing the probability and/or impact of the risk. For instance, if stakeholders have difficulty expressing their requirements, creating a prototype can be a mitigating strategy. Similarly, if there is a risk of communication difficulties due to different locations, the team could implement a mitigating strategy by using a reliable collaboration tool.

The “transfer” strategy involves finding another entity to assume the risk. This could include purchasing an insurance policy or outsourcing certain aspects of the project to a more knowledgeable party with better tools.

On the other hand, the “accept” strategy entails taking no specific action to address the risk. This approach is suitable for risks with low criticality. However, there is also an “active acceptance” approach that involves building reserves of money and time to account for any potential impacts.

It is possible that the risk management plan also establishes a certain level of criticality that would require escalating the risk to the project board or even to the corporate level. Certain project risks can pose a threat to the entire organization’s existence, such as contract penalties.

Let us continue the risk analysis using these strategies to develop responses for risks with a criticality level of 25 or higher:

• Risk number 6: Unengaged sponsor
• Risk number 1: Vague functional requirements
• Risk number 2: Supplier of the tracking tool
• Risk number 3: e-Payment difficulties in certain countries

Risk number 6, where the sponsor is not engaged due to being too busy with multiple projects, can be addressed through a mitigation strategy. The project manager could propose nominating a delegate who can represent the sponsor on a day-to-day basis for the project. This ensures that the delegated sponsor will have dedicated time for the project.

Risk number 1, the functional requirements are vague. One possible response would be to switch from a predictive approach to an incremental approach. In an incremental approach, the requirements for some selected functionalities would be asserted and implemented in a first version of the solution, while additional functionalities would be defined in more detail and implemented in a second version. This would be an avoidance strategy as it would involve changing the project management plan, moving from implementing a complete functional solution to a delivery in increments. On the other hand, if we maintain the predictive approach but organize additional workshops to define the functional requirements of the complete solution more precisely, we would be applying a mitigation strategy.

Risk number 2, concerning the supplier of the tracking tool, the project management team can choose to replace the supplier as an avoidance strategy. Alternatively, they can opt for a mitigating strategy by closely monitoring the supplier’s work progress. Imposing contractual penalties for delays would be considered a “transfer” strategy, although it is worth noting that obtaining reimbursement from insurance companies can sometimes be challenging.

Risk number 3, related to e-Payment difficulties in certain countries, a potential response could involve a “transfer” strategy by seeking cooperation with local financial institutions to propose triangular payment solutions for those countries. Another option could be an “avoidance” strategy by deciding not to implement e-Payment for those countries and instead relying on manual bank-to-bank money wire transfers.

For risks 4 and 5, which fall below the criticality threshold of 25, an active acceptance approach can be employed by creating reserves for contingencies in the project’s schedule and budget.

After selecting the risk responses, the updated risk register would reflect the actions to be taken, including nominating a delegated sponsor, conducting requirements gathering workshops, replacing the tracking tool supplier, hiring a supplier for triangular payment solutions, and building reserves of time and money.

Risk Name	Risk Nr	Prob. 1 to 5	Impact 1 to 5	Criticality	Strategy	Measure
Sponsor	6	5	12	60	Mitigate	Nominate delegated sponsor
Functional   requirements	1	5	12	60	Mitigate	Requirement   workshops
Supplier of tracking tool	2	4	9	36	Avoid	Replace the supplier
e-Payment	3	5	5	25	Transfer	Hire triangular   payments supplier
Online help	4	3	7	21	Accept	Reserve of 2 weeks and 25K (*)
Training     sessions	5	4	4	16	Accept	Reserve of 1 Week and 35K (**)

(*) Probability medium: 3 = 31%-50% / Impact on time (low) 1-4 weeks; 50% of 4 weeks = 2 weeks / Impact on cost (low) 10K-50K; 50% of 50K = 25K

(**) Probability high: 4 = 51%-70% / Impact on time (very low) 1 week x 70% = 0.7 week rounded up to 1 week / Impact on cost (low) 10K-50K; 50K x 70% = 35K

For risks that are particularly critical, it may be necessary to develop a “Plan B” or contingency plan in case the risk occurs despite the initial strategy. This fallback plan involves pre-selecting potential alternatives or solutions. For example, if the team decides to keep the current supplier of the tracking tool using a mitigating strategy, they can prepare a contingency plan by identifying and pre-selecting a potential replacement supplier.

It is important to consider that some risk strategies may give rise to new risks known as “secondary risks” that result from the chosen risk response. For instance, if you take a romantic trip to the Seychelles with your spouse to mitigate the risk of routine in your relationship, you might encounter financial risks due to the cost of the trip. These financial risks would be secondary risks resulting from the primary risk response.

Cost consideration is crucial when implementing risk responses. The cost of implementing a risk response should be factored into the project budget. This cost should not exceed the expected monetary value of the risk, which is the probability multiplied by the cost impact of the risk. If the expected monetary value is lower than the cost of the response, it is more practical to accept the risk and allocate a specific reserve for the expected monetary value. For example, if you earn $10,000 a year as a freelancer and there is a 1% probability of being sick and losing income for a year, the expected monetary value of the risk would be 1% of $10,000, which is $100. If an insurance policy costs $200, it would be more efficient to set aside a reserve of $100, which covers the expected monetary value of the risk.

It is important to note that after implementing a mitigating strategy, a residual risk may still remain. While the probability and impact are reduced, they do not become zero. Therefore, your reserves for contingencies should cover both accepted risks and residual risks.

Updating the draft elements of the project management plan is necessary after implementing risk responses. Let’s assume that a delegated sponsor will address the risk and provide strong sponsorship for the project. However, conducting a series of workshops to gather functional requirements could introduce new costs and time-consuming activities, potentially affecting the draft schedule and budget.

Replacing the supplier for the tracking tool would involve new activities to find a new supplier. It’s important to consider whether the new supplier carries any risk of delays.

Hiring the e-Payment supplier would also introduce new activities, and they may charge fees for each transaction. If these fees are passed on to the final customer, it would not significantly affect the business case. However, if the fees are substantial and need to be absorbed by the project, it may impact the projected cash inflows in the business case. The acceptance of these additional costs by the sales department could be an important consideration, making active sponsorship crucial in this case.

All of the information provided thus far pertains to “identified risks.” However, there are also “unknown risks” that remain hidden and are not detected during the risk identification process. These unknown risks are addressed through the “Management Reserve,” which was explained in a previous section. The Management Reserve is outside the project baseline and falls outside the control of the project manager.

In the final step of the risk management process, it is important to assign a person who will be responsible for managing each identified risk. This person is known as the “risk manager” or “risk owner.” The risk owner will continue to oversee the management of the risk even after the project execution has begun, including monitoring its status.

Some advanced risk management methods also define measurable thresholds that trigger conditional responses. For example, if a certain indicator surpasses a predefined threshold, a specific response plan will be activated.

To summarize, it is important to keep in mind the typical risk response strategies: avoid, mitigate, transfer, and accept.

• It is also essential to be aware that selecting a particular risk response strategy may introduce secondary risks.
• Additionally, remember that even after responding to risks, there may still be residual risks remaining if the primary risk is not completely eliminated. Therefore, the contingency reserves should account for both accepted risks and residual risks.
• Finally, it is necessary to update the corresponding sections of the project management plan to reflect the direct costs and activities associated with the selected risk responses, as well as any other necessary changes identified during the process of risk identification, analysis, and response.

 

 

2.8 Integrate a Project Management plan, obtain sponsor approval and inform stakeholders

This section summarizes the elements that compose the project management plan. Now, we focus on the integration of all these elements, obtaining the project’s performance baseline, and communicating the approved plan to stakeholders.

At this stage, the project’s initial team has collaborated with experts and other key stakeholders, including the sponsor, to develop and integrate the scope, schedule, and costs in order to achieve the objectives leading to the project’s goal. These efforts included creating subsidiary management plans and planning risk responses.

The starting point is the project charter, which first indicates which part of the problem we are trying to solve and then defines the project’s goal with one or several key deliverables.

During the planning activities, we have set SMART objectives leading to the project’s goal.

We have obtained functional requirements and quality attributes for the key deliverable derived from the scope statement, describing the product the project will create and the work needed to create it. Then, we have decomposed this scope down to the level of work packages. Some of these work packages, especially those to be implemented first, are defined in more detail under the direction of a responsible person for each work package. The work packages define the activities needed to develop the deliverables of each, as well as the quantity and types of resources required for them.

With this information at hand, we have estimated durations and created a project schedule, based on the approximate milestone schedule created for the project charter. The schedule is not created all at once but gradually incorporates elements from other aspects of project planning.

We have used the work breakdown structure and the schedule to estimate the costs of the work packages, summarizing them into control accounts, deliverables, and summary deliverables to obtain the cost baseline.

We have defined an approach for the development of the solution, sometimes called the project life cycle. Different components of the work breakdown structure may have different types of life cycles, depending on their nature. Those that we understand sufficiently in advance can use a predictive life cycle. Those that will be better understood during the project can use an iterative or incremental development approach if it is technically feasible and acceptable for the overall project.

We have also gathered requirements on how the project should be managed. These stakeholder requirements for project management are an important input for developing subsidiary management plans.

Finally, we integrate all the individual components to create an integrated plan. This means that we integrate the scope of work to create the product, along with corresponding estimates of efforts, durations, and costs. But we also integrate these elements with the activities necessary to manage communications, stakeholder engagement, team development, acquisitions, risk responses, and any other elements included in subsidiary management plans.

Integrating means that we should not have activities in the communications management plan, or risk responses, or work packages in the work breakdown structure, and not have them in the schedule or miss their respective costs in the budget. The project management plan should merge all individual planning elements into one harmoniously integrated piece.

When all these elements are well combined and balanced, approval must be obtained from the governing body. In most cases, this would be the sponsor and the project’s client, if these two roles are performed by two different individuals.

Upon approval, the scope statement and the WBS become the scope baseline, the estimated schedule becomes the schedule baseline, and the estimated costs become the cost baseline. These three baselines together form the project baseline, which provides the updated version of what the project will deliver, when, and at what cost. The baselines serve as the foundation for performance measurement throughout the project.

Finally, the project manager informs stakeholders about the approved project management plan, and a second kickoff meeting can be organized to inform everyone about the final plan and transition from planning activities to execution activities.

Please review the section on the kickoff meeting after creating the project charter. You can use and adapt all the elements described in that section. One adaptation consists of summarizing now the elements of the project management plan, instead of the elements of the project charter. In other words, what starts now are the execution activities. That is, we begin to carry out the work indicated in the project management plan. Make sure that those who need to start first are prepared.

The completed project management plan is not placed on a shelf to gather dust. It is actively used and kept up to date throughout the duration of the project: to lead and monitor the progress of the work, to make corrections as needed, and to communicate effectively with stakeholders.

A final word on the lifespan of the first version of the project management plan. It is not planned once at the beginning of the project, hoping that things will automatically unfold according to the plan.

After the approval of the project management plan, we begin to execute the first phase if there are multiple phases. During the execution of this first phase, we monitor and control the progress of the work to see if things deviate from the plan. Experience indicates that in most cases, there will be deviations from the plan due to issues, risks, and unforeseen circumstances, to which we will respond with corrective and preventive measures that need to be planned and implemented, and that will naturally affect the project management plan.

Upon completing the first phase, we will carry out phase closure activities, which are explained in detail in the section dedicated to phase closure activities. Then, we will initialize the next phase, possibly with new stakeholders and risks. We will perform initialization and detailed planning for this next phase. And so on. Therefore, we must update the project management plan iteratively throughout the entire project, after the approval of the project charter.

The individual components of a project management plan have been explained in detail in the previous sections.

To summarize, we follow the initiating, planning, executing, controlling, and closing cycle, which constitutes a dynamic and iterative process rather than a unidirectional linear progression.

 

 

3.1. Executing a project – Overview

This section provides an overview of the management and leadership activities necessary to direct the execution of the work included in the project management plan.

At this point, we have dedicated enough time to planning the project, and now we are ready to begin the execution of the work. The big moment has arrived for those who prefer doing more than just planning, as they can finally start creating the key deliverable. What needs to be done is explained in the project management plan. Naturally, the creation of the project’s main product is what consumes the majority of the budget.

In the following sections, we will learn how to acquire human and inanimate resources, when to use which type of contract for procurement, how to approve work packages, and how to lead, manage, and develop teams, including coaching techniques and examples of methods to engage stakeholders.

We will explore how to ensure quality, implement changes, corrective measures, and answers to risks.

We will explain how to use lessons learned to improve processes and much more.

Stay tuned for the next lessons to learn more about the management of project execution.

 

 

 

 

3.2 Acquire project or phase resources

This section explains the techniques and tools used to acquire the necessary resources for the execution of the project or of a phase.

Acquiring resources means obtaining the right resources at the right time. That is, getting the responsible individuals for the work packages, team members, as well as technical equipment, space, raw materials, and other elements necessary to carry out the work packages.

Please note that specific aspects of acquiring external resources through procurement are addressed in the section dedicated to procurement management.

Not obtaining the right resources or not obtaining them on time would have a negative impact on the performance baseline and could lead to project failure.

To obtain the right responsible individuals to lead work packages and team members, the project manager must use their influence and negotiation skills with those who control these resources.

Much depends on the type of organization established for the project. If the project is large-scale and uses a projectized organization (sometimes called a project-oriented organization) instead of a matrix organization, at least key human resources of the project will be allocated full-time, and the project manager will be their only hierarchical superior. In this case, there will be no conflicts of priorities with functional managers for the use of these resources. Potential conflicts in priorities arise more often in the matrix organization, especially for part-time resources who continue to work in their operational functions alongside their work for the project.

But even in a projectized organization, negotiations for some resources are required. Whether it’s obtaining part-time staff to perform activities that do not have full-time resources, reserving the use of technical equipment or space, or acquiring external resources through purchase, leasing, or rental.

If we have developed an appropriate project management plan, we can rely on what we have already anticipated in the resource management plan. In this subsidiary plan, we should have clarified how resources will be acquired. The schedule baseline tells us when work packages should start and finish, and the cost baseline tells us their respective budgets. The stakeholders register tells us with whom we must talk. Additionally, we have a sponsor and a problem management process to implement in case of conflicts of priority with functional managers who control the resources we need.

Let’s look at some useful techniques for acquiring the necessary resources for the project or a phase.

The first technique is pre-assignment. This is done when the team members responsible for performing work are determined before the execution processes begin. If you need a specific skill or a specific set of skills and these resources are scarce, you can pre-assign them very early, even during the preparation of the project charter, especially if the project depends on those specific resources. In colloquial terms, we could say that we will have “reserved” those resources.

The second technique is the use of interpersonal skills, especially negotiation. To obtain the necessary resources for the project, you will probably need to negotiate with functional managers, other project teams, and even external organizations, suppliers, or subcontractors. The success of the project depends on the success of these negotiations.

The third technique is the use of virtual teams. These are an option for acquiring resources for the team that may not be available locally. Modern collaboration tools allow obtaining this type of resources that otherwise would not be available. However, the use of techniques and tools for remote collaboration requires good planning and preparation of communications. For example, the online version of this course allows you to experience the use of some good tools for remote collaboration.

You may need to make decisions between several candidates, and for that, you can use a multicriteria decision matrix, as explained in the section on strategy evaluation. Do you remember? The evaluation criteria are weighted according to their relative importance. Some examples of criteria to weigh in the selection of human resources are availability, cost, experience, knowledge, attitudes, cultural factors, or other criteria.

The result of these actions should be the binding assignment of specific resources, both human and inanimate, in accordance with the specifications of the work packages, the dates established in the schedule, and the costs defined in the budget.

In summary, let’s remember that resources include both human resources and inanimate resources, also called material resources, such as technical equipment, space, raw materials, and other elements necessary for the execution of works. Resources may have been pre-assigned beforehand or may be assigned during the start of the work execution processes. The resource management plan serves as a guide for the acquisition of these resources. The ability to influence stakeholders and negotiation skills are essential competencies in this process. Good planning and appropriate tools are fundamental for the effective functioning of virtual teams.

 

 

 

 

 

3.3 Conduct procurements

This section explains various aspects related to obtaining responses from suppliers, selecting a supplier, and awarding a contract to obtain external resources.

For some components of your solution, you may prefer to manufacture them internally. For other components, buying may be a better option. And for other elements, there may be a combination of purchasing and manufacturing. Deciding what to produce internally and what to buy are important decisions that must be made early in the project’s life cycle. This is because the approach to purchasing something is very different from the process of manufacturing it.

The cost of manufacturing versus buying is an important aspect of this decision, but it is not the only parameter to consider. Other aspects may influence this decision. For example, do you want to use internal resources? How rigorously do you want to control work progress? Is the intellectual property of the outcome important to you? Does your organization possess the necessary skills and capabilities? If so, to what extent is this personnel available for the project? Is the work to be done part of the company’s core competencies?

In some cases, you will need to decide between buying or renting, for example, equipment and facilities. The economic calculation for this is similar to when you decide to buy or rent a car for a day when you need it. The calculation is based on how often you would use the car and for how long. Buying tends to be a better option if it is used frequently and for an extended period. There are also other parameters, including, among others, the initial outlays required for the purchase. Another aspect is that buying implies that you will have the item on your balance sheet as an asset and the debt as a liability if you finance it.

Once the decision to manufacture, buy, or rent has been made, the next step is to select a suitable supplier using a weighted decision matrix. The weighted selection criteria may include:

• Cost
• Technical approach
• Project management capabilities
• Experience in similar projects
• References
• Intellectual property rights

Once the selection criteria are clear, look for potential suppliers who can meet your needs. Good candidates are pre-qualified suppliers with a good track record in previous projects of your organization.

If you need to search for new suppliers, the search can be conducted through discussions with other companies, internet search, or consulting specialized publications in the corresponding economic sector.

You will begin to create a fairly comprehensive list of potential suppliers. The goal of this stage is to have many potentially interesting options on your radar. You can narrow down this long initial list to a medium-sized list through an intuitive initial evaluation, looking for obvious reasons to discard some alternatives.

The next step is to move from the medium-sized list to a shortlist of candidates. You should send a request for proposal to the medium-sized list and evaluate their proposals using the weighted selection criteria.

As part of this process, you can interview suppliers or visit their facilities. In large projects, there may be supplier conferences to ensure that all suppliers receive the same information and that there is no favoritism.

You will calculate individual scores for each criterion, multiplying them by the weight of the criterion to obtain a score for each candidate. As a result, you should get a ranked list of suppliers according to a balanced set of selection criteria.

In many organizations, the project team makes a recommendation, and then the process is transferred to the entity officially in charge of purchasing in the organization. This could be the purchasing department if it exists. Sometimes, the project manager may be responsible, as technical, legal, and commercial experts may be required to participate. If the purchasing department leads the process, an important consideration from a project manager’s perspective is not to select the supplier based solely on being the cheapest, disregarding other selection criteria.

At this point, there should be enough information to make the decision. You may want to enter into contract negotiations before making the final decision, starting with your number one option. If contract negotiations are not satisfactory, you can move to your second option and then to your third if those suppliers still meet the minimum score set by the project management team.

The outcome should be a signed contract.

Regarding contracts, it should be noted that they do not necessarily have to be fixed-price contracts.

The three basic types of contracts are fixed-price contracts, cost-reimbursable contracts, and time and materials contracts. There are variations, especially regarding the type of incentive to use, if applicable, but these three types are the main ones.

These contract types define the level of financial risk sharing between the buyer and the seller. And each one is better suited to different scope definition scenarios. Let’s take a closer look at when each type of contract is better suited.

Fixed-Price Contracts: This type of contract usually details the quantity and quality of goods or services that the seller will provide, the schedule, and the price. In general, the scope of the work is very detailed. It offers a predictable cost. The responsibility for managing the work to meet the requirements primarily falls on the supplier. The project team oversees the quality and progress in relation to the schedule to ensure that the supplier meets the requirements. The drawback is that the supplier will add substantial reserves for contingencies and unforeseen events to cover risks that are primarily on the supplier’s side. A variation of this type of contract may include an incentive for milestone achievement.

Cost-Reimbursable Contracts: This category of contract provides cost reimbursements to the supplier for all legitimate actual costs incurred for the work performed. These payments are increased with fees representing the supplier’s profits, often in the form of a percentage of the estimated project costs. This type of contract is recommended for cases where the scope of work is not fully defined at the beginning of the contract or is expected to change over time. In this type of contract, the supplier needs fewer reserves for contingencies and unforeseen events, as they assume less risk. To encourage the supplier to find ways to reduce costs or meet schedule milestones, variants of this type of contract with a performance incentive are often used.

Time and Materials Contracts: This type of contract is often used for staff augmentation, acquiring experts, and obtaining external assistance when it is not possible to quickly establish a precise scope of work. Payment is made for the time of utilization of an external resource, associated costs, and the materials used. The project assumes most of the risks, and the supplier needs the lowest need for contingency reserves. The project management team must control what the project receives for the time paid.

The following table provides an overview of important aspects that are generally part of a contract:

Statement of work	Timelines for delivery
Progress reporting	Contracting parties and their roles and responsibilities
Location of performance	Pricing and payment terms
Place of delivery	Inspection and acceptance criteria
Warranty and product support	Limitation of liability
Change request handling	Termination and alternative dispute resolution mechanisms

Reaching a final agreement through the contract may involve updates to various elements of the project management plan, such as the cost management plan, cost baseline, schedule baseline, scope baseline, requirements documentation, stakeholder register, risk responses, and communications management plan.

In summary, it is necessary to make early decisions about what the project will buy or manufacture. The supplier selection process should use a weighted multicriteria decision matrix to evaluate responses to requests for proposals from a medium-sized list of potential suppliers. There are more criteria to consider besides the price. The choice of contract type should consider not only cost predictability but also the level of accuracy in defining the scope of work. Experts from various areas should be involved, and the procurement management plan should explain the process and the project manager’s role. Different subsidiary plans of the project management plan may need to be updated due to the realization of procurements.

 

 

3.4 Authorize, delegate, execute and approve work packages

This section addresses activities related to the management of work packages, after they have been defined and planned during the planning activities. It is strongly recommended to thoroughly review the planning sections dedicated to the Work Breakdown Structure and work packages.

The process of authorizing, delegating, executing, and approving work packages serves as a connection between the project manager and the work package leaders.

• From the project manager’s perspective, the focus is on authorizing and delegating the execution of work packages, followed by their approval after a final quality evaluation process.
• From the viewpoint of the work package leader, the emphasis is on accepting the delegation of the work package and managing its execution, including internal testing by the development team. The work package leader is also responsible for reporting progress to the project manager and presenting the completed work package for approval and delivery to the project manager.

Work packages are initially defined within the Work Breakdown Structure. From there, they are integrated into the schedule for sequencing, either as whole work packages or broken down into constituent activities.

Each project phase includes at least one work package. Typically, several work packages form one or more deliverables that must be completed within a phase, and the phase concludes when these phase deliverables are finished.

Work packages can be executed sequentially by one team or in parallel by different teams. The project schedule, which is more detailed for the current phase, serves as a reference framework for sequencing. The project manager uses the project schedule to determine when each work package should start and finish.

Each work package must have its own definition and planning. The leader of the work package development team is responsible for the detailed planning of the work package, utilizing the expertise of team members. They then coordinate the execution of the work by a team of specialists who will create the product described in the work package.

In many cases, the work package leader will assemble the team of specialists from their own organization. This occurs when the work package leader is part of an external organization. However, it can also occur when a functional manager from the same company as the project manager takes on the role of a work package leader and forms a team led by themselves to deliver the requested product. This arrangement helps avoid conflicts that can arise from a matrix organization, where a project manager oversees work performed by staff from a department led by someone else.

The level of formality in defining the work package may vary depending on whether the team of specialists is internal to the organization or if the work package has been outsourced to a subcontractor. In the latter case, the work package definition may be part of a contract with that subcontractor.

Authorization, Delegation, and Execution of a Work Package

Authorizing and delegating a work package is the responsibility of the project manager. Accepting the delegation of the work package’s execution is the responsibility of the work package leader, who becomes the leader of the team responsible for executing the work.

At the appropriate time, the project manager authorizes and agrees with the respective work package leader on the initiation of each work package. If necessary, review the sections on resource acquisition and procurement. These processes explain how to obtain specialists and team leaders for the work packages needed to complete the deliverables.

The information contained in the work package definition clarifies what needs to be produced, the product acceptance criteria, the tasks to be performed, as well as the estimated costs and schedule.

The project manager is responsible for managing the interfaces between different work packages.

The team leader is responsible for leading the execution of the work package that has been delegated to them and which they have accepted.

For a product to be considered completed, there are three stages:

• First stage: The work package development team creates the product in accordance with the acceptance criteria defined in the work package.
• Second stage: The work package team conducts an internal quality assessment of the product before presenting it for acceptance outside the development team.
• Third stage: This stage involves a formal presentation for approval by the project manager. Depending on the product, the project manager may request technical support from a subject matter expert during this evaluation for product approval.

During the execution of a work package, it is also important to regularly communicate accurate information about the progress status to the project manager. This is achieved through regular updates from the work package leader to the project manager. The work package definition explains how and how often progress reports are generated. The project manager is also the escalation point for the work package leader in case of issues and change requests. The key point that the work package team must understand is that their work package is part of a larger product for which the project manager is responsible.

Approval of a Work Package

At a meeting to approve a work package, at least two individuals participate.

One person acts as the chairperson and serves as the reviewer. The role of chairperson and reviewer can be assumed by the project manager. Depending on the product being reviewed, the project manager may receive assistance from a technical support person.

The other person is the work package leader, who acts as the presenter, taking notes themselves or being supported by an administrative support person.

The reviewer examines the product in relation to the acceptance criteria defined in the work package. Evidence of compliance with the acceptance criteria is requested and presented by the presenter. Questions are asked and answered. Actions that may be necessary are agreed upon and recorded.

The result of the quality review can be:

• The product is correct and complete; therefore, it is accepted.
• The product is almost correct and complete and is conditionally accepted. This means that some actions are still required, which are recorded, but a second quality review meeting is not necessary.
• The third possible outcome is that the product is not correct or complete, it is rejected, and it is sent back for rework. Another quality review will be necessary.

For products where the project manager takes on the role of the work package leader and leads the work of the development team, someone outside the process must assume the role of the reviewer.

Depending on the nature of the work package, especially if it is executed by an external provider, a second approval instance may be required if stipulated in the contract. In Agile projects or components, the final approval is carried out by the product owner.

In summary, let’s remember that:

• The process of authorizing, delegating, executing, and approving work packages serves as a connection between the project manager and the work package leaders.
• From the project manager’s point of view, the responsibility lies in authorizing and delegating the execution of work packages and their approval, following respective final quality evaluation processes.
• From the viewpoint of the work package leader, the responsibility lies in accepting the delegation of the work package, managing the execution of the work, including internal testing by the development team. The work package leader is also responsible for reporting progress to the project manager and presenting the complete work package for approval and final delivery to the project manager.

 

 

3.5 Lead and manage the project team to achieve project objectives

The word “leadership” can evoke a variety of images, such as a politician, an explorer, an executive, a combatant, a human rights activist, and others.

Leadership has different meanings for different people around the world. For example, many people associate a positive value with a leader, but the German word for leader, “der Führer,” elicits negative connotations.

This section focuses on “individual leadership” and addresses leadership in the workplace rather than in other areas.

There are many definitions of what “leadership” is.

• Peter Drucker, considered one of the fathers of modern management, says, “A leader is someone who has followers.” Without followers, there is no leader. But isn’t this a bit simplistic? Isn’t it tautology?
• Warren Bennis, an expert in leadership and senior advisor to several North American presidents, defines it as: “The ability to turn vision into reality.” Leadership is related to changing the status quo, but where do “others” fit in this definition?
• Bill Gates defines leaders as: “Those who empower others.” And yes, “those others” are necessary for there to be leadership, but shouldn’t we achieve something with that empowerment?
• Dwight D. Eisenhower, Supreme Commander of the Allied Forces in Europe during World War II and later President of the United States, provides the following definition: “Leadership is the art of getting someone else to do something you want done because they want to do it.” A notable definition from a five-star general, which concludes that, ultimately, leadership is based on voluntary followers.

There are several classifications of leadership styles, with the more classic ones elaborated in the 1930s using categories such as participative style, autocratic style, and laissez-faire style. More recent categories include servant leadership and transformational leadership.

• A participative style involves the contribution of others and results in decisions that reflect various viewpoints.
• An autocratic style emphasizes the need to inform everyone, not only about the goals to be achieved, but also about how to achieve them.
• Laissez-faire, or “do as you please,” is a more relaxed style that allows teams to explore their own creative strategies.
• Servant leadership refers to self-managed teams, where the leader’s role is to remove obstacles for the team.
• A transformational style focuses on the need to inspire and motivate, embrace change, ethical values, clear rules, the common good, open communication, coaching, and assumption of responsibility.

Please search the web for additional information on leadership styles. There are many articles on this topic.

From the perspective of a project manager, we face two basic scenarios. The first is having to lead and direct a team of experts who may have more advanced technical skills in the subject than the project manager.

The second is leading and directing a team of team leaders, some of whom may have a higher hierarchical rank in the functional organization than the project manager. Sometimes, these team leaders belong to external organizations, such as suppliers. These individuals may be senior directors in their own organization but serve on the project as work package leaders and, therefore, be accountable to the project manager in the project context.

Therefore, the leadership role of a project manager cannot depend solely on positional legitimacy, although the project charter names and empowers the project manager to lead the team and direct the project work.

So, what are the possible sources of power for a project manager or for any other role or position in an organization?

Sociology defines power as the ability of a person or group to influence the actions, beliefs, or decisions of other individuals or groups. The sources of power are the resources or characteristics that enable someone to exert influence over others. The most well-known types of power or sources of power are as follows:

• Positional Power: Also known as formal power or authority power, it derives from the hierarchical position or role that someone holds in an organizational structure. This source of power is based on the perception that people in certain positions have the right to give orders and make decisions that must be obeyed.
• Reward Power: It refers to a person’s ability to reward others for fulfilling their demands or desires. These rewards can be tangible, such as salary increases or promotions, or intangible, such as public recognition or approval.
• Coercive Power: This type of power is based on the ability to apply punishments or negative consequences to influence the behavior of others. Those who possess coercive power can use threats or sanctions to achieve compliance.
• Referent Power: It derives from admiration, respect, or a desire to emulate a person or group. Those who possess referent power exert influence due to the identification that others feel toward them and their desire to earn their approval.
• Expert Power: This type of power is based on the knowledge, experience, or specialized skill of a person. Those considered experts in a particular area can influence others through their competence and ability to solve problems.

These sources of power are not mutually exclusive and often overlap in a project. For example, the project charter confers a certain degree of positional power to the project manager. Through the project management plan, it’s possible to establish a bonus system that increases the project manager’s reward power. Phase closure processes provide opportunities for performance evaluation, which in turn increases both reward power and coercive power. If the project manager holds a professional certification in project management and enjoys a good reputation gained from successfully leading numerous previous projects, this grants them a high level of expert and referent power.

The more modern category of transformational leadership is based on the charismatic element of referent power and includes the ability to “articulate a vision of the future,” “the ability to motivate,” and inspire people, as well as coaching others.

Articulating a Vision of the Future

In the context of project management, an excellent way to create and articulate a vision of the future is to use the project purpose statement and the goal statement created at the beginning of the project. The project purpose and goal statements indicate to everyone what we are trying to achieve and why. In a few sentences, they provide an overview of the problem we are going to solve or contribute to solving and convey a vision of the future.

Your project may be establishing a fish farm, a seminar center, or a system for handling incoming phone calls. Those key deliverables may motivate certain individuals. But other people may feel much more motivated by knowing and remembering that they are contributing, for example, to combating poverty, preventing abuse of young girls, increasing customer retention, thus enabling better financial results, securing jobs, and enabling higher salaries.

There is a well-known story about the reconstruction of St. Paul’s Cathedral in London in the 17th century. It is said that the architect, Christopher Wren, observed three masons working at quite different intensities—one working slowly, another working at a moderate pace, and another working hard and fast. When Christopher Wren asked them what they were doing, the first mason replied, “I’m a mason and I work to feed my family.” The second mason responded, “I’m a mason and I’m building a wall.” The third mason responded with pride in his voice, “I’m a cathedral builder. I’m rebuilding the grand St. Paul’s Cathedral.” Needless to say, the third mason became the leader of the mason team due to the vision of the future he could convey to the team.

Motivating

A compelling vision is the foundation of leadership. But it is leaders’ ability to motivate and inspire people that helps them realize that vision.

Rewards are a powerful motivating factor. And it doesn’t have to be money or just money. In fact, research shows several negative side effects of money as a motivating factor. Rewards can also be recognition. Rewards and incentives can be material, but they can also be emotional, or they can invoke an aspiration that will materialize in the future.

If the project manager has credibility and charisma, they will find it easier to motivate and inspire the people they lead.

There are many opportunities to motivate or demotivate a team: clearly communicating roles and responsibilities is a part of it. This is what we do with the organization chart, with work package definition and delegation, and with explanations in kickoff meetings.

Another opportunity to motivate comes when defining ambitious yet achievable objectives. Ambitious yet achievable objectives and goals are motivating. Objectives and goals that are too ambitious and therefore unattainable are demotivating.

Other means of motivation include providing prompt and accurate feedback, showing respect for others; it’s not just what you say, but how you say it. Being an approachable human being who acknowledges their own weaknesses and mistakes. Always telling the truth, using transparent communication, and quickly solving problems. Most of these characteristics of true leaders translate into trust, an essential intangible asset that is built “step by step” but can be lost very quickly. Without trust, there is no leadership.

Much could be said about cross-cultural aspects. Being a leader or manager of a Japanese team is not the same as leading a Brazilian team. Different behavior is expected of a leader in a French and Dutch environment.

In other sections, we will delve into two other aspects of team motivation using communication, which will be covered in the “managing communications and stakeholder engagement” section, and using coaching, which is part of the “developing the team” section.

Leadership vs. Management

This section is titled “leading and directing the team.” Up to this point, we have addressed leadership, meaning the “leading the team” aspect. A shared function between the project manager and the project sponsor.

Naturally, we also need technical skills in managing the processes and individuals involved in achieving the goal.

What do these management activities and skills consist of? In short, we can say that the management activities of a project focus on the activities we have described throughout this course for project initialization, planning, execution, monitoring and controlling, and project closure, for each of its phases and each of its work packages. The lesson at the beginning of the course summarizes all of this in a few minutes. Please review that section as needed.

In summary, let’s remember that leading and managing are not identical concepts.

When it comes to leading the team, it is the art of arousing in others the will to do what needs to be done because they want to do it. These are interpersonal skills, also known as soft skills.

When it comes to management activities, it’s about determining the problem, or the part of the problem, that we are going to solve. Establishing how we will solve it. Creating an action plan to do so, as well as executing and keeping it up to date. And all of this, step by step. These are technical management skills.

 

 

3.6 Develop the project team

This section focuses on boosting team development through various stages to improve competencies, interactions, and the overall team environment, ultimately enhancing project performance.

Teams typically progress through several stages, as outlined in Bruce Tuckman’s model from the 1960s: forming, storming, norming, performing, and adjourning.

• The forming stage marks the initial formation of the team, where individuals come together as a collective unit.
• During the storming stage, conflicts and frictions arise as team members start working together.
• In the norming stage, team members begin to resolve their differences and appreciate each other’s strengths.
• The performing stage, which not all teams reach, is characterized by a high level of productivity. Team members have a clear understanding of their tasks, roles, and structured processes, requiring minimal intervention from the project manager, who steps in only when necessary.
• The adjourning stage occurs when the team is disbanded, and individuals are reassigned to other projects or roles.

It’s important to note that team development is not always a linear progression, and teams may move back and forth between stages. Changes in business direction, objectives, activities, roles, or team composition can disrupt the existing group dynamic.

Let’s delve into each stage and reflect on the leadership role within them.

During the forming stage, establishing clear objectives for the group is a priority. The project manager can utilize existing project documents, such as the project charter. In the initial team formation, which often consists of the core team developing the project management plan, the project charter serves as a guiding document. For subsequent teams formed in different project phases, the project management plan, along with the phase-specific planning and work package definitions, provide the necessary information. These documents already encompass the key elements typically found in a team charter, including the project context, objectives, team composition, roles, activities, reporting structure, and resource allocation.

Explicit agreement on “team values” may need to be established as they are not typically included in project management documents and may vary for each individual team. Here are some examples of team values that can serve as a foundation for collaboration:

• We prioritize timely communication and regularly share project status updates.
• We base our decisions on data and information rather than wishful thinking.
• We respect each other’s opinions and actively listen without interrupting.
• All team members are encouraged to express their views, and silence is not seen as conformity.
• Instead of making excuses or assigning blame, we focus on identifying and resolving the root causes of dysfunction.

These values can be customized based on the team’s preferences and objectives.

During the forming stage, a leader can also help team members establish or share their personal goals and explore how their participation in the project aligns with those goals.

Additionally, forming stage activities can include team-building outings such as lunches or dinners, as well as team-building games during dedicated team-building days. For remote team members, virtual onboarding exercises can help foster a sense of unity and commitment to the project goal.

Moving into the storming stage, team members begin to work through their relationships, often experiencing power struggles and disagreements. While storming can hinder progress and decision-making, it also provides opportunities for the team to communicate and grow.

In this stage, the project manager plays a crucial role in providing coaching and interpersonal skills support to the team. Although project managers may not be certified professional coaches, they can engage in informal coaching. It’s important to distinguish between the management role and the coaching role. Offering advice or direction should not be labeled as coaching. Instead, as a coach, it’s more effective to ask questions and summarize what you hear, practicing active listening.

Detecting coaching situations requires attentiveness. Here are some tips:

• Explore team members’ current and upcoming workloads, as they may not recognize their own stress or overload.
• Develop sensitivity to changes in behavior and body language, which can indicate emotional shifts.
• Pay attention when team members are preparing for significant or challenging tasks.
• Another coaching opportunity arises when a team member receives unhelpful feedback in a meeting.

When identifying coaching opportunities, offer support without imposing it. Recognize that the timing may not always be ideal, so ask if it’s a good time for a coaching conversation. These conversations can occur formally or informally, such as during a break, at the end of a meeting, or while traveling together. The spirit of informal coaching should be spontaneous, efficient, and professional.

Here’s an example of the type of questions to ask in an informal coaching conversation:

• You: Would you like to talk about what happened there? I’m not referring to the specifics but from a coaching perspective. Maybe we could grab a cup of coffee and discuss it.
• Team member: If you think it would be helpful.
• You: More so from the perspective that you might find it beneficial.
• Team member: Well, … explanations about the conflict…
• You: I understand. How were you feeling in that situation?
• Team member: Explanations…
• You: What would you like to do about it?
• Team member: Explanations…
• You: Let me make sure I understand you correctly. So, you’re saying… [summarize what you’ve understood]
• Team member: No, no, I mean… explanations
• You: Ah, I got it now. You want this and that. Can you see any other options?
• The conversation continues with more questions and active listening, concluding with:
• You: Thank you for sharing. Is there anything else you’d like to discuss?

Remember that coaching is distinct from managing. The essence of coaching lies in helping the other person find their own answers through questions and active listening, while summarizing their responses.

The storming stage is a critical phase that can either make or break a team. A leader plays a significant role in creating a safe environment where team members feel comfortable sharing their ideas. It is essential to revisit the previously mentioned examples of “team values.” The team leader should act as a guardian of these values and intervene when they are disregarded. If the team is moving in the right direction, members will naturally uphold these values. For instance, if someone displays disapproval through body language during a meeting, the leader can step in and remind everyone of the agreed-upon team values.

Fostering trust among team members is also important. Encourage team members to ask for help and establish a culture of peer support. Some Agile teams have found success with pairing developers, where individuals support each other in their work. The aim is to promote a climate where people are comfortable asking for, giving, and accepting help from their peers.

The team leader may need to facilitate the participation of quieter team members and prevent dominant individuals from overshadowing others. Ensure that everyone’s point of view is sought and heard.

Once the storming stage has passed, you will have a functioning team.

It is worth noting that interpersonal skills such as conflict resolution, problem-solving, decision-making, communication, and negotiation are essential for any manager. We will cover some of these skills in the sections on “manage communications and stakeholders’ engagement” and “manage issues and changes.”

During the norming stage, team members start to resolve their differences, appreciate each other’s strengths, and respect your authority as a leader. As they become more familiar with one another, team members will feel more at ease seeking assistance and providing constructive feedback. They will share a stronger commitment to the team’s objectives and make notable progress.

As a leader, you can support this stage by engaging in team-building activities. These activities are not limited to the norming stage but can be utilized throughout the team’s development lifecycle. Some examples of team-building activities include cooking together, nature rallies, creating a collective terrarium, Lego championships, a criminal investigation game, brain challenges, or creating a collaborative artwork. You can find real examples of team-building workshops by referring to the hyperlink: https://portesdesiris.ch/en/corporate/teambuilding.

Additionally, we recommend a combination of training sessions and team-building activities, such as a fun and educational project management simulation game that can be completed in one day or two half-days, even in a remote setting. Further information can be found through the following hyperlink: https://learnplace.org/sw-en.

If the team reaches the performing stage, you can allocate more time to other tasks, such as supporting new teams. In a performing team, you have the opportunity to delegate more complex work packages instead of individual activities.

There are several ways to celebrate team achievements, and this should be done not only when a team is about to disband but throughout the project whenever significant milestones are accomplished. The simplest gesture is verbal recognition, but you can also share the achievements with others through emails or on the company website, gather the team and applaud their accomplishments. Sometimes, a thoughtful gift may be appropriate, or you can organize a team outing to celebrate. If team members have put in unpaid overtime, consider offering an extra holiday as a form of reward. The concept of rewarding and celebrating success can even evolve into award ceremonies or a hall of fame.

The adjourning stage is reached when the team is disbanded, and individuals are redeployed. This stage can occur at various points throughout the project lifecycle as work packages and milestones are completed. People who prefer routine or have developed close working relationships may find this transition challenging. Coaching can be beneficial during this phase.

As a leader, you can boost team members’ confidence and career prospects by praising their accomplishments during company meetings. Additionally, offer to provide recommendations and references if they are moving on to new opportunities.

Training team members is another crucial aspect of improving their competencies. Various training methods can be employed, such as classroom sessions, online courses, or on-the-job training facilitated by experienced project team members. Scheduled training should align with the resource management plan. Unplanned training can occur based on observations, conversations, and project performance appraisals conducted during the management of the project team. Training costs can be included in the project budget or supported by the performing organization if the acquired skills can be beneficial for future projects. Training can be conducted by in-house trainers or external experts. This training class serves as an example of a blended learning approach, combining different methods to acquire knowledge and develop skills and competencies.

In summary, team development involves enhancing competencies, fostering positive team interactions, and creating a conducive team environment. A new team typically progresses through the stages of:

• Forming
• Storming
• Norming
• Performing
• Adjourning

Coaching and interpersonal skills are vital in supporting team development, while training team members plays a crucial role in improving their capabilities.

 

 

3.7 Manage communications and stakeholders engagement

This section explains the tools and techniques to be used for effective and proactive communication in your project.

Proper communication is a critical success factor in any project. If key stakeholders do not feel adequately informed, there is a high probability of encountering problems. This includes team members reporting to work package leaders, work package leaders reporting to the project manager, and the project manager communicating with various stakeholders. Regular meetings and reports are typical tools to communicate progress and manage expectations. Larger projects or projects involving a culture change in the organization will require a more comprehensive approach as defined in the subsidiary management plans for communications and stakeholder engagement.

Let’s start with communications management in small projects. Typically, they only require basic status reporting. If the project manager is actively involved in the project, they likely have a good understanding of the overall status. If the stakeholders consist of the sponsor and a small group of people, their communication needs may be fulfilled through regular meetings.

If the project manager is not deeply involved in the project work, for example, because they are managing multiple small projects, they may require a more formal status reporting process from the project team to the project manager, as well as reporting from the project manager to stakeholders. The following process would be typical:

• Project team members provide a weekly status update to the project manager. The project manager consolidates the individual status updates into a project report and shares it with the sponsor and other stakeholders on a weekly or bi-weekly basis.
• The project team and the project manager attend status meetings. These meetings should review the project baseline versus actuals, as well as discuss open issues, change requests, and risks.

The frequency of these meetings depends on the project’s duration and communication needs. For example, if the project takes three weeks to complete, the team may meet twice a week. If the project is eight weeks long, weekly meetings may be more appropriate. The project manager, sponsor, and other stakeholders involved in a small project should agree on the meeting frequency.

If the team is using an Agile lifecycle, such as the scrum method, they would not write extensive reports but instead meet every morning for a 15-minute stand-up meeting called a daily scrum. In this meeting, team members answer three questions: What did you do yesterday? What will you do today? Is anything blocking your progress? Any identified blockers become action items for the project manager (referred to as the scrum master in the scrum method). The primary function of a scrum master is to remove obstacles for the team. Additionally, the sponsor, known as the product owner in Agile, receives a product presentation at the end of every short development cycle, typically lasting two weeks.

In a larger project, reporting and meetings are obviously required, but other forms of communication are also considered, and the level of sophistication in engagement-building measures increases.

The first step is always to determine the key stakeholders. We conducted an initial round of stakeholder identification and classification as part of the project definition, which was documented in the project charter. During the planning phase, especially in the detailed planning phase, we update the stakeholders’ register as deliverables are planned in more detail and decomposed into work packages. This may result in changes to the stakeholders’ composition, with new stakeholders being identified.

The process of classifying stakeholders can utilize various matrices, such as the importance/interest matrix with three levels: low, medium, and high for both criteria.

To determine the importance of a stakeholder, you need to assess their significance to the success of your project and the potential impact on the project if the stakeholder had no involvement at all. If the stakeholder’s engagement is critical, they would be placed in the highest priority lane.

To determine their level of interest, engagement, or awareness, as well as to understand their communication needs, it is necessary to have conversations with the individuals. In some cases, a stakeholder may have specific expectations or requirements from the project and seek information and involvement. In other cases, the stakeholder may have limited interest in the project but still desires to be kept informed. Again, each level of interest can be categorized as low, medium, or high.

The outcome of this process will be a matrix with nine quadrants, providing guidance for your action plan in terms of communication and engagement efforts.

	Interest / Engagement / Awareness
Importance		Low	Medium	High
	High	4	2	1
	Medium	7	5	3
	Low	9	8	6

Your priority should be to address quadrants 4 and 7:

• The first priority is to focus on stakeholders in quadrant 4. They are crucial for your project but currently disinterested or unaware. Your goal should be to move them towards quadrant 1 or, at the very least, quadrant 2.
• The second priority is to engage stakeholders in quadrant 7. They are also disinterested or unaware, but of medium importance to your project. Your aim is to move them towards quadrant 3 or, at minimum, quadrant 5.

It is generally acceptable to maintain stakeholders in quadrants 2 and 5 without significant impact on your project. Stakeholders in quadrants 9, 8, and 6 can also remain where they are. Stakeholders in quadrant 6 can be particularly helpful during the project’s definition, planning, and testing phases.

Now, let’s discuss the communication options and engagement-building measures you can employ. These options can be categorized as mandatory, informational, and marketing:

• Mandatory communication includes reports required by law and company regulations. These reports are sent without waiting for someone to request them. It also encompasses reports and meetings defined as mandatory in your communication plan, such as reporting to the project manager and from the project manager to the sponsor and steering committee, if applicable. Meetings between the project manager and the sponsor or steering committee likely fall into this category as well.
• Informational communication provides access to information but requires active engagement from the recipients. Examples include a project website or webpage and a frequently asked questions (FAQ) section.
• Marketing communication aims to generate enthusiasm and goodwill for the project and its deliverables. This type of information is actively pushed out to the appropriate audience. Examples include project newsletters, regular one-on-one meetings with key stakeholders, traveling roadshows to explain the project and its benefits, testimonials highlighting the value of the project’s deliverables, a project acronym and slogan to create a positive image, celebrations to mark the completion of major milestones, publicizing accomplishments, and project-related merchandise like pins, pencils, frisbees, cups, T-shirts, and more. Think of it as a marketing campaign.

If the project is controversial, involves a cultural shift, or has political implications, the positive aspects of marketing communication become increasingly critical. Proactive communication is necessary, as opponents of the project will likely be proactive in their opposition.

A potential mix of communication and engagement measures could include the following:

• Daily walk-arounds by the project manager, particularly if the team is co-located.
• Weekly “greetings” from the project manager to the project team via email, WhatsApp video, or in a chatroom.
• Weekly reports to the project manager using a standardized format.
• Bi-weekly meetings between team members and the project manager.
• The steering committee receives an executive briefing and provides strategic direction every other month.
• The project sponsor receives a personal briefing monthly, along with a weekly, bi-weekly, or monthly report according to their preferences.
• A quarterly newsletter is sent to the entire sponsor organization for informational and marketing purposes.
• Celebrations of intra-phase milestones with the project manager and the development team of that phase, with the sponsor participating in phase gate celebrations.
• For external stakeholders in quadrants 4 and 7, engagement-building measures could involve information events to explain the project’s benefits, including the participation of reference individuals from similar projects, and the quarterly project newsletter.
• For selected external stakeholders in quadrant 4, engagement-building measures could include their involvement in requirements definition and quality reviews of deliverables.

A standard status report typically includes the following items:

• Accomplishments in relation to the assigned activities on the schedule. Green, yellow, and red indicators are welcomed.
• Comments on work that should have been completed but is not, along with its impact on interfaces. This section aims to avoid excuses and focuses on corrective measures.
• Outlook on the work scheduled for the next reporting period.
• Issues encountered and recommended or implemented courses of action.
• Scope change requests.
• Newly identified risks.
• Miscellaneous updates.
• Appendices, if needed, to provide more detailed information to stakeholders who require more granular data without overloading the main body of the report.

Now, let’s discuss status meetings:

• The duration of status meetings should not exceed one hour. Problem-solving discussions should be conducted in separate meetings. It is recommended to have a standard agenda that aligns with the items included in the standard status report (excluding appendices, naturally).
• Meetings should start on time, regardless of latecomers. However, it’s important to note that punctuality customs may vary across different cultures. For instance, being one minute late in a Swiss meeting might be considered a catastrophe, whereas being 15 minutes late in other environments may still be deemed acceptable.
• Action items should be captured and followed up on, for example, by tracking them as tasks in a collaboration tool.

Effective document management is a crucial aspect of communication management. When multiple individuals participate in the development of project documents, maintaining control over versions can be challenging. Collaboration tools can greatly assist in this regard, especially when the project involves stakeholders who do not have direct access to your company’s server. Additionally, encouraging your team to name documents using their initials and the date can help clarify the authorship and review process of each version. For example, a document named “2021.10.27 document xy MN OC document xy” signifies that MN originated the document and OC reviewed it on October 27, 2021. The ISO date format provides clarity and reduces confusion. Another example, “2021.10.29 document xy MN GS,” indicates that GS also reviewed the document but did not incorporate OC’s feedback. Lastly, “2021.10.30 document xy MN OC GS MN” signifies that MN, the original author, consolidated the feedback provided by OC and GS in a newer version on October 30.

If your team operates in different time zones across continents, using Coordinated Universal Time (UTC) for scheduling meetings can help avoid confusion. UTC, also known as Greenwich Mean Time (GMT), serves as the reference time for all other time zones and remains consistent throughout the year, unaffected by daylight saving time changes. It is advisable to manually indicate the meeting time as “the meeting takes place at UTC 14:30” or a similar format to mitigate potential scheduling errors when translating between time zones. To prevent date ambiguity, using the ISO format (e.g., 2021.01.12) clarifies that “01.12.21” refers to January 12, 2021, instead of December 1.

Finally, let’s discuss proactive and reactive communication. Reactive communication occurs when someone asks you for information, and you respond accordingly. While this is considered a minimum requirement of polite behavior, it’s worth noting that some people perceive no response as an answer in itself. The proactive communication style advocated in this course emphasizes the value of informing stakeholders before they ask for information. By the time someone reaches out to inquire about the project’s progress, it may already be too late to provide the necessary updates.

In summary, project communication should be tailored to align with the specific characteristics of the project. For small projects, communication efforts can be relatively modest, while larger projects require more extensive and comprehensive communication strategies.

It is crucial to prioritize and focus attention on key stakeholders, particularly those who may be unaware, disinterested, or disengaged. Additionally, it is important to consider opponents of the project and proactively address their concerns or objections through effective communication.

 

 

 

 

3.8 Assure quality

This section explains the distinction between quality assurance and quality control, with a focus on quality assurance.

Let’s begin with the definition of quality according to the ISO 9000 standard: “Quality is the degree to which a set of inherent characteristics fulfills requirements.” The key aspect here is the fulfillment of requirements.

It’s important to note that the degree of fulfillment of requirements, which determines quality, is not the same as the “grade” assigned to products with the same functional use. For example, eggs of grade XL are larger than eggs of grade S, but this does not necessarily imply higher quality. If an XL egg is cracked, its grade may be high, but its quality is low if one of the quality attributes of eggs is that the eggshell should not be cracked. Similarly, a car may possess impressive features such as accelerating from 0 to 100 in 3 seconds, having a built-in champagne refrigerator, and the ability to take off and fly. However, if one of the must-be requirements was for the car to consume 5 liters of fuel per 100 km and it actually consumes 8 liters, it fails to meet an important performance quality attribute, and its quality is lower in comparison to a simpler car that meets efficiency requirements.

In project management, two aspects of quality must be considered.

The first is quality assurance, which involves implementing standards, policies, and processes established in the quality management plan to ensure that the key deliverables and their components satisfy customer requirements. This aspect focuses on producing quality and is the main focus of this section.

The second aspect is control quality, which pertains to measuring how well deliverables meet functional requirements and quality attributes. This aspect will be addressed in the sections related to project control. It’s important to remember that quality assurance and quality control work in parallel. Not only must the key deliverable of a project comply with functional requirements and quality attributes, but each work package should also have clearly defined acceptance criteria.

The implementation of standards, policies, and processes aimed at generating deliverables that meet requirements must be audited. This auditing function can be performed by an audit department, a project management office, or an external auditor. Additionally, the project manager plays a role in quality assurance by examining the process used to create the product rather than solely focusing on the product itself. For example, if someone mentions that a design document was rushed and not reviewed by anyone, it is apparent that the document is likely to be defective, even without seeing or fully understanding its content.

A broader perspective of quality assurance goes beyond auditing and encompasses quality generation during the design, production, testing, integration, and deployment of the key deliverable and its components. It involves the quality of raw materials, equipment, software, processes, as well as the organizational culture and work habits of all individuals involved, including management, suppliers, and even the customer.

The concept of total quality management (TQM) provides a valuable approach. TQM is a management philosophy that originated in Japan and strives for high quality at all levels through continuous improvements. It is closely related to the idea of Kaizen, which encourages individuals at all levels of the organization to identify inefficiencies, suggest improvements, aim for zero defects, and do things right the first time, rather than discovering errors later and requiring rework, which is considered wasteful.

The lean management philosophy also emphasizes the elimination of waste wherever possible. Waste, in this context, refers to any activity that does not add value for which the customer is willing to pay. For example, properly attaching a door to a car during manufacturing is value-added, while any action required to fix a poorly attached door is considered waste. Disorder and repeatedly encountering the same obstacles also lead to waste. Blaming others while denying one’s own responsibility is wasteful. Spending time on excuses during performance reviews is wasteful. Large inventories are seen as waste, as are unfinished tasks that consume resources without producing value. A lean management philosophy strives to limit the number of items started simultaneously to a level that can be completed, rather than overwhelming production capacity with numerous unfinished tasks. A simple everyday example would be taking on too many tasks at once, resulting in many unfinished tasks that could have been completed sooner—these unfinished tasks represent waste.

Another aspect of producing quality in project management is team motivation. Motivated team members make fewer errors, detect more errors, help others improve, and work faster and more effectively. If necessary, refer back to the sections on leading the project team, developing the project team, and managing communications and stakeholder engagement.

Creating teams with the right skills, developing those teams through training and coaching, and fostering a culture of quality are crucial factors in producing good quality work rather than having to correct poor quality later.

An organizational quality framework and a culture that prioritizes quality, supported by effective leadership, are indispensable. It is challenging for a project to achieve high quality if it is executed within an organization accustomed to producing low-quality outcomes. The project manager can contribute by utilizing a structured project management approach, such as the one explained in this course, which is based on the ISO standard for project management. Implementing such an approach would involve having a quality management plan, well-defined and measurable requirements, acceptance criteria for all work packages, motivated team members, engaged sponsors, quality audits, and measured quality attributes. However, if the organization does not endorse these principles and views them as a waste of time and money, the project manager will face difficulties in delivering a high-quality product and achieving the desired outcomes.

As mentioned earlier, audits are a key tool for ensuring quality. There are also various other quality tools and techniques, including checklists, process analysis, decision-making frameworks, and problem-solving techniques. Let’s delve into two of these techniques in more detail: cause and effect diagrams and Pareto analysis.

Cause and effect diagrams, also known as fishbone diagrams, help identify the factors contributing to quality problems or any type of problem. During a brainstorming session, the team identifies potential causes for an effect or problem and organizes them into relevant categories. This process forms the basis of mind mapping tools.

Pareto analysis utilizes statistical analysis to identify the critical few factors that should be prioritized, as they are responsible for a significant majority of quality issues noticeable on the surface. You may be familiar with the 20/80 rule discovered by Pareto, which implies that 20% of the causes are responsible for 80% of the problems in quality-related issues.

By implementing quality assurance practices throughout project execution, you will generate quality reports, trigger corrective measures that impact changes to the project management plan, address issues, manage newly identified risks, and learn from encountered problems.

In summary, it is important to understand that quality refers to compliance with requirements and should not be confused with grade.

Quality assurance and quality control are distinct concepts.

Quality assurance involves implementing standards and policies through processes, inputs and outputs, tools, techniques, equipment, and behavior to generate quality throughout the entire development life cycle. It focuses on doing things right the first time, eliminating waste in all processes, involving everyone, and keeping the customer’s needs at the forefront.

To achieve high-quality outcomes, strong organizational leadership, appropriate frameworks (including cultural aspects), and highly motivated and skilled teams are essential elements.

 

 

3.9 Implement approved changes and corrective actions

This section discusses the implementation of activities necessary to address plan deviations, resolve issues, or accommodate approved changes. While project work is being executed, controlling activities are performed in parallel to ensure that the project is progressing according to the plan. Deviations from the plan are common, issues arise, the need for changes becomes evident, and new risks emerge. In response to these situations, the project management team develops corrective and preventive measures that may impact the project management plan. These controlling activities will be covered in the lesson on “managing issues and changes” within the sections about “controlling a project.”

The outcome of these controlling activities includes approved changes, as well as corrective and preventive measures that need to be incorporated into the scheduled activities.

The transition from execution to controlling, and then back to execution, is a conceptual process. As a project manager, you may experience it as a seamless flow. For example, while performing project work (execution), you encounter an issue. Mentally, you switch to controlling mode to evaluate possible courses of action and determine a solution, which could be a corrective measure that may or may not impact baselines. If it does impact the project baseline, a formal change management process is initiated, resulting in an approved change or corrective and preventive measures.

During this process, you are still in a “controlling mode” mentally. Once the change request is approved or the preventive or corrective measures are decided, you continue your mental journey from controlling to planning processes, incorporating the decided measures into the activity list.

Some measures may involve defining and planning work packages in more detail and assigning resources. Others may trigger secondary risks that require analysis and a response. Some measures may necessitate changes to the scope, schedule, or cost baselines, or all three. The implications of changing baselines were analyzed while in controlling mode, leading to a change request. Once the change is approved and resulting activities are planned, you transition back to “execution mode” mentally to implement what has been decided and planned.

At this stage, we are in the process of implementing approved changes, preventive measures, and corrective measures.

The specific type of measures implemented depends on the affected management areas and the available options in the given context. As mentioned before, identifying plan deviations and determining appropriate responses to these situations occur in the controlling processes, which will be covered in the lessons on controlling. However, let’s consider an example here to illustrate the types of measures that could be implemented during execution as a result of approved changes, corrective actions, and preventive measures identified during controlling.

Suppose, during the controlling phase, it is discovered that work package 4.7 is 10% behind schedule after the first 2 weeks of the planned 20-week construction work. Through problem resolution techniques, it is determined that the delay is due to the behavior of new revolutionary materials chosen for their extraordinary resistance to particles X. However, these materials do not perform as expected under the high temperatures at the construction site during the day. Consequently, the development team has been working only during night shifts when the temperature drops below the critical level.

In this situation, several options can be considered:

• Option A: Changing materials, which would impact quality attributes and cost an additional 300,000 Euros.
• Option B: Continuing construction with the same materials but creating an artificial temperature-controlled environment, which would take 4 weeks to build and cost 200,000 Euros.
• Option C: Continuing without changes, resulting in an extended construction period of 40 weeks instead of the planned 20 weeks. This work package is on the critical path, meaning that a delay in this work package would cause a delay in the entire project. The contract includes penalties of 200,000 Euros per week of delay. However, the team believes there is a 50% probability that other activities on the critical path can be compressed to compensate for the delay in work package 4.7.

The control account to which work package 4.7 belongs has a reserve of 1 million Euros and 10 weeks specifically allocated for technical risks.

After analyzing all three options, the team decides to go with option B: continuing construction with the same materials but creating an artificial temperature-controlled environment, which would take 4 weeks to build and cost 200,000 Euros.

Does this decision impact the project baseline and require a formal change request process? No, it does not. There are contingency reserves available to cover such situations, and they would be utilized accordingly.

The project manager logs the case in the issues log and determines that option B is the resolution (still in “controlling mode”). This decision triggers a new work package for the construction of the artificial temperature construction environment (the project manager remains in controlling mode). When the project manager approves the change by signing the change log, she transitions from controlling to planning mode.

In planning mode, the project manager defines the new work package for building the artificial temperature construction environment and delegates it. She updates the work breakdown structure (WBS), schedule, and cost estimates during the planning process. And just like that, the mental journey shifts from planning back to execution, and a construction team begins building the artificial temperature construction environment.

As part of managing communications during execution, the project manager includes this case in project reports and meeting agendas. If the project manager is following the practices learned in this course, standard reports and meeting agendas would have dedicated sections to address issues, changes, and risks. The case would be recorded in the issues and change logs and become part of the reporting and meeting agendas.

If the team had chosen option A, changing the material and impacting quality attributes at a cost of 300,000 Euros, it would need to be escalated to the change control board. The change might involve new engineering work, different equipment and tools, and potentially additional team members to work with the new materials. These approved changes and corrective measures would need to be planned and implemented. Reports and meeting agendas during execution would address this item.

If the team had chosen option C, continuing without changes and attempting to compress other activities on the critical path to compensate for the delay in work package 4.7, the corrective measures to be planned and implemented would involve schedule compression techniques (to be explained in the section on controlling the schedule), such as working overtime or allocating more resources. This may impact cost estimates if overtime pay is required. Team motivation could also be affected if the team must work overtime for an extended period. Additionally, the risk exposure of the project would increase, considering the team’s belief that the probability of compensating the delay is only 50% and there are contract penalties. Reports and meeting agendas during execution would include this item.

In summary, planning, executing, and controlling are not linear processes but repeating cycles that interconnect all areas of project management. To address issues, risks, and deviations encountered during execution, the project manager, sometimes with the involvement of project governance, develops changes and corrective measures using controlling processes. These measures then go through planning processes before being implemented in execution.

Indeed, the life of a project manager can be both exciting and challenging!

 

 

3.10 Implement risk responses

This section focuses on implementing the planned responses to risks that were identified and analyzed during the planning stage. It is the natural progression of the risk management processes: risk planning, risk identification, risk analysis, and planning the responses. The purpose of this lesson is to explore the implementation of these risk responses.

To illustrate, let’s continue with the example of a project that aims to implement an online solution to enhance transaction transparency. During the planning processes, the risk register was assessed, resulting in the following status:

Risk Name	Risk Nr	Prob. 1 to 5	Impact 1 to 5	Criticality	Strategy	Measure
Sponsor	6	5	12	60	Mitigate	Nominate delegated sponsor
Functional requirements	1	5	12	60	Mitigate	Requirement workshops
Supplier of tracking tool	2	4	9	36	Avoid	Replace the supplier
e-Payment	3	5	5	25	Transfer	Hire triangular payments supplier
Online help	4	3	7	21	Accept	Reserve of 2 weeks and 25 K (*)
Training sessions	5	4	4	16	Accept	Reserve of 1 Week and 35K (**)

(*) Probability medium: 3 = 31%-50% / Impact on time (low) 1-4 weeks; 50% of 4 weeks = 2 weeks / Impact on cost (low) 10K-50K; 50% of 50K = 25K

(**) Probability high: 4 = 51%-70% / Impact on time (very low) 1 Week x 70% = 0,7 Week rounded up to 1 Week; / Impact on cost (low) 10K – 50K; 50K x 70% = 35K

The identified risk responses that need to be implemented are as follows:

• Obtain a delegated sponsor.
• Obtain better requirements.
• Obtain a replacement supplier for the tracking tool.
• Obtain a triangular payments service.

Build reserves for contingencies to address risks that are being actively accepted.

Reserves for contingencies regarding risks 4 and 5 have already been established as part of the project management plan, which is currently being executed.

Now, let’s discuss how we can obtain each of these deliverables. Just like any other deliverable, we have two options: we can either make it or buy it. The specific development lifecycle of each deliverable will depend on its nature and the circumstances surrounding it.

Let’s delve into each of these deliverables and create example development lifecycles to illustrate their implementation.

Number one: Obtain a delegated sponsor.

To achieve this, we need to secure agreement from the sponsor to nominate a delegate. This involves a negotiation process where we clarify the goal of having a delegated sponsor and ensure active sponsorship for the project. Building a good relationship with the sponsor, who is likely a senior manager, is also important. The mere conversation about the risk with the sponsor may render the risk response unnecessary, as the sponsor may commit their time to the project. Alternatively, the sponsor may agree to the nomination of a delegated sponsor who will represent them in the day-to-day sponsor role for the project. To ensure the delegated sponsor performs the role effectively, a job description may be necessary. If your organization follows a standardized project management method, there may already be a job description for the sponsor role. Otherwise, you can develop one that includes responsibilities such as leading at project gates, approving phase closures and starts, approving major deliverables, making decisions on issues and baseline changes, providing strategic guidance, consulting and coaching the project manager, advocating for the project within the management community, supporting resource availability, and ensuring funding. The work package “Obtain a delegated sponsor” may include activities such as negotiations, identifying an appropriate person, engaging in discussions with the chosen individual, and a milestone for reaching an agreement. It may also involve the development and adoption of a job description if one doesn’t already exist.

Number two: Obtain better requirements.

In the given example, the team decided to conduct workshops to elicit requirements. The work package would encompass activities such as organizing and conducting these workshops, including tasks like selecting stakeholders, booking appropriate spaces, and possibly arranging travel support. It may also involve the decision of whether to employ a facilitator. If so, the work package would include activities for selecting and hiring a facilitator or, if there is a framework agreement with a facilitator, simply booking their time. Special equipment requirements, such as a Metaplan box, should also be considered. After the elicitation phase, the team needs to analyze, align, classify, and rank the requirements, seeking agreement among stakeholders. Multiple rounds of review and refinement may be necessary, and these activities should be carefully planned and implemented. They are likely to impact the project schedule and cost estimates. Ideally, a budget should have been allocated during the planning phase to cover these activities, allowing for their smooth execution.

Number three: Obtain a replacement supplier for the tracking tool.

This particular risk response presents a challenge in the given case study. The supplier was initially selected based on their unbeatable low cost, meeting a cost constraint set by the finance department. Negotiating with the finance department is necessary, but it is important to handle the situation delicately to avoid causing them to lose face. Ideally, the project manager should manage the situation in a way that makes the finance department appear as the originator of the new idea. The sponsor may be the best person to facilitate this process, and involving the purchasing department is also essential. If the initial supplier was selected solely based on cost and other important selection criteria were not adequately considered, it would be crucial to engage more effectively in the supplier selection process. The lifecycle for obtaining a replacement supplier follows the procedures outlined in the lesson on conducting procurements. Revisiting that lesson for guidance is recommended. In some cases, the lifecycle may be shorter, and it may be possible to select one of the candidates who entered the shortlist. Building reserves to address such risks should have been part of the planning processes conducted prior to approving the project management plan.

Number four: Obtain a triangular payments service.

The procurement lifecycle described in the lesson on procurements can be applied here. This includes steps such as creating a long list of potential providers, narrowing it down to a medium list, issuing requests for proposals, evaluating the candidates, shortlisting the top choices, conducting negotiations, and ultimately awarding the contract. Time and budget considerations should have been included in the project management plan during the planning phase.

In summary, the implementation of risk responses involves defining, planning, and executing work packages just like any other project deliverable. Cost and time estimates for these responses were established during the planning phase when the risk responses were developed and decided upon. During the execution phase, it is crucial to take the necessary steps to put these responses into action.

 

 

3.11 Manage project knowledge and improve processes through lessons learned

This section discusses the importance of knowledge management in leveraging existing knowledge and creating new knowledge throughout a project.

The goal of knowledge management is to achieve project objectives by improving processes and utilizing the skills and expertise of the project team and stakeholders. This involves creating an atmosphere of trust and collaboration, motivating team members to share their knowledge and experiences.

While knowledge resides in the minds of individuals, it is crucial to facilitate the sharing and utilization of knowledge. Project documents and information management tools can help codify knowledge and enable sharing among team members. These aspects have been covered in previous lessons on leading the project team, developing the team, and managing communications and stakeholders’ engagement.

One specific aspect of knowledge management is improving project processes through lessons learned. This involves capturing and utilizing the experiences and interactions of team members. Retrospective meetings are a common technique used for this purpose. Retrospectives allow the team to reflect on their work, identify areas for improvement, and make adjustments to enhance effectiveness and efficiency.

Retrospective meetings can be conducted at regular intervals or when specific milestones are reached during the project. It is recommended to hold interim retrospectives to make timely improvements rather than waiting until the end of the project. These meetings can also be helpful when the team encounters challenges or when work processes are not flowing smoothly. Agile teams often conduct retrospectives at the end of each iteration, typically lasting two weeks.

It is important to note that a retrospective meeting is not about assigning blame but rather about learning and making small improvements. The focus is on evaluating the quality of work processes, tools, techniques, and team interactions. Quantitative measurements and data are used to identify root causes of dysfunction. The outcome of a retrospective meeting includes designing countermeasures and action plans to improve processes.

The agenda of a retrospective meeting typically involves the following:

• Reviewing the interactions, processes, and tools used during the previous working period.
• Identifying both successful aspects and areas with potential for improvement.
• Agreeing on actions to implement the identified improvements.

It is crucial to encourage active participation from everyone at the start of a retrospective meeting. Allowing silence to persist establishes an understanding that non-participation is acceptable, which is counterproductive to the purpose of a retrospective. The goal is to get people talking about their experiences and future aspirations. One way to facilitate early participation is by asking participants what they hope to achieve from the retrospective or to express their feelings about the past working period and the team’s progress using one or two words. It is important to remind everyone that there are no right or wrong feelings and that feelings are valid facts. Referring back to the team charter, where the team values were recorded, can be helpful in setting the tone. For example:

• We do not procrastinate and share project status often and early.
• We use data and information, not wishful thinking, to make educated decisions.
• We respect each other’s opinions and do not interrupt during discussions.
• All team members are encouraged to express their opinions, and silence should not be used to communicate conformity or disagreement.
• Instead of making excuses or seeking culprits, we focus on identifying and solving root causes of dysfunction.

To facilitate the retrospective discussion, tools such as a whiteboard or post-it cards can be used. Brainstorming, Fishbone diagrams, and the Five Whys technique are common tools for identifying and analyzing issues. If the discussion becomes dominated by a few individuals, the facilitator should intervene and ensure that everyone has an opportunity to contribute.

The outcome of the retrospective meeting may be a long list of action items needed to address identified impediments. To prioritize these items, the team can use a voting method, such as allocating a certain number of dots to each participant to vote on the most significant impediments.

It is important to limit the number of action items the team focuses on for the next working period. Some teams choose to focus on one or two critical items for improvement, as trying to improve too many things simultaneously can be demotivating if significant progress is not achieved. The team should also define how they will measure the outcomes of the chosen improvements.

If certain items reveal major issues that cannot be resolved in a single meeting, they should be recorded in the issues log and addressed using the issue resolution process outlined in the relevant subsidiary management plan. Although they may not require escalation to the sponsor for decision-making, the process should include steps for identifying root causes and evaluating alternative solutions. Referring to the detailed issues resolution process in the PDF document annexed to the lesson on subsidiary management plans can provide guidance if needed.

In the next working period, the team should measure the outcomes of the improvements to validate their success or failure.

In summary, knowledge management aims to leverage existing skills and expertise while generating new knowledge through information exchange and collaboration. Project documents, information management tools, and techniques are essential, but they must be supported by an atmosphere of trust and a team spirit of collaboration. Regular retrospective meetings are a valuable tool for generating lessons learned and driving continuous improvement.

 

 

4.1 Control a project – Overview

The purpose of project control is to gain an understanding of the project’s current state, anticipate its future status through cost and schedule forecasts, and take corrective and preventive actions as necessary.

In the upcoming lessons, we will delve into monitoring processes and techniques that enable us to identify deviations from the plan and evaluate their impact. We will explore potential countermeasures to address these variances, and we will examine fundamental controlling techniques for analyzing the project’s earned value and identifying root causes of problems.

The project management plan serves as an integrated blueprint, comprising both the project baseline and subsidiary management plans. If a plan exists, it necessitates a controlling process to monitor progress, assess deviations from the plan (as there are always variances), understand their implications for the project, and initiate appropriate actions.

Consequently, the controlling processes encompass all areas outlined in the project management plan.

This serves as an overview of the upcoming lessons on project control.

4.2 Control scope

4.3 Control scheduler

4.4 Control budget

4.5 Control quality

4.6 Control issues

4.7 Control change

4.8 Control risks, communications, stakeholders engagement, material resources and procurements

4.9 Control phase gates

 

 

4.2 Control scope

This section focuses on the inevitability of changes in projects and the importance of implementing a solid process to control scope changes.

Imagine a scenario where someone approaches you in the hallway and asks, “Hey, can you add this or that to the project?” and quickly rushes off to a meeting. There is a high probability that this person expects or hopes you will incorporate the request into the project without making adjustments to the schedule or budget. While it may seem customer-focused to say “yes” in such situations, it actually leads to what we call “scope creep.” Scope creep refers to the uncontrolled expansion of the project’s scope without corresponding adjustments to time, cost, and resources. This is something we should avoid.

There are various reasons why the approved scope baseline may change. For instance, the scope may not have been clearly defined upfront. Sometimes customers fail to communicate all their needs during the requirement identification phase. It could also be due to deficiencies in the requirement elicitation process or the customer’s lack of clarity about their own needs during that phase.

It’s a fact that few customers can articulate all their functional requirements and quality attributes upfront. Therefore, changes should be expected as the project progresses. The key to controlling scope is to channel these change requests through a predefined scope change control process, ensuring that the project manager doesn’t have to unilaterally say “yes” or “no” to the customer.

If you did a good job during the planning phase, you should have established a change control authority, which could be a board in larger projects or solely the sponsor in smaller projects. This change control authority is responsible for making decisions regarding changes to the approved scope, and any impacts on the budget and schedule must be approved as well. Other sections of the project management plan may also be affected by scope changes.

The role of the project manager in this process is to provide the necessary information. The sponsor needs to understand the purpose and need for the change, as well as its impact on the project in terms of cost, schedule, quality, and risks. The sponsor’s role is to make timely decisions based on this information, even if those decisions require courage. This is part of the sponsor’s responsibility.

To keep scope changes under control, here is a process you can follow:

• Firstly, scope changes should be requested in writing and addressed to the project manager, preferably using a scope change request form. If your process is less formal, an email may suffice. If someone informs you about the need for a scope change, remind them that your project management plan requires written change requests.
• Secondly, it’s important to validate whether the request constitutes a scope change. Not all changes are related to the project’s scope. For example, if a supplier replaces the person in charge of a work package, it is not a scope change. It may pose a risk if the new person is less capable, but it doesn’t impact the project’s scope. It could be addressed as an issue, and alternative solutions can be considered instead of a scope change.
• Once you confirm that it is indeed a scope change request, record it in the scope change log for tracking purposes. This log can be a summary spreadsheet where all change requests are documented with a unique identifier.
• Next, ask the person making the request to explain the purpose behind the change, which clarifies why it is needed. This information is crucial for the sponsor to make a decision.
• Afterwards, the project manager defines a work package to investigate the impact of the change on the project baseline, exploring possible alternatives and assessing the associated risks.
• Subsequently, present the scope change request, including its purpose, alternative options, and impact evaluation, to the change control authority for decision-making. The change control authority should approve or deny the request, considering the effects on the project management plan. Record the resolution in the scope change log.
• The next step is to update the project management plan accordingly. This may involve adding new activities to the schedule, adjusting the budget to account for potential costs, and addressing any new risk responses that may be required.
• Finally, communicate the resolution of the scope change to project team members and other relevant stakeholders using the methods specified in the communications management plan. It’s important to include “changes” as a standard item in your regular status reports and meeting agendas.

These approved scope changes become work packages to be implemented like any other work package. If the work package for investigating the impact of the scope change is extensive and may deplete existing reserves for contingencies, it becomes a special case. For instance, if the change request involves changing materials or technology, the investigation may require substantial engineering work before the change request itself is approved. In this scenario, the work package to investigate the impact of the change request becomes a change request in its own right. The project manager needs to obtain approval for conducting the investigation work, including additional time and budget. If the sponsor denies the means to investigate the impact of the scope change, it implies that the original change request is rejected as well. Consequently, it should be closed in the scope change log and communicated accordingly.

Here are some additional ideas that can help you streamline your scope control process:

Your project management plan can include provisions for resolving and approving scope changes up to a defined threshold by the project manager. This authority level must be clearly defined in either the project charter or the change management procedure. Additionally, it can be helpful to allocate a specific budget position for future change requests that were not individually identified during the planning phase. Remember that reserves for contingencies in an approved scope are not intended for accommodating scope changes. They serve a different purpose, and using them for scope changes can lead to regret if contingencies arise and additional work is required to complete the defined scope.

There are certain points in the project timeline, particularly during the implementation phase, where additional scope changes can be disruptive. In such cases, it is advisable to hold new change requests in a backlog and address them as enhancement requests after the solution has been implemented and stabilized. It’s important to note that this applies to change requests, not to defects, which should be resolved before implementation.

A backlog can also be used to track changes that are considered beneficial but may not be implemented in the current release of the solution. These enhancements can be scheduled for implementation in a subsequent release after the initial project is completed.

If the customer’s requirements are unclear or evolving, consider adopting an incremental approach. This allows both you and the customer to gain a better understanding of the requirements and adjust the scope accordingly throughout the project.

In summary, while the best approach is to define the scope well upfront, it’s not always possible, and change requests should be expected. Utilize a pre-defined scope change management process, where the project manager provides impact information to the change control authority. The change control authority’s role is to approve or reject change requests, taking into account their associated impacts on the project management plan. Additionally, leverage a backlog to manage changes that are not included in the current release of the solution but may be implemented in future releases. If the customer’s requirements are uncertain, consider adopting an incremental approach to better accommodate evolving needs.

 

 

4.3 Control schedule

This section focuses on monitoring and controlling the project schedule. We will explore three key aspects of schedule control:

Number one: Monitoring Process

Start by updating the schedule with current information using the frequency and tools outlined in your schedule management plan. Team members or leads should provide progress updates on completed activities during the previous working period. If you are tracking actual effort hours, team members need to report their work efforts for each work package. Keep in mind that this reporting process may not be a favorite activity for team members. You can manage it manually with spreadsheets or use specialized software applications. Update the schedule accordingly, and in a large project, this task may be assigned to a project controller.

Analysis of the Updated Schedule: Examine the updated schedule to identify any activities that should have been completed but are still outstanding. Work closely with those responsible for these activities to determine the causes of delay and apply problem resolution techniques to address them or minimize their impact. Collaborate with team members to assess the remaining effort and duration required to complete the activities.

Soft Indicators of Schedule Risks: Consider the following indicators as part of your analysis:

• Small variances that are growing, particularly in the early stages of the project.
• Activities previously marked as “done” are still ongoing due to unclear definitions of completion or unfinished tests.
• The team is consistently working overtime to meet interim deadlines, especially in the early stages of the project. This level of effort is not sustainable in the long run.
• Work appears to be on schedule but with an increasing number of errors or a gradual dilution of the project scope.
• Team morale is declining, which can have a negative impact on productivity and schedule adherence.

Addressing root causes and resolving issues promptly is essential. By tackling these challenges early on, you can prevent potential schedule deviations and maintain better control over the project timeline.

Number two: Understanding the Impact of Detected Delays on the Project Duration

To assess the impact of detected delays on the project duration, you need to analyze the critical path of the project. The critical path is the longest sequence of activities in the project schedule.

Why is the critical path so crucial? There are three reasons:

• First, any delay on the critical path will directly delay the project’s finish date.
• Second, by finding ways to shorten the critical path, you can also reduce the overall project duration.
• Third, the critical path provides early visibility of the impact on the project’s end date, allowing for early implementation of countermeasures.

How do you determine which activities are part of the critical path? The key is to identify activities that have no float. Float refers to the amount of time an activity can be delayed without affecting subsequent activities or the project’s overall completion. Activities with float can be delayed within the float duration without impacting the project duration. These activities are not part of the critical path.

On the other hand, activities without float must start and finish as planned, as any delay in these activities will directly affect the project’s finish date. These activities are the critical path activities, also known as “critical activities.” It’s important to note that critical activities are not necessarily the most important activities; they simply have no float.

For smaller projects where the Gantt diagram can be easily reviewed, you can visually identify activities with float. However, for larger projects, it is recommended to use a scheduling tool that can calculate the critical path for you. The critical path is typically displayed as a “red chain of activities” in the tool, which requires careful attention.

The critical path is a crucial technique for determining whether a delay in an activity will impact the project’s end date and to what extent. It is an essential aspect of schedule control.

Number three: Types of Corrective Measures for Critical Activities to Counterbalance Detected Delays

There are several options for applying corrective measures to critical activities when delays are detected. These options include:

• Adjusting dependencies between activities, such as changing them from finish-to-start to another type of dependency.
• Implementing overtime work to accelerate progress on critical activities.
• Utilizing crashing techniques, which involve adding additional resources to critical activities to expedite their completion.
• Exploring fast-tracking approaches, which involve overlapping or parallelizing critical activities to compress their duration.
• Identifying process improvements that can optimize the efficiency and effectiveness of critical activities.

These options can be further explored and evaluated based on the specific circumstances of your project. The goal is to identify the most suitable corrective measures to mitigate the impact of detected delays on critical activities.

By applying these corrective measures to critical activities, you can help recover schedule delays and ensure that the project remains on track.

Change suitable dependencies among activities from finish to start to something else

Schedule dependencies determine the sequence in which activities must or should be completed. For example, in a house construction project, you cannot start building the walls before pouring the foundation. This is a “mandatory relationship.” However, there are cases where activities can be done in parallel, but you prefer a specific sequence. These are “preferred relationships” that we seek to identify and redefine to optimize the schedule.

In some cases, finish-to-start relationships are created hastily or due to mistakes during the planning phase. Upon review, it may become apparent that the dependency does not actually exist or can be modified.

The idea is to have the team review the schedule and identify any unnecessary or preferred finish-to-start dependencies that can be adjusted. This is a crucial area to focus on, as it holds significant potential for time savings. For instance, if an activity is scheduled to start four weeks after its predecessor, but both activities can be done in parallel, making the adjustment can save four weeks without incurring additional costs or resources.

Work overtime is another option

While working overtime is not a favorite choice, it can be considered if the duration of activities depends on the number of work hours. The team can accomplish more work within the same calendar time by extending working hours. Overtime is often utilized towards the end of the project when a final push is needed to meet the schedule. However, if you are still in the early stages of the project, there may be more efficient alternatives to explore. It’s important to note that working overtime may impact costs if overtime is paid at a higher rate than regular working hours. Additionally, team motivation may be affected, so appropriate team-building measures should be implemented.

Crash the schedule

Crashing the schedule involves allocating additional resources to critical path activities. Instead of relying solely on overtime work with existing resources, you would add more resources to expedite those activities. The impact on costs depends on the type and source of the additional resources.

Fast track

Fast tracking involves starting the successor activity before the predecessor has finished, without formally changing the relationships. For example, you may begin preparation works for the successor while the predecessor is nearing completion. Fast tracking often carries a certain level of risk, especially when the relationship is mandatory. For instance, starting production activities before the design is fully finalized may lead to potential design changes that require rework. Experienced project managers suggest that sequential activities can sometimes be fast-tracked by up to 25%, meaning the successor activity can start when the predecessor is 75% complete. While there is risk involved, fast tracking can be a viable option to compress the schedule and compensate for delays if the risk level is deemed acceptable.

 

Process improvements

Process improvements are always worth considering. There is almost always room for improvement in terms of efficiency and speed. The project manager can use retrospective meetings to identify opportunities for process enhancements. Candidates for elimination include any sources of waste, as described in the lesson on assuring quality. Process bottlenecks, where work waits in queues to be further processed, are also considered waste. This can include waiting for approvals or team members being diverted from project work by other organizational activities that could be postponed until the project is back on track. Negotiation is a key technique in addressing such issues.

Increase morale and regain commitments

Regardless of the corrective measures used, increasing team morale and reaffirming commitments is always a valuable option. After missing intermediate deadlines, some team members may question the need to work hard to meet deadlines, especially if others are not meeting theirs. It is important to refresh commitments to complete assigned work on schedule, including individual and personal commitments. Team building activities, as explained in the lesson on leading the project team, can also contribute to improving morale.

Preventive measures: Ensure team members know their due dates

To prevent delays caused by lack of clarity, misunderstandings, or conflicts in priorities, it is important to ensure that team members are clear on their responsibilities and deadlines. This is achieved through a well-developed work breakdown structure (WBS), work packages, and a schedule. If these planning tools are defective or missing, it may lead to consequences during project execution. Managing a schedule requires having a detailed schedule that specifies when each work package should start and finish, along with assigned responsibilities. Use this information to identify approaching start dates and engage with the relevant individuals to refresh and validate commitments and dates.

Communicate schedule risks

If, despite taking corrective measures, there is still a risk of missing the project deadline, it is crucial to communicate this risk to the sponsor and provide new estimates. Communicating schedule risks is important as it allows for potential adjustments, such as scoping back the project to meet the original estimated timeline.

In summary, controlling a schedule involves regular monitoring, understanding the impact of delays, and implementing corrective and preventive measures when necessary. Analyzing the critical path and applying corrective measures to critical activities are key aspects. Additionally, effective communication of schedule risks is essential throughout the project.

 

 

4.4 Control costs

This section is about monitoring the status of project costs and techniques to keep them under control.

We will explore three aspects of cost control:

• The monitoring process to detect if costs are progressing according to cost estimates and in line with the actual funds release rate of your organization.
• Earned Value Analysis, which relates actual costs to the work accomplished and provides insights into cost performance, helping detect variances that need to be addressed.
• Possible countermeasures to recover from a budget overrun.

Please note: that this lesson involves numbers and takes approximately 25 minutes. If you are in a hurry, tired, or engaged in activities such as piloting a plane or driving a car, we advise you to stop the video and listen to it when you can fully concentrate and engage with the content.

Number one: the monitoring process

Cost control is closely tied to schedule monitoring, as most expenses are related to the progress of work. Even if your project does not involve costs for internal resources due to no monetary outflow, there will likely be external suppliers generating invoices that need to be validated by the project manager, although the finance department handles accounting and payments. If you are monitoring costs and efforts of internal resources, your monitoring process includes translating effort hours into costs using the rates defined in your budget.

The process begins with updating actual expenditures as per the frequency and tools established in your cost management plan. In most organizations, financial reporting is done monthly.

The monitoring process focuses on two aspects: comparing actual costs with estimates and assessing the funds release rate.

The first aspect involves comparing actual costs to the cost estimates once you have updated your schedule and gained visibility into the remaining effort and its duration. The project manager also estimates the cost of the remaining work, forecasting costs at project completion. In other words, you add actual expenses for completed and ongoing work, along with expected expenses for the remaining work. Comparing these projected costs at completion with the cost baseline indicates if the project is likely to stay within budget.

These calculations and updates can be performed manually using spreadsheets or through the cost control functionality of advanced scheduling tools (such as SAP or Oracle). In larger projects, a project controller may be responsible for this activity.

The second aspect of cost monitoring involves comparing actual and expected costs with the release rate of funds by your organization. Deviations can occur on both sides of the equation. On one side, the project may be consuming funds faster than planned, not necessarily due to a budget overrun, but because work is progressing quicker than anticipated or because certain payments need to be made.

On the organizational side, the funding requirements are approved, indicating the timeline of project expenses. The sponsor’s approval of the project management plan should ensure that the organization will release funds according to this plan. However, in reality, things may change over time, especially in long projects. In some cases, particularly in small projects, the entire budget may be made available at the start, but for larger projects, the budget is typically released in increments.

The key point of this aspect of monitoring is to keep an eye on actual and upcoming expenses on one side and the funds release rate on the other side. In other words, you need to monitor how much money is available. It may be necessary to request the next round of funds earlier than planned to avoid committing to expenses when the funds are not yet available.

Include in your analysis the following early indicators of cost risks:

• Number 1: a small cost variance that starts to increase, especially early in the project.
• Number 2: work declared as “done” in the past that is later found to have errors or missing functionalities, resulting in rework and cost impacts.
• Number 3: the project falling behind schedule and the intention to use schedule compression techniques, which may have cost implications.
• Number 4: declining team morale, as a demotivated team is less productive and more cost-intensive than a motivated team.

Sooner or later, these situations will affect costs. It is crucial to address the root causes as early as possible.

Number two: Earned Value Analysis

Earned Value Analysis relates actual costs to the work accomplished and provides a deeper understanding of cost performance. This analysis is necessary because a simple comparison of actual costs to planned costs can be misleading and may show a cost overrun that is only apparent. For example:

Some actual expenses in the reporting period may have been budgeted to occur later, leading to an “over budget” position for the current period. However, this is not a true over budget situation but a temporary shift in the expense rate. The important consideration is whether the funds released by your organization can cover the advanced cash flow need.

Another scenario is spending more than budgeted because the project has accomplished more work than planned. Again, this is not a true over budget situation but another temporary shift in the expense rate.

A true cost overrun occurs if one of the following situations arises:

Defined work packages require more effort than estimated, resulting in increased resource consumption.

The Work Breakdown Structure (WBS) was incomplete, and additional work items need to be done.

The resources being used have higher costs than estimated.

Some team members are working outside the project’s defined scope.

Your analysis needs to differentiate between apparent and real cost overruns, and this is where Earned Value Analysis comes into play.

Earned Value Analysis (EVA) is a method that provides a deeper analysis of cost and schedule performance beyond basic cost and schedule reports. It is based on a key measure known as the project’s “Earned Value,” which is defined as the budgeted amount of work performed.

Imagine this is the Gantt of your project, simplified to one single Gantt bar.

The budget at completion (BAC) for the entire project is 100 €, and the planned duration is 100 days. The current day is 70. So far, 80 € has been spent, and 50% of the work has been completed, indicated by the colored section of the Gantt bar.

Earned Value is defined as the budgeted amount of work performed. Since 50% of the work has been completed, the proportional budget for the work accomplished is 50 €. Therefore, the Earned Value is 50 €.

The next step is to compare the Earned Value to the Planned Value.

The Planned Value is the budgeted amount for the work that should have been completed until the measurement date. In this example, the plan was to accomplish 70% of the work, which corresponds to a proportional budget of 70 €.

By subtracting the Planned Value (70 €) from the Earned Value (50 €), we get a Schedule Variance of -20 €. A negative variance indicates that we are behind schedule. This delay would likely have been visually evident on the Gantt Chart without performing this calculation.

The cost situation is not as apparent. Simply comparing actual costs (80 €) to the total budget (100 €) may suggest that we are within budget. However, when comparing actual costs to the proportional budget for the work accomplished (Earned Value), the Cost Variance is -30 €, indicating that we are over budget by 30 €.

To express these variances in percentage terms, we can divide the Earned Value by the Actual Costs and the Planned Value, respectively, to calculate the Cost Performance Index (CPI) and Schedule Performance Index (SPI).

• Earned Value (50 €) divided by Actual Costs (80 €) gives a Cost Performance Index of 0.625 or 62.5%. This means we are over budget by 37.5%. A CPI of 1 indicates being on budget.
• Earned Value (50 €) divided by Planned Value (70 €) gives a Schedule Performance Index of 0.71 or 71%. This means we are 29% behind schedule. An SPI of 1 indicates being on time.

In mathematical terms, “managing a project to the baseline” means achieving Schedule and Cost Performance Indices equal to 1, or 100% on time and within budget.

By translating time to money, we can better understand these aspects of project performance using a common denominator. This unified view allows for more informed decision-making. For example:

• If we are more over budget than behind schedule, we should avoid schedule compression techniques that may have cost implications.
• If we are more behind schedule than over budget, we could justify using schedule compression techniques despite the cost impact because being on time is a higher priority.

Next, we need to estimate the impact of the cost situation at project completion, known as Estimated At Completion (EAC). We still have 50% of the work remaining. The Cost Performance Index of 0.625 allows us to calculate the expected costs at completion. BAC divided by CPI gives an EAC of 160 €. This means that if we continue as we are, the project will end up with costs of 160 €. However, corrective measures may be implemented to address the cost overrun.

Even if we correct the situation for the remaining work, the cost overrun incurred thus far cannot be reversed. The 80 € already spent remains. To calculate the expected costs at completion in this scenario, we add the remaining work, which can be done at the original estimate of 50 € (BAC minus Earned Value). Therefore, the expected costs at completion would be 80 € (already spent) + 50 € (remaining work) = 130 €.

If the corrective measures are considered “courageous measures,” involving some level of pain, it is important to communicate both scenarios to stakeholders:

• If we do not correct the situation, the project will end up with costs of 160 €.
• If we take corrective action now, the project will end up with costs of 130 €.

Finally, to analyze an example project report using Earned Value Analysis, the same calculations performed earlier can be applied to each work package or control account and summarized at the project level. This allows for a more detailed assessment of project performance.

WP or contr. Acc.	EV	PV	AC	BAC	SV EV – PV	SPI EV / PV	CV EV – AC	CPI EV / AC	EAC resolved (AC + BAC-EV)	EAC not resolved BAC/CPI
A	200	200	200	200	200-200 = 0	200/200 = 1	200-200 = 0	200/200 = 1	200+200–200 = 200	200/1 = 200
B	90	180	100	180	90-180 = -90	90/180 = 0,5	90-100 = -10	90/100 = 0,90	100+180-90 = 190	180/0,9 = 200
C	100	100	130	200	100-100 = 0	100/100 = 1	100-130 = -30	100/130 = 0,77	130+200-100 = 230	200/0,77 = 260
D	10	60	20	300	10-60 = -50	10/60 = 0,17	10-20 = -10	10/20 = 0,50	20+300-10 = 310	300/0,5 = 600
∑	400	540	450	880	-140	400/540 = 0,89	-50	390/450 = 0,87	450+880-400 = 930	880/0,87 = 1011

Let’s start at the project level, applying the same logic as before. We can observe that we are behind schedule and over budget, with both the Schedule Performance Index and Cost Performance Index below 1. However, the Earned Value Analysis provides valuable information about the problem areas and helps prioritize corrective measures.

Work packages B and D are experiencing schedule issues, with SPIs of 0.5 for B and an even worse SPI of 0.17 for D. Although official Earned Value Analysis calculations don’t use days, we can use the Schedule Performance Index to estimate the delay in terms of days. For example, if work package B was originally planned for 20 days, dividing the planned duration by the SPI of 0.5 indicates that it will now take 40 days to complete. Similarly, work package D, with an estimated duration of one month, would take almost 6 months to complete based on an SPI of 0.17. This extended duration could be catastrophic for the project, highlighting the need to apply schedule compression techniques to these work packages.

Turning to costs, work packages B, C, and D are all over budget. However, the Cost Performance Index reveals that work package D is the major concern, with a CPI of 0.5. At this expense rate, completing work package D would cost 600,000 instead of the planned 300,000. Therefore, addressing the cost issues in work package D should be our primary focus.

We also observe two calculations for the Estimated At Completion. If we take corrective action and make a “courageous decision,” we could potentially minimize the cost deviation. Work package D, which has only earned 10 out of 300, indicates that 97% of the work is still pending, presenting significant potential for cost savings. Work packages B and C also have potential cost savings, but they are comparatively smaller at 10,000 and 30,000, respectively.

Furthermore, we need to communicate a budget risk. Even if we resolve existing problems, the projected cost will be 930,000 instead of the planned 880,000, resulting in a 5% overrun. The good news is that if you have followed the practices taught in this class, you should have contingency reserves of 5%. However, if the problems persist and the spending reaches 1 million instead of 880,000, it may exceed the available 15% management reserve. Utilizing the management reserve would impact the Project Baseline, which serves as the performance baseline for the project manager.

Now, let’s move away from the numbers. Are you still with me? The rest is a piece of cake and will only take 2 minutes.

It’s crucial to communicate budget risks

As soon as you realize that there is a risk of exceeding your budget, you should inform the sponsor and management stakeholders. You don’t have to state that you will definitely exceed the estimates, but it’s important to communicate the risk to manage expectations and prepare for implementing corrective measures. This information is valuable because management stakeholders may provide input and, for instance, the sponsor might agree to reduce requirements and scope to ensure the project can be completed within the original estimates.

Number three: corrective measures for the budget

In many organizations, projects often do not account for the cost of internal resources, limiting the budget responsibility of the project manager to managing the costs of acquired supplies. In some cases, the project manager is only responsible for managing the scope of delivery and the schedule.

If you are a project manager with budget responsibility and need to implement corrective measures, here are the most important options available to you:

Number one: process improvements are always applicable, as explained in the lesson about controlling the schedule.

Number two: avoid higher rates for overtime work. While this may not always be possible or even prohibited, there are instances where collective agreements allow for compensating overtime with extra holidays after the project is completed.

Number three: swap more expensive resources for less expensive ones. If your company does not account for the project costs of internal resources, replacing an external consultant with an employee can result in immediate cost savings, at least on the surface, due to the assumption that internal resources have no project costs. Alternatively, you may be able to replace expensive multi-talented resources with more cost-effective options that still possess the necessary capabilities for the current phase.

Number four: lower non-labor costs. For example, opting for a discount hotel instead of a regular business hotel, flying in economy class instead of business class, substituting a 5-day training at a luxury resort with a computer-based training, or sending one person on a business trip instead of two. These cost-cutting measures may not be desirable, but they can help reduce expenses.

Number five: renegotiate external contracts. While it’s true that a contract is a contract, there may be room for negotiation, especially when there is a sense of partnership in the seller-buyer relationship. Your supplier may be willing to work with you to cut costs. For instance, a contract resource might reduce their rate in exchange for additional work hours, or a vendor might accept lower payment in return for the possibility of becoming a preferred supplier.

To summarize, you should monitor your budget situation according to the guidelines established in your schedule management plan, which should adhere to organizational rules. However, it is not forbidden to review the cost situation twice a month, even if your company requests monthly financial reports.

The Earned Value Analysis is a cornerstone of your analysis, providing insights not only into the cost situation and project outlook but also indicating problem areas for both costs and schedule.

Implement corrective measures where necessary, focusing on areas where there is more room to reduce costs. Ideally, you have established reserves for contingencies during the planning phase. If not, and you find yourself in a difficult situation due to unrealistic assumptions, such as overly optimistic estimates to sell the project, you will need to adjust using change management. Remember to manage expectations in a timely manner to avoid unpleasant surprises at the end of the project.

 

 

 

 

4.5 Control quality

This section is about verifying deliverables to ensure they are complete and correct.

Let’s begin by refreshing the definition of quality from the ISO 9000 standard: “Quality is the degree to which a set of inherent characteristics fulfills requirements.” The key point here is the fulfillment of requirements.

In project management, there are two aspects of quality to consider:

• Quality assurance: This involves implementing standards, policies, and processes to produce deliverables that meet requirements.
• Control quality: This focuses on measuring how well deliverables meet requirements, which is the focus of this lesson.

If needed, you can revisit the lesson on quality assurance, which is part of managing project execution. Remember that it’s not just the key deliverable of a project that must comply with requirements. Each work package has acceptance criteria and must undergo a quality review. Even each phase of a project and the entire project should have defined success criteria.

You control the compliance of an object to requirements by checking if it is complete and correct. This should be done before presenting it to the customer for acceptance and final delivery. The goal is to avoid the final customer discovering errors or missing functionalities that should have been identified prior to the final presentation for approval and delivery.

Quality review is an essential part of the control quality process. In the lesson on “authorizing, delegating, and accepting work packages,” we discussed a quality review process specifically for work packages. Here, we will adapt it for deliverables in general, as this quality review process can be used for any type of deliverable and represents the conclusion of the quality control process.

During a quality review meeting, at least two people participate:

• The presenter: This person is responsible for managing the execution of the deliverable and takes on the role of presenting the deliverable during the review. They may take notes themselves or be supported by an administrative staff member.

The reviewer: This person chairs the meeting and plays the role of reviewing the deliverable. It’s important that the reviewer is not the same person who managed the execution of the deliverable. Depending on the nature of the product being reviewed, the reviewer can be supported by a technical expert.

The roles played by individuals depend on the type of deliverable being reviewed:

• If the deliverable is a component of a work package: The presenter is the team member or members responsible for executing the work, and the work package leader serves as the reviewer.
• If the deliverable is a work package: The presenter is the work package leader, and the project manager takes on the role of the reviewer.
• If the deliverable is a project phase: The presenter is the project manager, and the sponsor serves as the reviewer.
• If the deliverable is the entire project at project closure: The presenter can be the project manager, and the sponsor plays the role of the reviewer. Alternatively, depending on the governance processes in place, the presenter can be the sponsor, supported by the project manager, and the reviewer can be a corporate governance body.

During the quality review meeting, the reviewer assesses the deliverable against the acceptance criteria. The presenter provides evidence of compliance, and questions are asked and answered. Any necessary actions are agreed upon and noted.

The result of the quality review can fall into one of the following categories:

• The deliverable is deemed correct and complete and is accepted.
• The deliverable is nearly correct and complete and is conditionally accepted, meaning a few actions are required to address identified issues. However, a second quality review meeting is not necessary.
• The deliverable is found to be incorrect or incomplete, and it is not accepted. It is sent back for rework, and another quality review will be scheduled. If the object under review is a project, a negative result is considered an input to the portfolio management process. The organization must decide if subsequent measures are needed to address the missing requirements, depending on the organizational context.

It’s important to note that the quality review meeting does not measure compliance with requirements directly. During the meeting, the focus is on verifying the presence of evidence that demonstrates conformity with requirements. This evidence should have been generated prior to the quality review meeting through activities such as technical tests, surveys, analysis, and reporting.

The processes for collecting this evidence are also part of the quality control process. However, the specific types of evidence and the methods for generating it vary depending on the product and industry. For example, the requirements and acceptance criteria for a Netflix movie, a salmon fish farm, an Airbus plane turbine, and a custom-made wheat seed for Pizza Hut will differ significantly. Additionally, project management styles, such as agile and waterfall, can influence when and how quality control activities are performed throughout the project life cycle.

Let’s look at some examples of acceptance criteria or requirements in different product types and how compliance can be demonstrated.

Type of requirement	Requirement	Means to demonstrate compliance
Functional requirement	The system must request agreement of the caller to record the call	Functional test
Functional requirement	The system connects to the general customer desk when the caller does not specify the subject of the call	Functional test
Quality attribute	The material should stand a heat of 500° C with a deformation no larger than x%	Stress test
Quality attribute	The speaker must be understood by the audience with a level of understandability of 8 in a scale of 1 to 10 by at least 80% of the audience	Survey and structured interview of a focus group
Project management   requirement	The Cost Performance Index must not exceed 20% at each phase end	EVA report
Business requirement	Ability to promote the organization’s services to Chinese potential customers	Acceptance of the deliverable of a project to develop this business capability
Quality attribute	Immunity against Covid-19 with an effectiveness of at least 70% of persons in the age group of 60 years and older	Test series as defined in exception law for Covid-19

It’s important to recognize that the types of testing or evaluation techniques used are specific to each product and cannot be generalized. The aim, however, remains consistent: to identify errors, defects, or nonconformance issues in the product or service. The extent of testing and product evaluation also depends on constraints such as budget, time, and the quality management plan.

Some examples of industry-specific testing include:

• Unit testing, integration testing, interface testing in software development.
• Cement strength, concrete workability tests, soil tests in construction projects; and environmental stress screening, burn-in tests, system testing in hardware development.
• Civil aircraft testing involves safety tests, performance tests, and more.

The Earned Value Analysis report discussed in the control costs lesson can be considered an example of demonstrating compliance with project management requirements related to costs.

Finally, it’s important to consider the interconnections between quality assurance, quality control, issues, and changes. The project team ensures quality through quality assurance processes based on the quality management plan and acceptance criteria defined for each work package. The deliverables resulting from execution processes undergo quality control to verify compliance and detect errors. Errors and missing functionalities trigger non-conformance reports (NCRs), leading to defect repair or further development. This process involves a back-and-forth between quality assurance and quality control.

Sometimes, the identification of defects in quality control not only requires the correction of specific product defects but also prompts an assessment of underlying issues in the production process, materials, tools, skills, or attitudes of those involved. Such root causes can trigger the declaration of an issue or a change request to address the underlying problem. These issues or change requests are handled in accordance with the lesson on implementing approved changes and corrective measures.

In summary, quality assurance aims to produce the desired level of quality, while quality control measures how well deliverables meet requirements. Each deliverable type has specific requirements and quality attributes that need to be verified and measured by the development team before the quality review meeting. The functionalities and attributes of a deliverable, as well as the methods for measuring them, are specific to the product and industry involved.

 

 

 

 

4.6 Control issues

This section focuses on managing issues, which are a specific type of problem.

In the lesson about “implementing approved changes and corrective measures,” we discussed the complete process flow of an issue, starting from its generation during execution, through detection and analysis in the control phase, developing options and selecting a corrective measure, planning the corrective activities, and finally implementing the corrective measures and resolving the issue. If needed, please revisit that lesson for a refresher.

In this lesson, we want to reflect on the nature of issues, outline a process for handling them, and explore the root cause analysis technique.

Let’s begin by defining what an issue is. An issue refers to a significant problem that poses a threat to project objectives and requires intervention beyond the project manager’s scope. We are not referring to normal problems that can be resolved by the project manager. Issues are the type of problems that necessitate an escalation process and require intervention from the project sponsor.

There are various reasons why an issue may need to be raised. All problems and issues are essentially risks before they manifest, either because they remain undetected or because the risk response developed during risk management was inadequate. Thus, the sources of issues and problems are as diverse as the sources of risks; the only difference is the timing: a risk is a potential problem, while an issue or problem has already occurred.

If you have done a good job during the planning phase, you should have a defined issue management procedure in place. Alternatively, your organization may have standard procedures for managing issues.

If you need to develop an issue management process from scratch, you can follow the guidance provided below.

The first step is to determine whether it is an issue that requires escalation or a problem that can be resolved by the project manager. If it is a significant issue requiring escalation, then it falls under the issue category.

The next step is to formally document the issue. While it may have initially surfaced verbally or through informal written communication, it must be documented using an issues form. Expressing the nature of the issue clearly in writing is essential. If you cannot articulate the issue in writing, it indicates that you haven’t fully understood it yet. As you gain a deeper understanding of the issue, the initial definition may be updated.

Additionally, enter the issue in the issues log for tracking purposes. This log can be a summary spreadsheet that includes a unique identifier for each issue.

Next, determine the stakeholders who need to be involved in resolving the issue. Since it is an escalated issue, the sponsor will be part of the resolution process. However, depending on the nature of the issue, other stakeholders such as legal or purchasing departments, line managers, or external parties may also need to be consulted and involved.

Problem resolution works best as a collaborative effort, involving teamwork with the defined stakeholders to detect and analyze options and their respective impacts. It’s important to note that sometimes there may not be a perfect resolution to an issue, and the team involved may need to choose the best option from a set of unfavorable alternatives.

If the chosen course of action impacts the project baseline, the approval of the resolution approach also approves associated changes to the project baseline, resulting in a new baseline.

Next, update the issue form and issue log to reflect the decision made.

The subsequent step is to update the project management plan accordingly. This may involve adding new activities to the schedule, incorporating new costs into the budget, or addressing new risk responses. Additionally, lessons learned from the issue should be recorded in the lessons learned register and shared with relevant stakeholders.

Finally, communicate the issue resolution to project team members and other appropriate stakeholders using the methods outlined in the communications management plan. It’s important to include “issues” as a standard item in your status reports and meeting agendas.

The approved measures to resolve the issue become work packages to be implemented, just like any other work package. If necessary, refer back to the lesson on implementing approved changes and corrective actions, which is part of the execution section.

Root cause analysis

During the investigation of an issue, a widely used technique is root cause analysis. Let’s use the analogy of a weed to explain it.

The visible part of a plant, the weed above the surface, represents the problem we see. However, the root of the weed, which is invisible and lies beneath the surface, represents the underlying factors that contribute to the problem’s growth. Just like with weeds, merely cutting the surface will only temporarily make it disappear, but unless we remove the root of the weed by digging down and understanding its ramifications, it will continue to resurface.

However, a root is a system consisting of various parts. “Analysis” refers to breaking down the system into its individual components and understanding all the pieces that make up the root. This is where techniques like fishbone diagramming and brainstorming come into play, allowing us to break down the root cause into its components, group and organize them in a graphical manner.

Let’s use the example of the Titanic to illustrate the causes of the disaster. The “five why” technique may lead some brainstorming participants to realize that the sinking occurred because the staff in the crow’s nest wasn’t paying enough attention. Others may point out that the ship was traveling at excessive speed. Some participants may raise concerns about construction defects, particularly faulty rivets that caused the ship to sink rapidly. Lastly, others may highlight issues such as insufficient lifeboats or the absence of binoculars in the crow’s nest.

All these statements are true, and there is no contradiction among them. It serves as a prime example of a problem, in this case, a catastrophe, that has multiple causal paths, as most issues do.

The objective is to identify these multiple causal paths. Fortunately, we don’t have to start from scratch. Evidence suggests that most problems in project management can be grouped into four categories: processes, tools, know-how, and attitude. Problems may arise from inadequate or non-existent standard procedures, unsuitable equipment or tools, insufficient expertise among team members regarding the subject matter, processes, or tools, and a lack of a conducive attitude towards high performance. Each of these standard cause paths can be broken down using the “five why” technique to identify ways of resolving the various components of a root cause.

Lastly, detecting issues at their early stages is crucial. The earlier we identify them, the sooner we can work on their solution and minimize their impact. Ideally, we aim to prevent issues altogether while they are still risks.

Retrospectives serve as excellent opportunities to detect issues when they are still in their infancy. You may refer back to the lesson on improving processes through lessons learned if necessary.

Additionally, Earned Value Analysis serves as a valuable early indicator. Although it may not reveal the root causes directly, it can provide insights into specific work packages that may have underlying problems.

Observation is also a useful tool for detecting upcoming issues. Project managers should spend time with their project teams, utilizing techniques explained in the lesson on developing the project team. The classic technique of “managing by walking around,” as discussed in the book “In Search of Excellence” by Tom Peters and Robert Waterman, can be effective in this regard.

In summary, the best approach for problems and issues is to prevent them while they are still risks. However, if prevention fails, it is crucial to address issues promptly, considering the time constraint in project management. Involve the team when managing issues and follow a structured process. Retrospective meetings, Earned Value Analysis, and managing by walking around are effective avenues for detecting problems and issues at early stages. When analyzing issues and problems, don’t focus solely on surface-level symptoms. Dive deep into the root cause, which often consists of multiple causal paths. This is where teamwork is essential.

Implementing corrective measures requires defining, planning, and executing work packages, just like any other project task.

4.7 Control changes

This section focuses on the integrated management of changes that originate from various controlling processes.

All controlling processes generate work performance information, which is then compared to the project management plan to detect deviations. These deviations can trigger changes to different aspects of the project management plan.

The changes required can be corrective measures to realign the project with the baselines or to address defects in deliverables that do not meet requirements. These changes are reactive in nature. However, changes can also be proactive measures taken to prevent future deviations from the baselines.

The necessary changes may or may not affect the project baseline.

• If the changes do not impact the project baseline, they fall within the authority of the project manager.
• If the changes do affect the project baseline, a formal change control process must be followed. The change request is submitted for consideration and approval by the Change Control Board, which may consist of the sponsor and corporate managers. In larger projects, where the performing organization is a consortium, the change control board may include the entire steering committee to deliberate on major changes.

The process of change control, including participants and levels of authority, is determined in the project management plan.

It is important to take an integrated view of all changes because all project areas are interconnected. Making decisions solely based on one aspect, such as compressing the schedule to address a delay in a critical activity, without considering the effects on costs, team morale, and quality, can have unintended consequences. It is crucial to assess the impacts across all project dimensions.

One of the subsidiary management plans is the change control process, which we have already seen in action in the lesson on “control scope.” In this lesson, we present an abstract of the change control process, now adapted to handle changes affecting the project baseline, not limited to scope changes.

The steps in the change control process are as follows:

1. Change requests must be submitted in writing using a change request form and tracked in the change log.
2. The person requesting the change explains the purpose behind it.
3. The project manager defines a work package to investigate the impact of the change on the project baseline, explores possible alternatives, and assesses the associated risks.
4. The change request is presented to the change control authority for decision-making.
5. The change control authority approves, denies, or defers the change request. If approved, the approval includes the effects of the change on the project management plan.
6. The project manager updates the change request form and change log with the resolution.
7. The project manager updates the project management plan to reflect revised cost estimates, potential changes in activity sequencing and deliverable completion dates, resource requirements, and any additional risk responses resulting from the approved change.
8. Finally, the project manager communicates the change resolution to project team members and other stakeholders using the methods outlined in the communications management plan. It is important to include “changes” as a standard item in status reports and meeting agendas.

The approved changes become work packages to be implemented like any other work package. Refer to the lesson on implementing approved changes and corrective actions, which is part of the execution sections, if necessary.

In some cases, the work package to investigate the impact of a change may require substantial effort, potentially depleting existing contingency reserves. In such instances, the project manager needs to seek approval for the investigation work upfront. If the sponsor denies approval for the investigation, it implies the rejection of the original change request, which should then be closed in the change log and communicated accordingly.

Some projects may define a certain level of authority for the project manager to decide on changes up to a specific amount without seeking approval from a change control board, as stated in the project charter.

In summary, deviations from the project management plan trigger changes. Changes that affect project baselines must go through a formal change control process for consideration and approval by the designated change control authority. Take an integrated view of change requests, considering their purpose, alternatives, and impacts on baselines and risks. Approved changes are implemented as work packages.

 

 

 

 

4.8 Control risks, communications, stakeholders’ engagement, material resources and procurements

This section focuses on the purpose and activities involved in controlling risks, communications, stakeholders’ engagement, material resources, and procurements.

Similar to other controlling processes, the aim is to track and review data from execution, analyze it in the overall project context, and generate meaningful information. This information helps identify areas requiring changes and initiate corresponding actions.

Let’s review each controlling area individually.

Control Risks:

The purpose of controlling risks is to ensure project decisions are based on up-to-date information regarding the overall project risk exposure and individual project risks. The project management team continuously monitors the risk situation to determine if identified risks have changed, if planned risk responses are effective, if new risks have emerged, and if assumptions have transformed into risks. Risks and assumptions are closely related and depend on the perception of probability and impact. The team also verifies if risk management policies and procedures are being followed and assesses the need for modifications to contingency reserves for cost or schedule. Overall, the objective is to validate the ongoing project strategy from a risk perspective. Corrective measures are initiated as needed, leading to adjustments in the project management plan and updates to various project documents such as assumptions and issues logs, as well as lessons learned and risk registers. These changes are planned, executed, and controlled like any other work package.

Next controlling area…

Control Communications and Stakeholders’ Engagement:

The term “control communications” may sound politically incorrect. To address this, alternative terms such as “monitor communications” or “monitor the impact of communications” have been used. However, we maintain the term “control” in alignment with other controlling processes. In controlling communications, it is not only about monitoring the implementation of planned activities but also developing and implementing corrective and preventive measures based on the monitoring results. It is important to note that “control” does not imply any covert or secretive activities. If a different term better suits your preference, such as “monitor and improve project communications and stakeholders’ engagement,” feel free to use it.

The purpose of controlling communications and stakeholders’ engagement is to ensure an optimal flow of information and obtain desired support from stakeholders. Satisfaction surveys conducted at phase gates are a typical tool used to gather real data on areas that require improvement in project communication with stakeholders. Another tool is the stakeholders’ engagement assessment matrix, which can be updated by the project management team based on their observations. This matrix compares the current and desired levels of stakeholder engagement, with “C” representing current status and “D” representing desired status. The gap between the two levels for each stakeholder guides the necessary actions to achieve the desired degree of engagement.

Stakeholder	Unaware	Resistant	Neutral	Supportive	Leading
Stakeholder 1	C			D
Stakeholder 2		C	D
Stakeholder 3				DC

The matrix indicates that Stakeholder 1 needs to be “supportive,” but currently, they are unaware. We need to work on improving their awareness, possibly through communication efforts. Stakeholder 2 is categorized as “resistant,” and our goal is to at least make them “neutral,” if not “supportive.” We will need to develop a strategy to address their resistance. On the other hand, Stakeholder 3 is where we want them to be, in a “supportive” status. Our strategy is to maintain their support by continuing our current approach. The stakeholders’ engagement assessment matrix is updated based on observations and communications during the monitoring process.

Moving on to the next controlling area…

Control Material Resources:

The purpose of controlling material resources is to ensure that the project has access to the assigned resources at the right time and place and that they are released when no longer needed. Material resources encompass equipment, raw materials, facilities, and infrastructure. The specific types of physical resources required for a project depend on the product and industry. For example, a biological project may require a device to measure endophytes, a construction project may need austenitic steel, an education project might require an e-learning plugin for a WordPress platform, and an event project may need microphones and loudspeakers. It is important to note that no general statements can be made about the types of material resources needed for projects as it varies greatly.

However, what remains consistent across projects is the need for the project management team to monitor the planned utilization versus the actual utilization of these resources and take corrective action if necessary.

Moving on to the final controlling area in this lesson…

Control Procurements:

The purpose of controlling procurements is to ensure that both the seller and the buyer adhere to the contractual terms. Due to the legal aspects involved in procurement relationships, many organizations have dedicated purchasing departments responsible for contract administration. It is a good project management practice to include the person from the purchasing department in charge of contract administration as part of the project team.

When managing work packages executed by external suppliers, they are treated like any other work package, albeit with more attention to formal aspects, similar to working with colleagues within the organization.

One key concern in controlling procurements is to ensure that payments are tied to the work accomplished. This is where the Earned Value Analysis proves its value. In fact, this technique was specifically developed by the US Army to ensure that payments to suppliers align with the value earned by the project through their contracted work.

In summary, the activities involved in controlling risks, communications, stakeholders’ engagement, material resources, and procurements all fall under the umbrella of “controlling.” This entails tracking and reviewing data from project execution, analyzing it within the project’s overall context to generate meaningful information, identifying areas that require changes to respective plans, and initiating the necessary changes.

4.9 Control phase gates

This section focuses on controlling activities at the boundaries between project phases.

The primary purpose of dividing a project into phases is to enable phase-gate reviews. These reviews, also known by various names such as stage-gates, kill-points, phase-reviews, handoffs, and transition-points, occur at the end of each phase. Their purpose is to allow the project board to evaluate the completed phase, make an informed decision regarding proceeding to the next phase, and approve the planning for that subsequent phase. Additionally, there are administrative activities associated with phase closure.

Planning the next phase:

The planning of the next phase begins with the issuance of a phase plan at the phase gate of the previous phase. For the first phase, this planning is done after the project plan is approved. The closure of the last phase coincides with the closure of the entire project, which will be discussed in a separate lesson.

The phase planning is a condensed version of the project management plan, focusing specifically on the deliverables and activities of the upcoming phase. It should include a phase goal, measurable objectives, deliverables, identification and analysis of stakeholders, risk identification, analysis and response planning, a detailed breakdown of the project work breakdown structure (WBS) for the phase, a schedule with an appropriate level of detail, and a proportionate phase budget.

Another aspect of planning the next phase is the validation of assumptions and constraints that were made in the previous planning. Assumptions and constraints are integral components of any plan.

Evaluation of the ending phase:

The evaluation of the closing phase is based on the phase plan. The key aspect of the evaluation is the achievement of phase objectives, which are realized through the delivery of the phase scope within the allocated time and budget.

One practical way to demonstrate compliance with the objectives is through the use of Earned Value Analysis. Since a phase end should align with the completion of major deliverables, it serves as an appropriate point in time for conducting this analysis. The Earned Value Analysis should not include deliverables that are still in progress; otherwise, the phase end is not well-defined, or the in-progress deliverable should have been broken down in a way that allows completion within the closing phase.

The Earned Value Analysis will indicate whether all deliverables of the phase have been completed and provide Cost Performance and Schedule Performance Indices (CPI and SPI) for each deliverable. If CPI and SPI are both equal to 1 for all deliverables, then the phase objectives have been fully met. Any variance from these indices indicates a certain degree of success that is lower or higher than 100%.

To complete the evaluation, a satisfaction survey targeting relevant stakeholders should be conducted. This survey should focus on the stakeholders’ satisfaction with the project team’s work, as each deliverable has its own acceptance criteria. For example, were professional answers provided in a timely manner? Was the project team easily accessible? Were problems resolved professionally? Was it pleasant to work with the project team?

Another valuable activity conducted during phase closure is capturing lessons learned. Although lessons learned should ideally be collected throughout the project, the phase closure provides an opportune time to distill and document the most important ones. It is important to note that retrospectives should not be limited to phase closures alone but should also occur at intermediate milestones within each phase. Waiting until the end of the project to reflect on areas for improvement is not advisable, as it may be too late to address critical issues. Agile teams, in particular, have popularized the use of retrospectives at the end of each iteration, typically lasting two weeks.

During a retrospective, the focus should not be on assigning blame or identifying culprits. Instead, it is a time for the team to learn from their previous work and make incremental improvements. The retrospective is not meant to inspect the product, as this is addressed in deliverable review meetings, as explained in the lesson on defining, delegating, and approving work packages.

By conducting retrospectives in this manner, the team can leverage the wealth of lessons learned throughout the phase, avoiding the need to start from scratch in identifying lessons learned from weeks or even months ago, especially in large projects with long-lasting phases. It is crucial to document lessons learned, and phase closure provides an excellent opportunity to distill and capture the most important ones.

The two key questions to consider during the phase retrospective are: What was done well? and What could have been done better? The benefits of conducting effective retrospectives include improved team performance and an overall more fulfilling project experience.

Deciding Whether to Proceed to the Next Phase:

The decision on whether to proceed to the next phase is analyzed from two angles. One angle involves the forecast shown in the Earned Value Analysis. If the forecast indicates a negative outcome, the project board may decide to either cancel the project or reduce the scope to realize partial benefits in light of the unfavorable developments.

The second angle considers the business case review. The business case serves as the foundation for initiating the project. Assumptions and high-level estimates of delivery time and costs were made to estimate the expected benefits. At phase closure, with real data and forecasts from the Earned Value Analysis, it is necessary to update the business case. The updated business case is then used as input to the project board for them to confirm or reject the continuation of the project.

Unfortunately, many projects continue progressing for months, if not years, expending organizational resources and efforts only to end up with results that significantly differ from what was initially projected in the business case. The project management team can avoid such failures by ensuring that the project remains aligned with the organization’s strategic objectives. This alignment can be achieved through periodic validation of the project and its business case during phase-gate reviews. The findings from this exercise may lead to one of the following outcomes:

• Termination of the project
• Proceeding with the project as planned
• Modifying the business case and/or the project

It’s important to note that a decision not to proceed is not necessarily a failure. Projects can encounter challenges or be affected by external factors that render the initial business justification invalid. Alternatively, the organization may have shifted priorities, necessitating the reallocation of resources to other initiatives. The true failure lies in continuing with a project despite evidence suggesting it would be better to discontinue.

Administrative Closure

The most crucial aspect of administrative closure is confirming that the deliverables of the phase have been formally accepted and transitioned to the relevant organization. If the deliverable being transitioned is the final deliverable, the recipient is the customer. This scenario applies when the project delivers the product incrementally. However, if the deliverable is a component of a larger deliverable in production, the recipient is the new team for whom the deliverable from the closing phase serves as an input in the next phase.

Note that the acceptance of deliverables itself is not part of the phase-closing activities. Each deliverable must have already been formally accepted, as explained in the section on “defining, delegating, and accepting work packages.” During phase closure, the focus is on confirming that the acceptance has taken place. There should be documented evidence of acceptance for each deliverable. If any acceptance document is missing, this is the appropriate time to obtain it.

Another important administrative element of closing a phase is releasing team resources that are no longer needed in the next phase. This includes conducting performance evaluations. If necessary, refer to the section on the project manager’s activities during the “adjourning stage” in the lesson on “developing the team.” Additionally, resources extend beyond human resources and also encompass project facilities, equipment, excess material, and other physical resources that will no longer be required. These resources should be reallocated or discontinued accordingly.

If there were external suppliers working on the project, the project manager verifies that both parties have fulfilled their contractual obligations towards each other. Any outstanding obligations should be addressed, and agreement on open claims should be reached. If necessary, these matters can be handed over to the legal department. The performance of the supplier is evaluated as well.

Other activities involved in administrative closure include:

• Archiving project information
• Ensuring that all project logs, such as the issues log, lessons learned log, risks log, and change log, are updated.

In summary, the purpose of controlling phase gates is to enable the project board to evaluate the completed phase, make an informed decision on whether to proceed to the next phase, and approve the planning for that subsequent phase. Administrative closure activities are performed, leveraging lessons learned from both intermediate milestones and the entire phase as a whole.

 

 

5.1 Closing the last project phase and the entire project

Closing the Last Project Phase and Project Closure

During the closing of the last project phase, which coincides with the closure of the entire project, several activities are combined with the project closure. Let’s explore each of these activities individually.

Evaluation, acceptance, and transition of accomplished deliverables, and performance evaluation:

The evaluation criterion for a phase or the project as a whole is the successful accomplishment of objectives. These objectives pertain to the scope of delivery in accordance with requirements, within the defined time and budget, and any other specified success criteria.

Regarding the scope of delivery in the last phase, it represents the completion of the project’s scope. Acceptance and transition of the deliverables from the last phase signify the acceptance and transition of the final deliverable of the project. The functional requirements and quality attributes of the deliverables from the last phase must align with the product requirements established for the completed key deliverable of the project. During the review meeting of the solution, you would present documentation demonstrating that the acceptance criteria have been fulfilled.

When evaluating schedule and cost performance at project end, the schedule baseline and cost baseline are best utilized. The Earned Value Analysis becomes less useful at this stage. Its strength lies in serving as an early indicator of trends. However, at project end, the earned value and planned value are both 100% unless the project was terminated prematurely without delivering the solution. If the project did deliver the solution, the work performed is 100% of the planned work, resulting in no schedule variance and a schedule performance index of 1, even if the project finished behind schedule.

Therefore, the earned value analysis is not effective in measuring schedule performance at project end. However, it can still be used to assess cost performance by comparing the earned value (which equals the approved budget at completion) with the actual costs incurred. For instance, if the budgeted scope was 100 and the actual costs amounted to 140, a cost performance index of 0.71 would realistically indicate a cost overrun.

Due to the peculiarities of the earned value analysis at project end, it is advisable to compare the actual delivery date and actual costs with the schedule baseline and cost baseline. However, if these baselines were modified during the project through approved changes, it becomes debatable whether the original baselines should be used for comparison. Consider a scenario where change control procedures were followed, resulting in updates to the baselines to reflect necessary changes during execution. If the change control authority approved these changes, they also approved the impact of those changes on the schedule and cost baselines.

Nevertheless, there are cases where comparisons are made to the original baselines, regardless of the changes that occurred throughout the project. It is not uncommon to hear news reports stating that “Project X, originally budgeted for Y, was completed with a 400% budget overrun and a three-year delay.” Such comparisons are made without considering the project’s evolution. In such situations, not only explanations are required at project end, but political skills may come in handy. If you have successfully managed such a project, you likely possess the political acumen to demonstrate its success. On the other hand, if you took over as the new project manager, the political responsibility for any failure would fall on the previous manager. Sponsors rarely take responsibility for project failures, preferring to place the blame on the project manager.

Evaluation of Stakeholder Satisfaction

The evaluation of stakeholder satisfaction is a standard component of both phase closure and project closure. For stakeholders who were involved throughout the entire project, you can combine the satisfaction survey for the last phase with the one for the entire project. However, for stakeholders who only participated in the last phase, the survey would be part of the phase closure process.

Lessons Learned

Lessons learned are integral to both phase closure and project closure. In the context of the last phase, there will be lessons specific to the type of work conducted in that phase. When gathering these lessons, you are effectively closing the last phase. Lessons specific to construction or user training during the deployment phase, for example, offer unique insights that can be valuable for future similar projects. While they may not directly impact subsequent phases, they can benefit the organization when executing similar projects in the future.

Lessons learned from a holistic project perspective may or may not add to the insights captured during each phase closure. The main task at project end is to compile the lessons learned and documented from the closure of each phase. Distilling the most important lessons with a full project perspective can provide significant value.

The areas described above for project evaluation should be included in a project closeout report. This report would cover the achievement of project objectives, delivery of the defined scope, time and budget performance, stakeholder satisfaction, and a summary of lessons learned. It is also advisable to include a list of follow-up activities, such as requirements that were not implemented but could be addressed in potential follow-up projects or any other activities to be performed by the new owner of the project deliverable.

Decisions about Continuation

In previous phases, there was a process in place for planning and approving the next phase. However, during the closure of the last phase, there is no next phase to plan for. Therefore, this aspect of controlling phase gates is not applicable to the last phase of a project.

From a whole project perspective, planning a follow-up project would also not occur at project end. The decision regarding a potential follow-up project should go through a portfolio management process governed at the corporate level. The organization’s management may have different priorities that do not involve initiating a follow-up project to address any remaining requirements from the current project. If the closing project is part of a program, it is likely that another project within the program will utilize the key deliverable from the closing project. However, this falls under the purview of program management rather than project management. Thus, this aspect of closing does not apply to the last phase of a project or to the project as a whole at its closure, at least not from a project management perspective.

Administrative Closure

At the end of the last phase of a project, specific administrative closure activities are conducted. While they may resemble project closure activities due to it also being the end of the project, from a conceptual standpoint, these activities are considered phase closure activities.

For example, releasing resources utilized in the last phase and addressing any outstanding claims are part of phase closure. Evaluations are performed as they would be at the end of any other phase. If there are resources and suppliers that have been involved in the project throughout its entirety, they would be released at project end. Conceptually, this would be part of project closure. However, it doesn’t prevent the project management team from evaluating them at the end of each preceding phase.

Archiving project information and ensuring that all project logs are updated, the last two activities of phase closure, are also performed at the end of the last phase. From a project closure perspective, these activities involve consolidating and cleansing all the files and transferring them to the appropriate organizational repository.

Project Success

At the end of a project, two questions need to be answered: Was the project successful, and is there anything else that needs to be done?

To answer these questions, it is necessary to revisit the project charter, which contains the project success criteria and business requirements.

The project success criteria should have been addressed through the evaluation elements explained earlier. The business requirements specified in the project charter represent the capabilities that the organization aimed to acquire when initiating the project. The answer to this question depends on how well the project scope was defined, not delivered. The evaluation of the defined scope focused on how well it was delivered. However, when considering the business requirements, we are assessing how well the scope was defined to achieve the desired capabilities for the organization.

If the project charter was well-developed, the answer would be yes. However, if there was a mismatch between the business requirements and the defined key deliverable intended to fulfill those capabilities, the project would have delivered the defined scope in terms of product requirements, within the allocated time and budget, but it would not have provided the envisioned capabilities to the organization. In such cases, another project would be necessary to bridge the gap, resulting in the closing project receiving a less than perfect rating despite delivering the defined scope on time and within budget.

Lastly, it is important to consider the benefits of the project. This can be a potential trap for the project manager. It is crucial not to fall into it. The business case used to justify the project may indicate an expected return on investment of, for example, 16%. However, your project success criteria should not include achieving a 16% return on investment because it cannot be accomplished at project end. Your project success criteria should be attainable within the scope of the project’s deliverables.

From a sponsor’s perspective, the organization will expect to achieve the 16% return on investment and other benefits defined in the business case. However, this falls outside the scope of the individual project and becomes a matter of program and portfolio management. These higher-level initiatives encompass operations, programs to attain benefits, and the achievement of corporate goals through portfolios.

From the project manager’s perspective, if the project delivered according to the project baseline, including the other elements of success defined in the project success criteria (including business requirements and project management requirements), then the project team and project management team can and should celebrate success. They deserve recognition for their accomplishments.

On that note, congratulations on completing this book!