Viisi tärkeintä kipukohtaa, joita projektisalkun hallinnoijat kohtaavat vuonna 2026

Miten päätät, mikä projekti on tärkeämpi ja kuinka paljon resursseja siihen tulisi kohdentaa? Pisteytys on monimutkainen kysymys, johon sidosryhmät ja asiakkaat vaikuttavat ja jossa on otettava huomioon monia muuttujia. 

”Pisteytys on ratkaisevan tärkeää paitsi päätöksenteon läpinäkyvyyden ja ylimmän johdon tuen kannalta,” sanoo Doron Eliezer, PMP-sertifioitu monday.comin asiakasmenestyksestä vastaava aluejohtaja, ”myös siksi, että sen avulla ruohonjuuritason ponnistelut voidaan yhdistää yrityksen laajempiin tavoitteisiin. Oikein toteutettuna se on erinomainen tapa selkeyttää toimintamme taustalla olevia perusteita.”

Portfoliopäälliköt käyttävät lukuisia pisteytysmenetelmiä, mutta useimpien mielestä heidän käyttämänsä menetelmät eivät vastaa heidän tarpeitaan. Jotkut portfoliopäälliköt luovat erityisiä ja henkilökohtaisia matriiseja ja laskelmia, kun taas toiset keskittyvät aikatauluihin, budjetteihin ja määräpäiviin. 

Tärkeintä tässä on kuitenkin ymmärtää, kuinka olennaista sopiva pisteytysmenetelmä on. Tätä ei voi korostaa liikaa – se on portfolion perusta, ja huolimattomasti toteutettuna se voi vaikuttaa tehokkuuteen merkittävästi. Tarkka ja harkittu pisteytysmenetelmä auttaa priorisoimaan projektit ja päättämään, mihin kannattaa keskittyä olosuhteiden muuttuessa, kuten niillä on tapana.

Jos portfoliopäällikkö pystyy luomaan selkeän ja läpinäkyvän pisteytysjärjestelmän, jonka kaikki ymmärtävät, hänen päätöksensä hyväksytään helpommin ja nopeammin. Hän voi myös saavuttaa laajan yhteisymmärryksen ja yhteistyön ylemmän johdon sekä alemman johdon, sidosryhmien ja työntekijöiden kanssa.

Projektin "käynnissä olevan vaiheen" aikana prioriteetit muuttuvat jatkuvasti, ja salkunhallinnasta vastaavat joutuvat jatkuvasti kamppailemaan tämän kanssa. Kun uusi projekti alkaa tai asiakas pyytää muutosta, koko tilanne on arvioitava uudelleen ja ymmärrettävä, mitä voidaan siirtää tärkeysjärjestyksessä alemmas tai järjestellä uudelleen. Salkku- ja ohjelmapäälliköiden on selvitettävä nopeasti, miten kukin muutos vaikuttaa aikatauluihin ja budjetteihin. 

Tällä hetkellä tämä on useimmille salkkupäälliköille raskas tehtävä. On myös muistettava, ettei riitä, että selvität asian itse – priorisoinnin haasteisiin kuuluu näiden muutosten ja niiden mahdollisten seurausten välittäminen sidosryhmille ja asiakkaille. Jokaisella päätöksellä on hintansa, ja se on tehtävä kaikille selväksi. 

Vacon ohjelmapäällikkö Tom Evansen on samaa mieltä: “Suurin kipukohtamme on priorisointi. Emme pysty määrittämään taloudellista rajaa, resurssirajaa emmekä ehkä edes hyötyrajaa. Tarvitsen jotain, joka kertoo minulle: hyvä on, priorisoit nämä kolme asiaa, ja nyt sinulla on jäljellä tämän verran rahaa. Kun koko priorisointiprosessissa asiat pakotetaan esimerkiksi arvojärjestykseen yhdestä kymmeneen, se on hienoa. Mutta voi olla, että pystyt tekemään … 1, 2, 3, minkä jälkeen rahaa on jäljellä vain seitsemänteen kohtaan. Silloin on järkevää siirtyä alaspäin ja ottaa seitsemäs mukaan, vaikka se tarkoittaa, että neljättä, viidettä ja kuudetta ei toteuteta…” 

