Kun julkiselle puolelle tulee huonosti toimiva tietojärjestelmä, vastaus on aina että henkilöstö ei vain osaa käyttää sitä ja järjestelmä kyllä on hyvä

Jos ongelma on että hyväksi koetusta vanhasta järjestelmästä loppuu tuki niin miksi ei poimita vanhasta sitä mikä toimii ja lisätä vain se mikä tekee siitä aiempaa paremman tai selkeämmän?

Miksi lähteä nollasta?

Vierailija kirjoitti:

Jos ongelma on että hyväksi koetusta vanhasta järjestelmästä loppuu tuki niin miksi ei poimita vanhasta sitä mikä toimii ja lisätä vain se mikä tekee siitä aiempaa paremman tai selkeämmän?

Miksi lähteä nollasta?

On kiva keksiä pyörä uudestaan. Harmi että yleensä siinä keksiessä unohtuu jarrut, polkimet ja se että pyörän pyörät on pyöreät syystä.

Vierailija kirjoitti:

Ihan perusohjelmissa, joiden käyttö ei ole edes vaikeaa, tehty monimutkaisempia versioita. Kun itse yhdelle ammattiohjelmalle hankittiin päivitys, monia päivittäin tarvitsemiani ominaisuuksia oli piilotettu. Löysin ne kyllä, mutta niitä ei saa enää suoraan näkyviin kuten ennen, vaan ne on kolmen-neljän klikkauksen päässä. En löytänyt ohjetta miten ne saisi kiinnitettyä ja kysyin help-deskistä. Siellä eivät heti tienneet ja parin päivän päästä tuli vastaus, että sitä ominaisuutta ei enää ole. Syyksi sanottiin, että kun uudessa ominaisuudessa on versioita niin paljon. Ai, se on syy siihen, että ominaisuus kiinnittää näkyville jatkuvasti tarvittavat ominaisuudet puuttuu nyt.

It-alan porukka on aina ollut vähän ylimielistä ja vika on aina käyttäjässä. Vaikka omasta mielestäni ohjelmiston tekijä on onnistunut vasta silloin, kun tekee niin helppokäyttöisen, että apinakin osaa käyttää. Jos samassa ohjelmassa on paljon ominaisuuksia, hyvä ohjelmoija/suunnittelija voi tehdä valintamahdollisuuksia niin että voi ottaa käyttöön vain tarvittavat ominaisuudet.  Huono ei osaa. Jonkin verran olen opiskellut koodausta itsekin, sekä kokemusta eri ohjelmista vuosikymmeniä ja monet muutokset käyty läpi, joten en nyt ihan hölmö käyttäjänäkään voi olla. Oletteko huomanneet, että it-alan toimijat usein nauravat käyttäjille, jotka eivät osaa heidän ammattitermejään? Hoitajien vaikkapa kannattaisi vastapainoksi pistää omiaan ja katsoa, osaavatko. Se pääasiassa miesvaltainen it-alan porukka, eli ne ihanat kaikkien kanssa toimeentulevat miehet...

No ei se minkään tasoinen koodari lisäile itse sinne mitään ominaisuuksia tuosta vaan. Kyllä ne pitää olla sopimuksessa ja aikataulussa mukana, ja maksavat. Onko asiakas valmis maksamaan vaikka 70000€ tuosta haluamastasi ominaisuudesta? Vaikka onko järkevämpää, että klikkaat hiirellä muutaman kerran?

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Nykyjärjestelmien perusongelma on se, että ovat niin mutkikkaita, koska niihin on ympätty valtavasti tietoa ja eri toimintoja yhteen ja samaan ohjelmaan. Väistämättä (?) lopputulos on sekava. Mutta se on sitten voi voi ja käyttäjät muutosvastarintaisia tyhjästä valittajia kun eivät varauksetta ylistä uutta hienoa järjestelmää... 🙄

Niinpä. Ja kyllä sitä aina ihmettelee, miksi jotain aivan nyanssiasiaa, kuten fonttia, on viilattu ja viilattu, mutta sitten joku perusominaisuus tökkii.

Ilmeisesti on siis todella vaikeaa tehdä järjestelmää, jossa voisi esim vetää monta tiedostoa asian alle kerralla. Nyt sitten vedetään niitä yksi kerrallaan ja odotellaan jokaisen kohdalla 2min että se latautuu. Tosin ei siinä järjestelmässä myöskään pysty korjaamaan tietoa, jos huomaat että merkkasit väärin. Tai poistamaan tuplana mennyttä asiakirjaa keskeneräiseltä asialta.

Tämä. Miettikääpä kun jokainen virkamies jokaisen paperin kohdalla odottelee aina 2min sitä että se latautuu sinne ohjelmaan. Onko tehokasta? Ei ole. Aivan saamarin kallista ja hidasta. Ja veronmaksajat maksaa koko lystin.

Koettu. Huolehdin ison yrityksen maksuliikenteestä. Oli vajaa vuorokausi aikaa tallentaa saajien pankkitilit järjestelmään. Laskuja oli jopa 100 per erä ja yhden laskun päivittäminen vei 15 minuuttia. Käytännössä mulla oli ajastin huutamassa vartin välein että sain neljä laskua tunnissa tungettua koneeseen. Äkkiähän yhden laskun tiedot syötti vaan kun järjestelmä leipoi tuon vartin päivittäessään tietuetta.

Eikä järjestelmätoimittajalla mitään käryä mihin luuppeihin se koodi jäi pyörimään. Hieno ihmiskoe ja kylläpä tehosti työtä.

Tn järjestelmälle on tilaaja speksannut tietyt suorituskykyominaisuudet, jotka nyt täytetään. Kyse ei välttämättä ole softasta, vaan raudasta ja siinä on voitu säästää. Tuloksena suorituskykyongelmia.

Ikinä ei juurisyy epäonnistuneeseen käyttöönottoon ole ollut käyttäjien osaamattomuus. Syynä epäonnistumiseen on surkee tekele, joka on testattu surkeasti hyödyntämättä loppukäyttäjien osaamista.

Vierailija kirjoitti:

Mutta niinhän se näyttää olevan aina tällaisten uudistusten kanssa, ne ovat aina hieman vaikeampia ja huonompia kuin se, jota korvaamaan ne tulivat.

Tuskin.

Vanhoissa voi olla vanhentunutta teknologiaa, kirjastoja ja tietoturvaongelmia niin, että ovat tulleet elinkaarensa loppuun.

Ihminen myös tykkää kaikesta, mihin on tottunut, ja muutos aiheuttaa vastarintaa.

Vierailija kirjoitti:

Järjestelmän suunnittelu on usein aika monen kompromissin summa. Meillä kyllä otetaan asiakkaan puolelta loppukäyttäjän mielipide huomioon. Valitettavasti loppukäyttäjillä ei usein ole koskaan minkäänlaista aiempaa kokemusta järjestelmäuudistuksista. On ehkä käyttänyt jotain yhtä kahta aikaisemmin, mutta usein loppukäyttäjillä ei ole hajuakaan siitä millaisen järjestelmän haluaisivat. Tilaajan puolta kiinnostaa hinta ja aikataulu, numerot yleensä.

Lopulta toteuttaja on kourallinen suunnittelijoita, joilla on kullakin oma osuutensa. Sitten näiden osioiden yhteensovittamista, testausta, kommenttikierrosta loppukäyttäjältä (joka ei vieläkään osaa sanoa yhtään mitään). Sen jälkeen järjestelmä otetaan käyttöön.

Käyttöönoton jälkeen sitten alkaa niitä soraääniä kuulua: miksi tämä ei toimi näin, miksi kukaan ei kysynyt. Mutta kun kysyttiin ja selvitttiin ja istuttiin kymmenissä ellei sadoissa palavereissa.

Kun käyttäjäpalautetta on saatu riittävästi, niin suunnitellaan sitä miten sitä saataisiin muokattua siihen suuntaan. Kaikkea ei olla osattu välttämättä ottaa etukäteen huomioon. Aina kaikki ei ole mahdollista ja usein käyttäjillä ei ole käsitystä siitä mitä mikäkin muutos vaatii. Lisäksi kun toimitus on hyväksytetty ennen käyttöönotta, muutokset maksavat tilaajalle lisää rahaa. Siinä on tilaajan sitten mietittävä paljonko lisää rahaa laitetaan näihin muutoksiin.

Näitä jälkeenpäin huutelijoita yhdistää kuitenkin aina sama asia: jälkiviisaus. Mikään ei ole helpompaa kuin arvostella valmista tuotetta. Sitten kun täytyy tehdä jotain puhtaalta pöydältä, menee näillä joka kerta sormi suuhun.

