Kaikella tekemisellä pitää olla tarkoitus

Kaikella tekemisellä pitää olla tarkoitus. Kuvittele kaksi rinnakkaista maailmaa, joissa kaikki on samaa, paitsi asia, jota harkitset ruveta tekemään: kuinka erilaiset nuo maailmat olisivat? Onko tuo ero vaivan arvoinen?

Ilman selkeää tarkoitusta asioita tehdään koska muut tekevät niin tai määrittelevät että niin täytyy tehdä. Näin ollen:

• Kyseisestä asiasta ei ehkä ole ollenkaan hyötyä, tai
• Kyseisestä asiasta voi olla hyötyä, mutta koska tarkoitus ei ole kirkas, niin tapa, jolla asia toteutetaan, ei välttämättä auta saavuttamaan hyötyjä.

Esimerkki: Projektisalkku ja projektit

Projektien valinnassa ja aloittamisessa on varmistettava, että keskitytään hyötyihin ja ratkaistaviin ongelmiin, eikä tuotteeseen, joka tulee toteuttamaan nuo asiat.

Klassinen esimerkki on hissivalmistaja, joka oli saanut valituksia hissien nopeudesta, ja oli sitten toteuttanut projekteja nopeuden lisäämiseksi, mutta ilman suurta menestystä. Sama jatkui, kunnes valmistaja päätti keskittyä itse ongelmaan (matkustajien ikävystyminen tai epämukavuus) “luonnollisen” ratkaisun sijaan (nopeammat hissit). Lopputulema oli lisätä hissiin peilejä, ja tämä ratkaisu ratkaisi ongelman yksinkertaisesti ja halvalla.

Projektinhallinta tarkoittaa pääasiassa asioiden tekemistä oikein, kun taas salkunhallinta tähtää siihen, että tehdään oikeita asioita. Hyvin johdetulla projektilla ei ole merkitystä, jos tehdään vääriä asioita. Kyse on tarkoituksesta.

Esimerkki: Projekti kokonaisuutena

Tuotteen joustavuus vaihtelee projektien välillä. Joissakin IT -kehitysprojekteissa tuote on löyhästi määritelty, ja sen lopullinen muoto riippuu palautteesta, jota kerätään tehdyille tuotoksille projektin aikana, mikä vaatii mukautuvaa (ketterää) lähestymistapaa. Tämä on käytännössä yhdistelmä salkku-, ohjelma- ja projektikerroksia ja toiminta tarvitsee maksimaalisen huomion, joka tähtää lopulliseen tavoitteeseen. On hyvä idea dokumentoida tarkoitus ja tuoda se tietoisuuteen; Tämä on yksi “tuote-vision” tarkoituksista, kuten joissain Scrum -projekteissa käytetään. Huomio tuotteen liiketoiminta-arvoon ketterissä hankkeissa on niiden tapa varmistaa, että toiminta on linjassa tarkoituksen kanssa.

Toisissa projektityypeissä, joissa tuote on suhteellisen vakio ja on olemassa muita mekanismeja varmistamaan, että tuote täyttää tarkoituksen, projektitiimin jäsenet voivat siirtää suurimman osan huomiostaan tarkoituksesta tuotteeseen (tästä johtuu PRINCE2^®-periaatteen “tuotefokus”). Silti on tarpeen kiinnittää jonkin verran huomiota tarkoitukseen sen varmistamiseksi, että synnytetään jotain, joka täyttää tarkoituksen, mikä voidaan tehdä vertaamalla ennustettuja hyötyjä odotettuihin hyötyihin (tästä johtuu jatkuva liiketoimintahyödyn arvioinnin periaate ja PRINCE2^®:n business case-teema.)

Asiakkaalla, jolle projekti toteutetaan, saattaa olla oma tarkoituksensa ja toteuttavalla yrityksellä omansa. Todelliseen onnistumiseen täytyy ymmärtää molemmat.

Esimerkki: Projektin seuranta

Keskittyminen lopulliseen tarkoitukseen on välttämätöntä, mutta se saattaa olla liian abstrakti asia monille päivittäisille toimille. Siksi tarvitaan ‘kuljettajan hierarkia’, jotta siitä saadaan käytännöllisempi. Ensinnäkin, hankkeen perusteet ja hyödyt on määritelty lopullisen tarkoituksen perusteella. Tämän lisäksi on nimenomaisia ja implisiittisiä tavoitteita projektimuuttujille (esim. aikataulu, kustannukset ja laatu) projektin perustelun täyttämiseksi, mitkä puolestaan toteuttavat lopullisen tarkoituksen. Nämä ovat alemman tason tarkoituksia, joista on hyötyä päivittäisessä tekemisessä.

