Initiation

Initiation

Important: This plugin assists with project management workflows but does not replace professional judgment. All outputs should be validated with stakeholders and your team before making project decisions.

Project Charter

A project charter is the single document that authorizes a project to exist. It defines the why, the what, and the who at a level sufficient to secure funding, align stakeholders, and give the project manager authority to act. Without a signed charter, a project is just an idea with no organizational commitment behind it.

The charter should be concise -- one to three pages maximum. It is not the project plan. It is the agreement that a project plan should be created. Teams that confuse charters with plans end up with 30-page documents nobody reads and nobody signs.

Software Mode

For software projects, the charter must address technical realities that directly affect feasibility and delivery. Skip these and you will discover them mid-sprint, when the cost of change is highest.

Technical Feasibility Assessment

Before committing to a software project, answer these questions explicitly:

Architecture Dependencies

Document every system this project touches. For each dependency, note:

Dependency: [System/Service Name]
Owner: [Team or individual]
Type: [Upstream data provider | Downstream consumer | Shared service | Third-party API]
Current State: [Stable | Degraded | Under active development]
Risk: [What breaks if this dependency is unavailable or changes?]
Action Needed: [None | API contract review | Load test | Migration]

Worked Example:

Dependency: User Authentication Service (AuthN)
Owner: Platform Team (Sarah Chen)
Type: Shared service
Current State: Stable, but scheduled for OAuth 2.1 migration in Q3
Risk: If migration timeline shifts left, our integration breaks mid-sprint
Action Needed: Confirm migration timeline with Platform Team; build against
               new OAuth 2.1 spec if migration completes before our launch

Team Capacity Check

Assess whether the team can absorb this project without overcommitting:

Tech Stack Decisions

If the project introduces new technologies, document the decision and rationale:

Technology: [Name and version]
Category: [Language | Framework | Database | Infrastructure | Third-party service]
Why: [What problem does this solve that existing stack does not?]
Alternatives Considered: [What else was evaluated and why was it rejected?]
Team Familiarity: [High | Medium | Low -- if Low, what is the ramp-up plan?]
Licensing: [Open source | Commercial -- cost implications?]
Support/Community: [Active community? Enterprise support available?]
Decision Maker: [Who approved this?]
Reversibility: [Easy to swap out later | Medium effort | Locked in]

Definition of Done

Establish project-level Definition of Done before any work begins. This prevents end-of-sprint arguments about what "done" means.

A feature is DONE when:
[ ] Code is written and passes all unit tests (>80% coverage on new code)
[ ] Code has been peer-reviewed and approved by at least one reviewer
[ ] Integration tests pass in staging environment
[ ] Documentation is updated (API docs, runbooks, architecture diagrams)
[ ] Feature flag is configured (if applicable)
[ ] Performance benchmarks meet acceptance criteria
[ ] Security review completed (if touching auth, PII, or payment flows)
[ ] Product owner has accepted the feature in staging
[ ] Deployment runbook is updated
[ ] Monitoring and alerting are configured

Integration Points

Map every integration this project requires:

General Mode

For non-software projects -- organizational change, process improvement, facility build-outs, marketing campaigns, and similar -- the charter must ground the project in business value and governance.

Business Case

Every project needs a business case, even if the project feels "obviously" needed. The business case forces clarity on why this project deserves resources over competing priorities.

BUSINESS CASE

