Asiakkaan budjetissa pysyminen ymmärretään usein väärin muutoksen rajoittamisena, vaikka todellisuudessa kyse on sen ymmärtämisestä ja hallitsemisesta oikein projektin kehittyessä.
Useimmat ohjelmistoon liittyvät tiedustelut alkavat samasta paikasta. Organisaatiolla on olemassa oleva prosessi, usein jotain, joka on kasvanut ajan myötä, ja se haluaa muuttaa sen käytettäväksi sovellukseksi, joka parantaa tehokkuutta, näkyvyyttä ja hallintaa.
Ensi silmäyksellä se kuulostaa yksinkertaiselta. Prosessi on jo olemassa, joten oletus on, että se voidaan yksinkertaisesti siirtää ohjelmistoon. Monissa tapauksissa se on totta. Jos yritys ymmärtää prosessin ja pystyy dokumentoimaan sen selkeästi, olet jo lähtöviivalla.
Johtajuuden näkökulmasta sen pitäisi tuntua hallitulta asemalta. Organisaatio tietää mitä se tekee, miten se toimii ja mitä se tarvitsee järjestelmän tukevan.
Haaste alkaa, kun tuo prosessi alkaa muotoutua järjestelmän sisällä.
Heti kun se tulee näkyväksi, ihmiset alkavat nähdä sen eri tavalla. He sitoutuvat, näkevät miten se voi kehittyä ja alkavat tunnistaa uusia mahdollisuuksia. Uusia ideoita syntyy, reunatapauksia tunnistetaan ja eri sidosryhmät tulkitsevat sen toiminnan hieman eri tavoin. Tämä ei ole epäonnistuminen, vaan luonnollinen osa prosessin tekemistä eksplisiittiseksi.
Tässä vaiheessa jopa yksinkertaiselta kuulostavat muutokset on tarkasteltava jokaisesta näkökulmasta ja prosessin jokaisessa vaiheessa. Se, mikä näyttää vähäiseltä eristettynä, voi olla laajempia seurauksia erityisesti siellä, missä useita rooleja, päätöksiä ja riippuvuuksia on mukana.
Hyvin jäsennellyssä ohjelmistotoimituksessa keskitytään siihen, mikä on tärkeintä organisaatiolle, ei vain siihen, mitä sidosryhmät pyytävät. Monissa tapauksissa se sisältää tarkastettavuuden, joka on kriittistä organisaatiolle, mutta joka usein jää huomiotta lisäominaisuuksien hyväksi.
Sidosryhmät keskittyvät luonnollisesti siihen, mitä he haluavat järjestelmän tekevän. He harvoin keskittyvät siihen, miten nämä muutokset on toteutettava, kirjattava ja hallittava, kun järjestelmä on käytössä.
Tämä muuttaa jopa yksinkertaisimman pyynnön luonnetta. Pieni muutos ei ole enää vain tekninen muutos, siitä tulee osa hallittua ja jäljitettävää prosessia. Tämän seurauksena se, mikä näyttää vähäiseltä, voi olla paljon suurempi vaikutus, kun vaatimustenmukaisuus, vastuullisuus ja operatiivinen näkyvyys otetaan huomioon.
Jos muutosta ei hallita, tulostakaan ei hallita.
Se, mikä alkaa hyvin määriteltynä aloitteena, voi nopeasti muuttua joksikin aivan muuksi, ei huonojen aikomusten vuoksi, vaan päätöksenteon rakenteen puuttuessa järjestelmän kehittyessä. Kustannus ei ole vain taloudellinen. Se mitataan ajassa, monimutkaisuudessa, toiminnallisissa häiriöissä ja selkeyden menettämisessä.
Tässä monet organisaatiot menettävät hallinnan huomaamatta sitä.
Ne uskovat hallitsevansa toimitusta, kun todellisuudessa järjestelmän suunta muotoutuu vähitellen mittaamattomien muutosten kautta.
Juuri tässä Libertas Software Research toimii.
Ei vain järjestelmien rakentamisessa, vaan sen varmistamisessa, että nämä järjestelmät pysyvät organisaation kanssa linjassa niiden kehittyessä. Se tarkoittaa rakenteen luomista muutoksen ympärille, sen vaikutuksen näkyväksi tekemistä ja sen varmistamista, että jokainen päätös ymmärretään kustannusten, ajan ja pitkän aikavälin toiminnan kontekstissa.
Kysymys ei ole siitä, tapahtuuko muutos.
Se tapahtuu.
Kysymys on siitä, kuka sitä hallitsee.