Luin hiljattain kaksi australialaisen huippucoachin David Rockin kirjaa valmentavasta johtamisesta. Kirjat ovat nimeltään Quiet Leadership ja Your Brain at Work. Voin lämpimästi suositella molempia opuksia kaikille yksilöiden suorituskyvyn parantamisesta kiinnostuneille.
Olen mieltynyt Rockin ajatukseen, jonka mukaan ihmisten ongelmia ei (projekteissa tai muutenkaan) kannata suinpäin ratkomaan heidän puolestaan. Jos projektipäällikkö esiintyy messiaana, jolla on kaikki viisaus hallussaan, ihmiset alkavat myös odottaa sitä häneltä. Tämä taas ei ole omiaan ihmisten oma-aloitteisuuden ja ratkaisuhakuisuuden kehittämiseksi.
Your Brain at Work esittelee mielenkiintoisella tavalla vielä kolme raudanlujaa perustetta sille, miksi ihmisiä ei kannata aina neuvoa, vaan ohjata heidät mieluummin pohtimaan ongelmaansa:
1) Jokaisen ihmisen mieli on erilainen. Meillä kaikilla on sama perspektiiviharha: tajusimme tai emme, me oletamme muiden olevan samankaltaisia kuin itse olemme. Aivotutkimus on osoittanut tämän virhepäätelmäksi suorastaan aivojen toiminnan tasolla. Jos jokaisen ihmisen aivot ovat sekä rakenteeltaan että toiminnaltaan ainutlaatuiset, miten voimme olettaa että sama ongelmanratkaisun tapa toimii kaikkien kohdalla? Siis: se mikä toimii sinulle, ei ainakaan automaattisesti toimi muiden projektissasi työskentelevien kohdalta.
2) Neuvomalla saat vain harvoin aikaiseksi oivalluksen toisessa ihmisessä. Aivoja koskevissa tutkimuksissa on saatu selville, että kun ihminen aikaansaa oivalluksen (joka muuten on pääasiallinen tapa, jolla aikuinen oppii), hänen aivoissaan aktivoituu monta aluetta samanaikaisesti. Aivoihin syntyy uusi kytkentöjensarja, eräänlainen ”kartta” tai ”kartta kartoista”. Tällainen kartta puolestaan myötävaikuttaa siihen, että oivallus johtaa konkreettisiin toimenpiteisiin. Siis: omakohtaisesti oivalletut asiat muuttuvat käytännön toimiksi paljon todennäköisemmin kuin ulkopuolisen antamat neuvot.
3) Kolmas peruste liittyy ihmisten väliseen vuorovaikutukseen. Sen perusilmiöitä on, että ihmisten ensimmäiseksi ilmaisema ongelma on vain harvoin se ongelman ”juurisyy” tai villakoiran ydin. Jos tartut päällimmäisenä olevaan ongelmaan, se on vain harvoin tuo juurisyy. Siis vaarana on että hoidetaan oiretta, ei oireen aiheuttajaa.
Entä miten ihmisten ajattelua sparrataan ongelmanratkaisussa? Ensimmäinen lähtökohta on oikeanlaisten kysymysten esittäminen.
maanantai 18. lokakuuta 2010
keskiviikko 22. syyskuuta 2010
Mitä projektipäällikön kannattaa tietää aivojen toiminnasta?
Aloitin pari viikkoa sitten business coach –opintoni. Koulutuksen järjestäjän viitekehys nojaa uusimpaan aivotutkimukseen ja pyrkii luomaan siltoja neurologian ja johtamisen kehittämisen välille. Ala on äärimmäisen kiinnostava myös projektijohtamisen kannalta ja monet lähiaikojen blogipäivityksistäni tulevat todennäköisesti käsittelemään tätä aihetta.
Projektiryhmän ja sen jäsenten toiminnan ymmärtämisessä coachingin perusopinkappaleisiin kuuluva, David Rockin kehittämä SCARF-malli on erittäin mielenkiintoinen (ks. Esim. http://www.strategy-business.com/article/09306?pg=all). SCARF tulee sanoista Status, Certainty, Autonomy, Relatedness ja Fairness. Näitä viittä asiaa tietoisuutemme etsii jatkuvasti, vähintäänkin kaikissa sosiaalisissa tilanteissa.
Syyt tähän ovat syvällä ihmisen fysiologiassa. Vielä kymmenen tuhatta vuotta sitten yksilö joka ei pitänyt huolta perusasioista - asemastaan ryhmässä, turvallisuudesta ja jatkuvuudesta, mahdollisuuksistaan vaikuttaa elinympäristöönsä, ryhmän kiinteydestä ja muiden kohtelun oikeudenmukaisuudesta – suljettiin pian ryhmän ulkopuolelle. Ryhmän ulkopuolelle sulkeminen merkitsi melko varmasti syödyksi tai lyödyksi tulemista.
Tietoyhteiskunnassa toimiva projektiyritys on monella tavalla erilainen kuin kivikauden elinympäristö, mutta ihmisaivot tarvitsevat edelleen näitä viittä perusasiaa voidakseen hyvin, toimiakseen tehokkaasti ja luovasti. Aivot pyrkivät niitä kohden ja kokevat näiden asioiden kyseenalaistamisen uhkaksi. Aivokemian kannalta tällaisen ”sosiaalisen uhkan” seuraukset ovat aivan samanlaiset kuin fyysisen hyökkäyksen tai muun konkreettisen uhkan. Niinpä projektipäällikönkin kannattaa kantaa kortensa kekoon ryhmän hyvinvoinnin edellytysten luomisessa:
Status: pidä huolta että ketään ei alisteta ryhmässä
Certainty: luo viestinnällä ja projektityön rutiineilla jatkuvuutta ja ylläpidä ihmisten turvallisuuden tunnetta
Autonomy: varmista että jokaista yksilöä kuullaan hänen työhönsä vaikuttavissa päätöksissä
Relatedness: pidä huolta että ketään ei suljeta projektiryhmän ulkopuolelle
Fairness: kohtele ihmisiä oikeudenmukaisesti ja vaadi sitä myös muilta
Projektiryhmän ja sen jäsenten toiminnan ymmärtämisessä coachingin perusopinkappaleisiin kuuluva, David Rockin kehittämä SCARF-malli on erittäin mielenkiintoinen (ks. Esim. http://www.strategy-business.com/article/09306?pg=all). SCARF tulee sanoista Status, Certainty, Autonomy, Relatedness ja Fairness. Näitä viittä asiaa tietoisuutemme etsii jatkuvasti, vähintäänkin kaikissa sosiaalisissa tilanteissa.
Syyt tähän ovat syvällä ihmisen fysiologiassa. Vielä kymmenen tuhatta vuotta sitten yksilö joka ei pitänyt huolta perusasioista - asemastaan ryhmässä, turvallisuudesta ja jatkuvuudesta, mahdollisuuksistaan vaikuttaa elinympäristöönsä, ryhmän kiinteydestä ja muiden kohtelun oikeudenmukaisuudesta – suljettiin pian ryhmän ulkopuolelle. Ryhmän ulkopuolelle sulkeminen merkitsi melko varmasti syödyksi tai lyödyksi tulemista.
Tietoyhteiskunnassa toimiva projektiyritys on monella tavalla erilainen kuin kivikauden elinympäristö, mutta ihmisaivot tarvitsevat edelleen näitä viittä perusasiaa voidakseen hyvin, toimiakseen tehokkaasti ja luovasti. Aivot pyrkivät niitä kohden ja kokevat näiden asioiden kyseenalaistamisen uhkaksi. Aivokemian kannalta tällaisen ”sosiaalisen uhkan” seuraukset ovat aivan samanlaiset kuin fyysisen hyökkäyksen tai muun konkreettisen uhkan. Niinpä projektipäällikönkin kannattaa kantaa kortensa kekoon ryhmän hyvinvoinnin edellytysten luomisessa:
Status: pidä huolta että ketään ei alisteta ryhmässä
Certainty: luo viestinnällä ja projektityön rutiineilla jatkuvuutta ja ylläpidä ihmisten turvallisuuden tunnetta
Autonomy: varmista että jokaista yksilöä kuullaan hänen työhönsä vaikuttavissa päätöksissä
Relatedness: pidä huolta että ketään ei suljeta projektiryhmän ulkopuolelle
Fairness: kohtele ihmisiä oikeudenmukaisesti ja vaadi sitä myös muilta
tiistai 17. elokuuta 2010
90/10 sääntö puutarhaprojektissa
Vanhan viisauden mukaan projektit edistyvät nopeasti kunnes ne ovat 90-prosenttisesti valmiita. Sen jälkeen niillä on taipumus jämähtää paikalleen ja viimeisten 10 prosentin suorittaminen kestääkin sitten ikuisuuden (viimeaikaisista aiheen käsittelyistä ks. esim. http://herdingcats.typepad.com/my_weblog/)
Moni on huomannut tämän ilmiön ja selityksiä sille on lähes yhtä monta. Itse koin hyvin omakohtaisesti projektin viimeisten työvaiheiden aiheuttaman päänsäryn tänä kesänä siviilielämässä – kaivaessani pihaterassin perustuksia puutarhaamme. Löysin ainakin kolme hyvin yleistä syytä oman projektini venymiselle ja vanumiselle.
1) koko projektin vaatima työmäärä on yksinkertaisesti arvioitu väärin (poistettavaa maa-ainesta ei olekaan peruskallion päällä 20 vaan 40-60 senttiä)
2) projektin lähestyessä pilotointi- tai käyttöönottovaihetta paljastuu ongelmia, jotka olisi pitänyt ratkaista aikaisemmin tai joihin olisi ainakin pitänyt valmistautua suunnitelmissa (kivikovaksi pakkautunutta sinistä savea peruskalliota vasten)
3) yksinkertaisesti into tai energia loppuu (kädet känsillä, selkä liian kipeä kaivamiseen)
Entä sinun projektisi - venyykö se ja mistä löytyvät syyt? Entä millä eväillä aikataulun repsahtamista voidaan välttää?
Moni on huomannut tämän ilmiön ja selityksiä sille on lähes yhtä monta. Itse koin hyvin omakohtaisesti projektin viimeisten työvaiheiden aiheuttaman päänsäryn tänä kesänä siviilielämässä – kaivaessani pihaterassin perustuksia puutarhaamme. Löysin ainakin kolme hyvin yleistä syytä oman projektini venymiselle ja vanumiselle.
1) koko projektin vaatima työmäärä on yksinkertaisesti arvioitu väärin (poistettavaa maa-ainesta ei olekaan peruskallion päällä 20 vaan 40-60 senttiä)
2) projektin lähestyessä pilotointi- tai käyttöönottovaihetta paljastuu ongelmia, jotka olisi pitänyt ratkaista aikaisemmin tai joihin olisi ainakin pitänyt valmistautua suunnitelmissa (kivikovaksi pakkautunutta sinistä savea peruskalliota vasten)
3) yksinkertaisesti into tai energia loppuu (kädet känsillä, selkä liian kipeä kaivamiseen)
Entä sinun projektisi - venyykö se ja mistä löytyvät syyt? Entä millä eväillä aikataulun repsahtamista voidaan välttää?
Projektibloggaaja sapattivapaalle, blogi jatkaa ilmestymistään
Hei lukija,
Yli kymmenen innostavan ja työntäyteisen konsultointivuoden jälkeen olen päättänyt vetää hetkisen henkeä. Vietän syksyn 2010 sapattivapaata, mutta jatkan tämän blogin säännöllistä julkaisemista. Toivottavasti minulla on myös tähänastista enemmän aikaa seurata ajankohtaista kansainvälistä kirjoittelua projektimaailmassa ja jakaa sen parhaita paloja sinulle!
Seesteistä ja energisoivaa syksyä toivottaen,
Aaro
Yli kymmenen innostavan ja työntäyteisen konsultointivuoden jälkeen olen päättänyt vetää hetkisen henkeä. Vietän syksyn 2010 sapattivapaata, mutta jatkan tämän blogin säännöllistä julkaisemista. Toivottavasti minulla on myös tähänastista enemmän aikaa seurata ajankohtaista kansainvälistä kirjoittelua projektimaailmassa ja jakaa sen parhaita paloja sinulle!
Seesteistä ja energisoivaa syksyä toivottaen,
Aaro
perjantai 28. toukokuuta 2010
Onko vaikeneminen kultaa?
Luin äskettäin nautinnolla maineikkaan projektinhallintakirjailijan Tom deMarcon uusimman tuotoksen Adrenaline Junkies and Template Zombies. Understanding Patterns of Project Behavior.
Kirja on todellista blogiaikakauden tavaraa, se koostuu 86:sta sivun tai kahden mittaisesta havainnosta projekteissa esiintyvistä ilmiöistä (ja kyllä, adrenaliininarkkari ja asiakirjapohjazombi kuuluvat näiden ilmiöiden joukkoon). Ehkä eniten minuun kuitenkin kolahti luku Silence gives consent, joka kertoo vaikenemisen erilaisista merkityksistä erilaisissa tilanteissa.
Kirjoitin yhdessä ensimmäisistä blogimerkinnöistäni siitä, miten projektin laajeneminen tuntuu usein johtuvan sidosryhmien ristiriitaisista odotuksista projektia kohtaan. deMarcon artikkelin mukaan ongelmia usein seuraa, kun osallistujilla on erilaisia näkemyksiä tai muistikuvia projektissa tehdyistä sitoumuksista.
Osa näistä sitoumuksista on kirjallisia tai ääneen lausuttuja; dokumentoituja päätöksiä, hyväksyttyjä suunnitelmia tai allekirjoitettuja resurssisopimuksia.
Monesti hiljaiset, ääneen lausumattomat sitoumukset ovat kuitenkin tärkeämmässä roolissa projekteissa. Sanotaanpa että projektiryhmän palaverissa keskustellaan tärkeästä ratkaisusta ja joku tekee ehdotuksen. Miten sitoutuminen ehdotukseen tällöin todennetaan? Riittääkö päännyökkäys? Entä onko vaikeneminen myöntymisen merkki?
On helppo yhtyä deMarcon ehdotukseen, jonka mukaan tärkeimpiä (ehkä lähes ainoita) projektissa dokumentoitavia asioita ovat eri osapuolten toisilleen antamat sitoumukset. Sitoudun tekemään tuon asian tähän päivämäärään mennessä.
Koko ajatus sitoumuksista projektitoiminnan ytimessä on sitä paitsi silmiä avaava! Projekti on ainutkertainen ihmisten toisilleen antamien sitoumusten verkko...
Kirja on todellista blogiaikakauden tavaraa, se koostuu 86:sta sivun tai kahden mittaisesta havainnosta projekteissa esiintyvistä ilmiöistä (ja kyllä, adrenaliininarkkari ja asiakirjapohjazombi kuuluvat näiden ilmiöiden joukkoon). Ehkä eniten minuun kuitenkin kolahti luku Silence gives consent, joka kertoo vaikenemisen erilaisista merkityksistä erilaisissa tilanteissa.
Kirjoitin yhdessä ensimmäisistä blogimerkinnöistäni siitä, miten projektin laajeneminen tuntuu usein johtuvan sidosryhmien ristiriitaisista odotuksista projektia kohtaan. deMarcon artikkelin mukaan ongelmia usein seuraa, kun osallistujilla on erilaisia näkemyksiä tai muistikuvia projektissa tehdyistä sitoumuksista.
Osa näistä sitoumuksista on kirjallisia tai ääneen lausuttuja; dokumentoituja päätöksiä, hyväksyttyjä suunnitelmia tai allekirjoitettuja resurssisopimuksia.
Monesti hiljaiset, ääneen lausumattomat sitoumukset ovat kuitenkin tärkeämmässä roolissa projekteissa. Sanotaanpa että projektiryhmän palaverissa keskustellaan tärkeästä ratkaisusta ja joku tekee ehdotuksen. Miten sitoutuminen ehdotukseen tällöin todennetaan? Riittääkö päännyökkäys? Entä onko vaikeneminen myöntymisen merkki?
On helppo yhtyä deMarcon ehdotukseen, jonka mukaan tärkeimpiä (ehkä lähes ainoita) projektissa dokumentoitavia asioita ovat eri osapuolten toisilleen antamat sitoumukset. Sitoudun tekemään tuon asian tähän päivämäärään mennessä.
Koko ajatus sitoumuksista projektitoiminnan ytimessä on sitä paitsi silmiä avaava! Projekti on ainutkertainen ihmisten toisilleen antamien sitoumusten verkko...
torstai 22. huhtikuuta 2010
Tulipalojen sammuttamista?
Tänä keväänä parikin projektipäällikköä on kertonut työnsä luonteen muuttuneen melkoisesti viimeksi kuluneen vuoden aikana.
Kun taantuman aikana kehittäminen jäi säästämisen ja tehostamisprojektien jalkoihin, on kehittämisen uudelleen liikkeelle polkaiseminen osoittautunut todella vaikeaksi.
Kaikki aika kuulemma kuluu tulipalojen sammuttamiseen pikemminkin kuin pitkäjänteiseen kehittämiseen.
Kaivoin uudestaan esille lähes vuosikymmenen takaisen HBR:ssä olleen loistavan artikkelin Stop Fighting Fires, jota olen suositellut monelle projektipäälliköllekin (http://hbr.org/2000/07/stop-fighting-fires/ar/1).
Teksti kuvailee mielenkiintoisella tavalla palokuntamentaliteetin riivaamissa yrityksissä esiintyviä ilmiöitä (aikapula, puolivillaiset ratkaisut ongelmiin, toistuvat ongelmat, kiireen kulttuuri, kriisiytyminen jne.).
Esimerkkinä käytetään 1990-luvun lopulla sattunutta onnettomuutta jossa NASAn Orbiter-marsluotain rysähti punaisen planeetan pinnalle yksinkertaisesta mittavirheestä johtuen. Yksi suunnittelutiimi nimittäin oli käyttänyt laskelmissaan metristä järjestelmää, toinen taas tuumia, jalkoja tai paunoja.
Artikkelin kirjoittajien lääkkeet tähän ongelmaan sitten ovat tuttuja mutta ah niin vaikeita toteuttaa; tunnista ilmiö, priorisoi asiat uudestaan, ole jämäkkä, tehosta kokouksia jne. Näinhän toki pitäisi toimia ja tähän useimmat meistä pyrkivätkin.
Tekstissä oli kuitenkin myös yksi itselleni erittäin tärkeä oivallus. Nimittäin se, että suurin osa tulipalosyndrooman riivaamista organisaatioista itse asiassa palkitsee (joko rahallisesti tai symbolisesti) tulipalojen sammuttamisesta.
Tästä taas on vain pieni looginen hyppy siihen, että ihmiset alkavat luoda pieniä tai suuria kriisejä - tietoisesti tai tiedostamattaan - itse.
Joten kun tätä kulttuuria lähdetään muuttamaan, vanha suomalainen sananlasku on korvaamattoman arvokas: älykäs selviää tilanteista, joihin viisas ei koskaan edes joudu.
Kun taantuman aikana kehittäminen jäi säästämisen ja tehostamisprojektien jalkoihin, on kehittämisen uudelleen liikkeelle polkaiseminen osoittautunut todella vaikeaksi.
Kaikki aika kuulemma kuluu tulipalojen sammuttamiseen pikemminkin kuin pitkäjänteiseen kehittämiseen.
Kaivoin uudestaan esille lähes vuosikymmenen takaisen HBR:ssä olleen loistavan artikkelin Stop Fighting Fires, jota olen suositellut monelle projektipäälliköllekin (http://hbr.org/2000/07/stop-fighting-fires/ar/1).
Teksti kuvailee mielenkiintoisella tavalla palokuntamentaliteetin riivaamissa yrityksissä esiintyviä ilmiöitä (aikapula, puolivillaiset ratkaisut ongelmiin, toistuvat ongelmat, kiireen kulttuuri, kriisiytyminen jne.).
Esimerkkinä käytetään 1990-luvun lopulla sattunutta onnettomuutta jossa NASAn Orbiter-marsluotain rysähti punaisen planeetan pinnalle yksinkertaisesta mittavirheestä johtuen. Yksi suunnittelutiimi nimittäin oli käyttänyt laskelmissaan metristä järjestelmää, toinen taas tuumia, jalkoja tai paunoja.
Artikkelin kirjoittajien lääkkeet tähän ongelmaan sitten ovat tuttuja mutta ah niin vaikeita toteuttaa; tunnista ilmiö, priorisoi asiat uudestaan, ole jämäkkä, tehosta kokouksia jne. Näinhän toki pitäisi toimia ja tähän useimmat meistä pyrkivätkin.
Tekstissä oli kuitenkin myös yksi itselleni erittäin tärkeä oivallus. Nimittäin se, että suurin osa tulipalosyndrooman riivaamista organisaatioista itse asiassa palkitsee (joko rahallisesti tai symbolisesti) tulipalojen sammuttamisesta.
Tästä taas on vain pieni looginen hyppy siihen, että ihmiset alkavat luoda pieniä tai suuria kriisejä - tietoisesti tai tiedostamattaan - itse.
Joten kun tätä kulttuuria lähdetään muuttamaan, vanha suomalainen sananlasku on korvaamattoman arvokas: älykäs selviää tilanteista, joihin viisas ei koskaan edes joudu.
sunnuntai 28. maaliskuuta 2010
Liikennevalokoodaus – mitä punainen tarkoittaa?
Viime aikoina vastaani on tullut useissa projekteissa erilaisia tapoja hyödyntää liikennevalokoodausta. Tiedättehän, statusraportissa esitetään yhteenveto projektin tehtävien edistymisestä, riskien tilasta tai avoimista asioista havainnollisin värikoodein.
Liikennevalokoodauksen näennäinen yksinkertaisuus kuitenkin kätkee taakseen monta mahdollista merkitystä väreille.
Vihreä väri tarkoittaa lähes aina jotakuinkin samaa - projekti etenee (suurin piirtein) raiteillaan. Ei ole vakavia poikkeamia suhteessa suunniteltuun, tai poikkeamat ovat sellaisia, että projektipäällikkö pystyy palauttamaan projektin raiteilleen.
Keltainen on varoitusväri, jolla kiinnitetään huomio mahdollisesti ongelmaksi / viivästykseksi muodostuvaan asiaan. Mielestäni keltaista väriä tulisi käyttää harkiten ja sillä merkityn tehtävän tai riskin tulisi ennen pitkää "muuttua" vihreäksi tai punaiseksi. Siis potentiaalinen ongelma ratkaistaan tai se toteutuu.
Punainen väri tietenkin tietää ongelmia. Mutta, tässä tullaankin liikennevalokoodauksen moniin erilaisiin tulkintoihin. Eri yhteyksissä olen nähnyt punaista käytettävän ainakin seuraavissa merkityksissä:
1) Projektissa on ongelmia, jotka vaarantavat tavoiteaikataulun saavuttamisen tai tavoitteiden saavuttamisen - ei kuitenkaan oteta kantaa siihen, mitä näille ongelmille tehdään
2) Projektissa on ongelmia, joiden hoitaminen vaatii välitöntä linjaesimiesten tai ylimmän johdon puuttumista
3) Projektin tavoiteaikatauluun ei tulla pääsemään. Suunnitelmia on päivitettävä ja asiasta sovittava asiakkaan tai projektin omistajan kanssa
4) Kaikkia suunniteltuja tuotoksia ei ole saatu aikaan, tai on muita tekijöitä jotka estävät projektin jatkamisen. Projekti keskeytetään kunnes sovitut asiat on tuotettu (tällaista määritelmää sovelletaan erityisesti vaiheveräjämallia noudattavissa kehitysprojekteissa, ei niinkään asiakastoimituksissa).
Ei siis ole välttämättä itsestään selvää, "mitä punainen tarkoittaa". Liikennevalokoodauksen tarkka merkitys onkin syytä käydä huolella läpi jokaisen projektin aluksi.
Liikennevalokoodauksen näennäinen yksinkertaisuus kuitenkin kätkee taakseen monta mahdollista merkitystä väreille.
Vihreä väri tarkoittaa lähes aina jotakuinkin samaa - projekti etenee (suurin piirtein) raiteillaan. Ei ole vakavia poikkeamia suhteessa suunniteltuun, tai poikkeamat ovat sellaisia, että projektipäällikkö pystyy palauttamaan projektin raiteilleen.
Keltainen on varoitusväri, jolla kiinnitetään huomio mahdollisesti ongelmaksi / viivästykseksi muodostuvaan asiaan. Mielestäni keltaista väriä tulisi käyttää harkiten ja sillä merkityn tehtävän tai riskin tulisi ennen pitkää "muuttua" vihreäksi tai punaiseksi. Siis potentiaalinen ongelma ratkaistaan tai se toteutuu.
Punainen väri tietenkin tietää ongelmia. Mutta, tässä tullaankin liikennevalokoodauksen moniin erilaisiin tulkintoihin. Eri yhteyksissä olen nähnyt punaista käytettävän ainakin seuraavissa merkityksissä:
1) Projektissa on ongelmia, jotka vaarantavat tavoiteaikataulun saavuttamisen tai tavoitteiden saavuttamisen - ei kuitenkaan oteta kantaa siihen, mitä näille ongelmille tehdään
2) Projektissa on ongelmia, joiden hoitaminen vaatii välitöntä linjaesimiesten tai ylimmän johdon puuttumista
3) Projektin tavoiteaikatauluun ei tulla pääsemään. Suunnitelmia on päivitettävä ja asiasta sovittava asiakkaan tai projektin omistajan kanssa
4) Kaikkia suunniteltuja tuotoksia ei ole saatu aikaan, tai on muita tekijöitä jotka estävät projektin jatkamisen. Projekti keskeytetään kunnes sovitut asiat on tuotettu (tällaista määritelmää sovelletaan erityisesti vaiheveräjämallia noudattavissa kehitysprojekteissa, ei niinkään asiakastoimituksissa).
Ei siis ole välttämättä itsestään selvää, "mitä punainen tarkoittaa". Liikennevalokoodauksen tarkka merkitys onkin syytä käydä huolella läpi jokaisen projektin aluksi.
Tilaa:
Blogitekstit (Atom)
