Oplanerbara projekt?

Igår skrev jag att digitaliseringen kräver att vi slutar upp med att arbeta i projekt när det gäller vår digitala närvaro. Det här är en tanke som är lite ny för en del så jag behöver nog förklara lite djupare.

När man talar om "projekt" kan man använda ordet lite slarvigt om allt möjlig som görs i en verksamhet. Man har till och med talat om agila metoder som "projektmetoder". Men man kan också vara mer precis, eftersom verksamheter ofta har regelverk som definierar vad ett projekt är och därmed styr hur man alls kan arbeta inom organisationen.

Så gott som samtliga projektmetoder som är implementerade i verksamheter idag, (PEJL, PROPS, PRINCE2, PPS med flera) bygger på att du kan arbeta mot ett på förhand fastslaget mål, och att vägen dit kan planeras i detalj. Själva ordet "projekt" kommer från begreppet "förarbete". Projektstyrning handlar om hur man styr utefter den på förhand upprättade planen: korrigerar avvikelser och följer upp på att alla utför precis de aktiviteter som man långt tidigare bestämt ska utföras.

Att utveckla tjänster, och särskilt komplexa tjänster som IT, är en verksamhet med två egenheter. För det första ger små avvikelser i förutsättningarna stora förändringar i utfallet. En liten insikt om att systemet behöver hantera ytterligare en liten sak kan leda till att hela informationsmodellen behöver tänkas om. För det andra så upptäcker vi nya förutsättningar hela tiden, på ett sätt som inte är förutsägbart.

På senare tid har ägarna bakom olika projektmetoder försökt justera dem för att inkorporera den här nya flugan agila metoder. Ofta har man sagt att det går alldeles utmärkt att bedriva "utförandefasen" på ett "agilt sätt" (folk arbetar i team och flyttar lappar på en tavla varje morgon). Men så länge som projektet styrs utifrån den på förhand upprättade planen (resultatet av "förstudiefasen") är modellen inte kompatibel med de agila metodernas hjärtpunkt: ständig omplanering i takt med att man får nya insikter om hur behov ska mötas. Att folk träffas varje morgon och flyttar lappar på en tavla har inget med saken att göra.

Projektstyrning kan hantera små förändringar. Man gör mindre justeringar i planen och i resursallokeringar och hoppas på så sätt få tillbaks projektet "på banan". Vad man däremot inte kan hantera är om banan visar sig leda helt fel. Projektmodellerna föreskriver faktiskt att projektet ska nödstoppas när de grundläggande antagandena inte längre gäller. Problemet är att detta innebär en prestigeförlust, och att folk helt felaktigt tar hänsyn till de pengar man redan plöjt ner i projektet.

Alla inser dessutom att själva behovet inte försvinner bara för att projektet dör. Och om projekt är den enda arbetsform som verksamheten tillåter när det gäller att möta behov genom tjänsteutveckling blir man så illa tvungen att fortsätta och ta hand om de nya insikterna på ett improviserat sätt, inte sällan till mycket höga kostnader.

Agila metoder är inga projektstyrningsmetoder. De är alternativ till projektstyrningsmetoder. Projekt kan hantera komplicerade verksamheter, men inte komplexa. Agila metoder är tekniker för att på ett välstrukturerat sätt hantera komplexitet, att hantera budgetar och planer i ljuset av varians och oförutsägbarhet, och kunna nå både långsiktiga och kortsiktiga mål om dessa är möjliga att nå.

För en chef i en verksamhet som står inför digitaliseringens utmaningar krävs det att man tar tag i problemet med ekonomisk styrning kopplad till projekt, och byter ut den gamla styrningen mot de ekonomiska styrverktygen som de agila metoderna erbjuder. Det kräver att man gör slut med en del av sina tidigare beteenden och mätpunkter, för annars kommer de gamla projektmetoderna att fortsätta vara grus i maskineriet.

Det finns även andra problem med tjänsteutveckling i projektform, men den ekonomiska styrningen baserad på ohållbar planering är det mest grundläggande hindret. Därför tar jag upp det först.

Samtiden och framtiden

Ny regering där IT-frågorna delats upp på det som rör infrastrukturen och det som rör e-samhället (bra), folk inom fler och fler områden som får upp ögonen för smidigare arbetssätt (inte minst i ljuset av sjuktalen och att arbetsgivarens ansvar för den psykiska hälsan har förtydligats), fler som börjar förstå vad digitalisering faktiskt innebär, och Almedalen med tonvikt på framtidsfrågor inträffar om en månad.

Att IT i framtiden skulle sluta ses som en separat del för sig har vi vetat länge. Nu är den framtiden här. Att det händer samtidigt som de smidiga arbetsmetoderna börjar vinna terräng utanför IT-avdelningarna är nog ingen tillfällighet. Vi står i början av en transformation på stor skala av stora delar av samhällslivet, och vi som genom åren sett den transformationen äga rum i det lilla på flera ställen har lite tankar att bidra med tänker jag.

Här följer några tanketrådar:

