mboost-dp1
www.politi.dk
Jeg har fra starten været positivt overrasket over at man valgte at trække stikket fra projektet så forholdsvis tidligt i forløbet.
IT-projekter inden for det offentlige har historisk set båret præg af at ligemeget hvor dårligt det kører, så hælder man penge i projektet til det er nået i mål uden nogen garanti for at det rent faktisk er anvendeligt.
I den private sektor sker der jævnligt at man dropper projekter efter en vis periode eller omkostning, og jeg har savnet samme klarsyn inden for offentlig IT-ledelse.
IT-projekter inden for det offentlige har historisk set båret præg af at ligemeget hvor dårligt det kører, så hælder man penge i projektet til det er nået i mål uden nogen garanti for at det rent faktisk er anvendeligt.
I den private sektor sker der jævnligt at man dropper projekter efter en vis periode eller omkostning, og jeg har savnet samme klarsyn inden for offentlig IT-ledelse.
Jeg er stadig imponeret over hvordan et projekt kan løbe så løbsk uden at nogen er blevet fyret for det. Der må da være en projekt leder et sted?
Men jo, fint at det blev droppet. Men sindsygt at CSC kan blive ved med at vinde kontrakter når de nu igen og igen overskrider budgettet og ikke leverer de bestilte systemer.
Men jo, fint at det blev droppet. Men sindsygt at CSC kan blive ved med at vinde kontrakter når de nu igen og igen overskrider budgettet og ikke leverer de bestilte systemer.
Valkar (2) skrev:
Men jo, fint at det blev droppet. Men sindsygt at CSC kan blive ved med at vinde kontrakter når de nu igen og igen overskrider budgettet og ikke leverer de bestilte systemer.
Jeg synes nu også at det er vigtigt at overveje om det er de offentlige projekter der er noget galt med. Kan en del af problemet ligge i kravspecifikationen, eller ændringer til denne undervejs i forløbet? Er projektet dårligt specificeret når det sendes i udbud? CSC kan jo godt finde ud af at udføre projekter for det private også. Her sker der naturligvis også fejl (som vi ikke hører så meget om), men det vidner vel alt andet lige om at det ikke kun er CSC der er aldeles uduelige.
jonesn (3) skrev:Kan en del af problemet ligge i kravspecifikationen, eller ændringer til denne undervejs i forløbet?
Selvfølgelig kan en stor del af problemet ligge i kravspecifikationen fra det offentlige. Det bør bare betyde at et firma som CSC vælger ikke at byde ind på opgaven, hvis ikke de er sikre på at kunne løse den.
CSC blev jo sådan set også fyret i og med at man trak stikket. Om CSC fyrer nogen internt, får vi jo aldrig at vide, men hvis det var en dårlig forretning for CSC at drive den her slags udvikling, så ville de nok have skiftet stil for mange år siden...Valkar (2) skrev:Jeg er stadig imponeret over hvordan et projekt kan løbe så løbsk uden at nogen er blevet fyret for det. Der må da være en projekt leder et sted?
Jeg ved ikke noget om Polsag, men ofte er offentlige systemer tværtimod stærkt overspecificerede. Det kommer som resultat af at nogen har siddet i et lokale og fortænkt alt mellem himmel og jord i systemet, typisk uden for eksempel at undersøge hvordan de ansatte rent faktisk bruger deres nuværende systemer. Så skriver man en kontrakt på nogle hundrede sider som definerer i detaljer hvordan systemet skal virke (og typisk også at det derudover skal gøre det samme på den samme måde som et oldgammelt DOS system som er i brug lige nu). Sådan en kontrakt hindrer effektivt at man kan blive klogere undervejs og at man kan ændre systemet tidligt ud fra feedback fra dem som bruger systemet. Det kan så forløbe i nogle år mens systemet bliver dyrere og dyrere og mindre og mindre anvendeligt for dem som rent faktisk skulle have lettet deres arbejdsgang. Modtrækket bliver så for eksempel at kaste 100 mio. i efteruddannelse af personalet i stedet for at lave noget der passer til deres arbejdsgange, så de forholdsvis let ville kunne bruge det.jonesn (3) skrev:Er projektet dårligt specificeret når det sendes i udbud?
Alle successfirmaer i IT-branchen (jeg kan i hvert ikke komme på eksempler på det modsatte) er opstået ved at nogle få, dygtige personer har startet på et projekt uden en kravsspecifikation. De har haft et mål og en gruppe af brugere som de gerne ville gøre noget godt for og derefter startet med det som gav brugerne den mest væsentlige forbedring og efterladt resten til senere. Alt fra Microsoft, Apple, Google, Facebook, Skype osv. er opstået på den måde. Der er ikke mig bekendt ét eneste af de successer som er opstået ved at 200 advokater har skrevet lige så mange ringbind med kravspecifikationer til hvordan for eksempel Googles søgemaskine skulle virke inden første linje kode blev skrevet i Emacs.
Hvis man vil have success med offentlig IT-udvikling, så skal man forsøge at skabe den slags miljøer i stedet for at blokere samtalen mellem udviklere og brugere med ringbind og juristeri. I bund og grund ønsker enhver software-udvikler at hans system bliver en success, og det skulle man prøve at udnytte...
(skrevet af én som aldrig har siddet på et offentligt IT projekt)
Valkar (2) skrev:Men sindsygt at CSC kan blive ved med at vinde kontrakter når de nu igen og igen overskrider budgettet og ikke leverer de bestilte systemer.
http://www.computerworld.dk/art/223155/csc-siet-fr...
http://www.computerworld.dk/art/223155/csc-siet-fra-til-milliardkontrakt-paa-danske-hospitaler skrev:"Vi har kigget på store, lignende systemer, der beviseligt kører andre steder. Så selvom CSC var egnet bedømt på funktionaliteten og organisatorisk med hensyn til at forestå implementeringen, var selskabets referencer på lignede kørende systemer mindre og mindre dækkende end de prækvalificerede leverandørers referencer."
mathiass (5) skrev:CSC blev jo sådan set også fyret i og med at man trak stikket. Om CSC fyrer nogen internt, får vi jo aldrig at vide, men hvis det var en dårlig forretning for CSC at drive den her slags udvikling, så ville de nok have skiftet stil for mange år siden...
CSC har været en dårlig forretning i en del år - de har kørt med store underskud.
Da det er nemmere at estimere drifts omkostninger end udviklings omkostniner, så var det nærliggende at tro at en stor del af disse underskud kom fra udviklingsprojekter.
mathiass (6) skrev:Jeg ved ikke noget om Polsag, men ofte er offentlige systemer tværtimod stærkt overspecificerede.
Logikken er:
kunden vil have fast pris => leverandøren vil have en krav specifikation
mathiass (6) skrev:Så skriver man en kontrakt på nogle hundrede sider som definerer i detaljer hvordan systemet skal virke
Nogle hundrede sider er ingenting.
Og formentligt ikke et problem.
En enkelt person kan læse nogle hundrede sider og forstå indholdet.
Nogle titusinder af sider er et problem, fordi ingen kan læse og forstå det hele.
mathiass (6) skrev:Det kommer som resultat af at nogen har siddet i et lokale og fortænkt alt mellem himmel og jord i systemet, typisk uden for eksempel at undersøge hvordan de ansatte rent faktisk bruger deres nuværende systemer.
Det ses ofte.
Men det er meget svært at designe en process som kan forhindre folk i at opføre sig tåbeligt.
:-)
mathiass (6) skrev:Sådan en kontrakt hindrer effektivt at man kan blive klogere undervejs og at man kan ændre systemet tidligt ud fra feedback fra dem som bruger systemet. Det kan så forløbe i nogle år mens systemet bliver dyrere og dyrere og mindre og mindre anvendeligt for dem som rent faktisk skulle have lettet deres arbejdsgang.
Det kan den gøre.
Men der kan også godt være defineret en velfungerende process for ændringer.
Og sat penge af i det oprindelige budget til ændringer.
mathiass (6) skrev:Alle successfirmaer i IT-branchen (jeg kan i hvert ikke komme på eksempler på det modsatte) er opstået ved at nogle få, dygtige personer har startet på et projekt uden en kravsspecifikation. De har haft et mål og en gruppe af brugere som de gerne ville gøre noget godt for og derefter startet med det som gav brugerne den mest væsentlige forbedring og efterladt resten til senere. Alt fra Microsoft, Apple, Google, Facebook, Skype osv. er opstået på den måde. Der er ikke mig bekendt ét eneste af de successer som er opstået ved at 200 advokater har skrevet lige så mange ringbind med kravspecifikationer til hvordan for eksempel Googles søgemaskine skulle virke inden første linje kode blev skrevet i Emacs.
Det er formentligt rigtigt, men jeg ved ikke om det er så relevant.
Det er lidt æbler og pærer.
1-2 personer starter et simpelt software udviklings projekt fra scratch, som bliver en stor success.
Der skal laves en meget kompleks software løsning der skal integreres ind i en eksisterende organisation.
Bill & Allen, Woz, Larry & Sergey, Zuck, Arpit & Priit & Jaan kunne ikke levere POLSAG alene.
Windows NT, .NET, Android, Google+, iPhone er ikke blevet designet garage style ligesom da firmaerne blev startet.
Komplekse problemer kræver komplekse løsninger.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund