georg strøm bloghoved

IT-projekter er ikke forberedt på det sandsynlige

Det er årsagen til at mange projekter ikke bare går galt, men at de går rigtig galt. Den digitale tinglysning er et eksempel, Rejsekortet og Forsvarets DeMars projekt er andre eksempler. Vi kan endda betragte IC4 togene som endnu et eksempel, da toget i princippet er et komplekst IT-system på hjul.

Statistikken viser at langt de fleste større IT-projekter enten er for dyre, forsinkede, eller ikke opfylder de behov som de egentlig skulle. Alligevel lader det til at ledere af IT-projekter ikke tager højde for at de går galt, men i stedet regner med at netop de er i den usandsynlige heldige situation, at deres projekt vil levere det ønskede til tiden og indenfor budgettet.

I stedet er det bedre fra begyndelsen at tage højde for at projektet vil gå galt, så det er nødvendigt at være klar til at begrænse konsekvenserne. Det øger nok ikke risikoen for at projektet vil gå galt. Risikoen er høj nok i forvejen, og ledere af et projekt vil nok under alle omstændigheder gøre mest muligt for at undgå at det går galt.

Måske er problemet at der er ikke er så mange som ved, hvordan de kan begrænse konsekvenser af uheld i projekter? Her er så nogle forslag ud fra min viden om hvad der sker når projekter går galt.

Lav en kontrakt som tager højde for at projektet kan gå rigtig galt, at det altså ryger helt ud over den kant som parterne normalt forestiller sig, når de laver kontrakten. Det sker faktisk ret ofte i IT-projekter. Om ikke andet har parterne tænkt igennem på forhånd hvad de skal gøre, når projektet går galt, så de ikke spilder tid på at forhandle eller beslutte det.

Sørg for at tage højde for tredjeparter som projektet er afhængige af, men som ikke har været med til at tage beslutningerne. I den digitale tinglysning var det både boligadvokater og købere og sælgere af fast ejendom. Dem der leder projektet kan ikke automatisk regne med at andre som ikke er med i projektet, automatisk gør som de ønsker.

Lav så tidligt som muligt en realistisk test af brugbarheden og de mest kritiske arbejdsprocesser. Det er bedre at finde ud af på et tidligt tidspunkt at der er problemer som bør løses, end at de først bliver opdaget når systemet skal i drift.

Lav en plan for forberedelse og undervisning af brugerne, og sørg for at de bliver forberedt så tidligt som muligt. Det er min erfaring at for sen introduktion eller for dårlig uddannelse af brugere alene er nok til at vælte et ellers nogenlunde vellykket projekt.

Lav en plan for, hvis projektet er forsinket. I den digitale tinglysning var det sandsynligvis en medvirkende årsag til problemerne, at tinglysningen var flyttet til Holstebro, og at mange af dem der lavede manuel tinglysning var afskediget, så det var umuligt at skaffe nok personer til at tinglyse manuelt i en overgangsperiode.

Lad være med at forvente, at det er muligt samtidig at afskedige personer, give de tilbageværende tid til at lære det nye system at kende, og tilbyde en normal eller bare nogenlunde tilfredsstillende service til kunderne.

Det er almindeligt at ledelsen i et projekt ikke får noget af vide om mulige problemer, eller at de ikke er tilstrækkeligt opmærksomme på når der er et muligt problem. Det er værd at sørge for en særlig person eller gruppe som kan indsamle og vurdere informationer, og som ikke er med til at tage beslutningerne. Ellers vil vurderingen af informationerne uundgåeligt blive farvet af hvad beslutningstagerne håber vil ske og netop er optaget af.

Sørg for at have nogen som hurtigt kan identificere de mest akutte problemer og finde ud af hvordan de kan løses, når projektet går galt. Konsekvenserne af et projekt som går galt, vokser meget hurtigt. Omvendt har jeg set hvordan en hurtig løsning af de to eller tre værste problemer kan vinde nok tid til at få et projekt nogenlunde helskindet igennem.

Endelig skal ledelsen af et projekt huske, at der altid er mindst tre parter. Leverandøren, kunden og virkeligheden. Og uanset hvad leverandøren og kunden bliver enige om, så er virkeligheden den stærkeste af de tre.

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Poul-Henning Kamp Blogger

Jeg har i flere år udfordret folk til at vise mig blot et IT projekt med over 20 udviklere der er kommet i mål indenfor +/- 10% af budget, funktionalitet og pris.

Jeg har ikke fået et eneste dokumenteret eksempel.

