De Organisatorisk Naive Teknologiprojekter

Transkript

1 Peter Madsen Thomas Robert Madsen Anders Bünger Villadsen Morten Warnich-Hansen 3. semester tværfaglig IT & 2. modul Interaktive Medier Roskilde Universitetscenter Efterår 2002 Vejleder Bent Sloth De Organisatorisk Naive Teknologiprojekter tværfaglig IT interaktive medier

2 INDHOLD FORORD PROBLEMFELT PROBLEMFORMULERING: METODE OPGAVENS OPBYGNING UNDERSØGELSESDESIGN DATAINDSAMLING OG TEORETISKE IMPLIKATIONER BEGREBSDEFINITION TEORETISK DISKUSSION AF IT-PROJEKTER IT-PROJEKTER I ET FORANDRINGSPERSPEKTIV Det dominerende perspektiv på forandring Teoretiske alternativer Teknologi og organisation Socio-teknikken SYSTEMUDVIKLINGSMETODERS HISTORIE Metoder indenfor systemudvikling Videnskabens indflydelse på systemudvikling Vandfaldsmodellen ALTERNATIVER I PRAKSIS: PROJEKTLEDELSE OG RISIKOSTYRING Spiralmodellen Risikohåndtering Risikostyring i praksis OPSUMMERING IT-ARKITEKTUR OG INFORMATIONSUDVEKSLING PARADIGMESKIFT I ARKITEKTURMODELLER Flerlagsmodellen Webservices Middleware ÅBNE STANDARDER EN NØDVENDIGHED? Hvad er en standard? REDEGØRELSE FOR DET EMPIRISKE TERRÆN AMANDA Grundlaget Kontrakten indgås Idriftsættelse Ekspertgruppens anbefalinger Organisatoriske og tekniske problemer i AMANDA Det forberedende arbejde Organisering og projektledelse Samarbejde Teknologivalg Hardware og infrastruktur

3 Systemdesign Systemudvikling Effektivitet og Brugervenlighed ELEKTRONISK PATIENTJOURNAL [EPJ] Hvorfor EPJ? Hvad er EPJ? Status for EPJ i Danmark Grundstruktur for EPJ (G-EPJ) Problemorienteret journalisering Ét eller flere EPJ-systemer? Standarder og EPJ DOMÆNE OBJEKT MODEL (DOM) I ÅRHUS AMT Standardiseret udveksling af data (SUP) Distributed Health Environment (DHE) ANALYSE MANGELFULD OG DOMINERENDE ORGANISATIONSOPFATTELSE DÅRLIG PROJEKTORGANISERING MANGELFULD RISIKOVURDERING Risikostyringen i AMANDA Risikostyringen i EPJ UHELDIGE TEKNOLOGIVALG Brugerne med i systemudviklingen KONKLUSION PERSPEKTIVERING LITTERATURLISTE BØGER RAPPORTER, VEJLEDNINGER MV.: ARTIKLER O. LIGN: WWW-KILDER INFORMANTINTERVIEW

4 Forord Baggrunden for dette projekt er utraditionel i den forstand, at det er baseret på to semesterbindinger, hvilket som udgangspunkt giver to forskellige tilgange til projektet. Et forhold vi dog mener, har styrket projektet, idet det har skabt en bredere tilgang til fænomenet, hvilket det empiriske felt også inviterer til. De to semesterbindinger er hhv. TVÆRFAGLIG IT 3. Semesterbinding og Datalogi OB 2. Modul. Den tværfaglige semesterbinding på Tværfaglig IT 3. semester, sigter efter at kombinere IT med et andet fagområde, eksempelvis ved at belyse anvendelsen af IT inden for et udvalgt fagområde. 1. Vi er 2 studerende med denne semesterbinding, begge med en samfundsfaglig uddannelsesbaggrund, der derfor ser dette projekt som et oplagt forsøg på at kombinere datalogiske og samfundsvidenskabelige problemstillinger. Den datalogiske semesterbinding, som den anden halvdel af projektgruppen har arbejdet under, har et mere teknisk sigte, idet kravet til projektets indhold er de systemer af programmel og maskinel som indgår i en moderne computer 2. Et krav der er blevet honoreret gennem fokusering på de tekniske aspekter i problemstillingen. At kombinere de to semesterbindinger, har givet mulighed for en indgående forståelse af en eller flere konkrete teknologier, sammenholdt med et organisationsteoretisk perspektiv, hvilket vi kun anser som en styrke. Dette forhold argumenterer vi med, at problemet, og dermed også svaret, er en kombination og teknologiske og organisatoriske problematikker, hvilket dermed giver mulighed for at nå hele vejen rundt om det empiriske felt

5 1. Problemfelt Udgangspunktet for dette projekt er danske IT-projekter i offentligt regi. Disse projekter synes alle i mere eller mindre grad at stile mod en fælles vision om digital forvaltning. Digital forvaltning skal her forstås som en forbedret og mere effektiv løsning af forvaltningsopgaver gennem anvendelse af informationsteknologi. Ønsket om digitalisering af det offentlige er tæt knyttet til håbet om besparelser. Blandt andet udtrykker et bredt sammensat fagligt udvalg under Finansministeriet håb om store offentlige effektiviseringspotentialer, når/hvis visionerne bliver realiseret: Selv om realisering af det fulde effektiviseringspotentiale ved digital forvaltning forudsætter indfrielse af en række organisatoriske, lovgivningsmæssige og tekniske forudsætninger, vil det også på kort sigt være muligt at høste gevinster, uden at samtlige forudsætninger er opfyldte. 3. Samtidig synes der at eksistere bred politisk enighed om, at disse potentielle gevinster bør og kan realiseres, således at fremtidige samfundsmæssige udfordringer bedre kan imødekommes. Der kan altså konstateres store forhåbninger, høj grad af velvillighed og enighed omkring højere grad af IT-anvendelse i offentligt regi. Overfor den velvillighed og optimisme står de eksisterende erfaringer med offentlige IT-projekter: Mere end hver andet offentlige IT-projekt ender uden resultat. Selv om amter, kommuner og staten har investeret mange skattekroner i ny teknologi, har kun få givet økonomisk gevinst 4. Citatet refererer til endnu ikke udgivne undersøgelser fra Danmarks Statistik (udgives januar 2003) vedrørende den offentlige sektors brug af IT i 2002, som viser at de færreste offentlige virksomheder, har fået et positivt afkast af deres IT-investeringer. IT-projekter der netop har haft som formål at realisere de digitale forhåbninger. Men mod forventning har disse IT-projekter ikke resulteret i offentlige besparelser og strømlinede administrationer. Konsekvensen har derimod ofte været store budgetoverskridelser, frustrerede medarbejdere og utilfredse politikere. Rigsrevisionen gennemførte i 2000 en vurdering af offentlige IT-projekter 5, der viste at 71 % af de 124 IT-projekter i undersøgelsen ikke gennemførtes som planlagt, enten i forhold til projektets tidsmæssige eller økonomiske ramme eller i forhold til det færdige systems funktionalitet. Der synes således umiddelbart at være en påfaldende uoverensstemmelse mellem visionerne for digital forvaltning og de eksisterende erfaringer på området, hvilket i høj grad skyldes skuffende erfaringer med ovenstående IT-projekter. Dette er et førstehåndsindtryk vi gerne vil undersøge nærmere. Derfor vil vi gennem en kombineret teoretisk og case-baseret argumentation og analyse forsøge at nærme os en forklaring på hvorfor problematiske IT-projekter i det offentlige regi er reglen snarere end undtagelsen. Det munder ud i følgende problemformulering: 3 Finansministeriet, Bjerge, Statsrevisoratet,

