”30 dagarsutmaningen” – hur ’US Citizen & Immigration service’ fick skickligare leverantörer och bättre kvalitet med hjälp av Code camps (sv)

(This article is also available in english – read here)

Vi tog tillfället att prata med Joshua Seckel från ”US Citizenship and Immigration Services” , USCIS  (jfr. Amerikanska migrationsverket). USCIS har använt sig av Agil upphandling sedan 2013, vilket betyder att de idag har ett antal genomförda projekt som upphandlats Agilt under bältet. Resultatet? Drastiskt förbättrad kvaliteten och snabbare leveranser. De har också lyckats attraherat fler och skickligare leverantörer till sina projekt. Vi undrade; vilka var nycklarna för att lyckas?.

Hej Joshua, trevligt att träffas. Berätta lite om dig själv?

Ok. Min bakgrund är datorvetenskaplig, jag har en M. Sc. i Datorvetenskap som jag sedemera kompletterat med en MBA. Den största delen av min karriär har jag varit verksam inom offentlig verksamhet i USA (jfr US State IT samt Federal IT). Under 2013 fick jag en förfrågan att börja hos USCIS (U.S. Citizenship and Immigration Services) som divisionschef med uppdraget att modernisera deras IT tjänster och plattform. Vi insåg tidigt att en nyckelfaktor bestod i hur vi valde att arbeta med vår upphandling då moderniseringen skedde ihop med externa parter. Resultatet är att vi sedan 2013 har bedrivit ett flertal experiment med inspiration från Agila kontrakt för att förbättra vår upphandling och leverans . Under samma tid var jag även drivande bakom ”DHS Flash challenge”, en upphandling där vi använde Code camps istället för traditionella upphandlingssvar för att rätt leverantör att arbeta med (bland 111 ansökande leverantörsteam). Idag arbetar jag som Chief Solution Architect hos Sevatec.

Berätta lite om den upphandlingsmodell ni använde på USCIS?

Modellen vi använde kommer från ett initiativ vi kallade ”30 dagarsutmaningen”. Målet var att kapa tiden från Request for Proposal (RFP) , till utdelande av kontrakt, till 30 dagar med hjäp av tekniker från Agil upphandling. Den drivande faktorn bakom initiativet var att vi såg att vår upphandlingsprocess tog för lång tid. När väl upphandlingarna var klar och leverantörerna stod i startgroparna – hade affärsverksamheten gått vidare till nya utmaningar. Prioriteringarna och målsättningarna hade förändrats och vi hade missat marknadsfönstret. Så vi behövde prova något bättre.

Första gången vi testade konceptet tog det 80 dagar från start till mål. En bra bit från de 30 dagar vi siktade mot, men, det var ett start steg framåt i jämförelse med hur det var innan. Vi lärde oss också tre viktiga saker om vår process:

1. Var vi hade flaskhalsar och onödig väntetid (dvs områden vi borde förbättra oss på)
2. Att vi fick bättre kvalitet med de nya metoderna.
3. En stor majoritet av leverantörerna gillade angreppssättet.

Sammantaget: ett stort steg framåt. Detta gav oss blodad tand att fortsätta använda de nya metoderna, samt förbättra dem.

Intressant att höra. Kan du gå igenom nyckelfaktorerna som låg bakom era framsteg?

Den första nyckelfaktorn är att bygga ett nära samverkan mellan Upphandling, IT och affärsfunktionen. Ett exempel på detta är att se till att rätt kunskap finns i det utvärderingsteam som väljer samverkansmodell samt leverantör. Det är viktigt att utvärderingsteamet kan ställa rätt frågor. För oss betydde det att validera att det i utvärderingsteamet alltid fanns tre kompetenser, affärsförståelse, upphandlingskunskap samt IT.

Nyckel nummer två var att se till att leverantörsteamen som var med i anbuden gjorde riktiga demonstrationer av sin förmåga, dvs att inte nöja sig med skriftliga anbud. Vi åstadkom detta genom sk. ”Code camps”, där varje leverantörsteam fick bygga en prototyp under fyra timmar och demonstrera resultatet för oss. Det är genom Code camps, du som kund kan se den reella förmågan som leverantören faktiskt besitter.

Den tredje och sista nyckelfaktorn var att begränsa antalet deltagande leverantörer som kunde konkurrera om kontraktet mha Code camps.. Inom ramen för ”30 dagarsutmaningen”, begränsade vi antalet konkurrerande leverantörer till 5:st. Begränsningen var nödvändig för att lyckas inom den snäva tidsram som ”30 dagasutmaingen” medgav. Vid andra situationer kan det vara rimligt att ha fler leverantörer med, för att öka urvalet. Ett ytterlighetsexempel är DHS Flash challenge, där vi utvärderade och validerade 111 leverantörsteam  mha Code camps.

