Projektin määrittely ratkaisee
Useimmat projektit eivät kaadu teknologiaan tai “resurssipulaan”. Ne kaatuvat heikkoon määrittelyyn. Jos tavoite, rajaus ja resurssit ovat alussa hämäriä, aikataulu ja budjetti eivät pidä. Eikä lopputulos vastaa siihen peruskysymykseen: miksi projekti käynnistettiin. Minulle tämä on yksiselitteistä: toteutusta ei aloiteta ennen kuin määrittely on valmis ja hyväksytty.
Lyhyt vertaus: pitkälle talviajolle lähtevä sähköautoilija suunnittelee reitin, pysähdykset ja varavaihtoehdot etukäteen. Projektissa sama periaate: joustetaan matkan varrella, mutta suunta ja rajat ovat selvät.
Mitä projektin määrittelyssä tarvitaan
Tavoite ja mittarit
Mitä arvoa syntyy, kenelle ja milloin? Toivelista ei ohjaa.
Esimerkkejä minulle tyypillisistä mittareista:Käyttöönotto ilman käyttökatkoa (ns. zero downtime).
Kriittiset virheet tuotannossa ensimmäisten 14–30 päivän aikana: 0 kpl.
Palautustarve (rollback) käyttöönoton jälkeen: 0.
Tukipyyntöjen määrä ensimmäisen kuukauden aikana alle sovitun rajan.
Suorituskyky ruuhkassa: sivun/rajapinnan vasteaika < sovittu tavoite.
Rajaus + “ei tehdä” -lista
Paisumisen estää “ei” yhtä paljon kuin “kyllä”. Jos “ei”-listaa ei ole, jokainen idea muuttuu kustannukseksi.Roolit ja päätöksenteko
Kuka päättää laajuudesta, rahasta ja prioriteeteista? Päätöstyhjiö maksaa viivästyksinä.Realistinen kapasiteetti ja aikataulu
Aikataulu tehdään toteutuskyvyn, ei toiveiden, varaan. Puskuri tunnetuille riskeille kuuluu asiaan.Riskit numeroiksi, ei tunteeksi
Vaikutus × Todennäköisyys (1–5). Priorisoi suurimmat ja tee toimet: Vältä, Siirrä, Lievennä, Hyväksy. Raportoi säännöllisesti.
Muutokset ovat väistämättömiä – mutta kaikki muutokset eivät ole saman arvoisia
Muutoksia tulee aina. Ongelma on se, että ne niputetaan samaan koriin. Erotan kaksi koria ja pelaan eri säännöillä:
Kori A – Pakolliset (tavoitteen kannalta välttämättömät)
Nämä eivät muuta projektin tarkoitusta – ne paljastavat sen, mitä määrittelyssä jäi näkemättä.
Esimerkkejä: vaatimustenmukaisuus (turva/audit trail), integraatioiden “piilokustannukset”, välttämättömät käytettävyys- ja suorituskykyrajat.
Sääntö:
- Sisään “ilman syyllisiä” – tämä velka oli olemassa alusta asti.
- Käytetään muutos-/riskipuskuria (aika/€).
- Jos puskuri loppuu: siirretään aikataulua tai tiputetaan toissijaisia asioita, mutta tavoite ei muutu.
Kori B – Nice-to-have (lisäarvoa, mutta ei päämäärän ehto)
“Kun kerran tehdään, niin samalla voisi…” / “Järjestelmä mahdollistaa myös…”.
Sääntö:
Yksi sisään – yksi pois (1-in-1-out): jos otetaan sisään, jotain vastaavaa poistuu tai siirtyy myöhemmäksi.
Investoinnin tuotto (Return on Investment, ROI) näkyväksi: miksi nyt, miksei vaiheessa 2?
Minimitoimitettava kokonaisuus (Minimum Viable Product, MVP) ensin: B-korin jutut oletuksena seuraavaan julkaisuun.
Käytännössä: A-kori suojelee tavoitetta, B-kori kasvattaa arvoa hallitusti. Sekoittaminen tekee vahinkoa.
Muutosportti – sama käsittely kaikille, eri lopputulos koreittain
Kaikki muutokset käyvät läpi saman portin. Päätös on nopea, koska malli on selvä.
Luokittelu: A (pakollinen) vai B (nice-to-have)?
Vaikutus: aika, kustannus, laatu, riskit.
Toteutustapa:
A-kori: käytä puskuria → jos loppu, tee näkyvä aikataulu-/scope-trade.
B-kori: 1-in-1-out tai siirto seuraavaan julkaisuun.
Päätös ja kirjaus: hyväksy/hylkää/siirrä. Ei hiljaista hyväksyntää.
Helpottavat käytännöt:
- Valmiuskriteerit (Definition of Ready, DoR) ja valmistumiskriteerit (Definition of Done, DoD): selkeät sisäänmeno- ja ulostuloehdot työlle.
Yksi prioriteettilista: ei rinnakkaisia “yliprioriteettijonoja”.
Työn alla olevan työn raja (Work In Progress, WIP): näkyy heti, jos kuorma ylittyy.
Tehtäväjono (backlog): kaikki uudet toiveet talteen samaan jonoon, samaan tärkeysjärjestykseen.
Ketterä ja hallittu samaan aikaan
Tarvitaan molemmat. Näin teen:
MVP (minimitoimitettava kokonaisuus): ensin pienin kokonaisuus, joka tuottaa arvoa.
Sprintin lukitseminen: sprinttiin menee vain sovittu työ; uudet asiat eivät tule kesken sprintin, vaan backlogiin.
A/B-käsittely: A-kori voi poikkeuksena läpäistä sprintin portin, jos kyse on tuotannon tai tavoitteen turvaamisesta; B-kori ei.
Kun määrittely ontuu, projektin merkitys katoaa
Huonosti määritelty projekti alkaa elää omaa elämäänsä. Lopulta tiimi ei enää muista, miksi projekti on olemassa. Se on merkki siitä, että ohjaus on pettänyt. Avaan ilmiötä tarkemmin täällä: Projektin merkitys hukassa
Yhteenveto – käytä tämä tarkistuslistana
- Lukitse tavoite ja mittarit (käyttöönotto ilman katkoksia, 0 kriittistä virhettä, ei rollbackeja, rajattu tukipyyntöjen määrä, sovittu suorituskyky).
Kirjoita “ei tehdä” -lista.
Sovi päätöksenteko.
Ajoita kapasiteetin, ei toiveen, mukaan.
Riskit = Vaikutus × Todennäköisyys, tee toimet.
Muutosportti: luokittelu A/B, vaikutus, päätös, kirjaus.
A-kori: käytä puskuria, tavoite pysyy.
B-kori: 1-in-1-out tai seuraava julkaisu.
Pidä ketteryys kurissa MVP:llä, sprintin lukolla, yhdellä prioriteettilistalla ja WIP-rajalla.
Jos näistä lipsuu, projekti paisuu. En lähde matkaan ennen kuin suunta, pysähdykset ja varavaihtoehdot ovat selvät. Se on halvin ja tehokkain tapa varmistaa, että ollaan perillä ajallaan ja budjetissa.
Tarvitsetko apua projektin määrittelyyn?
Tulen mukaan määrittelyvaiheeseen — kahdella tavalla:
Projekti Coach (määrittelyvaihe): fasilisoin 1–2 viikon Definition Sprintin, jonka tuotoksina saat tavoitteen ja käyttöönoton mittarit, rajauksen + “ei tehdä” -listan, roolit ja päätöksenteon, realistisen kapasiteetti-aikatauloluonnoksen, riskilokin (Vaikutus × Todennäköisyys) sekä muutosportin A/B-koreille ja DoR/DoD-kriteerit (Definition of Ready / Definition of Done).
Interim-johtaja (määrittelyjohtaja): otan ohjat, vien määrittelyn läpi sidosryhmien kanssa ja valmistan Go/No-Go-päätösesityksen ohjausryhmälle.
Discover more from Tassberg Consulting
Subscribe to get the latest posts sent to your email.