6 1.1. Problemformulering: Hvorfor har større danske offentlige IT-projekter udviklings og implementeringsvanskeligheder og hvad består vanskelighederne i? Hvilke initiativer vil kunne gennemføres for at give IT-projekter højere succesrate? 5

7 2 Metode 2.1 Opgavens opbygning Læsevejledning Forord Abstract Problemfelt Problemformulering: Metode Hvorfor har større danske offentlige IT-projekter udviklings- og implementeringsvanskeligheder og hvad består vanskelighederne i? Hvilke initiativer vil kunne gennemføres for at give IT-projekter højere succesrate? Teoretisk diskussion af IT-projekter IT-projekter i et forandringsperspektiv Systemudviklingmetodernes udviklingshistorie Alternativ praksis: Projektledelse og risikostyring Redegørelse for det empiriske terræn AMANDA Elektronisk patientjournal [EPJ] IT-arkitektur og informationsudveksling Analyse Der eksisterer en dominerende organisationsopfattelse der er mangelfuld i forhold til forandring, eksempelvis i forbindelse med IT-projekter, hvilket medfører dårlig projektorganisering. Dårlig projektorganisering tager ikke højde for den kompleksitet IT-projekter indebærer, hvilket medfører mangelfuld risikostyring. Mangelfuld risikostyring ignorerer usikkerheden i IT-projekter, hvilket medfører uovervejede og derfor ofte uheldige teknologivalg, som medfører problematiske IT-systemer. Problematiske IT-systemer medfører udvikling af anderledes og mere velegnede tilgange til IT-projekter. Konklusion Perspektivering 6

8 2.2. Undersøgelsesdesign Valget af undersøgelsesdesign bør være dikteret af projektets formål og problemstilling. Spørgsmålet for vores projekts vedkommende er således, hvilken strategi der bedst kan afdække problemformuleringen. Vores tilgang til fænomenet problematiske IT-projekter er baseret på casestudier, som er en kvalitativ metode. Et kvalitativt casestudie er karakteriseret som en empirisk undersøgelse, der belyser et samtidigt fænomen, på baggrund af et relativt lille antal cases 6. Det skyldes hovedsageligt, at vores primære sigte er af forstående karakter, eftersom vi søger en dybere forståelse for vores problemkompleks. Et sigte hvor kvalitative metoder er særligt egnede 7. I denne type design er udvælgelse af cases afgørende for undersøgelsens forklaringskraft, hvilket betyder, at de skal have en fornuftig relation til det undersøgte. På den baggrund har vi valgt at se på AMANDA og Elektroniske Patient Journaler (herefter EPJ). AMANDA er valgt, da dette klassiske tilfælde forekommer illustrativt til belysning af projektemnet. Det skyldes dels, at casen virker så tilpas grel, at de væsentligste pointer fremhæves med al tydelighed, og dels er casen belyst fra så mange forskellige sider, at mange forskellige typer af information er tilgængelig fra pressen og diverse rapporter. Med inddragelse af EPJ bliver undersøgelsesdesignet udvidet til et multipelt casedesign. Begrundelsen for dette er et forsøg på at skabe øget robusthed i det empiriske materiale. Denne robusthed er baseret på en kvalitativ replikationslogik 1, der ikke skal forveksles med en statistisk jo flere jo bedre - logik. Det betyder samtidig, at generaliseringsmulighederne er fokuseret i en analytisk retning, hvilket betyder at vi stræber efter at generalisere vores casebaserede data til en bredere teoretisk sammenhæng. Det er derfor afgørende, at vores cases er formålsbestemte snarere end repræsentative. EPJ er valgt på baggrund af dets forskellighed fra AMANDA. Forskel i kronologi, omfang, organisering, genstandsfelt og fagområde, med hensigt på dannelse af den efterlyste robusthed. Forskelligheden i det empiriske materiale betyder, at generaliseringsmulighederne er øgede idet vi ikke er så sårbare overfor casespecifikke forhold. En anden væsentlig faktor for caseudvælgelse har været deres forklaringskraft i forhold til problemstillingen. Vi stod på et tidligt tidspunkt i projektforløbet med flere cases, som efter nærmere research ikke syntes at bidrage med andet end øget datamængde og de blev derfor fravalgt. Ydermere skal det nævnes, at vi ikke har en anvendt en holistisk tilgang til vores cases, idet vi har valgt ikke at skrive om alle facetter ved vores cases, men omkring aspekter som kan belyse vores problemstilling Dataindsamling og teoretiske implikationer Vi har gennem dataindsamling forsøgt at skabe så stor pålidelighed som mulig i vores empiriske materiale. En pålidelighed der kan opnås ved at indhente forskellige typer af information. Vi har således både primær- og 6 Yin, Andersen, 1998 s. 41 7

9 sekundærdata i form af informantinterview og artikler, bøger, rapporter og andet skriftligt materiale. Tidligt i projektforløbet, afholdt vi et informantinterview med lektor Erik Frøkjær (jf. kap. 9.4), som har deltaget aktivt i debatten om offentlige IT-projekter og i særdeleshed omkring AMANDA. Målet var at få en indledende indføring i hans synsvinkel på problematikkerne i systemudvikling af store offentlige IT-systemer. Derudover besøgte vi Roskilde Amtssygehus, og fik af en overlæge (jf. kap. 9.4), en generel præsentation af brugen af patientjournaler, samt en diskussion af potentialet i en elektronisk udgave af samme. Udgangspunktet for interviewet var en almen indsigt i begrebet patientjournal, der viste sig at være mere detaljeret end vi først havde antaget. Vi fik imidlertid mere ud af besøget på Roskilde Amtssygehus. Vi blev overraskende mødt af en generel skepsis overfor EPJ-projektet og dette gav os et langt mere nuanceret syn på etableringen af EPJ, og forholdet til de klinikere, der skal bruge systemerne, blev sat i perspektiv. Dette perspektiv blev yderligere forstærket under et foredrag af Ole Grünbaum, arrangeret af Gyldendal, som gruppen deltog i. Foredraget blev afholdt i forlængelse af Ole Grünbaums bog Technofetichismen som netop appellerer til et skeptisk perspektiv på IT, frem for den dominerende indstilling om indførsel af IT for teknologiens egen skyld. Vores informantinterview har således været med personer, som besidder et førstehåndskendskab til fænomener vi har været interesseret i at studere. Det har givet os en god indgangsindsigt i nogle af problemfeltets facetter. Som udbygning af det metodiske apparat kunne projektet have inkluderet interviews med implicerede personer, men med i baggrund i det omfattende skriftlige materiale fandt vi ikke anledning til dette. I begge vores to cases har der været store mængder at data på Internettet både i form af pressemateriale og evalueringer, rapporter og lignende publiceret af det offentlige. Formålet med at benytte forskellige typer data er generelt, at øge validiteten af data samlet set. Ved ikke at lægge sig op ad en eller få kilder, sikrer vi større pålidelighed. Dette var også baggrunden for at vi valgte offentlige IT-projekter. Risikoen for at kildematerialet var vanskelig tilgængelig synes mindre i offentligt regi i forhold til privat. Hvad angår projektets teoretiske implikationer, synes fastlæggelse af en teoretisk ramme nødvendig pga. førnævnte analytiske sigte frem for statistisk generalisering. Teorien er modellen som casene skal måles op mod, som gør os i stand til at stille de rigtige spørgsmål. Vi har valgt at tage udgangspunkt i samfundsvidenskabelig organisationsteori, der ikke har rod i et datalogisk problemfelt. Det teoretiske afsæt har derfor været bredt, men bliver forsøgt tilpasset projektemnet. Det brede teoretiske perspektiv er medtaget, idet det bidrager til en bedre forståelse af emnet, end et rendyrket datalogiteoretisk udgangspunkt ville gøre. Vi har dog af omfangsmæssige årsager valgt udelukkende at fokusere på, hvad der kan kaldes sociologisk neoinstitutionalisme, der indebærer fokus på organisationernes interaktion med omgivelserne. Alternative samfundsvidenskabelige tilgange, som f.eks. åbner op for en interessentanalyse, er ikke inkluderet. Et valg der i sidste ende er baseret på hvilken grundlæggende ontologi, man betragter sociale og individuelle aktører på. 8

10 2.4. Begrebsdefinition Som grundlag for problemformuleringen synes det relevant at definere succes- og fiaskokriterier for større IT-projekter. Da vi gerne vil analysere årsagerne til implementeringsvanskelighederne i danske offentlige ITprojekter, er det nødvendigt at anskueliggøre forskellige parametre, der er med til at afgøre, om et IT-system kan karakteriseres som en succes eller en fiasko. Hvad der adskiller et succesfyldt systemudviklingsforløb fra en fiasko, vides ikke helt præcist. Hvis det var så simpelt, ville man hævde, at der allerede burde være udviklet metoder, som kunne tage hånd om alle vanskelighederne, før de udviklede sig. Sådanne metoder findes ikke, på trods af at der har været ihærdige forsøg de sidste 50 år. Ud fra forskellige teoretiske synspunkter 8 ser vi, at årsagerne til fiasko sandsynligvis involverer en eller ofte flere dimensioner; mennesker, processen, projektet og/eller teknologien. At et IT-projekts succes derfor afhænger af flere forskellige variable, er naturligt. I spørgsmålet om definition af succes og fiasko trækker vi delvist på Rigsrevisionen, som i 2000 udarbejdede en rapport om gennemførelsen af statslige edb-projekter. Projekternes grad af succes kategoriseres ud fra hvorvidt de lever op til den økonomiske ramme, den tidsmæssige ramme og i hvor høj grad systemet fungerer efter de oprindeligt fastsatte krav til funktionaliteten 9. Således kan et projekt være udsat for problemer, idet: IT-systemet overskrider markant det originale budget, IT-systemet overskrider markant den originale tidsramme, IT-systemet fungerer ikke, herunder: - IT-systemet fungerer ikke teknisk, - IT-systemet fungerer, men kvaliteten er så ringe at systemet i praksis er uanvendeligt, - IT-systemet fungerer, men bruges ikke fordi brugerne afviser systemet fordi det enten er for besværligt at anvende, eller fordi det ikke tilstrækkelig understøtter deres manuelle arbejdsrutiner, - IT-systemet fungerer, men mangler fuldstændig den lovede funktionalitet, således at det ikke lever op til de formulerede målsætninger/kravspecifikationer, som det var tiltænkt fra starten, af køberen af systemet. Disse kriterier afspejler Rigsrevisionens mål med rapporten en primært økonomisk vurdering af projekterne. De to første kriterier er klare at forholde sig til, og må forventes at kunne indfris af et projekt, uanset hvor det udvikles og til hvem. Derimod synes kriteriet om, at systemet skal leve op til de oprindelige krav til funktionaliteten problematisk. Den løbende udvikling i interne og eksternt givne krav gør, at systemer i langt højere grad skal være så fleksible, at det endelige system og dermed udviklingspro- 8 Lyytinen m.fl., Statsrevisoratet, 2001 afsnit 6 9