Problem Statement:
[What problem exists today? Who is affected? What is the cost of inaction?
Be specific: "Customer onboarding takes 14 days on average; industry
benchmark is 3 days. We lose 22% of signed customers during onboarding."]

Proposed Solution:
[What will this project deliver? Describe the end state, not the activities.
"Redesigned onboarding process that reduces time-to-value from 14 days to
5 days through automation of document collection, parallel processing of
compliance checks, and a dedicated onboarding specialist role."]

Expected Benefits:
- Quantitative: [Revenue retained: $1.2M/year from reduced churn during onboarding]
- Quantitative: [Cost savings: $180K/year from reduced manual processing]
- Qualitative: [Improved customer satisfaction; stronger first impression]
- Qualitative: [Reduced burden on operations team; lower burnout risk]

Cost Estimate:
- Project cost: [Total budget including labor, tools, external vendors]
- Ongoing cost: [Annual operating cost of the solution once implemented]
- ROI: [Payback period or ROI calculation]
  Example: "$340K project cost / $1.38M annual benefit = 3-month payback"

Timeline:
- Estimated duration: [X weeks/months]
- Target completion: [Date]

Sponsor Alignment

The project sponsor is the person who funds the project, removes organizational blockers, and makes final decisions when the team is stuck. Sponsor alignment means:

1. Sponsor understands and agrees with the business case. They can articulate why this project matters in their own words, not just nod at your slides.
2. Sponsor commits time. Minimum: 30-minute weekly check-in with PM, attendance at monthly steering committee, availability for escalations within 24 hours.
3. Sponsor has decision-making authority. If the sponsor needs to "check with their boss" on every decision, they are not the real sponsor. Find the real sponsor.
4. Sponsor agrees to scope boundaries. The sponsor understands what is in scope and what is out, and will defend those boundaries when pressure arises.

Sponsor alignment checklist:

• Sponsor has reviewed and approved the business case
• Sponsor has committed to governance cadence (weekly 1:1, monthly steering)
• Sponsor's success criteria are documented and match the charter
• Sponsor has identified who can act in their absence
• Sponsor agrees to the escalation path and response time expectations

Governance Structure

Define how decisions get made before decisions need to be made.

Steering Committee:

RACI at Project Level:

R = Responsible, A = Accountable, C = Consulted, I = Informed

Procurement Needs

If the project requires external vendors, tools, or services, document procurement requirements early. Procurement cycles (RFP, vendor evaluation, contract negotiation, legal review) routinely add 4-12 weeks to timelines.

Procurement Item: [What you need]
Estimated Cost: [$X]
Procurement Method: [Direct purchase | RFP | Sole source | Existing contract]
Lead Time: [Estimated weeks from request to delivery]
Approval Required From: [Procurement, Legal, Finance, IT Security]
Dependency: [What project work is blocked until this is procured?]

Compliance and Regulatory Check

Before launch, identify any regulatory, legal, or compliance requirements that constrain the project:

• Data privacy (GDPR, CCPA, HIPAA) -- does the project handle personal data?
• Industry regulations -- are there sector-specific rules (financial services, healthcare, government)?
• Internal policies -- does the project comply with corporate security, procurement, and HR policies?
• Audit requirements -- will the project be subject to internal or external audit?
• Accessibility requirements -- does the output need to meet WCAG or ADA standards?
• Environmental/safety regulations -- applicable for physical projects or facilities

Charter Template

Use this template for both software and general projects. Adapt sections as needed.

PROJECT CHARTER
===============
Version: ___  |  Date: _______________
Status: [Draft | Under Review | Approved]

1. PROJECT NAME
   [Clear, descriptive name -- not a code name that nobody outside the team
   understands]

2. PROJECT SPONSOR
   Name: _______________
   Title: _______________
   Authority: [Budget approval up to $X; escalation decision-maker]

3. PROJECT MANAGER
   Name: _______________
   Authority: [Day-to-day decisions; budget allocation within approved limits;
              team assignments]

4. START DATE / END DATE
   Planned Start: _______________
   Planned End: _______________
   Key Phase Gates: [Phase 1 complete by ___, Phase 2 by ___, etc.]

5. OBJECTIVES
   [What will this project achieve? Write 3-5 objectives using the SMART
   format: Specific, Measurable, Achievable, Relevant, Time-bound]
   - Objective 1: _______________
   - Objective 2: _______________
   - Objective 3: _______________

6. SCOPE
   In Scope:
   - [Specific deliverable or work area]
   - [Specific deliverable or work area]
   - [Specific deliverable or work area]

   Out of Scope:
   - [Explicitly excluded item -- name it so nobody assumes it is included]
   - [Explicitly excluded item]
   - [Explicitly excluded item]

7. SUCCESS CRITERIA
   [How will we know this project succeeded? Define measurable outcomes.]
   - Criterion 1: [Metric] reaches [target] by [date]
   - Criterion 2: [Deliverable] is accepted by [stakeholder] by [date]
   - Criterion 3: [Outcome] is sustained for [duration] post-launch

8. KEY STAKEHOLDERS
   | Name | Role | Interest | Influence | Communication Need |
   |------|------|----------|-----------|-------------------|
   |      |      |          |           |                   |

9. HIGH-LEVEL RISKS
   | Risk | Likelihood | Impact | Mitigation |
   |------|-----------|--------|------------|
   |      |           |        |            |

10. BUDGET
    | Category | Estimated Cost | Approved? |
    |----------|---------------|-----------|
    | Labor (internal) | $_______ | [ ] |
    | Labor (external/vendor) | $_______ | [ ] |
    | Tools/licenses | $_______ | [ ] |
    | Infrastructure | $_______ | [ ] |
    | Contingency (10-15%) | $_______ | [ ] |
    | TOTAL | $_______ | [ ] |

11. ASSUMPTIONS
    [What are we assuming to be true that, if wrong, would change the plan?]
    - Assumption 1: _______________
    - Assumption 2: _______________
    - Assumption 3: _______________

12. CONSTRAINTS
    [What limits are imposed on the project?]
    - Constraint 1: [Budget cap of $X]
    - Constraint 2: [Must use existing vendor; no new procurement]
    - Constraint 3: [Team cannot exceed X headcount]
    - Constraint 4: [Must comply with regulation Y]

APPROVALS:
Sponsor: _______________ Date: ___
PM: _______________ Date: ___
Finance: _______________ Date: ___

Charter Quality Checklist

Before circulating the charter for approval, validate it against these criteria:

• Objectives are SMART. Each objective is Specific, Measurable, Achievable, Relevant, and Time-bound. If an objective says "improve customer experience," it fails -- improve by how much, measured how, by when?
• Scope boundaries are explicit. Both "in scope" and "out of scope" are listed. Out-of-scope items are named specifically, not implied. If it is not in the "in scope" list, it should be in "out of scope."
• Success criteria are measurable. Every criterion has a number, a date, or a verifiable outcome. "Project is successful" is not a criterion. "NPS increases from 32 to 45 within 90 days of launch" is.
• Stakeholders are identified by name. Not "engineering team" -- specific people. You cannot communicate with a department; you communicate with individuals.
• Risks have mitigations. Every identified risk has at least one mitigation action. A risk without a mitigation is just a worry.
• Budget includes contingency. A budget without 10-15% contingency is a fantasy. Something will go wrong. Plan for it.
• Assumptions are documented. Assumptions are the invisible load-bearing walls of a project. If an assumption breaks, the project may collapse. Write them down so you can test and monitor them.
• Constraints are acknowledged. The charter reflects real-world limits: budget caps, headcount freezes, regulatory deadlines, technology mandates. Ignoring constraints does not make them go away.
• Sponsor has signed. A charter without sponsor sign-off is a wishlist. The signature represents organizational commitment of resources, budget, and political support.
• The charter fits on 1-3 pages. If it is longer, you are writing a project plan, not a charter. Cut it down.

Charter Anti-Patterns

These are the most common ways charters fail. Recognize and correct them early.

Scope Too Vague

• Symptom: Scope section says "Build a new customer portal" with no further detail.
• Problem: Every stakeholder imagines a different portal. Engineering thinks it is a dashboard. Sales thinks it is a self-service buying tool. Support thinks it is a ticketing system.
• Fix: List 5-10 specific capabilities in scope. List 3-5 things explicitly out of scope. Use concrete language: "Self-service password reset, order history view, and support ticket submission. Does NOT include payment processing, live chat, or account creation."

No Success Criteria

• Symptom: The charter lists objectives but no way to measure whether they were achieved.
• Problem: At project close, nobody can agree on whether it succeeded. The sponsor says "I expected more." The team says "We delivered everything we were asked for." Both are right because there was no shared definition of success.
• Fix: For every objective, write a corresponding success criterion with a specific metric and target. "Reduce onboarding time from 14 days to 5 days, measured by median time across all new customers in the first 90 days post-launch."

Missing Stakeholders

• Symptom: The charter lists the sponsor and PM but nobody else. Or it lists departments instead of people.
• Problem: Stakeholders who are not identified are not engaged. They surface mid-project with requirements that blow up scope, timeline, or both.
• Fix: Conduct a stakeholder identification exercise before writing the charter. Ask: "Who can block this project? Who is affected by the outcome? Who controls resources we need? Who has expertise we require?" Name them individually.

Charter-as-Contract

• Symptom: The charter is treated as a legally binding document that can never change. Any proposed modification triggers a formal change control process.
• Problem: Projects operate in uncertain environments. If the charter cannot evolve as the team learns more, it becomes an anchor rather than a compass. Teams either ignore it entirely or spend more time managing change requests than doing work.
• Fix: The charter is a living document. It should be reviewed at every phase gate and updated when material assumptions change. Changes to objectives or scope require sponsor approval. Changes to implementation details do not. Version the charter and track what changed and why.

Stakeholder Mapping

Stakeholder mapping identifies who matters, how much influence they have, what they care about, and how to engage them. A project can have a perfect plan and still fail because a key stakeholder was ignored, surprised, or actively working against it.

Power/Interest Grid

The Power/Interest grid is the foundational tool for stakeholder classification. It plots stakeholders on two axes: their power to influence the project outcome and their interest in the project.

                        HIGH POWER
                            |
         Keep Satisfied     |     Manage Closely
         (High Power,       |     (High Power,
          Low Interest)     |      High Interest)
                            |
        These stakeholders  |  These are your most
        can block you but   |  critical stakeholders.
        are not paying      |  Engage them deeply,
        close attention.    |  consult them on major
        Keep them informed  |  decisions, and never
        enough to prevent   |  surprise them.
        negative surprises. |
                            |
   LOW INTEREST ------------+------------ HIGH INTEREST
                            |
         Monitor            |     Keep Informed
         (Low Power,        |     (Low Power,
          Low Interest)     |      High Interest)
                            |
        Minimal effort.     |  These stakeholders care
        Periodic updates.   |  deeply but cannot directly
        Watch for changes   |  influence outcomes. Keep
        in their power or   |  them informed, listen to
        interest level.     |  their concerns, and use
                            |  them as advocates.
                            |
                        LOW POWER

Quadrant Descriptions and Engagement Strategies:

Stakeholder Register Template

Maintain a living register of all identified stakeholders. Update it at every phase gate and whenever organizational changes occur.

STAKEHOLDER REGISTER
=====================
Project: _______________  |  Last Updated: _______________
Maintained By: [PM Name]

| # | Name | Role/Title | Org/Dept | Influence (H/M/L) | Interest (H/M/L) | Grid Quadrant | Communication Need | Potential Resistance | Engagement Strategy |
|---|------|-----------|----------|-------------------|------------------|---------------|-------------------|---------------------|-------------------|
| 1 | ___ | ___ | ___ | ___ | ___ | ___ | ___ | ___ | ___ |
| 2 | ___ | ___ | ___ | ___ | ___ | ___ | ___ | ___ | ___ |
| 3 | ___ | ___ | ___ | ___ | ___ | ___ | ___ | ___ | ___ |

Column guide: Influence = can they approve, block, or materially change the project? Interest = how much do they care about the outcome? Communication Need = format, frequency, and detail level (e.g., "Bi-weekly 1:1, wants to review deliverables"). Potential Resistance = concerns that could cause opposition (e.g., "Worried about headcount reductions"). Engagement Strategy = specific actions to keep them aligned (e.g., "Include in design reviews to address technical concerns early").

Software Mode: Technical Stakeholder Categories

Software projects have a distinct stakeholder landscape. Missing any of these groups creates risk.

Technical Stakeholders:

Product Stakeholders:

Business Stakeholders:

General Mode: Stakeholder Categories

Non-software projects have broader organizational reach and often involve external parties.

Stakeholder Analysis Anti-Patterns

Forgetting End Users

• Symptom: The stakeholder map includes executives, managers, and the project team but nobody who will actually use the project output day-to-day.
• Impact: The project delivers something that looks good in a steering committee but is unusable in practice. Adoption fails.
• Fix: Always include representative end users on the stakeholder register. Engage them in requirements, design reviews, and UAT. If you cannot name specific end users, you do not understand your audience well enough.

Assuming All Executives Are Equal

• Symptom: Every VP and C-level is placed in the "Manage Closely" quadrant regardless of their actual influence on or interest in the project.
• Impact: The PM spends excessive time managing executives who do not care about the project, while under-engaging the ones who do.
• Fix: Assess each executive individually. A CFO on a marketing project may be "Keep Satisfied" (high power, low interest) while the CMO is "Manage Closely." Not every executive needs the same level of engagement.

Not Revisiting the Map

• Symptom: Stakeholder map is created at project start and never updated.
• Impact: Organizational changes, role changes, or shifting priorities mean the map becomes inaccurate. A stakeholder who was "Monitor" in month 1 may become "Manage Closely" by month 3 due to a reorg or strategic shift.
• Fix: Review and update the stakeholder register at every phase gate (minimum monthly). Ask: "Has anyone's power or interest changed? Are there new stakeholders we missed? Has anyone left the organization?"

Treating It as a One-Time Exercise

• Symptom: Stakeholder mapping is done as a checkbox activity during project initiation and filed away.
• Impact: The map becomes a dead artifact. Engagement strategies are never executed. Stakeholders who needed attention do not get it.
• Fix: The stakeholder register should be a working document that drives weekly engagement actions. Every PM weekly planning session should include: "Who do I need to talk to this week based on the stakeholder register?"

Ignoring Potential Resistance

• Symptom: The "Potential Resistance" column is left blank or filled with "None" for every stakeholder.
• Impact: Resistance surprises the team mid-project. A department head blocks a process change because they feel threatened. An architect vetoes a technical approach because they were not consulted.
• Fix: Assume resistance exists until proven otherwise. For each stakeholder, ask: "What could they lose from this project? What could make them uncomfortable? What past experiences might make them skeptical?" Document it and plan for it.

References

For detailed templates, frameworks, and field-level guidance, read:

• references/initiation-reference.md — Complete framework details, templates, and examples

Read this file when the task requires:

• Kickoff Planning