Monesti asiakkaan mielestä projektipäällikkö on firman tyhmin jätkä. Hän ei ole joustava, ei ota kuuleviin korviinsa uusia ehdotuksia ja on luotaantyöntävä. Miksihän näin on?
Yleensä asiakkaalta tulevat muutokset ovat pieniä muutoksia. Ainakin heidän omasta mielestään. Mitä muutoksen käsittely tarkoittaa projektille?
Ensinnäkin kutsuu paluu suunnittelupöydän ääreen. Pitää tarkistaa että uusi idea ei ole ristiriidoissa vanhojen kanssa. Seuraavaksi suunnitellaan toteutus ja aikataulutetaan se. Lopulta uusi idea toteutetaan ja testataan. Pitää tarkistaa, onko järjestelmä edelleen yhtenäinen ja vakaa. Jos näin on, on uusi idea saatu vietyä ohjelmistoon.
Samaan aikaan asiakas haluaa pitää kiinni alussa sovituista (IT-alalla todennäköisesti hyvin tiukoista) aikatauluista. Lisää rahaa ei haluta maksaa. Projektin myöhästymisestä sakotetaan. Samalla kuitenkin jo pelkkä ehdotus viivästyttää projektia. Projektipäällikkö joutuu asettamaan jonkun tutkimaan (tai tutkimaan itse), voidaanko uusi ominaisuus toteuttaa. Vaikka toteutukselle löytyisi este ja sitä ei toteutettaisi, aikaa on silti mennyt hukkaan.
Entä jos ajan säästämiseksi nopeutetaan hieman suunnittelua. Tehdään vanhojen ratkaisuiden pohjalta ja säästetään näin aikaa. Se saattaa oikeasti toimia ja ohjelmisto valmistuu aikataulussa sopimuksen mukaan. Jos kyseessä on asiakkaalle räätälöity ohjelmisto, on sopimukseen todennäköisesti kirjattu myös ylläpito. Ohjelmiston elinkaaressa ylläpitoon kohdistuvat kulut ovat noin 67% koko kuluista. Eli suurimman laskun asiakas saa ylläpidosta. Tätä ei yleensä käsitetä.
Ylläpitovaiheessa löydetyt virheet ja korjaukset maksavat 4-10 kertaa enemmän, kuin kehitysaikana tehdyt korjaukset tai parempi suunnittelu (yleensäkin ajan kulutus). Vertauskuvana voidaan pitää kerrostaloa, jonka alimman kerroksen seinät on rakennettu huonosti ja ne pitää uusia. Projekti tulee olemaan todella massiivinen.
Vaikka projektipäällikkö ennen kaikkea on huolissaan omasta projektista, niin hän silti pitää myös asiakkaan puolta. Kun ohjelmoija kirjoittaa hyvää ja ylläpidon kannalta mietittyä koodia, säästöt ylläpitopuolella kompensoivat mahdolliset menetykset kehitysaikana nopeasti.
...