Auran ohjelmanhallintatoimiston vanhempi johtaja Sarah M. Hoban sanoo, että osa tästä kamppailusta on ratkaistava organisaatiotasolla. “Monet organisaatiot sanovat haluavansa kehittyä priorisoinnissa, mutta käytännössä en usein näe sitä,” hän sanoo. “Väärän päätöksen tekemistä pelätään, ja joskus se johtaa siihen, ettei päätöstä tehdä lainkaan.”

Priorisoinnin aiheuttaman kuormituksen vähentämiseksi “ohjelmapäälliköiden on esitettävä vaikeat kysymykset, jotta päätöksenteolle voidaan luoda ympäristö tai kulttuuri: mitä haluamme tehdä tässä tilanteessa? Mitkä ovat seuraavat askeleemme? Mikä on etenemissuuntamme? Miten tämä sopii laajempaan strategiaan?” Hoban sanoo. 

“Toinen osa on yhteistyö organisaation johdon kanssa sellaisen kulttuurin luomiseksi, jossa ihmiset voivat tehdä virheitä ja asettaa kunnianhimoisia tavoitteita,” hän jatkaa. “Toimimme liiketoimintaympäristössä, jossa prioriteetit saattavat muuttua paljon, ja se on hyväksyttävää, mutta johdon on viestittävä siitä… ja silloin on myös poistettava jotain tehtävälistalta sen sijaan, että vain lisätään asioita ja jätetään niitä taka-alalle. Juuri taustalla tapahtuva asiayhteydestä toiseen vaihtaminen tappaa tuottavuuden.”

Priorisoinnissa on otettava huomioon myös organisaation laajemmat tavoitteet. Hobanin mukaan monilla organisaatioilla “on tavoitteenasettamisprosessi, mutta se on vain muodollisuus. Ne asettavat tavoitteensa vuosineljänneksen alussa, mutta jotkut eivät tarkastele tavoitteita enää ennen seuraavaa vuosineljännestä.” 

Tähän liittyen organisaatioilla saattaa olla “joukko tavoitteita, mutta se muuttuu käytännössä luetteloksi kaikesta tekemästänne, koska ette todellisuudessa priorisoi,” Hoban sanoo.

Tarvitaan myös toimintojen välistä yhteistyötä. 

“Kukin osasto voi asettaa tavoitteensa, joiden pitäisi liittyä johonkin yrityksen tavoitteeseen, ja ehkä näin tapahtuukin,” Hoban sanoo. “Mutta ehkä kahdella osastolla on sama osa ongelmasta ratkaistavanaan. Mielestäni tavoitteiden asettaminen on keino pakottaa ne työskentelemään yhdessä ongelman ratkaisemiseksi ja ymmärtämään, että kyseessä on yhteinen ongelma, mutta kestää jonkin aikaa, ennen kuin ihmiset oppivat tämän. Tavoitteiden asettaminen edistää siis yhteistyötä, mutta tulosten saavuttaminen kestää pari vuosineljännestä.”

Seuranta on merkittävää, koska ohjelmapäälliköt ja salkunhallinnoijat etsivät aina yksinkertaista tapaa ymmärtää oikea hetki puuttua projektiin ja tehdä tarvittavat toimet. He eivät voi perehtyä yksityiskohtiin – se kuuluu projektipäällikön tehtäviin. 

Heidän on selvitettävä, missä heitä tarvitaan eniten, mutta salkunhallinnoijan huomiosta käydään jatkuvaa kilpailua, ja jokainen tiimi sekä projektipäällikkö ajattelee olevansa tärkein. 

Jotkut salkun- ja ohjelmapäälliköt saavat sadoista projekteistaan satoja päivittäisiä ilmoituksia, ja kiireellisiä tai vähemmän tärkeitä ilmoituksia on vaikea suodattaa pois. He tuhlaavat arvokasta aikaa loputtomiin yhteensovittamispalavereihin yrittäessään selvittää, mikä on tärkeää, ja uupuvat, koska vaihtavat jatkuvasti kontekstia alustojen ja projektien välillä. 

IBM:n johtava testauskonsultti Usha Bhovan selittää tätä haastetta Microsoft Projectin (MSP) yhteydessä. “MSP osaa … todella hyvin näyttää tehtävien tai toimenpiteiden väliset yhteydet, riippuvuudet ja niin edelleen,” hän sanoo. “Siitä voi kuitenkin tulla melkoinen hirviö, jos ei ole varovainen. Se on todella hyvä, koska sen avulla voi seurata asioita. Mutta tunnen hyvin harvoja ohjelmapäälliköitä, jotka todella seuraavat asioita [MSP:ssä]. He pyytävät lähes aina testausvastaavia, ohjelmavastaavia, projektivastaavia tai projektipäälliköitä luomaan laskentataulukoita, jotka antavat heille yhteenvedon siitä, mitä tehtäviä suoritetaan[,] milloin ne täytetään[,] milloin ne toimitetaan, sekä tunnistamaan kyseisellä tasolla mahdolliset riskit, ongelmat ja niin edelleen.”

Sarah M. Hoban kertoo, mitä organisaatiossa voitaisiin standardoida tämän helpottamiseksi. “Salkunhallinnoijan tehtävänä on koota kaikki olennainen tieto eri tiimeistä. Ihmisillä on taipumus toimia omassa pienessä maailmassaan. Monet yrityksen kannustinrakenteet vahvistavat tahattomasti ajatusta siitä, että kyse on sinusta ja suoriutumisestasi sen sijaan, että yhteistyötä palkittaisiin,” hän sanoo. “Ohjelmapäällikkö voi yhdistää eri ryhmien väliset asiat, mutta myös selvittää, miten ne dokumentoidaan.” 

Hoban näkee myös kasvavat teknologiapinot yhä suurempana haasteena. “Toinen haaste on myös teknologian lisääntyminen,” hän sanoo. “Miten tämän voisi ratkaista? On hienoa, että tehtävään on nimetty henkilö, ja myös jonkinlainen yritystason ohjelmistojärjestelmä on hyvä asia. Haasteeksi muodostuu kuitenkin se, mitä työkalua käytetään. Jokaisella on oma työkalunsa tai suosimansa työskentelytapa. Siksi ohjelmanhallinta voisi jälleen astua kuvaan ja todeta, että on hyväksyttävää käyttää kaikkia näitä eri työkaluja, mutta näin niitä pitäisi käyttää, näin kutakin niistä pitäisi käyttää ja tätä kukin niistä tarkoittaa.”

Lue lisää siitä, miten ohjelmanhallinta eroaa projektinhallinnasta.

Riskien tunnistaminen edellyttää selkeyttä ja täsmällisyyttä, sillä se vaikuttaa merkittävästi tuleviin toimiin ja lopputuloksiin. Ongelma on siinä, että jokaisesta projektista on riittävästi dataa hukuttamaan portfoliojohtajat alleen, mutta heiltä puuttuvat työkalut, joilla he voisivat tarkentaa tarkastelun tiettyyn projektin osaan ja auttaa riskien lieventämisessä. 

Kun heidän on suodatettava häly pois ja tarkasteltava tilannetta uudesta näkökulmasta, useimmat heistä siirtyvät yksinkertaisempiin työkaluihin tai jopa manuaalisiin työkaluihin, jotta he voivat keskittyä vain käsillä olevan riskin kannalta olennaiseen. Nämä toimet vievät paljon aikaa ja energiaa, ja ne voivat myös rajoittaa toimintaa.  

Riskirekisterit ovat yksi esimerkki manuaalisesta työkalusta. 

“Riskirekisterin käyttäminen on hyvä käytäntö suunnittelussa ja ennakoinnissa, mutta sillä on muutama rajoite”, Hoban sanoo. “Yksi niistä on se, että ajattelet vain tunnettuja tuntemattomia … tulee olemaan jotain, mitä et ajattele ja joka menee pieleen. Toinen asia, jonka näen tapahtuvan, on se, että teet rekisterin projektin alussa etkä sitten tavallaan koskaan katso sitä uudelleen. Asiakirjaa on … tarkasteltava säännöllisesti … Tässä mielessä se lisää vastuullisuutta.”

