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

Transkript

1 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

2 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.

3 Indholdsfortegnelse Indholdsfortegnelse FORORD V KAPITEL 1 INDLEDNING Problemformulering Metode 8 KAPITEL 2 PROJEKTET Historien om projektet Projektets organisering 11 KAPITEL 3 INTERESSENTANALYSE Interessenterne i bibliotek.dk Interessekonflikter Interessenternes indflydelse Interessenternes holdning til resultatet 26 KAPITEL 4 PROJEKTFORLØBET Projektforløbet - årsager og konsekvenser Første del Anden del 32 KAPITEL 5 KONKLUSION 39 iii

4 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

5 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

6 bibliotek.dk vi

7 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

8 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

9 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

10 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 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 En anden faktor der var med til at forsinke projektet var, at vedtagelsen af den nye bibliotekslov blev forsinket til først i maj 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

11 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 Kulturministeren Kulturminister Elsebeth Gerner-Nielsen er den officielle opdragsgiver, og det er på hendes foranledning, at bibliotek.dk kommer på finansloven. 11

12 bibliotek.dk 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å 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å 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

13 Kapitel 2 Projektet 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 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å Endvidere har andre repræsentanter for svagtseende været tilknyttet som konsulenter 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

14 bibliotek.dk 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

15 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

16 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 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

17 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 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

18 bibliotek.dk 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] 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 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

19 Kapitel 3 Interessentanalyse 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 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

20 bibliotek.dk 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 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

21 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

22 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

23 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

24 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

25 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 s 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

26 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

27 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

28 bibliotek.dk 4.2 Første del 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

29 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 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

30 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 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] 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

31 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

