Project Initiation and the Project Charter

What Happens Before Planning Begins

A project does not start when work begins. It starts when the work gets authorized, and that authorization is not a rubber stamp. Before a single deliverable is scoped in detail, before a schedule is built, before resources are confirmed, there is a phase whose entire purpose is to establish the authority and direction that everything else follows. That phase is initiation. By the time it is complete, the project has a formal authorization document, a named project manager with a recognized mandate to coordinate and direct project work, and a mapped stakeholder landscape. Without those things, planning rests on unstated assumptions. Unstated assumptions become disputes about scope, budget, and accountability the moment anything goes wrong. Initiation is not the formality before the real work starts. It is the work that makes everything following it possible.

Initiation has two core outputs. The first is the project charter, the document that formally authorizes the project and establishes the project manager's mandate to act. The second is the stakeholder register, a map of everyone affected by or involved in the project, built before any planning decisions are made. These two outputs are not interchangeable and the sequence is not accidental. You cannot plan stakeholder engagement for people you have not yet identified. You cannot run a credible authorization process without knowing whose interests the project needs to account for from the start.

The Project Charter — What It Is and How It Gets Built

A project charter is a formal authorization document. Not a summary, not a plan, not a memo. A document that formally authorizes the project to exist and gives the project manager the authority to apply organizational resources toward defined objectives. Without a charter, a project manager has no formal mandate. When scope is disputed, when resources are contested, when a stakeholder challenges a decision, the charter is the reference that establishes what was agreed before the work began. Building it is a collaborative process: the sponsor provides strategic direction and confirms the objectives the project is expected to achieve; subject matter experts contribute scope details, requirements, and realistic estimates; the project manager steers the process, organizes the contributions, and ensures the document is complete and internally consistent.

The process of building a charter typically starts with a conversation with the sponsor: what business problem is being solved, what does success look like from their perspective, and what constraints is the organization operating within before the project even begins. From there, the PM works outward through structured sessions with subject matter experts to develop both sides of the scope, requirements sessions to establish what each deliverable must satisfy, and cost input from people who have done similar work or can benchmark against comparable projects. For the RtR relocation, this meant separate conversations with the Office Manager, who owned the workspace logistics; the Fleet Manager, who understood the vehicle and equipment requirements; the Operations Director, who set the commercial strategy; and field staff, who would be most affected by the cutover. Each person contributed a piece the others could not see. The final document assembled those contributions into a single coherent agreement. The sponsor's signature should mean all the right people have been heard before the commitment is made.

Goals and Deliverables — The Why and the What

Every charter starts by answering two related questions that are easy to conflate. Goals and objectives capture why the project is being done: the business outcomes the organization expects it to create. Deliverables are what the project will physically produce or complete to achieve those outcomes. These are not the same thing. Treating them as if they were is one of the most reliable ways to end up building the right thing for the wrong reason, or the wrong thing for a perfectly stated reason. For a company relocating to a commercial district to improve emergency response times, the goals are stated as outcomes: faster commercial emergency response, greater visibility in the target market, and a stronger foundation for commercial revenue growth. The deliverables are specific and tangible: selecting and acquiring a commercial location, relocating all staff and equipment, installing and configuring security and communications technology, and managing the entire transition from current site to new. Goals answer why the organization is investing. Deliverables answer what the PM is accountable for producing. Both belong in the charter, and they are only aligned when you write them down separately and confirm they connect.

Scope — Both Sides of the Line

Scope is the most consequential section of any project charter, and it works only when both sides of the boundary are explicitly stated. In-scope items define what the project will do. Out-of-scope items define what it will not, and that list matters just as much. Without a clear out-of-scope list, stakeholders fill the gap with their own assumptions. When those assumptions collide with the project's actual plan, the result is scope creep: a frustrated team and a sponsor defending a project they no longer recognize. Writing out-of-scope items is not about protecting the PM from extra work. It is about locking in agreements before the conversation becomes a conflict. For the RtR relocation, the in-scope list covered seven specific items: researching and acquiring a new commercial location, moving all staff workstations and office furniture, transporting equipment and fleet assets, updating contact information and the company website, identifying infrastructure gaps at the new site, managing the change process for staff, and coordinating new fleet vehicle decals. The out-of-scope list was equally specific: advertising campaigns for the new location, staff personal items, any form of commute compensation, client notification (handled by a parallel marketing and customer communications effort), new departmental procedures triggered by the move, and pay-and-benefits items. Each exclusion exists because someone anticipated where a stakeholder might assume the project covered something it was never designed to address. Writing it down converts that anticipation into a shared agreement.

Assumptions, Constraints, and Dependencies

