About

A readiness playbook for software projects. It defines the mandatory artefacts and the approval workflow every project goes through before any line of code, from business conception to the formal authorisation to start development (the Go/No-Go gate).

Why it exists

Projects that start coding without formal alignment between business and technology accumulate rework, ownerless decisions and requirements nobody tests. The Day Zero Playbook attacks that with three mechanisms:

• Objective gates: every step has verifiable entry (DoR) and acceptance (DoD) criteria; approval is not subjective.
• Separation of duties: whoever produces an artefact is never the one who approves it.
• Self-sufficient handoff: each step’s artefact must be enough for another team to run the next step without depending on the previous one. That is what allows internal, contracted and partner teams to alternate along the flow.

Vocabulary

The Day Zero Playbook is organised internally into Chapters (1-10, parts of the document) and Steps (0-6, stages of the workflow). A reference like “Chapter 7” points inside the normative document; “Step 3” points to a stage of the workflow.

It covers pre-development readiness; the topics that follow (security, deploy, code review, closure) are roadmap companions handled outside this playbook.

Versioning and contribution

The Day Zero Playbook uses its own semantic versioning; see the CHANGELOG. The document is reviewed quarterly by the Architecture Team, informed by the process metrics (Chapter 4.4). To suggest a change, open an issue or contact the Architecture Team.

On agile and bureaucracy

The Day Zero Playbook is not a reaction against agile, and it does not exist to add control.

I work with agile. What this playbook covers is what happens before the first sprint: the alignment between business and technology that, when missing, comes back as rework mid-development. After the Go/No-Go gate, the team works the way it already works — the playbook ends exactly where development begins.

It does not invent a new process either. BRD, HLD, LLD/TDD, SAD, ADR and Go/No-Go already exist and are already practised, usually scattered and with no clear owner. What the playbook does is bring together resources that are already there into a single path, state who produces and who approves each step, and match the rigour to the project’s criticality — at Low criticality, BRD and HLD fit in a one-pager.

The goal is a healthy path: less rework, decisions with owners, and a development start that does not rely on guesswork. If on some project the playbook is producing paperwork instead of clarity, either the chosen track was too heavy for its criticality — or the playbook needs to change. Open an issue when that happens.