32 bibliotek.dk 4.3 Anden del 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 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, [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

33 Kapitel 4 Projektforløbet 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 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

34 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 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 korrespondancer [ref. PMP, 09/2000]. 34

35 Kapitel 4 Projektforløbet 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 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

36 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 s 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 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

37 Kapitel 4 Projektforløbet 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 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

38 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

39 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

40 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

41 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

42 bibliotek.dk Efterskrift Siden bibliotek.dk blev åbnet for tre uger siden, er der ekspederet 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

43 Litteraturliste Litteraturliste Referater Reference [ref. PMP, 09/2000] [ref. LA, 10/2000] [ref. BW, 10/2000] [ref. DBB, 11/2000] Forfattere, titel, udgiver og år. Referat fra møde hos DBC med Per Mogens Pedersen. 27. september Se Appendiks C. Referat fra møde hos BS med Leif Andresen. 13. oktober Se Appendiks D Referat fra møde hos DBC med Bo Weyman. 26. oktober Se Appendiks E Referat fra møde hos DBB. 16. november Se Appendiks F. Litteratur Reference [Vinje, 1997] [Hughes et.al, 1999] Forfattere, titel, udgiver og år. Projektledelse af systemudvikling. Poul Staal Vinje. Teknisk Forlag Software Project Management. Bob Hughes & Mike Cotterell. 2 nd edition. McGrawHill

44 bibliotek.dk Artikler Reference [NfN nr. 4, 12/1998] [NfN nr. 1, 3/1999] [Debatoplæg, 5/1999] [Panelindlæg, 5/1999] Titel, forfatter, år. Hvad er DanBib-for-folket? Per Mogens Pederersen, DBC. Artikel i Nyt fra Nyhavn nr. 4, 2. december DanBib for alle? Leif Andresen, BS. Artikel i Nyt fra Nyhavn nr. 1, 24. marts Debatoplæg til Åbne møder om DanBib for Alle. Jens Thorhauge, Leif Andresen & Lone Hansen. Biblioteksstyrelsen maj pid=0 DanBib for Alle Panelindlæg ved møder den 31. maj 1999 i Århus og den 2. juni 1999 i København. Karl Posselt, Alice Nørhede & Jakob Andersen. Juli pid=0 pid=0 pid=0 44

45 Appendiks Appendiks Appendiks A - Forkortelser Personer BW LA PMP Bo Weyman, IT-chef DBC. Leif Andresen, Bibliotekskonsulent BS. Per Mogens Pedersen, Divisionschef DBC. Andet bibliotek.dk BOB BS DBB DBC NfN Arbejdsnavn for projektet bag bibliotek.dk. Base over bestillinger, del af systemet bag bibliotek.dk. Biblioteksstyrelsen Dansk Blindebibliotek. Dansk BiblioteksCenter Nyt fra Nyhavn, BS nyhedsblad. 45

46 bibliotek.dk Appendiks B - Tidslinie Tid Kulturminister /ministeriet Oktober 1998 Udtaler at hun ønsker offentlig adgang til DanBib. December BS Arbejdsgruppen DBC Externe leverandører PMP beskriver hvordan projektet kan realiseres Januar 1999 Deltager i arbejdsgruppen Arbejdsgruppen dannes. Deltager i arbejdsgruppen Igangsætter udviklingen. Medio 1999 Arrangerer en række offentlige debatmøder omkring projektet. November 1999 December 1999 Arbejder på specifikationen for projektet. Lægger sidste hånd på specifikationen. Februar 2000 Integrationstests påbegyndes. Leverer første del af hardwaren. Hardwareleverancen er fuldstændig. Maj 2000 Den nye bibliotekslov vedtages, og hermed finansieringen for bib.dk. Juni 2000 Organisationsændring. Flere ugentlige møder med DBC (BW). Juli 2000 Certificere hardware (48 timers test). September Oktober 2000 Performance tests starter. Bibliotek.dk indvies af kulturministeren, som bestiller den første bog over systemet. 46

47 Appendiks Appendiks C - Referat fra møde med Per M. Pedersen Referat fra møde 27. sept. 2000, hos Dansk BiblioteksCenter, Tempovej i Ballerup, fra klokken 9.00 til Referatet er godkendt af Per Mogens Pedersen. Tilstede: Per Mogens Pedersen (PMP), Morten Primdahl (MP), Thomas B v Linde (TBL), Niels Erik Gilvad (NEG), Jacob W Jespersen (JWJ). Mødet var et indledende møde til introduktion af det DBC-projekt bibliotek.dk som skal være baggrund for rapport til kurset "IT-projektledelse" på IT-højskolen. Jacob, Morten, Niels Erik og Thomas gav først en præsentation af baggrunden for vores interesse for DBC og fortalte hver især kort om sig selv. PMP fortalte om starten på bibliotek.dk. Ideen til projektet blev bragt på bane offentligt af kulturministeren (Elsebeth Gerner-Nielsen?) i efteråret Det skete på en tale som formodentligt var forfattet af Biblioteksstyrelsen (BS). Ideen angik "offentlig adgang til Fælleskataloget," dvs. at alle borgere skal have adgang til den fælles database (DANBIB) der benyttes af alle offentlige biblioteker i Danmark. DanBib-Databasen indeholder 16 millioner records. I bibliotek.dk -basen er en oversigt over alle emner i disse bibliotekers arkiver; ca. 8 millioner records. Det inkluderer bøger, tidsskrifter, musik, video, osv. Der er ca offentlige biblioteker i DK: kommunale, amtslige, statslige, mm. Herunder "normale" biblioteker, forskningsbiblioteker, institutbiblioteker. Statslige biblioteker har indberetningspligt til databasen; folkebibliotekerne har ikke, men gør det overvejende. DANBIB drives i dag af DBC (siden 1994) fra deres adresse i Ballerup, og er i kraft af det et naturligt valg til udvikling af bibliotek.dk. Det lå i oplægget fra kulturministeren at der borgerne skulle have offentlig adgang til både at søge og bestille emner fra DANBIB, og det skulle kunne ske hjemmefra (egen computer). At der skulle indgå en bestillingsfunktion gjorde at projektet fik et særlig stort omfang. Et af målene med projektet var at opnå "mange biblioteker - een service." Bibliotekerne kan opdeles i 3 grupper: bogleverandører (uden slutbrugere), bogekspeditioner (ingen bøger, med slutbrugere) og en kombination (de fleste). 47

48 bibliotek.dk Et af PMPs fokusområder definerede han som "brugbarhed fremfor præcision," dvs. hellere få (brugbare) søgeresultater end en masse (alle?) uoverskuelige søgeresultater. Kommentar: det er vist ikke slået igennem. Kulturministeren bruger BS til at gennemføre ideen. BS nedsætter arbejdsgruppe som består af 2 statslige repræsentanter (1 bibliotekar (biblioteksleder) og 1 sagsbehandler fra BS) og 2 kommunale repræsentanter (1 sagsbehandler fra KL og 1 bibliotekar (IT-chef)). BS repræsentant i arbejdsgruppen er Leif Andresen, som fungerer som leder i gruppen. Hos DBC nedsattes en styregruppe med PMP som leder. Hele projektet involverer 10 delprojekter i DBC med hver sin leder; f.eks. databaseadm., brugergrænseflade, hardware, osv. BS hyrer DBC til at lave bibliotek.dk, men der eksisterer (stadig) ingen konkret aftale om projektet mellem de to parter. Kulturministeren har afsat 35 mill. kr. over 4 år til projektet. Beløbet fordeles som mill. over denne periode. Der er ikke aftalt nogen form for drift eller vedligeholdelse af systemet efter udviklingen er færdig mellem BS og DBC. Det ligger "i luften" at DBC skal varetage dette. Herefter fortalte PMP mere detaljeret om historien bag projektet. BS (Jens Thorhauge, direktør for BS)) kontakter DBC (PMP) "en lørdag formiddag på vej hjem fra Irma" og beder ham begynde at tænke over hvordan kulturministerens oplæg kan føres ud i livet. I januar '99 skriver PMP artikel til "Nyt fra Nyhavn" (biblioteks-brancheblad?) omkring bibliotek.dk som en slags projektudkast. Arbejdsgruppen etableres og der afholdes konferencer og møder landet over (og med nordiske gæster) for at diskutere projektet og erfaringer fra lignende projekter andre steder. I foråret '99 afholdes 2-3 "åbne møder" for biblioteksfolk i DK. Arbejdsgruppen fastlægger specifikationen i løbet af efteråret '99 og DBC starter projektet. Specifikationen af projektet har primært form af en række s mellem BS og DBC; en såkaldt "åben kravspecifikation." DBC ugentlige styregruppemøder afvikles uden at der tages referat, men der eksisterer statusrapporter, frem til , hvor projektets funktionalitet, opgavefordeling etc. ligger nogenlunde fast. 48

