Kirjoittaja: Jyrki Autio
Haastavia, mutta onnistuneesti maaliin vietyjä kehitysprojekteja yhdistää yksi yhteinen tekijä: Ammattimainen muutoksen hallinta. Jotta onnistumisesta digitalisoituvassa liiketoiminnassa tulisi rutiinia, tarvitaan projektin johtamiseen nykyaikaiset menetelmät ja työkalut.
Koska ratkaisu on valmis käyttöönotettavaksi?
Täydellisen CRM- tai ERP-ratkaisun rakentaminen on kallista, ellei jopa mahdotonta. Tärkeämpi tavoite onkin luoda yrityksen tarpeita turvallisesti tukeva ratkaisu, jonka käyttöönotto ei vaaranna liiketoimintaa. Ohjausryhmissä pohditaankin usein, milloin ratkaisun valmiusaste on tarpeeksi korkea, jotta käyttöönottovaiheeseen voidaan siirtyä turvallisesti:
- Jokainen kehitysprojektipäivä kerryttää kustannuksia.
- Mitä nopeammin uusi toimiva ratkaisu saadaan käyttöön, sitä nopeammin se alkaa tuottaa tavoiteltuja hyötyjä
- Jos ratkaisu otetaan kuitenkin keskeneräisenä käyttöön, se aiheuttaa sekä kustannuksia että ongelmia liiketoiminnalle.
Jotta asia voidaan ratkaista, ohjausryhmällä pitää olla luotettavaa tietoa projektin todellisesta valmiusasteesta. Turvallinen päätöksenteko edellyttääkin toimivia testaustyökaluja, tehokkaita korjausmetodeja virheiden varalle sekä ammattimaista muutoksen hallintaa.
Mitkä muutokset toteutetaan?
Suuri muutospyyntöjen määrä vaikuttaa negatiivisesti projektiin. Budjetti ja aikataulu ylittyvät, ja silti vain osa pyynnöistä saadaan toteutettua. Käytännössä on valitettavan yleistä, että vain pakolliset sekä teknisesti helpot muutokset toteutetaan, mutta monimutkaisemmat, liiketoiminnalle tarpeelliset muutokset karsiutuvat pois ajan puutteen seurauksena.
Toteutettavien muutosten listaan olisi kuitenkin tärkeää priorisoida pakollisten muutostarpeiden lisäksi ne muutokset, jotka edistävät projektin perusteina olevien hyötyjen saavuttamista.
Tätä tavoitetta voidaan edistää selvällä, yhteisesti sovitulla toimintatavalla muutospyyntöjen käsittelyssä. Muutospyyntöjen tarpeellisuudelle on hyvä luoda kevyt byrokratia, joiden avulla varmistetaan, että tärkeimmät pyynnöt priorisoidaan. Jos muutospyyntö ei ole niin tärkeä, että sitä ei jakseta kunnolla perustella, sitä harvoin kannattaa toteuttaa!
Vaikka onnistuneesti toteutettujen suunnittelu- ja määrittelyvaiheen seurauksena muutospyyntöjen kokonaismäärä jäisi vähäiseksi, muutospyyntöjen kriittinen pohtiminen on silti järkevää – kannattaako muutos kohdistaa ratkaisuun vai liiketoiminnan prosessiin? Mitä enemmän järjestelmiä digitalisoidaan, sitä enemmän perinteisen liiketoiminnan pitää taipua muutokseen!
Esimerkki epäonnistuneesta projektin johtamisesta ja muutoksen hallinnasta
Taannoin minut pyydettiin auttamaan ongelmiin ajautuneen, noin 20 henkilöä työllistäneen ja liiketoiminnalle kriittisen ERP-projektin kanssa. Yksi projektin näkyvistä ongelmista oli projektidatan pirstaloituminen:
- Toimittaja oli luetellut toteutettavat muutospyynnöt täsmällisesti, koska listaus oli laskutuksen perusteena. Projektin sopimus oli muodoltaan sellainen, että toimittajan kannatti toteuttaa muutospyyntöjä.
- Ehdotetut muutospyynnöt olivat kuitenkin hajonneet lukuisiin sähköposteihin ja pöytäkirjoihin. Epämääräisen määrittelyn johdosta muutostarpeita oli paljon, eikä tarpeiden kokonaiskuva ollut tiedossa.
- Avoimet asiat, kysymykset, päätökset ja vastaukset olivat myös pirstoutuneet lukuisiin sähköposteihin ja pöytäkirjoihin.
- Testaus oli projektissa toteutettu ”tutkivana testauksena” – testitapaukset oli jätetty dokumentoimatta ja tehdyt havainnot hukuksissa sähköposteissa ja Excel-taulukoissa.
Yritys oli ajautunut tilanteeseen, jossa projektin jatkaminen oli liian kallista, mutta ratkaisu niin keskeneräinen, että sitä ei uskallettu ottaa käyttöön. Pohjasyy ongelmiin oli huolimattomasti tehty suunnitelma ja huonosti toteutettu sekä seurattu muutoksen hallinta.
Esimerkki onnistuneesta projektin johtamisesta ja muutoksen hallinnasta
Olin apuna toisessa kehitysprojektissa, jonka avuntarve oli hyvin erilainen; projekti oli alkanut hienosti, mutta projektipäällikkö kaipasi vinkkejä siitä, miten varmistetaan projektin onnistuminen.
Muutospyyntöjen määrä oli tässä projektissa vähäinen, sillä projekti oli suunniteltu ammattimaisesti ja määrittely oli toteutettu laadukkaasti käyttötapausten avulla. Loimme tästä huolimatta muutoksenhallinnan prosessin, jotta muutospyynnöt saatiin käsiteltyä hallitusti.
Kuka tahansa liiketoiminnan parissa toimiva pystyi esittämään kysymyksiä projektille. Jokainen avoin asia käsiteltiin ja kirjattiin projektissa hyödynnetyn ProjectTOP-ohjelmiston avulla. Ihmiset suhtautuivat järjestelmällisesti etenevään ja avoimesti johdettuun projektiin positiivisesti ja turvasivat projektille työrauhan. Aina ratkaisut eivät voineet miellyttää kaikkia osapuolia, mutta vastauksissa mukaan liitetyt perustelut edesauttoivat muutosten hyväksyntää.
Analyysia projektin tilanteesta tehdessäni havaitsin, että ProjectTOP-ohjelmiston muutoslokiin oli kertynyt 10 462 tapahtumaa, muun muassa statusvaihdoksia, kommentteja, korjauksia ja päätöksiä. Jos näin suuri datamäärä pirstoutuu useille alustoille, projektissa onnistuminen käy erittäin haastavaksi. Se, että projektiryhmä käyttää yhtä yhteistä ohjelmistoa, antaa projektipäällikölle sekä ohjausryhmälle mahdollisuuden johtaa projektia tehokkaasti, reaaliaikaisen ja luotettavan tiedon pohjalta.
Haluatko kuulla lisää?
Katso webinaari aiheesta!
