bibliotek.dk Projekt af 22 november 2000 IT-projektledelse IT-højskolen i København

bibliotek.dk Projekt af Niels Erik Gilvad Jacob W. Jespersen Morten Primdahl Thomas Berg von Linde Vejleder: Sten Mogensen 22 november 2000 IT-projektledelse IT-højskolen i København

Citat på forsiden stammer fra Per Mogens Pedersen, Dansk BiblioteksCenter, og henviser til tidspunktet hvor Jens Thorhauge, Direktør Biblioteksstyrelsen, kontaktede Per for få ham til at give et bud på hvordan bibliotek.dk kunne realiseres.

Indholdsfortegnelse Indholdsfortegnelse FORORD V KAPITEL 1 INDLEDNING 7 1.1 Problemformulering 7 1.2 Metode 8 KAPITEL 2 PROJEKTET 9 2.1 Historien om projektet 9 2.2 Projektets organisering 11 KAPITEL 3 INTERESSENTANALYSE 15 3.1 Interessenterne i bibliotek.dk. 15 3.2 Interessekonflikter 23 3.3 Interessenternes indflydelse 25 3.4 Interessenternes holdning til resultatet 26 KAPITEL 4 PROJEKTFORLØBET 27 4.1 Projektforløbet - årsager og konsekvenser 27 4.2 Første del 28 4.3 Anden del 32 KAPITEL 5 KONKLUSION 39 iii

bibliotek.dk EFTERSKRIFT 42 LITTERATURLISTE 43 Referater 43 Litteratur 43 Artikler 44 APPENDIKS 45 Appendiks A - Forkortelser 45 Appendiks B - Tidslinie 46 Appendiks C - Referat fra møde med Per M. Pedersen 47 Appendiks D - Referat fra møde med Leif Andresen 51 Appendiks E - Referat fra møde med Bo Weyman 57 Appendiks F - Referat af møde med Dansk Blindebibliotek 62 iv

Forord Forord Denne rapport er lavet i forbindelse med kurset IT-projektledelse på IThøjskolen i København. Den omhandler projektet bag bibliotek.dk. Vi har i den forbindelse interviewet en del af de personer der har været involverede i projektet, og vi vil gerne sige tak til Per Mogens Pedersen, Leif Andresen, Bo Weyman og Dansk Blindebibliotek for at have taget sig tid til at tale med os. København 22. november 2000 Niels Erik Gilvad Jacob W. Jespersen Morten Primdahl Thomas Berg von Linde v

bibliotek.dk vi

Kapitel 1 Indledning Kapitel 1 Indledning bibliotek.dk er en portal på Internettet, der giver adgang til at søge i alle de materialer, der findes på offentlige biblioteker i Danmark. Tillige er det muligt at bestille materialerne, som så kan hentes på éns eget bibliotek. Vi fik kontakt til Dansk BiblioteksCenter (DBC), der er ejere og udviklere af bibliotek.dk, og Biblioteksstyrelsen (BS) som er den myndighed, der bestilte udviklingen af bibliotek.dk hos DBC. Efter at have talt med BS og DBC blev det hurtigt klart, at den vinkel vi ville analysere projektet ud fra, skulle være en interessentanalyse. Dette er primært begrundet i, at projektet er atypisk i forhold til normale projekter, fordi DBC (som udviklerorganisation) og BS (som kunde) i forvejen er bundet sammen gennem en række andre projekter og aftaler. De har derfor på forhånd et godt kendskab til hinanden, hvilket har betydet, at projektet er gennemført i en uformel ånd. Vi vil starte med at give et overblik over projektet, for derefter gennem interessentanalysen at beskrive de involverede interessenter og deres succeskriterier, for til sidst, på baggrund af interessentanalysen og teori om ITprojektledelse, at vurdere projektforløbet. 1.1 Problemformulering Projektet bibliotek.dk har til formål at gøre bibliotekernes emne-database DanBib tilgængelig for offentligheden via Internet. Leverandøren i projektet er Dansk Bibliotekscenter; kunden er Biblioteksstyrelsen. Projektet gik i luften d. 31 oktober d.å. Indledningsvist erfarede vi, at der: ikke er underskrevet en kontrakt om udviklingsprojektet, ikke foreligger en sammenhængende formel kravspecifikation, ikke er blevet anvendt nogen formel projektstyringsmetode. Vi ønsker på baggrund af en interessentanalyse at undersøge om projektet er forløbet tilfredsstillende, og at vurdere årsager til og konsekvenser af den tilsyneladende mangel på formel styring af projektet. 7

bibliotek.dk 1.2 Metode Vi har gennem interviews 1 med projektets nøglepersoner indsamlet den primære empiri, der ligger til grund for analyse og undersøgelse, og vi baserer vores rapport alene på disse interviews samt på offentligt tilgængelige artikler om bibliotek.dk. Vi har brugt teori-modeller fra [Vinje, 1997] til at strukturere vores undersøgelse, som er delt i to dele: en interessentanalyse og en vurdering af projektets forløb. Ifølge [Vinje, 1997] er en interessentanalyse en undersøgelse og beskrivelse af: De involverede parter i projektet, Parternes indbyrdes relationer, Parternes individuelle interesser og succeskriterier i.f.t. projektet. På baggrund af interessentanalysen vil vi beskrive hvilke faktorer, der har haft betydning for projektets udformning og planlægning i definitionsfasen og siden dets udførelse i produktionsfasen. Derudover vil vi beskrive årsagerne til den måde projektet er styret på, samt hvilke konsekvenser det kan have på projektforløbet og dets udkomme. 1 Referater fra disse ligger i appendiks. 8

Kapitel 2 Projektet Kapitel 2 Projektet Vi vil i dette kapitel skabe et overblik over projektet. Dette gør vi ved først at beskrive projektforløbet, og derefter kort at præsentere projektets interessenter og deres indbyrdes organisering. I Appendiks B har vi vedlagt en tidslinie, der viser projektets forløb. 2.1 Historien om projektet Projektet startede i efteråret 1998, hvor kulturministeren holdt en tale ved Kommunernes Landsforenings bibliotekskongres. Her fremsatte hun et ønske om, at der skulle være offentlig adgang til DanBib. DanBib er: En database over al litteratur, musik, videoer, multimedier, elektroniske dokumenter etc., der kan lånes på eller fremskaffes gennem biblioteket [NfN nr. 4, 12/1998]. Projektet startede med titlen DanBib for folket eller DanBib for alle, og formålet var at åbne DanBib for almindelige brugere, samt at gøre det muligt for brugerne at bestille materialerne hjemmefra og hente dem på det nærmeste folkebibliotek. I resten af rapporten vil vi referere til projektet ved det navn, der bliver brugt nu: bibliotek.dk. Det var BS, som hører under kulturministeriet og er det øverste organ for de offentlige biblioteker i Danmark, der startede projektet op efter kulturministerens tale. I første omgang bad de DBC, repræsenteret ved Per Mogens Pedersen (PMP), at give et bud på, hvordan kulturministerens ønske kunne føres ud i livet. Valget af DBC er begrundet ved, at det er DBC, der har driften på DanBib. PMP forfattede herefter en artikel [NfN nr. 4, 12/1998], hvor han trak linjerne op til, hvordan kulturministerens ideer ville kunne udføres og herved også første udkast til rammerne for projektet. DBC og BS nedsatte derpå en arbejdsgruppe, der fik ansvaret for at udrede de praktiske forudsætninger for projektet, herunder opstille en slags kravspecifikation for systemet [NfN nr. 1, 3/1999]. BS tog også initiativ til en række åbne debatmøder i juni 1999, hvor ansatte på bibliotekerne blev indbudt til at komme for at høre om og diskutere projektet. Arbejdsgruppen startede med at arrangere et temamøde i starten af 1999, hvor deltagerne, 9

bibliotek.dk bl.a. repræsentanter fra lignende projekter i Norge og Sverige, diskuterede realiseringen af bibliotek.dk. Processen med at fastlægge specifikationerne i arbejdsgruppen løb over resten af 1999. Sideløbende hermed starter udviklingen af systemet hos DBC. I foråret 2000 starter integrationstest af hardware, der afslører at hardwaren ikke lever op til de krav, der er sat til det. Dette medførte, at projektet blev forsinket, mens DBC og de involverede hardware-leverandører arbejdede på at finde en løsning på problemerne. Bl.a. var hardwaren ikke certificeret, hvilket skete på DBC initiativ i juli 2000. En anden faktor der var med til at forsinke projektet var, at vedtagelsen af den nye bibliotekslov blev forsinket til først i maj 2000. Loven indeholdt et afsnit om bibliotek.dk, hvor der bl.a. blev bevilget 35 mio. kr. over 4 år til udvikling og drift af bibliotek.dk. Medio 2000 gennemgik DBC en organisationsændring, som har medført en opsplitning af det samlede ansvar, i store træk således: bibliotek.dk blev som udviklingsprojekt forankret i Netdivisionen med PMP som projektleder. Udviklingsressourcer til projektet kom primært fra IT-afdelingen (IT-chef Bo Weymann), Servicedivisionen (sektionsleder Kirsten Larsen) og Netdivisionen [ref. PMP, 09/2000]. Efter at performance testene var vel overstået, blev bibliotek.dk indviet den 31. oktober 2000 af kulturministeren og ringen var dermed sluttet. 10