Med mindre du kan påvise et sådant eksempel, synes jeg du skal rette "de fleste større IT-projekter" til "alle større IT-projekter" så vi er helt på det rene med hvor elendigt det star til.

Pall Jonsson

Ericsson AXD301 er i dag rygraden i internettet. Dette var et 400.000 mantime projekt i årene 1995 - 1997. Projektet overhold alle krav om funktionalitet, og leverancedatoer og lå under budget i hele perioden.
Så det kan godt lade sig gøre ;-)

Anonym

Den mulighed der ligger nærmest, er at man skal kunne fremvise et produkt, som opfylder de basale krav og en løsning på den problemstilling der skal løses. Alternativt, skal man ikke i betragtning i forbindelse med udbud eller direkte indkøb.

Der er at for mange projekter, der sættes i gang, med forventning om, at en eller anden med tilknytning til projektet, kommer på de løsninger der er behov for, i forbindelse med de relevante problemstillinger.

Anonym

IC4 er et projekt, der er indkøbt af flere omgange. Det kan der ikke rettes op på, det er kun leverandøen, der kan trække sig, og så vidt jeg ved, kun ved at gå konkurs.

Der er masser af muligheder for, at IC4 kan komme på skinner i regelmæssig drift. Det er kun er spørgsmål om man spørger de rigtige, så kan der sættes en fungerende løsning sammen.

I forbindelse med DSB / BaneDanmark / IC4, benyttes der en række rådgivere. Der skal man måske kigge på, hvor tæt på målet de rådgivere har været.

Lars Christensen

Det er meget godt at være forberedt på det mest sandsynlige eller det værste, det er sikkert også ret godt at kunne forudsige fremtiden :-)

Langt de fleste af de kuldsejlede eller haltende IT-udviklingsprojekter vi har været præsenteret for i DK i de sidste 10-15 år, har alle haft samme problem.
De er startet, uden en veldefineret kravspecifikation og så har man bare fyldt nye ønsker på fra dag et. Det går altså galt!

Det er helt essentielt, at projektchefen (PC) holder sig til det mål der udstikkes fra Go-signalet - og PC SKAL have så meget magt og gennemslagskraft at den råde tråd kan holdes fra start til slut. Basta!

Vi lavede et præprojekt der var similart til Rejsekortet da dette var i sin vorden (vi vidste ikke det var på vej)
Det var en ustyrlig proces med et væld af ting "der også lige skulle med" Men pr. definition er kravspecifikationen det ENESTE holdepunkt man har at forholde sig til - alt andet er snak, støj eller i værste fald obstruktion, som simpelthen skal holdes ude af udviklingsprocessen.

Mvh Lars plbrake.dk

Morten Krøyer

Sjovt. Jeg er af den stik modsatte opfattelse. Hvis man skal holde sig til den oprindelige kravspecifikation, så ender man jo med at være nødt til at udbygge den så den har al tænkelig og utænkelig funktionalitet med, og så går det da først galt. Så ender man jo, som så ofte set med et system som har kostet urimelig mange penge og hvor 50-60% af funktionaliteten aldrig bliver brugt.

Jeg tror iøvrigt ikke det er sandsynligt, at man inden igangsættelsen af et projekt kan lave en kravspecifikation som ikke efterlader spørgsmål til hvordan kravende skal implementeres...

Per Lolk Blogger

Inden for de opgaver, jeg har erfaring med (hvilket primært er infrastruktur/platform for applikationer) har jeg faktisk en del positive oplevelser med projekter, der bliver afsluttet til tiden og inden for den aftalte økonomi.

Efter min mening er et vigtigt succeskriterie, at projektet ledes af en dygtig projektleder, der ud over at have værktøjerne til at lede projektet også har en høj grad af faglig indsigt, fordi det gør det meget nemmere at sikre kommunikationen imellem de tekniske kompetencer og kunden, så man kan navigere rundt om de udfordringer/uforudsete elementer, der opstår i et projekt, uden at det giver forsinkelser eller uventede budgetoverskridelser.

En af mine kollegaer har skrevet lidt om, hvordan man kan sikre dette, på vores blog, Blogit

Thomas Vestergaard

En dygtig projektleder er ikke i sig selv tilstrækkeligt. En projektleder kan ikke udrette mere, end der er støtte til fra ledelsen.

Der skal være mulighed for at eskalere problemer til en leder med tilstrækkelig interesse og indflydelse til at gå ind og tage de nødvendige forretningsbeslutninger.
Det kunne f.eks. være at få en obsternasig mellemleder til at rette ind, sikre udarbejdelsen af en analyse bliver opprioriteret eller rådigheden over en bestemt ressource. Altså ting der ligger udenfor projektet, men som kan være afgørende for projektets leverance.

