Portfolio Accountability Rhythm

Use this when the team needs to turn "we should do this" into clear promises with dates, owners, and visible follow-through.

The goal is simple:

• every active initiative states what it is promising
• every active project states what it will deliver by when
• every active item has one live issue that reflects the current truth
• reviews are about commitments kept vs missed, not vague progress updates

Scope

The company portfolio primarily tracks ongoing initiatives. Standalone project pages are limited to bounded, core, cross-cutting work outside routine delivery. Campaigns, product releases, monthly cycles, and delivery tasks are tracked in execution systems and summarized or linked from their initiatives. Apply this scope before reviewing project commitments.

Operating rule

No initiative or project should stay active unless all of these are true:

1. It has one accountable owner.
2. It has a concrete commitment or definition of done.
3. It has a target date, end date, or explicit review point.
4. It has measurable key results or a success test.
5. It has milestone dates.
6. It has one active tracking issue.
7. For executive review, it records when it was last reviewed.

If one of those is missing, the item should be:

• rewritten immediately
• downgraded to idea
• or paused until someone is willing to own it properly

Team activity: Promise Reset

Run a 90-minute working session with the leads for every active initiative/project.

Step 1: Open the active portfolio

• Review all status: active items in initiatives/ and projects/.
• For each item, ask: "What exactly are we promising, and by when?"

Step 2: Force a one-sentence commitment

For each active item, write:

• initiatives: commitment, meaning what we are promising to achieve
• initiatives: target_date, meaning when that promise will be judged
• projects: definition_of_done, meaning what finished means
• projects: end, meaning when the work will be judged

This should be specific enough that it can be marked kept or missed.

Step 3: Define the success test

For each item, write:

• 1 to 3 key results for initiatives
• a success metric and definition of done for projects

If the team cannot agree on how success will be judged, the work is not well-defined yet.

Step 4: Define milestones

For each active item, add 2 to 5 milestone dates with concrete outputs.

Examples:

• proposal sent
• pilot live
• demo published
• review completed
• first 10 qualified leads generated

Step 5: Name the live issue

Each active initiative or project gets exactly one active issue that answers:

• what is the current commitment
• what is blocked
• what changed since last review
• what is next before the next milestone

If more detailed sub-work exists, link sub-issues from that parent issue. But the parent issue remains the executive checkpoint.

Step 6: Make the hard calls in the room

For every active item, force one of three outcomes:

1. active and committed
2. paused because the owner/date is not real
3. idea because it is still exploratory

This is the crucial step. The portfolio only becomes trustworthy when the team is willing to remove fake-actives.

Weekly review rhythm

Run one weekly portfolio review, 30 to 45 minutes.

For each active item, review only:

• commitment
• target date
• milestone due before next review
• whether the active issue is up to date
• red / amber / green confidence

Questions to ask the owner:

1. Are we still on track to keep this promise by the target date?
2. What proof moved this forward since the last review?
3. What is the next dated milestone?
4. What is the risk that could cause us to miss?
5. If we are off track, what is the reset: scope, date, or owner?

Review discipline

Use these rules:

• Missed milestone without explanation: update the item the same day.
• Missed target date: mark the commitment missed and rewrite the promise explicitly.
• No issue update since the last review: item is automatically at risk.
• No owner in the room: item is not reviewable and should not remain active for long.

What the CEO should expect to see

For every active item, the CEO should be able to answer in under 30 seconds:

• what is the promise
• who owns it
• by when it will be judged
• what the next milestone is
• whether it is on track
• where the live issue is

If that cannot be answered, the portfolio is not ready for executive tracking.

Minimal repo standard

Use these fields on active initiative pages:

• owner
• north_star
• next_step
• commitment
• target_date
• active_issue

Use these fields on active project pages:

• owner
• hypothesis
• success_metric
• definition_of_done
• end
• active_issue

For projects, definition_of_done and end carry the commitment and target date.

Use last_reviewed when an item is part of the weekly executive review rhythm.

Use body sections for:

• initiatives: ## Current Commitment, ## Key Results, ## Milestones, and ## Related Issues
• projects: ## What this project is, ## Plan of work, and ## Related Issues

Tracking issue rule

This repo uses bd for work tracking, so the preferred active_issue value is a bd-* issue id.

If GitHub issues are used as supporting context, link them in ## Related Issues, but keep one canonical active issue per item.

Suggested meeting output

At the end of the Promise Reset session, the team should have:

1. A cleaned list of active initiatives and projects.
2. A due date and explicit commitment for each active initiative.
3. A live issue for each active project and initiative.
4. A visible set of items that were paused because no one would make a real commitment.