Kapitel 2 Projektet 2.2 Projektets organisering Organisationen omkring bibliotek.dk er skitseret på Figur 1. De interessenter der er taget med på figuren, er de der har været aktivt involverede i udviklingen af projektet, f.eks. er bibliotekerne indirekte repræsenteret igennem BS, som per definition varetager deres interesse i dette projekt. Kulturminister Biblioteksstyrelsen Arbejdsgruppen Eksterne konsulenter Dansk BiblioteksCenter Eksterne leverandører Figur 1: Organisationen omkring bibliotek.dk. 2.2.1 Kulturministeren Kulturminister Elsebeth Gerner-Nielsen er den officielle opdragsgiver, og det er på hendes foranledning, at bibliotek.dk kommer på finansloven. 11

bibliotek.dk 2.2.2 Biblioteksstyrelsen BS er en styrelse under Kulturministeriet og dermed ministeriets sagkyndige organ for hele det offentlige biblioteksvæsen. BS er det statslige centralorgan på biblioteksområdet og regeringens rådgiver i alle spørgsmål vedrørende folke- og forskningsbiblioteker. Styrelsen har bl.a. til opgave at administrere Lov om Folkebiblioteker og Lov om Biblioteksafgift. BS væsentligste interessenter er et offentligt biblioteksvæsen med et ressourceforbrug på ca. 3,0 mia. årligt, fordelt på en række nationale institutioner, en række større og mindre forsknings- og uddannelsesbiblioteker, samt kommunale folkebiblioteker, i alt omkring 2000 enheder. Se mere på http://www.bs.dk. 2.2.3 Dansk BiblioteksCenter DBC leverer bibliografiske data, bibliotekssystemer, netydelser og rådgivning til de danske biblioteker. DBC er et aktieselskab med en omsætning på ca. 110 mio. kr. Aktierne er fordelt på 4 ejere: Kommunernes Landsforening (46 %) Staten (29 %) Gyldendal (14%) Københavns Kommune (11 %) Se mere på http://www.dbc.dk DBC dannede en intern styregruppe med PMP som leder, og med deltagelse af projektlederne for de 10 delprojekter, som bibliotek.dk blev delt op i. Blandt de 10 delprojekter findes: databaseopgave brugergrænseflader hardware servicedeklarationer (vedr. bibliotekerne) 12

Kapitel 2 Projektet 2.2.4 Arbejdsgruppen Arbejdsgruppen blev dannet af Biblioteksstyrelsen til at stå for opstille kravene til bibliotek.dk, og bestod i grove træk af repræsentanter fra ejerkredsen bag DanBib, bortset fra Gyldendal. Arbejdsgruppen havde følgende medlemmer: Leif Andresen, Biblioteksstyrelsen Lone Hansen, Biblioteksstyrelsen Inger Larsen, Kommunernes Landsforening Irene Ludvigsen, Københavns Kommune Per Mogens Petersen, Dansk BiblioteksCenter Kirsten Waneck, Dansk BiblioteksCenter 2.2.5 Eksterne konsulenter Dansk Blindebibliotek har virket som konsulenter for BS i forbindelse med designet af brugergrænsefladen til bibliotek.dk. Blindebiblioteket er et offentligt, landsdækkende bibliotek, der producerer og udlåner bøger, aviser og tidsskrifter på lydbånd, i punktskrift og på e-tekst til blinde, svagtseende og andre, der på grund af handicap er ude af stand til at læse trykt tekst. Se mere på http://www.dbb.dk. Endvidere har andre repræsentanter for svagtseende været tilknyttet som konsulenter. 2.2.6 Eksterne leverandører DBC har brugt et antal underleverandører til specialiserede hard- og software opgaver: Index Data (søgemaskine) ICL og Hitachi (hardware) Netbureauet Araneum (design) 13

bibliotek.dk 2.2.7 Bibliotekerne Bibliotekerne i Danmark kan groft opdeles i 2 kategorier: folkebiblioteker og forskningsbiblioteker. Forskningsbibliotekerne ejes af staten og har pligt til at indberette deres materialebeholdning til DBC (DanBib). Folkebibliotekerne er ejet af de enkelte kommuner og har ikke pligt til at indberette til DBC, men gør det hovedsageligt alligevel. Ud over disse har enkelte store virksomheder også et bibliotek. 14

Kapitel 3 Interessentanalyse Kapitel 3 Interessentanalyse 3.1 Interessenterne i bibliotek.dk. Poul Staal Vinje beskriver i [Vinje, 1997], hvordan interessentanalysen indgår i projektlederens værktøjskasse. Opgaven er at finde interessenterne, dokumentere succeskriterier og de deraf afledte krav, og at identificere interessekonflikter. Poul Staal Vinje definerer interessenterne som de personer, organisatoriske enheder, underleverandører og institutioner der påvirkes af projektet under eller efter projektforløbet. Vi vil således definere interessenterne i bibliotek.dk som: Biblioteksstyrelsen Kunde/modtager Dansk BiblioteksCenter Systemudvikling Driftsleverandør Kulturministeriet Overordnet opdragsgiver Lovgiver Biblioteksvæsenet Folkebiblioteker Forskningsbiblioteker Brugerne Det vil sige borgerne Danmarks BlindeBibliotek Konsulent for BS Videnscentre for synshandicappede Underleverandører i øvrigt Index Data (søgemaskine) ICL og Hitachi (hardware) Netbureauet Araneum (design) 15

bibliotek.dk Sammenligner man listen herover med organisationsdiagrammet tidligere i opgaven ses det, at alle interessenter på nær private brugere uden synshandicap er repræsenteret i projektorganisationen i bred forstand. Private brugere kan i øvrigt siges at have været involveret via brugertests af grænsefladen. I det følgende præsenteres de enkelte interessenter og deres indbyrdes interesser og relationer. 3.1.1 DBC og BS De centrale interessenter er kunden BS og systemleverandøren DBC. Leif Andresen forklarer opgavefordelingen således, at BS har haft det politiske ansvar og DBC det tekniske. Man kan sige, at der har været et utraditionelt kunde/leverandør forhold mellem DBC og BS i dette projekt. For det første er det ikke IT-systemet som sådan, DBC har udviklet til BS, men derimod serviceydelserne søge-adgang og bestilling. DBC ejer selv systemet bibliotek.dk. [ref. LA, 10/2000] For det andet har systemet ikke været i almindeligt udbud, fordi BS og DBC har en samarbejdsaftale, som fastslår, at DBC har eneret på levering af ITydelser, der baseres på den centrale DanBib database. Leif Andresen understreger, at bibliotek.dk ikke er nogen selvstændig aftale, men bygger på den eksisterende aftale mellem DBC og BS om DanBib [ref. LA, 10/2000]. For det tredje foreligger der ingen formel kontrakt mellem kunde og leverandør om udviklingen af bibliotek.dk. DBC startede udviklingen af systemet før biblioteksloven, der hjemlede ydelsen, var vedtaget, og inden der var afsat penge på finansloven. Der har således heller ikke været nogen kontraktligt fastsat tidsfrist for aflevering af systemet, men DBC har naturligvis haft en klar interesse i at få færdiggjort systemet, da DBC ikke har haft mulighed for at få finansieret indsatsen, før systemet gik online. Med offentliggørelse af bibliotek.dk er det sandsynligt, at DBC mister indtægter på DanBib databasen. Bibliotekerne har nemlig hidtil betalt for DanBib efter forbrug, men de har nu mulighed for at flytte en del af deres søgninger over i det gratis bibliotek.dk. Derfor har DBC været interesseret i 16