49 Appendiks Omkring sommer '99 angiver DBC en deadline 2/2/2000 som målet. Det viser sig, at projektet er sværere end forventet så denne deadline nåes ikke. En medvirkende årsag er, at ny bibliotekslov med passus om betaling for bestillinger via bibliotek.dk kommer til at påvirke beslutning om åbningstidspunktet, idet systemet ikke kan sættes i drift før loven er vedtaget og bekendtgørelsen udsendt; den første udskydelse af åbningsdatoen fra til maj 2000 er således begrundet i biblioteksloven, medens den senere udskydelse, fra maj til oktober 2000 primært er begrundet i fejl i hardwareleverancer mv. En anden, men absolut ikke afgørende, årsag til forsinkelsen har været tidskrævende brugstest og tilpasninger for at sikre tilgængelighed for synshandicappede. Disse tests er udført i samarbejde med Danmarks Blinde Bibliotek. Andre samarbejdspartnere og leverandører har været Araneum (design af brugergrænseflade), Index Data (Z3950-protokol-eksperter, DANZAP), ICL (hardware) og Hitachi (RAID-system). DBC er ISO9000-certificeret; PMP oplever i dag ISO9000 som en sparringspartner og ikke som en kvalitetskontrolfornastaltning. PMP nævner at nogle af hans folk "nok har savnet en projektsekretær." Problemer med hardware har betydet en stor forsinkelse, og disse problemer er pt. ikke løst. Hardware blev bestilt og leveret i november 99, men først i februar 00 er leverancen fuldtstændig, og man går ud fra at udstyret fungerer. Det viser sig i maj måned '00 at det gør det ikke. Fejlene bliver fundet, da systemet skal til at køre i installation/integrationstest. Leverandøren indrømmer, at udstyret (hardware og basissoftware) ikke er certificeret; denne certificering finder sted i juli måned. Udstyret kommer ikke i drift i perioden fra januar til maj, da projektet af andre årsager er forsinket. Test af performance er ikke foretaget endnu. På performance opereres der med at kunne klare en belastning svarende til Krak. Succeskriteriet bliver her nævnt som et ønske om at "håndtere dobbelt så mange bestillinger som nuværende (DANBIB) system." Det vil sige ca. 2 mill. bestillinger per år. "Overdragelsesforretningen" fra DBC til kunden (BS) vil foregå ved et brev fra PMP til BS som fortæller, at udviklingsprojektet er slut, og at systemet vil gå i luften på en given dato. 49

50 bibliotek.dk Drift og vedligehold af systemet skal ligge hos DBC; derfor er der ingen dokumenter omkring dette der skal overbringes til BS. Det er fortsat ikke aftalt hvilke krav der stilles til driften (åbningstid, belastning, svartid, osv.). DBC har afleveret et forslag til BS. PMP forventer at BS vil afskrive projektomkostningerne indenfor den 4-årige periode således, at: afskrivning = ramme - drift - nyudvikling. Udviklingen og idriftsættelsen af bibliotek.dk har indflydelse på DBCs nuværende indtægter fra driften af DANBIB. PMP forventer at miste indtægt fra DANBIB, hvis de professionelle kunder flytter til bibliotek.dk som (indtil videre) er gratis. Det imødegås ved at omlægge opkrævningen for brug af DANBIB fra en afgift for forbrug til en fast afgift afhængig af kommunestørrelse. Derudover forventer PMP at DBC mister ca. 2 mill. i indtægter fra udenlandske biblioteker og større danske selskaber som i øjeblikket betaler for at bruge DANBIB. Mht. ressourcestyring, så nævner PMP at det altid er "en kamp om ressourcer," men at projektet har været det højest prioriterede indenfor DBC og derfor har fået hvad der var behov for. Det har betydet problemer pt. pga. nuværende hardware-problemer som har lagt beslag på hardware-folk, som så må undværes på andre projekter. PMP fortæller, at der 15. juni '00 skete en organisationsændring i DBC, som har medført en opsplitning af det samlede ansvar, i store træk således: bibliotek.dk er som udviklingsprojekt forankret i Netdivisionen med PMP som projektleder. Der indgår i udviklingsprojektet projektressourcer fra primært IT-afdelingen (IT-chef Bo Weymann), Servicedivisionen (sektionsleder Kirsten Larsen) og Netdivisionen. Ved overgang til drift, vil produktansvaret være placeret i Netdivisionen med fortsat ressourcetræk i forhold til IT-afdelingen (drift, vedligehold, videreudvikling) og Servicedivisionen (primært hotline, undervisning og bidrag til videreudvikling) 50

51 Appendiks Appendiks D - Referat fra møde med Leif Andresen Referat af møde 13. okt. 2000, hos Biblioteksstyrelsen, Nyhavn i København, fra klokken til Referatet er godkendt af LA, hvis kommentarer er skrevet med kursiv. Tilstede: Leif Andresen (LA), Morten Primdahl (MP), Thomas B v Linde (TBL), Niels Erik Gilvad (NEG), Jacob W Jespersen (JWJ). Forud for mødet havde vi forberedt en række spørgsmål som vi ville søge besvaret: 1. Ansvarsområder Hvordan har fordelingen været? Anderledes end hvis leverandøren ikke var DBC? 2. Ledelsesform Kommunikation med styregruppen. Kommunikation med DBC. Styring af DBC. Styrkes BS-DBC dialogen ved at der er en primær kontakt begge steder, frem for direkte kontakt til underprojektledere? Kommunikation med kulturministeriet. Styring samt definition af interessenter: Biblioteker Specifikation Hvordan blev systemet specificeret? Krav? Var begge parter fra start enige om systemets endelige virke? I fald af modifikationer af specifikation, ændringsstyring? 4. Den subjektive dialog. Kendskabet/sammenhængen med DBC. Fordele og ulemper. Håndtering af 'hvad nu hvis...' situationer DBC ikke udviste samarbejdsvilje? DBC fik strammere time/money box? Tillid til leverandøren. 5. Opfyldte forventninger. Hos BS, DBC, ministeriet. Stemmer produktet overens med initiale forventninger? 51