Tiedän ja ymmärrän ongelmasi. Valitettavasti loppukäyttäjät eivät yleensä ole järjestelmäasiantuntijoita eivätkä todennäköisesti osaa vaikka haluaisivatkin selittää mitä ominaisuuksia tarvitaan, mikä on tärkeintä jne. Mitä monimutkaisempi järjestelmä, sen pahemmaksi vaan se vyyhti menee. Yleisesti ottaen kuitenkin olisi parempi käyttää varmaan reilusti enemmän aikaa suunnitteluun ja selvitysvaiheeseen koska valmista tuotetta on sitten hankalampaa muokata, esimerkiksi tutustua paremmin jo käytössä oleviin ohjelmiin ja niiden toiminnallisuuksiin. Tietty toisessa päässä maksaja taas toivoo nopeaa, halpaa ja hyvää ratkaisua vaikka näitä kolmea ei voi mitenkään saada ja usein sitten otetaan nopea ja halpa...

Vierailija kirjoitti:

Miksi noita järjestelmiä ylipäätänsä pitää vaihtaa kuin sukkia?  Tehdäänkö niitä lähinnä sen vuoksi että kehittäjille olisi jotain kehitettävää ja myytävää?

Koska kaikki pitää saada pilveen.

Vierailija kirjoitti:

Jos ongelma on että hyväksi koetusta vanhasta järjestelmästä loppuu tuki niin miksi ei poimita vanhasta sitä mikä toimii ja lisätä vain se mikä tekee siitä aiempaa paremman tai selkeämmän?

Miksi lähteä nollasta?

Siksi, että on helpompaa, nopeampaa, halvempaa ja laadukkaampaa tehdä scratchista kuin yrittää sovitella jotain vanhentunutta legacy-tauhkaa sinne.

Miksi on halvempaa rakentaa kokonaan uusi talo kuin korjata talo, jossa kaikki muu vanhentunutta paitsi lattian pintamateriaali ja ikkunalaudat?

Monilla ei tunnu olevan mitään hajua ohjelmistosuunnittelusta ja elinkaaresta softatuotteille, mutta silti ovat asiantuntijoita, kun ovat jotain käyttöliittymästä joskus klikkailleet. Mutta mitään ymmärrystä, mitä taustalla tapahtuu, ei ole.

Järjestelmästä saa hyvän vain, jos loppukäyttäjä on sitä mukana rakentamassa.

Tällöin logiikka säilyy ja saadaan toimiva systeemi.

T.yksi rakentaja

Vierailija kirjoitti:

Järjestelmästä saa hyvän vain, jos loppukäyttäjä on sitä mukana rakentamassa.

Tällöin logiikka säilyy ja saadaan toimiva systeemi.

T.yksi rakentaja

No näin. Jos konsultoi loppukäyttäjiä ja oikeasti kuuntelee heidän tarpeitaan, ei ole ongelmaa. Mutta kun julkisella a) ei konsultoida ja b) jos konsultoidaan niin aivan kaikki on liian kallista ja ei pysty. En tiedä onko vika tekijöissä vai onko tilaajalle vain liian kova paikka myöntää, että hän ei oikeasti tiedä mitä hänen virastossaan tehdään.

Vierailija kirjoitti:

Vierailija kirjoitti:

Jos ongelma on että hyväksi koetusta vanhasta järjestelmästä loppuu tuki niin miksi ei poimita vanhasta sitä mikä toimii ja lisätä vain se mikä tekee siitä aiempaa paremman tai selkeämmän?

Miksi lähteä nollasta?

Siksi, että on helpompaa, nopeampaa, halvempaa ja laadukkaampaa tehdä scratchista kuin yrittää sovitella jotain vanhentunutta legacy-tauhkaa sinne.

Miksi on halvempaa rakentaa kokonaan uusi talo kuin korjata talo, jossa kaikki muu vanhentunutta paitsi lattian pintamateriaali ja ikkunalaudat?

Monilla ei tunnu olevan mitään hajua ohjelmistosuunnittelusta ja elinkaaresta softatuotteille, mutta silti ovat asiantuntijoita, kun ovat jotain käyttöliittymästä joskus klikkailleet. Mutta mitään ymmärrystä, mitä taustalla tapahtuu, ei ole.

No enpä tiedä. Olen nyt ollut kohta 4 vuotta tilaajan puolella tekemässä uutta järjestelmää, jossa ensin ei saanut ottaa vanhasta mitään toimintoja, vaan piti aloittaa puhtaalta pöydältä. Harmi, että jos jotain pitää allekirjoittaa, niin järjestelmässä pitää olla jokin toiminto, jolla tämä voidaan tehdä tai ainakin pitää saada merkintä, että paperiversio on allekirjoitettu. Ei käy, sanoo ohjelmistontoimittaja, koska sellainen on jo vanhassa, me ei tehdä vanhaa uusiksi! Tätä keskustelua on käyty uudestaan ja uudestaan, koska tilaajan substanssiedustusta ei kuunnella, meillä ei ole tarpeeksi natsoja kauluksessa. Niinpä ihan kaikki pienet vaatimukset pitää käyttää hanketoimistossa päätettävinä, oli kyse sitten siitä, onko pakko antaa puhelinnumero tai sähköpostiosoite päätyen siihen, seurataanko toimia eräajoilla vai pitääkö tehdä työjonomerkintä manuaalisesti.

Tähän mennessä noin 7 miljoonan euron hintaiseksi budjetoitu hanke on päässyt jo lähes 45 miljoonan hintaan. Vanha olisi korjattu 4 miljoonalla jo melkein 5 vuotta sitten.

Valitettavasti sellaisista osaajista on valtava puute, jotka osaisivat suunnitella tietojärjestelmiä. Pienillä jutuilla saisi käytettävyydessä ihmeitä aikaan ja itse koodaus on helppoa. Se on illuusio, että kokonaisuudesta tulisi hyvä, jos prosessissa tilaaja tekee koko ajan valintoja ominaisuuksiin huutoäänestysten avulla. 

Vierailija kirjoitti:

Miksi noita järjestelmiä ylipäätänsä pitää vaihtaa kuin sukkia?  Tehdäänkö niitä lähinnä sen vuoksi että kehittäjille olisi jotain kehitettävää ja myytävää?

Tietojärjestelmien uusimiselle on ainakin kaksi ilmeistä syytä. Vanha tietojärjestelmä muuttuu jatkuvien muutosten ja korjausten johdosta väistämättä mahdottomaksi ylläpitää järkevällä työmäärällä ja hinnalla. Lisäksi esimerkiksi lainsäädäntö tai muut syyt saattavat edellyttää sellaisia muutoksia joita ei ole järkevää tehdä 30 vuotta vanhana järjestelmään.

Toinen syy on järjestelmän hoitamien prosessien tehostaminen. Esimerkiksi Helsingin palkanlaskenta toimi vanhalla järjestelmällä niin että esihenkilöt, rehtorit, jne toimittivat palkanlaskentaan työntekijöiden palkkatiedot sähköpostilla, sen excel-liitteinä ja lippusina sekä lappusina. Palkanlaskija-armeija toimi tallentajina ja syötti nämä tiedot palkanlaskentajärjestelmään. Tuossa on turhaa kaksinkertaista työtä, mikä myös lisää virheen mahdollisuutta. Käytännössä ainakin osittain koominkertaistakin, työntekijä ilmoittaa tuntinsa esihenkilöllä, joka kokoaa ne tiimin tunneiksi ja palkanlaskenta tallentaa.

Nykyaikainen palkanlaskentajärjestelmä toimii niin että työntekijä syöttää tuntinsa järjestelmään, esihenkilö hyväksyy ne ennen palkanmaksua ja palkanlaskenta vain valvoo että kaikki on tehty ajallaan sekä potkii tarvittaessa. Lisäksi palkanlaskenta ylläpitää henkilöstötietoja, eli lisää uudet työntekijät ja tekee tarvittaessa muutokset palkanlaskennan parametristoon ja hintoihin.

Vierailija kirjoitti:

Järjestelmän suunnittelu on usein aika monen kompromissin summa. Meillä kyllä otetaan asiakkaan puolelta loppukäyttäjän mielipide huomioon. Valitettavasti loppukäyttäjillä ei usein ole koskaan minkäänlaista aiempaa kokemusta järjestelmäuudistuksista. On ehkä käyttänyt jotain yhtä kahta aikaisemmin, mutta usein loppukäyttäjillä ei ole hajuakaan siitä millaisen järjestelmän haluaisivat. Tilaajan puolta kiinnostaa hinta ja aikataulu, numerot yleensä.

