– Vi tror att det är så här att Beställare och Bestämmare är Bekymrade av olika saker beroende på vad de är de befinner sig och vad som har störst fokus hos dem. Det beror på vilka roller det rör sig om och vad de ansvarar för. Bilden ovan visar exempel på hur en kärnverksamhet har stort fokus där att den helt enkelt måste hända. Andra delar som informationsförvaltning eller projektstyrning är normalt mera etablerade och något som har fokus utifrån detta. Och självklart också styrning av förvaltning. 

Men när det kommer till utveckling och en styrning av en designprocess så är en iakttagelse att detta ofta har mindre fokus. Därför tror vi det behövs ett sätt att förstå detta närmare och se hur det går att adressera. Vi tror en designproess kan hanteras på samma sätt som styrning av andra förmågor. Begreppet som brukar användas är design management. Hur det kan ledas styras och fås operativt. Vi använder de termer som finns i branschen o är på engelska för vi tror det underlättar. 

Men detta behöver vi utforska, bygga gemensamt förståelse och sedan kunna försörja med innehåll i form av metodiker, verktyg för att skapa kunskap.

Vi har givetvis en apprachering kring detta och den är utifrån arkitektur, design ux, agilt och systemutveckling. Vi har ockdå en struktur som vi tror kan hjälpa att förstå och leverera praktiska lösningar. Vi tror också vi har ett arbetssätt som bygger på deltagande, dialog och att prova vad som fungerar praktiskt och lära oss och anpassas efter det. Givetvis behöver detta prioriteras, det kan bli mycket arbete så vi har även här en value funnel som vi också vill beskriva – hur vi transparent visar vad vi adresserar och även är inbjuder till dialog att prioriterar vad som ger mest värde.

Om ‘Utrymme’

Som vi skrivit tidigare så finns alltid någonslags utvecklingsarbete eller designprocess, den är bara mer eller mindre känd och hanterad. Med utrymme menar vi här att den är just känd, ledd och styrd och att den fungerar och att en hela tiden förbättras utifrån en lärande loop. Man brukar tala om ‘double learning loops’ alltså att man i utvecklingsarbetet lär sig att förbättra inte bara proudkten utan hur utvecklingen av produkten kan förbättras.

När vi här talar om utrymme så kan det alltså finnas utvecklingsarbete men ett kännetecken på att det kan förbättras är indikatorer som ständiga förseningar, att det som byggs inte hänger ihop eller att olika tjänster gör samma sak, eller att vissa delar i en värdekedja saknas, oförutsägbarhet kring tid, resurser och som ofta leder till överraskningar. Typiska orsaker kan vara att det finns en stark projektorganisation eller IT-avdelning som tar över och bara delvis klarar av att hantera det en designprocess måste finnas på plats att utföra, som kontinuerligt utforskande, att involvera användare och ta fram lösningar i en kadens från vision, via bheov och krav till konceptuella lösningar. Detta är typiska exempel på sådant projektledare och projektkontor eller IT-avdelningar med bara programmeringsroller inte kan utföra.
 

Om det finns utrymme

Finns det utrymme och om en designprocess finns på plats så kan denna alltid förbättras. Beroende på hur långt organisation och team har kommit beror detta på. I grunden handlar det om kontinuerligt förbättringsarbete, som vi sagt tidigare är detta också en typ av designarbete och som behöver en designprocess. Har man agila arbetssätt på plats så bör detta redan vara inbyggt via mekanismer som retrospektiv, medvetenhet om PDCA/OODA-cykeln och andra varianter. 

Om man vill få igång förbättring kan man titta på vad den agila rörelsen har inbyggt i t.ex scrum men även andra metodiker som ‘a3-improvement’ eller vad som finns att hämta inom ‘Kaizen’-rörelsen.

Om det inte finns utrymme

I det här fallet krävs mera av förändringsarbete. Det är utanför vad vi tänker skriva här för man behöver andra typer av resurser. Det som både Westrum skriver och som den agila rörelsen använder sig av är insikten att för att förändra en organisations kultur skall man börja med hur medarbetare arbetar, inte försöka förändra sätt att tänka. En bra början är att förstå hur organisationen ser ut. Utifrån detta kan man då som individ eller ledare bedöma möjligheterna till en förändring och överväga alternativen som i slutändan kan vara att det faktiskt inte finns möjlighet till förändring, iallafall inom praktiska gränser.

Resurser att börja med är boken ‘Team Topologies’ och det som skrivits av Ron Westrum kring organisationskultur, t.ex från Google här: https://cloud.google.com/architecture/devops/devops-culture-westrum-organizational-culture

DevOps-rörelsen har också resurser kring hur man får fungerande organisationer, t.ex DASA https://www.devopsagileskills.org/