Projektien aikataulut kusee

Ehkä speksit ovat niin huonot, että niistä ei pysty tekemään arviota? Ehkä projektipäällikkö ei hyväksy annettua realistista arviota, vaan laatii aikataulun optimistisen arvion mukaan? Ehkä asiakas muuttaa speksejä kesken projektin ja projektipäällikkö pelaa alkuperäisen aikataulun mukaan.

jos aikataulu alkaa kusemaan niin on pyydettävä ja saatava lisäresursseja vaikka sitten vinkuintiasta, tosin silloin voi aikataulut venyä vaan lisää...
pp:n vietävä aikataulu-, resurssi- jne.ongelmat mm. esimiehensä ja projektiin osallistuvien tietoon, jotta niihin saadaan nopeasti korjaus eikä jäädä ihmetteleen tumput suorana.

pp:n vastuu kirjoitti:

jos aikataulu alkaa kusemaan niin on pyydettävä ja saatava lisäresursseja vaikka sitten vinkuintiasta, tosin silloin voi aikataulut venyä vaan lisää...
pp:n vietävä aikataulu-, resurssi- jne.ongelmat mm. esimiehensä ja projektiin osallistuvien tietoon, jotta niihin saadaan nopeasti korjaus eikä jäädä ihmetteleen tumput suorana.

Lue lisää

Vielä tuosta resurssien hankkimisesta. Yleensä projekteissa tuppaa se ydinporukka vaan tiivistymään loppua kohden ja lisäresuja ei saada mukaan tehokkaasti. Tämäkin on vain huomioitava jo projektia alottaessa, että ne lisäresut on perillä menosta ja voidaan oikeasti ottaa tuottavaan työhön.

> Joten projektit myydään aina sellaisella aikataululla jonka asiakas haluaa

Harvinaisen totta tuo. Käytännössä asiakas ostaa aina halvimman projekin, joten tarjousvaiheessa heitetään aika optimistisia toteutusaikatauluja. Sitten toivotaan, että asiakas haluaa lisäkilkkeitä softaansa, mistä sitten revitään rahaa, kun asiakas on jo sitoutunut ohjelmistotoimittajaan.

Paitsi Nokia-konsernin tapauksessa Nokia sanelee alihankkijalle, kuinka paljon projektiin laitetaan rahaa ja kuinka kauan se näin ollen kestää.

ja tarvittaessa lomailijoiden varahenkilöiden aikataulut pitää olla selvillä aikataulua kasattaessa.

Jos projektipäällikkö pääsee mukaan sopimuksen tekemiseen, niin kuin olen itse päässyt, voi vaikuttaa paljon siihen tuleeko sanktioita vaiko ei. Olen tehnyt sidosryhmien kanssa tarkan riskienhallinta-osion projektisuunnitelmaan. Myös varahenkilöt on nimetty ja pidetty tietoisena siitä mitä projektissa tapahtuu - voihan avainhenkilötkin sairastua. Näin vältyn siltä, että oman organisaationi syyksi tulee asiakkaan viivästykset tai kolmannen osapuolen (asiakkaan alihankkija) viivästykset.

Projektipäällikön ei tarvitse ottaa niskaansa kaikkea paskaa, mitä asiakkaan omasta toiminnasta aiheutuu. Hyvät suunnitelmat ja muu dokumentaatio ovat projektipäällikön turvana.

Miksi muuten täällä haukutaan naispuolisia projektipäälliköitä?

Eräs ilmiö on vielä alasta mitään tietämättömät pp:t mallia kävelevä katastrofi (pahimmat jostakin syystä yleensä naispuolisia).

näiden perusasioiden luulisi olevan hallussa, mutta eivätpä ne tunnu olevan missään projektissa.

dokumentointiin panostetaan 300% jottei tarvitse panostaa koulutukseen taikka systemaattiseen työskentelytapaan...

Nämä dokumentoijat ovat yleensä kokeneinta sakkia, eivätkä tasan kirjoita kaikkea paperille, siltä varalta, että tappiota tulee, mikäli kenkää tulee seuraavissa YT neuvotteluissa.

nimim. ex dokumentoija
ps. tappiota tulee

Kuvaamasi vesiputousmalli on suurimpia syitä projektien myöhästymiseen. Vaatimukset muuttuvat, se on fakta, eikä sille voi mitään. Niinpä aluksi tehty turhan tarkka suunnittelu on vain turhaa työtä, joskus jopa haitallista.

Vesiputousmalli otettiin käyttöön jenkkilässä joskus 70-luvulla. Puolustusvoimissa muistaakseni. Ja heitä ei oikein kiinnostanut se, että aikataulut ja budjetit paukkuivat ja lopputuloksena oli läjä paskaa... Ja sitten muut keksivät, että jos malli on tarpeeksi hyvä DoD:lle, kelpaa se meillekin.

Toki pieniä projekteja voi saada jopa onnistumaan vesiputousmallina, mutta se vaatii pätevät tekijät ja tiukkaa bisnestuntemusta. :)

siinä kun selostetaan ympäripyöreästi mitä halutaan.

Niin se puuttuva ominaisuus lukee noissa ympäripyöreissä kohdissa.

Jos ette tee sitä samalla hinnalla niin oikeudessa tavataan =)

Samaa sähläämistä ja säätämistä vuosikymmenestä toiseen. "Hienoja" menetelmiä ja tekniikoita kehitetään, mutta yhdelläkään firmalla ei ole varaa noudattaa niitä, eli siis toisin sanoen, yhdelläkään asiakkaalla ei ole varaa maksaa kunnolla tehdystä softasta.

