From request to results: the lifecycle of a technology investment

Every technology investment follows the same path, whether anyone draws it or not. A need is noticed, a request is made, a decision is taken, work is done, something is released, and a result happens, or doesn't. The technology investment lifecycle is simply that path made explicit, with a clear output at each stage.

Making it explicit matters because value is usually lost in the hand-offs between stages, not inside them.

The six stages

Stage 1: Request

A request should describe a problem, not a solution. "Field supervisors spend 40 minutes a day re-keying inspection data" is a request. "Build a mobile inspection app" is a proposed solution that hides the problem it's meant to fix.

Where it goes wrong: requests arrive by email or in hallway conversations, with no consistent information. See Building an IT intake process that captures the why.

Stage 2: Assessment

Assessment estimates value, complexity and risk well enough to compare the request with others. It isn't a full business case. For most requests, a relative rating on a simple scale is enough. Precision can come later, for the requests that survive.

Assessment should also identify which products, systems and teams the request touches. A change that looks small to one team can be large once dependencies are visible. See Mapping your product and technology landscape.

Where it goes wrong: every request gets the same heavyweight treatment, so the queue backs up and people route around it.

Stage 3: Decision

The decision is the hinge of the lifecycle. A good decision record states:

• what was approved, deferred or declined, and why;
• who owns the outcome;
• the assumptions the decision rests on, such as budget, capacity and benefits;
• what will trigger a revisit.

Where it goes wrong: decisions are made informally and never recorded, so six months later nobody can explain why a project exists. See Designing a project approval workflow.

Stage 4: Delivery

Delivery is where most tools focus, and where most organizations already have reasonable discipline. The value question during delivery is narrower: is the value case still intact? If scope has doubled or the key assumption has changed, the decision should be revisited rather than quietly absorbed.

Where it goes wrong: the status turns amber, but no one asks whether the investment is still worth finishing. See Leading indicators of project trouble.

Stage 5: Release

Release confirms that what was built meets acceptance criteria and that people are starting to use it. Adoption is the first real evidence of value, and it is often the most neglected.

Where it goes wrong: the project closes at go-live, and the team that could fix adoption problems has already moved on.

Stage 6: Outcome

The outcome stage compares what happened with what the request promised. Did the 40 minutes a day become 10? Did error rates fall? It also captures what was learned, so future estimates improve.

Where it goes wrong: this stage simply doesn't happen. See The post-implementation review your organization keeps skipping.

The thread that holds it together

The six stages only create value when they share one thread: the objective set at Stage 1. The objective guides the assessment, justifies the decision, shapes delivery trade-offs, defines acceptance, and is the yardstick at the outcome review.

When each stage lives in a different tool (intake in a form, decisions in slides, delivery in Jira, outcomes nowhere), that thread breaks. The most practical improvement most organizations can make is to keep the objective attached to the investment at every stage.

Matching effort to size

Not every request needs all six stages in full. A useful rule:

• Small changes (days of effort): lightweight request and decision; outcome noted in passing.
• Medium initiatives (weeks to a few months): full request and assessment, recorded decision, outcome review.
• Large programs: everything above, plus gates at key points and periodic re-validation of the value case.

How Aizu follows the lifecycle

Aizu keeps one record per initiative from intake to outcome. The intended outcome and owner are captured at intake; value, complexity and risk are assessed and compared across the portfolio; approval decisions and gate checks are recorded; delivery evidence comes from Jira or Azure DevOps; and objectives, key results and KPIs carry through to measurement. The thread doesn't break between stages. Read more in What is project value management?