Hoban jatkaa: “Toinen riskeihin liittyvä asia, jossa organisaatiot ovat mielestäni yleisesti ottaen todella huonoja, on opittujen kokemusten seuraaminen ja sen selvittäminen, miten niiden avulla voidaan suunnitella seuraavien projektien riskienhallintaa. Joskus kyse on jopa järjestelmätason ongelmista, jotka liittyvät organisaation sisäisiin työskentelytapoihin tai jopa työskentelyyn kyseisen asiakkaan kanssa … Mutta mallia ei ole. Tarkoitan, että on olemassa malli, jonka voi täyttää tietyssä määrin, mutta aina tulee olemaan asioita, jotka jäävät sen ulkopuolelle.” 

Kuten Eliezer sanoo, “... tarve jakaa kokemuksia ja oppia muiden kokemuksista on elintärkeä. Ohjelmajohtajat voivat tehostaa oppimistaan ja omaksua tehokkaita riskien lieventämisstrategioita projektista toiseen, mikä varmistaa paremman onnistumisen. Projektin lopussa järjestettävää laajaa opittujen kokemusten istuntoa ei tarvitse odottaa. Nykyään jokainen projektin tilannekatsaus toimii alustana kokemusten vaihtamiselle ja haasteista keskustelemiselle.”

On hämmästyttävää huomata, kuinka monimutkaista ja kankeaa raportointi on useimmille portfolio- ja ohjelmajohtajille — haastattelemamme henkilöt sanoivat, että raportointi edellyttää heiltä paljon manuaalista työtä — he käyttävät kuvakaappauksia useista eri työkaluista ja lisäävät ne myöhemmin esityksiinsä. 

Jos tämä ei ole tarpeeksi turhauttavaa, heidän on esitettävä tietonsa sekä ylemmälle johdolle että asiakkaille, jotka molemmat haluavat nähdä tilanteesta eri osan, mikä tarkoittaa kaksinkertaista työtä. Eräs portfoliojohtaja kertoi tutkijoillemme päivittävänsä tietyn työkalun tietoja manuaalisesti vain sen pienen mahdollisuuden vuoksi, että ylempi johto saattaisi haluta tarkastella niitä (he eivät muuten koskaan tee niin). 

Toinen haaste on se, että useimmat alustat ovat visuaalisesti ylikuormitettuja datalla, ja jos et tunne yksityiskohtia, projekteista on lähes mahdotonta ymmärtää mitään niitä tarkastelemalla. Tämä tarkoittaa, että portfoliojohtajien on käytettävä aikaa datan ”kääntämiseen” ylemmälle johdolle. 

Datan kokoaminen yhteen on myös vaikeaa. Todellista standardointia ei ole, ja raportit ovat eri muodoissa, minkä vuoksi portfoliojohtajat käyttävät paljon aikaa datan kokoamiseen sen analysoinnin sijaan. Tämä jättää myös tilaa mahdollisille inhimillisille virheille. 

Evansen kuvailee tilannetta, jossa hän kohtasi tämän haasteen.

“Yksi paikallisessa energiayhtiössä hallinnoimistani portfolioista oli yritystason portfolio, joten minun piti nähdä kaikki yhtiössä käynnissä olevat projektit ja ohjelmat”, hän sanoo. “Jossain vaiheessa niitä oli 62. Tarvitset siis työkalun, joka voi raportoida niistä kaikista ja … antaa minulle kaavioita ja koontinäyttöjä, joita voisin käyttää – en ainoastaan itse, vaan myös ylimmälle johdolle, jolle raportoin… [jotta] asiat voidaan esittää riittävän korkealla tasolla … niin, että he saavat hyödyllistä tietoa, mutta eivät esimerkiksi valtavaa määrää kaavioita, joissa on 90 datapistettä ja joista he toteavat: ‘En tiedä, mitä tämä tarkoittaa.’

Hoban on samaa mieltä: “Johdolle raportointi on aina todella vaikeaa. Organisaatiot joko eivät tee sitä, tai ihmiset eivät välttämättä halua johdon tietävän näin yksityiskohtaista tietoa, ja korkean tason näkymän luominen on todella vaikeaa. Teknologiapinon rakenteen selvittäminen voi todella auttaa tässä, ja seuranta pitäisi toteuttaa tavalla, joka mahdollistaa raportoinnin kaikille.”