KL's webportal fanget mellem faste priser og fede features

Projektleder i KL, Adam Osbirk-Jensen: Hvad gik projektet ud på?

I første omgang gik det ud på at få konsolideret vores web. Vi hoster udbudsportalen.dk, danskekommuner.dk og kl.dk, og vi har en masse domæner, som har fået lov at knopskyde rundt omkring. Vi ville gerne samle det hele på et webbaseret CMS, der hedder Episerver.

Vi har konsolideret kl.dk, der tidligere har været på Portalservice, og danskekommuner.dk, som har kørt på gammel CMS, der hedder Coma. Derudover har projektet også omfattet udbudsportalen.dk, som kommer inden for en måned, og som også tidligere har kørt på Coma.

Endelig er der tre lukkede digitale projektrum, som vi også har set på at konsolidere på Episerver.

Hvad var målet med projektet?

Vi laver en masse dokumenter, høringssvar, procesguides og vejledninger til forskellige typer af opgaver i kommunerne. Det er jo noget viden, der kun er aktivt, hvis der er nogen der bruger det. Det vil sige, at vi skal have det ud til vores medlemmer.

Vi bruger journaliseringsplanen fra vores ESDH-system (Elektronisk Sags- og Dokumenthåndtering, red.) som forretnings-metadata på CMS'en. Det betyder, at når vi på et tidspunkt får skiftet vores gamle ESDH-system ud, vil vi gerne have et samlet system med CMS som præsentationslag for dokumenter i ESDH-systemet med journaliseringsplanen som det metadata, der sikrer vidensdistributionen fra ESDH til CMS og dermed til kommunerne.

Derudover her vi gerne villet sikre effektivisering af vores interne arbejdsgange, og at forfatterne af materiale til hjemmesiden ikke skal forholde sig til en hierakisk træstruktur i CMS'en, men bare skal skrive sit indhold og kategorisere indholdet. Så bliver indholdet automatisk præsenteret i de rigtige sammenhænge og på de rigtige steder. På den måde opnår du en større effektivisering, fordi info-medarbejderne holder sig til at producere indhold.

Hvad har din rolle været i projektet?

Jeg har været projektleder. Vi begyndte med at lave en analyse af CMS-markedet og så på, hvilke systemer der var tilgængelige. Vi havde en række kriterier til, hvad KL's system skulle kunne. Vi nåede vi frem tre valgmuligheder og valgte Episerver.

Derudover har min opgave været at udarbejde kravspecifikationer, kontraktforhandling, valg af leverandør, analysefase og selve projektledelsen under udviklingen af projektet. Hvilke tekniske løsninger er det baseret på? Det er baseret på Episerver CMS. Vi har derudover lavet et brugerregister, fordi Episerver er et web-CMS. Det er en SQL-database omgivet af webservices. Når vi får vores nye ESDH-system, vil vi gerne have, at arkitekturen er så tæt på SOA (serviceorienteret arkitektur, red.), som det praktisk muligt kan lade sig gøre.

Databasen indeholder alle brugere, abonnenter, ekstranet-brugere og kommer muligvis til at indeholde Mostrup-kontakter fremover. Det hele er så pakket ind i webservices for fremover at kunne understøtte det nye ESDH-system.

Så har vi benyttet os af Episerver Composer, som er et add-on til Episerver. Det gør, at du trække elementer på hjemmesiden rund modulært som drag and drop med musen, og det virker ikke kun på det pågældende domæne, men kan flyttes til andre domæner.

Derudover har vi brugt endnu et add-on til Episerver, Imagevault, som bruges til at organisere, redigere, versionsstyre og søge i de omkring 22.000 pdf'er, vi ligger inde med.

Til sidst har vi en Access-database på vores gamle ESDH-system, hvor emner og facetter i ESDH-journaliseringsplanen opdateres og vedligeholdes. Derfra bliver de så udlæst til en SQL-server, og derfra er der et script, som indlæser det til Episerveren. Grunden til, at det ikke er mere webservicebaseret, er, at det er et gammelt ESDH, som alligevel skal skiftes til et nyt. Det er lidt en 'høkerløsning', som skal skiftes, når det nye ESDH kommer.

Hvilke problemer er I stødt på undervejs?

Som de fleste offentlige og organisatoriske virksomheder er vi også budgetorienteret. Vi er nødt til at præsentere for beslutningstagere, hvad det kommer til at koste. Så bevilger de nogle penge, som vi så har at købe for.

Det er den gamle vandfaldsmodel. Men vi ved jo også godt, at man lynhurtigt bliver meget klogere, når man bevæger sig ned i materien i et projekt. Der kommer hurtigt nogle webparts, der måske skulle kodes anderledes eller noget andet.

Vi har derfor kørt selve projektet som et agilt projekt, og derfor har vi måttet lave nogle retningslinjer for, hvornår vi er inden for den agile ramme.

Vi har som kunde skullet forstå, at vi ikke bare kan forvente en masse ændringer undervejs, for leverandøren har givet en fast pris på projektet, og de har som leverandør skullet forstå, hvad det var for en løsning, vi gene ville have helt ned i dybden for at komme så tæt på som muligt i de agile sprints (delleverancer, red.)

Vi har valgt at køre det agilt, fordi vi jo godt ved, at vi ikke har fundet alle de vise sten - at vi ville blive klogere efterhånden, som projektet skred frem.

Men det er supersvært, at man på den ene side vil betale fast pris, men på den anden side gerne vil have mulighed for at skære kravene til undervejs.

Vi var ikke kommet ret langt ind i projteket, før vi opdagede, at vi manglede nogle webparts, der præsenterer de indloggede brugere for , hvilke arrangementer, de har tilmeldt sig, og hvilke Ekstranet de er medlem af.

På den ene side er det en del af en god løsning, at man har noget personalisering. På den anden side er det noget nyt, der skal kodes. Vi lavede den aftale med leverandøren, at hvis der var noget opsætning eller konfigurering, så lå det inden for den agile ramme, men skulle der kodes et eller andet nyt, så var det penge op af lommen fra os.

Derfor var vi også meget klare på fra begyndelsen at finde ud af, hvordan vi kunne bruge standardsystemet fuldt ud frem for hele tiden at få kodet et eller andet nyt, fordi vi fik en god idé.

Hvilke gode råd kan du give videre?

Det kræver et godt samarbejde og en god ånd mellem kunde og leverandør at køre et projekt agilt. Vi har benyttet os af et track changes system og så vidt muligt referater for at i sidste ende har kunnet være enige om, hvilke ting der hørte under den agile ramme, og hvilke der ikke gjorde. Lige pludselig er løsningen jo ikke helt det samme, som der stod i kontrakten, og derfor skal man have styr på sit papirarbejde.

Der er skrevet rigtig mange lærebøger om agil projektledelse, men man skal huske grundprincipperne i det: du bliver klogere undervejs og sørg for at have flere delleverancer.

Derudover er det meget vigtigt at have en ultrapragmatisk tilgang til det, fordi tingene ændrer sig og afhænger af, om man kommer godt ud af det med leverandøren.