Kapitel 3 Interessentanalyse at få ændret betalingsmodellen for DanBib til en abonnementsordning, og der har tilsyneladende været konsensus mellem DBC og BS på dette punkt. Konkret er det aftalt, at kommunerne skal betale efter indbyggertal [ref. LA, 10/2000][ref. PMP, 09/2000]. DBC er via kommunal afgift sikret indtjening til at dække service tab. Fra bibliotekslovens side er driftsomkostninger dækket, bibliotek.dk har potentiale for at skaffe dem yderligere indtægter i fremtidige projekter. DBC s interesse i at gøre projektet færdigt stikker dybere end blot at få betaling for systemet. Det er naturligvis i DBC s interesse at få bibliotek.dk op at køre, før tilsvarende initiativer fra centralbibliotekerne kommer. Det først tilgængelige web-site af en bestemt type bliver ofte kendt, alene af den grund, at det var det første. DBC får ikke umiddelbar øget økonomisk vinding ved at komme først, men på sigt kan det betyde, at de bliver den foretrukne leverandør af tilsvarende systemer indenfor biblioteksverdenen. Som BW formulerer det, så håber DBC at bibliotek.dk.. på lang sigt kan være en portal som DBC kan leve af. 3.1.2 DBC og bibliotekerne Generelt er DBC afhængig af bibliotekerne som samarbejdspartnere og som indtægtsgrundlag. DanBib-dataene strømmer for eksempel begge veje nye registreringer kommer ind fra bibliotekerne, der til gengæld kan søge i den samlede database [ref. BW, 10/2000]. Bibliotekerne har også skullet bidrage til bibliotek.dk for at gøre systemet funktionsdueligt. Bibliotekerne har angivet service- og bestillingsforhold dels til orientering for brugerne og dels til at guide bestillinger rigtigt frem i systemet. I visse situationer er bibliotekerne også i konkurrence med DBC, idet specielt de større biblioteker fra tid til anden lancerer systemer ikke mindst på Internettet som konkurrerer med ydelser fra DBC. 17

bibliotek.dk 3.1.3 Kulturministeriet Kulturministeren er den formelle opdragsgiver og den som betaler for ydelserne fra bibliotek.dk via en bevilling på finansloven. For Kulturministeriet kan bibliotek.dk ses som en opfyldelse af intentionerne i regeringens IT-handlingsplan for så vidt angår Kulturministeriets ressortområde. Departementet har stort set ikke involveret sig i projektet undervejs. Leif Andresen fra BS forklarer det med, at BS reelt varetager opgaver som på andre ressortområder ville være departementale opgaver. [ref. LA, 10/2000] 3.1.4 Brugerne Biblioteksbrugerne (og skatteyderne) er også interessenter, men de har ikke været organiseret direkte i projektet. Undtaget herfra er særlige brugergrupper som blinde og svagtseende, der kan siges at have været repræsenteret ved videnscentre og ved Danmarks BlindeBibliotek Som DBC s IT-chef siger, så er bibliotek.dk DBC s første masseprodukt, som kommer direkte ud til private brugere. På den måde repræsenterer systemet en ny grænseflade for DBC til omverdenen. 3.1.5 Danmarks BlindeBibliotek Danmarks BlindeBibliotek har fungeret som konsulent for BS i forhold til bibliotek.dk, og har i den forbindelse haft indflydelse både på sidernes udformning og på projektforløbet. Danmarks BlindeBibliotek s opgave har været at bidrage til, at siderne blev tilgængelige for synshandicappede. Danmarks BlindeBibliotek har dog ikke været involveret helt fra starten af projektet, hvilket Danmarks BlindeBibliotek selv beklager, da det efter deres opfattelse har mindsket mulighederne for at præge siderne i en handicapvenlig retning. Danmarks BlindeBibliotek har gennemført to brugertests og afleveret fem rapporter om bibliotek.dk s tilgængelighed.[ref. DBB, 11/2000] 18

Kapitel 3 Interessentanalyse 3.1.6 DBC s underleverandører DBC s leverandører af hardware, søgemaskine og web-design tages med her for fuldstændighedens skyld. Det drejer sig om henholdsvis ICL, Hitachi, Index Data og Netbureauet Araneum. 3.1.7 Håndtering af interessenter I Projektledelse af systemudvikling skitserer Poul Staal Vinje to måder at håndtere interessenter på. Enten betragtes interessenterne som eksterne i forhold til projektet eller de inddrages som ekstra ressourcer. DBC (og BS) har haft en bevidst strategi med at inddrage interessenterne i et nærmere bestemt omfang. Eller som det stikordsvis formuleres i et mødepapir: information, høring, bidrag, respekt for interessenterne. På Figur 2 nedenfor er interessenterne i bibliotek.dk beskrevet ved Poul Staal Vinjes kategorisering af interessent-roller. Krydser i parentes angiver, at det er en definitionssag at afgøre, hvorvidt en interessent kan siges at have udfyldt en given rolle i forhold til bibliotek.dk. Beslutte Arbejde Bidrage Rådgive Kontrollere Vurdere Modtage (blive informeret) Biblioteksstyrelsen X X X X X X Dansk Biblioteks X X X Center Bibliotekerne (X) X (X) X Brugerne (X) Danmarks Blinde X X X X Bibliotek Videnscentre vedr. X handicaps Kulturministeriet X (X) X Index Data, ICL, Netbureauet Araneum X (X) Figur 2 - Interessenternes roller. Skemaet giver ikke overraskende et billede af BS og DBC som de mest aktive efterfulgt af Danmarks BlindeBibliotek(!) og bibliotekerne. 19

bibliotek.dk 3.1.8 Succeskriterier Når projektlederen har identificeret interessenterne, er den næste opgave at opklare de respektive interessenters succeskriterier for projektet. Kulturministeriets succeskriterier kan kort beskrives ved ønsket om at få leveret det lovede system og således opfylde en politisk målsætning som IThandlingsplanen. BS s succeskriterier har været at levere det system, som Kulturministeren stillede i udsigt på Kommunernes Landsforenings bibliotekskongres i 1998. BS s primære målsætning for projektet var at få et velfungerende system, der kunne holde til den belastning, som systemet måtte blive udsat for herunder eventuelt ekstra stor belastning lige efter offentliggørelsen [ref. LA, 10/2000]. Derudover havde BS en proces-orienteret eller politisk målsætning om, at systemet ikke skulle lave om på alt muligt i biblioteksvæsenet ikke i første version i hvert fald. Det skulle passe ind i de gældende normer og procedurer på bibliotekerne [ref. LA, 10/2000]. For eksempel ville direkte bestilling og forsendelse fra biblioteket med det ønskede materiale uden om brugerens lokale bibliotek være en grundlæggende ændring eller omgåelse af det såkaldte interurbane lånesamarbejde mellem bibliotekerne. I den nu offentliggjorte løsning er det fortsat det bibliotek, som brugeren er tilknyttet, der henter materialet hjem. I det udsendte oplæg op til informationsmødet med biblioteksvæsenet i maj/juni 1999 hedder det, at: Det er ikke tanken, at åbningen af DanBib i sig selv skal medføre ændringer i hvordan bibliotekerne i Danmark løser deres opgave. [Debatoplæg, 5/1999] Dette kan dels ses som et mål i sig selv, men også som et middel til at få opfyldt det første succeskriterium om et velfungerende system. En politisk, konfliktpræget udviklingsproces kan i sig selv medføre problemer for den tekniske gennemførelse af et IT-projekt, fordi der kan opstå modsatrettede krav og forventninger til, hvad det færdige produkt skal kunne og ikke kunne. BS har ikke givet udtryk for ambitioner om at opnå et bestemt antal søgninger eller bestillinger, eller at få positive tilbagemeldinger fra brugerne. I 20

Kapitel 3 Interessentanalyse det lille spørgeskema, som BS uofficielt udsendte til udvalgte biblioteker godt en uge efter offentliggørelsen, spørger Leif Andresen dog til: omfanget af bestillinger fra bibliotek.dk, stigning i antallet af fjernlånsbestillinger, publikums reaktioner, er der kommet nye lånere? oplever bibliotekarerne funktionsproblemer i bibliotek.dk? DBC har flere forskellige succeskriterier for projektet. Det afhænger til dels af, hvilke (del-)projektledere der udtaler sig. Som tidligere beskrevet har projektet bestået af 10 delprojekter, og DBC har både udviklings- og driftsfolk beskæftiget på projektet. Overordnet har divisionschef Per Mogens Pedersen (PMP) udtrykt, at han ville være tilfreds, hvis systemet klarer den givne belastning og genererer bestillinger i størrelsesordenen 2 mio. det første år eller dobbelt så mange bestillinger som ekspederes i det nuværende DanBib [ref. PMP, 09/2000]. IT-chef Bo Weyman (BW) har derudover givet udtryk for nogle interne succeskriterier for projektet. For det første at projektet blev gennemført inden for den afsatte bevilling det vil sige 5 mio. kr. det første år. Dernæst at projektet som sidegevinst gav nogle nye, solide og genbrugelige komponenter og en fornyelse af nogle basiskomponenter [ref. BW, 10/2000]. Som chef for driftsafdelingen er det naturligvis også et succeskriterium for Bo Weymann at overholde de opstillede krav til oppe-tider med videre. Lederen af delprojektet om bibliotekernes service-deklarationer har givet udtryk for, at det for hende var et succeskriterium, hvis bibliotekerne rent faktisk stillede deres indsats til rådighed og fik indtastet alle de nødvendige servicedeklarationer til systemet. Bibliotekerne. At dømme efter biblioteksrepræsentanternes oplæg ved de åbne møder i maj/juni 1999 er bibliotekerne (i hvert fald cheferne) generelt positive over for ideen om bibliotek.dk. Deres kritiske kommentarer kredser om de mulige fremtidige betalingsordninger, udsigten til stigende arbejdsbyrde for bibliotekerne og hensynet til de primære brugere. Nogle giver også udtryk for en faglig bekymring for, om søgefaciliteterne på hjemmesiden er for uprofessionelle [Panelindlæg, 5/1999]. En af oplægsholderne, souschef Jakob Andersen fra Forskningsbibliotekernes chefkollegium og chef ved Danmarks Pædagogiske Bibliotek, nævnte 21