These three concepts are frequently grouped together because they appear in the same charter section, but they do different things and protect the project in different ways. Assumptions are the conditions your estimates depend on being true. If an estimate is based on departmental staff being available part-time for project tasks, that is an assumption, and it should be stated as one, because if it proves false, the estimate needs to change. Constraints are the limits the project must operate within regardless of what the team might prefer: a hard deadline, a budget ceiling that cannot be exceeded, a regulatory requirement that shapes how the work must be structured. Dependencies link this project to other work happening in parallel or in sequence: a marketing campaign that cannot launch until the relocation is complete, a system upgrade that must finish before the new office can be certified operational. Documenting all three converts invisible conditions into visible, agreed terms. When an assumption later proves wrong, the charter gives the PM a documented basis for raising the issue and requesting a plan adjustment, rather than silently absorbing the impact while the schedule compresses and nobody understands why. When a constraint shifts, the charter shows what was agreed at the start. When a dependency is delayed, the charter establishes who needs to know and what the downstream effect is. These sections protect the project not because they prevent problems, but because they ensure that when problems arrive, the team has a shared reference point rather than a dispute about what anyone agreed to.

The Assumption Log — Keeping Assumptions Honest

The assumptions recorded in the charter represent your best understanding at initiation. But project conditions evolve, and an assumption that was reasonable in June may no longer reflect reality in September. The assumption that departmental staff will be partially available for project tasks may not survive the arrival of a competing operational priority. The assumption that suitable commercial properties will be available within the search area may not hold after the first three weeks of property research. An assumption that goes unchecked is not a planning input. It is a hidden risk, and it tends to surface at the worst possible moment.

The assumption log is the document that keeps assumptions honest throughout the project's life. Unlike the charter, where assumptions appear as a point-in-time list, the assumption log is a living record designed for ongoing review. It captures each assumption individually: what it states, when it was made, who is responsible for monitoring it, what evidence would confirm or invalidate it, and the current validation status. At regular intervals, or before any significant planning decision, the PM reviews the log and asks a direct question about each entry: is this still true? When an assumption holds, that confirmation is recorded. When one proves false, it is marked as invalidated and the team assesses what needs to change as a result.

An invalidated assumption is a risk that has materialized. The chain that follows is the same one applied to any realized risk: understand the impact, determine the response, and decide whether the change rises to the level of a formal change request. The assumption log makes that chain traceable and documented. Without it, teams tend to discover invalidated assumptions late, often after decisions have been made that relied on conditions that were no longer true. The log is a simple artifact with a significant practical effect: it converts a list of static beliefs into a monitored set of conditions that the project team stays accountable to throughout delivery.

Requirements — What the Deliverable Must Be

High-level requirements are distinct from scope, and the distinction matters enough to deserve its own section in the charter. Scope says what you are acquiring. Requirements say what it needs to be. If scope says the project will find and acquire a new office location, requirements define the specifications that location must satisfy to be acceptable: minimum floor space, required facility types, vehicle access requirements, occupancy capacity, layout specifications. These are not preferences. They are the acceptance criteria that determine whether the scope item, once delivered, actually fulfills the commitment. Without requirements, a project can deliver exactly what was scoped and still be told the deliverable was wrong. For the RtR relocation, the requirements section specified that the new location must include at least 10,000 square feet of warehouse space with a loading bay, a fleet service bay, separate kitchen and washroom facilities for office and warehouse staff, office space for 40 people, three meeting rooms, and an open area capable of holding groups of up to 100. Scheduling requirements specified that office staff should move within a single 24-hour window, and field operations must maintain continuous availability throughout the cutover period. These requirements could not have been derived from the scope statement alone. They represent the team's detailed understanding of what the deliverable must contain. Once in the charter, they become the benchmark that governs the property search and the acceptance review at the end.

The Estimate, the Risks, and Critical Success Factors

A project charter includes a rough order-of-magnitude estimate: not a precise budget, but a credible cost and schedule range grounded in what is actually known at this stage. At initiation, estimates carry a wide accuracy range because the detail needed for precision does not yet exist. Precision at initiation is false confidence. The information required to justify a tight budget number does not yet exist. What the charter needs is a realistic range supported by expert input, alongside the risks that could affect it. For RtR, the estimate totalled $368,000, broken across four line items: moving costs, site renovation, security installation, and real estate consulting fees. That number had analysis behind it. It was not a target someone hoped would be acceptable. Including risks in the charter gives the sponsor a complete picture before they authorize. It also starts the risk register, the living document that tracks and manages uncertainty throughout the project lifecycle. A risk that appears in the charter at initiation can be incorporated into the plan. One that surfaces for the first time during execution lands on the team as a surprise. Also worth including are critical success factors: the organizational conditions without which the project cannot succeed regardless of how well it is managed. For RtR, these were prioritization of project work over day-to-day operations at key milestones, genuine departmental buy-in for the move, and close coordination with the parallel marketing campaign. Critical success factors are not risks. They are explicit conditions the project depends on, stated in the charter so that the sponsor and steering committee carry visible ownership of them from the start.

Authorization and What the Signature Actually Means

Before presenting the charter for signature, confirm the document can answer these questions clearly.

• Is the business reason for the project stated?
• Are goals and deliverables written separately?
• Are in-scope and out-of-scope items both listed?
• Are assumptions, constraints, and dependencies documented?
• Are high-level requirements testable?
• Is the estimate clearly marked as preliminary?
• Are major risks and critical success factors named?
• Does the sponsor understand what they are authorizing?

The charter closes with the sponsor's signature. This is the formal moment the project becomes authorized, resourced, and directed, and it is the source of the project manager's authority within the organization. That authority is real, but it depends on one condition: the sponsor must understand what they signed. A signed charter the sponsor has not read does not create shared understanding. It creates a gap that reopens as a dispute every time the project's direction is questioned, a scope boundary is challenged, or a decision needs the sponsor's backing. The PM who accepts a signature without confirming the understanding behind it has a document but not the protection the document is supposed to provide. The project charter is not the end of a process. It is the beginning of the relationship between the PM, the sponsor, and the project. Every decision made during planning and execution can be traced back to what was agreed here. When circumstances change, the charter is the reference that establishes what was true at the start and what therefore needs to be formally updated. Treat it as a living reference throughout the project's life, not as a document filed after authorization.

Stakeholder Identification — Finding Everyone Who Matters

A stakeholder is anyone who affects, is affected by, or has an interest in the project's outcome. That definition is broader than most project managers initially realize. For a company relocation project, the list extends well beyond the sponsor, the project team, and the staff who will move. It includes the landlord of the property being vacated, the postal service that will need to update delivery routes, the municipal authority at the new address, and the employee on the night shift whose commute just became significantly longer. It extends inward as well, in ways that get missed: the department manager who was not consulted but whose team the project depends on, the compliance function with oversight authority over the new location, the peer project running in parallel that shares resources with this one. An unidentified stakeholder is an unmanaged risk. The influential manager who opposes the project and is never engaged becomes a blocker during execution. The regulatory body not notified early becomes a compliance problem mid-delivery. Stakeholder identification is not an administrative checkbox. It is a risk management activity, and doing it before planning begins is what determines whether the plan is built on complete information or optimistic assumptions.

Identifying stakeholders is a structured process that begins with the project charter, which already names key roles and establishes scope and organizational context. From there, the process expands through structured sessions with the initial team: who depends on this project's output, who has authority over any element of it, who might oppose it, and who might be adversely affected by it. The goal is not a complete list achieved in one sitting. It is systematic expansion. The easiest stakeholders to find are the obvious ones. The more valuable exercise is locating the non-obvious, resistant, or politically sensitive ones before planning locks in. At that stage, there is still room to incorporate what you learn into how the project is structured and communicated.

Eight questions help expand the initial list beyond the obvious entries.

• Who approves or blocks key decisions on this project?
• Who provides resources the project depends on?
• Who uses the output after the project closes?
• Who must change how they work because of this project?
• Who has compliance or regulatory authority over this work?
• Who is indirectly affected but not formally involved?
• Who opposed or resisted similar work in the past?
• Who will inherit and maintain the result after delivery?

Three of those questions did most of the work on the RtR project. "Who must change how they work?" surfaced the dispatch coordination team, eight people whose workflows depended on continuous service access and who needed a separate cutover protocol the original stakeholder list had no row for. "Who has compliance or regulatory authority?" identified the municipal permit authority at the new address, a clearance requirement that would have landed mid-execution as a surprise if nobody had asked the question at initiation. "Who will inherit and maintain the result?" pulled in the IT administrator who would own the network infrastructure after go-live, a person with specific requirements for how cabling and hardware were configured that the project's IT lead did not know to ask about. None of those three rows appeared in the obvious first-pass list. All three of them shaped how the project was planned.

The output is the stakeholder register.

The Stakeholder Register