Jos aikataulu tai työmääräarvio pettää, niin ensimmäiseksi aina tingitään laadusta, oli firmalla minkälaiset sertifikaatit tahansa.

Tästä syystä kehitettiin nämä Agile-menetelmät. Ketterästi vedetään hihasta mutu-pohjalta, ihan niin kuin isoisä ennenkin.

The Rat kirjoitti:

Kuvaamasi vesiputousmalli on suurimpia syitä projektien myöhästymiseen. Vaatimukset muuttuvat, se on fakta, eikä sille voi mitään. Niinpä aluksi tehty turhan tarkka suunnittelu on vain turhaa työtä, joskus jopa haitallista.

Vesiputousmalli otettiin käyttöön jenkkilässä joskus 70-luvulla. Puolustusvoimissa muistaakseni. Ja heitä ei oikein kiinnostanut se, että aikataulut ja budjetit paukkuivat ja lopputuloksena oli läjä paskaa... Ja sitten muut keksivät, että jos malli on tarpeeksi hyvä DoD:lle, kelpaa se meillekin.

Toki pieniä projekteja voi saada jopa onnistumaan vesiputousmallina, mutta se vaatii pätevät tekijät ja tiukkaa bisnestuntemusta. :)

Lue lisää

että yrityksellä/asiakkaalla on määriteltynä joku tarkoin kuvattu ja harkittu tapa tehdä softaa, mutta siitä ei pidetä kiinni, koska se on liian työlästä ja se maksaa liikaa. Ammattimaisessa ohjelmistotuotannossa liian usein tyydytään leikkimään, että hommat hoidetaan asiallisesti ja tosiasiallisesti kuitenkin mutkat vedetään suoriksi laadun kustannuksella mennen tullen. Nokia-konserni on tiennäyttäjä tässäkin suhteessa.

... kirjoitti:

Samaa sähläämistä ja säätämistä vuosikymmenestä toiseen. "Hienoja" menetelmiä ja tekniikoita kehitetään, mutta yhdelläkään firmalla ei ole varaa noudattaa niitä, eli siis toisin sanoen, yhdelläkään asiakkaalla ei ole varaa maksaa kunnolla tehdystä softasta.

Jos aikataulu tai työmääräarvio pettää, niin ensimmäiseksi aina tingitään laadusta, oli firmalla minkälaiset sertifikaatit tahansa.

Tästä syystä kehitettiin nämä Agile-menetelmät. Ketterästi vedetään hihasta mutu-pohjalta, ihan niin kuin isoisä ennenkin.

Lue lisää

Agilet menetelmät ovat kylläkin vanhempia kuin vesiputousmalli, nehän ovat luonnollinen tapa lähestyä ohjelmistotuotantoprosessia. Ja ihan järkeäkin niissä on... Iteratiivisella prosessilla löydetään haluttu lopputulos melkein optimaalista reittiä käyttäen, joskin overheadia syntyy enemmän.

Voisi oikeastaan sanoa, että jos vesiputousmallilla tehty proggis menee kerralla täysin oikein, on se aika optimaalinen prosessi. Näin vain ei koskaan käy, ja vesiputouksen patoaminen on aina aika työlästä. :)

Kumpi on siis parempi? Kun asiakas ei tiedä mitä haluaa, yritetään aluksi arvata ja sitten pidetään kynsin ja hampain kiinni arvauksesta, vai tehdäänkö ensin jotain ja katsotaan onko tämä yhtään sinne päinkään...

Työmääräarviossa pitäisi aina tehdä optimistinen arvio ja pessimistinen arvio. Realistinen arvio (minkä perusteella tarjous tehdään) on jotain siltä väliltä. Näin joku projektin osa voi kusta, mutta toinen osa kuittaa kuset. Tuo kertaa kaksi menetelmä antaa kivan puskurin, mutta tarjouskilpailussa sillä ei valitettavasti kalkkiviivoille päästä.

Raipppa kirjoitti:

Työmääräarviossa pitäisi aina tehdä optimistinen arvio ja pessimistinen arvio. Realistinen arvio (minkä perusteella tarjous tehdään) on jotain siltä väliltä. Näin joku projektin osa voi kusta, mutta toinen osa kuittaa kuset. Tuo kertaa kaksi menetelmä antaa kivan puskurin, mutta tarjouskilpailussa sillä ei valitettavasti kalkkiviivoille päästä.

Lue lisää

ihmeellistä, sähläystähän siitä tulee, kun asiakas ei tiedä mitä haluaa.

Myynti on provisiopalkattua ja tinkii hinnasta niin kauan, että menee kaupaksi.

Piut paut mitä joku projektipäällikkö sanoo.

Asiakaskaan ei tiedä mitä haluaa ja "ostajat" määrittelee haluamansa mokkulan ympäripyöreästi, jotta myöhemmin siihen voidaan vaatia puuttuvia ominaisuuksia ilmaiseksi.

Sitten katsotaan halvin mahdollinen tarjous jne.

Sitten kun kauppa saadaan itse toteuttajat kummastelee, ettei tällä aikataululla saa mitään aikaiseksi ja turhat työvaiheet jätetään väliin kuten suunnittelut ja testaukset.

Testauksenhan softamaailmassa hoitaa asiakkaat nimittäin.
Ja myynti myy keskeneräistä betasoftaa euron kuvat silmillä tuotantokoneisiin huh huh...