4.1 Statement of Project Justification

All projects are created for a reason. Often, the pressure to produce results encourages people to identify possible solutions without fully understanding the needs and purposes of the project. This approach can create a lot of immediate activity, but it also creates the likelihood that the change initiative will fail to deliver the proposed organizational value.

Miscommunication is a common occurrence in our everyday lives. Even something as simple as ordering food can lead to misunderstandings. For instance, a waiter brings us our dinner and we note that the baked potato is filled with sour cream, even though we expressly requested no sour cream. Misunderstandings are not intentional; they simply speak to the challenges associated with effective communication.

One of the best ways to gain approval for a project is to clearly communicate the project’s objectives and describe how the project provides a solution for an organizational need or opportunity. A needs analysis is often conducted to better understand the underlying organizational needs and how meeting these needs would help the organization increase its success. Once alternative solutions are identified, each is assessed to determine if it supports the organization’s vision and strategies. Issues of justification (“should we do the project?”) and feasibility (“can we do the project?”) are addressed. A final recommendation is determined after all solutions and issues are assessed. It is important to note that project justification is a key part of the project initiation phase. If issues of justification are not adequately addressed, the project will lack the required organizational support and, therefore, will ultimately be unsuccessful. An effective project justification document contains the following:

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

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

Often, the project leader is part of the project justification work. If not, a project leader is appointed shortly after this work has been completed. The project leader then begins to develop the project infrastructure to support all the activities associated with planning, executing, monitoring, and closing the project. The project leader conducts one or more kickoff meetings to align all the various stakeholders. The strength of the initial alignment will have a big impact on project success. At this early stage, the project leader is learning to identify the appropriate means of communicating with key stakeholders. Effective communication with project stakeholders is another critical success factor so this work must begin early.

Team building begins and collaborative approaches for working together are discussed. During these meetings, the project leader will share:

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

This information and the decisions that go along with it are often captured in a document referred to as a project charter. Just like with project justification documents, low complexity projects may have very short project charters while higher complexity projects may require longer, more comprehensive project charters. In either case, there are two very important aspects of the project charter: key stakeholders, who specifically detail their respective roles and responsibilities, and project success measures.

Similar to the project justification document, the project charter must also be approved by the project sponsor. This document formally recognizes the existence of the project by presenting the project leader’s understanding and conceptualization of the project’s objectives. Most importantly, it authorizes the project leader to apply organizational resources in order to achieve the project’s objectives. Once it is approved and formally signed off, it becomes an agreement between the project leader and the project sponsor. As such, some organizations prefer to refer to this document as a letter of agreement instead of a project charter. The title and form of the document are not important. Approval of this document, whether a letter of agreement or a project charter, signals the transition into the planning phase of the project.

4.2 Assessing Organizational Constraints and Trade-Offs

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

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

• Scope encompasses the work involved in delivering on the project’s objectives and the processes used to complete the work.
• Schedule encompasses the time available to complete the project.
• Cost encompasses the amount of money available to complete the project and includes support for the resources, supplies, and other materials required to produce the project outcomes.
• Quality encompasses the standards and criteria the project’s deliverables must meet in order for them to perform effectively. The end outcomes must meet stakeholders’ expectations and performance requirements, and service levels, such as availability, reliability, and maintainability, as well as deliver on its anticipated organizational benefits/value.

Project management has many practical applications for everyday life and a great way to highlight this is to look at the triple constraints for planning a vacation. Unfortunately, it is very unlikely that we can spend as much money as we want, stay for as long as we want, and travel any place we want. We must decide what our priorities are. If we treat the budget (cost) as our priority, it will have implications for how long we can stay (schedule) as well as the nature (scope) and overall quality of the accommodations, flight, and/or food we select.

In this example, we achieve our budget objective (fixed at $2,000) by making trade-offs with our vacation schedule and the destination (scope). If your circumstances change and you happen to have more money available for your vacation, you can evaluate the implications this has on the other constraints. For instance, you may choose to stay longer (modify your schedule), book more day trips throughout your stay (modify your scope) and/or select a hotel with more amenities (modify the quality). The opposite could be true as well. If you discover that the cost of the flight has just gone up, you would have to identify ways to reduce the costs associated with other aspects of your vacation. You could decide to shorten your stay (reduce your schedule), eliminate some of your day trips (cut scope), and/or select a hotel with fewer amenities (reduce quality).

In organizations, the circumstances surrounding project delivery may also change. For instance, if your project sponsor requests more features/functionality in the product, service, or result delivered by the project (scope modification), this may require more money and/or more time. The decisions we make about the triple constraints have broader implications. We need to consider the resource requirements and the uncertainties (risks) associated with our plans to achieve the project outcomes.

These examples effectively highlight the interdependencies between cost, schedule, and scope, and their implications on quality. It all starts with understanding the organization’s priorities. This gives the project leader and development teams the guidance needed to make effective recommendations and decisions.

