Initiatives
An initiative is the temporary work that answers one or more demands and changes one or more solutions. It is managed as a project, as small work or as urgent work; the mode decides its steps.
What belongs to it
Its requirements, work, delivery risks (schedule, cost, scope, dependencies, people), decisions about scope and priority, and open questions about the change. Risks about security, availability, compliance or operations, and decisions that bind the solution long term, belong to the solution. Move either way from the risk or decision page.
It closes only when all its work is Done or Cancelled and its open risks and questions are closed or moved to the solution.
Delivery on the initiative page shows the change's own delivery over 90 days, across the solutions it changes: finished work, rework, story cycle time and agent calls per finished story (counting only the calls made in this initiative's sessions). Every step of an initiative or a demand — created, moved, mode changed, closed — also appears in the audit trail of the solutions it changes.
Readiness on the initiative page lists its closing gates in one place: work closed, every acceptance criterion of its requirements met, no UAT session open, its design changes applied or rejected, no change proposal waiting, risks and questions settled. Each unmet gate names what is missing and who can settle it; open stories that miss the Definition of Ready are shown as advice. The portfolio board shows how many gates an initiative under way meets and the first one missing.
Modes and steps
- Managed as a project: Reviewing → Analyzing (lean business case, go/no-go) → Ready → Implementing (MVP, then Persevere) → Done.
- Managed as small work: Reviewing → Ready → Implementing → Done.
- Managed as urgent work: straight into Implementing, then Done; it may go over a WIP limit, and the overrun is recorded.
- An initiative moves one step at a time, forward or back. Not pursued closes it from any open step, with a reason. The mode can change; the change and the reason are written to its history.
- While it is open, a portfolio manager can change its capacity type and add or take off solutions it changes, each with a reason written to its history. A solution it still has work or requirements in cannot be taken off, nor the last one; a maintenance period keeps its solution and stays maintenance.
Closing and work
Maintenance: each solution has a maintenance initiative per quarter (small work); defects that are not part of another item go there. When the quarter ends, its open work moves to the next quarter's initiative and the old one closes. Emergencies: declaring a production emergency opens an urgent demand and an urgent initiative; the emergency defect and its make-good task belong to it, and it closes only with a post-incident review on its page — what happened, why the tests did not catch it, what changes, and a runbook for next time, in the blameless form. The criteria its defects violated are offered as the missed ones. Closing leaves behind, in each solution it touched: a proposed lesson linked to the missed requirements and the defect; a draft regression test for every missed criterion that has no working test (make it active once it is written); and the runbook as a Runbook reference, which then shows in the context of work on those requirements.
An initiative can be Done only when its closing gates are met (see Readiness on its page): every work item Done or Cancelled, its criteria met, its UAT finished, its design changes settled, no change proposal waiting; its demands close when all their initiatives have closed. New top-level work picks its initiative on the New work form; work under a parent follows the parent's initiative. Make default sets the initiative new work of a solution goes to when none is chosen.