Lars Christensen

Enhver rejse (udvikling) kræver at målet kendes, ellers kan man tage megen unødvendig bagage med :-)

En kravspec i min optik drejer sig kun om selve kerneproduktet - alt andet ligger i den altid forandrelige forretningsplan/drejebog/what ever.

Desuden er Keep It Simple Stupid "KISS" en rigtig god rettesnor, fordi vi behøver altså ikke lave "the silver bullit" hver gang.

Der foregår så megen udvikling sideløbende rundt om i verden, at et meget komplekst projekt risikere at bruge energi og penge på, at udvikle ting som andre arbejder på i andre sammenhænge.

Mvh Lars plbrake.dk

Jacob Christian Munch-Andersen

Lars, har du overhovedet forstået hvad softwareudvikling går ud på? Du skal levere et produkt som opfylder kundens behov.

Ingen tvivl om at en kravspecifikation som så vidt muligt beskriver disse behov er et rigtig godt sted at starte, men det ville være naivt at tro at den kan stå alene. Før eller siden må man begynde brugertest, og så viser der sig i reglen nogle nye hensyn.

Selvfølgelig må man også sætte en grænse for ændringerne, og særligt må man sørge for at de ændringsforslag som kommer igennem er gennemtænkt således at det rent faktisk er værdifulde forbedringer.

Men pointen er, hvis ikke man er bare en smule fleksibel så risikerer man at levere et system som reelt ikke kan bruges til det formål det var tænkt til.

Anonym

Det med Kravspecifikation er såmænd godt nok. Det er jo også en del af udbudsmaterialet, eller bør være det.
Men kan man ikke fremvise en vare, der lever op til det, så skal man ikke have lov til at byde ind.

Som der ligges op til i indlæg, så er det i udviklingsfasen, det går galt.
Staten skal ikke foretage indkøb, hvor der indgår UDVIKLING af nyt produkt, hverken i IT eller f.eks. som vi har set det med IC4.

Det er jo ikke Statens opgave at fremelske nye virksomheder, der tager livet af dem som kan, hverken inden for det ene eller det andet. Det er konkurrenceforvridende i forhold til dem som faktisk kan levere en vare.

Som eksempel. I forbindelse med IC4, er det tydeligt, at der var en Dansk fabrik som kunne levere varen, men som blev vraget fordi man valgte at betale for en mulig udvikling, hos en anden leverandør.

Alt andet lige, så gør man hvad man kan, for at vride halsen om på dem som i forvejen kan, når Staten begynder at betale for at udvikle et produkt.

Udvikling, er noget der foregår inden man byder ind på et produkt, ellers skal man ikke kunne byde ind.
Kun at sandsynliggøre, at man kan levere noget som man ikke har eller kan specificerer som et indkøb, er ikke nok.
Består en levering af mange delprodukter, så kan man beskrive at man kan samle disse produkter til en samlet løsning, der opfylder kundens krav.
Det er helt almindelig udbuds- og indkøbspolitik.
En entreprenør, skal ikke bare vise han har en rendegraver for at kunne byde ind på et byggeri, han skal også fremvise realistiske projektplaner, økonomiplaner, tegninger og lignende. Indeholder tegningerne ikke den forventede løsning, så bliver man udelukket, allerede i forbindelse med licitationen / tilbud.

Det eneste en kunde skal forholde sig til, er KRAVENE til produktet.
Når kunden har specificeret sine krav, kan mulige leverandører forholde sig til om det er et produkt de kan levere, og hvad prisen på deres løsning bliver.
Det er mekanismen i enhver handel.

Søren Louv

@Thomas: Hvad vil du gøre, når kunden ikke kender alle krav på forhånd, ned til mindste detalje?

Lad os forestille os en graf over "information til rådighed", og "beslutninger der skal træffes" - de vil være omvendt propertionale.
Ved starten af et projekt, vil vi formulere krav, og dermed tage størstedelen af beslutningerne, der kommer til at påvirke resten af projektet.
Denne graf vil altså være faldende.

I modsætning, vil informationsgrundlaget ved projektets start være på et minimum, men konstant stigende, da vi undervejs støder på nye udfordringer og får ny indsigt.

Vælger vi at lægge os fast på én løsning fra starten, uden mulighed for ændringer, nedsætter vi selvfølgelig alle usikkerheder - der er ingen tvivl om hvordan systemet skal udvikles. Men vil det i sidste ende opfylde kundens behov og ændrede krav?

