Offentligt udslæt - del 2

Beklager at dette indlæg har været så længe undervejs, når der nu blev lovet at det kom "inden længe".

Men det skulle altså først lige i udbud, såeh ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Siden sidst..
...er der jo løbet meget vand i åen og en del større IT projekter er kørt i hegnet. Ingen nævnt, ingen glemt - men alle projekter havde sikkert en rigtig god grund til at være dødfødte eller kollapse under deres enorme vægt.

For selvfølgelig skal store strategiske projekter netop være, ja lige præcis: Store !
Men har succeskriterierne for store strategiske tiltag (IT eller ej) ikke alle dage været, at de rodfæster sig i organisationen og at de involverede forstår problemstillinger, løsningsmodeller og gevinster ved enhver strategi ?

Hvordan opnår man så at store offentlige IT projekter opfylder disse kriterier - vel at mærke under hele forløbet fra undfangelse til endelig produktionsstadie ?

Vel ikke ved at kræve brug af mega-uhyggeligt store og ofte uafprøvede teknologisk infrastruktur ?

Og vel heller ikke ved at kræve at leverandøren benytter såkaldte de facto SOA standarder (I kid you not, denne formulering optrådte som et krav i et udbud for nylig...)

Smidigt nok ?

Som flere af kommentarerne til mit tidligere indlæg var inde på, så ligger det jo i udbudsformen at man skal have det hele med, når man nu er godt i gang - og enkelte nævnte også, at man skulle lægge vægt på at få kravene beskrevet utvetydigt og præcist fra kundens side.

Jamen er det i så fald ikke der vi skal tage fat ?

Hvis det er et must at alle krav skal kunne beskrives utvetydigt og præcist fra starten, så må vi nøjes med at liste de krav som vi KAN beskrive på denne måde - nemlig de overordnede mål og rammer der er til løsningen.
Og kontrakten skal så være smidig nok til at kunne rumme en mere generisk prismodel og en iterativ samarbejds/udviklingsmodel, som implicit løbende validerer de oprindelige krav.

Utopi ' Naivt '

Måske - men i så fald er jeg ikke alene - og det luner altid lidt ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Den norske tanke

Via en norsk konference om smidighed (agile) fandt jeg et link til nogle håbefulde nordmænd hos "Direktoratet for forvaltning og IKT", som igennem længere tid har arbejdet med en ny standardkontrakt rettet mod "smidige" projekter

Titlen på aftalen er:
"Koncept for avtale om utvikling av IT-systemer basert på anskaffelsesprosedyren konkurransepreget dialog og smidig (agile) systemudviklingsmetodikk."

Og aftalens hovedformål er at
- beskrive mål og rammer uden at beskrive en udtømmende kravspecifikation
- regulere samarbejdet i udviklingsprocessen
- basere sig på delleverancer som kunden løbende accepterer
- understøtte fleksible prismekanismer

Et udkast til aftalen kan ses her - hvorvidt der stadig pågår arbejde med aftalen er uklart, da direktoratet tilsyneladende pt. er fusionsramt ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Copy/paste

Kunne vi med fordel overveje at lave en lignende aftale herhjemme i DK ? Vi er jo, som Henrik skriver, underlagt nogle andre regler qua vores andel i fællesskabet.

Men er der ikke indenfor landets egne rammer mulighed for at bide elefanten i mindre stykker og så netop lave mindre kontrakter, som har større chance for succes?

Jeg synes det er værd at overveje - og måske endda få lavet en business case på.

Tænk sig alle de penge man kunne spare på kommende offentlige IT-projekter - det vil frigøre midler til minimum 300 plejehjem, en 10% nedsættelse af topskatten og en ny bro direkte fra Århus city til hjertet af Kbh. ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jens Jakob Andersen

En anden tanke - hvilke krav og sæt af krav stiller det offentlige igen og igen i alle løsninger - og kan der laves et sæt af fællesoffentlige standardkrav - funktionelle og nonfunktionelle - set i forskellige kontekster (mønstre)?

Som f.eks:
Ved webløsninger med personligt logon og tilgang til myndighedens oplysninger om borgeren -skal der anvendes 1) Digital Signatur, 2) Fælllesoffentlig bruger/rettighedsstyring, 3) Den fællesoffentlige log-service.

Ved dataudveksling mellem myndigheder skal der anvendes en af de fællesoffentlige integrationsløsninger, som beskrevet i ....

Hvad mere kan man finde på af potentielle fællesoffentlige arkitekturkrav - som vil gøre at den dybe tallerken ikke skal genopfindes igen og igen - men kan genbruges på tværs af projekter - og dermed give hurtigere projekter - og gerne også billigere?

Med spændte hilsner på hvilke bud der dukker op

Jens Jakob

  • 0
  • 0
Bjørn Anker-Møller

I den agile model er kunden aktiv projektdeltager og følger udviklingen løbende. Til gengæld kan det nok give nogle voldsomt komplicerede juridiske tvister hvis en agil proces itererer sig af sporet – både med at afklare årsagerne til det, og også med at finde nogen der vil påtage sig at samle stumperne op.

Det kan næppe undgås at kunden vil ønske sig nogle overordnede rammer som definerer ”hele systemet”, hvad det koster og hvornår det leveres. Det er både i det private og det offentlige grundlaget for at få finansiering.

Jeg er dog helt enig i at elefanterne bør bides i mindre stykker, men det kræver at kunderne også er agile omkring deres eksisterende systemer. Det er ikke kun bevillingssystemet der gør, at mange offentlige opgaver er meget store. For mange ignorerer deres IT-systemer, indtil de pludselig opdager at vedligeholdelse og ændringer bliver voldsomt dyre, når ”end of design life” nærmer sig (eller er overskredet). Så er de tvunget til at modernisere i kæmpeprojekter.

Leverandørerne har som regel ikke den store interesse i at hjælpe med en løbende vurdering, da de typisk skal tjene ind på vedligeholdelsen, hvad de tidligere har brugt på at levere gratis kæmpetilbud og efterfølgende udvikle under en fastpriskontrakt, der sjældent er særlig lukrativ. Der er en ond cirkel her, som skal brydes ved at betale for værdien når den leveres, fx gennem at honorere tilbudsarbejde.

/Bjørn

  • 0
  • 0
Peter Nørregaard Blogger

Under overskriften "Hvorfor giver masser af detaljerede krav en dårligere løsning?" har jeg skrevet om at det er kundens fokusering på at beskrive sine krav til den tekniske løsning i stedet for at beskrive hvilke behov, han har, som kan give problemer.

http://iloblog.norregaard.dk/peter?Home&post=4

Så måske er det dér vi kunne ændre tingenes tilstand?

  • 0
  • 0
Log ind eller Opret konto for at kommentere