Use this skill when planning, executing, or recovering software projects with a focus on risk management, dependency tracking, and stakeholder communication. Triggers on project planning, risk assessment, dependency mapping, status reporting, milestone tracking, stakeholder updates, escalation decisions, timeline estimation, resource allocation, and project recovery. Covers RAID logs, critical path analysis, and communication cadences.
Instrucciones de origen · Vista previa de solo lectura
name
project-execution
version
0.1.0
description
Use this skill when planning, executing, or recovering software projects with a focus on risk management, dependency tracking, and stakeholder communication. Triggers on project planning, risk assessment, dependency mapping, status reporting, milestone tracking, stakeholder updates, escalation decisions, timeline estimation, resource allocation, and project recovery. Covers RAID logs, critical path analysis, and communication cadences.
Risks are first-class artifacts - Every project maintains a living risk register. A risk without an owner, a likelihood rating, and a mitigation plan is just a worry. Quantify risks on a 3x3 matrix (likelihood x impact) and review them weekly, not just at kickoff.
Dependencies are contracts, not hopes - When your timeline depends on another team's deliverable, treat it as a contract. Document the what, the when, the who, and the fallback if it slips. Check dependency health weekly - do not wait for the deadline to discover a slip.
Communicate before they ask - Stakeholders should never learn about problems from a status meeting. Bad news travels up immediately. Status updates are predictable, structured, and honest. Use red/amber/green (RAG) status consistently and never inflate green to avoid a conversation.
Plan for recovery, not perfection - Every plan will deviate. The mark of good execution is how fast you detect deviation and course-correct. Build explicit decision points (go/no-go gates) into the plan, not just milestones.
Scope is the primary lever - When timeline, resources, and quality are constrained, scope is the variable you negotiate. Never silently reduce quality to hit a date. Make trade-offs explicit and get stakeholder sign-off.
Core concepts
RAID Log - The central tracking artifact for any project. Risks are things that might happen. Assumptions are things you believe to be true but have not verified. Issues are risks that have materialized - they are active problems. Dependencies are external deliverables your project requires.
Critical Path - The longest sequence of dependent tasks that determines the minimum project duration. Any delay on the critical path delays the entire project. Non-critical tasks have float (slack time). Focus risk mitigation and dependency tracking efforts on critical-path items first.
RAG Status - Red/Amber/Green health indicator used in status reporting. Green means on track with no significant risks. Amber means at risk - there are issues that could cause a miss without intervention. Red means off track - the current plan will not meet its commitments without a scope, timeline, or resource change. Define these thresholds explicitly at project start.
Stakeholder Map - A matrix classifying stakeholders by influence and interest. High-influence/high-interest stakeholders get direct, frequent updates. Low-influence/low-interest stakeholders get broadcast updates. Misclassifying a stakeholder's quadrant is a common source of project friction.
Common tasks
Build a risk register
Create a structured table with these columns: Risk ID, Description, Likelihood (Low/Medium/High), Impact (Low/Medium/High), Risk Score (L x I), Owner, Mitigation Plan, Status (Open/Mitigated/Occurred), Last Reviewed. Seed the register during planning by running a pre-mortem exercise - ask "It is 3 months from now and this project has failed. What went wrong?" Categorize risks into Technical, Resource, Dependency, Scope, and External buckets.
Risk ID
Description
L
I
Score
Owner
Mitigation
Status
R-001
Auth service migration delays our API launch
H
H
9
@alice
Build adapter layer to decouple; weekly sync with auth team
Open
R-002
Key engineer on PTO during final sprint
M
M
4
@bob
Cross-train second engineer by week 3
Open
R-003
Third-party API rate limits hit during load test
L
H
3
@carol
Request limit increase by week 2; implement circuit breaker
Open
Map project dependencies
Create a dependency graph with four attributes per dependency: Source (who needs it), Target (who provides it), Deliverable (what exactly), Due Date, and Fallback Plan. Visualize as a table or directed list. Flag any dependency where the target team has not acknowledged the commitment - these are "unconfirmed dependencies" and carry the highest risk.
Dependency Chain:
[Design Team] --wireframes (Mar 20)--> [Frontend Team] --UI components (Apr 5)--> [QA Team]
[Auth Team] --OAuth SDK v3 (Mar 25)--> [Backend Team] --API endpoints (Apr 10)--> [QA Team]
[Data Team] --schema migration (Mar 15)--> [Backend Team]
Unconfirmed: Auth Team has not acknowledged Mar 25 date - ESCALATE
Write a weekly status update
Follow this template for consistent, scannable status updates:
Before execution begins, run a structured pre-mortem session. Prompt the team (or simulate as an agent) with: "Assume this project has failed spectacularly. List every reason why." Group responses into categories (Technical, People, Process, External). Convert the top findings into risk register entries with owners and mitigations. A pre-mortem surfaces risks that optimism bias hides during normal planning.
Create a stakeholder communication plan
Map each stakeholder to a communication cadence:
Stakeholder
Role
Influence
Interest
Update Frequency
Channel
Content Level
VP Engineering
Sponsor
High
High
Weekly + ad-hoc
1:1 + email
Executive summary
Product Manager
Partner
High
High
Twice weekly
Slack + standup
Detailed
Platform Team
Dependency
Medium
Medium
Weekly
Email
Dependency status only
Design Team
Contributor
Low
High
As needed
Slack
Task-level
Perform critical path analysis
List all tasks with their durations and dependencies. Identify the longest path through the dependency graph - this is your critical path and minimum project duration. Calculate float for non-critical tasks. When the critical path is too long, apply schedule compression: fast-tracking (parallelizing sequential tasks that can overlap) or crashing (adding resources to critical-path tasks with the lowest incremental cost).
Write an escalation
When a project turns red, escalate with this structure: (1) State the problem in one sentence, (2) Quantify the impact (days of delay, revenue at risk, users affected), (3) List options with trade-offs (never escalate without options), (4) State your recommendation, (5) Name the decision needed and by when. Never surprise leadership - pre-wire key stakeholders before the formal escalation.
Run a go/no-go gate review
At each major milestone, run a structured gate review. Check: Are all entry criteria met? Are all critical-path dependencies delivered? Are open risks within acceptable thresholds? Is the team confident in the next phase estimate? Document the decision (Go, Conditional Go with actions, or No-Go with remediation plan) and circulate to all stakeholders within 24 hours.
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Tracking risks only at kickoff
Risks evolve weekly. A static register gives false confidence.
Review and update the risk register every week. Add new risks as they emerge.
Treating all dependencies equally
Not all dependencies are on the critical path. Spreading attention equally means critical ones get insufficient focus.
Prioritize dependency tracking by critical-path impact.
Reporting green until suddenly red
Skipping amber destroys trust. Stakeholders cannot help if they do not see the warning signs.
Use amber honestly. An amber status with a mitigation plan builds more confidence than false green.
Escalating without options
Dumping a problem on leadership without solutions signals lack of ownership.
Always present 2-3 options with trade-offs and your recommendation.
Silent scope changes
Absorbing scope increases without adjusting timeline or resources leads to burnout and quality drops.
Make every scope change visible. Log it, assess impact, get sign-off.
Single-threaded dependencies
One person as the sole contact for a critical dependency is a single point of failure.
Ensure every critical dependency has a backup contact and a documented handoff plan.
Gotchas
Dependency treated as confirmed when it's just assumed - The most common project failure mode: a team plans against a dependency that the other team never actually acknowledged. Always get explicit written confirmation (Slack/email/ticket) from the dependency owner before putting it on the critical path.
RAG status inflated to avoid a difficult conversation - Amber status that gets reported as green because "we'll figure it out" destroys trust the moment the project turns red without warning. Define green/amber/red thresholds explicitly at kickoff so status becomes factual, not emotional.
Escalating without options - Bringing a problem to leadership without presenting 2-3 options and a recommendation signals lack of ownership and puts the cognitive load on the wrong person. Always escalate with options.
Pre-mortem skipped as a team-building exercise - Teams skip pre-mortems because they feel pessimistic. The result is that obvious risks (key person dependency, unconfirmed external dates) go unregistered until they materialize. Run a pre-mortem even if it's 30 minutes.
Go/no-go gate treated as a formality - When a gate review happens but decisions are never actually no-go, the process loses credibility. Gates need real criteria and the authority to halt. If a gate has never blocked anything, it's not a gate.
References
For detailed guidance on specific sub-domains, read the relevant file from the references/ folder:
references/risk-management.md - Deep dive on risk identification techniques, quantitative risk analysis, and mitigation strategy patterns
references/stakeholder-communication.md - Communication templates, stakeholder mapping frameworks, and difficult conversation playbooks
Only load a references file if the current task requires it - they are long and will consume context.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
