project-execution

Files (6)

• README.md
• SKILL.md
• evals.json
• dependency-tracking.md · references/
• risk-management.md · references/
• stakeholder-communication.md · references/

SKILL.md (first lines)

## Key principles

1. **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.

2. **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.

3. **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.

4. **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.

5. **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:

```
## Project: [Name] - Week of [Date]
**Overall Status: [GREEN/AMBER/RED]**

### Progress this week
- [Completed item 1]
- [Completed item 2]

### Planned next week
- [Planned item 1]
- [Planned item 2]

### Risks & blockers
- [AMBER] [Risk description] - Mitigation: [action] - Owner: [name]
- [RED] [Blocker description] - Need: [what you need] - From: [who]

### Key decisions needed
- [Decision 1] - Deadline: [date] - Decision maker: [name]

### Metrics
- Milestone progress: [X/Y] complete
- Days to next milestone: [N]
- Open risks: [N] (H:[n] M:[n] L:[n])
```

### Conduct a pre-mortem

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. |

From mkurman/zorai, MIT.

More from mkurman/zorai