SLM arrives after the service is built

The current position - one activity, too late. SLM is engaged only in design and transition, at the point of sign-off. That makes it a documentation function and guarantees the SLA describes whatever has already been built rather than what the citizen needs.

Where SLM should contribute:

• Engage. Early and continuously. Run the service level requirements workshops with the permit policy owners, the caseworkers and, where possible, citizen representatives. Establish what statutory compliance actually demands - the statutory obligation is normally on issuing a decision within a period, not on an IT component being available - and surface constraints and demand patterns.
• Plan. Own the SLM policy and the service level framework: how requirements become targets, who approves them, how services enter the service portfolio, what the review cycle is, and how targets are retired. Contribute the agreed targets to the product team's roadmap and budget case.
• Design and Transition. Define acceptance criteria based on service levels, agree the measurement specification and instrumentation before build, and confirm warranty is demonstrable - a service cannot be accepted on the basis of a document signed on the last day.
• Obtain/Build. Advise on what must be built to measure the service: telemetry on the citizen journey, not just on server uptime.
• Deliver and Support. Monitor against targets, manage exceptions and breaches, produce reports that support decisions, and run the service reviews.
• Improve. Feed trends, near misses and unmet requirements into the continual improvement register and the product backlog.

Practical change. Give SLM a standing seat in each value stream's discovery phase, make an SLR outcome a gate before design starts, and make the service review a product-team ritual rather than an operations ritual.

Organisations and people. The permit product team has no operations representation and no relationship with SLM, so there is no channel through which requirements could travel. Legal is drafting commitments it will not have to meet. SLM's four people are positioned inside IT Operations, which frames them as an approval gate rather than a partner; nothing in their role description or incentives rewards early engagement. Roles and responsibilities for service level ownership across the four value streams are undefined.

Information and technology. There is no measurement capability described for the citizen permit journey - no instrumentation for the citizen-facing transaction, no agreed data model for incidents, and no reporting pipeline that could produce the 99.99% claim. Data on demand volumes, statutory deadlines and caseworker behaviour is held by the business and has not been shared. Without this, any target in the draft SLA is unfalsifiable.

Partners and suppliers. A citizen permit service will almost certainly depend on an identity provider, an SMS or email notification gateway, and possibly a payment processor for fees. None of these appear in the draft. There are no underpinning contracts, and no analysis of whether a supplier's own commitment is compatible with 99.99% end to end.

Value streams and processes. The value stream has no SLM activity in discovery or design; the only touchpoint is a sign-off step at the end. There is no SLR process, no service review process, no breach management process and no target-setting method. The continual improvement register - the mechanism that would capture "this happened again" - is 14 months stale, so the organisation has no way to learn from the previous service that went live this way.

Implication. Fixing the SLA wording alone would change nothing. The failure is structural across all four dimensions, and the cheapest intervention is organisational: put SLM into discovery and make the SLR a gate.

The draft fails several guiding principles at once.

Focus on value. The statutory obligation is almost certainly about the time to issue a permit decision, not about a component being available. A two-hour resolution target for every incident may be irrelevant to that outcome while driving disproportionate cost. The first move is to test the target against the citizen and statutory outcome.

Start where you are. There is no baseline. The department does not currently know its permit decision times, incident volumes or failure modes, so 99.99% is a guess. Measure for a period before committing.

Progress iteratively with feedback. Replace a single monolithic commitment with a small set of targets introduced in stages: two or three indicators in the first quarter, reviewed and extended once the data is trusted.

Collaborate and promote visibility. Bring Legal, the permit policy owners, caseworkers and SLM into the same conversation so that the target is jointly owned rather than imposed.

Keep it simple and practical. Three or four measures with clear definitions beat twenty. A single two-hour resolution target applied to all incidents ignores priority, impact and the difference between a total outage and a cosmetic defect.

Optimise and automate. Design measurement into the service so reporting is a by-product of operation rather than a monthly manual exercise.

Applying the continual improvement model:

1. What is the vision? Citizens receive permit decisions within the statutory period, with a service they can use without assistance.
2. Where are we now? No baseline; take one quarter of data on decision times, failures and demand.
3. Where do we want to be? Targets derived from the statutory deadline and from citizen tolerance, not from Legal's ambition.
4. How do we get there? Instrument the journey, agree requirements with the product team, write compatible underpinning contracts.
5. Take action. Pilot the measures in one permit type before scaling.
6. Did we get there? Review at the service review against the baseline, and feed the result into the improvement register - which itself needs reviving as part of this work.