Valvonnan suhteen projektin alemman tason seuranta tehdään käyttämällä alimman tason muuttujia, koska lopullisen tarkoituksen täyttymistä ei välttämättä ole mahdollista seurata. On kuitenkin pidettävä tarkoitus mielessä: Mikä on seurannan tarkoitus?

Normaali ja hyväksyttävä vastaus on ymmärtää, onko projekti matkalla tavoitteeseen, ja jos ei ole, aloittaa korjaavat toimenpiteet, jolla projekti saadaan takaisin raiteilleen, tai voidaan säätää tavoitteita ja tarkistaa, pystytäänkö lopullinen tarkoitus silti täyttämään. Mittaroinnin pitäisi siksi kyetä edesauttamaan tätä alemman tason tarkoituksen toteutumista, ja asianmukaiset mittaukset ovat muuttujien ennusteita valmistumiseen; Esimerkiksi, milloin projekti on valmis? Paljonko projektin loppuun tekeminen kustantaa?

Muut mittaukset, kuten suunnitellut ja totetumat ovat vain väliaikaisia arvoja, joita tarvitaan ennusteiden laskemiseksi, ne ei ole loppuarvoja, joita käytetään johtamistarkoituksiin.

Esimerkki: Dokumentointi

Riippumatta siitä, mitä kehityslähestymistapaa käytetään, suunnittelu on aina välttämätöntä. Tärkeä kysymys on detaljiikan taso kussakin suunnitelmatyypissä. Jos suunnitelmassa ei ole tarpeeksi yksityiskohtia, suunnitelma ei auta tekemistä riittävästi, ja projektin toteuttaminen perustuu ad hoc -päätöksiin, eikä integroityihin, kokonaisuuden huomioiviin päätöksiin. Toisaalta monesti ollaan liian varovaisia ja lisätään suunnitelmaan liikaa yksityiskohtia, mikä vaikeuttaa tekemistä, ylläpitämistä ja on liian jäykkiä projektin epävarmuustekijöille. Seurauksena on, että suunnitelmasta tulee epärealistinen ja hyödytön.

Paras tapa päättää detaljiikan taso on pitää mielessä tarkoitus suunnitelman jokaiselle työpaketille. Esimerkiksi, jos harkitaan resurssien lisäämistä suunnitelmaan, pitää olla tarkoitus: Kuinka tuota resurssia hyödynnetään? Miten tuo resurssi auttaa projektia? Kuinka paljon panostusta tuo resurssi vaatii? Onko tuo kaikki vaivan arvoista?

Toisinaan pitää päättää halutaanko tietty työpaketti suunnitelmaan ja toisinaan pitää päättää tapa, jolla halutaan suunnitella tai valmistautua johonkin. Olipa kyse business case:sta, projektimäärittelystä tai raportista: aina on kysyttävä miksi tuo dokumentti kannattaa tehdä ja miten se auttaa projektia.

Mallin, ’templaatin’ etsiminen on vastakohta sille että täytetään tarkoitus.

Esimerkki: Status-raportointi

On yleistä, että projekteissa valmistellaan pitkiä statusraportteja. Tämän NUP:n perusteella on syytä miettiä, mikä on statusraportin tarkoitus ja miten voimme saavuttaa tuon tarkoituksen riippumatta siitä, miten yleensä toimitaan.

Tämä voi monissa tapauksissa saada meidät laatimaan hyvin yksinkertaisen, yhden sivun raportin, jota sidosryhmät oikeasti lukevat ja ymmärtävät pitkien raporttien sijaan. Tämä on sitä, että kiinnitetään huomio tarkoitukseen.

Yhden sivun statusraporttien perustella, joku saattaa olla eri mieltä ja ajatella että projektilla ei ole kunnollista seurantajärjestelmää paikallaan. Käytännössä tämä luo toisen tarkoituksen (ensimmäisen tarkoituksen lisäksi, joka oli auttaa sidosryhmiä ymmärtämään hankkeen tila) ja täyttääkseen tämän, voi yksinkertaisesti luoda toisentyyppisen, pitkän raportin. Ei kuitenkaan pidä sekoittaa tätä ensimmäiseen raporttiin, koska nämä kaksi tarkoitusta eivät ole samoja.

