Nya Karolinska har blivit lite av en följetång i media. Projektet lider av sena överraskningar, vården hinner inte ens inledas innan lokalerna måste byggas och slutnotan skenar (kostnaden är uppe i 2 gånger världens högsta byggnad, Burj Khalifa). Men den osynlig slutnotan, extraanställning/utbrändhet hos personal, en vård som inte är anpassad till behovet – mindre antalet vårdplatser jämfört med Gamla Karolinska i en växande storstadsregion – tas dock inte upp av projektet, utan av personal och patienter som måste hitta en annan väg.
Nya Karolinska är ett exempel på vad som går fel när du inte bygger för att lösa ett behov, utan bygger för att skapa en lösning. Vad som skall ingå styrs i för hög grad utifrån önskemål om att hänga med i den senaste utvecklingen, snarare än att lösa ett problem. Lösningarna blir mer avancerade än vad de hade behövt vara. Klassiska symptom på ett prestigeprojekt.
Detta är illa, men hade gått och korrigera om projektet hade valt rätt process för sin byggnation. Istället för att realisera byggnationen iterativt (steg för steg, man bygger och testar av en del i taget), byggdes hela sjukhuset klart innan man öppnade avdelningarna och fann att vård inte kunde bedrivas där.
Projekt som Nya Karolinska göder det felaktiga antagandet att ”försening får man räkna med i ett så här komplext projekt”.
Det är fel.
Felet ligger i okunskapen om hur projektet skall bedrivas. Rätt sätt att bedriva dem är att anta att det kommer att bli överraskningar (att vi lär oss hur vi bygger det på ett bra sätt och i hur bra lösning är anpassad för det behov som skall uppfyllas) . Om vi bygger projektplanen efter detta antagande inser vi att vi kommer att behöva bygga prototyper av vår lösning, simulera hur det är att bedriva vård där, innan vi bygger den slutgiltiga lösningen.
Fördelen vi uppnår är att risken blir mindre. Om allt går som det skall så kommer vi att hålla tidsplanen. Check. Om vi lär oss saker under vägen (det sannolika utfallet), så har vi skapat oss själva möjligheten att agera på det. Utfallet blir att vi kan hålla tidsplanen och har gett oss möjligheten att slipa på vår lösning under gång så att det är rätt anpassat till behovet. De felaktiga antagandet som fäller stora projekt är att de antar att lösningen kommer att funka. Sanningen uppstår sent (typsikt 1 månad innan tänkt igångsättning) och det enda rimliga handlingsalternativet blir att försena projektet.
Ett exempel. Barnintensivsjukvården på Gamla Karolinska har idag 36 intensivsjuksköterskor, jämfört med de 96 som skulle behövas för att bemanna 15 platser på Nya. I valet mellan att skicka hem patienter (eller omlokalisera) eller bygga om och försena projektet, valde man det senare. Systemfelet är att detta upptäcks så sent som 1 månad innan faktisk flytt.
Hur kan man göra istället? Vi kan lära oss av Karlstad sjukhus Nya Operationscentrum.
Projektet inleddes med ett tydlig målbild. De ville hitta en lösning som möjliggjorde att vården kunde centrerad kring patienterna. Istället för att patienterna transporteras runt mellan avdelningar kommer personal och utrustning till patienterna.
Operationsscentrumet byggdes i iterationer genom prototyping. Resultatet kunde löpande stämmas av mot målbilden. Tex byggdes skalenliga prototyper byggdes för alla rum. Dessa användes för att testa hur utrustning, handgrepp, rörelsemönster och rördragning fungerade innan man byggde det slutgiltiga huset. Viktiga lärdomar drogs som ledde till att projektet kunde innovera fram nya byggnationsmetoder. Man hittade också en lösning som innebar att färre antal operationssalar än planerat behövdes för att lösa vårdbehovet. Resultatet blev sjukhus centrerat kring patienten och flexibla operationssalar där de flesta ingrepp kan utföras i alla operationssalar. Bättre för personalen, och bättre för patienterna.
Sena överraskningar kommer att finnas så länga vi inte förväntar oss att de uppstår.
Förvänta dig överraskningar. Bygg lösningen i iterationer. Testa av hur väl anpassade de är mot behovet. Använd Agila kontrakt för att ställa krav på involverade parter att använda detta angrepsssätt i stora och komplexa projekt.
Offentlig sektor skulle må bra av det.
Referenser och länkar: