E1 An existing modernisation programme
A multi-year rewrite was already underway for a workflow system over twenty years old, with a previous partial rewrite. The immediate question was how to improve progress within that programme.
A real engagement, in review format
How do we get completed work into use?
Anonymised engagement · Reconstructed review
A software development agency was partway through a multi-year modernisation programme for an enterprise client. The operational workflow system had been in use for more than twenty years and had already undergone a partial rewrite. Development was progressing slowly, with finished changes often waiting months for release.
Based on James’s first-hand account of a real engagement. Organisation names are omitted and the operating context is generalised. The five outputs below retrospectively present the work in today’s review format; they are reconstructed examples, rather than original client documents. The engagement included hands-on implementation over time.
What changed in the engagement
Releases moved from roughly once every three months to weekly, sometimes more often. Verification became fully remote, saving several thousand pounds per release and reducing rework, repeat verification and context switching.
Outcomes are reported from James’s experience. Frequencies and savings are approximate; no independently verified cost breakdown or exact transition period is presented.
The engagement account
These summaries come from James’s retrospective account, rather than a review of original client records. Each output refers back to these identifiers.
E2 Completed work waiting for release
Changes were written and tested, then shelved for months while waiting for a deployment slot sponsored by the responsible project manager. Releases happened roughly once every three months.
E3 Costly on-site verification
Each release required overnight opening of specialist facilities, security cover and overtime for engineers and testers. This made a release an expensive event to organise.
E4 Work revisited before deployment
Long gaps between completing and releasing changes meant rework, repeat verification and context switching between new work and older changes.
E5 The intervention James prioritised
James focused on why on-site verification was necessary, building confidence through automated verification and smaller, more frequent releases. Verification eventually became fully remote.
E6 Reported operational outcomes
Releases became weekly, sometimes more frequent. James reports savings of several thousand pounds per release and faster development through less rework, repeat verification and context switching. Figures are approximate retrospective recollections.
01 / Executive scorecard
What needs attention?
Anonymised engagement · Reconstructed review
This reconstructed scorecard looks at the situation before the improvements. Its qualitative assessments explain the priorities suggested by the account.
Flow of completed work
PriorityFinished, tested changes wait months for a sponsored release slot. Review the path from completion to operational use.
Evidence: E2E4Release confidence
PriorityVerification depends on an on-site event. Establish what must be demonstrated and which checks can be automated or performed remotely.
Evidence: E3E5Release cost
AttentionOvernight facilities, security and overtime create recurring overhead. Record the cost components before comparing release approaches.
Evidence: E3Development capacity
AttentionRework and repeat verification consume time that could advance the programme. Track the effect of reducing the wait.
Evidence: E2E4Modernisation direction
Focus the next stepA rewrite is already underway. Improving the release path helps completed changes reach users throughout the programme.
Evidence: E1E2The reported outcomes appear in E6. The assessments here explain the starting situation; they do not imply these issues remain today.
02 / Decision memo
Build confidence in the release path.
Anonymised engagement · Reconstructed review
Recommendation to programme leadership
Prioritise the release path within the modernisation programme. Establish what on-site verification needs to prove, build confidence with automated checks, and move to smaller, more frequent releases. Progress towards remote verification as the evidence supports it.
Why this recommendation follows
Completed changes waited months for release. Each deployment carried the cost and coordination of overnight on-site verification, while older work needed attention again. Improving that path could bring completed changes into use sooner and reduce repeated effort. This was the direction James prioritised within the existing rewrite. Evidence: E1E2E3E4E5
Continue the existing release model
Retains familiar on-site verification and scheduling, with recurring event costs and months of waiting for completed changes.
Assessment: Leaves the observed constraints in E2–E4 in place.
Prioritise release confidence and smaller changes
Requires engineering and client participation to establish verification criteria, automate checks and review the evidence.
Assessment: The direction James prioritised. It addresses the release constraint while the wider modernisation continues.
Increase feature-development throughput first
May complete more changes, while the deployment queue and verification overhead continue to limit when they reach users.
Assessment: Resolve the release constraint before assuming that more completed development will produce faster delivery.
What would change the recommendation?
Evidence that a check depends on the physical operating environment, or that remote checks do not provide the required confidence. Retain the relevant on-site verification while investigating an alternative. Review total effort as well as cost per release.
Reconstructed decision request: agree capacity and client participation at D1, then define verification criteria at D2. The account reports the eventual outcome in E6; this memo illustrates how the reasoning can be presented in a review.
03 / Decision and ownership map
Make the next decision—and its owner—clear.
Anonymised engagement · Reconstructed review
These role-based responsibilities illustrate how the decisions could be organised. They are proposed owners for the reconstructed review, rather than a record of the client’s historical reporting lines.
D1 Prioritise release improvement within the programme
- Accountable owner
- Programme sponsor
- Input needed
- Delivery lead summarises waiting time, rework and release overhead with the client team.
- Decision point
- Before allocating improvement capacity
- Consequence
- Agree scope and capacity to investigate verification and release scheduling. Links to R1 and R5.
D2 Agree the evidence required for a release
- Accountable owner
- Client operational owner
- Input needed
- Engineering and testing leads map on-site checks to the confidence each check provides.
- Decision point
- Before changing the verification approach
- Consequence
- Define acceptance criteria and identify checks that can be automated or performed remotely. Links to R2 and R4.
D3 Authorise smaller, more frequent releases
- Accountable owner
- Client release owner
- Input needed
- Verification results, a release procedure and a recovery approach reviewed with engineering.
- Decision point
- When D2 criteria are met for the proposed change
- Consequence
- Trial the revised release path and review failures, waiting time and effort. Links to R1–R3.
D4 Expand remote verification
- Accountable owner
- Client operational owner
- Input needed
- Evidence from the revised releases, remaining on-site dependencies and a cost comparison.
- Decision point
- When the evidence supports the next step
- Consequence
- Extend remote verification within agreed boundaries and retain checks that still need a physical presence. Links to R2–R5.
The adviser explains options and challenges assumptions. The client’s leadership makes decisions, assigns owners and authorises work.
04 / Prioritised risk register
Keep material risks visible.
Anonymised engagement · Reconstructed review
This reconstructed register separates the reported constraint from prospective risks to consider when changing a release process. It does not assert that those potential failures occurred.
R1 Completed work still waits for a sponsored slot
Impact: Automation alone may leave scheduling delays and repeat work in place.
Assessment: Observed constraint: E2 describes the deployment queue.
Owner: Programme sponsor
Action and review: Review release sponsorship and scheduling alongside engineering changes. Revisit at D1 and D3.
R2 Remote checks leave a verification gap
Impact: A change could reach operational use without the confidence previously provided by an on-site check.
Assessment: Prospective risk to test; the account does not describe a specific control failure.
Owner: Client operational owner
Action and review: Map checks to acceptance criteria at D2. Progress at D4 only where the evidence supports it.
R3 More frequent releases retain the same manual overhead
Impact: Increasing frequency could multiply release effort before the process is improved.
Assessment: Prospective risk grounded in the recurring overhead described in E3.
Owner: Engineering lead
Action and review: Track effort and cost per release and over time. Review the balance after each trial at D3.
R4 A physical dependency is missed
Impact: Some behaviour may still depend on the operational environment and need an on-site check.
Assessment: Open question for verification design; no specific dependency is asserted.
Owner: Testing lead
Action and review: Identify environment-dependent checks with operational staff at D2; retain necessary on-site checks until alternatives are demonstrated.
R5 Benefits are assumed without a comparable baseline
Impact: The team cannot distinguish avoided event costs from changes in total delivery effort.
Assessment: Measurement requirement: E6 is an approximate retrospective account.
Owner: Programme sponsor
Action and review: Define cost categories, waiting time and rework measures at D1. Review comparable evidence before extending the approach at D4.
05 / 30/60/90-day plan
Turn the decision into a sequence of work.
Anonymised engagement · Reconstructed review
This illustrative phasing shows how a review could turn the lessons into a practical plan. The original engagement’s transition period has not been specified; the reported results are not attributed to these 90 days or to a ten-day review.
Days 1–30
Understand the wait and the verification need
Agree D1. Map a change from completion to deployment, including sponsorship, repeated work and release costs. Work with operational staff to understand what each on-site check proves and agree D2 criteria.
Dependencies: Access to the delivery and operational teams, release information and agreed improvement capacity.
Evidence of progress: A documented release path, baseline definitions, verification criteria and a list of checks suitable for automation or remote execution.
Review gate
Day 30: review the proposed changes and unresolved verification needs. Keep necessary on-site checks while alternatives are tested.
Days 31–60
Build confidence through smaller releases
Automate suitable checks and trial smaller changes through the revised release path. Seek D3 authorisation against the agreed criteria. Review scheduling, recovery, repeat work and verification effort together.
Dependencies: D2 criteria, client agreement to trial releases and a reviewed recovery approach.
Evidence of progress: Verification results, time from completion to release, manual effort, recurring event costs and issues found during the trial.
Review gate
Day 60: review whether the approach provides sufficient confidence. Adjust the checks or release scope before extending it.
Days 61–90
Extend the approach where the evidence supports it
Use the trial evidence to consider D4. Expand remote verification where suitable and agree a repeatable release cadence with the client. Carry remaining dependencies into the modernisation plan.
Dependencies: Successful verification against agreed criteria, operational acceptance and a comparable view of cost and effort.
Evidence of progress: Release frequency, waiting time, on-site requirements, cost per release and total effort over time. Record remaining rework and verification gaps.
Review gate
Day 90: agree the next improvement scope and owners. The pace of transition depends on the evidence; this illustrative schedule is not the historical delivery timetable.
Leadership and the team own implementation. Further CTO Decision Support can be agreed separately when continued advice would help.
Your business, your decision
A review built around the question you need to answer.
An independent CTO review over 10 working days. Typically across 2–3 weeks. From £9,500 + VAT.