bibliotek.dk som eksempel, at hans bibliotek nødigt låner deres børnebøger ud til børn, idet materialerne er tiltænkt studerende og forskere. Karl Posselt fra Det Sønderjydske Landsbibliotek er generelt positiv over for ideen om bibliotek.dk. Han forudser større gennemsigtighed i bibliotekernes service, hvilket vil motivere til ekstra service, og han er i øvrigt ikke bange for et library bypass det vil sige, at bestillinger og eventuelt senere betaling går uden om brugerens eget bibliotek. Han kunne godt have tænkt sig, at bibliotek.dk arbejdsgruppens kommissorium havde forpligtet parterne på, at svartider og driftsstabilitet i bibliotek.dk skulle blive bedre end i det eksisterende DanBib [Panelindlæg, 5/1999]. En del bibliotekarer herunder nogle af oplægsholderne har også givet udtryk for, at bibliotek.dk ville blive rigtig godt, hvis det blev integreret med bibliotekernes lokale systemer en facilitet som arbejdsgruppen for bibliotek.dk afviste for første version. Ifølge Leif Andresen kunne nogle biblioteker desuden godt have tænkt sig en form for synliggørelse på siderne som en slags returværdi af det udførte arbejde med ekstra brugerbestillinger [ref. LA, 10/2000]. For Danmarks BlindeBibliotek har det overordnede succeskriterium været at bibliotek.dk blev en hjemmeside med lige adgang for alle. Dertil kræves, at siderne kan læses hensigtsmæssigt ved hjælp af skærmlæsere, og at brugeren kan navigere med tastaturet alene det vil sige uden brug af mus [ref. DBB, 11/2000]. Den almindelige brugers og skatteborgers - succeskriterier kan vi kun gisne om, da de for så vidt ikke er blevet hørt. Objektivt set er det en fordel for borgerne, hvis de til færrest mulige penge får et system, som giver nogle fordele i dagligdagen, men dette kan vi som sagt ikke specificere nærmere. Det er bemærkelsesværdigt, at færdiggørelsesdatoen ikke har været et afgørende succeskriterium for nogen af interessenterne. Normalt kan det ellers være en kritisk faktor i IT-projekter. Flere interessenter har ganske vist givet udtryk for, at det kunne være godt, hvis systemet blev færdigt primo 2000, men vi har ikke sporet nogen kritik af, at denne (ikke kontraktligt fastsatte) tidsfrist blev overskredet. Tværtimod siger for eksempel BS, at det for dem var meget vigtigere at få et velfungerende system. Det er naturligvis fornuftigt nok, men i mange ITprojekter er det ikke et valg, om leverandøren vil levere til tiden eller levere et velfungerende system. 22

Kapitel 3 Interessentanalyse 3.2 Interessekonflikter Når interessenterne og deres respektive målsætninger, interesser og succeskriterier er identificeret, kan projektlederen bruge dette til at forudse og håndtere potentielle konflikter. De største potentielle konflikter i forbindelse med bibliotek.dk, har så vidt vi kan bedømme været: De forandringer af biblioteksvæsenets opgaver og procedurer, som bibliotek.dk kunne medføre, De økonomiske konsekvenser for de involverede specielt DBCs svindende indtægtsgrundlag i forbindelse med DanBib. Derudover skulle det vise sig, at der opstod visse problemer med processen omkring det at gøre siderne tilgængelige for synshandicappede. Det må konkluderes, at nogle af de mulige konflikter er undgået ved på forhånd at tage hensyn til bibliotekernes og DBC s grundlæggende interesser - eller ved at udskyde stillingtagen til de indbyggede konfliktmuligheder. Alice Nørhede, De Små Chefers Forum opsummerede problematikken om bibliotek.dk s konsekvenser for de nuværende procedurer i biblioteksvæsenet således: det danske biblioteksvæsen er endnu ikke skruet sammen til at håndtere de fulde konsekvenser af et DanBib for Alle. Teknologien skal på plads for alle danske biblioteker og der er mange ting, vi skal blive enige om ude i bibliotekerne. Det handler om så kontroversielle ting som lånertilhørsforhold og den deraf følgende lånerregistrering, samt betalingsordninger i form af udligning mellem kommuner og biblioteker eller decideret brugerbetaling og det vil nok tage et par år endnu, inden vi i det samarbejdende danske biblioteksvæsen kan blive enige om det. Det handler også om ressourcer har vi materialer og tilstrækkelig bemanding af kopimaskinerne til at give lånevejene frit løb for BRUGERNE? [Panelindlæg, 5/1999] 23

bibliotek.dk En anden oplægsholder på de åbne møder tvivlede på, at bibliotek.dk ville bevare status quo som BS s oplæg hævdede. Jakob Andersen fra Danmarks Pædagogiske Bibliotek sagde: Vi har heller ikke indtil nu fjernlånt materiale til de 70% af vores brugere, som ingen tilknytning har til Danmarks Lærerhøjskole. De er i stedet blevet henvist til deres egne institutioners biblioteker, subsidiært til deres folkebiblioteker. Det er muligt, at DanBib for Alle vil tvinge os til at revurdere denne beslutning, og dermed dementere oplæggets lidt naive udsagn: Det er ikke tanken, at åbningen af DanBib i sig selv skal medføre ændringer i hvordan bibliotekerne i Danmark løser deres opgave. [Panelindlæg, 5/1999] Som sagt har BS med den første version af bibliotek.dk undladt at tage hul på disse potentielle problemer. Oplæggene viser dog ikke umiddelbart, at der skulle være skarpe fronter på spørgsmålet om bibliotekernes rolle. Selv om nogle af oplægsholderne kunne se problemer i det såkaldte library bypass, er der ingen der udtrykker decideret modvilje mod tanken om direkte interaktion mellem brugeren og det bibliotek, der kan levere det ønskede materiale. De (få) ledende medarbejdere, vi har interviewet fra forsknings- og folkebiblioteker, går hovedsageligt ind for på sigt at give brugerne mulighed for at bestille direkte hos det bibliotek, som ligger inde med materialet. Men de ser en del tekniske, politiske og økonomiske problemer, og siger i øvrigt, at en del biblioteker frygter at drukne i brugerbestillinger i et sådant anarkistisk system. Lone Gladbo, Gentofte bibliotek, mener således, at et sådan system vil være i overensstemmelse med den fri låneret, men at det også vil kræve et centralt lånerregister og dermed godkendelse fra registertilsynet. Det lykkedes ikke helt for DBC og BS at få taget en anden interessent Danmarks BlindeBibliotek tilstrækkeligt i ed. Der har været en konflikt mellem DBC og Danmarks BlindeBibliotek vedrørende sidernes tilgængelighed for synshandicappede. Tilsyneladende nåede konflikten ikke at blive løst inden offentliggørelsen, idet Danmarks BlindeBibliotek fortsat beklager, at de er inddraget for sent i processen det vil sige efter at designprocessen var i fuld gang - at deres bidrag ikke er taget tilstrækkeligt alvorligt, og endelig, at slutresultatet som følge heraf er blevet mindre handicapvenligt end det kunne være. Danmarks BlindeBibliotek s synspunkt er, at siderne kan bruges, men at der er betyde- 24

