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