52 bibliotek.dk Mødet startede med, at LA kommenterede mødereferatet fra vores møde med Per Mogens Pedersen (PMP) fra DBC. I den forbindelse korrigerede han tallet for det antal biblioteker som direkte indgår i bibliotek.dk; det korrekte tal er ca fordelt i ca. 240 "bibliotekskommuner" som igen er opdelt i en række biblioteksforbund. Som PMP også nævnte, er de 1300 biblioteker inddelt i 3 kategorier: biblioteker med "intet udlån", nogle med "offentligt udlån" og en gruppe med "begrænset udlån". NEG gav en kort introduktion til os og hvad vores projekt går ud på. LA fortalte kort om baggrunden for den nuværende situation på biblioteksdatabaserne. På europæisk plan er det typisk at hver land har et "National Union Catalog" over sit offentlige biblioteksvæsens emner. I Danmark har man haft 2 separate kataloger: et forskningsorienteret og et offentligt. LA: Det er normalt kun for forskningsbiblioteker er der er NUC'er for For 6-7 år siden pressede en modernisering af det forskningsorienterede katalog sig på, og det blev foreslået (af PMP og?) at foretage en sammenlægning med det offentlige i samme ombæring. LA:?? er daværende rigsbibliotekar Morten Laursen Vig Udvikling og drift af databaserne var fordelt på KommuneData og FEK (forskning). Nu fusioneres FEK og DBC, og DBC overtager al udvikling og drift af det fælles katalog, DANBIB. "Opdragsgiverne" (for udvikling og drift af DANBIB) udgøres af stat og kommuner i forening, og de står samlet som part i aftalen med DBC. Denne model ændres i forbindelse med bibliotek.dk således, at det alene er et projekt mellem DBC og staten, repræsenteret af Biblioteksstyrelsen (BS). LA gennemgår ændringerne til afregningen for forbrug af systemet (ift. kommuner og andre) som også PMP nævnte. Ændringen er en konsekvens af, at den nye gratis tilgang til bibliotek.dk uværgeligt vil trække kunder fra DANBIB, som jo koster penge. LA: DanBib-aftalerne ændres m.h.t. prismodellen, idet der formelt åbnes mulighed for at der afregnes efter andet end forbrug. Men DanBib-aftaler er fortsat mellem de hidtidige opdragsgivere (KL, KBn og Frederiksberg kommune + staten) LA understreger at aftalen om bibliotek.dk (mellem BS og DBC) ikke er en selvstændig aftale, men at den bygger på eksisterende aftale om DANBIB. I den forbindelse har DBC eneret på leverance af DANBIB-systemer til Biblioteksstyrelsen, dvs. til bibliotekerne i Danmark. Hvis aftalen om DANBIB ikke havde eksisteret, så havde man være nødt til at gennemføre en traditionel udbud- og licitationsrunde, hvor formelle kravspecifikationer, selvstændige kontrakter, budgetter, mm. ville skulle indgå. 52

53 Appendiks I den foreliggende situation (med en aftale om DanBIB) blev aftalen om bibliotek.dk indgået som "en ramme" som gennem dialog mellem BS og DBC skulle udfyldes bedst muligt. LA angav, at de primære mål i projektet var hurtigst muligt at give åben, offentlig adgang til fælleskataloget med mulighed for bestilling af emner til afhentning på brugerens foretrukne bibliotek. Et vigtigt princip i udviklingen af projektet var, at det skulle passe i gældende normer/teknik/politik på bibliotekerne. Projektet måtte ikke ændre på disse. Dette princip blev valgt for at minimere modstand undervejs fra netop bibliotekerne. En konsekvens af princippet er, at enhver bruger (låner) i bibliotek.dk fortsat er knyttet til et bibliotek (som har godkendt låneren). Bestillinger fra en given bruger er således at betragte som en bestilling fra brugerens bibliotek, som derfor har ansvaret for det udlånte. I projektspecifikationsfasen indgik en række parter (som også PMP oplyste). LA fortalte om fasen, hvor et debatoplæg og "åbne møder" i henholdsvis København og Århus den 31. maj og 2. juni 1999 søgte at inddrage ideer og kommentarer fra repræsentanter fra bibliotekerne. Der blev diskuteret dels "hva' nu" (de direkte konsekvenser af projektet) og visioner for projektet på længere sigt (f.eks. muligheden af banner-reklamer på bibliotek.dk). LA mente, at de åbne møder ikke havde bragt nyt på banen, men at man havde fået bekræftet en række forhold, som var kendte i forvejen. Der var dog én ændring til eksisterende praksis i bibliotekernes bestillingssystem, nemlig at enhver bestilling gennem bibliotek.dk skal godkendes manuelt af det bestillende bibliotek. Denne praksis blev indført som svar på manges bekymring (også luftet på de åbne møder) over en mulig "stormflod" af bestillinger. Basen over bestillinger (BoB) er den eneste egentlige rationalisering i bibliotek.dk. BoB skal bruges af bibliotekerne til at videresende bestillinger (uden at skulle oprette en ny bestilling). LA: Det er ikke en ændring, men en videreførelse af praksis. Og den blev ikke opfundet undervejs, men lå klart fra starten. Det var BoB's nye funktionalitet, som blev opfundet undervejs. I den forbindelse blev det også diskuteret, om man burde have et centralt brugerregister (lånerregister), men det blev droppet. Som eksempel på ide til kommende udvikling af bibliotek.dk nævnte LA muligheden for at forespørge på udlånsstatus for emner på fjernbiblioteker lige så nemt, som det i dag sker for emner på lokalbiblioteket. LA fortalte, at ingen i Kulturministeriet har fulgt projektet aktivt undervejs, men at Kulturministeriet løbende er blevet holdt orienteret. BS fungerer i princippet i en slags departemental rolle i forhold til bibliotek.dk. 53