Kapitel 3 Interessentanalyse lige irritationsmomenter, som relativt let kunne være undgået, samt at blinde brugere i praksis er afskåret fra at vælge mellem de forskellige niveauer af søgefaciliteter. Det sidste problem - spørgsmålet om DBC s svindende indtægtsgrundlag på DanBib - er løst ved at parterne har nået principiel enighed om en ændret betalingsmodel, hvor der ikke betales pr. søgning men efter abonnement opgjort i forhold til kommunernes indbyggertal. 3.3 Interessenternes indflydelse Som det fremgår af ovenstående, er biblioteksvæsenet blevet hørt, men ifølge Leif Andresen fra BS har bibliotekerne kun haft ret begrænset indflydelse på projektets forløb undervejs. Direkte adspurgt kunne Leif Andresen ikke komme i tanke om større, konkrete forslag fra biblioteksvæsenet, som var blevet implementeret i det endelige system [ref. LA, 10/2000]. Lone Gladbo, Gentofte bibliotek, siger at biblioteksvæsenet har haft mulighed for at påvirke funktionaliteten i bibliotek.dk men at det er sket inden for de rammer, som BS har udstukket på forhånd. Også Alice Nørhede, Danmarks Farmaceutiske Bibliotek og Lene Stampe, Danmarks Veterinærog Jordbrugs-bibliotek, mener at bibliotekerne har kunnet påvirke for eksempel Basen over Bestillingsønsker (BOB) og systemet til servicedeklarationer i en positiv retning. Netop Basen over Bestillingsønsker minder meget om et forslag, som blev stillet af en af oplægsholderne ved de åbne møder i maj/juni 1999, Jakob Andersen. Den betyder en egentlig rationalisering for bibliotekerne, der kan bruge den til at videresende bestillinger frem for at skulle oprette dem ud fra e-mails fra brugerne [Panelindlæg, 5/1999][ref. LA, 10/2000]. Som eksempel på ønsker bibliotekerne ikke har fået igennem, nævner Leif Andresen, at BS har afvist at give det bibliotek, som stiller de bestilte materialer til rådighed, en synliggørelse på siderne. Nogle bibliotekarers bekymring for søgeredskabernes uprofessionelle præg blev også afvist med den begrundelse, at den primære målgruppe er almindelige borgere frem for professionelle bibliotekarer [ref. LA, 10/2000]. Leif Andresen siger i øvrigt, at funktionaliteten blev låst fast i december 1999, således at biblioteker og andre herefter ikke kunne komme med ændringsønsker. DBC s udviklingschef Bo Weyman siger dog, at udviklingsorganisationen har modtaget og implementeret ændringsønsker indtil sidste øjeblik. Disse forskellige fremstillinger af forløbet kan skyldes, at de to taler ud fra forskellige detaljeringsniveauer. 25

bibliotek.dk 3.4 Interessenternes holdning til resultatet Bibliotek.dk har været online i ganske få uger, men nok til at få nogle umiddelbare reaktioner fra interessenterne. Danmarks BlindeBibliotek er generelt ikke tilfredse med processen og resultatet. Siderne kunne uden store ekstra omkostninger have været bragt til at fungere betydeligt bedre for synshandicappede, mener Dansk BlindeBibliotek, der tilføjer, at de gerne vil bevare tilliden til, at dét også er planen. De få biblioteker vi har talt med, er til gengæld generelt positive. Lene Stampe mener, at det er i bund og grund lykkedes godt, og finder det utroligt at udvikle et system med så stor ressourceindsats uden at få penge på forhånd. Det kræver en god tillid. Lone Gladbo vil også betegne projektet som en succes. Men hvad med brugerne og deres respons? Det kan Danmarks Farmaceutisk Bibliotek og Danmarks Veterinær- og Jordbrugsbibliotek pt. sige nul og niks om. Der har i skrivende stund ikke været nogen bestillinger. Lone Gladbo fortæller til gengæld, at Gentofte bibliotek fik 88 bestillinger de første 8 dage, hvilket hun egentlig finder meget flot i betragtning af, at der ikke har stået noget videre i aviserne om bibliotek.dk. 26

Kapitel 4 Projektforløbet Kapitel 4 Projektforløbet 4.1 Projektforløbet - årsager og konsekvenser I dette kapitel vil vi beskrive, hvordan DBC har håndteret projektforløbet omkring bibliotek.dk. Målet er at angive mulige årsager til det aktuelle forløb samt pege på realiserede og sandsynlige konsekvenser. Beskrivelsen bygger ligesom interessentanalysen på en summering af de informationer, vi har modtaget gennem vores interviews samt på offentligt tilgængeligt materiale om projektet. Vores vurderinger af årsager og konsekvenser bygger på den viden, vi har erhvervet i interessentanalysen, samt på inddragelse af teori for IT-projektledelse. Kapitlet er delt i 2 dele; 1. del beskriver forhold omkring opstart og evaluering af projektet og indeholder følgende punkter: Aftalegrundlag Projektmodel Projektevaluering Kapitlets 2. del omhandler styringen af projektforløbet indenfor følgende områder: Målformulering Strategier Aktivitetsplanlægning Ressourcer Gennemførelse og opfølgning Rapportering Regulering (herunder ændringsstyring) Overdragelse og nedlukning 27

bibliotek.dk 4.2 Første del 4.2.1 Aftalegrundlag Aftalegrundlaget er den konkrete aftale mellem aftaleparterne som dækker alle aspekter af projektets forløb og udkomme. DBC s aftalepartner som leverandør i bibliotek.dk -projektet er som nævnt BS som kunde. Da DBC har eneret på leverance af database-ydelser som bygger på Dan- BIB [ref. BW, 10/2000], så betragter BS ikke aftalen om udvikling af bibliotek.dk som en selvstændig aftale, men som en forlængelse af den eksisterende aftale om DanBIB [ref. LA, 10/2000]. (Indholdet af den konkrete aftale mellem BS og DBC omkring DanBIB ligger udenfor vores projektafgrænsning.) Der indgås derfor ikke en (juridisk) aftale i form af en kontrakt eller købsaftale forud for projektstart. DBC udvikler bibliotek.dk på forventet efterbevilling og er principielt i samme situation som firmaer der udvikler offthe-shelf-software: deres kunde køber først produktet, når det er færdigt [ref. LA, 10/2000]. Produktet er i denne sammenhæng driften af bibliotek.dk. Principelt skal finanslovsbevillingen på 35 mio. kr. over 4 år netop kun dække driften af det nye system i perioden. Det forhold, at systemet skal udvikles, inden det kan sættes i drift, er i teorien BS uvedkommende [ref. LA, 10/2000]. Teknisk set er aftalen mellem BS og DBC således en fastpris-aftale; som udgangspunkt skal bevillingen dække alle udgifter i perioden. Projektet blev aftalt og påbegyndt alene ud fra en ramme som gennem dialog mellem BS og DBC skulle udfyldes bedst muligt [ref. LA, 10/2000]. Forløbet fra sommeren 1999, hvor DBC starter udviklingsprojektet, og frem til årsskiftet samme år, kan betragtes som et (langt) forprojekt med det mål at fastlægge funktionskravene til bibliotek.dk. DBC får heller ikke direkte betaling for forprojektet; udgifterne hertil afskrives sammen med systemudviklingen over det kommende driftsbudget i den første bevillingsperiode på 4 år [ref. LA, 10/2000]. En væsentlig årsag til det uformelle aftalegrundlag for udviklingen af bibliotek.dk er således den eksisterende aftale og det eksisterende samarbejde om DanBIB. Uden DanBIB-aftalen ville bibliotek.dk -projektet i følge BS have krævet en traditionel udbud- og licitationsrunde, hvor formelle kravspecifikationer, selvstændige kontrakter, budgetter, m.m. ville skulle indgå [ref. LA, 10/2000]. 28

Kapitel 4 Projektforløbet Som gennemgået i interessentanalysen, så er tillidsforholdet mellem BS og DBC meget betydende for forløbet. BS angiver direkte, at de ikke ville lave tilsvarende aftale med et traditionelt kommercielt firma [ref. LA, 10/2000]. DBC tilskriver det løse aftalegrundlag den måde som projektet er påbegyndt og at de involverede først undervejs har (...) erkendt kravene til systemet [ref. BW, 10/2000]. En konsekvens af det løse aftalegrundlag er i følge BS en risiko for at miste overblikket over projektet og hvad det indeholder samt muligheden for, at leverandøren kan manipulere til egen vinding undervejs i projektet [ref. LA, 10/2000]. Konsekvenserne af at vælge at indgå en fastpris-aftale [Hughes et.al, 1999] identificeret i det aktuelle projekt: DBC bærer risikoen for, at målene kan nås indenfor den aftalte pris. DBC vil derfor kalkulere med denne risiko i deres tilbud og kræve en højere pris end deres estimat tilsiger. DBC er i en god position til at kræve en høj kompensation for at efterkomme ændringsønsker fra BS undervejs i projektet. Kvaliteten af det færdige produkt kan kompromitteres af, at DBC vil forsøge at bruge færrest muligt ressourcer på projektet for at optimere indtjeningen. Da DBC reelt har monopol på at levere ydelser fra DanBIB, har de i udgangspunktet en stærk position i fastlægning af aftalegrundlaget, og de har endvidere undgået en konkurrencesituation med andre firmaer som kunne påvirke pris og ydelse i leveringen af bibliotek.dk. DBC har følgelig ikke bundet sig til en løsningsmodel fra start, og BS har ikke haft mulighed for at se alternative forslag til opgavens løsning. 4.2.2 Projektmodel En projektmodel er en teoretisk og forenklet model af et projektforløb [Vinje, 1997]. Projektmodellen er et værktøj til at fastlægge de forhold omkring udvikling, kommunikation og dokumentation som er de samme uanset projektets aktuelle formål. DBC har en vedtagen projektmodel som led i selskabets ISO 9000 certificering som indeholder retningslinier for projektforløb og bl.a. definerer udseende og indhold af design- og specifikationsdokumenter. Forholdet til certificeringsorganisationen (ISO) oplever DBC i dag mere som en sparring end en kontrolmekanisme [ref. PMP, 09/2000]. 29

