Scope creep. Vai oliko scopea alun perinkään?

Mistä tiedetään, että kyseessä on scope creep?

Jos projektin scope (laajuus) on karkaamassa käsistä, ensimmäinen kysymys ei ole, mitä pitäisi muuttaa, vaan miten tiedetään, että kyseessä on scope creep. Usein ongelma ei ole itse scopen karkaaminen, vaan se, että projektin laajuutta ei ole alun perinkään kunnolla määritetty.

Jos scopea ei ole määritetty, sitä ei voi hallita

Jos scopea ei ole suunnitteluvaiheessa määritetty kunnolla, kommunikoitu avoimesti ja hyväksytty yhteisesti, ei sitä voi tehokkaasti hallita siinä vaiheessa, kun projekti on jo käynnissä.

Scopen määrittelyksi ei riitä, että ”halutaan raportti tietyistä mittareista” tai että ”otetaan käyttöön uusi suunnittelujärjestelmä.” Pitää määritellä, joskus jopa ärsyttävän yksityiskohtaisesti, esimerkiksi minkä datan raportti kattaa, mitkä ovat datan lähdejärjestelmät tai mitä toiminnallisuuksia uudelta suunnittelujärjestelmältä halutaan.

Ja yhtä tärkeää on määritellä se, mitä scope ei sisällä. Jos esimerkiksi järjestelmäprojektin aikana on tulossa muutoksia lähdejärjestelmiin, kattaako projekti myös ne, vai ei?

Scope pitää pitää hengissä

Kun scope on määritetty, se ei hoida itse itseään. Scope pitää pitää hengissä koko projektin ajan.

Käytännössä tämä tarkoittaa, että scope:n ulkopuoliset pyynnöt, joita kuitenkin aina tulee, joko käsitellään muutosprosessin kautta tai siirretään parkkipaikalle odottamaan. Parkkipaikka ei tarkoita ”ei ikinä.” Se tarkoittaa: katsotaan projektin edetessä, onko aikaa, rahaa ja resursseja kattaa myös nämä.

Tässä työssä tarvitaan vahvasti myös ohjausryhmän ja projektin omistajan panosta, ei pelkästään projektipäällikköä.

Projektin omistajan rooli on isompi kuin usein ajatellaan

Scopen hallinnassa projektin omistajalla on tärkeä rooli. Hän varmistaa, yhdessä projektipäällikön kanssa, että projekti ei laajene hallitsemattomasti.

Käytännössä tämä tarkoittaa sitä, että tiimille muistutetaan säännöllisesti, mitä projektissa on sovittu tehtäväksi, ja että projektiin tulevat lisäykset ja muutokset (koska niitä kuitenkin tulee 😄) käsitellään hallitusti ja tarvittaessa hyväksytetään ohjausryhmällä.

Scope creep ei ole vain projektipäällikön ongelma. Se on koko projektiorganisaation asia.