En af de ting, som godt kan gøre mig lidt irriteret, er, at organisationer ofte får for lidt ud af deres udviklingsprojekter.
Mange projekter har kun fokus på produktet og bruger overordnet set de samme teknikker, uanset om man udvikler kaffekander, møbler eller Storebæltsbroer.
Men interne udviklingsprojekter handler ikke primært om produktet; de handler om de organisationsforandringer, som skal faciliteres gennem produktet (for der er vel ingen, der bruger penge på it-systemer bare for at købe it-systemer), og her har den klassiske produkttilgang sine begrænsninger.
Traditionelt design
Men lad os starte med at kigge på traditionelt design.
Det overordnede flow sker ved, at der defineres et problem eller et mål, hvorefter en designer, et designteam eller en leverandør indsamler informationer om problemet.
Ved hjælp af viden, erfaring og genialitet skabes der et produkt, som løser problemet (og hvis man er rigtig produktdesigner, kan det vinde en designpris).
Dette kan så ske enten som et traditionelt vandfaldsforløb eller ved hjælp af iterationer, men det basale forløb - at designteamet indsamler information og skaber produktet - ændrer sig ikke.
Selv mange UX/usability-teknikker er i bund og grund måder at trække viden ud af medarbejdere og organisationer på.
Fremgangsmåden er også brugbar i it-kontekst, hvis man designer "of the shelves"-produkter, websider og lignende, som skal sælges til mange forskellige brugere.
Men når man fremstiller skræddersyede løsninger til en organisation, er produktet ikke i samme grad det primære.
Ulempen ved denne tilgang bliver ofte, at den viden, som genereres under et sådant projekt, kun eksisterer hos designteamet og ikke bliver forankret i organisationen.
Det svarer til at hyre en traditionel organisationskonsulent til at foretage en analyse og så kun få en liste med forslag til forandringer ud af det uden forklaringer på, hvad der er observeret, og hvorfor forandringerne vil gavne organisationen. Når så præmisserne ændrer sig, skal man næsten starte forfra.
Cooperativt design
I den anden grøft har vi så cooperativt design, som er afledt af de erfaringer, der kom fra Utopia-projektet i midten af 80'erne.
Formålet med Utopia var at sætte typografer i stand til selv at forme deres fremtid, som var under kraftig forandring på grund af it, i stedet for at forandringerne blev styret af ledelsen og it-leverandører.
Man brugte derfor megen tid på at opkvalificere typografernes forståelse for it og på at afprøve en masse fremtidsscenarier, så medarbejdere og ledelse kunne blive mere ligeværdige parter i at skabe den fremtidige arbejdsplads.
Hvis man lige ser bort fra de åbenlyse politiske undertoner i Utopia, så har det bestemte udgangspunkt, at vi som it-konsulenter skal hjælpe brugerne og kunden til selv at skabe den bedst mulige fremtid gennem it, i nogle situationer klare fordele.
Forandringsledelse
Kigger vi på forandringsledelse, så findes der også forskellige tilgange, som hver især har sine fordele.
En af tendenserne de seneste mange år har været øget fokus på medarbejderdrevet forandring, hvor medarbejderne enten selv er med til at definere målet, eller i hvert fald selv finder frem til den bedste måde at opnå et mål.
Forudsætningen er dog, at der er forandringsvillighed blandt medarbejderne (hvis ikke har man under alle omstændigheder problemer), at man er villig til at tilføre kompetencer til medarbejderne, og at ledelsen har overskud nok til at acceptere andre løsninger, end dem de lige har forventet.
Til gengæld får man nemmere accept af forandringerne, fordi medarbejderne selv har haft kontrollen over processen. Oftest får man også løsninger, som bedre håndterer de reelle udfordringer.
Hvis dette skal overføres til udviklingsprojekter, bliver it-konsulenternes rolle ikke længere at levere løsninger, men at uddanne og coache medarbejderne og kunden til selv at kunne designe produktet (og selvfølgelig skal it-konsulenterne også stadig stå for den tekniske implementation).
Med det agile mindset har vi fået en ramme, som muliggør, at vi ikke længere behøver at have så snævert et produktfokus. I stedet kan vi fokusere på det, som giver mest værdi for projektet og kunden - uanset om det er så er produktet, organisationsforandringen eller noget helt tredje.
Men det kræver, at både kunder og leverandører af og til gentænker deres klassiske relationer, og at værktøjskassen er stor nok til også at se på andre faktorer end lige produktet.
