Prosjektledelse Prosjektledelse nr. 2 2020 | Page 23

DEBATT
På samme måde kan man definere en IT-katas- Man kan fx ikke se hvem der skal bruge det nye
trofe som et projekt der har væsentlige "skader" system, hvornår og til hvad.
på leveringstid og/eller kundens udgifter, den Ofte har projektledelsen aldrig stillet sig selv det
forretningsmæssige værdi, brugertilfredsheden, spørgsmål. I stedet beskriver man - ofte i detaljer
leverandørens udgifter, eller hvor det aldrig blev - hvad systemet skal gøre. Det er ikke så smart,
afklaret om projektet var realiserbart. for leverandøren har måske en bedre løsning, der
gør tingene på en anden måde end den kunden
De 5 projekter har meget forskellige skadesmøn-
har beskrevet.
stre. Fx har EPIC (som det eneste) hverken skade
på tid eller kundens udgifter. Til gengæld er der En grunn som ikke er nevnt ovenfor og ser ut til
store skader på brugertilfredsheden. For PolSag å ligge utenfor horisonten er stakeholderanalyse.
og EFI blev det aldrig afklaret om de kunne reali- Den ville antakeligvis avslørt svakheter ved alle
seres. Dog kørte halvdelen af EFI i flere år. prosjektene.
Hvorfor skete disse skader så? Vi fundet frem til Så har vi det britiske NPfIT med tosifret milli-
36 skadesårsager. Hvert projekt er ramt af mellem ardtap – i pund. Det var til helseadministrasjon,
13 og 17 af årsagerne. De optræder i forskellige men man tok seg ikke tid til å spørre legene hva
mønstre i de 5 projekter. de hadde behov for.
Lad os se på nogle af de hyppige årsager i de 5
projekter: En annen metode er å utvikle enkle prototyper,
Årsag A1: Kunden identificerer ikke brugernes det ville trolig avslørt svakheter ved alle de fem
behov (ramte alle 5 projekter). Behovene burde danske prosjektene.
fremgå af den kravspecifikation kunden og leve-
randøren skriver under på, men det gør de ikke.
Mer generelt for et stort og viktig dataprosjekt
PROSJEKTLEDELSE • NR. 2 2020 23