Esimerkki: Liiketoimintatarkastelu ja projektikuvaus

Asiakirjojen, kuten liiketoimintatarkastelun ja projektikuvauksen, valmistelu on yleensä tylsää, hedelmätöntä, byrokraattista välttämättömyyttä useimmille, vaikkakin kaikilla näillä asiakirjoilla on pätevät tarkoituksensa useimmissa projekteissa. On ajanhukkaa yrittää löytää malli, ’templaatti’, jonka voi vaan täyttää joka projektissa; on parempi ymmärtää kunkin dokumentin tarkoitus, ymmärtää miten ne voivat edistää projektia, ja sitten tuottaa dokumentti haluamallasi tavalla, tavalla, joka täyttää tarkoituksen. Näin toimien syntyy oikea dokumentti.

Miettiessä tapaa miten tuottaa dokumentit oikeaan tarkoitukseen, ei välttämättä tule mietittyä jokaista mahdollista skenaariota ja jotain saattaa unohtua. Tämän välttämiseksi on hyvä tarkistaa Prince:n2, PMBOK^®-ohjeen, P3.express:n ja DSDM^®:n ehdotukset ja arvioida miten hyvin noiden avulla tarkoitus täyttyy.

Esimerkki: Seuranta projektin jälkeen

Vaikka projektilla on erityinen tarkoitus, ja voimme tarkastella tätä tarkoitusta koko projektin ajan, tarkoituksen toteuttamista arvioidaan pääasiassa projektin aikana tehtyjen ennusteiden perusteella. Ei kuitenkaan pidä unohtaa sitä, kun projekti on valmis. On tärkeää tarkistaa tavoitteiden toteutuminen projektin valmistumisen jälkeen, koska

• Silloin voi nähdä, miten projektin lopulliset tavoitteet saavutetaan ja niistä voi ammentaa oppia oppivat tuleville projekteille, ja
• Joskus tavoitteet saavutetaan vain, kun projektin päätyttyä suoritetaan tiettyjä ylimääräisiä tehtäviä ja ymmärretään näiden ylimääräisten tehtävien seurantatarpeen.

Projektin jälkeinen seuranta on välttämätöntä, kun tavoitellaan tarkoituksen toteutumista. Se on pääasiassa projektiohjelman ja salkunhallintajärjestelmien vastuu, ja koska useimmissa yrityksissä ei ole tällaisia hallintotasoja ole, tämä vaihe on yleensä laiminlyöty. Siksi menetelmät, kuten P3.express ja DSDM^®, lisäävät tämän vaiheen projektinhallintamenetelmiin.

Esimerkki: Yksinkertaisuus

Maailma on monimutkainen ja kaoottinen, mutta mallimme ovat abstrakteja likiarvoja, jotka heijastavat maailman tiettyjä palasia, ja siksi ne voivat olla yksinkertaisia. Toisaalta yksinkertaiset järjestelmät toimivat yleensä paremmin, koska ne antavat mahdollisuuden keskittyä pääasiaan.

Monesti yritetään saada aikaan parempia tuloksia lisäämällä järjestelmiin monimutkaisuutta toivoen, että se vastaa maailman monimutkaisuutta, vaikka käytännössä tämä vaikeuttaa järjestelmän kanssa työskentelyä ja yleensä estää meitä täyttämästä tarkoitusta.

Esimerkki: Räätälöinti

Ohjelmistolla, jota käytetään musiikin suoratoistoon on hyvin erilaiset vaatimukset kuin ohjelmistolla, jota käytetään sairaalalaitteistoihin, tai lentokoneen ohjelmistolla, jossa ihmisten elämä voi riippua siitä, tai ohjelmisto, jota käytetään satelliitissa, jossa sen oletetaan työskentelevän monien vuosien ajan kaatumatta, ja ne ovat kaikki erilaisia vaatimuksia kuin kesähuvilan, palontorjunta-aseman ja prosessitehtaan rakentamisen vaatimukset.

Kun tarkoitus on mielessä, ymmärtää paremmin, kuinka räätälöidä järjestelmiä erilaisia projekteja varten.

▼ PDF