11 cessen indarbejder kravene, eller er så fleksibelt, at det kan implementeres senere. Det nytter således ikke noget, at vurdere et system ud fra de krav, der blev stillet til dem, da kravspecifikationen blev defineret muligvis flere år tidligere. Disse krav stilles til projektets endelige produkt, og vurderer som sådan ikke processen, der ligger til grund for projektet, hvilket udgør et afgørende element af projektet. Rigsrevisionen er i sine vurderinger således mere produkt- end procesorienteret, eller lægger i hvert fald ikke op til en vurdering af den systemudviklingsmetode, der ligger bag projektet. Et eksempel på denne problemstilling er, at identifikation af en stram, kontraktstyret systemudvikling, vil betyde at projektet blive evalueret ud fra kriterier om hvorvidt leverandørerne følger kontrakten og i hvor høj grad den bestillende myndighed har kontrol med processen. Vores udgangspunkt vil således lægge sig tæt op ad Rigsrevisionen, men i højere grad være fokuseret på, om systemet lever op til den anvendelse, som det skal udgøre, altså at systemet skal understøtte organisationen bedst muligt i enten nye eller gamle arbejdsprocedurer, og således i højere grad fokusere på processen. For at opnå systemets funktionalitet, er der forskellige kvaliteter som et system bør have: Rette valg af teknologi, som skal understøtte følgende: Effektivitet, herunder: o Brugervenlighed o Ydeevne Fleksibilitet, herunder: o Skalérbarhed o Opgraderingsmuligheder Konsulentfirmaet CSC 10 opstiller en række krav, der bør stilles til såvel særudviklede som semi-generiske systemer. Disse understøtter forsøget på at opnå de ovenstående mål: Simplicitet Åbenhed Tilgængelighed Modularitet Erstattelighed 10 CSC, 2002 s. 26f 10

12 3. Teoretisk diskussion af IT-projekter Formålet med den teoretiske diskussion indeholdt i dette kapitel er, at give en indsigtsfuld synsvinkel på IT-projekter som fænomen, således at det er muligt at danne sig en teoretisk forståelse af empirien. Vi vil diskutere forskellige teoretiske organisationsantagelser og hvilke konsekvenser de har for den videre planlægning og organisering af IT-projekter. Relevansen af denne diskussion baserer sig på en antagelse om, at alle IT-projekter hviler på en form for organisationsteori, hvad enten den er gjort implicit eller eksplicit. Det er vores tese at ved at klargørelse sine teoretiske antagelser fra start, vil man have en bedre mulighed for at udvælge frugtbare systemudviklingsmetoder og projektledelsesformer. IT-projekter med et utilstrækkeligt teoretisk grundlag vil samtidig have tendens til at vælge en organisering der er hæmmende for et succesfyldt IT-projekt. Dermed får vi efterfølgende mulighed for en teoretisk baseret vurdering af konkrete systemudviklingsmetoder og projektledelsesformer, der er blevet anvendt i vores empiri, hvilket giver det teoretiske aspekt en forklaringskraft i forhold til vores problemstilling IT-projekter i et forandringsperspektiv Vi vil i nedenstående betragte IT-projekter som organisatoriske forandringer/reformer. Årsagen til overhovedet at tale om forandringer i forbindelse med IT-projekter skyldes den kendsgerning, at moderne IT-løsninger ikke som tidligere blot indebærer en automatisering, men snarere en reorganisering af arbejdsgange 11. Samtidige er der en erkendelse af, at effektiviseringsgevinster med digitalisering i den offentlige sektor også kræver omlægning af arbejdsgange 12. Derfor vil implementering af ny teknologi i vid udstrækning have karakter af en organisatorisk forandring Det dominerende perspektiv på forandring Det dominerende perspektiv på organisatorisk forandring er det instrumentelle. 13. Det instrumentelle perspektivs dominans tillægges forestillingen om en politisk orden, der gennem en organiserende og ledende rolle kan skabe rammerne for et godt samfund. Det er forankret i en tro på at mennesket kan forme fysiske og sociale omgivelser og derved påvirke samfundets velfærd. Organisationer bliver i dette perspektiv betragtet som rationelle systemer, der er klart adskilt fra omgivelserne og fokuseret i sin virksomhed mod entydige mål, der giver omverden indtryk af en selvstændig og funktionel identitet 14. Selve måludvælgelsen er resultat af ledelsesmæssige overvejelser, hvilket for politiske organisationers vedkommende antages at være utilitaristisk funderet 15. En forudsætning for effektiv forfølgelse af de fastsatte mål er, at koordination og styring af organisationer er muligt, hvilket understreger betydningen af organisationens formelle 11 Andersen m.fl., 1999 s Den Digitale Taskforce, 2002c 13 Scott, 1998 s Brunsson & Olsen, 1993 s Brunsson & Olsen, 1993 s

13 struktur for præstationsniveauet. Det afspejles også i synet på forandring: Thus in a fundamental sense, the organizational structure is viewed as an instrument, that can be modified as necessary to improve performance 16. Dermed understreges atter, at organisatorisk forandring er en bevidst proces, der via rationelle midler kan justere strukturen, så organisationen opnår større nytteværdi. I dette lys bliver IT-projekter en forholdsvis uproblematisk affære, hvor produktudviklingen kan baseres på veldefinerede mål med ubetingede organisatorisk opbakning. Ligesom den instrumentelle/rationelle opfattelse har været dominerende i den generelle opfattelse af organisationer, har den også været det i IT-projekter 17. Denne opfattelse kan forstærkes af, at projekter af den type ofte har haft et teknisk udgangspunkt. Konsekvensen bliver et snævert og forfejlet fokus, der ikke er opmærksom på relevante situationsbetingede faktorer. Dette instrumentelle/rationelle ideal giver et utilstrækkeligt grundlag for IT-projekter, da det baserer sig på en naiv opfattelse af virkeligheden, lyder kritikken. Denne kritik har været udgangspunktet for den fortsatte teoretisering omkring IT-projekter Teoretiske alternativer Det samfundsvidenskabelige bidrag til udvikling af IT-projekter har givet mulighed for bedre forståelse af projekters organisering og ledelse, hvilket har udfordret den instrumentelle tilgang til forståelse af organisationer og projektorganisering. Det betyder bl.a., at projekter ikke længere betragtes som afgrænsede fænomener, men at samspillet mellem projekt og omgivelser pointeres, som værende kritisk for implementeringssuccesen. Dermed er der åbnet op for udvikling af alternative projekttilgange. Et eksempel på en samfundsvidenskabelig teori, der kan bidrage til denne forståelse, er den neoinstitutionelle organisationsteori. For denne teoriretning gælder det overordnet, at organisationer gør en forskel, hvilket indebærer at det er vanskeligt at forudsige, hvordan folk optræder i en organisatorisk kontekst på baggrund af, hvordan de optræder på egen hånd. En sociologisk variant af neoinstitutionalismen antager, at de individuelle aktører handler ud fra en sømmelighedslogik, hvilket betyder, at aktørerne opfører sig afpasset i forhold til omgivelsernes normer og værdier. Det betyder at omgivelserne ikke alene påvirker aktørernes adfærd, men i høj grad også definerer deres virkelighedsopfattelse. Hierarkisk kontrol af individuel adfærd afvises dermed, da begrænsede kognitive ressourcer og den menneskelige natur gør aktørens adfærd uforudsigelig. Det er således ikke muligt at sikre implementering af en reform, eksempelvis i form af et IT-projekt, uden at medinddrage aktørerne, brugerne, og tilrettelægge reformen efter disses virkelighedsopfattelse 16 Scott, 1998 s Christiansen, 2001 s Andersen m.fl., 1986 s

14 Denne tilgang til forståelsen af organisationer betyder ikke at samarbejde og organisationer afvises som sådan, men at forståelsen skal nuanceres i væsentlig højere grad end tidligere. Desuden synes hierarkisk og rationel styring af kollektive enheder som organisationer, urealistisk i situationer med usikkerhed og kompleksitet. Det skyldes, at organisationer ses som komplekse systemer, der skaber organisationsspecifikke værdier og interesser. Derfor bliver organisationens eksistens ofte et mål i sig selv, og den officielle dagsorden har vanskeligt ved at komme til udtryk i organisationens daglige praksis. Endvidere er omgivelsernes betydning for adfærden også gældende for det kollektive niveau, hvor organisationen betragtes som en del af et institutionaliseret miljø og derfor underlagt eksterne normer og forventninger. Ofte vil en reform være initieret af et krav udefra, i form af et direkte pålæg fra en overliggende myndighed eller et generelt pres udefra. Omgivelsernes accept og billigelse bliver en nødvendig betingelse for at skabe en succesfuld organisation. Organisatorisk forandring skal i dette perspektiv ses som interaktion med omgivelserne, og behovet for forandring opstår som resultat af spænd mellem organisationens resultater og omverdens forventninger. En stor del af organisationers berettigelse er betinget af, at de udviser fleksibilitet og handlekraft, hvilket er de egenskaber en reformerende organisation udviser. Omgivelsernes forventninger til organisationen er typisk baseret på de instrumentelle præmisser, da denne form for rationalitet, jf. dets dominans er blevet en væsentlig del af den vestlige kulturs selvforståelse. Reorganisering er samtidig et hyppigt fænomen, hvilket til dels skyldes det institutionaliserede miljø, og dels at offentlige organisationer ofte har indarbejdet en reformrutine til at håndtere de urealistiske forventninger, der med jævne mellemrum optræder i deres politiske miljø. Organisationens primære hensigt med forandring bliver derfor tilfredsstillelse af omgivelsernes krav og derfor er indholdet rettet mod omgivelsernes forventninger. Det betyder, at det konkrete indhold i reformerne ofte er præget af den instrumentelle tankegang hvilket også er en afgørende faktor i forklaring af reformers manglede implementering. Instrumentelle reformer er endvidere præget af et højt ambitionsniveau, og derfor vanskelig at omsætte til handling 19, men deres simplicitet sikrer den vigtige opbakning og legitimitet i og udenfor organisationen. Legitimiteten ligger i den handlekraft og fornyelse som reformen udstråler, men da den legitimerende effekt er uafhængig af faktiske ændringer, er succesparameteret det retoriske aspekt og ikke selve implementeringen. Hvorvidt projektet reelt bliver succesfuldt implementeret, er således i denne sammenhæng af mindre betydning. Det væsentlige for organisationen er at kunne markedsføre sig som moderne, fremadrettet og visionær. Samtidig kan forhold internt i organisationen virke hæmmende for forandringers effekt. En reform der varierer væsentligt i forhold til organisationens gældende værdier, vil støde ind i betydelige barrierer. Hvis reformen er uforenelig med organisationens interne værdier, træder der mekanismer i kraft, så organisationen tækker den offentlige opinion uden at 19 Brunnson & Olsen, 1993 s

15 øve vold på egne normer. Der kan ske en såkaldt afkobling 20, således at reformen ikke får nogen praktiske konsekvenser for organisationens virke. Der er med andre ord tale om en symbolsk handling og vidtgående og intentionelle reformer er derfor nærmest en umulighed. Et IT-projekt der iværksættes på denne baggrund og i praksis vil modarbejde organisationens uformelle struktur, har således dårlige odds. Risikoen for at reformen og dermed IT-projektet vil blive syltet og i værste fald modarbejdet i organisationen, er overhængende. Sammenfattende kan organisatoriske reformer i dette teoretiske lys betragtes som en yderst vanskelig proces som følge af komplicerede ydre og indre omstændigheder. Resultatet bliver ofte derefter. Sammenhængen mellem ændringer og reformers oprindelige hensigt er ofte ringe. Erkendelse af denne kompleksitet og usikkerhed som IT-projekter færdes i skærper kravene til projektorganiseringen og systemudviklingen Teknologi og organisation Implementering og anvendelse af IT i organisationer bliver i ovenstående teoretiske lys en kompleks proces bestående af både tekniske, strukturelle og intra-/interorganisatoriske aspekter. Indførelse af en teknologi kan være udtryk for et politisk valg, der forstærker eller forandrer den eksisterende struktur i den pågældende organisation og/eller omgivelsernes opfattelse af denne. Relationen mellem teknologiske valg og politiske prioriteringer synes endvidere mere markant i dag, da de tekniske muligheder er større end tidligere. Hvad enten man ønsker en mere flad organisationsstruktur og uddelegering af beslutningskompetence eller øget og centraliseret overvågning, kan dette implementeret gennem IT. Harold Leavitts diamantmodel 21 giver udover et systemteoretisk overblik over væsentlige elementer i og omkring en organisation, et systematisk indtryk af teknologiens organisatoriske rolle. Teknologi har i dette perspektiv en determinerende indflydelse på organisationen i samspil med andre faktorer. Der lægges i Leavitts diamant ikke op til et bestemt teoretisk perspektiv. Det står således en frit for, hvilken aktør- og organisationsanskuelse man vil anvende. Alt afhængig af det teoretiske perspektiv vil der blive fokuseret og vægtet forskellige aspekter indenfor organisationen. Modellens vigtigste pointe er den indbyrdes afhængighed ændres en af variablene, vil det påvirke mindst en af de andre uanset om det er intentionen eller ej. Leavitt anskueliggør selv denne interdependens med følgende eksempel: the introduction of new technological tools computers, for example may cause changes in structure (e.g. in the communication system or decision map of the organization), changes in actors (their numbers, skills, attitudes, and activities), and changes in performance or even definition of tasks, since some tasks may 20 Brunnson & Olsen, 1993 s Leavitt,

16 now become feasible of accomplishment for the first time, and others may become un-necessary 22. Figur 1: Leavitts Diamant Organisations mål, som kan være et materielt eller immaterielt produkt, er ifølge Leavitt den vigtigste bestanddel, da det oftest er de øvrige variable, der bliver tilpasset, for at fremme organisationens mål. Deltagerne i organisationen er sociale aktører, der alle har forskellige mål med og behov for, at være en del af en organisation. Uformelle og formelle sociale strukturer er alle adfærdsregulerende. De uformelle strukturer er de værdier og normer som udgør organisationens kultur. Først i det øjeblik strukturerne bliver ekspliciteret, nedfældet på papir, bliver det til formelle adfærdsregulerende strukturer. Teknologi skal i denne forbindelse forstås i en bred forstand og relateres her til det arbejde, som organisationen udfører. Det inkluderer både hardware (maskiner, computer m.m.), som en medarbejder anvender, samt dennes evner og viden til at håndtere og udføre sit arbejde. Teknologier er med til at hjælpe organisationerne til målrealisering, så teknologi bliver derfor en mekanisme, der skal transformere input til output 23. Endelig er der organisationens omgivelser, som danner ressourcegrundlaget. Det er en samlet betegnelse for de mulige udefrakommende påvirkninger en organisation er udsat for, lige fra samfundets love og regler, til konkurrenter på det marked organisationen er en del af Socio-teknikken Socio-teknikken er et eksempel på et teoriapparat, der kombinerer et sociologisk organisationsperspektiv med en systematisk inddragelse af teknologi. Socio-teknikken skal hermed forstås som en generel systemteori. So- 22 Leavitt, 1970 s Scott, 1998 s. 20 og

17 cio-teknikken blev udviklet som et modspil til Taylorismen 24 og dens fokusering på teknologiske løsninger som redskab for udvikling forandring af organisationer. I stedet for udelukkende at fokusere på enten den menneskelige del af organisationen eller den teknologiske, har socio-teknikken fokus på hele organisationen og dens samspil med sine omgivelser. Organisationen betragtes udefra som et åbent system, som skal ses og forstås i samspil med dens relevante omgivelser, og indadtil som bestående af tre delsystemer det teknologiske, det administrative og det sociale delsystem der er gensidigt afhængige af hinanden 25. På samme måde anskuer socio-teknikken en organisation og dens omgivelser (kunder, klienter, leverandører, overordnede myndigheder m.v.) som delsystemer i et større system. Her kan der ligeledes ikke ske ændringer i et delsystem uafhængigt af de andre delsystemer. Derfor kan der ikke foretages organisationsinterne ændringer uden samtidig at medinddrage samspillet med omgivelserne. Det grundlæggende i den socio-tekniske tankegang er, nødvendigheden af samtidige og koordinerede ændringer i de delsystemer, som bliver påvirket af forandringer. Grundlaget er accept og forståelse af den gensidige afhængighed og resultatet skal være med til at styrke såvel de enkelte delsystemers funktion som helhedens funktion 26. Som navnet socio-teknik antyder, var det oprindelige sigte at fokusere på samspillet mellem mennesker og teknologi. Det var blevet klart, at den måde man tidligere tilrettelagde arbejdet og brugte teknologien på, var bestemmende for jobindholdet, ledelses- og samarbejdsformer m.v. Skal man foretage organisationsforandringer, er det derfor nødvendigt med nytænkning inden for alle de nævnte delsystemer. Teorien anskueliggør, at individer og grupper har deres egne behov og værdier, og at disse skal imødekommes, hvis de til gengæld skal være villige til at tilfredsstille organisationens behov. Teknologi er en vigtig variabel i dette netværk af forhold, som både påvirker individets, eller gruppens, evne til at imødese sine egne personlige behov, samt organisationens evne til at interagere succesfuldt med dets miljø. En socio-teknisk inspireret systemudvikler vil således, som udgangspunkt være i stand til at integrere tekniske systemer i sociale omgivelser, da denne er bevidst om, at systemer udvikles i et samspil mellem brugere og udviklere. Mennesker ønsker indflydelse på deres eget liv og derfor også indflydelse på de systemer, der i mange tilfælde kommer til at forandre deres daglige arbejdsrutiner. Det er derfor vigtigt for udvikleren at få brugerne med i udviklings- og beslutningsprocessen for at undgå at brugerne modsætter sig systemet i integrationsfasen og i systemets videre virke. Gode tekniske løsninger er ikke tilstrækkeligt, men skal forankres i organisationen, hvis potentialet skal udnyttes. Socio-tekniske metoder har desuden haft betydning for IT-projekters interne organisering. Relevansen i at op- 24 Begrebet Taylorisme stammer fra den nordamerikanske ingeniør Frederick Winslow Taylor, som bl.a. ud udgav bogen The principles of Scientific Management i Thompson & McHugh, 1995 s Thompson & McHugh, 1995 s

18 dele IT-projekter i en teknisk søgen efter løsninger og en organisatorisk søgning efter forudsætninger er blevet understreget Systemudviklingsmetoders historie Som tidligere nævnt har det instrumentelle perspektiv haft en dominerende status i synet på organisationer, hvilket også har haft konsekvenser for synet på systemudvikling gennem tiderne. Systemudviklingsmetoder deler mange karakteristika med designmetoder inden for andre videnskabelige grene. De forskellige metoder der anvendes i dag inden for systemudvikling, kan direkte relateres tilbage til de traditionelle designfilosofier, som igen er baseret på mere generelle filosofiske retninger indenfor samfundsvidenskaben samt natur- og humanvidenskaberne 28. Vi vil i nedenstående beskrivelse tage udgangspunkt i nogle af de grundlæggende betragtninger, inspireret af samfundsvidenskaben. I løbet af 50 erne og 60 erne steg kravene til udvikling af komplekse computersystemer kraftigt til stor frustration for datidens systemudviklere, og udtrykket software krise blev således for første gang diskuteret offentligt på NATOs videnskabelige konference i Alt for ofte skete det, at computerindustrien ikke kunne levere software der virkede, eller til den rette tid eller sågar indenfor de aftalte budgetrammer. På konferencen besluttede forskerne, at der måtte ske en fundamental udvikling af de metoder, man udviklede software efter, og et generelt tema var bl.a., at man ville eliminere den ad hoc-baserede tilgang til systemudvikling. I stedet skulle softwareudviklingsmetoderne baseres på systematiske principper inspireret af naturvidenskaberne og især matematikken, hvilket reelt skabte forskningsfeltet systemudvikling. De matematiske inspirationer ses ved, at mange systemudviklingsmetoder ofte er meget strukturerede, baseret på formalisme og byggende på reduktionistiske principper, hvilket indebærer, at virkeligheden i bund og grund er enkel, og at mennesker alene i kraft af deres intellekt og sanseapparater i sidste ende til fulde vil kunne forstå naturen af og oprindelsen til alle fænomener i universet. Dette skal forstås i en generel systemteoretisk retning (jf. nedenstående afsnit om systemudviklingsmetoder), således at det angiver at ethvert system er sammensat af enkeltdele, såvel fysiske, politiske, sociale og ITsystemer, der alle består af mindre dele. Reduktionisme består i denne henseende af at beskrive disse mindre dele på en sådan måde, at det kan skabe grundlaget for en fuldstændig forklaring af systemets opførsel. I dag, 30 år efter NATO-konferencen, er behovet for større, stabile og komplekse softwaresystemer, der leveres til tiden og indenfor budgettet fortsat aktuel. Som vi indledningsvis har skitseret, bliver synes disse krav ikke altid at blive honoreret og det er primært ift. faktorerne tid, økonomi og funktionalitet, at de store systemer som bliver udviklet stadig fejler. Naturligvis har softwareindustriens kompetencer til at honorere de stadig større krav udviklet sig, og nutidens krav til IT-systemer er større og mere komplekse end i 1960 erne. Men moderne systemudviklingsmetoder har 27 Christiansen 2001 s Ullman, 1991 s Quintas, 1994 s

19 ikke været i stand til at imødekomme kravene om mere komplekse systemer. Spørgsmålet fra konferencen i 1968 hvordan kan vi blive bedre til at skabe bedre systemer synes mere relevant end nogensinde Metoder indenfor systemudvikling Flere af de metoder vi i det efterfølgende vil behandle, har en systemteoretis1k tankegang som fundament. Systemteori skal ikke opfattes som en teori i traditionel forstand eller repræsentere en egentlig metode, men derimod vise en tankegang et perspektiv jf. Leavitts model. Systemteori kan dog i dette lys bidrage til at forstå, hvorledes organisationer virker, idet den gør det muligt at fremstille organisationsteorien som et integreret hele, frem for løsrevne dele. Det skal derfor ses som et system, der udfører en funktion i sammenspil med andre systemer 30. Generel systemteori kan, som begrebet antyder, anvendes overalt, hvor der findes systemer. Systemer defineres indenfor den generelle systemteori, oftest som bestående af en række dele, der gensidigt påvirker hinandens adfærd. I forhold til softwareudvikling er et system en samling af sammenhængende komponenter, der er designet for at opnå et bestemt mål. Systemteori hænger derfor sammen med systemudviklingsteorier og systemudviklingsmetoder. Men det synes vigtigt, at der sondres mellem begreberne systemudviklingsteorier og systemudviklingsmetoder, da teorier omkring systemudvikling, som tidligere antydet, primært skal give systemudvikleren en forståelse af de forhold, der sætter rammen for et ITprojektudviklingsforløb. Systemudviklingsmetoder derimod, er et instrument, der bygger på en eller flere teoretiske grundantagelser og som sådan er mere handlingsorienterede 31. Vi mener at systemudvikling rummer tre forskellige niveauer: en filosofisk grundantagelse, en teoretisk ramme byggende på de filosofiske grundantagelser, samt en metode der holder sig inden for den teoretiske ramme Videnskabens indflydelse på systemudvikling Hele feltet indenfor systemudvikling var i 1960 erne kraftigt påvirket af filosofier indenfor videnskaben, især Descartes rationalisme. Den videnskabelige undersøgelsesmetode opfattes således deduktivistisk. Descartes var af den opfattelse, at alt, hvad den menneskelige erkendelse magter, hænger sammen på én og samme måde. Descartes fandt det sikre grundlag for menneskelig erkendelse i en rationel selvindsigt: i selvindlysende eller uafviselige sandheder, som er tilgængelige for enhver, der blot giver sig tid til at tænke sig om. Denne tanke om enhedsvidenskab og reduktionisme fik mange filosofiske efterfølgere 32. Fokus i systemudvikling var på det tidspunkt, at udvikle hardware samt forfine matematiske algoritmer: Det gav mening, at bruge udviklingsmetoder bygget på analytisk tænkning, når der skulle designes computersystemer 33. Selv i dag er der stadig en stærk forestilling om, at efter- 30 Blegen & Nyhelm, 1979 s Andersen m.fl., 1986 s Gaarder, 1997 s Gries, 1981 og Dijkstra,

20 som computere grundlæggende er matematisk-logiske maskiner på laveste niveau, så skal design af softwareprogrammering af samme, ligeledes foregå strengt taget bygget på matematik og logik. Vi vil indledningsvis beskrive to grundlæggende forskellige paradigmer indenfor systemudvikling; den konstruktionsmæssige tilgang og den evolutionære tilgang. Den konstruktionsmæssige tilgang er den tilgang der har været den mest dominerende indenfor softwareudvikling, bl.a. igennem vandfaldsmodellen (jf. nærmere beskrivelse af modellen nedenfor og ovenstående) 34. Den evolutionære tilgang er først for alvor ved at blive forankret i især nyere systemudviklingsmetoder, der indeholder iterative forløb. Når man vælger at udvikle systemer ud fra en konstruktionsmæssig tilgang er den fundamentale antagelse, at systemudvikling er en rationel proces. Udvikleren sidder som eksperten og analyserer sig frem til den mest optimale løsningsmodel til et givent problem for at økonomisere med sine ressourcer. Konstruktionsmetoden analyserer problemområdet grundigt således, at problemet er veldefineret i en grad, at det kun kan tolkes på én måde. Herefter bliver det struktureret i stadig mindre delproblemer. Man følger typisk lineære udviklingsmodeller hvor aktiviteterne i processen er givet trin for trin. Denne konstruktionsmæssige tilgang er kraftigt inspireret af naturvidenskaberne. Som udvikler i et evolutionært udviklingsforløb, sætter man sig derimod ikke ned og analyserer sig rationelt frem til en fuldstændig forståelse af et givent problem. I stedet tager man hånd om usikkerheder ved at identificere og eksperimentere med forskellige alternative løsningsmodeller til problemet. I stedet for at inddele og forædle problemet benytter man trial and error -tilgang og får således et fungerende system tidligt i udviklingsprocessen. Man ser problemet som værende levende, og grundlaget for systemet dynamisk så det løbende tilpasses omgivelserne, i et evolutionært udviklingsforløb bliver brugere involveret i processen, ikke kun til udformningen af kravspecifikationen, men også til evaluering af designforslag og prototyper. De er i høj grad med til at tage beslutninger i forhold til problemformuleringen og kvaliteten af det producerede system. Systemudvikleren er den tekniske og kommunikative ekspert, som foreslår og udvikler tekniske løsninger. De mest optimale løsninger udvælges gennem kommunikation og interaktion med brugerne. Det evolutionære forløb er kraftigt inspireret af human- og samfundsvidenskaberne herunder etnografi og organisationsteori. Selvom de to paradigmer er forskellige, kan de sagtens fungere som supplerende tilgange til systemudvikling. 35 Hvis man tager udgangspunkt i en rationel proces, med abstraktion og dekomposition, og dermed stoler på en simplificeret verden, introduceres nye usikkerheder, da systemet ikke nødvendigvis bliver udviklet i overensstemmelse med den komplekse, virkelige verden. Tilsvarende, hvis man tager udgangspunkt i en eksperimentel proces, produceres ny information i løbet af processen, og derigennem introduceres mere kompleksitet og der er risiko for at systemet aldrig bli- 34 Royce, Stage, 1995 s