54 bibliotek.dk bibliotek.dk -projektet har haft 2 faser. I projektets 1. fase (specifikationsfasen) har BS' styregruppe jævnligt holdt møder med DBC samt afholdt åbne møder m.m. Denne fase strakte sig frem til december 1999, hvor styregruppen holdt sit næstsidste møde. (Det sidste møde blev holdt i juni 2000.) I projektets 2. fase (implementationsfasen) har der ingen formelle møder været mellem BS og DBC, men fortsat en række uformelle møder (ca. 1 møde per måned) og en lang række s og telefonkontakter. LA opgør ansvarsfordelingen i projektet således, at DBC har ansvaret for teknikken og BS har ansvaret for politikken. BS konfererer med Biblioteksrådet i overordnede spørgsmål; DBC refererer til Brugerrådet. I oktober 1999 afholdtes møde om service deklarationer. "Service deklarationer" er et middel til at håndtere det faktum, at forskellige biblioteker tilbyder forskellig service. Gennem en service deklaration skal brugerens forventninger tilpasses den service som et givent bibliotek vil tilbyde (qua reglementer/metoder/aftaler/tradition). Der er 2 sider i en service deklaration: en "prosa-stil" og en servicefunktionsbeskrivelse. Med sidstnævnte er det muligt på en standardiseret måde at få at vide, hvilken service biblioteket tilbyder. For at sikre at den færdige løsning ville kunne accepteres af bibliotekerne har LA undervejs foretaget "personlige Gallups". Det har bestået i, at han har kontaktet biblioteksansatte som han kender personligt. I samtale med dem har han hurtigt og uformelt prøvet ideer af for eventuelt at justere kursen for projektet. LA: Jeg har brugt dem til belysning af enkelte spørgsmål. Forespurgt om bibliotekerne generelt har været tilfredse med projektet, svarer LA, at nogen bekymring blev luftet på møderne i juni 1999 fra forskningsbibliotekerne omkring det ønskværdige i en samlet offentlig adgang. Fra den side var det foretrukket at bruge egen eksisterende bestillingsfunktion (OPAC). Der var fra omtrent samme side utilfredshed med, at det bibliotek som ejer det bestilte materiale ikke profileres tiltrækkeligt i forhold til brugeren. LA har modgået denne kritik med en holdning om, at det er materialet, som har krav på profilering, og ikke biblioteket. I erkendelse af, at der er stor forskel på den service bibliotekerne yder, opstår ideen om service deklarationer undervejs i projektet. På spørgsmålet om ændringsstyring undervejs i projektet fortæller LA at DBC "udvikler bibliotek.dk mhp. salg af systemet til staten", underforstået, at det er DBC's ansvar at sørge for, at systemet har den ønskede funktionalitet, herunder at foretage de ændringer som skønnes nødvendige undervejs. DBC arbejder således på "forventet efterbevilling"; i praksis skal biblioteksloven vedtages før projektet officelt kan bestilles hos DBC. Skulle man have ventet på dette, samt på at 54

55 Appendiks man havde færdiggjort hele specifikationsfasen, så havde DBC først kunnet starte projektet i juni, LA: loven blev vedtaget i maj 2000 LA nævner, at DBC principelt er i samme situation som firmaer der udvikler "plasticsoftware" (d.v.s. "off-the-shelf" software): deres kunder køber først produktet, når det er færdigt. I DBC's tilfælde er der naturligvis i praksis ingen risiko for, at BS ikke køber produktet, forudsat at pengene bevilges på finansloven. DBC har brugt betydelige ressourcer på projektet indtil i dag og er tvunget til at få en aftale på plads. Det faktum, at BS ikke har underskrevet en købsaftale på bibliotek.dk endnu, gør, at BS i nogen grad kan gennemtrumfe vilkår/ændringer for den kommende aftale. BS fører forhandlinger omkring aftalerne med direktøren for DBC (Mogens Brabrand). LA: Det har jeg nu ikke sagt. Jeg mener ikke at tidspunktet - heller ikke forsinket - har nogen betydning for indholdet af aftalen. Bevillingen på finansloven (35 mill. over 4 år) er afsat alene til at dække driften af systemet. DBC afskriver derfor udviklingsomkostningerne over driftsbudgettet på den måde PMP har beskrevet. Nyudvikling på systemet skal også dækkes af driftsbudgettet. Efter det 4. år skal der hvert år aftales hvad driften skal koste; anslået 10 mill. per år. Adspurgt ser LA ulemperne ved den benyttede aftalemetode mellem BS og DBC som en risiko for at miste overblikket over projektet og hvad det indeholder. Den åbner mulighed for, at leverandøren kan manipulere til egen vinding undervejs i projektet, og kræver derfor stor tillid mellem parterne. LA: Der er også stor tillid mellem DBC og BS LA tror ikke, at BS ville lave tilsvarende aftale med et traditionelt kommercielt firma; DBC ejes overvejende (X %) af staten. LA: 92% af staten og kommunerne (KL + Kbh), men staten ejer mindre end 50%. Til gengæld er der en musketeraftale, nemlig at staten ikke kan overrules m.h.t.danbib. Der er ikke angivet nogen formelle tekniske krav fra BS overfor DBC. Mht. uformelle krav til performance og stabilitet, så nævner LA at "det skal holde" og at "det går ikke ned". En belastningstest, udført af DBC og godkendt af BS, skal bevise, at systemet kan klare ønsket belastning inden det går i luften. Den godkendte belastningstest vil være BS' dokumentation overfor Kulturministeriet på, at man har forsøgt at gardere sig bedst muligt. PMP har oplyst til LA, at systemet kan klare 4000 samtidige brugere. LA oplever nuværende hardwareproblemer hos DBC som en konsekvens af, at DBC udfører belastningstests og derfor finder kapacitetsproblemerne nu og ikke først, når systemet er luften. Så det er godt, at problemerne opdages nu. 55

