Install
$ agentstack add skill-vigneshbarani24-sap-superpowers-project-kickoff ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
SAP Project Kickoff
This skill enforces structured SAP project initiation so that no project starts without a charter, governance model, stakeholder register, and risk register — the four artifacts that prevent the "we assumed someone else was handling that" failures that kill SAP programs.
Iron Laws
- NO PROJECT WITHOUT A CHARTER. A verbal agreement is not a project. A charter with scope, governance, milestones, and sign-off authority is a project. Everything else is a favor.
- NO SCOPE WITHOUT BOUNDARIES. In-scope means nothing without explicit out-of-scope. Every charter must list both. Ambiguous scope is the #1 cause of SAP project overruns.
- NO GOVERNANCE WITHOUT ESCALATION PATHS. A steering committee that meets monthly is not governance. Defined escalation paths with SLAs and named decision-makers is governance.
- NO RACI WITHOUT VALIDATION. A RACI created by one person is a wish list. A RACI validated by every Accountable party is a commitment.
- NO KICKOFF WITHOUT RISK REGISTER. Projects that start without identified risks are not optimistic — they are negligent. Minimum 5 risks with quantified impact.
- ACTIVATE PHASES ARE NON-NEGOTIABLE. Every SAP project maps to SAP Activate phases (Discover, Prepare, Explore, Realize, Deploy, Run). Custom phase names create confusion with SAP support and quality gates.
Rationalization Table
| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter | |---|---|---|---| | Skip stakeholder analysis | "The project sponsor told us who matters" | Sponsors have blind spots. Missed stakeholders surface at UAT with blocking objections. | Checklist Step 1: Minimum 4 stakeholder categories (executive, process owner, end user, IT). | | Define scope as a bullet list | "The SOW already has the scope" | Bullet lists lack precision. "Implement FI" could mean 2 company codes or 50. | Iron Law 2: Scope must include entity counts, process boundaries, and explicit exclusions. | | Skip the communication plan | "We'll figure out communication as we go" | Ad-hoc communication means the steering committee learns about risks from rumors. | Checklist Step 5: Communication plan with audience, frequency, channel, and owner for each stakeholder group. | | Create a RACI in isolation | "I know the org chart" | Org charts show reporting lines, not project accountability. The FI lead may not know they own chart of accounts migration. | Iron Law 4: Every A (Accountable) party must confirm in writing. | | Use generic risk categories | "Risks are risks — resource, budget, timeline" | Generic risks generate generic mitigations. "Data migration complexity" with a specific legacy system named drives action. | Checklist Step 6: Each risk must name a specific SAP module, system, or workstream. | | Assume SAP Activate is understood | "Everyone knows Activate" | Teams confuse Activate with Waterfall, ASAP, or their own hybrid. Phase gates get skipped. | Iron Law 6: Charter must map deliverables to Activate phases explicitly. | | Skip the out-of-scope section | "We listed what's in scope, isn't that enough?" | What you don't list, the client assumes is included. Especially integrations, reports, data migration. | Iron Law 2: Out-of-scope section is mandatory and must be at least half as long as in-scope. | | Copy a charter template without customizing | "This template worked for the last project" | Every SAP landscape is different. A retail S/4HANA project charter does not fit a pharma brownfield migration. | Verification: Charter must reference this client's specific systems, modules, and org structure. |
Red Flags
Watch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:
- "The scope is pretty clear already..." → You have not written explicit boundaries. Stop.
- "We can refine the RACI later..." → Later means never. Get commitments now. Stop.
- "The risks are standard for this type of project..." → Standard risks are lazy risks. Be specific. Stop.
- "The stakeholders are obvious..." → You have not done a stakeholder analysis. Stop.
- "Let's keep the charter lightweight..." → Lightweight charters produce heavyweight change requests. Stop.
- "We'll handle governance organically..." → Organic governance means no governance. Stop.
- "This is similar to the last project..." → Similar is not the same. Different client, different landscape, different risks.
Hard Gates
DO NOT generate a project charter until ALL of the following exist:
- Stakeholder register with minimum 8 named stakeholders across 4 categories
- Scope statement with explicit in-scope AND out-of-scope sections
- Governance model with steering committee membership and escalation paths
- RACI matrix covering at least: scope decisions, budget approval, go-live decision, change requests, risk escalation
- Risk register with minimum 5 SAP-specific risks (not generic categories)
- SAP Activate phase mapping with key deliverables per phase
Checklist
Step 1: Stakeholder Identification
Identify all stakeholders using the SAP project stakeholder framework:
- Executive Sponsors: Who signs off on budget, scope changes, go-live?
- Process Owners: Who owns each business process being implemented? (One per SAP module area minimum)
- End User Representatives: Who will validate during Fit-to-Standard workshops and UAT?
- IT Landscape Owners: Who manages the current systems being replaced/integrated?
- Integration Partners: Who owns the non-SAP systems that will connect?
- Compliance/Audit: Who must approve data, security, and regulatory aspects?
Evidence: Stakeholder register table with Name, Role, Category, Influence Level (H/M/L), Engagement Strategy. Gate: Minimum 8 named stakeholders across 4+ categories before proceeding.
Step 2: Scope Definition
Define scope using the SAP module boundary method:
- Modules in scope: List each SAP module (FI, CO, MM, SD, PP, PM, etc.) with specific sub-components
- Entity scope: Company codes, plants, sales orgs, purchasing orgs — with counts
- Process scope: Name each business process (e.g., P2P, O2C, R2R) and its boundaries
- Geography scope: Countries, languages, currencies, legal entities
- Integration scope: Name each system-to-system interface with direction and protocol
- Data migration scope: Which data objects, from which source systems, approximate volumes
- Reporting scope: Operational reports, analytics, dashboards — named, not "as needed"
- OUT OF SCOPE: Explicitly list what is excluded — modules, processes, entities, integrations, reports
Evidence: Scope statement document with all 8 categories populated. Gate: Out-of-scope section exists and contains specific items (not "everything not listed above").
Step 3: Governance Model
Define project governance aligned with SAP Activate quality gates:
- Steering Committee: Members (by name/role), meeting cadence, decision authority
- Project Management Office: PM structure, reporting cadence, tools
- Workstream Leads: One per module/functional area, responsibilities
- Quality Gates: Map to SAP Activate phase transitions (Discover→Prepare, Prepare→Explore, etc.)
- Escalation Matrix: Issue severity levels (1-4) with escalation path, target response time, and named decision-maker per level
- Change Control: How scope changes are requested, evaluated, approved, and communicated
Evidence: Governance model document with named individuals (not just roles). Gate: Escalation matrix has at least 3 severity levels with distinct paths.
Step 4: RACI Matrix
Build a RACI covering SAP project decisions:
Minimum decision areas:
- Scope change approval
- Budget reallocation
- Go-live decision (Go/No-Go)
- Change request evaluation
- Risk escalation
- Data migration sign-off
- Integration design approval
- Security/authorization concept approval
- Test strategy approval
- Training approach approval
- Cutover plan approval
Evidence: RACI matrix with every decision area having exactly one A (Accountable). Gate: No decision area has zero A or more than one A.
Step 5: Communication Plan
Define communication for each stakeholder group:
| Audience | Content | Frequency | Channel | Owner | |----------|---------|-----------|---------|-------| | Steering Committee | Status, risks, decisions needed | Bi-weekly | Formal meeting | PM | | Process Owners | Workstream progress, open items | Weekly | Teams/Slack | Workstream Lead | | End Users | Project awareness, timeline, training | Monthly | Email/Town Hall | Change Manager | | IT Team | Technical progress, dependencies | Weekly | Stand-up | Tech Lead |
Evidence: Communication plan table with all stakeholder categories covered. Gate: Every stakeholder group from Step 1 appears in the communication plan.
Step 6: Risk Register
Identify SAP-specific project risks:
Each risk must include:
- Risk ID and Name: Specific, not generic (e.g., "Legacy GL account structure incompatible with Universal Journal" not "Data migration risk")
- Category: Technical, Functional, Organizational, Integration, Data, Resource
- Probability: H/M/L with justification
- Impact: H/M/L with estimated day/cost impact
- Mitigation: Specific action with owner and deadline
- Contingency: What happens if the risk materializes despite mitigation
Evidence: Risk register with minimum 5 risks, each with all 6 attributes. Gate: At least 2 risks must be rated High probability or High impact.
Step 7: Generate Project Charter
Assemble the charter document using the deliverable template below.
Evidence: Complete charter document with all sections populated. Gate: All Hard Gate conditions met.
Deliverable Template
# SAP Project Charter
## Project Overview
- **Project Name:**
- **Client:**
- **SAP Product:** [S/4HANA Cloud / S/4HANA On-Premise / BTP / SuccessFactors / etc.]
- **Implementation Approach:** [Greenfield / Brownfield / Bluefield / Selective Data Transition]
- **SAP Activate Phases:** [Which phases are in scope for this engagement]
- **Target Go-Live:**
- **Budget Range:**
## Stakeholder Register
[Table from Step 1]
## Scope Definition
### In Scope
[From Step 2 — all 7 in-scope categories]
### Out of Scope
[From Step 2 — explicit exclusions]
## Governance Model
[From Step 3]
### Escalation Matrix
[Severity levels with paths]
### Quality Gates
| Activate Phase Transition | Gate Criteria | Decision Maker |
|---------------------------|---------------|----------------|
## RACI Matrix
[From Step 4]
## Communication Plan
[From Step 5]
## Risk Register
[From Step 6]
## SAP Activate Phase Mapping
| Phase | Key Deliverables | Duration (est.) | Quality Gate |
|-------|-----------------|------------------|--------------|
| Discover | Project charter, stakeholder analysis | | |
| Prepare | Scope finalization, team onboarding, environment setup | | |
| Explore | Fit-to-Standard workshops, fit-gap analysis, process design | | |
| Realize | Configuration, development, testing | | |
| Deploy | Cutover, go-live, hypercare | | |
| Run | Steady-state support, optimization | | |
## Assumptions and Constraints
[List all assumptions that underpin this charter]
## Sign-Off
| Name | Role | Signature | Date |
|------|------|-----------|------|
Verification
This skill is complete ONLY when ALL of the following are true:
- [ ] Stakeholder register has 8+ named individuals across 4+ categories
- [ ] Scope statement has explicit in-scope AND out-of-scope sections with SAP module specifics
- [ ] Governance model names real people (not just roles) for steering committee and escalation
- [ ] RACI matrix has exactly one A per decision area and covers 10+ decision types
- [ ] Communication plan covers every stakeholder group identified in Step 1
- [ ] Risk register has 5+ SAP-specific risks with probability, impact, mitigation, and contingency
- [ ] Charter maps deliverables to SAP Activate phases
- [ ] Out-of-scope section contains specific named exclusions (not "everything else")
- [ ] All assumptions are stated explicitly in the charter
Evidence required: Complete project charter document with all sections populated and no placeholder text.
If any verification item is not met, the skill is NOT complete. Do not claim completion.
Next Skill
After completing this skill, invoke one of:
estimation— When the project needs effort estimates for planning and budgetingfit-gap-analysis— When moving into Explore phase to assess requirements against SAP standard
Conditions for handoff: Charter is signed off (or ready for sign-off) and the project is transitioning from Discover/Prepare into Explore or needs detailed estimation for budget approval.
Cross-References
estimation— For detailed effort estimation referenced in the charterchange-management— For expanding the stakeholder analysis into a full OCM planvalue-advisory— For building the business case that justifies the project chartersap-activate-methodology— For detailed phase gate criteria referenced in governance
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: vigneshbarani24
- Source: vigneshbarani24/sap-superpowers
- License: MIT
- Homepage: https://sap-superpowers.vercel.app/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.