mboost-dp1
SXC - nighthawk7
Og det kan kun betyde én ting, at vi ikke tager det seriøst nok, for åbenbart får en masse folk som ikke er engagerede nok/har en ordentlig plan penge til at prøve de her projekter. Og så er der ikke andet at gøre end at stramme op, og kræve en ordentlig fremtidig plan så projekterne faktisk kan gennemføres, præcis lige som andre store succesfulde brancher er nødt til for at overleve.
Kunne også godt tænke mig at vide, hvor mange offentlige it projekter der fejler kontra det private, for vi ved jo alle at det private er lidt bedre til at administrere penge, da det kommer fra deres egen lomme.
Kunne også godt tænke mig at vide, hvor mange offentlige it projekter der fejler kontra det private, for vi ved jo alle at det private er lidt bedre til at administrere penge, da det kommer fra deres egen lomme.
Det er heller ikke ligefrem let at lave store IT projekter.
Det implementøren har brug for at vide er præcist hvad kunden har brug for, inden implementøren går i gang med at løse opgaven, sådan at opgaven kan planlægges og designes fra starten af.
Jeg vil vove den påstand at kunden i 99% af tilfældende ikke ved præcist hvad det er for et produkt de har brug for.
Her ser jeg tingene gå galt, for når først implementøren har brugt tid på at designe et produkt og kunden så pludselig skifter mening og vil have et produkt som er anderledes, så er tiden spildt. Ydermere så risikerer man at det kunden nu vil have, er i konflikt med det som allerede er lavet, hvilket betyder spildt arbejde.
Projekter i udbud skal i sagens natur specificeres inden de starter, således at flere implementører kan byde på opgaven. Jeg vil personligt vove den påstand at denne model er en af hjørnestenene i problemet.
Software projekter egner sig bedre til at blive opbygget gradvist, således at kunden og implemtøren i samarbejde kan finde ud af hvilken retning projektet skal bevæge sig i, inden det er for sent at ændre på resultatet.
Hvis begge parter helt fra starten kan arbejde sammen om den rigtige løsning vil man spilde mindre tid og kunden vil få et produkt som passer bedre på deres behov... Det passer bare ikke ind i strategien om udbud.
Det implementøren har brug for at vide er præcist hvad kunden har brug for, inden implementøren går i gang med at løse opgaven, sådan at opgaven kan planlægges og designes fra starten af.
Jeg vil vove den påstand at kunden i 99% af tilfældende ikke ved præcist hvad det er for et produkt de har brug for.
Her ser jeg tingene gå galt, for når først implementøren har brugt tid på at designe et produkt og kunden så pludselig skifter mening og vil have et produkt som er anderledes, så er tiden spildt. Ydermere så risikerer man at det kunden nu vil have, er i konflikt med det som allerede er lavet, hvilket betyder spildt arbejde.
Projekter i udbud skal i sagens natur specificeres inden de starter, således at flere implementører kan byde på opgaven. Jeg vil personligt vove den påstand at denne model er en af hjørnestenene i problemet.
Software projekter egner sig bedre til at blive opbygget gradvist, således at kunden og implemtøren i samarbejde kan finde ud af hvilken retning projektet skal bevæge sig i, inden det er for sent at ændre på resultatet.
Hvis begge parter helt fra starten kan arbejde sammen om den rigtige løsning vil man spilde mindre tid og kunden vil få et produkt som passer bedre på deres behov... Det passer bare ikke ind i strategien om udbud.
#2 Meget enig.
sådan som jeg ser det, så er det netop fordi kunderne enten ikke ved hvad de vil have, eller får lov til at bestemme for meget i projektet uden vejledning fra fagfolk.
Samtidig så skal man også huske på det faktum at man har meget større erfaringer med andre typer projektet, f.eks. byggeprojekter.
Man har bygget huse i over 4000 år, så man er rimeligt god til at vurdere hvad der skal til og hvad det vil koste, mens man ikke har haft IT-projekter i 100 år endnu... det er for alvor et håndværk i sin spæde barndom, så ikke så underligt vi generelt er så dårlige til IT-projekter
sådan som jeg ser det, så er det netop fordi kunderne enten ikke ved hvad de vil have, eller får lov til at bestemme for meget i projektet uden vejledning fra fagfolk.
Samtidig så skal man også huske på det faktum at man har meget større erfaringer med andre typer projektet, f.eks. byggeprojekter.
Man har bygget huse i over 4000 år, så man er rimeligt god til at vurdere hvad der skal til og hvad det vil koste, mens man ikke har haft IT-projekter i 100 år endnu... det er for alvor et håndværk i sin spæde barndom, så ikke så underligt vi generelt er så dårlige til IT-projekter
Når man nu til dagligt sidder et sted hvor man ser IT projekter der næsten til dagligt vælter ned om ørene på folk, så er det største problem fra mit synspunkt da at folk essentielt set ikke ved hvad de laver, og at der er en generel uvillighed til at ansætte folk der gør. Jeg snakker ikke om at hyre konsulenter ind fra de store konsulenthuse, for alt erfaring siger da at de jubeltosser de sender ud til kunder ved endnu mindre end den gennemsnitlige IT mand, men at man hyrer folk med egentlig erfaring i det område man nu roder sig ud i.
Det kan sikkert også hænge sammen med at danmark er et så udueligt lille land at der ikke findes folk med den nødvendige mængde erfaring i alle de produkter som folk nu engang så gerne vil have.
Det kan sikkert også hænge sammen med at danmark er et så udueligt lille land at der ikke findes folk med den nødvendige mængde erfaring i alle de produkter som folk nu engang så gerne vil have.
Jeg hører en masse: "Det er ikke vores skyld - det er alle de andre". Det er egentlig lidt fattigt. Jo branchen er "ny", men ikke nyere end at der trods alt er kørt en del projekter gennem årene. Dertil laves der massere af projekter i lige IT branchen, langt flere end i mange andre områder.
Jeg ved godt det ikke er let at lave it projekter, men man kan ikke konsekvent sige at det er alle andres skyld når man underperformer så voldsomt. Grib i egen barm og find nogen løsninger. Hvis man har været med på bare lidt større projekter så har vi alle set en projektleder etc. der har oversolgt projektet.
Jeg siger ikke at branchen selv har hele skylden men som i fremstiller det så har de intet ansvar, kom nu lige.
Jeg ved godt det ikke er let at lave it projekter, men man kan ikke konsekvent sige at det er alle andres skyld når man underperformer så voldsomt. Grib i egen barm og find nogen løsninger. Hvis man har været med på bare lidt større projekter så har vi alle set en projektleder etc. der har oversolgt projektet.
Jeg siger ikke at branchen selv har hele skylden men som i fremstiller det så har de intet ansvar, kom nu lige.
#7 Det lyder som om du har en rigtig god indsigt i hvordan problemerne opstår og hvad der skal til for at løse dem.
Skal vi ikke også prøve at bruge samme løsning i alle andre sammenhænge:
1) Arbejdsløshed: De arbejdsløse må bare gribe i egen barm og finde nogen løsninger.
2) Lavkonjuktur: Regeringen må bare gribe i egen barm og finde nogen løsninger.
3) Dovne teenagere: Teenagerne må bare gribe i egen barm og finde nogen løsninger.
4) Dårlige argumenter: Argumentørerne må bare gribe i egen barm og finde nogen løsninger.
At pege fingre og sige at nogen bare må løse problemet og så er alting godt, virker ikke særligt konstruktivt.
Skal vi ikke også prøve at bruge samme løsning i alle andre sammenhænge:
1) Arbejdsløshed: De arbejdsløse må bare gribe i egen barm og finde nogen løsninger.
2) Lavkonjuktur: Regeringen må bare gribe i egen barm og finde nogen løsninger.
3) Dovne teenagere: Teenagerne må bare gribe i egen barm og finde nogen løsninger.
4) Dårlige argumenter: Argumentørerne må bare gribe i egen barm og finde nogen løsninger.
At pege fingre og sige at nogen bare må løse problemet og så er alting godt, virker ikke særligt konstruktivt.
#7 Det var faktisk lidt med vilje.
Jeg tror ikke på at det er så let. Jeg ved jeg ikke har løsningerne. Men de flester herinde har jo konstateret at det i hvert fald ikke er branchen selv.
Lige sådan er det på mit arbejde hvor min chef altid kan fortælle mig hvorfor vores it-projekt ikke er ontrack, og det er aldrig os (der trods alt skal levere det) den er galt med.
Meningen med min post var egentlig at vise hvordan folk i vores branche oftest opføre sig, eg. "Det er alle de andre".
Jeg tror ikke på at det er så let. Jeg ved jeg ikke har løsningerne. Men de flester herinde har jo konstateret at det i hvert fald ikke er branchen selv.
Lige sådan er det på mit arbejde hvor min chef altid kan fortælle mig hvorfor vores it-projekt ikke er ontrack, og det er aldrig os (der trods alt skal levere det) den er galt med.
Meningen med min post var egentlig at vise hvordan folk i vores branche oftest opføre sig, eg. "Det er alle de andre".
Tjah, store IT projekter er jo vigtige, derfor er det jo en direktør der skal stå for det - selv om han intet aner om hvordan resultate skal bruges, og til hvad.
IT folkene ved jo også bedre end alle andre. Direktøren er den der betaler, så ham skal de jo lytte til - dem som skal bruge resultatet aner jo intet om IT, så det de siger skal man da aldrig tage hensyn til.
Dem der skal bruge det har travlt med deres arbejde, og er alligevel ikke vigtige for det overordnede billede jo - de har ikke tid/lyst/mulighed til at indvolvere sig før det er for sent alligevel.
Men DJØF'erne kan bruge en masse tid på kontrakter, klausuler mv., så vi kan skære ned på folk så snart systemet er "færdigt" og selvfølgelig virker perfekt fra start af - for ikke at sige at folk naturligvis automatisk er eksperter i at benytte det.
IT folkene ved jo også bedre end alle andre. Direktøren er den der betaler, så ham skal de jo lytte til - dem som skal bruge resultatet aner jo intet om IT, så det de siger skal man da aldrig tage hensyn til.
Dem der skal bruge det har travlt med deres arbejde, og er alligevel ikke vigtige for det overordnede billede jo - de har ikke tid/lyst/mulighed til at indvolvere sig før det er for sent alligevel.
Men DJØF'erne kan bruge en masse tid på kontrakter, klausuler mv., så vi kan skære ned på folk så snart systemet er "færdigt" og selvfølgelig virker perfekt fra start af - for ikke at sige at folk naturligvis automatisk er eksperter i at benytte det.
Typisk for offentlige projekter, der kommer i udbud, er at en rigtig god virksomhed kommer med et meget realistisk bud, og nogle krejlere så underbydder dem og laver noget lort, der kommer til at koste det tredobbelte at rette op på
/stereotyp rant af offentlig it slut
/stereotyp rant af offentlig it slut
#11 Nah det lyder meget korrekt!
Sjovt at det aldrig undrer i det offentlige.
Eks:
4 virksomheder kommer med et tilbud på ca. 10.000.000 der varier med nogle hundrede tusinde.
1 virksomhed kommer med et tilbud på 3.000.000.
Virker den ene virksomhed troværdig? I think not. Hvorfor bliver den ofte valgt? Tja af samme grund folk kan finde på at købe en Bilka computer, den er billige og de ved ikke det er noget bras før det er for sent.
Sjovt at det aldrig undrer i det offentlige.
Eks:
4 virksomheder kommer med et tilbud på ca. 10.000.000 der varier med nogle hundrede tusinde.
1 virksomhed kommer med et tilbud på 3.000.000.
Virker den ene virksomhed troværdig? I think not. Hvorfor bliver den ofte valgt? Tja af samme grund folk kan finde på at købe en Bilka computer, den er billige og de ved ikke det er noget bras før det er for sent.
#14 Heldigt der aldrig er problemer med offentlige byggeprojekter.
#15 Sjovt, kan ikke helt finde ud af om det er ironi eller seriøst.
Men jeg bider da på. Kan du komme med nogle eksempler på offentlige byggerier der ikke er gået over budget og tid?
Sjovt nok lavede Bent Flyvbjerg der også er bag denne undersøgelse, samme undersøgelse for 3 år siden bare med byggebranchen. Samme konklusion i øvrigt:
http://www.djoef.dk/blade/djoefbladet/arkiv/djoefb...
Men jeg bider da på. Kan du komme med nogle eksempler på offentlige byggerier der ikke er gået over budget og tid?
Sjovt nok lavede Bent Flyvbjerg der også er bag denne undersøgelse, samme undersøgelse for 3 år siden bare med byggebranchen. Samme konklusion i øvrigt:
http://www.djoef.dk/blade/djoefbladet/arkiv/djoefb...
#16 Her får du lige nogle smileys, så kan du gemme dem og indsætte dem i nogle af mine fremtidige ironiske posts:
:) ;) :-o :-P xD B)
:) ;) :-o :-P xD B)
#IT projekter
Q: Er IT projekter værre end bygge projekter med hensyn til forsinkelser og fordyrelser?
A: Ja. Bygge projekter bliver også forsinket og fordyret, men IT projekter bliver hyppigere og mere forsinket/fordyret. Det kan konstateres ved at kigge på projekter.
Q: Er IT projekter vanskeligere at færdiggøre on time og on budget end bygge projekter?
A: Ja. Der er langt mindre erfaring med IT projekter end bygge projekter (50 år versus 5000 år). Der er langt større forskelle på IT projekter end på bygge projekter (for huse og broer er der typisk lavet noget lignende før mens IT løsninger typisk er unikke - hvis ikke de var unikke ville man købe den eksisterende løsning fordi prisen på at kopiere software er meget lille). IT projekter er typisk langt mere komplekse end bygge projekter.
Q: Hvad kan man gøre for at forbedre situationen?
A: Godt spørgsmål. Det er ikke nemt. Hvis det var nemt ville nogen have gjordt det allerede.
Men der er 2 ting som man skal starte med:
1) Erkende at den nuværende sitiuation ikke er tilfredsstillende og at man skal og kan forbedre den. Der er nogle store psykologiske barrierer for at finde forbedringer, hvis den generelle mentalitet er at den nuværende situation er god nok ("alle projekter overskrider deadline og budget, så det er OK at vi også gør det" mentaliteten).
2) Erkende at der ikke er nogen nemme løsninger (silverbullets). Det er ikke det nye programmerings sprog eller den nye udviklingsværktøjer som vil løse problemerne. Problemerne har vist sig ret konstante selvom der er sket store ændringer i sprog og værktøjer.
Q: Er IT projekter værre end bygge projekter med hensyn til forsinkelser og fordyrelser?
A: Ja. Bygge projekter bliver også forsinket og fordyret, men IT projekter bliver hyppigere og mere forsinket/fordyret. Det kan konstateres ved at kigge på projekter.
Q: Er IT projekter vanskeligere at færdiggøre on time og on budget end bygge projekter?
A: Ja. Der er langt mindre erfaring med IT projekter end bygge projekter (50 år versus 5000 år). Der er langt større forskelle på IT projekter end på bygge projekter (for huse og broer er der typisk lavet noget lignende før mens IT løsninger typisk er unikke - hvis ikke de var unikke ville man købe den eksisterende løsning fordi prisen på at kopiere software er meget lille). IT projekter er typisk langt mere komplekse end bygge projekter.
Q: Hvad kan man gøre for at forbedre situationen?
A: Godt spørgsmål. Det er ikke nemt. Hvis det var nemt ville nogen have gjordt det allerede.
Men der er 2 ting som man skal starte med:
1) Erkende at den nuværende sitiuation ikke er tilfredsstillende og at man skal og kan forbedre den. Der er nogle store psykologiske barrierer for at finde forbedringer, hvis den generelle mentalitet er at den nuværende situation er god nok ("alle projekter overskrider deadline og budget, så det er OK at vi også gør det" mentaliteten).
2) Erkende at der ikke er nogen nemme løsninger (silverbullets). Det er ikke det nye programmerings sprog eller den nye udviklingsværktøjer som vil løse problemerne. Problemerne har vist sig ret konstante selvom der er sket store ændringer i sprog og værktøjer.
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