56 bibliotek.dk BS' styregruppe holdt sit næstsidste møde i december 1999 og har således ikke samlet fulgt projektet i implementationsfasen. Her har alene LA overordnet repræsenteret BS i projektet. Karakteren af den information, som de enkelte biblioteker lægger ind i bibliotek.dk om sig selv, er tilrettelagt i samarbejde med bibliotekerne. Også her er LA's "supplerende Gallups" blevet benyttet. LA: Det var primært her. En del af forsinkelsen af bibliotek.dk skyldes den udskudte vedtagelse af den ny bibliotekslov (den vedtages i januar 2000). Særligt en passus om, at bestillinger via bibliotek.dk skal pålægges afgift på 5-7 kr. per bestilling har betydning for projektet. Det ender dog med, at loven kun bemyndiger, og ikke pålægger, ministeren at opkræve afgiften. LA: Den nu lov fremsættes og vedtage i maj 2000 Afgiften kommer angiveligt med i loven for at den kan indgå i et regnestykke, hvor den politiske intention er, at resultatet skal vise, at bibliotekerne kan være selvfinansierende. Mht. forsinkelsen af bibliotek.dk p.g.a. DBC's hardware-problemer, så nævner LA, at det primære er, at systemet fungerer, når det sættes igang. Kun sekundært at man holder deadlines. Og ministeriets holdning er den samme. Historien om "danmark.dk" skræmmer. LA har tillid til, at DBC gør alt, hvad de kan for at løse hardware-problemerne, og at de kan løse dem. LA har ikke lagt særligt pres på DBC for at få løst hardwareproblemerne hurtigere. Han mener, at DBC rigeligt er presset af det prestigetab, der følger af ikke at kunne levere en fungerende løsning til aftalt tid. LA er tilfreds med projektet og dets forløb indtil videre, og det er hans indtryk, at det er bibliotekerne også. 56

57 Appendiks Appendiks E - Referat fra møde med Bo Weyman Referat af møde 26. okt. 2000, hos Dansk Bibliotekscenter, Tempovej i Ballerup, fra klokken til Trods gentagede forsøg er det ikke lykkedes at få kontakt til BW, hvorfor referatet er ikke blevet godkendt af ham. Tilstede: Bo Weymann (BW), Niels Erik Gilvad (NEG) og Jacob W Jespersen (JWJ). NEG og JWJ præsenterede kort os selv og baggrunden for vores interesse i bibliotek.dk. NEG forklarede at vores fokus ligger på en interessentanalyse samt at undersøge årsager til og konsekvenser af den valgte projektmetode. BW gjorde opmærksom på, at mht. folkebibliotekerne som interessent, så burde man behandle centralbibliotekerne (store folkebiblioteker) og de andre (folkebiblioteker) for sig, da centralbibliotekerne i høj grad har ambitioner om selv at stille services (lignende bibliotek.dk) til rådighed for brugerne. Centralbibliotekerne har derfor en anden dagsorden i forhold til bibliotek.dk end andre folkebiblioteker har. De har iøvrigt deres egne databaser, som i dag sender poster til DanBib. BW fortalte, at Dansk Bibliotekscenter (DBC) ikke har eneret på udvikling af databaseydelser til bibliotekerne eller Biblioteksstyrelsen (BS), men at DBC har eneret på at udvikle services "ovenpå" det eksisterende DanBib, f.eks. bibliotek.dk. Data i DanBib ejes dels af DBC (nationalbibliografier), dels af staten/kommunerne (fælleskataloget). Hardware/software og diverse systemer til kontrol heraf ejes af DBC. Af andre interessenter nævnte BW Blindebiblioteket som igennem projektforløbet har spillet en væsentlig rolle for at varetage blindes særlige krav til systemets design. Desuden har DBC samarbejdet med andre videncentre om synshandicappede. BW har frem til maj '00 alene været udviklingschef for bibliotek.dk. Fra maj '00 og frem har han desuden været chef for driftsafdelingen, herunder den afdeling som står for integrationstest. 57

