10 gode råd af konsulent Morten Korsaa, DELTA Vælg den rette model SKI rammekontrakten giver mulighed for at bruge to udviklingsmodeller den klassiske og den nye. Dit valg er afgørende for succes. Den klassiske model er den du sikkert tænker på. En faseopdelt vandfaldsmodel med analyse, kravspecifikation, design, konstruktion, test og implementering. Den er skabt i produktionsmiljøet under industrialiseringen, og er fremragende til det som den er skab til, men ikke nødvendigvis til IT udvikling. Den nye model er skabt til et innovationsmiljø, hvor kunden ikke kender sit mål i detaljer, og hvor udnyttelsen af den læring som sker i processen er afgørende for succes. Det er to typiske kendetegn for IT udvikling. Den klassiske er optimeret til et stabilt marked, den nye er optimeret til et foranderligt marked. Hidtil har alle udbud skulle køre efter den klassiske, men muligheden for dialog under SKI rammekontrakterne giver mulighed for den nye model. Den nye model kræver imidlertid en helt anden type projekter, og nogle andre risikominimeringsteknikker. De findes og bliver stadig mere populære, der hvor de kontraktuelt kan benyttes, og det er den mulighed du har nu. Om du skal vælge den klassiske eller den nye kan afgøres ved følgende kriterier. Tænk eventuelt på organisationens sidste projekt, og vurder hvad der var kendetegnende: Klassisk Du ved nøjagtig hvad du vil have Du er klar til at specificere alle krav meget nøjagtigt tidligt i forløbet Du forventer ikke at opdage nye forretningsmæssige muligheder i udviklingsforløbet Du ønsker at begrænse involvering til begyndelsen og slutningen af projektet Dit forretningsområde forandrer sig ikke Din infrastruktur er stabil Det at kende prisen på forhånd er vigtigere end at få det maksimale forretningsmæssige udbytte. Ny (iterativ) Du kender de forretningsmæssige mål med anskaffelsen, men ikke design detaljerne Du har ikke ressourcer til at specificere alt fra starten Du forventer at opdage nye forretningsmæssige muligheder undervejs i forløbet, og er klar til udnytte dem og dermed ændre indhold af projektet i nødvendigt omfang. Du ønsker en jævn involvering gennem hele projektforløbet Du forventer forandringer i forretningen og omgivelserne Det er vigtigt at kunne tilpasse sig forandringer i infrastrukturen Du prioriterer maksimal forretningsmæssig værdi over det (tilsyneladende) at kende prisen på forhånd Hvis din virkelighed taler for den nye model, så vælg et projektforløb der følger en af de nye iterative udviklingsmodeller, som f.eks. Lean development, XP, RUP eller andre agile metoder.
Vær generøs med egen indsats i projektet Den politiske virkelighed vil altid til sidst blive overtrumfet af den praktiske. Lige inden et system er færdigt, har alle erfaret hvilken indsats det reelt krævede. Ofte er det en indsats, som ikke ville være muligt at skabe politisk vilje for i begyndelsen af et projekt, men som med et væsentligt spildtids tillæg alligevel bliver realiseret i projektforløbet. Historien viser, at værdien af brugerinvolvering næsten altid bliver undervurderet. Hvad er historien i din organisation? Hvor meget tid brugte I sidst? Hvor meget burde have været brugt? Lær af historien, og vær generøs for din egen skyld. Meld også din forventede indsats ud til leverandørerne. På den måde sikrer du, at leverandørens foreslåede samarbejdsorganisation lever op til din egen indsats eller kompenserer for den, om nødvendigt. Kend værdien af din IT implementering Afkastet af en investering i IT kan have mange ansigter. Nogle er direkte målbare, andre er meget indirekte. Men det er nyttigt at arbejde dem alle igennem, og sætte finansielle mål på. Nytten viser sig, når man i projektforløbet bliver stillet over for nogle beslutninger, som vedrører de omkostninger, der er forbundet med investeringen. Disse beslutninger bliver meget nemmere, hvis man har et klart billede af de forventede økonomiske fordele. Fordele er både de direkte omkostningsbesparende, som man relativt nemt kan sætte pris på, og de fordele som f.eks. borgerne har ved en lettere betjeningsproces. Det er ikke nemt, men prøv at sætte værdier på, for diskussionen er væsentlig. Det bliver aldrig helt nøjagtigt, men det er bedre end ikke at vide, og man er kommet meget tættere på sandheden. Derved skabes et mere sikkert beslutningsgrundlag, når der skal prioriteres i løbet af projektet. Meld gerne dine forventninger ud til leverandørerne. Så bliver løsningerne og implementering yderligere målrettet, så de forventede fordele lettere bliver opnået. Stil krav til leverandøren Du er som kunde i din gode ret til at stille krav til din leverandør, også på procesmodenhedssiden. Ved kontraktindgåelse kan du spørge ind til leverandørens modenhed, og på den baggrund skabe en god dialog. I forløbet op til denne rammekontrakt har alle leverandørerne skulle svare på nogle spørgsmål om egen modenhed. Leverandøren er under rammekontrakten forpligtet til at leve op til disse krav. I praksis vil det sige, at hvis en leverandør f.eks. har besvaret, at han kan genskabe en to år gammel version af et system, så kan du forvente, at han kan det. Bed i den forbindelse om at være med til at reviewe projektets Configuration Management plan, og få derved objektiv indsigt i leverandørens modenhed på dette område. Har leverandøren svaret at han ikke kan genskabe en to år gammel version af et system, så kan du som kunde overveje at stille det som krav. For at kunne det, skal leverandøren bl.a. have styr på alle sine arbejdsprodukter i et versions- og konfigurationsstyringssystem have kontrol med hvilke versioner af hvilke moduler som er ude hos hvilke kunder kende status på alle udviklingsaktiviteter have en defineret proces for hvilke moduler der kan komme med i en release, og hvilken kvalitet de skal have Alt sammen ganske grundlæggende krav til et projekt under fornuftig styring, og derfor helt valide krav at stille til en leverandør. Et andet eksempel kan være tiden leverandøren bruger på at analyserer et ændringsønske. Hvis det er væsentligt for dig, så stil krav til tiden. Det fortæller også om hans procesmodenhed.
Lad derfor specifikke procesmål indgå i aftalen, og aftal på forhånd en række procesaudits, som du som kunde deltager i, og få en objektiv indsigt i leverandørens evne til at levere det aftalte, og grib problemer før de opstår. Forlang også (og tillad) at leverandøren er kritisk og stiller spørgsmålstegn ved nogle af de krav og forventninger, som du stiller. En god og konstruktiv dialog med leverandøren kan være med til at sikre at alle styrker og svagheder bliver belyst og dermed at løsningen og processen bliver bedre. Tag egen modenhed seriøst Det er også nødvendigt at se på egen modenhed, for at kunne matche sin leverandør. Typiske områder hvor dette er relevant er: Kravspecifikation (beskrivelse af krav, prioritering af krav, sammenhæng mellem krav), dialog med leverandøren om løsningsbeskrivelse og ændringshåndtering, samt deltagelse i test, krav til test og testdata. Det bedste kunde-leverandør forhold opstår, når parterne matcher hinanden modenhedsmæssigt. Få lavet en vurdering af egen modenhed, så du kender dine styrker og svagheder. På den baggrund kan du lave en plan for hvilke områder, det vil være mest hensigtsmæssigt at blive bedre til. Lav dernæst forbedringsteams, som skal forbedre de processer, som trænger mest. Når man kender sin egen modenhed, er det nemt at skabe en dialog med leverandøren om, hvordan I opnår de bedste resultater sammen. Åbent, ærligt og konstruktivt. Skab nærhed I løbet af et IT projekt er der behov for store mængder af afklarende spørgsmål. Altafgørende for et projekts hastighed er derfor, hvor hurtigt en udvikler kan få svar på et spørgsmål. I det værst tænkelige scenario indgår opsamling af spørgsmål til et månedligt afklaringsmøde. I det bedst tænkelige scenario sidder dele af projektet fysisk i samme rum som brugerne i den tid, hvor det er mest nødvendigt. Sørg derfor for at skabe de bedst mulige forhold for projektet, hvor informationer kan flyde frit. Prisen for 30 min af en superbrugers tid væk fra hans daglige arbejde er synlig. Prisen for at tre mand i projektet kommer til at arbejde i en gal retning i 14 dage, fordi de ikke havde adgang til 30 minutter af superbrugerens tid er ikke særlig synlig, men den er med al sandsynlighed betragteligt større. Se projektet i sin helhed Først når virksomheden kan bevise at den har høstet de forretningsmæssige fordele af en IT investering, er projektet slut! Det betyder at når implementeringen fra en teknisk synsvinkel synes at være færdig, så skal kundeorganisationen: trænes i de nye systemer vende sig til at bruge dem, så udnyttelsen af systemerne bliver god tilpasse omkringliggende processer til at udnytte nye muligheder, som ikke var forudset tilpasse belønningsstrukturer m.m.. lære hvordan fordelene kan måles Det kræver i praksis et længere projekt forløb, med fortsat tilknytning af ressourcer. Der skal ikke nødvendigvis bruges megen tid, men ansvaret skal være klart defineret, så aktiviteterne ikke løber ud i sandet. Hele projektet risikerer at fejle på et tidspunkt, hvor leverandøren har afsluttet sine forpligtelser, dvs. de fleste udgifter er afholdt, men gevinsten er ikke indkasseret. Et projekt er således i praksis først afsluttet med succes, når projektet har bevist, at organisationen har haft gavn af implementeringen.
Vælg hyppige og små delleverancer Uanset valg af udviklingsmodel så er mange delleverancer godt for begge parter. Af to primære årsager: 1. Det begrænser hvor store fejl, der kan begås 2. Begge parter træner integrationsprocessen. Princippet er at bringe så meget af funktionaliteten så tæt på produktionsmiljøet så tidligt som muligt. Det er en risikominimeringsteknik, der handler om at få sikkerhed for kvaliteten hurtigst muligt, frem for at akkumulere fejl til en test fase til sidst. Hellere vide at 10% af funktionaliteten virker efter hensigten, end at tro at man er 80% færdig med udviklingen. På den måde øver både kunde og leverandør sig i, den erfaringsmæssigt meget komplekse proces det er at integrere den nye funktionalitet med den gamle. Hvis man har prøvet det 20 gange i projektforløbet, så er den sidste og endelige integration ikke noget problem. Ikke i forhold til hvis man har sparet al funktionaliteten op til en enkelt leverance, som man så skal integrere for første gang. Sørg for at beslutninger kan ske hurtigt Det er som udgangspunkt kun brugerne og kunden, som ved hvad de vil have. Derfor skal den viden også være umiddelbart til rådighed for projektet. Skab de kanaler som er nødvendige for, at informationen kan flyde hurtigt og effektivt. Styregrupper skal f.eks. være beslutningsdygtige på få dage. Intet seriøst projekt kan vente tre uger på en afgørelse, som er så væsentlig at den skal tages af en styregruppe. Så må andre midler end fastlagte møder tages i brug. Det kan være en vedtaget aftale om, at en given person tager en beslutning, baseret på de reaktioner han har fået fra de øvrige styregruppemedlemmer, to dage efter at spørgsmålet er blevet formelt rejst af projektlederen i en rundsendt e-mail. Målet er at projektet ikke bremses af ubeslutsomhed, eller tvinges til at tage tvivlsomme beslutninger på vegne af kunden/brugerne. Vær proaktiv med accepttest Den endelige accepttest er naturligvis altid kundens ansvar. Kunden kan minimere sin risiko, ved at gøre dette så tidligt som muligt. Så snart at der er defineret et funktionalitets krav, så bør kunden gå proaktivt ind og definere accepttest kriterierne, og køre testen så hurtigt, det er muligt. Det har følgende fordele: 1. Udviklerne har nogle helt klare mål i kundens accepttestkriterier, hvilket øger kvaliteten af deres arbejde betydeligt. 2. Kunden får en reel føling med projektets fremdrift, frem for en mere subjektiv vurdering fra projektledelsen. Udfordringen ligger i at kunne gentage testen uden det store besvær. For hver gang der kommer ny funktionalitet, så er det, til en hvis grad, relevant at teste den eksisterende funktionalitet, for at se at det ikke har ændret noget. Derfor kan automatisering af regressionstesten være en fremragende investering, ikke mindst da man så vil køre den oftere end hvis det var en besværlig manuel proces. Få hjælp til de rigtige ting Indkøb og implementering af IT er en øvelse, som kræver mange kompetencer, og flere af disse er det naturligt ikke at have i sin virksomhed. Mange vælger derfor at købe denne kompetence gennem eksterne konsulenter. Eksterne konsulenter kan hjælpe med nogle trin i processen, men ikke alle, og denne sondring er helt afgørende. Jo mindre moden man som kunde er, jo mere fristende vil det være at outsource hele projektet. IT implementering handler typisk om gennemgribende forandringer i organisationen. Med den nye teknologi, følger nye processer, nye arbejdsformer, nye arbejdsstrukturer, nye belønningsstrukturer, nye kompetenceudviklingsprogrammer, og alt det som er ledelsens normale ansvar. Og det er det
også når det handler om en IT implementering. Et ansvar som ikke kan uddelegeres, uden at uddelegere den indflydelse, man selv sidder med. Konsulenter kan hjælpe med alverdens praktiske gøre mål og rådgivning, blot ikke ansvaret for den forretningsmæssige implementering. Hvis motivationen for uddelegering er, at man ikke føler sig tryg, og gerne vil af med ansvaret, så er det en dårlig ide. Hvis motivationen for uddelegeringen er, at man gerne vil have hjælp til et bedre beslutningsgrundlag, eller hjælp til nogle praktiske gøremål, så er det en god ide. Men ansvarlig for den samlede implementering, det er og bliver den daglige ledelse. Afrunding - kom godt i gang med modenheden Modenhed er et udtryk for, hvor dygtigt en organisation udfører sine forretningsprocesser, her mest dem som har med IT udvikling at gøre. Erfaringer fra branchen har vist, at både kunder og leverandører har stort potentiale for forbedringer. Forbedringer af modenheden begynder med erkendelsen, og fortsætter med en bevidst forbedring af processerne, og energien kommer til dels fra de krav vi stiller til hinanden. Det er nemmere at skabe et godt samarbejde, hvis begge parter har erkendt sit forbedringspotentiale, er klar til at forbedre sig, og ved hvor den anden bør være stærk. Så er bevægelsen mod en højere modenhed skabt for begge parter, og derved mod bedre IT investeringer. Men et er målene, et andet er midlerne. Grundlæggende er det ganske simpelt, men det er svært at få det gennemført. Det kræver forandringer, og det kræver nye kompetencer af organisationen. Derfor: Tag bolden op i forbindelse med at organisationen forbereder det næste IT projekt. Vær realistisk med organisationens modenhed og brug også dialogmulighederne med leverandøren til at løfte den fælles modenhed for det konkrete projekt. Leverandørernes modenhedsniveau blev evalueret i forbindelse med udbuddene af de tre rammekontrakter. En oversigt herom findes på www.netindkoeb.dk,.