From project-management
Project charters, stakeholder mapping, and kickoff planning for software and general PMs Use when user asks to "create a project charter", "map stakeholders", "kick off a project", or mentions project setup, stakeholder analysis, or kickoff meeting.
npx claudepluginhub lauraflorentin/skills-marketplace --plugin project-managementThis skill uses the workspace's default tool permissions.
> **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.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Designs, implements, and audits WCAG 2.2 AA accessible UIs for Web (ARIA/HTML5), iOS (SwiftUI traits), and Android (Compose semantics). Audits code for compliance gaps.
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.
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.
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.
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 |
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
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 |
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]
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
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 |
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.
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]
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 alignment checklist:
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
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?]
Before launch, identify any regulatory, legal, or compliance requirements that constrain the project:
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: ___
Before circulating the charter for approval, validate it against these criteria:
These are the most common ways charters fail. Recognize and correct them early.
Scope Too Vague
No Success Criteria
Missing Stakeholders
Charter-as-Contract
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.
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. |
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 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 |
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 |
Forgetting End Users
Assuming All Executives Are Equal
Not Revisiting the Map
Treating It as a One-Time Exercise
Ignoring Potential Resistance
For detailed templates, frameworks, and field-level guidance, read:
references/initiation-reference.md — Complete framework details, templates, and examplesRead this file when the task requires: