# NUPP Projektihallinan lähes universaalit periaatteet [image] Tämä on ladattava versio verkkokäyttöoppaasta (https://omimo.org/fi/modules/nupp/), joka on luotu 2026‑07‑02-päivänä. Tarkista verkkosivustolta, onko uudempa versioita saatavilla. NUPP kuuluu OMIMO-kokonaisuuteen (https://omimo.org/fi/). OMIMO on avoin, minimalististen moduulien perhe. Tätä käyttöopasta voi käyttää ja jakaa vapaasti Creative Commons Attribution 4.0 International -lisenssin nojalla. Euroopan unioni osarahoittaa OMIMOa. Esitetyt näkemykset ja mielipiteet ovat kuitenkin ainoastaan OMIMOn omia eivätkä välttämättä vastaa Euroopan unionin tai EPOS VZW:n näkemyksiä. Euroopan unionia tai rahoituksen myöntävää viranomaista ei voida pitää niistä vastuullisina. Kielikäännös: Jukka Mäki ## Johdanto NUPP on kokoelma projektihallinnan lähes universaaleja periaatteita. Onnistumisen varmistamiseksi näitä periaatteita on viisasta noudattaa kaikissa projekteissa riippumatta siitä mitä projektinhallinnan menetelmää projektissa noudatetaan. NUPP on taustalla yleisesti käytetyissä projektihallinnan menetelmissä. Seuraavat seikat on kuitenkin syytä huomioida: - Kaikki menetelmät eivät aina noudata kaikkia NUPP-periaatteita. On tärkeää huomioida kaikki NUPP-periaatteet, eikä vain osaa niistä. - Tyypillisesti taustalla olevia periaatteita ei korosteta riittävästi, ja niinpä projekteja toteutetaan tavoilla, jotka eivät ole periaatteiden mukaisia. NUPP on harmoniassa kaikkien yleisimpien menetelmien ja lähestysmistapojen kuten PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP ja Scrum kanssa, mutta mahdollisesti se ei vastaa noiden menetelmien kaikkia tulkintoja. NUPP suositteleekin tulkitsijoita harkitsemaan oman tulkinnan oikeellisuutta. NUPP on kokoelma seuraavia lähes universaaleja periaatteita: - NUP1 — Tavoittele tuloksia ja totuutta - NUP2 — Optimoi henkinen energia ja resurssien käyttö - NUP3 — Ole proaktiivinen - NUP4 — Ketju on ytvä vahva kuin sen heikoin lenkki - NUP5 — Kaikella tekemisellä pitää olla tarkoitus - NUP6 — Hyödynnä toistettavuutta ## NUP1 Tavoittele tuloksia ja totuutta [image] Me kaikki haluamme kuulua joukkoon. Se on taipumus, joka luo vahvoja sidoksia ja aiheuttaa ongelmia. Menetämme enemmän kuin saamme sidoksistamme. Meistä voisi tulla ammattimaisempia ja parempia asiantuntijoita, jos emme rajoittaisi identiteettiämme ja mieltymyksiämme tiettyihin ryhmiin. ### Esimerkki: Agile vai vesiputousmalli Joukko erittäin innostuneita ihmisiä, jotka olivat rohkeita kokeilemaan adaptiivisia kehitysmenetelmiä IT-kehityksessä aikana, jolloin ennakoivien lähestymistapojen käyttö oli normaalitoimintatapa, kokoontui ja kutsui lähestymistapaansa sanalla “Agile”. Tämä oli hieno aloite, joka ei rajannut mahdollisuuksia vain siihen, mikä näytti mahdolliselta. Agile-yhteisössä on edelleen paljon innostuneita ja tuloshakuisia ihmisiä, mutta valitettavasti tässä yhteisössä on myös ihmisiä, jotka tekevät Agilesta kultin ja vähättelevät muiden metodiikkojen noudattajia. Tämä aiheuttaa ongelmia useilla tavoilla, mukaan lukien seuraavat: - Oppiminen ryhmän ulkopuolisilta rajoittuu - Ei rohkaise ryhmän ulkopuolisia oppimaan ryhmäläisiltä - Ryhmään kuulumisesta tulee tärkeämpää kuin itse asiasta, mikä rajoittaa ryhmän jäseniä oppimasta mistä Agilessa oikeasti on kysymys. Tätä ilmiötä voidaan merkittävästi vähentää, tai jopa poistaa, käyttämällä termiä ‘Agile’ nimikkeenä, joka viittaa kehittämislähestymistapaan, eikä jäsenyhteisöön, ja jos jäsenet, jotka pitävät itseään uuden luojina, ongelmanratkaisijoina ja johtajina alkavat nähdä Agilen työkaluna eikä identiteettinä. Oikeat ammattilaiset eivät taistele Agilen tai vesiputousmallin paremmuudesta. ### Esimerkki: PRINCE2^(®) vai PMBOK^(®)-opas Monet projektihallinnan ammattilaisista assosioivat itsensä joko PRINCE2^(®):een tai PMBOK^(®)-oppaaseen (yleensä maantieteellisen sijaintinsa vuoksi) eivätkä tunne toista. Meillä kaikilla voi olla tietyt preferenssimme, mutta on parempi tutustua niihin kaikkiin ja siten laajentaa näkökulmaamme ja mahdollisuuksiamme. Todellinen ammattilainen on avoin kaikille ideoille, etsii niitä, oppii niistä ja hyödyntää niitä tarpeen mukaan, ilman sidoksia. ### Esimerkki: Jatkuva oppiminen Kuuluminen ryhmään saattaa antaa tyydytystä yhteenkuuluvuuden tunteen vuoksi, mutta tämä ei pakota oppimaan, ja joskus jopa lannistaa oppimasta, koska on pelko ryhmään kuulumisen menettämisestä. Riippumattomana asiantuntija joutuu täyttämään tuon aukon oppimisella, jatkuvalla oppimisella. Se, mihin uskomme tänään, ei ole totuus. Se on vain paras ymmärryksemme tähän mennessä, ja sitä on parannettava joka päivä. Jotain on pielessä, ideamme ovat täsmälleen samoja kuin muutama vuosi sitten. Tämä koskee myös NUPP:a jos asiat nähdään muutaman vuoden kulutta samoin kuin tänään, on syytä alkaa epäillä oppimista. ### Esimerkki: Avoimuus Eri mieltä ollessasi varmista, että kohdistat vastalauseesi asiaan, ei henkilöön. Näin menetellen vähennämme mahdollisia jännitteitä. Samaan tapaan, kun jos joku on eri mieltä kanssasi, yritä olla ottamatta sitä henkilökohtaisesti, vaan pikemminkin ota se keskusteluna ajatuksistasi ja pysy avoimena tälle keskustelulle. Älä kuuntele vastataksesi, vaan kuuntele ymmärtääksesi; ja työskentele yhdessä idean parantamiseksi. Jotkut saattavat tarkoituksella kohdentaa kommenttinsa henkilöön asian sijaan. Tällöin tulee auttaa tuota henkilöä keskittymään itse asiaan, ei henkilöön. Koko keskustelu tulee pyrkiä käymään tässä hengessä. ## NUP2 Optimoi henkinen energia ja resurssien käyttö [image] Projektin käytettävissä olevat resurssit ja henkinen energia ovat rajallisia, siksi näihin asioihin liittyvien päätöksien pitää olla hyviä. On tärkeää, että panostetaan resurssien käytön ja henkisen energian optimointiin projektin hyväksi, ja että autetaan tiimiä toimimaan samoin. ### Esimerkki: 80/20-sääntö Suuri osa projektinhallinnan mahdollisista hyödyistä voidaan saavuttaa pienellä työllä. Useimmissa tapauksissa 100 %:n tavoitteleminen mahdollisista eduista on erittäin kallista ja perusteetonta. On syytä ottaa 80/20-sääntö huomioon kaikessa tekemisessäsi, ja rohkaistava muita tekemään samoin. ### Esimerkki: Päätöksentekoväsymys Käytämme yhtä ja samaa henkisen energian varastoa kaikenlaisten päätösten tekemiseen ja tahdonvoiman ilmaisemiseen. Jos käytämme suuren osan tästä varastosta tarpeettomien tai merkityksettömien päätösten tekemiseen, jää tärkeämpien päätösten tekemiseen vähemmän energiaa, mikä voi johtaa huonoihin päätöksiin. Tämän takia mikrojohtamista tulee välttää (Tämä on PRINCE2^(®):n “Hallitse poikkeuksia” -periaate). Ideoihin liittyvät erimielisyydet voivat olla hyödyllisiä, mutta ihmissuhteisiin liittyvät ristiriidat ovat yleensä haitallisia projektille, ja yksi seurauksista on, että ne kuluttavat tiimin jäsenten henkistä energiaa. Jos tällainen ristiriita huomataan, tulee tehdä kaikki voitava perimmäisen syy löytämiseksi ja ratkaisemiseksi. ### Esimerkki: Huolehdi itsestäsi! Tekemäsi päätökset ja harjoittamasi tahdonvoima kuluttavat henkisen energian lähdettä. Toisaalta tämä lähde täydentyy energialla, mikäli uni ja ravinto ovat asianmukaisia. Niinpä meidän tulee huolehtia itsestämme. Tulee varmistaa, että uni-, lepo- ja ravintoasiat ovat kunnossa. Haitallisia tapoja tai uniongelmia ei tarvitse käsitellä yksin; monet asiantuntijat voivat auttaa korjaamaan tällaisia ongelmia. Fyysinen aktiivisuus voi myös toimia energian lähteenä, vaikkakaan tutkimukset eivät ole vielä yksimielisiä tästä asiasta. On hyvä kannustaa tiimiä toimimaan samoin kuin itse toimit. On tarpeen varmistaa, että tiimin työskentelytahti on kestävällä pohjalla eikä merkittäviä ylitöitä tarvita. Mikäli mahdollista, on hyvä tarjota tiimille energistä, terveellistä ruokaa, välipaloja ja juomia työaikana. ### Esimerkki: Työn ja vapaa-ajan tasapaino Monet nauttivat työstään, mutta työ ei täytä kaikkia tarpeitamme elämässä. Aivan kuten optimoimme työtämme, on meidän hyvä suunnitella ja soveltaa ideoita henkilökohtaisessa elämässämme tavalla, joka tekee siitä iloisen ja onnellisen. Iloisena ja onnellisena menestyt paremmin myös työssäsi. Mikäli mahdollista, on hyvä kannustaa tiimin jäseniä toimimaan samoin. ### Esimerkki: Motivaatio Motivaatio on monimutkainen asia. Aiheesta on kirjoitettu mielenkiintoisia ja hyödyllisiä tutkimuksia, samoin monia epätieteellisiäkin artikkeleita. Tästä huolimatta meidän tulisi oppia motivointia ja hyödyntää sitä jatkuvasti, koska motivaatio lisää tiimin henkistä energiaa ja mahdollisuuksia saavuttaa parempia tuloksia projektissa. Motivaatio voi olla niinkin yksinkertaista kuin että kerrotaan tekiijöille, että heidän hyvä työ on huomattu esimerkiksi ystävällisen hymyn tai yksinkertaisen “kiitos” -lausahduksen kautta. Motivoinnissa täytyy kuitenkin oltava harkitseva, koska monet yleiset motivaation muodot, kuten pienet rahalliset palkinnot, voivat aiheuttaa myös negatiivisen vaikutuksen. ### Esimerkki: Yhteistyö ja tiimityö Yhteistyötä tekevillä tiimeillä saattaa joskus olla valtaa luoda parempia tuloksia, mutta mikä tärkeintä, ihmisolennot ovat sosiaalisia ja nauttivat ryhmään kuulumisesta. Mikäli tiimityön haittapuolet saadaan poistettua ja onnistutaan luomaan miellyttävä työympäristö, projektissa on onnellisempia tiimin jäseniä. Harkintaa kuitekin tarvitaan, koska ihmiset ovat erilaisia; jotkut kaipaavat rennompaa yhdessä tekemistä ja toiset keskittyneempää yksintekemistä; tämä on tasapainon hakemista. ### Esimerkki: Yhden tiimin kulttuuri Eri sidosryhmillä on taipumus luoda alaryhmiä ja aiheuttaa jännitteitä muiden ryhmien kanssa; esimerkiksi, ne, jotka ovat keskittyneet projektin liiketoimintaan, vs. ne, jotka kehittävät tuotetta. Tämä jännitys kuluttaa paljon energiaa molemmilta puolilta, siksi on tärkeää yrittää rakentaa yhden tiimin kulttuuria, jossa kaikki työskentelevät yhdessä saman tavoitteen eteen. ### Esimerkki: Joukkoviisaus Kun suuri joukko erilaisia ihmisiä kokoontuu ja työskentelee ohjatussa ympäristössä, on mahdollista saada erittäin hyviä tuloksia, ideoita ja ratkaisuja, jotka voivat olla jopa parempia kuin yksittäisten asiantuntijoiden tuottamat. Mikäli mahdollista, tätä vaihtoehtoa voi käyttää säännöllisesti ja pyytää tiimin jäseniä auttamaan vaikeiden ongelmien ratkaisemisessa projektissa. Hyvien tulosten mahdollisuuden lisäksi tämä toimintatapa viestii tiimin jäsenille, että heidän mielipidettä arvostetaan ja että he pelaavat tärkeää roolia projektissa, mikä puolestaan lisää heidän energiatasoaan. P3.expressin aktivitetti E02 on esimerkki joukkoviisauden käytöstä projekteissa. ### Esimerkki: Projektin ykkösapulainen Projektipäällikkönä suurin osa tekemisistäsi on (tai ainakin sen pitäisi olla) luonteeltaan facilitoivaa, avustavaa. Toisaalta saatat huomata, että tiimin jäsenillä on aikaisempia, huonoja kokemuksia projektinjohtajista, ja nämä kokemukset vaikuttavat heidän suhteeseensa sinuun: osa heidän energiastaan kuluu käyttäytymisesi analysoimiseen mahdollisten uhkien varalta sen sijaan, että he luottaisivat sinuun. Tällaisessa tilanteessa voit kokeilla muuttaa titteliäsi projektipäälliköstä projektin ykkösapulainen. Loppujen lopuksi se on sitä, mitä teet projektissa. ## NUP3 Ole proaktiivinen [image] Meissä on luonnollinen taipumus olla reaktiivisia. Tämä ilmiö saattaa auttaa meitä säilyttämään energiamme käsittelemällä merkityksettömiä asioita, tai johtaa parempiin tuloksiin, kun olemme tekemisissä sellaisen kanssa, jota emme hallitse. Nämä tilanteet eroavat projekteista, ja niissä voimme saada parempia tuloksia olemalla proaktiivisia. ### Esimerkki: Suunnittelu Jos olet ajamassa uuteen paikkaan ja olet jo myöhässä, voit aloittaa ajamisen välittömästi “ajan säästämiseksi” ja puuttua mahdollisiin ongelmiin niiden ilmaantuessa. Proaktiivinen lähestymistapa on kuitenkin käyttää hetki alussa, asettaa navigointijärjestelmä osoittamaan nopeimman reitin liikenteen ja mahdollisten onnettomuuksien ja tukosten perusteella ja sitten lähteä ajamaan. Tämä kuluttaa aikaa ennen varsinaista ajosuoritusta, mutta auttaa välttymään ongelmilta myöhemmin, ja näin säästyy kokonaisaikaa. Toisin kuin jotkut ajattelevat ketteristä projekteista, suunnittelu on aina välttämätöntä, ja kyse on vain suunnitelmien tyypistä ja tasosta. Suunnittelu ennen toteuttamista on proaktiivista toimintaa. Muista lainaus: “anna minulle kuusi tuntia kaataa puu, ja käytän ensimmäiset neljä kirveen teroittamiseen.” Jos kyseessä on ennakoiva projekti, saatetaan käyttää 4 tuntia kirveen teroittamiseen, koska tiedetään, että suunnitelmana on kaataa puu. Ketterässä projektissa ei olla varmoja, että aiotaanko kaataa puu, kerätä katkenneita oksia, korjata nurmikkoa, louhia hiiltä vai jotain muuta. Tästä huolimatta näihin kaikkiin on silti oltava yleistason valmistautuminen (täytyy tietää missä lähin rautakauppa on) ja tehdä erityisvalmistelut (teroitus) sitten kun alat keskittyä tiettyyn ratkaisuun; se on suunnittelua. ### Esimerkki: Suunnittelun suunnittelu Suunnittelemalla tapa, jolla toteuttaa projektin, on proaktiivisuutta. Tätä proaktiivisuutta voidaan jopa laajentaa suunnittelemalla tapa, jolla suunnittelemme toteutuksen; sitä ovat PMBOK^(®)-oppaan johtamissuunnitelmakonsepti, PRINCE2^(®):n johtamisstrategiat ja DSDM^(®):n lähestymistavat. ### Esimerkki: Jatkuva suunnittelu Todellisuus vastaa harvoin suunnitelmia, ja tämä on ok – mutta suunnitelmia on jatkuvasti mukautettava varmistaaksemme, että ne pysyvät realistisina ja käytännöllisinä. Tämä mukautus pitää tehdä heti muutostarpeen ilmetessä eikä vasta ongelmia kohdatessa. Tämä on proaktiivisuutta. ### Esimerkki: Riskien hallinta Koko riskienhallinnan käsite perustuu proaktiivisuuteen: kun kohtaamme riskialttiita asioita, sen sijaan, että odotamme, mitä tapahtuu, ja sitten reagoimme, hahmotamme mahdollisia vaihtoehtoja ja vaikutuksia ja suunnittelemme ja pyrimme tekemään riskille jotakin ennenkuin se toteutuu. Huomaa, että se, mitä teemme projekteissa, voi olla vakavaa; joskus kyse on ihmishengestä. ### Esimerkki: Määrittele roolit ja vastuut Projektitiimin voi laittaa tekemään työtä ilman selkeitä rooleja ja vastuita, ja ennemmin tai myöhemmin syntyy rooli- ja vastuumuoto, mutta tämä on liian kallista eikä välttämättä toimi hyvin. Proaktiivinen lähestymistapa on määritellä roolit ja vastuut etukäteen ja mukauttaa niitä tarpeen mukaan. Tämä tekee työstä helpompaa kaikille, ja jäsenet voivat keskittyä tuottavaan työhön sen sijaan, että miettisivät, kuka tekee ja mitä. Roolien määrä riippuu projektin tyypistä ja koosta; roolitus voi olla yksinkertainen määritelmä, kuten Scrumissa, jotain kohtalaista, kuten P3.express:ssa, tai jotain kattavaa, kuten DSDM^(®):ssä ja PRINCE2^(®):ssa. Ei pidä unohtaa, että näiden menetelmien roolikuvaukset koskevat vain johtamistoimintoja ja että sinun on aina lisättävä roolikuvaukset myös teknistä kehitystä varten. ### Esimerkki: Mahdolliset vaihtoehdot Pitäisikö projekti keskeyttää vai jatkaa sitä? Harvoin on vain kaksi vaihtoehtoa, joista valita, vaikka kysymys viittaa siihen. On oltava proaktiivinen lähestymistapa ja harkittava kaikkia vaihtoehtoja ennen päätöksentekoa. Ehkä projektin sisällön voisi määritellä uudelleen; ehkä projektin voi laittaa tauolle, kunnes jotain oleellista selviää; tai ehkä projektin lähestymistapaa voi muuttaa (esim. ulkoistaminen) jne. ### Esimerkki: Kriittinen ajattelu Meillä kaikilla on monia ajattelun vinoumia, jotka toisaalta auttavat meitä selviytymään ja toisaalta huijaavat meitä tekemään huonoja päätöksiä. Kun on tehtävä tärkeitä projektipäätöksiä, on parasta pysähtyä hetkeksi ja tarkastella noita vinoumia ennen kuin ne aiheuttavat ongelmia. Viitteenä voit käyttää Wikipediassa annettua luetteloa kognitiivisista vinoumista. On olemassa jopa päätöksentekometodiikkoja, joiden avulla voit tehdä parempia päätöksiä. Aluksi niiden käyttäminen voi olla häiritsevää ja jopa ärsyttävää, mutta niihin tottuu ja niistä alkaa saada hyötyä ilman suurta tietoista ponnistelua. ### Esimerkki: Läpinäkyvyys Emme pidä projektin myöhästymisestä emmekä muistakaan projektiongelmasta, mutta tämä ei tarkoita, että meidän pitäisi piilottaa niitä. On oltava läpinäkyvä ja viestiä ongelmista sidosryhmille, koska osa heistä voi auttaa projektia. Lisäksi sidosryhmät saavat tietävät ongelmista ja niiden seurauksista ennemmin tai myöhemmin joka tapauksessa, ja osa heistä saattaa vaatia varhaisia toimia omalta puoleltaan (esim. voidaan hyväksyä negatiivinen seuraamus). ### Esimerkki: Viesti tehokkaasti Usein voi käydä niin että sidosyhmille lähetetään raportteja, mutta palautta ei tule. Saattaa syntyä luulo, että kaikki on hyvin vain siksi, että negatiivista palautetta ei ole, vaikka asia ei välttämättä olekaan niin. On oltava proaktiivinen ja tarkistettava onko raportteja luettu ja onko raportointi palvellut tarkoitustaan. Käytä saamiasi kommentteja viestintätapasi säätämiseen,ettei palautteen saamattomuus aiheuta vakavia ongelmia myöhemmin, kun sitä on liian vaikea korjata. ### Esimerkki: Kanna vastuu On helppoa syyttää muita huonoista tuloksista. Voit esimerkiksi haluta, että organisaatiosi antaa sinulle täydet valtuudet organisoida projekti uudelleen ja toteuttaa se täydellisesti, mutta organisaatio ei tee niin, ja seurauksena projekti epäonnistuu. Tämä ei ole proaktiivista toimintaa. Proaktiivista toimintaa on kantaa vastuu ja tehdä kaikki voitava rajoitusten puitteissa. Et voi odottaa organisaation luottavan sinuun täysin ja antavan sinulle kaiken mahdollisen hyvien tulosten toivossa, etenkin kun päättäjät ovat nähneet niin monia epäonnistuneita projekteja. Parasta on toteuttaa yksi pieni parannus asetettujen rajoitusten puitteissa, hyödyntää tuota parannusta saadaksesi hieman lisää luottamusta, hiukan lisää resursseja ja hieman löysempiä reunaehtoja, ja sitten hyödyntää syntynyttä luottamusta hieman suurempiin parannuksiin ja jatkaa tällä tavalla, kunnes saavutat optimaalisen tavoitteen. ## NUP4 Ketju on ytvä vahva kuin sen heikoin lenkki [image] Projektissa on useita eri aihealueita, ja ne kaikki vaativat huomiota; on oltava kokonaisvaltainen näkökulma hankkeeseen. Huomion kiinnittäminen näennäisesti tärkeälle aihealueelle (esim. aikataulu) ei riitä, koska projektin kaikki aihealueet ovat vuorovaikutuksessa, eivätkä onnistu kunnolla, elleivät ne kaikki saa riittävästi panostusta. ### Esimerkki: Kyse on aikataulusta Oletetaan, että rakennat jotain olympialaisia varten. Projektilla on erittäin tiukka aikataulu, mikä tekee ajanhallinnasta erittäin tärkeää. Onko tämä kuitenkaan oikein? Entä jos laatu on niin heikko, että työ pitää tehdä uudelleen jonkin ajan kuluttua. Tämä vaikuttaisi aikatauluun, joten laatu on aikaa ja laatua. Projektin alkuperäisessä määritelmässä saattaa olla listattuna puutarha, mutta jos aikaa ei ole tarpeeksi, puutarha voidaan jättää tekemättä ja tilalle voidaan laittaa nurmikko, kunhan tämä mahdollisuus on huomioitu ja siihen on varauduttu. Niinpä projektin laajuuden hallinta on myös tärkeää. Nyt huomiomme keskipisteenä ovat laajuus, aikataulu ja laatu. Oletko kuullut siitä kuuluisasta esimerkistä, jossa presidentti Kennedy tapaa vahtimestarin NASA:ssa ja kysyy häneltä, mitä tämä tekee, ja hän vastaa: “Autan lähettämään miehen kuuhun”? Eikö tämäntyyppinen osallistuminen projektiin auta onnistumaan projektin aikataulun saavuttamisessa? Kun jatketaan tätä ajattelua, huomataan että projektin jokainen aihealue vaikuttaa aikatauluun, eikä aikataulu onnistu hyväksyttävällä varmuudella, ellei huomioita kiinnitetä kaikkiin aihealueisiin. ### Esimerkki: Kirsikanpoimintaa Kun käytämme eri menetelmiä, usein alamme poimimaan kirsikoita ja luomme yhdistelmän kaikkea kiinnostavaa eri järjestelmistä. Tämä ei kuitenkaan yleensä toimi, koska eri järjestelmien elementit eivät toimi erillään ja niiden on oltava yhteensopivia keskenään. Kaikki lisäykset tai muutokset järjestelmään tulee tehdä kokonaisvaltaisesti. Tästä syystä näemme joskus ristiriitaisia elementtejä eri menetelmissä; jokin toimii hyvin yhdessä järjestelmässä ja sen vastakohta toimii hyvin toisessa järjestelmässä. Yksittäinen elementti ei ole sinänsä oikea tai väärä. Turvallisin tapa on valita projektille metodologia, räätälöidä sitä ja lisätä siihen sitten varovasti uusia elementtejä koko järjestelmän johdonmukaisuus huomioiden. ### Esimerkki: Prosessinvastainen lähestymistapa Yksi parhaimmista ketterien menetelmien ansioista on kiinnittää huomio ihmisnäkökulmaan. Agile Manifesto antaa enemmän arvoa yksilöille ja vuorovaikutuksille kuin prosesseille ja työkaluille, vaikka tämä ei välttämättä ole oikeudenmukainen vertailu. Lähes kaikissa menetelmissä todetaan, että ihmisnäkökulma on tärkeä, mutta todellinen ero Agilessa on, että ihmisnäkökulma on prosessiin sisäänrakennettu, eikä se ole vain yksinkertainen ehdotus. Joten kyse ei ole ihmisnäkökulman ja prosessien välisestä kilpailusta, vaan pikemminkin tapa, miten ihminen näkyy järjestelmässä. On selvää, että jotkut yrittävät korvata ihmisnäkökulman lisäämällä hienostuneempia prosesseja, mutta se on vain väärää toimintaa. Ja päinvastainen on myös: prosessien korvaaminen ihmisnäkökulmalla ei myöskään toimi hyvin. ### Esimerkki: Projektihallinnan tarvittavat aihealueet Kun tarkastellaan projektihallinnan aihealueita, täytyy olla varovainen, ettei jokin alue unohdu. Mitä ne aihealueet sitten ovat? Jos katsotaan projektihallinnan tärkeimpiä metodeja ja lähestymistapoja, saadaan erilaisia vastauksia; Ja mikään niistä ei ole koko totuus. Prince2 -teemat ovat aihealueita, mutta vain niitä, joilla on avainrooli metodologiassa. Muihin aihealueisiin vain viitataan. PMBOK^(®)-opas ei ole metodologia vaan se pitää ymmärtää projektihallinnan kymmenenä aihepiirinä. Nämä aihepiirit heijastavat PMBOK^(®)-oppaan näkökulmaa projektinhallintaan sen sijaan, että opas tarjoaisi puhtaan neutraalin näkökulman (toki voidaan kysyä, että onko neutraalia näkökulmaa olemassakaan). Esimerkiksi inhimillinen ulottuvuus ei saa paljoakaan huomiota PMBOK^(®)-oppaassa. Hyvä tietolähde projektihallinnan aihealueiden ymmärtämiseksi on ICB, vaikka se ei niinkään keskity aihealuesiin, vaan niiden vaatimiin osaamisiin. ICB ei tarjoa suoraa yhteyttä aihealueisiin, mutta kylläkin auttaa tunnistamaan niitä. NUPP ei luettele aihealueita ennen kaikkea koska NUPP on metajärjestelmä ja koska aihealueiden luokittelu riippuu projektityypistä; esimerkiksi rutiininomainen rakennusprojekti saattaa vaatia erilaisen näkökulman kuin luova tutkimusprojekti. ## NUP5 Kaikella tekemisellä pitää olla tarkoitus [image] 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. ## NUP6 Hyödynnä toistettavuutta [image] Ad hoc -lähestymistapa projektin toteuttamiseen vie liikaa energiaa ja resursseja, ja aina on riski, että jokin oleellinen projektihallinnan elementti puuttuu. Paras tapa yksinkertaistaa projektien toteutusta on käyttää toistettavia elementtejä ja mieluiten hyödyntää niitä toistettavissa sykleissä. ### Esimerkki: Laadun tarkistuslista Tarkistuslista on yksinkertainen esimerkki mahdollisesti toistettavasta elementistä, jota monet käyttävät henkilökohtaisessa ja ammatillisessa elämässään. Otetaan esimerkiksi tuotoksen laatukriteerit: - Ensinnäkin on hyvä luoda tarkistusluettelo kaikista kriteereistä, mikä on yksi suunnittelun muoto. - NUP6:n suositus on yrittää luoda geneerinen lista: Onko projektissa muita vastaavia tuotoksia? Siinä tapauksessa tee yleinen laadun tarkistuslista kyseiselle toimitusluokalle ja hyödynnä sitä niille kaikille. Jos tästä on poikkeuksia, pidä lähtökohtana geneerinen lista ja lisää muutama ylimääräinen kriteeri yksittäisille tuotoksille. Näin toimien projektilla on nyt toistettavia tarkistuslistoja. - Kun valmistelee yleisiä tarkistuslistoja erityyppisiä tuotoksia varten, saattaa löytää toistuvia elementtejä, mikä viittaa virtuaaliseen yhteiseen luokkaan. Tällöin sen sijaan, että samat kriteerit toistetaan kaikille näille yleisille tarkistuslistoille, ne voi purkaa ja laittaa yhteiseen tarkistusluetteloon. Lopulta todennäköisesti yksi tarkistuslista riittää koko projektille. Scrumin “Valmiuden määritelmä” on esimerkki projektitason tarkistuslistojen käytöstä laadun osalta (mahdollinen myös muiden). Tällä tavoin jokaiselle tuotokselle syntyy hierarkinen vaatimusrakenne ja tuotoksen tulee täyttää ketjunsa jokaisen tason vaatimukset. Näin tekemällä yhteisen tarkistusluettelon kohta toistetaan kaikille sen alla oleville tuotoksille, mikä säästää aikaa ja energiaa suunnittelussa ja toteuttamisessa. Vielä tärkeämpää on, että kun tämä on tehty yhdelle projektille, sitä voi räätälöidä ja käyttää kaikissa tulevaisuuden vastaavissa projekteissa, mikä on yksi toiston muoto moniprojektisuunnittelussa. ### Esimerkki: prosessit ja työnkulut Jotkut tuotokset tai niihin liittyvät tavoitteet tarvitsevat tiettyjä työvaiheita, jotta ne voivat tulla standardisoiduiksi ja toistettaviksi. Esimerkiksi, jos tuotos on suunniteltava ja hyväksyttävä erikseen, voidaan valmistella yksinkertainen työnkulku, joka sisältää kaikki työvaiheet, tekijät ja likimääräiset kestot, ja näin välttää monia vaikeuksia. On kuitenkin varottava, ettei työnkulusta ja prosesseista tule liian monimutkaisia tai liian työläästi dokumentoitavia, koska tällä olisi ikäviä seuraamuksia. Kaikkien projektiin osallistuvien tulisi nähdä työnkulut ja prosessit heidän työtään tukevana asiana tehden työstä helpompaa, eikä byrokraattisena dokumentaationa, joka estää heitä tekemästä oikeaa työtä. Ketterissä menetelmissä käytetään toistettavia elementtejä iteratiivisessa kehityslähestymistavassa, jossa tietyntyyppiset kehitystoimet toistetaan jokaiselle ominaisuudelle; esim. Yleinen päivittäinen rutiini XP: ssä (eXtreme Programming): valitse pari, valitse työstettävä kohde, suunnittele se taululle, synnytä testiskriptit ja koodi, integroi koodi jne. Toistettavia työnkulkuja voi käyttää tekniseen toimintaan, mutta myös projektinhallintaan: PMBOK^(®)-oppaan, Prince2:n ja DSDM^(®):n prosessit ja P3.expressin ja Scrumin tapahtumat ovat esimerkkejä tästä ajattelusta. ### Esimerkki: Syklit Toistettavat elementit projektin hallinnassa ovat hyödyllistä. Tätä voidaan tehdä vielä helpommaksi asettamalla elementit toistettaviin sykleihin. Nämä syklit yksinkertaistavat merkittävästi projektin johtamiseen ja johtamiseen osallistuvien ihmisten päivittäistä toimintaa. Prosessiryhmien syklit PMBOK^(®)-oppaassa, kun niitä käytetään projektissa, jossa on useita vaiheita, vaiheet Prince2:ssa, päivittäiset, viikoittaiset ja kuukausittaiset syklit P3.express:ssä, DSDM^(®):n iteraatiot ja aikaikkunat sekä Scrumin sprintit ovat kaikki esimerkkejä tästä konseptista. Lyhyempiä syklejä on helpompi ymmärtää ja käyttää kuin pidempiä; esim. sprintit Scrumissa toisin kuin PMBOK^(®)-oppaan mukaiset vaiheet. Liian lyhyet syklit eivät kuitenkaan välttämättä riitä tukemaan tietyntyyppisiä projekteja, ja ratkaisu voi olla useiden syklien käyttö, kuten DSDM^(®):ssä lyhyiden aikaikkunasyklien käyttö pidempien iteraatiosyklien kanssa tai p3.express:n käyttämät päivittäiset, viikoittaiset ja kuukausittaiset syklit. ### Example: Metodiikka Menetelmän tai määritellyn lähestymistavan käyttäminen projektin toteuttamiseen on toinen toistettavien elementtien käyttö. Tämä voi olla olemassa oleva järjestelmä, kuten Prince2, P3.express, DSDM^(®) tai Scrum tai sellainen, jonka olet räätälöinyt tai rakentanut itse. On kuitenkin yleensä parempi idea aloittaa yhdellä olemassa olevista menetelmistä ja mukauttaa se tarpeisiisi kuin rakentaa se tyhjästä. Toistettava elementti on olemukseltaan abstrakti ja tarvitsee mukautuksen todelliseen maailmaan. Räätälöinnin tarve vaihtelee: Pienet, suhteellisen konkreettiset laadun tarkistuslistat ovat spektrin toisessa päässä, abstraktiotaso on alhainen ja räätälöinnin tarve vähäinen, kun taas metodologiat ovat spektrin toisessa päässä ja räätälöintitarve on suurempi. Räätälöinnin tarve täytyy aina huomioida, muutoin toistettava elementti ei vastaa tarpeitasi kunnolla.