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:

| Question | What You Are Assessing | Red Flag If... | |---|---|---| | Can the current architecture support this? | Architecture dependencies | Requires a platform migration before feature work can begin | | Do we have the skills on the team? | Team capacity and capability | Core technology is unfamiliar to >50% of the team | | What is the expected load/scale? | Performance requirements | 10x current traffic with no scaling plan | | Are there hard external deadlines? | Timeline constraints | Regulatory deadline in 8 weeks with 12 weeks of estimated work | | What systems does this touch? | Integration points | More than 3 upstream/downstream systems affected | | Is there existing technical debt blocking this? | Prerequisite work | Known debt items that must be resolved first |

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:

| Factor | Current State | Impact on This Project | |---|---|---| | Active projects per engineer | ___ | If >2, expect context-switching tax of 20-40% | | On-call rotation burden | ___ hours/week | Deduct from available capacity | | Planned PTO in project window | ___ days total | Adjust timeline accordingly | | Open headcount / backfills | ___ positions | Do not plan capacity for unfilled roles | | Upcoming tech debt sprints | ___ sprints reserved | Protect these; do not cannibalize for features |

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:

| Integration | Direction | Protocol | Auth Method | Data Format | SLA | Owner | |---|---|---|---|---|---|---| | Payment Gateway | Outbound | REST API | API Key | JSON | 99.9% uptime | Payments Team | | Analytics Pipeline | Outbound | Event stream | Service account | Avro | Best effort | Data Eng | | CRM Sync | Bidirectional | Webhook + REST | OAuth 2.0 | JSON | 99.5% uptime | Integrations Team | | Legacy Billing DB | Inbound | Direct DB read | Connection pool | SQL | N/A (internal) | Platform Team |

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:

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.
Sponsor commits time. Minimum: 30-minute weekly check-in with PM, attendance at monthly steering committee, availability for escalations within 24 hours.
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.
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:

| Role | Name | Responsibility | Meeting Cadence | |---|---|---|---| | Executive Sponsor | ___ | Final decision authority; budget approval; escalation resolution | Monthly steering + weekly 1:1 with PM | | Project Manager | ___ | Day-to-day management; risk management; status reporting | All meetings | | Business Lead | ___ | Requirements validation; UAT sign-off; change impact assessment | Bi-weekly + monthly steering | | Finance Representative | ___ | Budget tracking; cost approval; ROI validation | Monthly steering | | PMO Representative | ___ | Standards compliance; resource coordination; portfolio alignment | Monthly steering |

RACI at Project Level:

| Decision Area | Sponsor | PM | Business Lead | Finance | PMO | |---|---|---|---|---|---| | Scope changes (>5% budget impact) | A | R | C | C | I | | Budget reallocation (<5%) | I | A | C | R | I | | Timeline changes (>2 weeks) | A | R | C | I | C | | Vendor selection | A | R | C | C | I | | Risk escalation (Red status) | A | R | I | I | C | | Go/No-Go at phase gates | A | R | C | C | I |

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:

| Quadrant | Power | Interest | Strategy | Engagement Examples | |---|---|---|---|---| | Manage Closely | High | High | Deep, frequent engagement. Co-create solutions. Weekly or bi-weekly meetings. Include in decision-making. | Executive sponsor, key business owner, lead architect (software). Invite to steering committee. Share draft deliverables for early feedback. | | Keep Satisfied | High | Low | Provide high-level updates. Do not overwhelm with detail. Anticipate their concerns and address proactively. | CFO on a non-financial project, CTO on a marketing initiative. Send monthly executive summary. Flag only items that affect budget or timeline. | | Keep Informed | Low | High | Regular communication. Listen to their input even if they cannot mandate changes. They can become advocates or detractors. | End users, junior team members, customer advisory board members. Include in newsletters, demos, and feedback sessions. | | Monitor | Low | Low | Light touch. Periodic updates. Watch for shifts -- a stakeholder's power or interest can change as the project evolves. | Tangentially affected departments, external observers. Quarterly update email. No meetings unless they request one. |

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:

| Stakeholder | Why They Matter | Typical Concerns | How to Engage | |---|---|---|---| | Lead/Staff Architects | Define technical direction; can veto approaches | Architectural integrity, scalability, tech debt | Include in design reviews; seek their approval on architecture decisions before committing | | SRE/DevOps Engineers | Own production reliability; control deployment pipeline | Operational burden, monitoring gaps, on-call impact | Share operational requirements early; involve in non-functional requirements definition | | Security Team | Gate deployments through security review; own compliance | Vulnerability exposure, data handling, audit readiness | Engage at project start, not before launch; schedule threat modeling session | | QA/Test Engineers | Define quality bar; own test strategy | Test coverage, automation feasibility, regression risk | Include in sprint planning; involve in Definition of Done |

Product Stakeholders:

| Stakeholder | Why They Matter | Typical Concerns | How to Engage | |---|---|---|---| | Product Manager | Owns the "what" and "why"; prioritizes backlog | Scope clarity, customer value, delivery timeline | Weekly sync; co-own charter objectives; joint stakeholder communications | | UX/Design Lead | Owns user experience; defines interaction patterns | Usability, accessibility, design system consistency | Include in kickoff; schedule design review checkpoints at each milestone | | Data/Analytics Lead | Defines metrics instrumentation; owns reporting | Event tracking coverage, data pipeline capacity, metric definitions | Involve in success criteria definition; agree on instrumentation requirements before development |

Business Stakeholders:

| Stakeholder | Why They Matter | Typical Concerns | How to Engage | |---|---|---|---| | Engineering Leadership (VP/Director) | Allocate engineers; set team priorities | Headcount allocation, competing priorities, org-level commitments | Monthly update; escalation path for resource conflicts | | Sales/GTM Leadership | Sell what you build; set customer expectations | Feature availability dates, competitive positioning, customer commitments | Quarterly roadmap preview; flag any date changes immediately | | Customer Success/Support | Handle post-launch customer impact | Support burden, documentation quality, training needs | Include in launch planning; provide runbooks and FAQ before launch |

General Mode: Stakeholder Categories

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

| Category | Examples | Key Concern | Engagement Approach | |---|---|---|---| | Executive Sponsors | CEO, COO, Division President | Strategic alignment, ROI, organizational impact | Monthly steering committee; quarterly business review | | Functional Managers | Department heads whose teams are affected | Resource allocation, workflow disruption, change fatigue | Bi-weekly working sessions; involve in impact assessment | | PMO | Portfolio managers, standards owners | Methodology compliance, resource conflicts, reporting | Regular check-ins; align on templates and governance | | Vendors/Suppliers | Technology vendors, consultants, outsourced teams | Contract scope, deliverable expectations, payment terms | Formal contract management; weekly vendor status calls | | Regulators | Government agencies, industry bodies, auditors | Compliance, reporting, audit readiness | Dedicated compliance workstream; legal review of touchpoints | | Customers/End Users | Direct customers, internal users of project output | Quality, usability, disruption to current service | User research, beta testing, feedback sessions, launch comms | | Partners | Channel partners, integration partners | Timeline coordination, shared deliverables | Joint planning sessions; shared milestones and cadence |

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