# From idea to operation

Take an idea through to an owned system.

Use explicit decisions to move from a business problem to a useful, supportable release.

## Delivery decision points

- **Discovery:** Which workflow changes, for whom and why?
- **Design:** What boundaries and tradeoffs shape the solution?
- **Delivery:** What evidence demonstrates the agreed behaviour?
- **Operation:** Who maintains, observes and recovers the result?

## Keep scope connected to an outcome

A feature list can grow without improving the task. Trace each increment to a user need and define what is deliberately outside the release.

## Prepare ownership before launch

Access, runbooks, deployment and support arrangements should be ready before users depend on the application.

## Follow one business outcome through delivery

A project becomes easier to manage when the same outcome remains visible from discovery to operation. For a customer request portal, follow a request from submission through validation, assignment, fulfilment and confirmation. Identify the systems and people responsible for each transition. This gives the team a shared thread through decisions that might otherwise become separate technical tasks.

Use that workflow to establish the first useful release. It may cover one request type or user group while leaving other work in the existing process. Record those limits so staff know when to use the new system and when to follow the old route. A staged launch should have a clear operating model, not just fewer features.

## Use evidence at the handoffs

Discovery should hand over a bounded scope and acceptance examples. Design should make the interaction and exception paths understandable. Implementation should demonstrate the agreed behaviour with appropriate tests. Release planning should show how the change will be deployed, observed and reversed if necessary.

At each handoff, identify what the receiving person needs to proceed. A screenshot may explain an interface but not its permissions. A passing build may show code consistency but not that an external provider accepts the request. Ask for evidence relevant to the next responsibility. This reduces the chance that unresolved assumptions move quietly downstream until they become expensive to correct.

## Continue after the first release

Agree who owns the application, its dependencies and its improvement backlog after launch. Review the actual workflow with users and compare it against the original reason for the project. Distinguish defects from additional opportunities and record how each enters the delivery process.

Keep operational feedback close to product decisions. Repeated support requests may indicate confusing content, weak validation or an integration that needs a better recovery path. A useful follow-up release may simplify an existing task rather than add another feature. The delivery path should leave the business with a system it can operate and a clear way to decide what is worth improving next.

## When should operations join the project?

Early enough to influence architecture, monitoring and recovery. Handover should confirm a prepared operating model, not introduce one at the end.