Blogi 6.8.2015

Hyvin suunniteltu ei ole edes aloitettu

Gofore

Kiva kun löysit tämän artikkelin! Se sisältää varmasti hyvää tietoa, mutta pidäthän mielessä, että se on kirjoitettu 9 vuotta sitten.

Vanhan sananlaskun mukaan hyvin suunniteltu on puoliksi tehty. Suurten ICT -kehitysprojektien hallinnassa tämä ei päde! Lähelle totuutta päästään vain, jos ”hyvin suunniteltu” määritellään täysin uudella tavalla.
Projektilla on aina sisällön, aikataulun ja rahan määrittämät rajoitteet. Jotta projektipäälliköiden elämä ei olisi liian helppoa, projektit yleensä asetetaan siten, että nämä rajoitteet ovat tiukat ja projekteissa joudutaan jatkuvasti näkemään vaivaa rajojen sisällä pysymiseksi. Jos näin kaikesta huolimatta uhkaa käydä, on projektipäälliköllä oltava rohkeutta nostaa asia ohjausryhmään, jonka tehtävänä on tehdä tarvittavat päätökset. Ollaan auttamattomasti myöhässä, jos nämä nostot tehdään vasta siinä vaiheessa, kun ongelma on niin sanotusti housuissa. Mitä aikaisemmin uhkaavaan rajojen ylittymiseen voidaan reagoida, sitä pienemmillä vahingoilla selvitään.
Usein kuvitellaan, että päivät projektin eri vaiheissa ovat erimittaisia. Alussa voidaan löysäillä ja lopussa kiritään aikataulua kiinni. Kuten tiedämme, tällaista aikapoimua ei kuitenkaan tosielämässä ole. Jos alussa ollaan myöhässä, ollaan myös lopussa myöhässä – tai sitten joudutaan tinkimään sisällöstä ja/tai laadusta. Edistymisen seuranta ja poikkeamiin reagointi onkin tärkeää projektin alusta alkaen.
Perinteisten projektinhallinnan periaatteiden mukaan suunnitteluvaiheessa projektin tehtävät ositetaan, niiden työmäärät arvioidaan ja ne resursoidaan. Tämä on edelleen käyttökelpoinen tapa sellaisissa projekteissa, joissa tehtävät eivät ole ainutkertaisia, vaan aiemman kokemuksen perusteella voidaan melko tarkkaan arvioida niiden työmäärät. Perinteisissä projektinhallintamenetelmissä etenemistä on seurattu tehtävätasolla: vastaako toteutuma alkuperäistä suunnitelmaa. Toteutuman seuranta perustuu tekijän arvioon siitä, kuinka suuri osa työstä on tehty.
ICT-kehityshankkeiden kohdalla tämä menetelmä ei toimi, koska luotettavia työmääräarvioita ei pystytä tekemään ja koska ennalta tehtävä yksityiskohtainen määrittely- ja suunnittelutyö johtaa työlääseen ja kalliiseen muutostenhallintakierteeseen. Vanhan sanonnan mukaan työ on 90 % ajasta 90 % valmis. Siksi on otettu käyttöön ketterä vaatimustenmäärittelymenetelmä, jossa määrittely ja työmääräarviot tehdään suunnitteluvaiheessa vain karkealla tasolla ja niitä tarkennetaan iteratiivisesti projektin edetessä.
Miten projektin tavoitteiden saavuttaminen pystytään ennustamaan, jos ei ole tarkkoja suunnitelmia, joita vastaan etenemistä seurataan, eikä aikaisemmistakaan projekteista ole apua? Projektin pitää pystyä ennustamaan tulevaisuuttaan oman menneisyytensä perusteella. Suuressakin projektissa oppimisen pitää olla erittäin nopeaa, sillä laiva kääntyy hitaasti. Tämä asettaa vaatimuksia mittaamiselle, sillä ilman riittävän tiheitä mittauspisteitä ei pystytä varmistamaan, että korjaavat toimenpiteet purevat riittävän tehokkaasti.
Omat viisi kultaista sääntöäni suuren projektin onnistumisen varmistamiseksi:

1. Eliminoi ensin suuret riskit, lopussa voidaan viilata yksityiskohtia

  • Esimerkiksi uusien teknologioiden käyttöön liittyvät ongelmat on löydettävä mahdollisimman aikaisin, jotta niiden ratkomiseen tai varasuunnitelman tekemiseen jää riittävästi aikaa.

2. Jaa kakku hallittaviin palasiin, vastuuta ja aseta konkreettiset, mitattavat välitavoitteet (ei osa-alueelle vaan kokonaisuudelle)

  • Kukaan ei ole niin hyvä, että tietäisi kaikesta kaiken. Delegointi luotettaville aliprojektien vetäjille on välttämätöntä suuren projektin onnistumisessa. On hyvä kuitenkin muistaa, että vastuu ja valta kulkevat käsi kädessä. Kukaan projektipäällikkö ei siedä esimiehen mikromanageerausta.
  • Testaukseen pitää saada jatkuvasti päästä päähän toimivia kokonaisuuksia. Osatoimitusten kehittämien pitkiä aikoja toisistaan irrallaan kasvattaa riskiä siitä, että kokonaisuuden saaminen toimivaksi vie aikaa ja resursseja.

3. Ole tietoinen mahdollisista harmaista alueista – ongelmat muhivat siellä

  • Vain ne asiat hoituvat hyvin, joilla on tekijä.
  • Jos mahdollista, kannattaa varata kovia osaajia ”task force” -tyyppisiin, tiimien yli meneviin ongelmanratkaisutehtäviin.

4. Kommunikoi aktiivisesti – molempiin suuntiin

  • Jokaisen projektitiimin jäsenen pitää tietää, mitkä ovat projektin lähiajan tavoitteet ja miten hänen työnsä liittyy niihin.
  • Sidosryhmien odotusten hallinta on tärkeä osa projektipäällikön työnkuvaa. Usein siitä riippuu, nähdäänkö projekti onnistumisena vai epäonnistumisena.

5. Mittaa, seuraa, korjaa

  • Saavutimmeko tämän päivän / viikon tavoitteemme?
  • Onko näköpiirissä joitakin ongelmia, jotka pitää korjata tai riskejä, joihin pitäisi varautua?
  • Onko meillä tai toimittajillamme taipumus yliarvioida kyvykkyytemme?
  • Minkälainen on toimitusten laatu?
  • Teemmekö oikeita asioita (jatkuva palautteen keruu tuotteen tai palvelun kohderyhmältä)?
  • Toimimmeko tehokkaasti (esim. kokouskäytännöt, raportit)?
  • Teemmekö hukkatyötä (esim. samoja asioita käsitellään monta kertaa eri koalitiolla, ylitestaus, muutostenhallinta)?


Tarvitaanko siis suunnittelua? Mitä suurempi projekti sitä välttämättömämpää on t
ehdä ylätason suunnitelma riskien ymmärtämiseksi, työn osittamiseksi ja karkean tason välitavoitteiden määrittelemiseksi. Yksityiskohtainen suunnittelu kannattaa tehdä vasta siinä vaiheessa, kun sitä oikeasti tarvitaan.

 

Takaisin ylös