Bygg rätt sak innan du bygger den rätt

Under ett av mina uppdrag hamnade jag i ett väldigt intressant och lärorikt sammanhang – jag reflekterade mycket över detta projekt och hur vi gjorde saker och när jag beskrev det för mina kollegor insåg jag ännu mer hur unik denna erfarenhet var.

Lo-Fi Prototyping

Ni kanske har hört talas om konceptet Lo-Fi och Hi-Fi Prototyping. Enkelt förklarat kan ”Low Fidelity” beskrivas som något grovt eller begränsad. Inom prototyping handlar det om områdena interaktivitet, innehåll eller den visuella designen.

Fördelarna med Lo-Fi prototyping är att det går snabbt och är billigt att ta fram, och man kan fokuserar på en given utmaning och skapa sig en bättre förståelse inom teamet. Nackdelen är att det kan vara svårt att förstå vad man har framför sig och vad som ska eller inte ska fungera.

MVP

Ett annat koncept som är populärt att prata om och jobba utefter är MVP (Minimal Viable Product). En MVP har ofta fokus på tekniken/produkten/tjänsten. Enkelt förklarat är man ute efter att kunna släppa en fungerande produkt så fort som möjligt för att kunna validera en hypotes, få återkoppling från riktiga användare och/eller börja tjäna pengar snabbt. Grundtanken är att produkten ska stödja och spänna över hela processen men att funktionaliteten som implementeras bara innehåller det mest nödvändiga, så att man sedan kan anpassa och jobba vidare utefter de insikter man får genom faktiskt användande.

LO-FI Release

Men vad händer om vi tar båda dessa koncept och applicerar det på den fulla omfattningen av en release/produkt och inte bara dess IT-relaterade leverabler? En fungerade produkt som används på riktigt, av riktiga användare i en given process men där samtliga byggstenar; process, organisation och teknik, är ”Lo-Fi” och ”MVP’iga”. Dvs de är grova, grunda och inte slutgiltiga.

Caset

Scenario: Lanseringen av en ny process, organisation och teknik skulle göras på en begränsad del av ett företaget – enkelt uttryckt en pilot, som tillåter att man minskar risken vid införandet och möjliggör enklare justeringar innan det rullas ut till resten av organisationen.

Förutsättningar: Processen sattes på högnivå, förmågor identifierades ur ett IT-perspektiv, organisationen bestämdes och tillsattes, dock var ansvarsfördelningen inte helt tydliggjord i samtliga delar av processen.

Utförande: Av olika anledningar behövdes en teknisk förmåga implementeras separat – och man bestämde sig för att den skulle implementeras med hjälp av en teknik som hade stora begränsningar vad gäller skalning och modernutvecklingsstöd, men var billig och ”snabb”. Man skapade en strikt prioriterad produkt backlogg, som bestämdes utefter de behov man såg att verksamheten skulle behöva över tid - det var fanns en tydlig koppling mellan given grundfunktionalitet och datum då detta behövde finnas i systemet för att möta faktiska händelser i verksamhetskalendern. Teamet stod för både nyutveckling och förvaltning på både IT- och verksamhetsidan.

Vi hade även en plan B redo ifall det skulle … vilket innebar dubbelarbete under en begränsad tid för våra användare, men det gav oss den nödvändiga trygghet som detta äventyr krävde.

Vilket tar mig till vad som krävs för att en sådan implementering:

• Våga – krävs en hel del cachones för att göra på detta sätt.

• Stöd – kontinuerligt stöd från chefer och transparens mot samtliga intressenter för att skapa förståelse och en trygghet i att vi kommer lösa detta.

• Tät och ärlig kommunikation med samtliga inblandade.

• Flexibilitet – ansvar och processer utmanades och korrigerades utefter verkligheten vilket kan vara påfrestande.

• Vara tillgänglig och alert för att på alla möjliga vis hålla användarna under armarna så att de känner sig trygga att vi tillsammans kan lösa eventuella problem.

• Det krävs förlåtande och förstående användare och intressenter som i många fall får en temporärt ökad arbetsbelastning eller får hitta på temporära lösningar för att lösa ut begränsningar i lösningen.

Självklart stod vi inför en del utmaningar. Nedan är några konkreta utmaningar kopplade till själva systemutvecklingen.

• Vi hade utmaningar med att prioritera backloggen utifrån behov som vi fann under användandet av lösningen och processen och de backlogg komponenter som var länkade till behov i verksamhetskalendern. Här var vi ofta väldigt stränga och prioriterade verksamhetskalenderns behov, men det var inte alltid lätt.

• En annan utmaning var att hitta en balans mellan fortsatt utveckling av pilot-lösningen och att vänta in den ”riktiga” lösningen.

• Vi hade också begränsningar i form av tekniska möjligheter som framförallt visar sig i användarvänlighet och effektivitet vid utveckling (hur snabb man är).

Så vad var fördelen med detta sätta att implementera?

• Billig(are)

• En katalysator för ”Emerging requirements” snarare än en djup och kalendermässigt lång analysfas (som ändå oftast visar sig ha hål när verkligheten slår till).

• Tvingade fram en väldigt tydlig prioritet på vad som behövdes göras både på verksamhet- och systemsidan.

• Man synliggör hur processerna verkligen är.

• En katalysator för ”Emerging processes, responsiblities and routines”

• En fungerande ”prototyp” som kan användas vid kravställningen av den ”riktiga” lösningen

Summering

För att ro i land ett initiativ som detta krävs NÄRVARO. Konstant NÄRVARO, i flera dimensioner och tidshorisonter. Man måste hela tiden vara med i det dagliga arbetet – både ur ett verksamhets- och IT-perspektiv för att stötta och förbättra. Samtidigt som man måste se framåt för att möjliggöra och förändra samtliga dimensioner (verktyg, organisation och processer) av ett nytt arbetssätt.

Hoppas det framgått – det är ingen räkmacka att göra på detta sätt! Men jag är helt såld – fördelarna överväger alla gånger nackdelarna.