Lopulta toteuttaja on kourallinen suunnittelijoita, joilla on kullakin oma osuutensa. Sitten näiden osioiden yhteensovittamista, testausta, kommenttikierrosta loppukäyttäjältä (joka ei vieläkään osaa sanoa yhtään mitään). Sen jälkeen järjestelmä otetaan käyttöön.

Käyttöönoton jälkeen sitten alkaa niitä soraääniä kuulua: miksi tämä ei toimi näin, miksi kukaan ei kysynyt. Mutta kun kysyttiin ja selvitttiin ja istuttiin kymmenissä ellei sadoissa palavereissa.

Kun käyttäjäpalautetta on saatu riittävästi, niin suunnitellaan sitä miten sitä saataisiin muokattua siihen suuntaan. Kaikkea ei olla osattu välttämättä ottaa etukäteen huomioon. Aina kaikki ei ole mahdollista ja usein käyttäjillä ei ole käsitystä siitä mitä mikäkin muutos vaatii. Lisäksi kun toimitus on hyväksytetty ennen käyttöönotta, muutokset maksavat tilaajalle lisää rahaa. Siinä on tilaajan sitten mietittävä paljonko lisää rahaa laitetaan näihin muutoksiin.

Näitä jälkeenpäin huutelijoita yhdistää kuitenkin aina sama asia: jälkiviisaus. Mikään ei ole helpompaa kuin arvostella valmista tuotetta. Sitten kun täytyy tehdä jotain puhtaalta pöydältä, menee näillä joka kerta sormi suuhun.

Tilaaja-osapuolena toimineena voin allekirjoittaa tämän ihan täysin.

Vierailija kirjoitti:

Näiden järjestelmien kilpailutukset julkisella puolella tapahtuu niin, että asiakas määrittelee millainen järjestelmän pitää olla ja sitten ohjelmistotoimittajilta pyydetään tarjouksia. Pienikin poikkeama asiakkaan vaatimuksista pudottaa tarjoajan pois kilpailusta (esim. asiakas vaatii että toimittaja on tehnyt vähintään 5 vastaavanlaista toimitusta aiemmin, mutta toimittaja on tehnyt 4).

Rehelliset järjestelmätoimittajat käyttää paljon aikaa noihin kilpailutuksiin osallistumiseen mutta lopputulos on usein se, että kilpailija väittää täyttävänsä kaikki vaatimukset paperilla ja voittaa kilpailun. Projektin alkaessa sitten huomataan että eihän siinä järjestelmässä kaikkea vaadittua ollutkaan, mutta asiakas ei jaksa enää kilpailuttaa uudestaan vaan tyytyy maksamaan puuttuvien ominaisuuksien lisäkehityksistä kallista hintaa.

Lisämausteena edelliseen: halvin hinta useimmin ratkaisee voittajan, eli epärehellinen toimittaja väittää täyttävänsä kaikki vaatimukset ja laittaa vielä törkyhalvan tarjoushinnan jotta kilpailutus voitetaan, mutta ottaa lopulta voitot korkojen kanssa niillä kaikilla lisäkehityksillä jota järjestelmään pitää tehdä että se toimisi.

Asiakkaan on toimittava hankintalain mukaan, joten jos valheellisesti toiminutta järjestelmätoimittajaa ei jakseta vaihtaa uuden kilpailutuksen pelossa, niin todellisuus on tämä. Asiakkaat kiltisti hyväksyy tällaisen toiminnan ja tietyt it-talot näin valtaa markkinaa. :)

Nimenomaan noin se menee. Ja tuossa tarjouspyntömallissa on suurena ongelmana se että toteutus lyödään jo lukkoon tarjouksen liitteen esisuunnitelmassa. Tuon suunnitelman tekee joku devaaja joka ei tunne kyseistä toimialaa, asiakasymäristöä, nykyistä järjestelmää eikä ole ollut missään tekemisissä järjestelmän käyttäjien kanssa.

Vierailija kirjoitti:

Ongelmana on naiset jotka ovat hakeutuneet julkiselle sektorille (se sana jota Igor haet on sektori, ei puoli).

Ne naiset kun ei ole penaalin terävämpiä kyniä ja järjestelmät... ne nyt vaativat jotain perustaitoja.

