Hvordan gjør du mottaksprosjektene smidigere?
Smidig metodikk er et godt alternativ i utviklingsprosjekter — det reduserer risikoene og gir et produkt som er bedre tilpasset kundens behov.
Men hva bør gjøres på mottakssiden hvor man tar imot og innfører produktene? Her bruker de fleste fremdeles vannfalls-metodikk, spesielt der man innfører standardprodukter.
Vi gir deg her gode tips og anbefalinger til hvordan du kan få ditt mottaksprosjekt mer smidig!
Våre hovedanbefalinger er:
1. Del opp leveranseplanen i iterasjoner / del-leveranser. Iterasjonene skal testes helt ferdig og de bør utløse delbetaling.
2. Finn ut hvordan du får satt systemene i drift så fort som mulig. Da kommer brukerne i gang og bedriften kan starte å realisere gevinstene før prosjektet er avsluttet.
3. Ha demokontoer for å teste ut systemene.
4. Fokuser på behovene fremfor detaljerte krav.
For å få til dette må du legge litt mer innsats tidlig i prosjektet — men det vil det være verdt.
Hva er et mottaksprosjekt?
Et mottaksprosjekt er et prosjekt som skal ta imot en eller flere programvareenheter, produkter, systemer eller tjenester. For enkelhets skyld brukes begrepet systemer videre.
Disse systemene skal defineres opp, kjøpes inn, testes, tas i bruk av organisasjonen og skal gi en definert gevinst. Systemene vil som regel endre arbeidsprosessene i organisasjonen.
Vi i Systek anser det som urealistisk at systemene kan brukes helt standard. De må minimum konfigureres i henhold til kundens behov, i tillegg er det som regel spesialtilpasninger og integrasjoner mot eksisterende systemer i organisasjonen. I tillegg må de interne systemene tilpasses.
Mange systemer er også svært funksjonsrike, og kun en del av denne funksjonaliteten blir brukt i starten. Etterhvert vil man bruke flere moduler og funksjoner — noe som er viktig å ta hensyn til tidlig i prosjektet.
Hva er problemene med mange av dagens mottaksprosjekter?
Her er noen av våre erfaringer:
Mottaksprosjekter er som regel basert på at de leverte systemene er hyllevare, dvs. at det som leveres er stabilt ut-av-boksen og virker stort sett 100% fra første dag. Men dette er sjelden tilfelle. For å være konkurransedyktige så gir leverandøren deg ofte siste versjon rett fra utviklingsavdelingen. Og da får du med mangler, ustabiliteter og funksjonalitet som ikke ligner på det du ble lovet. I tillegg kommer tilpasninger og integrasjoner som i hovedsak er nyutviklet.
I et typisk mottaksprosjekt vil det være kun noen få personer som setter seg inn i de leverte systemene. Når systemene er store og funksjonsrike, må disse personene sette seg inn i svært mye — og det går bra hvis produktet er helt ferdig. Men hvis produktet inneholder feil som må rettes eller funksjonalitet som er umoden, må disse personene bruke mye tid både på å forstå funksjonaliteten samt å teste. Da går det enten veldig mye tid, eller kvaliteten går ned fordi ikke alt blir gått gjennom og testet.
Ressurser blir også reservert basert på at produktet virker fra første dag. Når det er feil i produktet og forsinkelsene oppstår — er opprinnelig personell allerede borte. Man tar da inn nye personer både hos leverandør og hos kunde, som må sette seg inn i både prosjekt og produkt. Mye tid og krefter går tapt.
Kontraktsmodeller og tilhørende leveransemodeller antyder også at produktene skal leveres fiks ferdig. Følgende er tatt fra Statens avtalemal SSA-K: “ Avtalen er også egnet for kjøp av tilpasning av programvare dersom du på forhånd kan spesifisere nøyaktig hvordan IT-utstyret og/eller programvaren skal tilpasses.”. Noe som ikke skjer i den virkelige verden. For å sette det på spissen sier SSA-K selv at den bare er egnet til å kjøpe inn skjermer og prosjektorer.
Hvordan passer smidighet i mottaksprosjekter?
Etter å ha jobbet med utviklings-, leveranse- og mottaksprosjekter i mange år mener vi i Systek at smidighet passer veldig bra til mottaksprosjekter.
Et godt utgangspunkt er å se på de opprinnelige prinsippene for smidighet:
http://agilemanifesto.org/iso/no/principles.html
Disse prinsippene passer utmerket til mottaksprosjekter selv om de egentlig er laget for utviklingsteam:
- “Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som gir verdi.
- Levér fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre.
- Fungerende programvare er det primære målet på fremdrift”.
Selv om du får stort sett hele systemet fra leverandøren på en gang, så bør kontrakt og leveranseplan definere leveranse og testing av del-leveranser. Dvs. at leverandøren leverer, og kunden tar imot funksjonalitet, tilpasninger og integrasjoner i del-leveranser eller pakker.
- “Ønsk endringer i krav velkommen, selv sent i utviklingen. Smidige prosesser bruker endringer til å skape konkurransefortrinn for kunden. “
I et mottaksprosjekt er kravene mer stabile enn i et utviklingsprosjekt da mye av standardfunksjonaliteten er ferdig. Men det er alltid uklare krav innen konfigurasjon, spesialtilpasninger og integrasjoner, og for komplekse integrasjoner er det nesten umulig å lage detaljerte krav på forhånd. Et hovedproblem er at mange av kontraktsformene prøver å forhindre kravendringer. Men her må kartet tilpasses terrenget og ikke omvendt — prosjekt og kontraktsform må ta hensyn til at integrasjoner og tilpasninger ikke er stabile.
- “Smidige metoder fremmer bærekraftig programvareutvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et jevnt tempo hele tiden.”
Ved å dele opp funksjonaliteten i passende pakker, økes fokus på det som skal godkjennes og testes nå. De som tar imot “hele pakken” i et vannfallsprosjekt har vanskelig for “gape over” hele produktet, det blir å hoppe mellom forskjellige moduler og funksjoner uten å bli ferdige med noe.
De andre prinsippene nevnt i Agile Manifesto er også generelle prinsipper som gjelder for mottaksprosjekter — og de bør også følges!
Et begrep fra Scrum-verdenen er også svært viktig: “Definition of Done”. Denne definisjonen har mange varianter — en norsk variant er “ferdig-ferdig”. I mottaksprosjekter blir man veldig ofte “nesten ferdig” med mange aktiviteter. Det gjenstår feil, del-funksjoner mangler etc., man får nye leveranser og man repeterer testingen mange ganger.
For å få bukt med dette må både leverandør og kunde være enige om at man faktisk skal bli ferdig med “noe” før man går videre. Og dette “noe” må være veldefinert — f.eks. en funksjon, tilpasning eller en integrasjon.
Mottaksprosjektene blir ikke fullt smidig med dette, men det er mulig å komme et godt stykke på vei.
Hva er anbefalingene?
Det viktigste du gjør er et godt grunnarbeid i starten. Da reduseres risikoen i mottaksprosjektet og du får samtidig mer kontroll.
Dette innebærer noe mer jobb tidlig i prosjektet — men det får du igjen senere, med god rente.
Krav og behov
- Fokuser på behov fremfor detaljerte krav.
Når man skal kjøpe standardprodukter så vil man samle behov og krav til en kravspesifikasjon som sendes ut i en tilbudsfase, deretter vil leverandøren svare opp tilbudet. Krav og behov kan være beskrevet på forskjellige måter og nivåer, f.eks. user stories, use cases, eller tradisjonelle krav av typen “Systemet skal….”.
I kravspesifikasjonen bør det være med overordnete behov samt eksempler på mer detaljerte krav. Leverandøren får da mulighet til å svare opp de overordnete behovene, men kan forstå litt mer av hva kunden vil ha ut ifra de detaljerte kravene, uten at disse er bindende.
Det er også vesentlig at de som formulerer behov og krav er de som skal bruke systemene — ellers får man ikke fram de reelle behovene.
Demosystemer
- Ta i bruk demosystemer og kjør realistiske brukertilfeller på plattformene.
Dette kan gjøres før man sender ut forespørselen eller som en del av forhandlingsfasen. Da får man en mye bedre følelse både med ytelse, funksjonalitet og brukervennlighet enn hvis man bare ser på en demo fra leverandør. Eller enda verre: At man får servert powerpoints med skjermbilder.
Kontraktsform:
- Velg din kontraktsform med omhu!
Det er viktig å ikke la seg begrense av kontraktsformene man har brukt i mange år. Eller at man i offentlig sektor låser seg til å bruke Statens maler uten endringer.
Hvis man f.eks. starter med noen av Statens maler som SSA-K eller SSA-L så bør disse endres slik at man får på plass de mekanismene man ønsker — bl.a. en stegvis leveranseplan. SSA-K sier bare at det finnes et bilag som spesifiserer leveransetidspunkt, ikke noe om hvordan dette skal utformes. Så det er fullt mulig å lage en leveranseplan som spesifiserer levert produkt hver annen uke og kundetest/utrulling i to uker.
Kan du få systemet i drift før alt er ferdig?
- Planlegg slik at du får deler av produktet ut til brukerne tidlig.
Et av hovedpunktene i den smidige tankegangen er at det som utvikles/leveres, ikke bare skal testes, men skal ut til brukerne i virkelig drift.
I mange tilfeller er det gammel vane at alt skal tas i bruk samtidig. Kan du snu på dette? Kan du f.eks. ta i bruk en og en integrasjon, eller kan du ta i bruk deler av funksjonaliteten?
En framgangsmåte er å starte med noen interne iterasjoner, deretter legge systemet ut til brukerne, og fortsette med flere iterasjoner for å legge til funksjoner og integrasjoner. I stort sett alle systemer er det tilleggsfunksjoner og moduler som kan tas i bruk etter hvert.
Og: Du får startet med gevinstrealiseringen før prosjektet er ferdig. Du har altså en god mulighet til å rette opp kursen hvis du ser at du ikke får ønsket gevinst.
Leveranser og leveranseplan
- Lag en leveranseplan med iterasjoner der enkeltfunksjoner kan leveres, testes og settes i drift.
I mange tilfeller er leveranseplanen basert på leverandørens lovnader om at hele produktet er ferdig. Dvs. systemet konfigureres opp og leveres til kunde «fiks ferdig». Ut fra dette velger mange å ta imot og teste alt på en gang.
Men: Det er alltid mye som skal konfigureres opp, integrasjoner som skal endres, og funksjonalitet som skal tilpasses. Og i store systemer vil det være flere måter å løse oppgaver på.
Noe av det viktigste du gjør er å dele opp leveransene, teste én og én bit og bli helt ferdig med en bit før du går videre.
Dette er en av de mest komplekse og viktigste oppgavene, dvs. å dele opp leveransene, sette opp en fornuftig leveranseplan og få det til å henge sammen med kontrakten. Se på leveranser og aktiviteter både hos leverandøren og internt hos kunden, vurder risikoene og få til en god rekkefølge på aktivitetene.
Et eksempel kan være en rapportmodul. Denne vil gjerne være ferdig tidlig i prosjektet - men kan ikke tas i bruk fordi det ikke er mulig å få ut realistiske rapporter i starten. Man må altså vente med rapportmodulen til resten er ferdig.
Derimot bør man prioritere viktige integrasjoner — f.eks. brukerhåndtering. Selv om dette kan være en tung oppgave (eventuelt fordi det er en tung oppgave) så bør det prioriteres slik at man får levert og testet dette tidlig.
Videre må man i god smidig-ånd ha mulighet til å endre på leveransene. Det viktige er jo ikke at leveransene kommer i akkurat den rekkefølgen man har definert i starten — men at man får levert en iterasjon, testet og godkjent denne og dermed blir ferdig med iterasjonen.
Betaling
- Lag en betalingsplan som følger leveranseplanen!
Kontrakten bør lages slik at leverandøren har et incentiv til å levere deler som er 100% ferdige. Altså at betalingen utløses når man er helt ferdig med en iterasjon — man har oppfylt “definition of done”.
Kanskje kan man gi leverandøren 5% betaling pr del-leveranse, i stedet for å betale 80% når alt er levert?
Skal du ta i bruk mer funksjonalitet senere?
-Ha en ekstra iterasjon for å gå gjennom fremtidig bruk!
I mange tilfeller tar man kun i bruk en liten del av det leverte produktet. Et tips er å legge til en iterasjon ekstra for å teste ut og vurdere de delene av produktet du tror skal brukes senere. Det vil gjøre deg mer trygg på at du vil lykkes med produktet også senere.
Konklusjon
Vi håper at dere har fått noen gode tips til hvordan man gjør mottaksprosjekter smidigere. Ved å gjøre et ekstra stykke arbeid før man skriver kontrakt med leverandøren kan man redusere risikoen vesentlig i et slikt prosjekt. Det er viktig å se på hvordan man deler opp leveransene, og hvordan man får funksjonalitet ut til brukerne så fort som mulig.