Tillader vi fleksibilitet kan vi forhåbentligt udnytte den nyvundne viden.

Agil udvikling er ikke nødvendigvis den hellige gral, og jeg sidder dagligt med de samme udfordinger - jeg tror dog ikke de løses ved at skrive en tyk kravspec med alt defineret ned til mindste detalje, uden mulighed for ændringer.

Men diskussionen er både interessant - og vigtig! :)

Anonym

@ Søren.

Du stiller valget mellem fleksibilitet og krav.
Det er ikke der valget ligger for leverandøren.
Leverandøren skal forholde sig til kundens forventning, altså kundens krav.
Ændrer kunden i kravene er det en tillægsydelse, som kunden betaler ekstra for.
Det er helt almindelige leveringsbetingelser.

Det har en afgørende fordel. Kunden kender prisen, og de efterfølgende tillægsydelser, kan kunden tage stilling til, efterhånden som kundens ønsker ændrer sig.

"Den her med" at kunden lige vil have noget grundlæggende ændret, midt i projektet, er ikke en mulighed, på godt og ondt.
Når man bygger et hospital, så er det f.eks. ikke en mulig løsning, at der skal parkeringskælder under, når man er ved at monterer der sidste lister på stuerne.
Disciplinen opretholdes, også fra kundens side.

Det er ikke leverandørens problem, hvilke krav og forventninger kunden har. Det er kunden der skal definerer sine krav og forventninger.

Når kunden har defineret hvad kunden ønsker, så kan leverandøren tage stilling til om det er en vare der ligger inden for leverandørens leveringsmuligheder, og fastsætte en pris.

Det er helt lige meget om kunden skal købe en bil der opfylder kundens krav og forventninger, eller om kunden skal have leveret et IT-system.

Det handler helt enkelt om at der er for meget dårlig købmandskab.
Det er jo ikke en tilfredsstillende handel, hvis kunden ikke får hvad kunden forventer.

Skulle IC4 være en god handel ?
I den forbindelse, er der ikke leveret den halve løsning, men der er samtidigt skabt særdeles ringe vilkår for den leverandør der kunne levere.
Det kan jeg sagtens tegne en tredobbeltkurve for, som er negativ, og selvforstærkende. Der er tale om, at pengene er brugt, den gode leverandør er i negativ vækst, og når der skal købes tog så skal pengene betales en gang til.

Det er ikke så svært, hold udvikling uden for handlerne, men betal for den vare man får.
Når man leverer en vare, så skal varens pris kunne betale for både varen selv, og udviklingen eller indkøbet af den kommende vare.
( Hvis købmanden sælger sine cornflakes, for det samme som han køber dem for, så taber han penge, for handlens finansieringsomkostning skal også indeholdes i leveringsprisen. )

Det er som oplægget beskriver, altid behæftet med meget stor økonomisk risiko, når man betaler for udvikling. ( Plante majs )
Meget ofte, så får man ikke engang et halvt produkt leveret, ( der gik mug i det for vi aner ikke hvad vi roder med ) og skal betale mange gange det oprindelige budget, ( dem der kan levere majs, sælger dem nu dyrt ) for at få den anden halvdel leveret og passet ind. ( Ellers skal vi gå sultne i seng )

Så er det heller ikke mere kompliceret...
Man har bygget skibe i mange år, på den måde. Der er langt mere komplekse end meget IT, eller et futtog.

Uden at stikke nogen noget i skoene, så vil jeg nødigt være den der skal op til Hr. Møller og sige, at man har overset leverancen på det halve af et containerskib. " Vi troede ikke der skulle motor i :D "

Den slags lader sig kun gøre, hvis det er en leverance til Staten !
Og ja, jeg kan godt huske færgerne AskePot og UrtePot.
Hvad var det lige det hed, det der "near to hulstrimmel", Amanda et eller andet.
Hvordan gik det med de der PET maskiner man fik solgt til forsvaret. Kom der nogensinde lys i nogen af de grønne skærme ?
Bare for at nævne et par projekter der ikke har aktualitet....

Det er lidt påfaldende, at man nødvendigvis må have haft en mere veludviklet projetstyring inkl. økonomi, da man byggede pyramiderne, end man har når der skal planlægges og indkøbes et tog, 4000 år senere.

Med og uden kurver.....

Lars Christensen

@Jacob,
Når du i et udviklingsprojekt kommer frem til brugertest, så bør du have gennemgået kerneproduktets kravspec - medmindre kunden eller kloge hoveder i mellemtiden har ændret så mange detaljer i kerneproduktet, at målet er forsvundet.

