---
id: SI_003
model: deepseek/deepseek-chat-v3
seeds:
  04_risiko: sårbarhet
  03_relasjon: tillit
  05_handling: implementer
  01_perspektiv: strategisk
  02_tidhorisont: historisk
---

# Instans SI_003  
**Seeds:** strategisk | historisk | tillit | sårbarhet | implementer  

### Strategisk sårbarhet i systemet  
Den historiske tilliten til at "byggherren alltid har rett" er en strategisk sårbarhet. De 8 prosjektene viser at feilen ikke ligger tilfeldig fordelt — den er implementert i mønstrene. Når 3/8 prosjekter har endringsmeldinger på 15-25% av kontraktsummen, er det ikke entreprenøren som svikter, men kravspesifikasjonen som er for vag eller rigid.  

### Tall som taler  
- 70% NS 8407 (fastpris) burde gi mindre variasjon, men likevel oppstår store avvik.  
- 2/8 prosjekter i rettslig konflikt tyder på at kontraktene ikke tar høyde for kompleksitet.  
- 0% korrelasjon mellom entreprenørtype og suksess/fiasko — problemet er systemisk.  

### Hva gjør du?  
1. **Innled sårbarhetserkjennelse:** Hold et seminar hvor dere analyserer 3–5 representative kontrakter (velg både suksesser og fiaskoer). Fokuser på hvordan *risikofordeling* og *kravformulering* skapte konflikt. Bruk eksterne moderatorer for å unngå forsvarsposisjon.  
2. **Implementer "strategisk tillit-test":** Revider kontraktmalene med en enkel regel: "Hvis dette kravet ble tolket radikalt annerledes av entreprenør, hvordan ville det påvirke prosjektet?" Legg til tolkningsnotater i kravspesifikasjonen.  
3. **Endre mål fra "fastpris" til "fast forståelse":** Pilotér samspillmodell på 2 nye prosjekter med fokus på felles risikokartlegging i tidlig fase. Mål endringsmengde etter 6 måneder.  

### Neste steg:  
1. Be KI-rådgiveren trekke ut alle formuleringer i kontrakter der ord som "rimelig" eller "etter god sed" brukes — disse er historiske konfliktpunkter.  
2. Inviter de mest kritiske entreprenørene til en workshop om hvordan de tolker uklare krav.  
3. Lag en "lessons learned"-database med anonymiserte endringsmeldinger — søkbar av alle prosjektledere.  

Det handler ikke om å skylde på noen, men om å erkjenne at systemet dere har tillit til, har sårbarheter som må implementeres bort.