4.3 Stakeholder Identification and Management

A project is successful when it achieves its objectives. The objectives need to be clear, measurable statements of organizational value. Ultimately, a project’s stakeholders will determine if the expected value was delivered.

Stakeholders are individuals who are impacted by the project or who are impacting the project. They are the people who are actively involved in carrying out the work of the project and/or have something to either gain or lose as a result of the project. The project sponsor is typically the most powerful stakeholder. They often initiate the project and as such, are often referred to as the “initiating sponsor.” They have the authority to start and stop the project and will support the achievement of project objectives by removing the barriers to success. They can be regarded as the “external champion” because they often serve as the last escalation point when the project team needs support bringing an off-track project back on track. Successful project teams know how to leverage the power and position of the project sponsor and will proactively ask them to deliver influencing communications throughout the organization in order to maintain the project’s momentum and high morale within the team. Many project sponsors assign one or more sustaining sponsors to act as the “internal champion(s)” of the project. The sustaining sponsors are often leaders of the internal departments that are most affected by the project, such as a marketing manager or human resources manager. When the project sponsor selects the sustaining sponsor(s), one of their goals is to ensure that the project team frequently considers the organizational impacts of the changes being introduced. By keeping the sustaining sponsor(s) actively engaged in the project, they will ensure their teams are intently participating in the project and identifying the operational impacts that must be considered in order for the change to be sustained once the project has been completed. On a day-to-day basis, the sustaining sponsor(s) act as the first point of escalation as issues/risks are raised.

A successful project leader will identify all stakeholders. The project sponsor and the sustaining sponsor(s) are very helpful in identifying additional project stakeholders and often consulted early in the project. Depending on the nature of the project, departments such as information technology, human resources, finance & accounting, engineering, manufacturing, and marketing are also considered to be project stakeholders. In addition, external stakeholders often include customers, suppliers, and regulatory bodies. During project initiation, it is important to effectively identify a comprehensive list of project stakeholders. This will allow the needs of these stakeholders to be identified and considered throughout the project. The stakeholders are then included in the project charter which must be approved by the project sponsor before the planning phase can begin.

For high complexity projects, it may often be challenging to maintain an accurate picture of all the stakeholders. New stakeholders can arise at any time, and the needs and interest levels of a particular stakeholder may change through the course of the project. A stakeholder register is a powerful tool and it is specifically designed to assist in stakeholder management.

Exhibit 4.2: Example of a stakeholder register. (accessible version)

In addition, it is important to prioritize stakeholders. Some stakeholders have little interest and little influence in a project and as a result, do not require as much contact from the project team. Understanding who these stakeholders are allows the project team to spend more time with the stakeholders that have a significant interest in the project and who exert significant influence over the project. Project teams assess the interest and power/influence of project stakeholders by researching their position, their actions in previous change initiatives, and by directly speaking with them about the project. Let us delve into how the assessment is done.

When considering a stakeholder’s interest, assess the following:

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

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

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

After the initial assessment has been completed, stakeholder prioritization can occur. A power/interest grid is a very helpful tool for prioritization. It helps project leaders categorize stakeholders and create effective communication strategies for each category of stakeholder on the project.

Thinking back to our vacation project, the following individuals could be our stakeholders:

1. Spouse (assuming they join you)
   • High interest
   • High influence/power
2. Neighbour (volunteered to watch over your house)
   • Medium interest
   • Low influence/power
3. Airline company (a vendor; critical in helping you reach your destination)
   • High interest
   • High influence/power
4. Hotel (a vendor; critical in achieving your quality expectations)
   • High interest
   • High influence/power
5. Insurance company (a vendor; critical in providing peace of mind for travel-related risks)
   • Medium interest
   • Medium influence/power

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

Exhibit 4.3: The five stakeholders in the example above superposed on a power/influence and interest matrix.

Project leaders need strong soft skills to carry out this work effectively. Project leaders generally have little or no direct authority over any of these individuals, making stakeholder management particularly challenging.

4.4 Selecting the Right Development Methodology

Determining which development methodology to use is one of the key decisions project leaders must make. Generally speaking, projects with a clear vision of the solution(s) are implemented using the predictive (waterfall) methodology. Note: for the purposes of this text, we will consider the terms “predictive” and “waterfall” as interchangeable. Since the solution(s) are well defined, it is possible to define all the requirements upfront. In situations where the solution(s) can not be well defined, adaptive development methodology is used. This allows the requirements to evolve over time. Instead of working with end-users to define what is required before development begins, development occurs in an iterative or incremental cycle. There are several adaptive development methodologies. Predictive and adaptive development methodologies are very different. It is important for project leaders to clearly communicate how the work will be managed depending on the selected approach.