58 bibliotek.dk Som også PMP nævnte, så er Netbureauet Araneum leverandør af brugergrænsefladedesignet (i samarbejde med DBC) og Index Data er leverandør af komponenter til databaseforespørgsler. Når udviklingsfasen er færdig, vil vedligehold og videreudvikling af brugergrænsefladen varetages af DBC alene, mens Index Data fortsat vil være involveret under drift og videreudvikling. bibliotek.dk skal efter planen "gå i luften" tirsdag d. 31. okt. (dvs. 5 dage fra d.d.) Mht. til de hardware/software problemer, som har forsinket projektet, så fortæller BW at de væsentligst dukkede op da DBC gik fra integrationstest til driftstest. Udvikling: fra forsommer '99 til efterår '00. Integration: fra feb. '00 til efterår '00. Drift: fra nov. '99 (indkøb af udstyr) og frem (1. afl. fra integration maj '00). Mht. til kravspecifikation (fra PMP som "bestiller" udvikling hos BW) så fortæller BW, at der ikke foreligger en formel kravspecifikation fra start, pga. den måde som projektet er påbegyndt. Først undervejs i forløbet har de involverede erkendt kravene til systemet. Fra en start som "DanBib for Folket" (med simpel søgning i DanBib) til nuværende bibliotek.dk med søgning og bestilling er den ønskede funktionalitet løbende blevet udvidet. BW har lovet at give os eksempler på hvordan kravene er specificeret i løbet af projektet i form af dokumenter. Den væsentligeste årsag til at der ikke ligger en traditionel kravspecifikation ved projektets begyndelse er i følge BW, at PMP ikke har modtaget en sådan fra BS. DBC (PMP og BW) har skønnet at ca samtidige brugere er et rimeligt tal for den belastning bibliotek.dk skal kunne klare i drift. Det svarer til omtrent den belastning Krak's site løfter. BW har iværksat et performance projekt for bibliotek.dk omkring maj '00 som også er det tidspunkt, hvorefter BW afviser yderligere funktionalitetsændringer og forslag. Performance test starter omkring september '00. På åbningsdagen for bibliotek.dk forventer BW en særlig stor belastning på systemet som iøvrigt ikke står i forhold til den forventede gennemsnitslige belastning. DBC mener ikke at driftsystemerne bør skaleres efter en enkelt dags belastning. Denne holdning er i følge BW tydeligt kommunikeret på et møde på direktionsniveau mellem BS og DBC, hvor de respektive direktører samt PMP, BW og Leif Andresen (LA) deltog. 58

59 Appendiks Der er for nylig truffet aftale mellem DBC og BS om kravene til driftssystemet: oppetid på 99% ml. klokken 8-22 og "core" funktioner må max. være nede i 4 timer/måned. DBC benytter "UniCenter" til driftsovervågning. DBC har haft store problemer med leverancer af hardware/basissoftware. Det har betydet at BW siden maj '00 har afholdt møde med leverandørerne af dette 1-3 gange per uge og BW har haft adgang til direktionerne disse steder. Allerede den første leverance i nov. '99 var fejlbehæftet. Diverse fejl og mangler gør, at DBC først i marts '00 kan starte egentlig integrationstest. Over sommeren bliver man opmærksom på, at kombinationen af hardware/basissoftware ikke er certificeret (af Sun) og gennemførelse af dette sker i DK og i England. Certificeringen (48 timers test) lykkes først efter flere forsøg og efterlader et indtryk af, at der fortsat kan være problemer. BW fortæller, at DBC agter at gøre krav gældende overfor leverandørerne af hardware og basissoftware pga. de konstaterede fejl og mangler. Igennem forløbet (med problemerne) har der været et tæt parløb mellem PMP, BW og lederen af testen (navn?), og man har næsten dagligt justeret løsningsstrategierne. BS har accepteret forsinkelsen af projektet pga. nævnte problemer, hvad BW finder naturligt idet BS jo ikke formelt har bestilt bibliotek.dk endnu. BW nævner, at BS's udlægning af projektet overfor bibliotekerne som "bibliotek.dk er baseret på kendt teknologi" ikke er helt i overensstemmelse med fakta. DBC's projektmetode er ikke baseret på nogen formel metode, f.eks. vandfaldsmodellen. DBC har bevidst fravalgt al form for bureaukrati og fokuserer istedet på at finde de rigtige personer til at styre projektet. Et vigtigt led i DBC's projektstyring generelt er ugentlige møder mellem projektets nøglepersoner, BW og PMP. Et andet vigtigt led er en høj grad af autonomitet for projektets dele sålænge aftaler holdes og målene nåes. For bibliotek.dk gælder det, at flere af delprojekterne har arbejdet med kendte DBCkomponenter, bla. DanBIB og dbclib, mens især bestillingssystemet er helt nyt. Da flere af komponenterne benyttes i andre sammenhænge (end bibliotek.dk) er der undervejs blevet taget hensyn til og koordineret med andre projekter i DBC. DBC er ISO 9000-certificeret. BW har lovet, at vi kan få lov at se de dokumenter der beskriver den foreskrevne metode for DBC projektforløb. 59

60 bibliotek.dk Ændringsstyring er foretaget ad hoc, hvor man i høj grad har truffet beslutninger "i vadestedet". BW fortæller, at DBC lægger vægt på et stort fokus i projektet og en tæt personkontakt projektdeltagerne imellem. BW understreger, at fremfor en meget formaliseret projektmetode, så er det vigtigt, at projektdeltagerne kører efter samme slutmål. Derfor skal alle være enige om hvad målet er. De bedste DBC-projekter er forløbet uden formel metode, og der er eksempler på at meget formelle og veldokumenterede DBC-projekter er "gået ned i flammer". DBC har lige så stor eller større interesse end BS i, at bibliotek.dk bliver en succes. Det er meget vigtigt for DBC at have en goodwill hos bibliotekerne, derfor har DBC en strategisk interesse i at levere et godt system med en masse funktionalitet og et godt design. BW mener, at formelle projektmetoder kan gøre gode projekter bedre, men det kan ikke gøre et dårligt projekt godt. DBC's metode medfører en høj grad af personafhængighed, men BW mener ikke, at det er et problem. DBC har gode folk og har ikke problemer med at tiltrække kvalificerede medarbejdere. For bibliotek.dk mener BW, at udviklingsholdet havde været langt bedre stillet, hvis der havde eksisteret et bedre designoplæg og en konkret kravspecifikation. For DBC-projekter generelt gælder, at DBC er gode til at identificere brugerkrav og finde en løsning på disse, men dårlige til at omsætte løsningen til noget som udviklerne direkte kan arbejde med. BW mener at dét er et alvorligt problem som der bør arbejdes med. Samlet set, så er det et problem, at der har manglet formelle krav til den løsning som udviklerne har skullet levere. Der har manglet rammer for kodearbejdet og det fører til for mange fejlskud. Som eksempel nævnes BOB (base over bestillinger) hvor kravene først var fuldt ud kendt her til efteråret. Det betyder, at udviklerne har kodet inden specifikationen var færdig og derfor selv har måttet "fylde de blanke ud". BW betegner projektindsatsen på analyse og design som svag, mens den er stærk på kodning og test. Projektdeltagerne (og DBC's organisation i det hele taget) øger typisk fokus/resourcetildeling eksponentielt op til projektets afslutning. BW mærker, at medarbejdernes engagement og arbejdsindsats er stærkest op til en deadline. Det er svært at være 100% motiveret/fokuseret i projektets startfase. 60

