I "gamle dage" hed det en FEJL40, fordi årsagen til fejlen var ca 40 cm fra skærmens forside, men folk er vel blevet mere langsynede ?
Smart at "tegne skærmbilleder og bruge blyant" istedetfor at anvende prototyping - I think not !
Hovedproblemet for det offentlige, som jeg ser det, er at man ansætter IT-pygmæer til, for det offentlige, ganske store lønninger. Disse VIL så lave en kravspecifikation, selvom de ikke er kappable og "tvinger" leverandører/konsulenter til at levere det, som pygmæerne har specificeret !
- Stil opgaven, formuleret som : "Vi gør sådan, sådan .... og sådan idag. Det tager for lang tid og for meget man-power - hvem kan foreslå effektivisering af disse arbejdsgange (med streg under, hvad lovgivningen kræver, og fra rutiner, som bord til bord flytning, med begrundelser)
- Lad leverandører fremstille primitive prototyper (blanket til skærmbillede ca ½ time) og forklare hvor de ser potentiale i et (nyt) system.
- Vælg leverandør udfra de sædvanelige kriterier
- Rafiner prototyper løbende, med bruger-involvering (hvis det tidligere har været en offentligt ansat, som udfyldte formularen, men fremover skal være borgeren, skal man vel ikke være profet til at finde ud af at brugertest IKKE udføres af offentligt ansatte ?)
- HUSK at mange systemer får mange FORSKELLIGE brugere : Offentligt ansatte, Borgere, rådgivere osv. ALLE brugere skal indrages i at få prototyperne til at fungere !
- NÅR det er muligt (næsten altid ved nye systemer !) lav en trinsvis udrulning   

Der er ikke rigtigt noget nyt og revolutionerende i den nye metode – dem af os der har arbejdet med bl.a. systemudvikling har de sidste 30 år arbejde med strukturerende metoder i alle årene – det er lidt som om at den dybe tallerken i artikel bliver præsenteret som noget helt nyt – det er det desværre ikke – den nye tallerken er blot en anelse større og har en lidt anden facon – men det er stadigvæk en dyb tallerken.
Det er desværre til gengæld helt rigtigt at både i det private og i det offentlige regi ofte går helt galt når der skal udarbejdes nye systemer og der er som regel kun når det rammer offentlige myndigheder at det kommer i medierne – store private virksomheder er langt bedre til at skjule deres fejl investeringer kuldsejlet projekter.
Årsagerne til det går helt galt er lige så mange som der er projekter – nogle gange er det system 60 fejl – dvs. brugerne laver ged i den (system 60 fejl henviser til den afstand(regnet i cm.)  der er i gennemsnit mellem brugerne og hans skærm) – en simpel fejl er den at nogle oplysninger er placeret anderledes på en skærm og en gammel tasteoperatør har måske i 25 år indtastet indkomne data i en bestemt rækkefølge – pludselig ændres det og det tager meget lang tid at få folk til at skrifte arbejdsmetoder – måske er det platformen systemet hviler på der er forkert eller eller.
Det korte af det lange er, at det er en yderst kompliceret proces at implementere et nyt system i en stor organisation og der er utroligt mange led i en sådan proces og de fleste er eksterne i forhold til selv systemet og det er gerne i de eksterne processer at det går galt – og ofte er det under behovs analysen og udarbejdelse af kravspecifikationen at det går galt – for det er nemlig i denne fase at en konsulent skal være sin opgave voksen – for som skrevet i artiklen så er det her pengene er at hente for et firma med lav moral.
Det er ekstremt vigtigt at få analyseret kundens behov meget præcist og bruge den nødvendige tid på at udarbejde en rigid kravspecifikation – men ofte så er det her at et konsulentfirma henter flødebolle maskinen op ad skuffen og bruger alt sin energi på powerpoints og animation så kunden kan få en oplevelse når det nye forslag til et system skal fremvises – dvs. mens de skal tænke analyse bruger de mest tid på at tænke design og hvilke gyldne løfte de kan animere – og så bliver både prisen og systemet derefter. Ofte har et smart ass fra design solgt kunden en GUI og kunden er blevet forelsket – nu skal teknikken så presse deres system ind i det ofte urealistiske verdensbillede.
En af de helt store fejl er gerne at ledelsen og konsulenterne stikker hovederne sammen og glemmer brugerne eller så bliver brugerne måske hørt – for det skal man jo – men deres erfaring med det gamle system bliver ikke brugt og overført til det nye system hvis det ikke passer ind i ledelses og konsulenternes verdensbillede. Hvis et system skal blive en succes er det nødvendigt at inddrage de eksisterende brugere lige fra dag et og tage dem alvorligt og selv med en fyreseddel hængende over hovedet er det muligt at få medarbejder til at medvirke positivt i processen hvis ledelsen spiller med åbne kort: Vi skal have et nyt system – i dag arbejder vi på 4 platforme og de kan ikke snakke sammen og ja det vil betyde at nogle af jer vil miste jeres arbejde når det nye system er færdigt – men vi vil inddrage jer i processen - løbende omskole jer og ellers gøre alt vi kan for at begrænse skaderne og evt. omplacere jer i andre dele af virksomheden hvis det er muligt.
Forslaget til en ny kravspecifikation er slet ikke dårligt – tværtimod - den er ganske brugbar og hvis den implementeres kan den i de rette hænder spare tid og penge – problemet er bare at det er mennesker der skal bruge systemet – og i lige som de andre strukturere modeller er der visse fase under en system udvikling hvor der kan og skal tjenes penge for et konsulent firma og kravspecifikationen er en af de faser hvor et tvivlsomt firma kan hente store penge og vinde en ordre – med andre ord vi har allerede værktøjerne men alt for ofte bruges de forkert enten fordi folk er griske eller konsulenterne ikke er deres opgave voksen – måske er det ledelsen der ikke har sikret sig medarbejdernes opbakning og måske har de ikke selv forstået deres virksomhedsbehov til bunds og lader sig besnære af opblæste præsentationer.
Jeg har deltaget i projekter hvor et firma måske er blevet en del at en global organisation og hvor mange platforme skal blive til én fælles i mange lande – der hvor det er gået godt er for de virksomheder der fra dag et bruger værktøjerne rigtigt – f.eks. ved selv at indsamle data og analysere deres behov til et kommende system og forstå hvilke krav de realistisk kan stille til et nyt system – når et stort firmas egne IT-eksperter sammen med ledelsen og medarbejderne forstår hvad de vil er det langt nemmere at tilkalde de tunge drenge og sætte dem i gang med arbejdet – man kan på den måde holde deres analyse op i mod ens egen og se om alle har forstået behovene – så kan man så kaste sig over kravspecifikationen og igen hvis en virksomhed ved hvilke krav til det nye der bare skal opfyldes og hvilke krav det kunne være rart at få opfyldt men ikke er så vigtige igen altså ønskekrav så er det med næsten alle strukturerede metoder muligt at få succes med ens nye system lige fra begyndelsen.
Men igen hans kravspecifikation er absolut brugbar og jeg vil da nærlæse den et par gange for at få alle detaljer med.