Skipping discovery on a nine-month contract deadline
Northwind Utilities is replacing a 14-year single-source outsourcing contract with Helix IT that expires in nine months. The target model is five tower providers: network, data centre, applications, service desk and security. Current performance is poorly understood: about 1,100 incidents a month, 62% closed at first line, no end-to-end SLA, CMDB coverage estimated at 40% of the estate, and three separate ITSM tool instances. A retained team of 7 FTE will govern the new model. The programme director proposes skipping discovery and going straight to design because 'we already know our estate' and the go-live date is fixed by the contract end. The budget is €2.4m. Forty staff will transfer under TUPE, and two shortlisted bidders have said they will not sign without an agreed exit plan from Helix. The board wants a recommendation within two weeks.
1. Should the programme skip discovery? Justify your answer by reference to what discovery must produce.
Read the worked answer
Skipping discovery is not defensible, but the go-live constraint is real and must be designed around rather than ignored.
Discovery produces the baseline the whole business case and design depend on: the actual service catalogue and demand profile, current performance against end-to-end outcomes, the state of data and tooling, the contractual obligations and exit terms, provider and internal capability, and the risk register. At Northwind, three facts already show the baseline is missing - 40% CMDB coverage, no end-to-end SLA, and three tool instances. Designing a five-tower model on assumptions about those will produce SLAs that cannot be measured and interfaces that fail in transition.
A proportionate approach is a time-boxed discovery of six to eight weeks, scoped to what design actually needs: service and demand baseline, contract and exit analysis, tooling and data assessment, and organisational readiness including TUPE. It can run in parallel with early design for stable towers such as the service desk. The remaining five months then covers design, tender clarification and transition.
The recommendation to the board should state explicitly what discovery will not cover and what risk is accepted by the time-box, so the decision is informed rather than avoided.
2. Identify the main transition risks and propose a sequencing approach.
Read the worked answer
The dominant risks are knowledge drain, service discontinuity, data and tooling gaps, TUPE-related morale and attrition, provider readiness, and the exit from Helix itself.
- Knowledge drain. Helix holds 14 years of undocumented operational knowledge. Mitigation: contractual knowledge transfer and exit obligations, exit plan agreed before award, shadowing and reverse shadowing, and retention of key Helix staff where possible.
- Service discontinuity. A big-bang cutover of five towers on one date concentrates risk. Sequencing by tower, with the service desk and network first because they are the entry point and the most visible, allows the integration model to be proven before the harder application tower moves.
- Data and tooling. 40% CMDB coverage and three tool instances mean the integration layer cannot be complete at go-live. Sequence tooling consolidation so that incident and service level data are integrated first, and accept federated tooling with a common data model in the interim.
- People. TUPE transfers and the retained team's new roles need early communication and consultation; otherwise attrition removes the people who understand the contracts.
- Exit from Helix. Two bidders have made this a condition, so the exit plan must be agreed and funded before contract award, not left to month nine.
3. What should the business case measure beyond cost reduction, and why does that matter for SIAM?
Read the worked answer
A cost-only case will not survive first contact with the programme. SIAM adds an integration layer and process overhead, so early costs typically rise before they fall. If the case promises only savings, the programme will be judged a failure during transition and support will evaporate.
The case should measure: end-to-end service performance (restoration time for major incidents, first-time fix, service availability as experienced by the customer); risk reduction (single points of failure, contract and exit risk, compliance exposure); capability and control (quality of performance data, speed of onboarding a provider, ability to change providers without service loss); and customer and staff experience (satisfaction, escalation volume, attrition).
For SIAM specifically, the value story is that integration makes the multi-provider model governable and contestable. Northwind is moving from one contract to five, which increases commercial flexibility but multiplies coordination risk. The case should show that the integration layer is what converts that flexibility into lower total risk and better service outcomes. Benefits should be baselined in discovery and reviewed at 6 and 12 months after go-live, with a stated tolerance for a temporary cost increase.