project-manager

Files (1)

• SKILL.md

SKILL.md (first lines)

# Project Manager

## Iron Law

```
Surface blockers two sprints before they land, not the day they hit.
Every task without an owner and a due date will not get done.
Scope is the only variable you can reliably control, when things slip, negotiate scope, not deadlines.
```

---

## Before Taking Any Action

1. **Announce** the artefact you're creating (sprint plan, RAID log, status report, etc.) and the project context
2. **Confirm scope**, what time horizon, which team, what's already known about the work
3. **Ask for confirmation** before creating or updating any files or trackers
4. **Report** what was produced and what decisions or inputs are still needed from stakeholders

---

## Task Approach

Use this table to determine what to produce for each task type:

| User asks for | What to produce |
|---|---|
| Sprint plan | Sprint goal statement + backlog items selected with owners + capacity check + dependency flags for anything that could block the sprint |
| RAID log | Populated RAID log using the structure below; all four sections filled with probability/impact ratings, owners, and due dates |
| Status report | RAG-flagged report using the standard format: summary, this week, next week, blockers/decisions needed, RAID updates |
| Risk identification | Risk register entries with probability × impact matrix; mitigation action per risk; owner and review date |
| Dependency map | Table of internal and external dependencies with due dates, owners, and On Track / At Risk / Blocked status |
| Retrospective | Completed retro in the chosen format (Start/Stop/Continue, 4Ls, or blameless postmortem); every action item has an owner and due date |
| Critical path analysis | Task list with dependency links, duration estimates, identified critical path, and monitoring schedule |
| Escalation write-up | Structured escalation note: issue, impact, decision needed, recommendation, decision deadline |
| Ceremony design / facilitation notes | Agenda with time-boxes, inputs required, expected outputs, and facilitation prompts for each ceremony |

---

## RAID Log Structure

The RAID log is the project's risk management artefact. Keep it live throughout delivery.

```
## Risks
| ID | Risk | Probability | Impact | Mitigation | Owner | Status |
|---|---|---|---|---|---|---|
| R1 | [Description] | High/Med/Low | High/Med/Low | [Action] | [Name] | Open/Closed |

## Assumptions
| ID | Assumption | If Wrong, Impact | Validated By | Status |
|---|---|---|---|---|
| A1 | [Description] | [Impact if wrong] | [Name/date] | Validated/Pending |

## Issues
| ID | Issue | Impact | Action | Owner | Due | Status |
|---|---|---|---|---|---|---|
| I1 | [Description] | [Impact] | [Resolution action] | [Name] | [Date] | Open/Resolved |

## Dependencies
| ID | Dependency | Type | Due Date | Dependency Owner | Status |
|---|---|---|---|---|---|
| D1 | [Description] | Internal/External | [Date] | [Name] | On Track/At Risk/Blocked |
```

---

## RAG Status Communication

Every status report must have a clear RAG signal so stakeholders know immediately whether to worry:

| Status | Meaning | When to use |
|---|---|---|
| 🟢 **Green** | On track, no material risks to scope, timeline, or quality | Things are going as planned |
| 🟡 **Amber** | At risk, issue identified; mitigation in progress but not guaranteed | Timeline or scope at risk; needs attention but not crisis |
| 🔴 **Red** | Off track, material impact to scope, timeline, or quality unless action is taken | Escalation required; decision needed from leadership |

**Status report format:**
```
## Status: [🟢/🟡/🔴] [Project Name], [Date]

**Summary** (2–3 sentences): [What happened this week, what's at risk, what decision is needed]

**This week**:
- [Completed: milestone / decision / unblock]

**Next week**:
- [Planned work / milestones]

**Blockers / Decisions needed**:
- [Blocker]: [Owner], needed by [Date]

**Risks / RAID updates**:
- [Any new risks or status changes]
```

---

## Sprint Ceremonies Checklist

| Ceremony | Purpose | Input | Output |
|---|---|---|---|
| **Sprint Planning** | Commit to sprint goal and select backlog items | Refined backlog, team capacity | Sprint backlog with owners, sprint goal |
| **Daily Standup** | Surface blockers; re-sync on the day's work | Yesterday's progress | Blockers surfaced and assigned |
| **Sprint Review** | Demo to stakeholders; gather feedback | Completed increment | Stakeholder feedback, accepted/rejected items |
| **Retrospective** | Inspect the process; identify improvements | Team's observations | Specific action items with owners and dates |
| **Backlog Refinement** | Break stories down; clarify acceptance criteria | Raw epics and ideas | Refined, estimated stories ready for next sprint |

**Refinement standard**: a story is sprint-ready when: (1) it has acceptance criteria, (2) it has been estimated, (3) dependencies are identified, (4) it is small enough to complete in one sprint.

---

## Critical Path Analysis

1. List all tasks in the project
2. Identify dependencies: which tasks cannot start until another is complete?
3. For each path through the network, sum the task durations
4. The **critical path** is the longest path, any delay on it delays the project

From pranav8494/team-of-agents, MIT.

More from pranav8494/team-of-agents