bibliotek.dk Udviklingen af bibliotek.dk har ikke fulgt DBC s vedtagne model for projektforløb; projektledelsen har for dette projekt bevidst fravalgt al form for bureaukrati [ref. BW, 10/2000]. Årsagen til dette valg begrundes i første omgang med, at et formaliseret projektforløb ikke giver garanti for et godt resultat. Det er vigtigere at fokusere på at vælge de rigtige personer til at styre projektet. Desuden er det DBC s erfaring, at effekten af at følge en projektmodel er ringe. De bedste projekter i DBC-regi er forløbet uden, mens meget formelle og veldokumenterede DBC-projekter er gået ned i flammer [ref. BW, 10/2000]. Fravalget af en projektmodel, bevidst som ubevidst, har som konsekvens, at styringen af projektet bliver sværere. Det skyldes, at projektmodellen med fordel bruges som skelet for aktivitetsplanlægningen, grundlag for tidsestimeringen, grundlag for kalenderfastsættelsen og som skelet for bemanding [Vinje, 1997]. Uden en projektmodel som hjælp bliver disse nødvendige planlægningsaktiviteter sværere at udføre, og stiller dermed større krav til projektledelsens dygtighed. 4.2.3 Projektevaluering Formålet med en projektevaluering er at vurdere projektets udkomme (produktet), projektets forløb, den valgte strategi/metode og væsentlige hændelser undervejs i projektet [Vinje, 1997]. I skrivende stund er bibliotek.dk -projektet netop afsluttet og bibliotek.dk er sat i drift. Der er endnu ikke iværksat en projektevaluering, men det er DBC s intention, at det skal ske. Det kan være i form af et evalueringsseminar om projektet som projekt. Her skal diskuteres gode og dårlige ting i projektforløbet/metoden [ref. BW, 10/2000]. 4.2.4 Delkonklusion Det særlige forhold der eksisterer mellem DBC og BS, er årsag til de fleste af de bemærkelsesværdige elementer i aftalegrundlaget for bibliotek.dk. Det, at BS betragter den formelle aftale om bibliotek.dk alene som en aftale om drift, kan opfattes som en måde at beskytte sig selv. På den måde undgår BS formelt at tage ansvar for udviklingen af bibliotek.dk og forbeholder sig i teorien retten til ikke at indgå en aftale. Af stor betydning for projektet forløb er under alle omstændigheder, at BS bevarer en position, hvor de kan tillade sig at stille krav undervejs i hele projektet. 30

Kapitel 4 Projektforløbet Farerne ved at indgå fastpris-aftaler er velkendte og teoretisk set tilstede, som vi har identificeret. Alligevel kan BS stort set se bort fra dem, for som DBC selv gør opmærksom på, så har de (DBC) nemlig en lige så stor eller større interesse end BS i, at bibliotek.dk bliver en succes [ref. BW, 10/2000]. Årsagen er, som beskrevet i interessentanalysen, at DBC i bibliotek.dk ser en mulighed for at skabe sig en position som den, der knytter brugerne til bibliotekerne. Det forudsætter, at bibliotek.dk bliver en succes, og derfor rækker DBC s engagement i bibliotek.dk videre end til at få projektet ud af døren. I sine bestræbelser på at levere det bedste produkt tilsidesætter DBC mange af de traditionelle forsigtighedsregler. Det primære eksempel er DBC s accept af den såkaldt åbne kravspecifikation, som under normale omstændigheder er helt umulig i en fastpris-aftale. DBC accepterer dette til trods for, at det giver store problemer i udviklingsforløbet [ref. BW, 10/2000]. Det er vel ikke ualmindeligt for IT-projekter, at man arbejder med mål, der flytter sig undervejs; om ikke fordi de involverede når nye erkendelser undervejs, så fordi verden omkring projektet ændrer sig. Men man kunne forvente, at DBC i kraft af sin monopolagtige status havde forhandlet sig til et mere fordelagtigt formelt aftalegrundlag, som i højere grad lagde ansvar hos BS, end tilfældet er. Men DBC s strategiske interesse i at få gennemført bibliotek.dk er tilsyneladende blevet prioriteret højere, eller også har DBC inkluderet en tilstrækkelig præmie i rammebeløbet for bibliotek.dk til at kompensere for risikoen. 31

bibliotek.dk 4.3 Anden del 4.3.1 Målformulering En målformulering sikrer, at der sættes konkrete mål for projektforløbet og dets udkomme. Målene er grundlaget for al planlægning af projektet, og de skal indgå i projektets aftalegrundlag. Målformulering kan ske gennem specifikation af de krav, der stilles til det aktuelle system. Opsamling og specifikation af kravene til bibliotek.dk sker i løbet af perioden fra sommeren 1999 frem til årsskiftet samme år (reelt et forprojekt), og resulterer i en såkaldt åben kravspecifikation. [ref. PMP, 09/2000] Der indgik ingen formelle tekniske krav i aftalen og væsentlige dele af aftalen m.h.t. systemets idriftsættelse og drift var ikke specificeret ved forprojektets afslutning [ref. LA, 10/2000]. Reelt er målformuleringen i det hele taget ikke afsluttet med forprojektet. Dels mangler vedtagelse og bekendtgørelse af den ny bibliotekslov, hvilket betyder, at der er usikkerhed om lovgrundlaget; dels er brugernes krav ikke færdiganalyseret før sommeren 2000. Skulle man have ventet (med at starte udviklingsprojektet) indtil biblioteksloven var bekendtgjort og specifikationsfasen færdiggjort, så havde DBC først kunnet starte projektet i juni, 2000. [ref. LA, 10/2000] Udviklingsarbejdet starter imidlertid et helt år før, i sommeren 1999[ref. BW, 10/2000]. På dette tidspunkt eksisterer primært et projektudkast, som er bearbejdet siden januar 1999 [ref. PMP, 09/2000]. Årsagen til at udviklingsarbejdet starter så tidligt, er, at man ønsker at levere en løsning hurtigt og at man undervurderer projektets omfang (og dermed behovet for specifikation)[ref. LA, 10/2000] [ref. PMP, 09/2000]. Uden klare og godkendte mål spildes der tid i planlægningen, og estimater kan kun beregnes med stor usikkerhed [Vinje, 1997]. En målformulering kan indeholde 3 typer af mål [Vinje, 1997]: Forandringsmål, systemmål og projektmål. Det er karakteristisk, at BS ved projektets start primært har opstillet forandringsmål for bibliotek.dk (kortfattet: offentlig adgang til søgning og bestilling af emner i fælleskataloget ), enkelte projektmål (m.h.t. økonomisk ramme og involvering af brugerne), men ingen systemmål (f.eks. oppetid eller svartid under drift). Det er ladt op til DBC alene at fastsætte mere operative projektmål særligt m.h.t. systemmål. 32