When the adaptive development methodology is used, a much higher degree of stakeholder involvement is required. This is not always seen as a positive because many stakeholders face competing demands for their time and change initiatives. Moreover, despite the priority of the project, key stakeholders may be unable to dedicate an adequate amount of time to the project. In addition, the organization requires clear “product/process owners” to be involved in the planning of each adaptive release as the project’s solutions are defined. Organizations that lack this type of ownership structure are likely to struggle with the use of an adaptive methodology.

Lastly, it is possible for some projects to use a combination of the approaches in situations where some of the solutions are well-defined while others remain unclear. This is referred to as the hybrid approach. For instance, a project may involve the deployment of new technology, the move to a new office location, and a reorganization of staff reporting relationships. It is possible for the new technology to not be well-defined while the requirements associated with the new location and organizational structure are well-defined. In this circumstance, the adaptive approach would be used to develop solutions for the technological aspects of the project and the predictive approach would be used to define and implement the transition to a new office location and organizational structure.

In summary, project leaders need to be able to highlight the pros/cons of each approach. In situations where the organization runs the risk of developing solutions that do not deliver the expected organizational value because the requirements are not fully known, project leaders who are able to effectively communicate this risk are likely to gain stakeholder support to use the adaptive approach.

Agile

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

Exhibit 4.4: The adaptive nature of Agile
^Tricentis

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

Scrum

Scrum is a product development methodology and part of agile project management. Scrum is a term from rugby (scrimmage) that refers to a way of restarting a game. It is like restarting the project efforts every few weeks. It is based on the idea that you do not really know how to plan the whole project upfront, so you start with what you know and then re-plan/iterate from there.

Scrum uses sequential sprints for development. Sprints are like small project phases (ideally two to four weeks). The idea is to take one day to plan for what can be done now, then develop what was planned for, and demonstrate it at the end of the sprint. Scrum uses a short daily meeting of the development team to check what was done yesterday, what is planned for the next day, and what (if anything) is impeding the team members from accomplishing what they have committed to. At the end of the sprint, what has been demonstrated can then be tested, and the next sprint cycle starts.

Scrum methodology defines several major roles. They are:

• Product manager/owner: essentially the business owner of the project who knows the industry, the market, the customers, and the business goals of the project.
  • Builds consensus within the end-user community
  • Communicates end-user expectations to the development team
  • Provides acceptance on completed feature definitions in the solutions and the completed user stories
  • Usually accountable to the project sponsor. If the project has two project sponsors (one from the business and the other from IT), the product managers would report to the business sponsor.
  • “Owns” the content (what is built and in what sequence)
• Business area lead (AKA subject matter expert or SME): is from a particular business unit and may be an end-user or directly represents the end-users.
  • Works very closely with the product manager/owner to develop the vision for the solution
  • Helps clarify business needs and expectations
• Scrum master:
  • Removes barriers that impede the progress of the development team
  • Helps the product owner maximize return on investment (ROI) in terms of development effort
  • Facilitates creativity and empowerment of the team
  • Improves the productivity of the team, as well as engineering practices and tools
  • Runs daily stand-up meetings
  • Tracks progress
  • Ensures the overall health of the team
• Development team: a highly empowered group that participates in planning and estimating for each sprint.
  • Develops the solution in sprints
  • Demonstrates the results at the end of the sprint
  • Sometimes (depending on the organization) involved in testing, including functional testing (confirming the software requirements have been met) and non-functional testing (security, usability, performance)

The role of the project manager varies by organization. Some organizations using scrum give some of the project manager’s accountabilities (particularly arranging for project funding, risk management, and iteration planning) to the product owner. However, the team management aspects are less likely to be assigned to the owner because they often require significant time commitment if the project has a large cross-functional team. In these cases, a project manager may be assigned not only to lead the project team but also to manage the budget and schedule commitments of the project. This frees the product owner to focus on what is being built as well as the end-user community. When all three roles – product owner, scrum master, and project manager – are present on the project, they all must work toward project success in a highly collaborative fashion.

Solutions developed with agile methodology typically start with an epic. An epic is the rough outlines and boundaries of the solution. It frames the organizational value to be delivered by the project. It serves as the starting place for analyzing what is required. Through analysis, the required capabilities and enablers are identified. The features (deliverables that will fulfill stakeholder needs) of each capability are then identified. These features can then be further broken down into user stories to represent smaller pieces of the functionality. The user stories go into a product backlog. Lastly, each story is then broken down into tasks. The tasks are what the team members would complete in order to define, build, and test a user story.

Iteration planning is very important in agile methodologies. This is where the scope of the iterations is determined. Ultimately, iterations representing about two weeks’ worth of effort are formed and referred to as sprints. As one sprint is developed, it is tested then shared with the end-user community for feedback. Further iterations are implemented as required.

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

References

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