InitiativesIdea
Requirements
Requirements say what must be true when an initiative is done. They’re written in the words of the people who need it, and they say nothing about how it’s built.
Deciding the scope first
Section titled “Deciding the scope first”Once the problem is clear, the next argument is about how much to do. You decide it with the requirements, before anyone picks a way to build. One of them is the core goal, the thing the whole initiative is for. The rest are must-haves, nice-to-haves, or out.
You measure everything after against that list. You check the approaches against it, and a slice names the requirements it serves. “is it done?” has an answer. Each requirement shows as working, or not yet.
Proposed by the agent, decided by you
Section titled “Proposed by the agent, decided by you”When the brief is written, you press Start the requirements. The agent writes them from the brief, with a rationale for the whole list and what’s out of scope.
Then it suggests a level for each requirement, one at a time in the chat, with why. You accept it or pick another. Or you set the level yourself, straight on the requirement: Must have, Nice to have or Out. The levels are yours. The wording goes through the agent. You say what should change, and it writes it and says what changed.
Take a support case. A depot’s approver was promoted, and six access requests waited for nobody. The core goal says the waiting requests go to whoever approves for that depot now. A must-have: the requests go to the customer’s administrators when nobody at the depot can. One email to the new approver is nice to have. And requests that follow the person to their new role are out, because the person shaping it decided they stay with the depot.
- R0. The requirement’s key, kept when the list is reordered.
- Core goal. The thing the whole initiative is for. There’s one.
- Must have. The work fails without it.
- Nice to have. Worth having. The initiative stands without it.
Each requirement keeps its key, R0, R1 and so on, when the list is reordered. A comment or a slice that names R2 still points at the same requirement.
People you shared the initiative with as Takes part answer the level questions too. Someone in security can say an audit trail is a must-have, without being able to rewrite anything.
Publishing and after
Section titled “Publishing and after”Until every requirement has a level, the initiative can’t be published. Its Kickoff checks that each must-have fits the chosen approach, and shows the ones that only partly fit. While it’s built, each requirement shows how far along it is, based on its slices.
Once the initiative is approved, its requirements change only through a change request.
When the requirements fall into groups that share nothing, the agent may propose splitting some out into an initiative of their own. The core goal always stays.
A requirement isn’t a task or a design. “The waiting requests go to the depot’s new approver” is a requirement. “Move them when a role changes” is part of one approach. Keeping the two apart lets you compare several approaches against the same list.