21 ver klar. Kompleksitet og usikkerhed er forbundne aspekter i problemløsningssituationer. Benytter man udelukkende det ene paradigme, vil det ske på bekostning af det andet. Vi vil i det næste afsnit forklare konkrete udvalgte systemudviklingsmetoder som dels giver et overblik over systemudvikling generelt, og dels illustrerer hvilket paradigme det er inspireret af. Samtidig vil det også fremgå af gennemgangen at de forskellige systemudviklingsmetoder er inspireret af hinanden på forskellig vis Vandfaldsmodellen Den mest kendte reference for softwareudviklingsmetoder er vandfaldsmodellen 36. Den klassiske vandfaldsmodel er et godt eksempel på en metode, der er udviklet i tråd med den klassiske videnskabelige metode og logiske deduktion. Der deduceres frem til den endelig løsning, hvor man via en faseinddelt strategi når sit mål. Royce beskrev ikke selv modellen som et vandfald, men hans metode blev senere kendt som vandfaldsmodellen pga. layoutet af kasserne i hans diagram, som lignede sten i et vandfald.. Vandfaldsmodellen er en udviklingsmetode som er lineær og sekventiel. Modellen bygger på metaforen fra et vandfald, der falder fra en klippe. Når først vandet ryger ud over en klippekant og falder nedad, er det ikke muligt at stoppe. Overført til systemudviklingsmetoden som består af en række faser, kan man ikke returnere til den forrige fase. Figur 2: Vandfaldsmodellen Den bærende ide i vandfaldsmodellen er, at den samlede udviklingsproces opdeles i en række adskilte og sekventielt ordnede faser. Faserne afspejler en (logisk) orden i udviklingsprocessen: Først undersøges problemet og kravene til en løsning formuleres; dernæst laves et design, der omsættes til et program osv. Resultatet af en fase er input til de(n) efterfølgende fase(r). 36 Royce,

22 Resultatet af en fase skal godkendes, inden den næste fase sættes i gang. Når en fase er afsluttet, er alle de dertil hørende aktiviteter også afsluttet; dvs. at alle krav f.eks. er fundet og beskrevet, når kravspecifikationsfasen er afsluttet. Hvis det senere i forløbet bliver nødvendigt at ændre resultatet af en fase (tilbageløb) skal den pågældende fase genåbnes, dens resultater ændres og konsekvenserne af rettelserne indarbejdes i de efterfølgende faser. Der er udviklet forskellige varianter af vandfaldsmodellen siden Royces udgave, hvoraf de fleste adskiller sig med hensyn til antallet og navnene på faserne, mens de underliggende principper er fælles. Modellen har siden sin introduktion været den dominerende reference for udviklingsmodeller. Det skyldes dels, at den er enkel at implementere, dels at dens struktur afspejler en intuitivt korrekt tilgang til udvikling af edb-systemer, hvor analyse og design går forud for konstruktion og test. På denne måde sikres i teorien en velordnet proces og et sammenhængende, komplet og robust edb-system. Vandfaldsmodellen har imidlertid vist sig ikke at fungere så godt som forventet i praksis, hvilket viser sig i overskridelser af tids- og ressourcebudgetter, uoverensstemmelser mellem det færdige system og brugernes forventninger/behov, pres på test- og integrationsfaserne på grund af akkumulerede forsinkelser og fordi hele systemet skal testes og integreres på én gang m.v.. I litteraturen diskuteres mange af de mulige årsager hertil 37. Men grundlæggende går kritikken på både følgende: Risici knyttet til krav og domæneforståelse: det er i praksis vanskeligt at beskrive samtlige krav til et nyt system på et tidligt tidspunkt. Det har også vist sig, at traditionelle kravspecifikationer er et utilstrækkeligt grundlag til at sikre, at systemet kommer til at svare til kundernes/brugernes behov og forventninger; og undgå misforståelser og fejltagelser i det senere forløb. De tekniske risici i systemudvikling benyttes ofte nye teknologier og værktøjer og der kan derfor opstå uforudsete tekniske problemer i både design- og programmeringsfaserne. Vandfaldsmodellen er ikke velegnet til at håndtere disse risici: For det første kan manglende eller misforståede krav ofte først konstateres, når man kan demonstrere en nogenlunde stabil version af et kørende system. Det kan man i vandfaldsmodellen først på et meget sent tidspunkt (i integrations- og testfasen). For det andet er det svært at forudsige omfanget af design- og programmeringsaktiviteterne uden at prøve kræfter med udviklingsværktøjerne, eller udarbejde forskellige løsningsalternativer. Dette er i vandfaldsmodellen ikke tilladt før i design- og konstruktionsfaserne (igen en direkte henvisning til konstruktionsparadigmet), hvilket afspejler en instrumentel-rationel tankegang. Konsekvensen er, at man i vandfaldsmodellen planlægger og estimerer på et i praksis usikkert grundlag hvor mange problemer først opdages på et sent tidspunkt, hvor de er svære at rette. Selvom vandfaldsmodellen har været meget kritiseret, har den dannet grundlag indenfor moderne systemudvikling. Enten i form af andres vide- 37 Boehm, 1988 og Sommerville,