The Kickoff

The Kickoff is the page an initiative is published and approved from. It holds two things: a few sentences on the plan, and the checks that say it’s ready.

Short, on purpose

By the time an initiative is shaped, its answers are spread over its sections. Someone asked to approve it shouldn’t have to read them all. The Kickoff used to retell each section, and most of it repeated another one. So we cut it down to two things the other sections don’t say. The plan in brief, and whether it’s ready.

In short is that brief. Once an approach is chosen, the agent writes it, and writes it again whenever the initiative changes, until it’s published. It says what gets built and why this way, what’s left out, and what’s still open. The agent writes it before you publish, so the publisher reads it first.

Ready to publish

Before you publish, the people who edit the initiative see which checks are done, what’s missing and how to fix it. Publish waits until the ones that hold it are done.

Emargen’s own checks look for gaps in the plan, like a requirement with no level, a must-have the chosen approach doesn’t meet, or slices not cut yet. A must-have that only partly fits shows what’s missing, and you can have the agent adjust the approach or accept the gap and say why.

Two of them catch work that’s really another initiative. One looks for an open initiative that already aims at the same outcome. If it finds one, you merge into it or say why yours is different. The other is the scope check. When the requirements look like two initiatives, you split it, or keep it as one and say why.

Then come your workspace’s own checks, set under Workspace. A person ticks one, or the agent reads the initiative and says if it’s met. Each one says if Publish waits for it. Open questions show too, but Publish never waits for them.

Someone in customer success shaping a fix for requests stuck after a role change gets this far. Emargen’s checks are done. The customer read the brief on a call, which meets one of the workspace’s checks. Security hasn’t read it yet, and Publish doesn’t wait for that one.

Published

When you publish, Emargen keeps a copy of the initiative as it stands, its published version. Approval is recorded against that version, and it’s what a coding agent reads when it asks Emargen what was published. The people who may approve it find it in their Decisions.

On it, you see that it waits for approval, and who can approve it. In short and the checks stay on it, for everyone who can open the initiative, so the person deciding sees what was checked and who ticked what.

123456Full size

Published and waiting for a yes. The person approving reads the plan in brief, then every check and what it found.

1. Waiting for approval. When it was published, and who can approve it.
2. Approve. For the people who may approve it.
3. In short. The plan in a few sentences.
4. Emargen’s checks. What each one found.
5. Open questions. They’re shown, but Publish never waits for them.
6. ACME’s checks. The workspace’s own, with who ticked each.

A question about the plan goes in the Kickoff’s comments, where the owner answers it.

Nobody edits the Kickoff. It’s written from the initiative, so you answer a question about a requirement on Requirements itself.

Next

How to

• Publish and get approval

Page by page

• The Kickoffevery part of the page.