Goal, Baseline, Benefit

The scope gets settled first: what actually needs to be built, what already exists to build on, and the benefit the result is meant to bring. These three questions are answered before an estimate is given, not after. That way the expected benefit is fixed before the first line of code, not claimed once the project ends.

Feasibility, PoC, Cost

Feasibility gets checked before any money is committed: a small proof of concept tests the approach against the real task, not a slide deck. The PoC produces a solid cost estimate for the full build. Only then does the decision get made on whether to build at all.

Delivery and Contact

Before the work starts, it’s fixed who delivers which part and who is the contact for questions on both sides. Every task has one person behind it, not a shared responsibility with no name attached. That makes it clear from day one who to reach when something is off track.
Fixed Before Spend
the target and its benefit are agreed before you commit budget
Test Before Build
the cost estimate comes from a real test on your own task
Clear Ownership
every deliverable is assigned to a name and a fixed deadline
Direct Line
named contacts on each side are fixed before work starts

How the Scope Becomes a Plan With Cost and Named Contacts

Settle the Goal and the Baseline 3 steps
01

What Needs to Be Built

The scope starts with a plain description of what actually needs to be built: which problem it solves, for whom, and how far it reaches. That description is written down before anything gets planned or estimated, so everyone involved starts from the same goal.
02

What Already Exists

Existing systems, data and processes are mapped before anything new is built: which applications already run, which data is already there, and which parts of the task are already solved. Nothing gets rebuilt that the business already has.
03

The Expected Benefit

Every project states the benefit it should bring, whether in time, money or quality, and how that benefit will be measured. The expected benefit is fixed before the start, not claimed after the fact, so the result can be checked against it later.
Check Feasibility and Cost 3 steps
04

Technical Feasibility Checked

Before any money is committed, someone checks whether the requirement can actually be built against the systems and interfaces already in place. Open technical questions are named and settled one by one instead of carried into the build.
05

A Proof of Concept on the Real Task

A small proof of concept tests feasibility against the real task, with real data, instead of a slide deck. The result shows whether the chosen approach holds before the full build starts.
06

A Cost Estimate for the Full Build

The proof of concept produces a solid cost estimate for the full build, broken down by component rather than one lump figure. That estimate exists before the decision is made, not after, and it gets checked against the actual effort once building starts.
Who Delivers What 2 steps
07

Who Delivers What

Every task in the build gets a name behind it: who delivers it, by when, and what it gets accepted against. That assignment is fixed in the plan before the work starts, not only once a task falls behind.
08

One Owner Per Deliverable

Every deliverable has exactly one person responsible for it, not a shared responsibility with no name attached. That holds for every delivery, from the first prototype to the handover, and it is recorded in the plan next to the task.
Contact and Handover 2 steps
09

A Named Contact on Both Sides

A fixed contact exists on both sides for questions, not a shared inbox. Who decides on a deviation and who is reachable day to day is named before the start and recorded in the plan.
10

Handover With Clear Contacts

The plan leaves this phase with the target, the cost estimate and the list of contacts on both sides. That's what the build needs to start without further back and forth, and what any later deviation gets measured against by name, not by guesswork.

Frequently Asked Questions

What does a fact-gathering pass actually hand over?
Three things. A scaffold contract fixing the file tree, the owning track per path and every shared interface verbatim, so six tracks build in parallel. A provenance record naming the artifact behind every figure. And a drift list of what disagrees between two records, such as a stale manifest or a DNS record pointing at a box no longer owned.
What happens to a number that has no source?
It renders as a designed empty state with the reason shown on screen, and the provenance document says why empty is correct. On one build, three of five data files shipped empty on purpose: no test-report generator existed, no counterparty correspondence existed, no invoice had ever been issued.
Does this only work on a codebase?
The same readers run over media libraries, document folders, and time and billing records. A consolidated media repository carries per-path provenance and exact source commits, and a billing journey reconstructs an engagement from the time ledger so declared and derived hours agree. A figure with no recorded session behind it never appears.
Is the DSGVO and EU AI Act review a separate project?
It runs in the same pass, before AI reaches company data. The systems already in production are checked, the risk tier classified, and the places personal data is processed identified. Tasks involving personal data are flagged and reviewed. Deliverables are checklists written per stakeholder role plus onboarding material, so people outside IT can act on them.