Om myndigheter tänker sig vara närvarande i medborgarnas liv primärt över digitala kanaler så krävs det att de inrättar sig för att faktiskt kunna sköta digitala kanaler. Muren mellan "verksamhet" och "IT" måste rivas. Det finns nämligen enbart verksamhet. Det finns inte heller någon skillnad mellan att komma på hur tjänsten ska vara och koda den. Kod är bara ett sätt att beskriva insikter på, och insikter måste tas fram löpande.

Projekt är en arbetsform som passar för tillfälligt arbete när mål, tidplaner och budgetar ligger fast. Att arbeta med sin digitala närvaro är istället ett ständigt pågående arbete emot ett mål som ständigt flyttar på sig. Att arbeta med digital närvaro är med andra ord inget för projektarbeten.

Man kan tänka så här (tack Carl för dialogen): Tänk inte "projekt", tänk produkt. En produkt utvecklas konstant över sin livscykel. Eller ett steg till: tänk inte "produkt", tänk tjänst. En tjänst är ständigt närvarande i brukarens liv och kräver att man ständigt sköter om den. Eller ytterligare ett steg: tänk inte "tjänst", tänk på att alltid möta mänskliga behov.

För att lyckas med e-förvaltning behöver en myndighet alltså ständigt arbeta med att pejla av medborgarnas behov, ständigt hitta sätt att förbättra tjänsten, och genomföra och driftsätta förändringarna löpande. Inte klumpvis.

Som tur är finns metoder i den smidiga verktygslådan för att göra detta: obyråkratiska förvaltningsramverk, kravfångningstekniker som utgår från mänskliga behov, ständig omprioritering, vidareutveckling och driftsättning. Den agilitet i organisationen som krävs uppnår man med självstyrande tvärfunktionella team som samarbetar tätt.

Men det kommer inte att lyckas om man inte inkluderar hela värdekedjan. Det är det jag menar med att riva murarna mellan "verksamhet" och "IT", och för den delen även mellan systemutveckling och drift av IT-baserade tjänster.

Idag hindras vi av tre saker. Dels okunskap förstås om hur man kan samarbeta tätt över rivna murar. Det hindret är vi många som i dagsläget är igång och river, inte minst inne på myndigheter. Men även konkreta strukturer ligger i vägen. Beställare/utföraremodeller kan vara institutionaliserade så att man inte ens kan ta ett gemensamt ansvar för tjänsterna. Det kan finnas regler om att IT-utveckling alltid måste bedrivas i projektform. Att man inte får genomföra plattformsförändringar om man inte samtidigt implementerar de funktioner som plattformsförändringen ska ge, vilket leder till stora projekt som då alltid misslyckas eftersom de är för stora. Att man följs upp på hur mycket man belägger sina resurser vilket gör flödet långsamt. Kostnadsfokus istället för att se till totalekonomin. Årsbudgetar som bygger på årsplanering som omöjliggör nya insikter.

Och det finns dessutom en omänsklig ledarskaps- och arbetsplatskultur på många myndigheter. Agilitet kräver transparens. Men kulturen är inte sällan straffande vilket alltid blockerar transparensen. Den som lyfter ett problem blir nedtryckt. Jag har sett hur höga chefer gått flera våningar ner till enskilda systemutvecklare och skällt ut dem för att de misslyckas när de lyft insikter om strukturella problem. Probleminsikt får nämligen chefer i de högre skikten att framstå som sämre i sina likars ögon, för i det högre skikten gäller det att framstå som bäst i klassen oavsett hur verkligheten ser ut.

Det jag är rädd för är att de ansvariga för e-samhället inte är beredda på att de ska behöva hantera den här typen av frågor. Att myndigheterna får direktiv om att röra sig i en viss riktning men inte mandat att undanröja de hinder som ligger i vägen. En del av de här strukturella hindren kan man spåra ända till [ÄNDRING: här beskyllde jag tidigare Statskontoret, det var fel] myndigheternas finaniseringsdirektiv för IT-projekt och hur Riksrevisionens följer upp, det vill säga sådant som inte ens en generaldirektör får besluta om. E-samhället kräver agilitet, och på den här nivån kräver agilitet alltså att självaste regeringen agerar.

Lean och agilitet är ledarskapsfilosofier baserat på systemsyn. I den smidiga verktygslådan finns gott om verktyg för att skapa en mänsklig ledarskaps- och arbetsplatskultur. De finns, de fungerar, och vi vet hur man inför dem. Det enda som krävs är ett beslut att göra det.

I den smidiga verktygslådan finns även ekonomiska ramverk som passar kontinuerlig behovsdriven tjänsteutveckling. Ramverk som ersätter stora budgetar med årsvis uppföljning. Ramverk som ger bättre kontroll över investeringar och effekthemtagning än vad dagens ramverk ger. Även här är vi bara ett beslut bort från att börja använda dem. Vi behöver inte uppfinna något helt nytt, metoderna är redan framtagna (även om kontinuerlig anpassning förstås krävs).

Det jag hoppas på är att berörda parter så snart som möjligt förstår vad som krävs för att förverkliga de drömmar de har om e-samhället och digitala myndigheter. Förstår, och även tar mod till sig och börjar agera därefter.