Jeg har heri starten af året været på konference hvor jeg har præsenteret en artikel om projektledelsesstrategier. Artiklen opstille et framework for projektledelsesstrategier, som er udledt på baggrund af et eksperimenterende prototype projekt i det danske sundhedsvæsen. Frameworket bygge på projektledelsestrekanten tre styringsmekanismer. Tid, ressourcer og mål/omfang. Artiklen behandler også et af projekledrens sværeste opgaver, nemlig det at nedlægge et projekt før tid og før end at målet er nået. Ofte ses det at projekter som egentlig er løbet løbsk (dvs. det forventede outcome er mindre end det man har lagt i projektet af påenge og ressourcer) ikke bliver stoppet, men i stedet søgt gennemført ved tilførelse af flere ressourcer og mere tid - også kaldet 'escalation' eller 'escalation theory'. Der er to faktorer der kan forklare denne adfærd. Den føste er 'sunken cost' - jo flere penge man allerede har puttet i projektet, jo sværere har man ved at stoppe det og giver gerne lidt flere penge...og lidt til. Nr. to er 'completion effect' - at jo tættere man tror, man er på målet jo mere villig er man itl at fortsætte og kaste flere resourcer og penge i projektet.
Ved prototype projekter og andre eksperimenterende iterative projekter kan det være svært faktisk at finde ud af hvor tæt eller alngt fra målet man egentlig er. Da målet ofte er uklart og kun defineret fra iteration til iteration - eller at projektet er sat i søen for at definere målet. Her kunne man bruge formative effektevaluering, ikke til at forholde sig til det (uklare) overordnede mål, men til at se om man opnåede noget ved hver iteration som er ønskværdig på det stadie i projektet.
Eskalering bliver ofte omtalt negativt, men nogle gange kan det være positivt. Det forventet outcome er beregnet udfra forventninger man havde ved projekt start. Der er der hvor man ved mindst og der er i teorien ikke taget højde for at man bliver klogere undervejs og korrigere projektet hvorved man har mulighed for at opnå et bedre outcome end forventet. OG vhis det er tilfælde kan det godt betale sig at bruge ekstra ressourcer på projektet i det omfang at ressourcer ind ikke overskrider de nye justeret outcome.
Artiklen er skrevet sammen med professor Jan Pries-Heje og Professor Richard Baskerville . HER følger artiklens resume:
Prototyping is often presented as a universal solution to many intractable information systems project problems. Prototyping is known to offer at least three advantages (1) provide users with a concrete understanding, (2) eliminate the confusion, (3) cope with uncertainty. On the other hand, managing the explorative and iterative aspects of prototyping projects is not a trivial task. We examine the managerial challenges in a small scale prototyping project in the Danish healthcare sector where a prototype breakdown and project escalation occurs. From this study we derive a framework of strategies for coping with escalation in troubled prototyping projects; the framework is based on project management triangle theory and is useful when considering how to manage prototype breakdown and escalation. All strategies were applied in the project case at different points in time. The strategies led to partial recovery of the project but not until several coping strategies had been tried.
Referencer til projekt eskalering:
M. Keil, J. Mann, and A. Rai, "Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models." vol. 24: Management Information Systems Research Center, University of Minnesota, 2000, pp. 631-664.
M. Keil and J. Flatto, "Information systems project escalation: a reinterpretation based on options theory," Accounting, Management and Information Technologies, vol. 9, pp. 115-139, 1999
Ingen kommentarer:
Send en kommentar