Förändringstakten som konstruktionskrav

Ni kan inte veta vilka delar av en lösning som kommer att bytas ut, eller när. Det är ingenting ni ska försöka gissa.

Det hållbara sättet är att behandla förändring som ett konstruktionsvillkor. Lösningen ska tåla att delar av den byts, och det ni bygger runt lösningen ska tåla att lösningen byts.

Det är inget påstående om hur snabbt något går. Det är ett antagande om vad ni inte vet, och till skillnad från en prognos behöver det aldrig revideras.

Det som gör en organisation illa rustad är sällan att den valde fel del. Det är att den band ihop sina val så att ingen del kan bytas ensam.

Två sätt att binda ihop är lätta att missa. Det första är att en inställning kalibreras mot ett utfall ingen kan mäta upp igen: en tröskel som satts genom att någon provade sig fram, utan nedskriven mätmetod, går inte att återställa när den underliggande delen byts.

Det andra är att era åtaganden knyts till en namngiven beståndsdel i stället för till en funktion, så att ett byte inuti lösningen tyst upphäver det ni avtalat.

Så här går det fel

Tröskeln för när systemet ska avstå från att svara provas fram under införandet, tills utfallet känns rätt. Ingen skriver ned hur det mättes.

Leverantören byter sedan en del inuti lösningen och meddelar det i ett driftmeddelande. Beteendet ändras. Det finns inget värde att jämföra med, och tröskeln går inte att sätta tillbaka eftersom mätmetoden aldrig skrevs ned.

Det här måste någon bestämma

Vad som ska överleva lösningen. Er fallsamling, er beskrivning av vad ett rätt svar är, era mätdata och er behörighetsmodell hör dit. De representerar arbete som är dyrare än lösningen.

Att varje inställning som styr utfallet har en nedskriven mätmetod ni kan köra själva. Det är det enda som gör den återställbar.

Och var ni medvetet accepterar ett beroende, för det går inte att undvika överallt. Skriv samtidigt ned vad det skulle kosta att bryta.