Back to Basics, Part 6: Initiation

We need to do better. Our current project management practices do not predictably deliver value.

Better project results come from consistently and reliably applying fundamental practices. “Back to Basics” highlights the core principles of simplicity, intentionality, and practicality. Clear, value-driven guidelines and practices enable project teams to make pragmatic, deliberate decisions rather than blindly following rigid standards.

“Back to Basics” is a series of articles that highlights the project management practices that lead to better, more reliable outcomes. The first six articles covered the state of the industry, the importance of establishing guiding principles, advice for choosing an approach, a framework, and the way of working.

This article explains the initiation phase, which establishes the project’s foundation. The outcome is a clear set of commitments and understandings. Without this alignment, stakeholders’ expectations will not be met.

The CIO mused that a new application might fill an unmet need. A development manager saw this as an urgent request and tasked the team with building it. They proceeded without sponsorship, approval, or a formal charter. After completing the development, the manager reported the achievement to the CIO, hoping for praise. However, he was met with a bewildered and annoyed boss. This was not an official request; the CIO was just musing aloud.

Initiation Phase

Contents

Initiation Phase
- Understanding the Context
The Project Charter

The initiation phase lays the project’s foundation. Before initiation, projects undergo a selection and funding process. Inputs such as the business case, benefits management, and realization plans inform this decision.

The project charter is the phase’s main artifact. It outlines the project’s context, goals, and opportunities and threats. Ensuring stakeholder alignment on the “what” and “why” is essential to the project’s overall success.

The project sponsor plays a dual and vital role during the initiation phase. They are accountable to the organization for delivering the benefits defined in the business case. They are also responsible for ensuring the project has the resources and support to succeed.

The sponsor, along with other organizational leaders, approves the charter. This affirmation can be leveraged by the project manager.

Understanding the Context

Every project is unique and operates within its own context, and has its own environmental factors; including:

The organization’s culture, which encompasses risk tolerance, decision-making practices, and structure;
The team’s maturity level, skills, trust, and cohesion, and whether co-located or virtual;
Regulatory, contract constraints, and operating procedures; and
Stakeholders’ expectations, degree of alignment, and level of engagement.

Honoring the context is critical to planning and structuring the project. For example, teams in highly structured, risk-averse environments will likely fail if they are required to “be Agile” without sufficient preparation.

Elements of the context can shift as the project progresses. This can be driven by changes in the operating environment, market conditions, or key stakeholders and their expectations.

The Project Charter

The project charter, or a similar document, is a critical output of the initiation phase and represents an agreement between the requesting and delivering organizations. It also designates and authorizes the project manager, defining their formal role and decision-making authority. As questions and conflicts emerge, the charter can serve as a resource to “re-ground” stakeholders in the original intent.

The following are the primary components of the charter:

Stakeholder Register and List

During the initiation stage, the stakeholder register is created. The register is a detailed, working document used to capture information about stakeholders and analyze their needs. It often includes assessments of stakeholder power, influence, interest, impact, and current versus desired engagement levels. The list is a summary included in the charter.

Objectives, High-Level Requirements, and Scope

The charter builds on the business case and provides a more refined, elaborated view of the objectives, high-level requirements, and scope. As more stakeholders are engaged as the project moves into the initiation stage, the objectives may shift, and a clearer view of the scope and more detailed requirements will emerge. Project boundaries—what will not be done—may also be documented.

The charter should clearly define the project’s “what” and “why.” The “what” describes the project’s outputs. The “why” establishes the objective or desired outcome. Incorporated in the “why” is an understanding of the problem to be solved. A robust alternatives analysis should be conducted to ensure the “what” is the most effective way of delivering the “why.”

Initial Schedule, Cost, and Performance Measures

The detailed project scope, schedule, and cost will be developed during the planning phase. At this point, the goal is to establish consensus on roughly what the project will deliver, how long it will take, and how much it will cost. These are still order-of-magnitude estimates that represent a range of outcomes. Other key performance measures may also be established; common examples include quality and product performance standards.

Refining the project performance goals is an iterative process as trade-offs are considered and decisions are made. Creating stakeholder alignment will be critical to the project’s ultimate success. Disagreement at this stage will be a strong predictor of future challenges. However, agreement will not guarantee success. Influencing, coalition-building, and decision-making skills will be valuable for creating and maintaining consensus and support.

Success Criteria

Defining the success or exit criteria at the beginning of the project motivates stakeholders to clarify their expectations and provides the project team with a clear view of success. This can be a valuable forcing function and resolves the “I will know it when I see it” conundrum. Well-established exit criteria may be required to enter the planning phase.

Initial Risks, Assumptions, and Constraints

Risks are opportunities and threats. At this stage, the focus should be on strategic items that could have a significant impact on the project and may inform requirements, scope, and project approach. Optimism often prevails at this phase; consequently, the risk log should be robust and avoid bias.

Assumptions are the things we know we don’t know. They can relate to the development and operational environments, and are used to develop initial plans, estimates, and designs. Without assumptions, it is often impossible to proceed. They should be documented and validated as soon as feasible.

Constraints limit the project and include contracts, operating agreements, regulations, internal procedures, and laws of nature. They represent project boundaries. Documenting the relevant constraints at the appropriate level of detail helps keep the project out of trouble.

Assumptions and constraints are also project risks and should be cross-populated in the risk log.

Initiation creates the project’s foundation. In the next article, I will discuss the planning phase, where the expectations are clarified and established.

See related articles:

To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/.