[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6EQMMH4M2Q9D1Y331ST04PZ":3,"skill-same:01M6EQMMH4M2Q9D1Y331ST04PZ":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6EQMMH4M2Q9D1Y331ST04PZ","project-kickoff",null,"Use when starting a new SAP project, setting up governance, defining scope, identifying stakeholders, creating a project charter, or establishing a RACI matrix for any SAP Activate engagement.","vigneshbarani24\u002Fsap-superpowers","vigneshbarani24","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F20842962?v=4","01M6EQKRW2KZ2M0H75J985XGDX","Vignesh Barani Sivakumar","01M6EQKS0E6EWFSXP4XWK6Y760",11,"MIT","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fconsulting\u002Fproject-kickoff\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"project kickoff","kickoff","project","up","scope","discover","sap","project manager","activate","change","engagement","use","management","change management","architect","governance","prepare","2026-11-10 10:12:30",false,"---\nname: project-kickoff\ndescription: Use when starting a new SAP project, setting up governance, defining scope, identifying stakeholders, creating a project charter, or establishing a RACI matrix for any SAP Activate engagement.\npersona: Project Manager, Change Management Lead, Solution Architect\nphase: Discover \u002F Prepare\n---\n\n# SAP Project Kickoff\n\nThis 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.\n\n## Iron Laws\n\n1. **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.\n2. **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.\n3. **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.\n4. **NO RACI WITHOUT VALIDATION.** A RACI created by one person is a wish list. A RACI validated by every Accountable party is a commitment.\n5. **NO KICKOFF WITHOUT RISK REGISTER.** Projects that start without identified risks are not optimistic — they are negligent. Minimum 5 risks with quantified impact.\n6. **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.\n\n## Rationalization Table\n\n| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |\n|---|---|---|---|\n| 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). |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| Copy a charter template without customizing | \"This template worked for the last project\" | Every SAP landscape is different. A retail S\u002F4HANA project charter does not fit a pharma brownfield migration. | Verification: Charter must reference this client's specific systems, modules, and org structure. |\n\n## Red Flags\n\nWatch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:\n\n- \"The scope is pretty clear already...\" → You have not written explicit boundaries. Stop.\n- \"We can refine the RACI later...\" → Later means never. Get commitments now. Stop.\n- \"The risks are standard for this type of project...\" → Standard risks are lazy risks. Be specific. Stop.\n- \"The stakeholders are obvious...\" → You have not done a stakeholder analysis. Stop.\n- \"Let's keep the charter lightweight...\" → Lightweight charters produce heavyweight change requests. Stop.\n- \"We'll handle governance organically...\" → Organic governance means no governance. Stop.\n- \"This is similar to the last project...\" → Similar is not the same. Different client, different landscape, different risks.\n\n## Hard Gates\n\n\u003CHARD-GATE>\nDO NOT generate a project charter until ALL of the following exist:\n1. Stakeholder register with minimum 8 named stakeholders across 4 categories\n2. Scope statement with explicit in-scope AND out-of-scope sections\n3. Governance model with steering committee membership and escalation paths\n4. RACI matrix covering at least: scope decisions, budget approval, go-live decision, change requests, risk escalation\n5. Risk register with minimum 5 SAP-specific risks (not generic categories)\n6. SAP Activate phase mapping with key deliverables per phase\n\u003C\u002FHARD-GATE>\n\n## Checklist\n\n### Step 1: Stakeholder Identification\nIdentify all stakeholders using the SAP project stakeholder framework:\n\n- **Executive Sponsors:** Who signs off on budget, scope changes, go-live?\n- **Process Owners:** Who owns each business process being implemented? (One per SAP module area minimum)\n- **End User Representatives:** Who will validate during Fit-to-Standard workshops and UAT?\n- **IT Landscape Owners:** Who manages the current systems being replaced\u002Fintegrated?\n- **Integration Partners:** Who owns the non-SAP systems that will connect?\n- **Compliance\u002FAudit:** Who must approve data, security, and regulatory aspects?\n\nEvidence: Stakeholder register table with Name, Role, Category, Influence Level (H\u002FM\u002FL), Engagement Strategy.\nGate: Minimum 8 named stakeholders across 4+ categories before proceeding.\n\n### Step 2: Scope Definition\nDefine scope using the SAP module boundary method:\n\n- **Modules in scope:** List each SAP module (FI, CO, MM, SD, PP, PM, etc.) with specific sub-components\n- **Entity scope:** Company codes, plants, sales orgs, purchasing orgs — with counts\n- **Process scope:** Name each business process (e.g., P2P, O2C, R2R) and its boundaries\n- **Geography scope:** Countries, languages, currencies, legal entities\n- **Integration scope:** Name each system-to-system interface with direction and protocol\n- **Data migration scope:** Which data objects, from which source systems, approximate volumes\n- **Reporting scope:** Operational reports, analytics, dashboards — named, not \"as needed\"\n- **OUT OF SCOPE:** Explicitly list what is excluded — modules, processes, entities, integrations, reports\n\nEvidence: Scope statement document with all 8 categories populated.\nGate: Out-of-scope section exists and contains specific items (not \"everything not listed above\").\n\n### Step 3: Governance Model\nDefine project governance aligned with SAP Activate quality gates:\n\n- **Steering Committee:** Members (by name\u002Frole), meeting cadence, decision authority\n- **Project Management Office:** PM structure, reporting cadence, tools\n- **Workstream Leads:** One per module\u002Ffunctional area, responsibilities\n- **Quality Gates:** Map to SAP Activate phase transitions (Discover→Prepare, Prepare→Explore, etc.)\n- **Escalation Matrix:** Issue severity levels (1-4) with escalation path, target response time, and named decision-maker per level\n- **Change Control:** How scope changes are requested, evaluated, approved, and communicated\n\nEvidence: Governance model document with named individuals (not just roles).\nGate: Escalation matrix has at least 3 severity levels with distinct paths.\n\n### Step 4: RACI Matrix\nBuild a RACI covering SAP project decisions:\n\nMinimum decision areas:\n- Scope change approval\n- Budget reallocation\n- Go-live decision (Go\u002FNo-Go)\n- Change request evaluation\n- Risk escalation\n- Data migration sign-off\n- Integration design approval\n- Security\u002Fauthorization concept approval\n- Test strategy approval\n- Training approach approval\n- Cutover plan approval\n\nEvidence: RACI matrix with every decision area having exactly one A (Accountable).\nGate: No decision area has zero A or more than one A.\n\n### Step 5: Communication Plan\nDefine communication for each stakeholder group:\n\n| Audience | Content | Frequency | Channel | Owner |\n|----------|---------|-----------|---------|-------|\n| Steering Committee | Status, risks, decisions needed | Bi-weekly | Formal meeting | PM |\n| Process Owners | Workstream progress, open items | Weekly | Teams\u002FSlack | Workstream Lead |\n| End Users | Project awareness, timeline, training | Monthly | Email\u002FTown Hall | Change Manager |\n| IT Team | Technical progress, dependencies | Weekly | Stand-up | Tech Lead |\n\nEvidence: Communication plan table with all stakeholder categories covered.\nGate: Every stakeholder group from Step 1 appears in the communication plan.\n\n### Step 6: Risk Register\nIdentify SAP-specific project risks:\n\nEach risk must include:\n- **Risk ID and Name:** Specific, not generic (e.g., \"Legacy GL account structure incompatible with Universal Journal\" not \"Data migration risk\")\n- **Category:** Technical, Functional, Organizational, Integration, Data, Resource\n- **Probability:** H\u002FM\u002FL with justification\n- **Impact:** H\u002FM\u002FL with estimated day\u002Fcost impact\n- **Mitigation:** Specific action with owner and deadline\n- **Contingency:** What happens if the risk materializes despite mitigation\n\nEvidence: Risk register with minimum 5 risks, each with all 6 attributes.\nGate: At least 2 risks must be rated High probability or High impact.\n\n### Step 7: Generate Project Charter\nAssemble the charter document using the deliverable template below.\n\nEvidence: Complete charter document with all sections populated.\nGate: All Hard Gate conditions met.\n\n## Deliverable Template\n\n```markdown\n# SAP Project Charter\n\n## Project Overview\n- **Project Name:**\n- **Client:**\n- **SAP Product:** [S\u002F4HANA Cloud \u002F S\u002F4HANA On-Premise \u002F BTP \u002F SuccessFactors \u002F etc.]\n- **Implementation Approach:** [Greenfield \u002F Brownfield \u002F Bluefield \u002F Selective Data Transition]\n- **SAP Activate Phases:** [Which phases are in scope for this engagement]\n- **Target Go-Live:**\n- **Budget Range:**\n\n## Stakeholder Register\n[Table from Step 1]\n\n## Scope Definition\n### In Scope\n[From Step 2 — all 7 in-scope categories]\n### Out of Scope\n[From Step 2 — explicit exclusions]\n\n## Governance Model\n[From Step 3]\n### Escalation Matrix\n[Severity levels with paths]\n### Quality Gates\n| Activate Phase Transition | Gate Criteria | Decision Maker |\n|---------------------------|---------------|----------------|\n\n## RACI Matrix\n[From Step 4]\n\n## Communication Plan\n[From Step 5]\n\n## Risk Register\n[From Step 6]\n\n## SAP Activate Phase Mapping\n| Phase | Key Deliverables | Duration (est.) | Quality Gate |\n|-------|-----------------|------------------|--------------|\n| Discover | Project charter, stakeholder analysis | | |\n| Prepare | Scope finalization, team onboarding, environment setup | | |\n| Explore | Fit-to-Standard workshops, fit-gap analysis, process design | | |\n| Realize | Configuration, development, testing | | |\n| Deploy | Cutover, go-live, hypercare | | |\n| Run | Steady-state support, optimization | | |\n\n## Assumptions and Constraints\n[List all assumptions that underpin this charter]\n\n## Sign-Off\n| Name | Role | Signature | Date |\n|------|------|-----------|------|\n```\n\n## Verification\n\nThis skill is complete ONLY when ALL of the following are true:\n\n- [ ] Stakeholder register has 8+ named individuals across 4+ categories\n- [ ] Scope statement has explicit in-scope AND out-of-scope sections with SAP module specifics\n- [ ] Governance model names real people (not just roles) for steering committee and escalation\n- [ ] RACI matrix has exactly one A per decision area and covers 10+ decision types\n- [ ] Communication plan covers every stakeholder group identified in Step 1\n- [ ] Risk register has 5+ SAP-specific risks with probability, impact, mitigation, and contingency\n- [ ] Charter maps deliverables to SAP Activate phases\n- [ ] Out-of-scope section contains specific named exclusions (not \"everything else\")\n- [ ] All assumptions are stated explicitly in the charter\n\n**Evidence required:** Complete project charter document with all sections populated and no placeholder text.\n\nIf any verification item is not met, the skill is NOT complete. Do not claim completion.\n\n## Next Skill\n\nAfter completing this skill, invoke one of:\n- `estimation` — When the project needs effort estimates for planning and budgeting\n- `fit-gap-analysis` — When moving into Explore phase to assess requirements against SAP standard\n\nConditions for handoff: Charter is signed off (or ready for sign-off) and the project is transitioning from Discover\u002FPrepare into Explore or needs detailed estimation for budget approval.\n\n## Cross-References\n\n- `estimation` — For detailed effort estimation referenced in the charter\n- `change-management` — For expanding the stakeholder analysis into a full OCM plan\n- `value-advisory` — For building the business case that justifies the project charter\n- `sap-activate-methodology` — For detailed phase gate criteria referenced in governance\n","# SAP Project Kickoff\n\nThis 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.\n\n## Iron Laws\n\n1. **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.\n2. **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.\n3. **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.\n4. **NO RACI WITHOUT VALIDATION.** A RACI created by one person is a wish list. A RACI validated by every Accountable party is a commitment.\n5. **NO KICKOFF WITHOUT RISK REGISTER.** Projects that start without identified risks are not optimistic — they are negligent. Minimum 5 risks with quantified impact.\n6. **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.\n\n## Rationalization Table\n\n| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |\n|---|---|---|---|\n| 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). |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| Copy a charter template without customizing | \"This template worked for the last project\" | Every SAP landscape is different. A retail S\u002F4HANA project charter does not fit a pharma brownfield migration. | Verification: Charter must reference this client's specific systems, modules, and org structure. |\n\n## Red Flags\n\nWatch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:\n\n- \"The scope is pretty clear already...\" → You have not written explicit boundaries. Stop.\n- \"We can refine the RACI later...\" → Later means never. Get commitments now. Stop.\n- \"The risks are standard for this type of project...\" → Standard risks are lazy risks. Be specific. Stop.\n- \"The stakeholders are obvious...\" → You have not done a stakeholder analysis. Stop.\n- \"Let's keep the charter lightweight...\" → Lightweight charters produce heavyweight change requests. Stop.\n- \"We'll handle governance organically...\" → Organic governance means no governance. Stop.\n- \"This is similar to the last project...\" → Similar is not the same. Different client, different landscape, different risks.\n\n## Hard Gates\n\n\u003CHARD-GATE>\nDO NOT generate a project charter until ALL of the following exist:\n1. Stakeholder register with minimum 8 named stakeholders across 4 categories\n2. Scope statement with explicit in-scope AND out-of-scope sections\n3. Governance model with steering committee membership and escalation paths\n4. RACI matrix covering at least: scope decisions, budget approval, go-live decision, change requests, risk escalation\n5. Risk register with minimum 5 SAP-specific risks (not generic categories)\n6. SAP Activate phase mapping with key deliverables per phase\n\u003C\u002FHARD-GATE>\n\n## Checklist\n\n### Step 1: Stakeholder Identification\nIdentify all stakeholders using the SAP project stakeholder framework:\n\n- **Executive Sponsors:** Who signs off on budget, scope changes, go-live?\n- **Process Owners:** Who owns each business process being implemented? (One per SAP module area minimum)\n- **End User Representatives:** Who will validate during Fit-to-Standard workshops and UAT?\n- **IT Landscape Owners:** Who manages the current systems being replaced\u002Fintegrated?\n- **Integration Partners:** Who owns the non-SAP systems that will connect?\n- **Compliance\u002FAudit:** Who must approve data, security, and regulatory aspects?\n\nEvidence: Stakeholder register table with Name, Role, Category, Influence Level (H\u002FM\u002FL), Engagement Strategy.\nGate: Minimum 8 named stakeholders across 4+ categories before proceeding.\n\n### Step 2: Scope Definition\nDefine scope using the SAP module boundary method:\n\n- **Modules in scope:** List each SAP module (FI, CO, MM, SD, PP, PM, etc.) with specific sub-components\n- **Entity scope:** Company codes, plants, sales orgs, purchasing orgs — with counts\n- **Process scope:** Name each business process (e.g., P2P, O2C, R2R) and its boundaries\n- **Geography scope:** Countries, languages, currencies, legal entities\n- **Integration scope:** Name each system-to-system interface with direction and protocol\n- **Data migration scope:** Which data objects, from which source systems, approximate volumes\n- **Reporting scope:** Operational reports, analytics, dashboards — named, not \"as needed\"\n- **OUT OF SCOPE:** Explicitly list what is excluded — modules, processes, entities, integrations, reports\n\nEvidence: Scope statement document with all 8 categories populated.\nGate: Out-of-scope section exists and contains specific items (not \"everything not listed above\").\n\n### Step 3: Governance Model\nDefine project governance aligned with SAP Activate quality gates:\n\n- **Steering Committee:** Members (by name\u002Frole), meeting cadence, decision authority\n- **Project Management Office:** PM structure, reporting cadence, tools\n- **Workstream Leads:** One per module\u002Ffunctional area, responsibilities\n- **Quality Gates:** Map to SAP Activate phase transitions (Discover→Prepare, Prepare→Explore, etc.)\n- **Escalation Matrix:** Issue severity levels (1-4) with escalation path, target response time, and named decision-maker per level\n- **Change Control:** How scope changes are requested, evaluated, approved, and communicated\n\nEvidence: Governance model document with named individuals (not just roles).\nGate: Escalation matrix has at least 3 severity levels with distinct paths.\n\n### Step 4: RACI Matrix\nBuild a RACI covering SAP project decisions:\n\nMinimum decision areas:\n- Scope change approval\n- Budget reallocation\n- Go-live decision (Go\u002FNo-Go)\n- Change request evaluation\n- Risk escalation\n- Data migration sign-off\n- Integration design approval\n- Security\u002Fauthorization concept approval\n- Test strategy approval\n- Training approach approval\n- Cutover plan approval\n\nEvidence: RACI matrix with every decision area having exactly one A (Accountable).\nGate: No decision area has zero A or more than one A.\n\n### Step 5: Communication Plan\nDefine communication for each stakeholder group:\n\n| Audience | Content | Frequency | Channel | Owner |\n|----------|---------|-----------|---------|-------|\n| Steering Committee | Status, risks, decisions needed | Bi-weekly | Formal meeting | PM |\n| Process Owners | Workstream progress, open items | Weekly | Teams\u002FSlack | Workstream Lead |\n| End Users | Project awareness, timeline, training | Monthly | Email\u002FTown Hall | Change Manager |\n| IT Team | Technical progress, dependencies | Weekly | Stand-up | Tech Lead |\n\nEvidence: Communication plan table with all stakeholder categories covered.\nGate: Every stakeholder group from Step 1 appears in the communication plan.\n\n### Step 6: Risk Register\nIdentify SAP-specific project risks:\n\nEach risk must include:\n- **Risk ID and Name:** Specific, not generic (e.g., \"Legacy GL account structure incompatible with Universal Journal\" not \"Data migration risk\")\n- **Category:** Technical, Functional, Organizational, Integration, Data, Resource\n- **Probability:** H\u002FM\u002FL with justification\n- **Impact:** H\u002FM\u002FL with estimated day\u002Fcost impact\n- **Mitigation:** Specific action with owner and deadline\n- **Contingency:** What happens if the risk materializes despite mitigation\n\nEvidence: Risk register with minimum 5 risks, each with all 6 attributes.\nGate: At least 2 risks must be rated High probability or High impact.\n\n### Step 7: Generate Project Charter\nAssemble the charter document using the deliverable template below.\n\nEvidence: Complete charter document with all sections populated.\nGate: All Hard Gate conditions met.\n\n## Deliverable Template\n\n```markdown\n# SAP Project Charter\n\n## Project Overview\n- **Project Name:**\n- **Client:**\n- **SAP Product:** [S\u002F4HANA Cloud \u002F S\u002F4HANA On-Premise \u002F BTP \u002F SuccessFactors \u002F etc.]\n- **Implementation Approach:** [Greenfield \u002F Brownfield \u002F Bluefield \u002F Selective Data Transition]\n- **SAP Activate Phases:** [Which phases are in scope for this engagement]\n- **Target Go-Live:**\n- **Budget Range:**\n\n## Stakeholder Register\n[Table from Step 1]\n\n## Scope Definition\n### In Scope\n[From Step 2 — all 7 in-scope categories]\n### Out of Scope\n[From Step 2 — explicit exclusions]\n\n## Governance Model\n[From Step 3]\n### Escalation Matrix\n[Severity levels with paths]\n### Quality Gates\n| Activate Phase Transition | Gate Criteria | Decision Maker |\n|---------------------------|---------------|----------------|\n\n## RACI Matrix\n[From Step 4]\n\n## Communication Plan\n[From Step 5]\n\n## Risk Register\n[From Step 6]\n\n## SAP Activate Phase Mapping\n| Phase | Key Deliverables | Duration (est.) | Quality Gate |\n|-------|-----------------|------------------|--------------|\n| Discover | Project charter, stakeholder analysis | | |\n| Prepare | Scope finalization, team onboarding, environment setup | | |\n| Explore | Fit-to-Standard workshops, fit-gap analysis, process design | | |\n| Realize | Configuration, development, testing | | |\n| Deploy | Cutover, go-live, hypercare | | |\n| Run | Steady-state support, optimization | | |\n\n## Assumptions and Constraints\n[List all assumptions that underpin this charter]\n\n## Sign-Off\n| Name | Role | Signature | Date |\n|------|------|-----------|------|\n```\n\n## Verification\n\nThis skill is complete ONLY when ALL of the following are true:\n\n- [ ] Stakeholder register has 8+ named individuals across 4+ categories\n- [ ] Scope statement has explicit in-scope AND out-of-scope sections with SAP module specifics\n- [ ] Governance model names real people (not just roles) for steering committee and escalation\n- [ ] RACI matrix has exactly one A per decision area and covers 10+ decision types\n- [ ] Communication plan covers every stakeholder group identified in Step 1\n- [ ] Risk register has 5+ SAP-specific risks with probability, impact, mitigation, and contingency\n- [ ] Charter maps deliverables to SAP Activate phases\n- [ ] Out-of-scope section contains specific named exclusions (not \"everything else\")\n- [ ] All assumptions are stated explicitly in the charter\n\n**Evidence required:** Complete project charter document with all sections populated and no placeholder text.\n\nIf any verification item is not met, the skill is NOT complete. Do not claim completion.\n\n## Next Skill\n\nAfter completing this skill, invoke one of:\n- `estimation` — When the project needs effort estimates for planning and budgeting\n- `fit-gap-analysis` — When moving into Explore phase to assess requirements against SAP standard\n\nConditions for handoff: Charter is signed off (or ready for sign-off) and the project is transitioning from Discover\u002FPrepare into Explore or needs detailed estimation for budget approval.\n\n## Cross-References\n\n- `estimation` — For detailed effort estimation referenced in the charter\n- `change-management` — For expanding the stakeholder analysis into a full OCM plan\n- `value-advisory` — For building the business case that justifies the project charter\n- `sap-activate-methodology` — For detailed phase gate criteria referenced in governance\n",{"name":5,"phase":41,"persona":42,"description":7},"Discover \u002F Prepare","Project Manager, Change Management Lead, Solution Architect","main","cf5d032baea1657808fa74369439ea7e9c7e0a20","skills\u002Fconsulting\u002Fproject-kickoff",3,"https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers","https:\u002F\u002Fsap-superpowers.vercel.app\u002F","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24","2026-08-23 17:03:43",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add vigneshbarani24\u002Fsap-superpowers --skill project-kickoff",{"tool":57,"command":58},"bunx","bunx skills add vigneshbarani24\u002Fsap-superpowers --skill project-kickoff",{"tool":60,"command":61},"pnpm","pnpm dlx skills add vigneshbarani24\u002Fsap-superpowers --skill project-kickoff","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fconsulting\u002Fproject-kickoff\u002FSKILL.md",true,[],[66,87,94,103,112,120],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":36},"01M6EQTMCBV605ETS5WWEQX209","s4hana-migration","Use when advising on S\u002F4HANA migration approach, assessing greenfield vs brownfield vs selective data transition options, analyzing custom code impact, reviewing simplification items, or building a migration business case or timeline.","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Fs4hana-migration\u002FSKILL.md",[],[73,74,75,76,77,24,78,21,79,80,81,26,30,82,83,33,84,85,86,35],"migration","s4hana migration","data","case","impact","simplification","brownfield","options","business case","business","technical","timeline","analyzing","code",{"skillNo":88,"name":89,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":36},"01M6EQTGJHSYYQDMBJY0APE19X","rise-licensing","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Frise-licensing\u002FSKILL.md",[],[93],"rise licensing",{"skillNo":95,"name":96,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":36},"01M6EQTCVAJPYQ7A8SA49A1Y72","joule-strategy","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Fjoule-strategy\u002FSKILL.md",[],[100,101,102],"joule strategy","joule","strategy",{"skillNo":104,"name":105,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":36},"01M6EQTA7RMJ6RNFDTK1E2E9YY","clean-core-strategy","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Fclean-core-strategy\u002FSKILL.md",[],[109,110,111,102],"clean core strategy","clean","core",{"skillNo":113,"name":114,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":36},"01M6EQT6QCR8MJ7J62ZP8WZ578","activate-methodology","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Factivate-methodology\u002FSKILL.md",[],[118,27,119],"methodology","activate methodology",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":36},"01M6EQT3XFHC6Y2F0EWQ62PHSR","strategic","strategic skills category for SAP Superpowers. Contains 5 sub-skills.","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002FSKILL.md",[],[122,127,25],"superpowers"]