Kapitel 4 Projektforløbet 4.3.2 Strategier Strategier fastlægger med udgangspunkt i projektmålene fremgangsmåden i et projekt, og de fungerer som overordnede retningslinier for projektlederens arbejde. DBC s overordnede strategier i bibliotek.dk -projektet er primært givet ved resultatet af vores interessentanalyse. For det første at søge at minimere den forventede forandringsmodstand mod bibliotek.dk fra bibliotekernes passe bibliotek.dk ind i gældende normer/teknik/politik på bibliotekerne. Projektet måtte ikke ændre på disse [ref. LA, 10/2000]. For det andet at inddrage bibliotekerne i processen omkring definitionen af bibliotek.dk s funktioner. Som beskrevet i de tidligere kapitler er det sket dels officielt gennem den række af debat- og informationsmøder som er holdt på dansk og nordisk plan gennem 1999, og dels uofficielt gennem kontakter (primært fra BS) til (unavngivne) nøglepersoner i biblioteksvæsenet i form af personlige Gallups [ref. LA, 10/2000]. Udover at observere de overordnede strategier for hele projektet følger DBC en række strategier ud fra egne interesser. Væsentligst er at opfylde målene gennem en overbygning på DanBIB, og således basere projektet på kendt teknologi [ref. BW, 10/2000]og at gennemføre det mellem kendte parter (BS og DBC). DBC har desuden truffet et strategisk valg om alene at egenudvikle de bibliotek.dk -komponenter som lå i deres kernekompetence. Det har betydet, at brugergrænsefladen, visse dele af databasesystemet samt levering af hardware og basissoftware er udført af underleverandører. Endelig tilstræber DBC at bygge bibliotek.dk på generiske komponenter, d.v.s. videreudvikle eksisterende komponenter, så de også kan bruges i bibliotek.dk, og udvikle nye komponenter som kan genbruges i fremtidige projekter. Forudsat, at det lykkes DBC at positionere sig som ønsket, så kunne genbruget ske i projekter for centralbibliotekerne, når disse vil udbyde egne services. 4.3.3 Aktivitetsplanlægning Formålet med aktivitetsplanlægning er at vurdere hvilke aktiviteter, der er en del af det forestående projekt. Planlægningen danner fundament for mange af de senere discipliner i styringsforløbet, herunder tidsestimering og ressourceallokering. DBC har kørt bibliotek.dk som 10 underprojekter, hvoraf nogle har været udliciterede. Skarpt afgrænsede delprojekter gør, at projektlederen for det 33

bibliotek.dk enkelte delprojekt lettere kan identificere delprojektets aktiviteter, og dermed mindske risikoen for, at evt. milepæle ikke nås. Dette er en fornuftig måde at køre et større projekt på idet det udnytter mulighederne for parallelle forløb og tydeliggør afhængigheder mellem de forskellige dele af et projekt. Men det kan naturligvis ikke kompensere for den manglende kravspecifikation. Aktivitetsplanlægning er svær, når man ikke kender aktiviteterne tilstrækkeligt langt ud i tiden. Planlægning er da reduceret til ad hoc, "hvor man i høj grad har truffet beslutninger i vadestedet"[ref. BW, 10/2000]. En umiddelbar konsekvens af ikke at lave aktivitetsplanlægning er, at ikke alle aktiviteter identificeres, hvorfor de resulterer i et direkte overhead, og dermed øget pres på udviklerorganisationen eller overskredne deadlines [Vinje, 1997]. Et eksempel på manglende aktivitetsplanlægning fra DBC s side er planlægningen af hardware-testene. De kunne med fordel have været sat i gang, så snart hardwaren var i hus (november 1999), hvilket sandsynligvis kunne have afsløret problemerne på dette område tidligere. 4.3.4 Tidsestimering De tidsestimater, der har foreligget, er meget løse qua manglende kravspecifikation. At DBC ikke har været fastholdt i en timebox fra hverken BS eller ministeriel side, har givet projektet en fleksibilitet, der gør, at revideringer og opdateringer til systemets funktionalitet har fundet sted uden prioritering af konsekvensen for leveringstidspunktet. Det har ikke nødvendigvis en dårlig indflydelse på det endelige produkt, men det har en negativ indflydelse på DBC s omdømme, da der følger et prestigetab med, når en leveringsdato overskrides [Referat LA]. Prestigetabet kan i værste fald betyde, at DBC mister ordrer blandt centralbibliotekerne, når disse skal udleve egne ambitioner om offentligt tilgængelige web services. At kommunikationen har været uformel, er ikke blot skyld i, at der ikke er en kravspecifikation, endsige kontrakt. Den har også del i, at DBC ikke får kommunikeret en reel tidsplan til BS. Der er derfor ikke belæg for at hænge DBC op på ikke overholdte leveringsdatoer. De dokumenter der reelt udgør projektets fysiske planer, har ikke været tilgængelige, da de dokumenter der skal danne basis for dem, blot forefindes som e-mail korrespondancer [ref. PMP, 09/2000]. 34

Kapitel 4 Projektforløbet 4.3.5 Ressourcer og fysiske planer De ressourcer der er til rådighed for udviklerorganisationen, er primært mandskab og (ofte begrænset) tid. En væsentlig del af projektstyring består i at udnytte de givne ressourcer bedst muligt, således at projektet får et optimalt forløb. Projektledelsen hos DBC har erfaring for, at den mængde ressourcer, der bruges på et projekt altid stiger eksponentielt mod projektets afslutning. Det gælder for såvel den enkelte medarbejderne som for organisationen som hele [ref. BW, 10/2000]. Holdningen er, at sådan vil det uundgåeligt være, da det er svært at være motiveret for at arbejde effektivt mod næste milepæl frem for "den endelige milepæl". Denne holdning er usund, fordi den udgør en trussel mod et homogent fremskred i et projekt. I bedste fald forlader DBC sig på en god arbejdsdisciplin hos medarbejderne; i værste fald skrider tidsplanerne p.g.a. en lav effektivitet i en stor del af projektperioden. Problemet er kun i første omgang en manglende arbejdsdisciplin blandt udviklerne; det virkelige problem er ledelsens holdning, da de ikke opfatter situationen som et reelt problem, men som en naturlig konsekvens af projektarbejdet. 4.3.6 Gennemførelse og opfølgning DBC har løbende holdt kontrol med de autonome delprojekter. Dette gøres ved ugentlige møder mellem nøglepersoner fra hvert delprojekt, BW og PMP. Der er ikke nedskrevne referater af disse møder, men der findes statusrapporter. PMP erkender, at "nogle af hans folk nok har savnet en projektsekretær". De ugentlige møder mellem delprojekternes nøglepersoner udgør den kommunikation, der har været delprojekterne imellem. Ugentlige møder er en god måde at afvikle opfølgningsprocedurer på; det skal blot sikres, at den enkelte gruppes nøglerepræsentant faktisk repræsenterer hele sin gruppe, og ikke blot egne synspunkter. Derudover vil det være fordelagtigt, hvis repræsentanten fik input med tilbage til gruppen, eksempelvis i form af et referat. Samme referat bør placeres i en central database, således det senere kan hentes frem, for at verificere hvilke aftaler der blev indgået på de enkelte møder. Selv om det forventes, at delprojekterne kører som autonome grupper, er det fordelagtigt at have en formaliseret arbejdsgang. Grupperne arbejder mod et fælles mål, hvorfor det er vigtigt at sikre en fælles vision. Dette 35

bibliotek.dk fremhæves af BW som værende vigtigere end en formaliseret projektmetode; metoden til at opnå dette har været at skabe en tæt personkontakt projektdeltagerne imellem[ref. BW, 10/2000]. Der har altså været taget højde for intern opfølgning hos DBC. Selve opfølgningen DBC/BS imellem har været af mindre formel karakter. I selve implementationsfasen var der ingen formelle møder mellem BS og DBC, men en række uformelle møder (ca. 1 per måned), og en række af e-mails og telefonsamtaler LA og PMP imellem. Grundet den tidligere nævnte holdning mht. motivation og milepæle, er det svært at lave løbende opfølgning på de enkelte delprojekter. Der har været en uformel aktivitetsopfølgning jvf. de ugentlige møder, men hvis et delprojekt ikke er opdelt i forskellige aktiviteter, er den reelle fremgang ikke målbar som funktion af den mængde ressourcer gruppen har brugt. Det er derfor besværligt at vurdere det samlede projekts egentlige fremdrift. 4.3.7 Regulering "Ændring af datoer meget tæt på leveringstidspunktet giver stor mulighed for at berige sit ordforråd..." [Vinje, 1997] Regulering skal ske, når opfølgningen på et projekt viser, at det forløber anderledes end planlagt. Som minimum skal planerne tilpasses virkeligheden. DBC's regulering af ressourcer undervejs i projektet har primært drejet sig om reallokering af interne ressourcer. bibliotek.dk har haft højeste prioritet blandt DBC's projekter. Da eksempelvis hardware-problemerne blev et regulært svagt punkt for projektets videre færd, trak bibliotek.dk -projektet ressourcer fra andre projekter i huset [ref. PMP, 09/2000] Enhver form for regulering tager naturligvis udgangspunkt i en planlægning af projektets indhold, ressourcer, tidsestimering eller arbejdsform. Mangelfuld planlægning gør regulering svær eller umulig at foretage. Som konsekvens af en ad hoc aktivitetsplanlægning har det været svært at foretage en styret regulering af bibliotek.dk-projektet. Det har bl.a. betydet, at det har været svært korrekt at vurdere konsekvenserne af at acceptere ændringsønsker undervejs i projektet. Netop dette forhold har haft stor betydning, da situationen har været, at DBC har været nødt til at acceptere mange og sene ændringsønsker bl.a. på grund af den sene erkendelse af mange af kravene til systemet (eksempelvis BOB ) [ref. BW, 10/2000]. 36