Vilka förmågor hos leverantörerna utvärderade ni?

1. Kan de bygga något som går att köra som användare?
Oavsett vilken process och vilka tekniker leverantören valt, är det en central förmåga att  kunna demonstrera något körbart i slutet av sessionen. Vi hade exempel leverantörsteam som inte tänkte på detta, och resultatet blev oftast dåligt genomförda och tunna demonstrationer.

2. Kvalitet och yrkeskunnande (craftsmanship)
En stor fördel med Code camps är att du med egna ögon kan se och bedöma vilket yrkeskunnande samt vilka ”best practices” leverantören använder för att leverera kvalitet under tidspress. Detta är viktigt då just yrkeskunnandet hos leverantören är en avgörande betydelse för slutresultatet i det kommande projektet. Fördelen som kund är att du får se skillnaden mellan leverantörsteam som ”har läst om” best practices vs.  de som använder dem instinktivt.

3. Samverkan med affär
Detta visade sig vara en vattendelare. När vi körde våra Code camps såg vi till att vi hade en produktägare (PO) i rummet som affärsrepresentant. Den avgörande frågan vi studerade var: hur valde leverantörsteamen att nyttja detta? Hur skapade de förståelse kring de krav ställda av produktägaren? När sessionen började exponerades leverantörsteamen för en mängd  krav (sk user stories, med Agil terminologi). Dessa motsvarade alltid långt mer än vad ett team kunde klara av under en given tidsram. Kraven var från början inte prioriterade, men produktägaren hade en prioritering förberedd, ifall någon skulle fråga efter den.

Leverantörsteam som inte gjorde bra ifrån sig om detta område kom antingen in med en egen, förutbestämd bild av vad som behövde byggas och sökte svar från produktägaren som bekräftade denna. Alternativt slösade de tid på att tidsuppskatta och förstå alla krav och detaljerna innan de insåg att det var för mycket för en 4h session.

Leverantörsteam som gjorde bra ifrån sig frågade produktägaren tidigt vilka underliggande affärsbehov som låg bakom kraven, för att förstå vad som var viktigt. Alternativt så engagerade de produktägaren på ett tidigt stadium för att åstadkomma en tydlig prioritering. Vi noterade också att högpresterande team la ofta ned tid med att skapa pappersprototyper för användargränssnitt och samt begära återkoppling på dem, innan de implementerades.

Även om tidsramen 4h var för kort för att kunna observera väsentliga skillnader i användarvänlighet under demonstrationerna, så kunde vi se vilka tekniker leverantörsteamen använde för att åstadkomma användarvänlighet. Dessa gav en tydligt indikation om vilka leverantörsteam som hade förmåga att producera användarvänliga lösningar i det verkliga projektet.

Hur såg ni till att leverantörerna utvärderades konsistent, även om ett Code camp genomfördes flera gånger och med olika leverantörer?

En av åtgärderna var att se till att det alltid var samma utvärderingsteam som utvärderade våra Codecamps. När vi körde ”DHS Flash challenge” som var lite större hade vi två utvärderingsteam. Vi såg också till att förmågorna vi ville utvärdera var beskrivna på förhand, samt att alla utvärderingsteam hade relevanta kunskap för att kunna genomföra en utvärdering.

Vad var förberett innan ett Code camp? Vad visste leverantörerna om projektet innan de valde att gå med i upphandlingen?

I ”30 dagarssutmaningen”, så fick leverantörerna följande förhandsinformation:

• Effektmålet  (affärsmålet) . Detta kommunicerades alltid i förväg.
• Hur många team som behövdes och under hur lång tid. Första gången vi körde ”30 dagarsutmaningen”  behövde vi 1 -2 team, och detta var vad leverantörerna committade till, om de fick kontraktet.
• Teknikplattformen (teknikstacken). Inom USCIS gör vi ganska lite nyutveckling,. Ny funktionalitet utvecklas ovanpå vår existerande plattform. Det bör noteras att vi har gjort stora ansträngningar för att se till att steget mellan utveckling och produktionssättning, är kort på plattformen. Det rör sig om timmar. Så inom ramen för, ”30 dagarsutmaningen”, så var teknikstacken vald på förhand för leverantörerna.

