Kuinka vältät projektin epäonnistumisen kolmessa vaiheessa + 4 tapaustutkimusta
Projektit epäonnistuvat monista syistä, mutta lähes kaikki voidaan pohjimmiltaan jakaa kahteen asiaan (joskus molempiin):
- Oli olemassa riski, jota kukaan ei tunnistanut, ja/tai
- Emme reagoineet hyvin ongelman ilmetessä
Tässä artikkelissa haluan tarkastella kokonaiskuvaa, jotta voimme puuttua projektien – ja usein projektinhallinnan – epäonnistumisten pääasialliseen syyhyn.
Näin voit välttää projektin epäonnistumisen ja toimia, jos ennalta arvaamaton katastrofaalinen ongelma toteutuu (voit silti onnistua, jos toimit nopeasti ja harkiten!).
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Mitä projektin epäonnistuminen tarkoittaa?
Aivan sitä, miltä se kuulostaa – projekti ei saavuta alussa asetettuja tavoitteita, ei täytä asiakkaan tai keskeisten sidosryhmien odotuksia tai ei pysy aikataulussa, budjetissa tai sovitussa laajuudessa.
Miksi projektit epäonnistuvat?
Kuten johdannossa vihjasin, on olemassa useita yleisiä syitä projektien epäonnistumiselle. Yleensä syynä on riski, jota ei arvioitu asianmukaisesti, ja/tai se, ettei tiimi (projektipäällikkö mukaan lukien) reagoinut riskiin asianmukaisesti.
Muita yleisiä projektien epäonnistumisen syitä voivat olla puutteellinen viestintä tilanteesta, ongelmista tai riskeistä; se, etteivät tiimin jäsenet noudata projektin laajuutta tai ymmärrä sitä asianmukaisesti, eivät pysy projektin tuotosten (eli projektin laajuuden hallitsemattoman kasvun) tai aikataulun rajoissa; resurssien puute tai se, ettei määritettyjä prosesseja tai menetelmiä noudateta.
Näin vältät projektin epäonnistumisen: 3 vaihetta
Riskienhallinta on keskeinen projektinhallinnan tehtävä. Se on niin tärkeää, että riskienhallinnan laiminlyönti johtaa usein projektinhallinnan epäonnistumiseen. Riskienhallinnassa on kolme tärkeää osa-aluetta:
- Tunnista riskit.
- Arvioi tunnistamasi riskit: Kuinka todennäköisesti ne toteutuvat ja kuinka pahaksi tilanne muuttuu, jos ne toteutuvat? Mitkä ovat todennäköisyys ja vaikutus?
- Laadi lieventämis- ja varautumissuunnitelmat riskeille, jotka voisivat suistaa muuten onnistuneen projektisi raiteiltaan. Riskirekisterit ovat käteviä toteutettujen toimien seuraamiseen.
1. Tunnista riskit
Tunnista ensin riskit. Kun teet tämän hyvin, projektin onnistumisen mahdollisuutesi paranevat huomattavasti. Vaikka kaikkia riskejä on vaikea havaita, voit yleensä selvittää suurimmat riskit tarkastelemalla projektia järjestelmällisesti. Tämä on yleensä osa projektisuunnitelman laatimisprosessia.
Taustani on ohjelmistokehityksessä, sekä tuotteiden että IT:n parissa, ja niihin liittyvissä prosesseissa. Ohjelmistoprojektit ovat monimutkaisia ja herkkiä, eikä niihin muutamia harvinaisia poikkeuksia lukuun ottamatta ole rakennettu samanlaisia vikasietoisuuksia ja tarkastuksia kuin esimerkiksi rakentamiseen tai lääkinnällisten laitteiden tuotantoon.
Sinulla tulisi olla projektitavoitteet jokaiselle neljälle säätimelle:
- Aikataulu
- Sisältö
- Kustannukset
- Laatu
Jos et tiedä, mitä ne ovat, aloita siitä. Yleensä kaksi neljästä muuttuu hieman, mutta mitä paremmin ymmärrät, mihin olet menossa, sitä helpompi esteet on tunnistaa.
Sen ymmärtäminen, mikä neljästä säätimestä on tärkein, auttaa vähentämään riskejä tekemällä asianmukaisia kompromisseja pienissä asioissa.
On helppo keskittyä projektin aikataulusäätimeen ja jättää huomiotta riskit, jotka saattavat vaikuttaa muihin säätimiin, mutta kaikki liittyvät toisiinsa ja kaikki on tärkeää tunnistaa.
Aikataulutavoitteiden saavuttaminen virheellisen tuotteen avulla ei yleensä ole hyvä vaihtoehto – vaikka julkaisisit tuotteen, joudut lopulta tekemään korjausjulkaisuja, jotka viivästyttävät riittävän hyvän tuotteen valmistumista enemmän kuin ongelman ratkaiseminen alun perin olisi tehnyt.
Neljän säätimen lisäksi
Neljän säätimen lisäksi sinun on tasapainotettava projektisi kolmea osa-aluetta:
- Tuote, joka yleensä katetaan säätimillä
- Prosessi
- Ihmiset
Prosessiriskejä on kahdenlaisia: olemassa oleva prosessi on riittämätön eikä vastaa projektisi tarpeita, tai kriittiseen tiimisi tekemään työhön ei ole prosessia. Prosessiriskejä on melko helppo lieventää luomalla tai korjaamalla prosessi.
Ihmiset unohdetaan usein, mutta tiimisi ja ne tiimit, joiden kanssa se toimii, ratkaisevat projektisi onnistumisen tai epäonnistumisen. Hankalat tai välinpitämättömät projektin sidosryhmät vaikeuttavat etenemiseen tarvittavien asioiden saamista.
Ylikuormittuneet, stressaantuneet tai tyytymättömät tiimin jäsenet eivät saa työtä tehtyä. Joistakin mahdollisista henkilöstöön liittyvistä ongelmista voit puhua julkisesti, kun taas toisia saatat haluta käsitellä yksityisesti, mutta älä tee sitä virhettä, että jätät ne huomiotta.
2. Arvioi tunnistamasi riskit
Kun olet tunnistanut riskit, määritä, kuinka todennäköisesti riski toteutuu. Käytän yleensä prosenttiosuutta: 100 % tarkoittaa, että olen varma sen toteutumisesta. On myös tärkeää määrittää, kuinka vakavat seuraukset ovat, jos riski toteutuu. Helpoin tapa tehdä tämä on luokitella riskit suuriksi, keskisuuriksi tai pieniksi.
Kun olet tehnyt tämän analyysin, on aika ottaa tiimisi mukaan. Kysy jokaiselta projektitiimin jäseneltä tai osallistujalta, mikä heitä huolestuttaa, lisää nämä asiat riskiluetteloon ja ottakaa ne tarkasteltaviksi:
- Keksivätkö tiimin jäsenet muita riskejä, joita et ole käsitellyt?
- Mitä mieltä he ovat todennäköisyys- ja vaikutusanalyysistä?
Tämän kokouksen perusteella voit tehdä muutoksia riskisuunnitelmaasi. Ensimmäinen ja toinen vaihe on nyt tehty – ainakin toistaiseksi. Sinun on tarkasteltava riskejä vähintään viikoittain selvittääksesi, onko ilmennyt uusia riskejä, onko jokin riski menettänyt merkityksensä tai onko jokin todennäköisyys tai vaikutus muuttunut.
3. Valmistele lieventämis- ja varautumissuunnitelmat
Jos jonkin riskin todennäköisyyden ja vaikutuksen yhdistelmä voi vaarantaa projektisi onnistumisen, laadi lopuksi yhdessä tiimisi kanssa dokumentoidut suunnitelmat riskin lieventämiseksi ja siihen varautumiseksi.
Lieventämisellä pyritään joko pienentämään riskin toteutumisen todennäköisyyttä tai vähentämään sen vaikutusta, jos se toteutuu. Varautumisessa keskitytään toimiin, joihin ryhdyt, jos riskiä ei voida välttää ja se toteutuu.
Varmista, että suunnitelmat dokumentoidaan ja että kaikki tietävät niistä. On myös hyvä varautua mahdollisiin henkilöstöön liittyviin ongelmiin neljän osa-alueen ja prosessin lisäksi, mutta tämän analyysin haluat todennäköisesti tehdä itse ja pitää luottamuksellisena.
Näin selviät projektin epäonnistumisesta
Toinen syy projektinhallinnan epäonnistumiseen on se, että projektiriskin toteutumiseen reagoidaan huonosti riippumatta siitä, ennakoitiinko riski vai ei. Tämä riippuu pitkälti sinusta projektipäällikkönä. Ennen kuin ryhdyt mihinkään alla olevista toimista, aloita näistä kahdesta vinkistä:
- Älä panikoi. Muista hengittää.
- Älä syyttele ketään äläkä anna kenenkään muunkaan alkaa etsiä syyllisiä.
1. Palaa varautumissuunnitelmaasi
Jos sinulla on varautumissuunnitelma, kutsu kokous koolle välittömästi tai lähetä ainakin varautumissuunnitelman käynnistävä sähköposti. Muistuta ihmisiä siitä, mikä suunnitelma on, ja kerro kaikille, milloin ja miten tilanne ilmoitetaan.
Jos ohitat tämän vaiheen tai viivytät sitä, huomaat, että auttamaan halukkaat ihmiset ovat ryhtyneet toimiin paniikissa. Kun näin käy, menetät käsityksen siitä, mitä on tehty, ja usein se pahentaa ongelmaa.
Jos sinulla ei ole varautumissuunnitelmaa, kutsu joukot välittömästi koolle kokouskutsulla ja tiukoilla ohjeilla, joiden mukaan MITÄÄN MUUTA EI SAA TEHDÄ ennen kokousta.
Muuten kaikki yrittävät auttaa, etkä tiedä, mitä on tehty. Kerro kokouksessa ongelma selkeästi – on aina hämmästyttävää, kuinka monia erilaisia käsityksiä ihmisillä voi olla ongelman laadusta.
Tehkää yhdessä perimmäisen syyn analyysi ongelman ytimen selvittämiseksi ja laatikaa suunnitelma tilanteen korjaamiseksi: kuka tekee mitä ja miten. Perimmäisen syyn analyysissä sinun on ymmärrettävä, kuka teki mitä ennen ongelman ilmenemistä, mutta pidä keskustelu tällä tasolla.
Toisin sanoen pitäytykää tosiasioissa. Älä syytä ketään, sillä syyllisten etsiminen vie huomion olennaisesta. Jos tiimisi ei pysty löytämään ratkaisua, sinulla on muutamia vaihtoehtoja.
Ensimmäinen vaihtoehto on pyytää mukaan joku, joka tuntee yleisen aihepiirin mutta ei työskentele tässä nimenomaisessa projektissa. Jos ongelma näyttää esimerkiksi liittyvän tietokantaan, pyydä projektiin kuulumaton tietokannan ylläpitäjä mukaan saadaksesi toisen näkökulman.
Toinen menetelmä on pyytää mukaan joku, jolla ei ole projektista lainkaan käytännön tietämystä. Joskus jokaisen vaiheen yksityiskohtainen selittäminen paljastaa virheellisiä oletuksia tai asioita, joita ihmiset eivät ole huomanneet.
2. Korjaa ongelma
Varmista, että kaikki sitoutuvat toimintatapaasi, ja jaa tehtävät. Pyydä ihmisiä raportoimaan edistymisestä sinulle ja kerro, kuinka usein heidän tulee lähettää tilanneraportteja: tunneittain, tehtävän valmistuttua, päivän päätteeksi tai miten tilanteeseen parhaiten sopii.
Raportointi saattaa tuntua sinusta itsestään selvältä, mutta sitä se ei ole kaikille. Säännölliset päivitykset auttavat pitämään tiimin tilanteen tasalla. Raportoi koottu edistyminen koko tiimille säännöllisesti.
Tiimin jäsenet, joilla ei ole välittömiä tehtäviä, alkavat käydä levottomiksi ja yrittävät lopulta ryhtyä auttamaan, ellet toimita heille tilannepäivityksiä ja muita tietoja.
On myös erittäin tärkeää pitää johto ajan tasalla. Käytä harkintaasi määrittäessäsi, kuka tarvitsee päivityksiä ja missä vaiheessa, mutta raportoi koottu edistyminen koko tiimille säännöllisesti.
3. Julista asia loppuun käsitellyksi
Kun se todella on valmis. Laadi loppuraportti ja siirry seuraavaan vaiheeseen. Anna tiimille hieman aikaa toipua.
4. Tee projektin jälkiarviointi tai retrospektiivi
On tärkeää tehdä projektin arviointi, jotta opituista asioista saadaan koottua yhteenveto. Näin voit jäsentää sen:
- Kuvaa ongelma, jotta kaikki ovat samalla sivulla
- Aloita siitä, mikä sujui hyvin. Vaikeimmassakin tilanteessa jokin asia onnistui. Tämä antaa kokoukselle aivan toisenlaisen sävyn.
- Keskustelkaa siitä, mitä pitäisi parantaa. Jos aikaa on, ideoikaa tapoja toteuttaa parannukset; muussa tapauksessa jakakaa tehtävät ja määräajat ja seuratkaa niiden toteutumista.
Jos kyse oli todella jonkun syytä, käsittele asia hänen kanssaan kahden kesken. Jos teet sen julkisesti, koko tiimisi alkaa miettiä, kuka joutuu seuraavaksi nolattavaksi julkisesti.
Jos jätät tämän kokonaan väliin, tiimistäsi tuntuu, että joku pääsi pälkähästä eikä ongelmaa korjattu. Pysy tosiasioissa ja seuraa kaikkia henkilökohtaisia prosessimuutoksia, joita jonkun täytyy tehdä. Kyse on vastuullisuudesta ja parantamisesta, ei syyllisen etsimisestä.
3 esimerkkiä todellisista projektien epäonnistumisista
Minulla on ollut oma osuuteni IT-projektien epäonnistumisista, vaikka ne onneksi – mutta tuskallisesti – saatiin palautettua raiteilleen.
Tässä on pari omaa epäonnistunutta IT- ja kehitysprojektiani sekä yksi esimerkki kuuluisasta epäonnistuneesta projektista.
Näiden projektien epäonnistumisesimerkkien ja epäonnistuneiden projektien tapaustutkimusten pitäisi myös antaa sinulle konkreettinen käsitys siitä, millä tavoin projektit voivat epäonnistua ja miten tilanteeseen voidaan puuttua.
1. Kirjanpitojärjestelmä
Uran alkuvaiheessa työskentelin IBM:llä. Ensimmäinen varsinainen työtehtäväni oli ottaa vastuulleni melko pieni järjestelmä, joka syötti tietoja yrityksen kirjanpitojärjestelmiin. Joku IBM:n työntekijä oli kirjoittanut sen pienelle järjestelmälle harvinaisella RPG-ohjelmointikielellä.
En ainoastaan hallinnoinut projektia – hallinnoin koko järjestelmää (vaikka sillä oli ylläpitäjä), mukaan lukien projektin vaatimusten keräämisen, vianmäärityksen ja ohjelmoinnin.
Eräänä kauniina päivänä asensin uuden ohjelman, suoritin sen ja löysin virheen. Korjasin virheen ja suoritin ohjelman uudelleen. Seuraavana aamuna sain kirjanpito-osastolta puhelun, jossa kerrottiin, että järjestelmään oli tullut kaksoiskirjauksia (kirjanpidon maailmassa tämä on erittäin huono uutinen).
Ensinnäkään kukaan ei tarkistanut työtäni. Toiseksi en pyytänyt seuraavien järjestelmien käyttäjiä tarkistamaan kirjauksia ennen kuin ne siirtyivät eteenpäin. Kolmanneksi en käyttänyt aikaa joidenkin yhä käynnissä olevien vanhojen ohjelmien analysointiin, vaikka ne loivat kaksoiskirjauksia. Lisäksi mitään prosessia ei ollut olemassa, lukuun ottamatta sitä, mitä keksin lennossa.
Ja sitten reagoin paniikilla. Hyvä luoja, olin juuri valmistunut korkeakoulusta ja olin tuhoamassa IBM:n kirjanpitojärjestelmää. En ottanut oikeita ihmisiä mukaan – ylläpitäjä ei tiennyt, mitä oli tapahtumassa – ja hän loi tietämättään vielä yhden kirjauserän. Lopulta työskentelin 48 tuntia yhtäjaksoisesti selvittääkseni perimmäisen syyn, korjatakseni sen sekä kirjoittakseni ja suorittaakseni ohjelmat kirjanpitovirheiden korjaamiseksi.
Opin läksyni – tarkista asiat huolellisesti, pyydä arvioita, mieti, mikä voisi mennä pieleen, ja pysähdy ajattelemaan ennen kuin ryhdyt suin päin korjaamaan asioita (kaikessa tässä kirjanpidon projektinhallintaohjelmisto voi auttaa). Kuvittele nyt, että johtaisin kymmenen hengen tiimiä ja kaikki yrittäisivät korjata ongelmaa samalla tavalla. Tilannetta ei todellakaan olisi voitu pelastaa ilman, että IBM:n kirjanpitojärjestelmät olisi pitänyt ajaa alas ongelman selvittämiseksi.
2. Uusi sisäinen tuote
Konsulttina johdin uutta, suurta projektia, jossa monet osapuolet vaikuttivat vaatimuksiin ja aiheuttivat jatkuvia muutoksia toiminnallisiin prioriteetteihin. Käytimme ketterää projektinhallintaprosessia, jota tämä yritys ei ollut aiemmin käyttänyt. Laadunvarmistus oli erittäin hyvä testauksessa, mutta se ei vielä ymmärtänyt loppukäyttäjän ajattelutapaa ja työnkulkua.
Tiesin kaiken tämän ja toin asiat ajoittain esiin, mutta minulla ei ollut riskirekisteriä, vaikutusten ja todennäköisyyksien arviointia, varautumis- tai lieventämissuunnitelmia. En myöskään ollut projektin toimeksiantajan ensisijainen tiedonvälittäjä, vaikka tapasin häntä toisinaan.
Lisäsimme yhden sprintin. Sitten vielä toisen. Kun kävi ilmi, ettemme olleet aivan siinä pisteessä, jossa meidän olisi pitänyt olla beetatestin suorittamista varten, lisäsimme kolmannen sprintin.
Koska en itse toimittanut tietoja projektin toimeksiantajalle, en tiennyt, ettei hän ollut tietoinen kaikesta tästä. Vastuuhenkilö teki vakavan virheen jättäessään kertomatta asiasta toimeksiantajalle siinä toivossa, että saisimme projektin vietyä läpi.
Ollakseni reilu, vaikka puhuin riskeistä, en antanut hänelle konkreettista riskikokonaisuutta esiteltäväksi, jotta toimeksiantaja olisi voitu valmistella aikataulun viivästymisen mahdollisuuteen.
Kaiken tämän keskellä tapasin toimeksiantajan ja mainitsin ohimennen, että lisäisimme vielä viimeisen sprintin. Hän keskeytti minut. Hän ei tiennyt asiasta mitään eikä ollut tyytyväinen.
Lopulta hän oli järkyttyneempi yllätyksestä kuin aikataulun viivästymisestä. Asiasta seurasi julkisia vaikutuksia, ja lopulta projektin vastuuhenkilö siirtyi muualle yrityksessä, koska luottamus oli menetetty.
Jälleen kerran opin epäonnistumisesta tärkeitä asioita. Riskien tunteminen ei riitä, vaan ne on koottava yhteen, arvioitava, niille on laadittava lieventämis- ja varasuunnitelmat sekä tuotava ne julkisesti ja jatkuvasti näkyville.
En ole koskaan ollut riskien ja ongelmien piilottelun kannalla, mutta projektin läpinäkyvyyden merkitys tuli täysin kiistattomaksi.
3. Muistatko OS2:n?
Et, ei kukaan muukaan. Se on yksi monista epäonnistuneista järjestelmäkehitysprojekteista. Työskentelin IBM:llä, kun alkuperäinen OS2 julkaistiin – se oli Windowsin kilpailija. En edes kokeillut ensimmäistä versiota, koska me kaikki IBM:llä tiesimme sen olevan todella virheellinen. Muu maailma sai heti huomata, että siinä oli aivan liikaa ongelmia, jotta sen kanssa olisi kannattanut vaivautua.
Se oli niin virheellinen, ettei projektiryhmä mitenkään voinut kuvitella sen olevan täysin valmis, mutta jostain syystä he eivät tehneet oikeaa kompromissia eivätkä lykänneet julkaisua. Jos inhimillinen tekijä jätetään huomiotta, sekä tiimisi että asiakkaasi pilaavat hienon suunnitelman nopeasti.
Ohjelmistojen parissa tähän tilanteeseen on monia vaihtoehtoja – voit tehdä rajoitetun julkaisun ihmisille, jotka sietävät virheitä saadakseen käyttöönsä uuden ja edistyksellisen ohjelmiston, kertoa julkisesti odottavasi, että luotettavuus saadaan omien korkeiden standardiesi mukaiseksi ja niin edelleen.
Uraani oli tuolloin vielä niin alkuvaiheessa, että pystyin ottamaan arvokkaita oppeja siitä, että rakastamani tuote oli toisessa julkaisussaan ajautunut umpikujaan.
Ole selkeä prioriteeteistasi – on muutamia tapauksia, joissa julkaiseminen tiettynä päivänä on tuotteen laatua tärkeämpää, mutta niitä ei ole montaa.
Käytä neljää säätönuppiasi, myönnä virheesi ja tee korjaukset näkyviksi, jotta ihmiset luottavat siihen, että ymmärrät ongelman etkä tee samaa virhettä kahdesti.
Ota inhimillinen tekijä huomioon – se on yhtä kriittinen kuin teknologia. Toimme nämä opit ohjelmisto- ja IT-projekteihin tuosta hetkestä lähtien, ja niistä on ollut korvaamatonta hyötyä.
Lopputulos
Muista kaiken kaikkiaan, että vaikka vastuu on viime kädessä sinulla, sinun ei tarvitse tehdä kaikkea työtä. Itse asiassa sinun ei missään nimessä pidä yrittää tehdä sitä yksin. Voit hyötyä tiimisi laajasta kokemuksesta ja tietämyksestä. Olet johtaja, mutta sinun ei tarvitse olla koko tiimi.
Projektinhallintaohjelmisto ja muut projektinhallintatyökalut voivat auttaa sinua seuraamaan riskejä, virstanpylväitä, resurssien kohdentamista ja muita kriittisiä mittareita, jotka kertovat, oletko matkalla kohti onnistunutta projektia.