Kapitel 4 Projektforløbet 4.3.8 Overdragelse og nedlukning En overdragelsesforretning markerer overgangen til drift (systemforvaltning), og sker i et samarbejde mellem projektlederen og den ansvarlige for driften [Vinje, 1997]. For bibliotek.dks vedkommende er der ikke tale om en traditionel overdragelsesforretning idet både udvikling og drift sker under samme hat. Da det fra start er besluttet, at BS også lægger driften af systemet hos DBC, så skal projektet blot overdrages internt hos DBC fra udviklingsafdelingen til driftsafdelingen. Det betyder, at inddragelsen af BS i idriftsættelsen er minimal; BS modtager et brev fra DBC, når systemet er færdigt, med besked om hvornår det sættes i drift [ref. PMP, 09/2000]. Den nuværende organisation hos DBC betyder at udviklings- og driftsafdelingen har samme chef. Der er således ikke engang tale om personadskilte funktioner, hvilket betyder, at der er fare for at overdragelsen bliver mangelfuld. Det kan få konsekvenser for omfanget og kvaliteten af den dokumentation, der fremstilles til systemet. 4.3.9 Anden delkonklusion Den først estimerede leveringsdato for bibliotek.dk lød på 2. februar 2000 og opererede med en udviklingsperiode på ca. 6 måneder. Projektet blev først sat i drift 31. oktober 2000 (8 måneder forsinket) efter en udviklingsperiode på ca. 12 måneder. Den første synlige forhindring i at køre projektet som normeret, er vedtagelsen af biblioteksloven, der påvirker kravene til systemet. Næste synlige forhindring erkendes i juli 2000, hvor DBC melder ud om tekniske problemer. Det viser sig, at DBC's valg af teknologi ikke er optimal, idet operativsystemet (SUN Solaris) ikke er certificeret til den valgte kombination af hardware. "Forsinkelse, der skyldes underleverandørens manglende opfyldelse af indgåede aftaler, er et udtryk for at projektlederen ikke har gennemført en planlægning der sikrer den tilstrækkelige uafhængighed." [Vinje, 1997]. Med andre ord, DBC har gjort sig for afhængige af en teknologi (Solaris på Intel platform, frem for SUNs eget hardware), der ikke umiddelbart kan levere varen. Afhængigheden kan tilskrives, at DBC mener at have ekspertise og gode erfaringer m.h.t. SUN på Intel platform. 37

bibliotek.dk Vi har ikke belæg for at vurdere om forsinkelsen af bibliotek.dk alene skyldes de synlige forhindringer, eller om DBC s håndtering af projektforløbet spiller en rolle. Det ville kræve, at vi havde mulighed for at sammenholde kravspecifikation, planlægningsdokumenter, tidsplan og ændringsdokumenter. At denne mulighed ikke er tilstede skyldes, at dokumenterne ikke eksisterer i en samlet og opdateret form. Det mener vi i sig selv er en indikation af, at håndteringen af projektforløbet ikke er optimal. Den umiddelbare konsekvens af manglende dokumentation undervejs i projektforløbet er naturligvis, at det er svært at vurdere projektets status og konsekvensen af at foretage ændringer. Ydermere betyder det, at personafhængigheden øges drastisk fordi kritisk viden om projektet ikke er dokumenteret, men kun findes hos de involverede medarbejdere. Endelig er grundig dokumentation en forudsætning for at evaluere et projektforløb. Uden en evaluering og opfølgning på projektmodellen kan organisationen ikke lære af det aktuelle forløb, og er i teorien dømt til at gentage de samme fejl igen og igen. 38

Kapitel 5 Konklusion Kapitel 5 Konklusion Hovedindtrykket af bibliotek.dk er, at det er et projekt der, indtil videre, må betegnes som en succes. De fleste af de centrale interessenter synes tilfredse med forløbet og teknisk set har systemet klaret offentliggørelsen. Ganske vist synes brugen af systemet at være ret begrænset set i forhold til de anstrengelser, der har været investeret i at forberede det til meget store belastninger, men de beskedne besøgstal kan foreløbig forklares med, at BS og DBC bevidst har nedtonet reklametrommerne for at give systemet en blid start. Og systemet kom noget senere end først antaget - trekvart år faktisk - men på den anden side har der aldrig været nogen helt officiel deadline for offentliggørelsen. Det har i det hele taget karakteriseret projektet, at deltagerne har set bort fra de gængse krav om kontrakt og aftalt afleveringstidspunkt og præcise aftaler om betaling for udviklingen af systemet. De centrale projektdeltagere har heller ikke lænet sig op ad kendte metoder for projektledelse eller systemudvikling. DBC siger, at de bevidst har fravalgt al form for bureaukrati og BS siger, at projektet ikke er kørt efter bestemte metoder, men at deltagerne har koncentreret sig om at få det til at virke i stedet for. Det kan være koketteri fra nogle erfarne folk i faget, men hovedindtrykket er et udviklingsprojekt som på mange måder er styret ad hoc. Særligt den lidt provokerende afskrivning af alt bureaukratiet er dog en klassiker, som er svær at sidde overhørig. Naturligvis har der løbende været lagt planer (også skriftligt), men i flere perioder har planlægningsaktiviteterne efter DBC s eget udsagn haft karakter af dag-til-dag planlægning, og under alle omstændigheder har den systematiske tilgang til projektstyringen manglet aldeles. 39

bibliotek.dk Med denne opgave har vi stillet spørgsmålet, hvordan projektet om bibliotek.dk kan blive en succes (i de flestes øjne), selv om det er afviklet på en uortodoks måde. Vi kan se følgende grunde: En enkel, letforståelig målsætning (søgning og bestilling), som har været nem at styre efter, En god håndtering af interessenterne, som bestod i: at tilgodese interessenternes grundlæggende interesser, at afgrænse projektet fra mere komplicerede, politiske og økonomiske diskussioner ved bevidst at begrænse funktionaliteten, bevidst at integrere og høre interessenterne uden at give for lang snor for ændringsønsker, en heldig kombination af checks and balances, hvor udviklerorganisationen (DBC) i virkeligheden var den part, som var mest motiveret for at få ført projektet til ende og med et godt resultat, og derfor tilførte projektet alle de nødvendige ressourcer - også på bekostning af andre projekter internt, mens kunden (BS) var mere interesseret i at få et stabilt system (uden åbningsskandaler) end i at få et system på et bestemt tidspunkt, Fraværet af en egentlig (hård) deadline, Mangeårigt samarbejde og gensidig tillid mellem leverandør og modtager. Med fokus på DBC s procesmetoder kan vi konkludere, at selve forløbet kunne optimeres, således at der var bedre styring med udviklings/leverancedelprojekterne. Vi mener, at den tætte tilknytning til BS har foranlediget nogle af de problemer der opstod i projektforløbet. Både DBC [ref. BW, 10/2000] og BS [ref. LA, 10/2000] erkender, at projektet ville have haft et andet (mere stringent) forløb, hvis konstellationen af interessenter (primært DBC og BS) havde været anderledes. For DBC kunne bibliotek.dk have været mere profitabelt (set i forhold til rammen), hvis der havde været bedre styring på f.eks. hardwareleverancen (for hvilken de dog regner med at kræve kompensation fra leverandøren [ref. BW, 10/2000]). Derudover kunne de som leverandør have krævet en kravspecifikation af kunden, således at grundlaget for projekt var i orden ved projektets start. 40

Kapitel 5 Konklusion Den kommende tid vil vise, hvordan driften af bibliotek.dk forløber. Vi vurderer, at den noget flydende overgang fra udvikling til drift på kort sigt vil være en fordel, fordi driftsfolkene og udviklingsfolkene er i samme organisation. På længere sigt frygter vi, at den kan være problematisk fordi den skjuler eventuelle (men sandsynlige) mangler i dokumentation og procedurer, som er essentielle for en effektiv og problemfri drift. Vi mener at have belyst interessentforholdende under bibliotek.dk projektet fyldestgørende. Derudover har vi fået en forståelse af årsagerne til det noget særegne projektforløb hos DBC, og vi har vurderet hvilke konsekvenser, der kan observeres nu samt hvilke der kan tænkes at komme. 41

bibliotek.dk Efterskrift Siden bibliotek.dk blev åbnet for tre uger siden, er der ekspederet 13.856 bestillinger. I dagtimerne foretager brugerne omkring 35 søgninger i minuttet. Efter nytår forventer Dansk BiblioteksCenter og Biblioteksstyrelsen at markedsføre bibliotek.dk for alvor. Her kommer dagens graf. Vi lader den stå et øjeblik. Figur 3 - Statistik på bibliotek.dk, d. 21 november 2000 42