Det finns dock andra situationer där du som kund med fördel kan lämna valet av teknikplattform öppen. Det ökar innovationshöjden och gör att leverantören kan bygga mjukvaran i en känd och för denne heterogen miljö. I bägge fallen kan Code camps användas för att utvärdera om leverantörerna har förmågan att skapa mjukvara med kvalitet.

Vilken återkoppling fick ni från leverantörerna i och med den nya upphandlingsprocessen?

Majoriteten av leverantörsåterkopplingen vi fick var positiv. De gillade att få chansen att visa vad de går för .De berättade också att det var billigare och enklare,att delta som leverantör i upphandlingen, när de jämförde med att författa och skicka in ett skriftliga underlag som svar..

Återkopplingen som vi fick efter DHS Flashupphandlingen, (som tyvärr fick ställas in pga ett administrativt fel) så skickade leverantörerna in ett öppet brev till vår upphandlingschef. Budskapet var :”vi gillar att ni genomför upphandlingar på det här sättet – fortsätt med det”

Om man sammanfattar så gillade en kvalificerade majoritet av leverantörerna vårt Agila tillvägagångssätt. Det fanns dock ett fåtal leverantörer som inte tyckte om det. En gemensam faktor var att dessa leverantörer ofta var duktiga på att författa upphandlingssvar (men inte lika skickliga i att demonstrera att de kunde leverera kvalitet, i linje med sina svar).

Du har nu ett antal projekt i bagaget som genomförts efter att ha upphandlats med Agila upphandling. Vad skulle du säga är det största fördelarna från ett kundperspektiv?

Fyra saker:

1. Att med egna ögon få se det som produceras.  Som vi säger: ”Show me, don’t tell me.”
2. Att vi kunde identifiera steg i vår egen upphandlingsprocess som vi kunde förbättra. Att kunna se var vi hade flaskhalsar och väntetid. Vår upphandlingsprocess blev pss transparent och vi fick en helhetssyn som gav oss ammunition att steg för steg bryta ned silos och överlämningar mellan avdelningar. Detta gjorde att vi steg för steg kom närmare vårt 30 dagarsmål.
3. Låg tröskel för deltagande från leverantörerna. Vi fick fler deltagare och mer engagerade leverantörer. I examplet DHS Flash gissade vi på att 50 leverantörsteam skulle anmäla sig som deltagare i upphandlingen och i våra Code camps,. Det slutade med att vi fick in anmälningar från 111 leverantörsteam(!).
4. Att vi lyckades få kunniga och engagerade leverantörsteam, som aktiva parter, i våra projekt. Vi kan se att detta lett till både snabbare leveranser och högre kvalitet..

Hur går det se/observera detta?

Låt mig nämna två exempel:

• Exempel #1: Förut fick vi träna våra leverantörsteam, samt våra leverantörer efter gjord upphandling,  i att jobba Agilt. Detta behov har i stort eliminerats, vi behöver inte göra det längre.
• Exempel #2: Tiden mellan produktionssättningar och releaser i våra projekt har blivit väsentligt kortare. Några exempel:  Vår ’Data analytics plattform’ produktionssätter i snitt 50 ggr om året. Dvs ungefär en gång i veckan. Vårt ELIS program, som involverar 15-20 utvecklingsteam, produktionssätter i snitt 4 ggr i veckan.

Ledtiden från prioriterad ide till att den finns körbar i produktion är också kortare.  Majoriteten av våra team an ta en iden till produktion inom en månad. Alla av våra team kan göra det inom 3 månader. Detta bör jämföras med situationen vi hade innan (och normen inom statlig verksamhet i USA), där leverans oftast sker en gång om året.

Vad skulle du rekommendera andra som vill använda Agil upphandling?

Prova på! Välj ut ett litet projekt och prova själv. Gör det idag! På så sätt får lär du dig själv hur det fungerar i din miljö och du lär dig se förbättringsmöjligheterna i din existerande upphandlingsprocess. Det andra jag vill trycka på  är att se till att du har rätt kompetens i ditt utvärderingsteam. Människor som förstår IT och kan bedöma yrkesskickligheten hos leverantörerna. Det tredje och sista rådet: engagera dina affärsenheter. Se till att du har en produktägare som medlem i ditt utvärderingsteam. Skapa en god samverkan mellan Affär, Upphandling och IT och gör det tidigt. Att ha ett dagligt ståuppmöte mellan Upphandlng, IT och Affär med fokus på en kommande upphandling ett exempel på en god vana.

Tack Joshua för att du tog dig tid. Vi ser fram emot att lära oss från dina framtida experiment!