The stakeholder register is not a contact list. It is a living strategic document that maps the people environment the project operates in, one row per stakeholder or stakeholder group, updated from initiation through project close. Its value lies in making invisible dynamics visible: this stakeholder is actively supportive; this one is neutral; this one is currently disengaged but holds significant influence; this group has information the project needs before a key decision can be made. Making that analysis visible is what turns a register into a planning tool rather than a record-keeping exercise. At minimum, the register should capture: name or group, project role, level of influence, primary interest, current engagement level, desired engagement level, communication needs, and which team member owns that relationship. Keep the full analysis within the project management function; it contains sensitivity about stakeholder positions and internal dynamics. When a governance process requires a public-facing list, produce a sanitized version. The engagement actions that team members need to perform should still be shared with whoever is responsible for executing them.

One of the most important decisions in building the register is when to create a row for a group versus when to create rows for named individuals. Listing all 150 staff members of an organization individually produces a document that looks thorough and functions poorly. The purpose of the register is to guide engagement planning: who needs what kind of communication, from whom, and when. Stakeholders with similar needs and similar engagement approaches belong in the same row. Key individuals with specific project authority, distinct influence, or unique engagement needs get their own rows, because their management must happen at the person level. The register feeds directly into stakeholder engagement planning, communications planning, and risk identification. When it reveals that a high-influence stakeholder is currently disengaged, the PM knows there is a gap to close, and knows it before that gap becomes a problem during execution.

Role Clarity — The RACI Matrix

Technical difficulty derails fewer projects than role ambiguity. Who makes the final call on this decision? Who needs to be asked before it is made? Who just needs to know it happened? When those questions do not have clear answers, decisions stall, work gets duplicated, and team members step on each other's authority without realizing it. The RACI matrix answers those questions systematically, for every major deliverable on the project. RACI stands for Responsible, Accountable, Consulted, and Informed. Responsible is the person who performs the work. Accountable is the person who owns the outcome: the one who makes the final decision and accepts the result. Consulted means their input is required before a decision or action proceeds. Informed means they need to know what happened but do not need to be involved beforehand. For any given deliverable, aim for one accountable owner. If accountability appears genuinely shared, the deliverable is likely too broad: either split it into two discrete items or clarify which decisions each person controls. When two people own a decision equally, neither truly owns it.

A = Accountable (owns the outcome). R = Responsible (does the work). C = Consulted (input required before action). I = Informed (notified after).

The matrix is built on two axes: stakeholders or roles along one axis, deliverables along the other. Where they intersect, you place the appropriate letter. Running that exercise across all major deliverables surfaces two patterns worth watching for. The first is deliverables with no clear Accountable owner, meaning no one can be held responsible for the outcome. The second is stakeholders listed as Consulted on nearly everything, which signals over-consultation: people who should simply be Informed are being pulled into decision loops that do not need them, creating bottlenecks that slow the project without adding value. The RACI matrix can begin in the project charter, where key stakeholders and high-level deliverables are already named, and is refined during planning as scope and team membership take shape. A RACI built once and filed is a document. One actively maintained and revisited as the project evolves is a tool, and the role clarity it sustains throughout execution is exactly what it is designed to protect.

A = Accountable. R = Responsible. C = Consulted. I = Informed. A/R = same person is both accountable and responsible for that deliverable.

Putting It Together — How Initiation Works

The tools in this chapter form a sequence. Here is how initiation runs in practice.

1. Review the business case. Understand what the organization is trying to achieve and why now.
2. Draft the charter with sponsor input: clarify goals, deliverables, both sides of scope, requirements, assumptions, constraints, and dependencies.
3. Name the initial risks and critical success factors. Mark the estimate clearly as preliminary.
4. Run the pre-signature checklist. Confirm the charter can answer all eight questions before the meeting.
5. Walk the sponsor through the charter in a working session. Update and re-sign if gaps surface.
6. Identify stakeholders using the eight discovery questions. Do not stop at the obvious list.
7. Build the stakeholder register: one row per person or group, capturing influence, interest, engagement gaps, and communication needs.
8. Draft the RACI matrix from the stakeholder and deliverable lists. Resolve any missing accountability or over-consultation before planning begins.

What's Next

The charter and stakeholder register establish what the project will deliver, who is authorized to run it, and who needs to be managed throughout. That is initiation complete. The next chapter opens the planning section: the phase where those high-level agreements get translated into a detailed, structured plan for scope, schedule, cost, risk, resources, communications, and procurement.

Reflect

• Think of a project you have been part of that lacked a clear charter, or where the charter was signed without being genuinely understood. What assumptions filled the gap, and when did those assumptions become disputes?
• Consider the last project you worked on. Were in-scope and out-of-scope items both explicitly documented? If not, what did stakeholders assume was included that was not?
• Where is the line between scope and requirements in a project you are familiar with? Could a team member have delivered the scoped item and still missed what was actually needed?
• Who was a stakeholder on a recent project that was identified later than they should have been, and what was the cost of finding them late?