Derfor er det vigtigt (som tidligere omtalt) at projektchefen har det helt afgørende ord i forbindelse med evt ændringer.

Du omtaler at såfremt man ikke er fleksibel, så kan man med en firkantet kravspec der beskriver kerneproduktet - risikere at stå med et produkt der ikke kan bruges til det formål det var tiltænkt.

Den situation vil kun opstå, såfremt man har et mangeårigt udviklingsprojekt i et meget omskifteligt marked - og den situation skal man selvfølgelig tage hensyn til.

Mvh Lars plbrake.dk

Flemming Lindbaum

Det er også min erfaring, at der bagved projektlederen bør stå en stærk organisation. Dette gælder naturligvis både på leverandørens og på kundens side. Min erfaring er, at det oftest bunder i forkert/manglende sammensætning af styregruppen, samt dennes manglende kendskab til, hvilke opgaver og hvilket ansvar der ligger i en styregruppe. Det bør være projektlederens livline at kunne gå til styregruppen med problemer, som løses af denne. Jeg har gode erfaringer med, ved projektstart, at uddele ”roller og ansvar” og gennemgå det sammen med styregruppen.

Casper Lawaetz

Der er vel ingen som kan benægte at en god kravspecifikation er alfa omega. Men med så store projekter som rejsekortet osv. så er det næsten umuligt at forudsige og beskrive alle kravene. Men ser man på rejsekortet bør det vel ikke være umuligt at beskrive selve kernen. Hvilke behov skal dækkes og hvordan ser man dem løst. Derefter er det vel hjem på tegnebordet for de forskellige leverandører at komme op med forslag hvordan de ser det implementeret og løst. Komme med forslag til hvordan GUI'en skal se ud osv. Derefter kan man prøve at lave rollespil, brugertest for at se om det vil virke eller ej. Jeg har set flere bruger test opfange hvad udviklerne og analytikerne troede var åbenlyst til, slet ikke blev opfanget af brugerne.

Den næste ting er vel prøve at dele leverancen op i flere små leverancer. Lav leverandøren vise at de kan levere de simple krav. Lad os se på rejsekortet igen. Hvorfor skulle man helt fra starten prøve at implementere den helst store løsning. I stedet som man har gør nu. Start med at få infrastrukturen på plads. Lad rejsekortet løse de simple opgaver som klippekort eller enkeltbillet og lær af erfaringerne og juster fremtidige implementeringer derefter.

Og til sidst projektlederen er vel ikke bedre end sine ansatte. Hvis de ansatte ikke kan spotte fejl og uhensigtsmæssigheder så fanger projektlederen det heller ikke.

Poul-Henning Kamp Blogger

Der er vel ingen som kan benægte at en god kravspecifikation er alfa omega. [...]

Det er ikke kravspecifikationen der er vigtig.

Det der er vigtigt er at vide hvad man foretager sig, hvorfor man gør det og hvad der er vigtigt og hvad der ikke er.

Gode kravspecifikationer formulerer og kommunikere dette præcist, dårlige kravspecifikationer tåger rundt og gør alle forvirrede om hvad der skal foregå.

Langt de fleste IT-projekter kører af sporet fordi der aldrig er blevet intelligent luget ud i kravspecifikationen og/eller aldrig tænkt over hvilke konsekvenser af organisatorisk, procedural og arkitektonisk art det nye system vil have.

Og alt for mange IT systemer er dødsdømt fra starten, fordi tossehoveder tro at "IT" bare er noget "engelsk sovs" man hælder ud over et problem så det forsvinder.

Casper Lawaetz

Det er ikke kravspecifikationen der er vigtig.

Det der er vigtigt er at vide hvad man foretager sig, hvorfor man gør det og hvad der er vigtigt og hvad der ikke er.

Gode kravspecifikationer formulerer og kommunikere dette præcist, dårlige kravspecifikationer tåger rundt og gør alle forvirrede om hvad der skal foregå.

Jeg vil nu mene at det du skriver er det som gør en kravspecifikation god. At beskrive alle mulige krav i en kravspecifikation gør ikke nødvendigvis en kravspecifikation god.
På en måde skal alle krav linkes tilbage til et behov og et benefit. Det er min erfaring at alt for mange kravspecifikationer er alt for beskrivende af hvordan løsningen i sidste ende skal være i stedet for at beskrive hvilke behov som reelt skal løses. Det hindre arkitekterne og udviklerne i at finde den bedste løsning.

Log ind eller Opret konto for at kommentere