61 Appendiks BW planlægger et evalueringsseminar om "projektet som projekt" som skal diskutere de gode og dårlige ting i projektforløbet/metoden. BW er klar over at andre (firmaer) arbejder med at optimere projektet som proces, men har ikke haft tid til dette arbejde. Et særligt forhold i DBC's projekter er, at der typisk udvikles systemer som skal køre i drift hos DBC selv. Det gør, at afleveringen af et projekt ofte blot sker fra en DBC afdeling til en anden, og det har betydning for måden det foregår på. BW's primære succeskriterie for projektet har været at holde rammen på kr. 5 mill for det første år, dvs. at levere den ønskede funktionalitet indenfor rammen. Og at "andre end os (DBC) har den opfattelse". Desuden har et succeskriterie været at levere systemet baseret på komponenter af en høj kvalitet som DBC kan genbruge i kommende projekter. Endelig har det været succeskriterie at få udviklet et velfungerende og attraktivt bibliotek.dk som måske på lang sigt kan være en portal som DBC kan leve af. "Blive et kendt site". 61

62 bibliotek.dk Appendiks F - Referat af møde med Dansk Blindebibliotek Referat af interview med Dansk BlindeBibliotek, torsdag den 16. november Referatet er ikke blevet godkendt af DBB, da det ikke kunne nås inden deadline. Tilstede fra DBB: Thomas Kellberg Christensen og Susie Christensen Tilstede fra IT-højskolen: Niels Erik Gilvad (ref.) TKC og SC indledte med at svare, at DBB's grundlæggende succeskriterium for DanBib for Alle projektet var "lige adgang for alle". Derefter beskrev TKC og SC kort forløbet og DBB's involvering i projektet. DBB har været engageret på konsulentbasis for BS i projektet. TKC bidrog således med et indlæg i oplægget til de åbne møder om DanBib for Alle i maj/juni Undervejs i design processen havde DBB møder med DBC og Araneum om brugergrænsefladen. DBB ville gerne have været med fra starten af denne proces og beklagede at det ikke var sket. SC udbyggede, hvad DBB mente med "lige adgang for alle": Hjemmesider skal kunne bruges med de hjælpemidler som blinde benytter sig af. Der skal være en konsekvent grænseflade Der skal tages højde for at ikke alle kan bruge mus Hvis der er grafik, skal der være alternativ-tekster til billederne Informationerne skal placeres i en hensigtsmæssig rækkefølge, fordi siderne læses sekventielt af skærmlæseren DBB deltog i en test i slutningen af DBB fortæller, at "den gik helt galt". Siderne kunne ikke bruges af blinde. DBB lavede derefter et koncept med frames i stedet for tabeller, i begyndelsen af men det er ikke implementeret. I mellemtiden var der kommet betydeligt bedre skærmlæsere, som blandt andet håndterer tabeller bedre. Siderne blev igen testet i forsommeren på Institut for blinde og svagtseende. Resultaterne var bedre men testen skulle dog tages med det forbehold, at det var de samme testpersoner som sidst, hvilket betød, at de allerede kendte siderne. Forespurgt hvilke mangler der var ved siderne efter offentliggørelsen, opregnede TKC og SC følgende problemer: 62

63 Appendiks Bruger man piletasterne til navigation - som blinde gør - kan man ikke skifte søgeniveau (almindelig, avanceret, kommando, osv). Der skiftes automatisk side til den første af søge-siderne (med onchange på select-listen), hvis man med piletasterne forsøger at bladre ned gennem søgemulighederne. Velkomsttekst og hjælpetekster er uhensigtsmæssigt placeret - de kommer sidst i oplæsningen af forsiden Søgesiden har links til hjælpetekster, og disse links er forsynet med meget lange [alternativ]-tekster, som skærmlæsere automatisk læser op, hver gang siden åbnes TKC siger i øvrigt, at siden ikke overholder W3C's anbefalinger for tilgængelighed, WAI. TKC og SC gav udtryk for utilfredshed med processen. Dels var DBB kommet for sent ind i processen på et tidspunkt, hvor designet af grænsefladenvar i fuld gang og dernæst, fandt DBB ikke, at deres arbejde blev taget alvorligt af DBC/Araneum. Der blev rettet en del basale problemer efter testen i 1999, men "siden er der ikke sket meget". bibliotek.dk rangerer således lavt i DBB's årsplan, hvor DBB's forskellige aktiviteter evalueres. DBB har erfaringer fra andre projekter, herunder forskningsbiblioteks projektet DEF, hvor processen med at gøre siderne tilgængelige er gået langt bedre. TKC og SC fandt at det var synd for projektet, fordi det er første gang at blinde og svagtseende får en reel mulighed for at skabe sig et overblik over materialebestanden på bibliotekerne. 63

64 bibliotek.dk 64