Ilmeisesti olet konsultti, joka on suunnittelemassa noita järjestelmiä, ja loukkaantunut, kun järjestelmään tarvitaan muutoksia ja sitä arvostellaan. Yleensä järjestelmän tulevia käyttäjiä ei huomioida, kun johtajat ovat uuden järjestelmän hankinnasta sopineet. Käyttäjät tietävät, mitä tietoja järjestelmästä pitää saada ulos, mitä raporttien tulee sisältää jne.

Sama juttu kuin Venäjän sodankäynnin epäonnistumisessa. Väärät henkilöt päättävät vääristä asioista.

Isoissa organisaatiossa käyttäjäkokemusta saadaan herra isoherralta joka lukee sähköpostitkin sihteerin tulostettua ne. aika mahdoton yhtälö.

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Järjestelmän suunnittelu on usein aika monen kompromissin summa. Meillä kyllä otetaan asiakkaan puolelta loppukäyttäjän mielipide huomioon. Valitettavasti loppukäyttäjillä ei usein ole koskaan minkäänlaista aiempaa kokemusta järjestelmäuudistuksista. On ehkä käyttänyt jotain yhtä kahta aikaisemmin, mutta usein loppukäyttäjillä ei ole hajuakaan siitä millaisen järjestelmän haluaisivat. Tilaajan puolta kiinnostaa hinta ja aikataulu, numerot yleensä.

Lopulta toteuttaja on kourallinen suunnittelijoita, joilla on kullakin oma osuutensa. Sitten näiden osioiden yhteensovittamista, testausta, kommenttikierrosta loppukäyttäjältä (joka ei vieläkään osaa sanoa yhtään mitään). Sen jälkeen järjestelmä otetaan käyttöön.

Käyttöönoton jälkeen sitten alkaa niitä soraääniä kuulua: miksi tämä ei toimi näin, miksi kukaan ei kysynyt. Mutta kun kysyttiin ja selvitttiin ja istuttiin kymmenissä ellei sadoissa palavereissa.

Kun käyttäjäpalautetta on saatu riittävästi, niin suunnitellaan sitä miten sitä saataisiin muokattua siihen suuntaan. Kaikkea ei olla osattu välttämättä ottaa etukäteen huomioon. Aina kaikki ei ole mahdollista ja usein käyttäjillä ei ole käsitystä siitä mitä mikäkin muutos vaatii. Lisäksi kun toimitus on hyväksytetty ennen käyttöönotta, muutokset maksavat tilaajalle lisää rahaa. Siinä on tilaajan sitten mietittävä paljonko lisää rahaa laitetaan näihin muutoksiin.

Näitä jälkeenpäin huutelijoita yhdistää kuitenkin aina sama asia: jälkiviisaus. Mikään ei ole helpompaa kuin arvostella valmista tuotetta. Sitten kun täytyy tehdä jotain puhtaalta pöydältä, menee näillä joka kerta sormi suuhun.

Se on hitsin hankalaa niissä suunnittelupalavereissa ottaa kantaa siihen, mitä käyttäjä ohjelmalta haluaa kun ei ole mitään hajua siitä, miltä se ohjelma sitten ihan käytännössä näyttää/miten toimii. Se on hankala vastata ennen sitä. Jos te suunnittelijat saisitte aikaan kunnon demon siitä, miten se ohjelma niillä ja näillä spekseillä siellä ruohonjuuritasolla näyttää ihan arjessa, niin tuskin soraääniäkään kuuluisi niin paljoa.

T. Lukuisat järjestelmämuutokset 20 vuoden aikana läpikäynyt niin yksityisellä kuin julkisella puolella

Juu juu, ja sitten tulee laskukin niistä 20 eri tavoilla toimivasta prototyypistä

Mitä hourit? Protoja tehdään yksi, ja sitä iteroidaan kunnes se vastaa asiakkaan toiveita ja tarpeita. Tai siis järkevässä maailmassa tehdään näin, julkisilla kun ei osata ostaa kuin vesiputousta niin saadaan aina mitä sattuu eikä protoista ole tietoakaan.

Ja kun organisaation johto on sitoutettu jo hankintavaiheessa projektin ohjausryhmän jäseniksi, niin se ei voi kovin kriittisesti lopputulosta arvostella koska muutenhan se arvostelisi omaa johtamistaan. Näin lopulta paskastakin tulee paperilla kultaa ja kaikki paitsi käyttäjät ovat tyytyväisiä.