Kuinka kävi – tuottiko kehityshankkeesi tavoitellut hyödyt?

Projekti on väline hyötyjen tuottamiseksi projektin sidosryhmille. Tavoitteena voi olla toiminnan laadun parantaminen, kustannustehokkuuden nostaminen, asiakastyytyväisyyden nostaminen jne.

Hyötyjen tunnistaminen ja saavutettujen hyötyjen mittaaminen ovat keskeisiä asioita arvioitaessa projektiehdokkaita suhteessa toisiinsa sekä sitä, kuinka onnistunut projekti lopulta olikaan.

Projektin valinta toteutukseen on valinta suuresta ehdokasmäärästä ja kriteerinä ovat hyötyjen maksimointi organisaation ja sidosryhmien kannalta.  Tähän tarvitaan toimivaa strategiaprosessia, jossa projektiehdokkaita arvioidaan suhteessa organisaation tavoitteisiin ja valinta kohdistetaan vain niihin, jotka täyttävät kriteerit parhaiten ja joilla on paras mahdollisuus menestyä.

Projektin tavoiteltavien hyötyjen saavuttamista pitää seurata ja mitata projektin alusta asti. Mikäli tavoitteet eivät suunnitellusti täyty, niin asiaan on puututtava sovituilla projektin muutoshallinnan keinoilla. Muutoshallinnan tulee keskittyä ensi sijassa tavoiteltujen hyötyjen saavuttamiseen. Projektin jatkaminen tulee olla mahdollista kyseenalaistaa missä tahansa toteutuksen vaiheessa. Näin projektin varaamat kyvykkyydet vapautuvat hyötyjä paremmin tuottaviin kohteisiin.

Hyötyjä aletaan saavuttaa useasti vasta projektin toimitusvaiheessa tai sen jälkeen. Samoja hyötyjä tavoitellaan myös muissa projekteissa. Merkittävää siis on, että tavoiteltujen hyötyjen saavuttamisen seuranta ja hallinta ovat projektien ylitse tapahtuvaa toimintaa. Seuranta tulee jatkua myös projektin toteutuksen jälkeen toiminnan jatkuvan kehittämisen periaatteiden mukaisesti.

Kyse on suunnitelmallisesta hyötyjen hallinnasta. Tavoitteena on varmistaa, että toteutettavat projektit saavuttavat tavoitellut hyödyt ja että saavutetut hyödyt ovat pysyviä. Hyötyjen hallinta edellyttää suunnitelmallisuutta, mittareita, omistajuutta ja sovittuja toimintamalleja. Asiaa on osaltaan edistänyt osaltaan myös PMI – Project management Institute omassa julkaisussaan.

Alla muutama vinkki hankkeen hyötysuunnitelman tekemiseen:

– Tunnista ja kuvaa tavoiteltavat hyödyt. Huomaa lyhyen ja pitkän tähtäyksen tavoitteet sekä sidosryhmien tavoittelemien suorien hyötyjen ohella välilliset hyödyt koko organisaatiolle.

– Muodosta mittari ja vertailukohta kunkin tunnistetun hyödyn saavuttamisen arviointiin sekä miten saavuttamista seurataan ja viestitään.

– Selvitä mahdolliset hyötyjen väliset riippuvuussuhteet. Varmista, että kukin tavoiteltava hyöty liittyy organisaation strategisiin tavoitteisiin.

– Määrittele hyödyn saavuttamiseen liittyvät keskeiset oletukset, tehtävät ja mahdolliset riskit ja rajoitteet.

– Arvioi kunkin hyödyn saavuttamisen ajankohta. Huomaa, että kyse ei niinkään ole tietystä hetkestä, vaan ajanjaksosta, jonka kuluessa hyöty saavutetaan ja se voi ulottua myös projektin päättymisen jälkeiseen aikaan.

– Määritä kuka omistaa kunkin tunnistetun hyödyn ja vastaa siitä, että saavutettu hyöty on pysyvä.

Edellä kuvattua projektin hyötysuunnitelmaa voidaan näppärästi visualisoida jana-aikataulukuvaajalla, joka ryhmitellään tarkoituksenmukaisesti. Kumulatiiviset rahalliset hyödyt voidaan esittää tähän liittyvänä histogrammina. Koko organisaatiota palvelevat vastaavat esitykset, mutta projektien ylitse tuotettuna.

Aivan kaikkia tavoiteltuja hyötyjä voi olla voi olla vaikea mitata kuten parantunut yritysimago. Tällaiset aineettomatkin hyödyt ovat yhtä tavoiteltavia, kuin mitattavissa olevatkin. Huomioi siis myös nämä hyötysuunnitelmassasi.

Tarvitsetko välineitä organisaatiosi hankkeiden strategianmukaisuuden arviointiin, priorisointiin ja valintaan? Ota yhteys – merkittäviä hyötyjä on saavutettavissa!

 

 

Pilvipalvelun elinkaarihallintaa

Viisaana päätöksenä yhä useammat yritykset ottavat käyttöön tarvitsemansa ohjelmistoratkaisut palveluna.

Palveluna käytettävissä ratkaisuissa tilaajalla on käytössään tyypillisesti toimittajan perusjärjestelmäratkaisun sisällä jonkinlainen asiakassovitus, jonka sisällöstä ja laajuudesta he itse vastaavat. Asiakassovitukseen voi liittyä raportteja ja rajapintoja sekä perusjärjestelmän laajennuksena sitä muuttanutta tai korvannutta toiminnallisuutta.

Uutena ja merkittävänä asiana on, että palvelun tilaajasta tulee tällöin aktiivinen toimija palveluna hankkimansa ratkaisun elinkaaren ylläpitäjänä.

Palvelun tilaajalla on myös monta huolta vähemmän:

  • Ylläpidettävänä ei ole vaativaa IT infrastruktuuria eikä sen edellyttämää osaamista ja tiloja.
  • Palvelu on käytettävissä ajasta ja paikasta riippumatta.
  • Palvelukeskustoiminta takaa skaalautuvan, korkean suorituskyvyn, tietoturvan ja luotettavuuden.
  • Toimittaja huolehtii palveluun kuuluvana siitä, että ratkaisu on teknisesti ja toiminnallisesti moderni ja aina ajan tasalla.
  • Merkittävää kertainvestointia ja siihen vuosiksi sidottua pääomaa ei tarvita. Mikäli tietojärjestelmä tulee tarpeettomaksi, niin palvelu on koska tahansa irtisanottavissa.
  • Toimittajan asiakastuella on suora pääsy ympäristöön ja mahdolliset ongelmatilanteet saadaan ratkaistua nopeasti.

Palveluna käytettävä ratkaisu edellyttää tilaajalta vahvaa sitoutumista ja organisoitumista sekä toimivaa yhteistyötä toimittajan kanssa. Tilaajan vastuulla viimekädessä on se, miten palvelun toimittajan tarjolle tuomia uusia tai korvaavia ominaisuuksia otetaan käyttöön ja miten asiakkaan tarpeisiin sovitettua ratkaisua ylläpidetään ja jatkokehitetään.

Organisaation toiminnan kannalta keskeisen palvelun elinkaarihallinnan apuna voidaan käyttää tuttuja ohjelmiston elinkaarihallinnan malleja ja tapoja:

  • Toteutetulle ratkaisulle annetaan käyttäjiä puhutteleva oma nimi erotuksena toimittajan perustuoteratkaisusta.
  • Kulloinkin käytössä oleva ratkaisukokonaisuus yksilöidään nimeen liitetyllä versiotiedolla.
  • Ratkaisun muodostavat erilliset asiakassovitukset (raportit, integraatiot, toiminnalliset laajennukset…) yksilöidään versiotiedolla.
  • Asiakassovituksiin liittyvä lähdemateriaali ja mahdollinen lähdekoodi hallintaan keskitetysti ylläpitoa ja jatkokehitystä varten.
  • Kehitysideat kerätään ja priorisoidaan ja ratkaisulle ylläidetään kehitystiekarttaa.
  • Ratkaisu dokumentoidaan ja sille toteutetaan ohjeistus ja koulutusmateriaali.

Laajennettavuuden ohella perusjärjestelmässä tulee olla sisään rakennettuna piirteet, joilla käytössä olevien erillisten asiakassovitusten kulloinenkin tilanne (versio) on mahdollista luotettavasti selvittää.

Versiointi tuo suunnitelmallisuutta ja jäntevyyttä toteutuksen eri osien ja itse kokonaisuuden elinkaaren hallintaan. Dokumentaatio, ohjeistus, käytössä olevat toiminnallisuudet, integraatiot ja kehitysideat on selkeää liittää tiettyyn versioon. Uusia piirteitä ja toiminnollisuuksia otetaan käyttöön tarpeen mukaan ratkaisun uusissa versioissa, joiden sisältö ja toteutusaikataulu suunnitellaan etukäteen ja jotka otetaan käyttöön hallitusti.

Ota yhteys jos pohdit kokonaisratkaisua organisaatiosi toiminnan suunnitteluun ja ohjaukseen haasteisiin. Saat sen kätevästi palveluna ja olemme valmiit ottamaan vastuuta ratkaisusi asiakassovitusten versiohallinnasta ja jatkokehityksestä.

Microsoft kiihdyttää Project for the Webiä

1. Project for the Web (PftW) ja Project Power App

Microsoftin uusi Project for the Web -väline on tarjonnut suoraviivaiset toiminnot aikataulujen laatimiseen ja tehtävien vastuuttamiseen tiimin jäsenille. Projektijohtaminen vaatii kuitenkin paljon muutakin, kuin vain tehtävät ja resurssivaraukset. Microsoft ei ainakaan vielä tarjoa mahdollisuutta muokata tai räätälöidä varsinaista https://project.microsoft.com osoitteesta löytyvää Project for the Web -välinettä.

Project for the Web tarjoillaan toisenkin käyttöliittymän kautta, nimittäin aikatauluja voi muokata myös mallipohjaisen Power App:n kautta. Project Power App:ssa voi muokata aikataulujen lisäksi muitakin projektiin liittyviä tietosisältöjä. Erityisen hyödyllinen Power App käyttöliittymä on, kun halutaan lisätä omia tietokäsitteitä, muokata käyttöliittymää ja sovelluksen liiketoimintalogiikkaa vastaamaan omaa tarvetta. Power App tarjoaa valmiin alustan räätälöidyn projektiohjausjärjestelmän pohjaksi.

2. Accelerator kiihdyttää kehittämistä

Microsoft julkisti hetki sitten Project Accelerator -nimisen laajennuksen Project Power Appiin. Accelerator laajentaa mallipohjaista Project Power App toiminnallisuutta, lisäämällä viisi uutta käsitteitä Project Power App:n käsitemalliin ja käyttöliittymään.

Entuudestaan Project for the Web:n tietomalliin kuuluivat peruskäsitteet, kuten esimerkiksi: Projekti, Tehtävä, Tehtävän riippuvuus ja Tiimin jäsen.

Erikseen asennettava Accelerator laajennus tuo mukanaan käsitteet:

Projektiehdotukset – Proposals
Ohjelmat – Programs
Riskit – Risks
Ongelmat – Issuet
Muutokset – Changes
Tilanneraportit – Status reports

Välttämättä uusien käsitteiden sisältö tai käyttöliittymä ei sellaisenaan tyydytä organisaation käyttötarpeita. Näitä käsitteitä kannattaakin ajatella aihioina, joihin voidaan lisäillä organisaation tarvitsemat tietokentät. Myös tietojen esitystapa ja toiminnallisuus käyttöliittymän lomakkeilla voidaan muokata tarpeen mukaan.

Accelerator ei siis niinkään kiihdytä Project Power App sovellusta suoraan, vaan nopeuttaa tämän pohjalta tehtävän laajemman toiminnallisuuden sisältävän räätälöidyn sovelluksen tekemistä.

3. Project Power App laajennettavuus Project lisensseillä

Accelerator lisäosan tuomien uusien käsitteiden lisäksi, Project-lisenssi sallii viiden oman lisäkäsitteen luomisen Project-sovelluksen tietomalliin, ja niiden hyödyntämisen Project Power App -käyttöliittymässä. Esimerkiksi tuotekehitysorganisaatiossa saatetaan haluta lisätä käsite: Tuote ja liittää projektit tuotteeseen. Tuotteiden tietojen ylläpitoon tarvittavat käyttöliittymän lomakkeet voidaan räätälöidä tarkoituksenmukaisiksi.

4. Tuki useille ympäristöille

Project Power App -sovelluksen laajennettavuutta helpottaa myös Microsoftin hiljattain tuoma tuki useille ympäristöille. Tämä tarkoittaa mahdollisuutta luoda erilliset kehitys- ja testausympäristöt tuotantoympäristön rinnalle. Yrityksen omat räätälöidyt toiminnot kehitetään kehitysympäristössä, paketoidaan ratkaisuksi ja siirretään sieltä testattavaksi testiympäristöön ja edelleen testauksen jälkeen tuotantoympäristöön.

5. Kuvia Project Accelerator käyttöliittymästä

(pikkukuva aukeaa uuteen ikkunaan)

Kuva: Project App jossa Accelerator

 

 

Kuva: Projektiehdotukset – Proposals

 

 

Kuva: Projektiehdotus -lomake

 

 

Kuva: Ohjelmat – Programs

 

 

Kuva: Ohjelman tiedot -lomake

 

 

Kuva: Projektin riskit

 

 

 

Kuva: Projektin riski-lomake

 

 

 

Kuva: Projektilista

 

 

Kuva: Projektin tiedot

 

 

Kuva: Projektin tilanneraportti

 

 

Kuva: Raportointi

Systems Thinking – Systeemiajattelu

Ei, otsikon käsite ei liity tietojärjestelmiin tai edes tietotekniikkaan. Kyse ei ole myöskään uudesta asiasta, vaan käsite on vakiintunut viimeisen 50 vuoden aikana.

Ajattelun taustalla on johtopäätös, että edes jotenkin rajatussa kokonaisuudessa asiat ja ilmiöt eivät ole toisistaan irrallisia. Kokonaisuuksien kautta näkeminen on systeemiajattelun tärkein ominaispiirre. Tavoitteena on tehdä näkyväksi, miten asiat ja ilmiöt kytkeytyvät toisiinsa ja kuinka tästä vuorovaikutuksesta syntyy jatkuvasti muuttuvien haasteiden ja mahdollisuuksien verkosto.
Parhaimmillaan systeemiajattelu on, kun pyrkimyksenä on jäsentää kompleksisia asioita (complex). Enemmän tai vähemmän monimutkaisten asioiden (obvious, complicated) erittely onnistuu sen sijaan hyvin jo arkiajattelulla. Kaaoksen (chaotic) hallinnassa ei edes systeemiajattelulla saada välttämättä hyvää lopputulosta. (https://en.wikipedia.org/wiki/Cynefin_framework).

Yhtymäkohta tietojärjestelmätyöhön tulee siitä, että tietojärjestelmien määrittelyssä ja toteutuksessa monesti ollaan tekemisissä kompleksisten asioiden kanssa. Optimistisena tavoitteena on kokonaisuuden mallintaminen ja tuottaa ajatellusta toteutuksesta malli. Sitäkin tarvitaan, mutta parempi lopputulos saavutetaan, kun toteutus mielletään jo lähdössä systeeminä, johon vaikuttavat tarpeen (ongelma, johon haetaan ratkaisua) ohella yksilöt, yhteisö, ympäristö sekä olemassa olevat toimintamallit ja rakenteet. Itse ongelma on jäävuoren huippu, joka pilkistää veden pinnalta. Siihen vaikuttaminen edellyttää pinnan alla olevien asioiden ymmärtämistä ja hyväksymistä.

Organisaation systeemikyvykkyys tuo toiminnan kehittämiseen merkittäviä etuja:

– Itseohjautuva ja yhteistyötä vaaliva tehokas organisaatio. Ymmärretään, että oma onnistuminen riippuu myös muiden työpanoksesta. Organisaation toiminta hyväksytään kokonaisuutena, jossa asiat ja henkilöt ovat alituisessa vuorovaikutuksessa.
– Uusia ja ennakoimattomia asioita syntyy henkilöiden ja asioiden ollessa vuorovaikutuksessa keskenään. Näiden poikkeamien tunnistaminen ja hyödyntäminen palkitsevat itseohjautuvan ja innovatiivisen organisaation uusilla kilpailuvalteilla.
– Asiat eivät henkilöidy ja ongelmaratkaisu on nopeaa. Aina asiat eivät mene odotetusti, mutta juurisyyt ja ratkaisut löydetään nopeasti erittelemällä ongelmaan liittyvät asiat ja miten ne vuorovaikuttavat toisiinsa.
– Ongelmat on tehty ratkaistaviksi. Mitkä tahansa ongelma on mahdollista nähdä haasteena, johon ratkaisut ovat löydettävissä jäsentämällä taustalla olevat syyt, ylläpitävät rakenteet ja ajattelutavat.
– Vahva pohjan toiminnan jatkuvalle kehittämiselle. Asioiden syy ja seuraussuhteet ovat selvillä ja toimintaa kehitetään ja säädetään tehokkaasti kohdistamalla huomio juuri oikeisiin asioihin toivotun vaikutuksen aikaansaamiseksi.
– Luodaan parhaat edellytykset asetettujen tavoitteiden saavuttamiseen. Päätöksenteko nojaa realistiseen ja ajantasaiseen kokonaisnäkemykseen organisaation toiminnasta ja toimintaan vaikuttavista asioista ja ilmiöistä. Lähtötilanteen ollessa selvillä tavoitteeseen on jo helpompi luovia.

Systeemiajattelua tukemaan on kehitetty erilaisia visuaalisia työkaluja, joiden avulla systeemin rakenne voidaan kuvata. Vuorovaikutuskaavio (causal loop diagram, CLD) on yksi näistä (https://en.wikipedia.org/wiki/Causal_loop_diagram).

Tietojärjestelmäkehityksessä systeemiajattelu kannustaa kokonaisratkaisujen toteuttamiseen osaratkaisuiden sijaan. Toteutettavan tietojärjestelmän tulisi huomioida kattavasti kaikki asiat ja ilmiöt, jotka kiinteästi liittyvät toteutettavaan ratkaisuun.

Esimerkiksi portfoliohallinnan keinoin on mahdollista hallita toimintaympäristön sanelemaa muutosta ja organisaation itselleen asettamia tavoitteita. Portfoliohallintaa ei kuitenkaan ole ilman projekteja sekä näissä mahdollisesti kehitettäviä tuotteita ja asioita. Uskottava projektien ja töiden hallinta edellyttää suunnitelmallisuutta ja toteuttavia resursseja. Resurssien osaamisen optimaalinen hyödyntäminen edellyttää toimivaa kapasiteettihallintaa. Toiminnan kehittämiseksi ja kokonaisuuden ylitse tehtäviin tarkasteluihin tarvitaan yhteisiä mittareita kustannuksista, väli- ja lopputulosten saavuttamisesta ja henkilöstön tyytyväisyydestä.

Tietojärjestelmätyössä systeemiajattelu johtaa myös johtopäätökseen, että täsmälleen sama toteutus ei sovi kaikkiin organisaatioihin ja ympäristöihin. Lisäksi systeemi ja vaatimukset muuttuvat koko ajan. Tarvitaan joustavuutta, joka mahdollistaa tietojärjestelmän sovittamisen erilaisiin ja alati muuttuviin tarpeisiin.

Ota yhteys, jos mielenkiintosi heräsi kokonaisvaltaisen ja organisaatiosi kulloisiinkin tarpeisiin mukautuvan tietojärjestelmän toteuttamisesta.

Camako EPM versio 6 irtautuu SharePointista

Camako EPM on perustoiminnallisuuksiltaan laaja projektien- ja työnohjauksen järjestelmä. Se on myös muokattava (low-code / no-code) alusta eri sovellusalueiden ratkaisujen helppoon toteutukseen.

Camako EPM on syntynyt ja kasvanut SharePoint alustalla. Nyt sen on aika rikkoa kahleensa ja irtautua SharePointista, kokonaan itsenäiseksi järjestelmäksi.

Aikansa kutakin

Camako EPM:n tuotekehityksen alkuvaiheessa, SharePoint alusta mahdollisti nopean tuotekehityksen ja laajan toiminnallisuuden. SharePoint tarjosi valmiin käyttäjähallinnan, alustan käyttöliittymälle ja lisätoimintoja, kuten dokumenttien hallinnan. Samalla SharePoint kuitenkin myös rajoitti kehittämistä usealla tavalla.

Nyt haluamme kehittää Camako EPM järjestelmää, ilman SharePointin rajoituksia. Haluamme myös taata asiakkaillemme edullisen tavan jatkaa Camako EPM järjestelmän käyttöä, kun Ilmaisen SharePoint Foundationin käyttömahdollisuus poistuu version 2013 myötä. Ilman kolmannen osapuolen lisenssivaatimuksia järjestelmän hinta voidaan pitää kohtuullisena ja ennustettavana.

Haluamme tarjota järjestelmän, joka sisältää laajat perustoiminnallisuudet, mutta myös mukautuu asiakkaidemme muuttuviin tarpeisiin. Joustava, muokattava alusta kasvattaa järjestelmän elinkaarta, koska järjestelmä mukautuu uusiin vaatimuksiin. Se myös mahdollistaa järjestelmän hyödyntämisen muissakin käyttöskenaarioissa, kuin projektien hallinnassa.

SharePointista irrottaminen mahdollistaa modernien teknologioiden hyödyntämisen esimerkiksi käyttöliittymän toteutuksessa. Nyt voidaan hyödyntää modernia JavaScript tekniikkaa käyttöliittymässä. Tämä mahdollistaa dynaamisen, rikkaan käyttökokemuksen.

Dokumenttien hallintaa voidaan edelleen jatkaa SharePointin dokumenttikirjastoissa, mutta SharePointin ohella mikä tahansa muukin dokumenttihallintajärjestelmä voidaan kytkeä joustavasti osaksi Camako ratkaisua.

Tekninen alusta valinnaisesti pilvessä tai maan päällä

Camako EPM 6 voidaan asentaa täysin pilviympäristöön, omaan tekniseen ympäristöön, Prohan tarjoamaan SaaS ympäristöön tai tarpeen mukaan, vaikka hybridiympäristöön, jossa tietovarasto on pilvessä ja sovellus Prohan SaaS ympäristössä.

Asiakas omistaa tietonsa, tietää missä ne ovat talletettuina ja tarvittaessa voi siirtää tietonsa toiseen ympäristöön. Camako EPM, ei ole moniasiakasympäristö, jossa eri käyttäjäorganisaatioiden tiedot sijaitsisivat samassa fyysisessä tietovarastossa. Jokaiselle käyttäjäorganisaatiolle luodaan oma tietovarasto. Käyttävän organisaation kaikki tieto on omassa SQL kannassa, josta se on helposti raportoitavissa, varmistettavissa ja siirrettävissä.

SharePointista irtautuminen on vaatinut käyttäjähallinnan toteutuksen kokonaan uudelleen. Uusi versio kasvattaa tietoturvallisuutta mahdollistamalla useita erilaisia käyttäjien tunnistamisen tapoja.

Perustoiminnallisuus kehittyy, alustan joustavuus säilyy, käytettävyys paranee

Camako EPM:n perustoiminnallisuuksia ovat olleet: Projektisalkku, projektisuunnitelmat, tehtäväaikataulut, tuntien kirjaus myös mobiilissa, aikajaksotettu resurssien kuormitussuunnittelu, suunnitelmien versiointi. Uutena toiminnallisuutena on valmistunut aikajaksotettu kustannusten suunnittelu.

Paketista otettuun ratkaisuun ei kuitenkaan tarvitse tyytyä. Joustava alusta tarjoaa edelleen mahdollisuudet muokata ja laajentaa järjestelmän tietomallia ja liiketoimintalogiikkaa. Muokatun tietomallin päälle rakennetaan käyttöliittymä käyttäen konfiguroitavia taulukko- ja lomakenäkymiä, Gantt-kaavioita, Kanban-taulua ja aikajaksotettuja resurssi ja kustannusnäkymiä.

Käyttöliittymän kieli on käyttäjän itsensä valittavissa. Uusi käyttöliittymä mahdollistaa myös entistä joustavamman datan analysoinnin. Graafisten esitysten vienti Camakosta esimerkiksi Power Pointiin Gantt-kaavioina ja Kanban-tauluina onnistuu.

Tulemme kevään aikana esittelemään Camako EPM 6 versiota webinaareissa.

Low Code No Code kehittäminen

Edellisessä bloki -kirjoituksessamme esiteltiin ohjelmistokehittämisen mallia, jossa ratkaisu toteutetaan joko ilman tai vain rajoitetulla määrällä itse tehtyä ohjelmakoodia. Siinä ohjelmointityön sijaan käyttöliittymä ja liiketoimintalogiikka toteutetaan ratkaisukehitysalustan tarjoamilla palveluilla ja muokattavilla komponenteilla.

Optimistisena tavoitteena on mahdollistaa Citizen Development (’kansalaiskehittäjä’) toiminta, jossa liiketoiminnan vaatimukset hyvin sisäistänyt, mutta vähän tai ei yhtään ohjelmistokehitystä hallitseva henkilö voisi toteuttaa ohjelmistoratkaisun tietojen hallintaan ja raportointiin. Perinteisesti toimintaan on käytetty toimisto ja –työryhmäsovelluksia. Näitä täydentämään ovat tulleet monipuoliset Saas- ja pilvipalveluna tarjottavat alustat, joille tehdyt toteutukset skaalautuvat aina yritystason ratkaisuihin asti.

Jo tällä hetkellä yrityksissä hyödynnetään jo laajasti raportointi- ja tiedon analysointiratkaisuihin kehitettyjä alustoja.

Jonkin verran vaativampaa on liiketoimintaa tukevan ohjelmistoratkaisun toteutus. Ohessa askeleet miten alun perinkin ratkaisukehitysalustaan nojaavaa projektien- ja töidenhallintajärjestelmää laajennettiin riskienhallinnan toiminnallisuudella.

Toteutuksen päävaiheet olivat:

  1. Tietojen ja näiden välisten relaatioiden määrittely. Tämä on vaativin osa, jossa asiantutijan käyttäminen palkitsee.
  2. Toteutuksen ulkoasun päättäminen. Käyttöön otettiin kokeilujen jälkeen visuaalinen taulu –muotoinen käyttöliittymä. Ratkaisukehitysalusta tarjoaa tyypillisesti erilaisia ulkoasuvaihtoehtoja esim. lista-, lomake ja taulumuotoiset näkymät ja erilaiset esitysgrafiikat.
  3. Toimintojen määrittely ja toteutus. Valittu taulu –muotoinen käyttöliittymä toi mukanaan jo paljon vaadittua toiminnallisuutta. Tämän lisäksi määriteltiin laskennalliset tiedot (riskipisteiden laskenta lähtötiedoista) ja tietokenttien arvojen tarkistukset ja pakollisuudet. Poimintalistoille toteutettiin lista –muotoiset ylläpitonäkymät.
  4. Integraatioiden määrittely ja toteutus. Kokonaisuus täydennettiin riskipisteiden perusteella lähetettävillä sähköpostilähetyksillä.
  5. Merkitsevän tiedon visualisointi. Toteutuksessa hyödynnettiin alustan tarjoamia liikennevaloja ja ikoneita korostamaan ja tuomaan esiin kriittistä tietoa ja työnkulkua.
  6. Väli- ja lopputulosten testaus. Toteutus eteni iteratiivisesti ja sen aikana palattiin lukusia kertoja päävaiheissa taaksepäin tyydyttävän lopputuloksen aikaansaamiseksi.
  7. Ratkaisun siirtäminen tuotantokäyttöön. Tuotantokäyttöön siirtäminen on syytä tehdä omana kokonaisuutenaan noudattaen organisaatiossa sovittuja käytäntöjä.

Toteutuksen tietomalli löytyi melko valmiiksi mietittynä internetistä. Mallin mukaiset rakenteet on toteutettu olemassa olevan projektien- ja töidenhallintajärjestelmän tietokantaan. Taulu -muotoisessa käyttöliittymässä yksittäiset riskit esitetään kortteina riskiluokkien mukaisissa sarakkeissa. Korttien järjestys sarakkeessa visualisoi kunkin riskin merkittävyyttä luokassaan ja liikennevaloilla pyritään visualisoimaan kuhunkin riskiin liittyvää tila- ja kriittisyystietoa. Riskin tietoja pääsee ylläpitämään korttia kaksoisklikkaamalla. Korttien järjestys ja sarake vaihtuvat siirtämällä korttia hiirellä.

Kuva 1. Uusi riskienhallinnan toiminnallisuus osana projektien ja töidenhallintaa.

 

 

 

 

 

 

 

Kuva 2. Suoraviivainen riskienhallinnan tietomalli

Heräsikö mielenkiitosi? Ota yhteys https://www.proha.com/yhteystiedot ja kerromme mielellämme lisää Low Code No Code kehittämisen eduista liiketoimintasovellusten toteuttamisessa Saas palveluna.

Low Code No Code

Selainpohjainen ohjelmistoratkaisu organisaatiosi tarpeeseen ilman ohjelmointia ja tehty toteutus käytettävissä kustannustehokkaasti pilvipalveluna.

Tämä on mahdollista nykyaikaisilla ratkaisukehitysalustoilla.

Ratkaisualusta tarjoaa tarvittavan toteutuskehyksen. Ohjelmointityön sijaan käyttöliittymä ja toiminnot toteutetaan alustan tarjoamilla muokattavilla komponenteilla. Toteutukset skaalautuvat tarvittaessa vaativiin ratkaisuihin ja mahdollistavat myös ohjelmoimalla tehtävät laajennukset.

Vaativin osa on tavoitellun ratkaisun tietomallin hahmottaminen. Tällä kuvataan tietorakenteet ja tietorakenteiden väliset suhteet. Alustojen piirteisiin kuuluu, että kerralla ei tarvitse olla valmista, vaan ratkaisun toteutuksessa voidaan edetä ketterästi iteroiden ja eri vaihtoehtoja arvioiden.

Merkittävää on, että ratkaisukohtaisesti ylläpidettävää ohjelmakoodia ei juuri synny. Ratkaisun konfiguraatiotiedot on talletettu samaan tietokantaan, kuin ylläpidetty liiketoimintatietokin. Näin se pysyy tallessa ja on aina käytettävissä ratkaisun edelleen kehittämiseen.

Tehtiin ratkaisu sitten omaan käyttöön tai palveluksi asiakkaille, niin merkittäviä etuja on saavutettavissa:

  • Ketteryys, korkea laatu ja pienemmät riskit. Varsinainen toteutus syntyy ketterästi. Helposti mukautettavat ratkaisut auttavat myös organisaatiota toimimaan ketterästi. Toteutustyö etenee nopeasti. Väli- ja lopputuloksia voidaan arvioida toteutuksen kaikissa vaiheissa. Huomattavaa on, että suhteessa enemmän panosta voidaan laittaa ohjelmointityön sijasta ratkaisun testaamiseen.
  • Pienentyneet kustannukset. Aika on rahaa – mahdollisuus rakentaa enemmän, pienemmällä tiimillä ja lyhyemmässä ajassa.
  • Korkeampi tuottavuus. Useampia ratkaisuja valmistuu lyhyemmässä ajassa. Tuottavuutta tuo myös se, että toteutettu ratkaisu on käyttäjäkokemuksen osalta yhdenmukainen läpi koko toteutuksen ja näin myös helposti loppukäyttäjien omaksuttavia.
  • Nopeampi reagointi muutokseen. Nopeiden kehityssyklien ja muokattavuuden kautta organisaatiot voivat nopeasti sopeutua markkinoiden muutoksiin, asiakkaiden muuttuneisiin tarpeisiin tai lainsäädäntöön.
  • Pidempi elinkaari. Tehdyn ratkaisun elinkaarta voidaan jatkaa joustavasti muokkaamalla tai laajentamalla olemassa olevaa toteutusta. Ratkaisualustan toimittaja huolehtii teknologian ajanmukaisuudesta ja uusien muokattavien perustoiminnallisuuksien tuottamisesta.

Alla esimerkki ratkaisualustan tarjoamasta toiminnallisuudesta projektihallintaratkaisun toteutukseen. Toteutus on selainpohjainen Saas palvelu, jossa tiedot ylläpidetään relaatiotietokannassa. Esimerkkiratkaisu ei ole edellyttänyt ohjelmointia, vaan nojaa projektihallinnan tietomalliin, ratkaisualustan tarjoamaan sovelluskehykseen sekä muokattaviin komponentteihin.

  • Käyttäjän ja käyttäjän roolien todentaminen Azure AD:n ryhmäkiinnityksen kautta. SSO.
  • Käyttäjälle avautuu rooliensa mukainen valikkorakenne
  • Käyttöliittymän kielisyys on vaihdettavissa valikkotoimintona
  • Projektilistaan haetaan tietokannasta vain ne projektit, joihin käyttäjälle on annettu oikeudet
  • Projektilistan sisältö on suodatettavissa sarakesuodattimen tai näiden yhdistelmien kautta
  • Projektilistan sarakekokoonpanoa voidaan vaihdella erilaisten valittavana olevien näkymien välillä
  • Riveillä olevien liikennevalojen väri asetetaan sovittujen sääntöjen ja laskukaavojen mukaan
  • Ulkoisiin järjestelmiin on mahdollista siirtyä rivikohtaisista pikalinkeistä: dokumenttihallinta ja Jira
  • Valitun projektin tehtävät on tuotu kytkettyyn taulukkonäkymään projektilistan alle

Ei ole yllättävää, että ratkaisualustat löytyvät myös monen kaupallisen liiketoimintasovelluksen takaa. Käytetty ratkaisualusta rajaa aina jonkin verran toteutusvaihtoehtoja, joten aivan kaikkia toiveita ei ilman ohjelmointia voida toteuttaa. Rajallisella ohjelmointityöllä ratkaisu saadaan myös integroitumaan saumattomaksi osaksi yrityksen muuta sovelluskantaa. Ota yhteys, jos mielenkiitosi heräsi juuri omaan tarpeeseesi sovitetun ratkaisun toteuttamisesta kustannustehokkaasti ja sen käyttämiseksi palveluna.

Havaintoja etäkokouksesta

Ulkona vihmoo marraskuun harmaus. Kodeissa, mökeissä ja muissa etätyöpisteissä näytöt valaisevat ja läppärit puhkuvat lämpöä. Suuri joukko työntekijöitä on jo pitkään työskennellyt kokonaan tai pääosin etätyöpisteissä. Koteihin on hankittu uusia työpöytiä, työtuoleja, näyttöjä, kuulokkeitaOn ehkä jopa remontoitu, jotta on saatu aikaiseksi itselle sopivat, viihtyisät ja tuottavat työskentelynurkkaukset. 

Keväällä aloitimme vaimon kanssa etätyöt toiveikkaasti yhteisessä työhuoneessa. Jo pian havaitsimme, ettei kumpikaan kykene keskittymään työntekoon, jos toisella on käynnissä etäkokous. Siirtyminen toiseen huoneeseen kokouksen ajaksi ei myöskään ollut hyvä ratkaisu. Työkalujen siirtely, toisesta näytöstä luopuminen juuri kokouksen ajaksi ei toiminut. Oma työhuone on meillä ollut yksi keskittymisen edellytys. 

Mahtavatkohan ihmiset enää suostua palaamaan avokonttorien hälyyn, kun ovat saaneet kokea rauhallisen, häiriöistä vapaan työympäristön? 

Vielä vartti työpajan alkuun. Availen esitykset, dokumentit ja sovellukset valmiiksi kahdelle näytölle. Toisen näytön tulen jakamaan muille, toisella pidän muistiinpanot ja muut ohjelmat. Viimeistelen agendan ja varmistan että dokumentit on jaettu osallistujille OneDriveltä. Napsautan kahvinkeittimen porisemaan, niin että saan tuoreen kahvin kokoukseen.  

Valmistautuminen on onnistuneen etäkokouksen edellytys. Kun ohjelmat ja dokumentit on valmiiksi avattu ja käynnistetty, jo ennen kokouksen alkua, jää pois paljon turhaa odottelua ja sähläystä. 

Verkkokytkimen vihreät valot vilkkuvat, kun käynnistän Teams kokouksenEhdin vielä valita videoon taustakuvan edelliseltä loma- ja etätyöreissulta. 

Olen mukana kokouksessa jo ennen säädettyä aikaa, silloin on hyvä hetki keskustella yksitellen mukaan ilmestyvien osallistujien kanssa niitä näitä ja orientoitua rauhassa. 

Etätyön mahdollistama infrastruktuuri on olemassa. Tietoliikennekaapelit yhdistävät kokouksen osallistujat. Kuin tilauksesta, hyvissä ajoin ennen pandemiaa, opittiin hyödyntämään etäkokousohjelmistoja, tiedostojen jakoja ja muita viestintäohjelmistoja. Asiantuntijoiden työn tulokset liikkuvat nopeissa tietoverkoissa vaivatta. 

Samaan aikaan kun eri osallistujat jakavat näyttöään, teemme päivityksiä jaettuun dokumenttiin, jonka kaikki osallistujat pääsevät näkemään, ja jota he voivat muokata samaan aikaan. Näin kokousmuistion päivitys ja ehdotukset tulevat kirjattua ja jaettua jo kokouksen aikana. 

Ideointiin pitäisi keksiä sopivia vapaamuotoista keskustelua tukevia keinoja. Etäpalaverit toimivat hyvin tilanteissa, joissa kokoontumiselle on mahdollista muodostaa selkeä tavoite ja agenda. Ideoiminen vaatii aikaa, hassuttelua ja vitsailua sekä kokemusten vaihtoa. Ideat eivät välttämättä nouse pakotettuna organisoidussa kokouksessa. Joskus jakautuminen pienempiin ryhmiin voi auttaa. 

Palaverissa nousi esiin ongelma, jonka avaaminen vaati parimukana olevan henkilön lisäksi ulkopuolista henkilöä. Jakauduimme kahteen ryhmään, joista toiseen kutsuttiin yksi asiantuntija lisää. Toinen ryhmä jatkoi muiden asioiden käsittelyä, samalla kun toinen ryhmä tutki ja testasi esiin noussutta ongelmaa. 

Joskus kokouksen vetäjän pitää vain osata olla hiljaa ja antaa muille mahdollisuus sanoa asiansa. 

Reilun tunnin kuluttua kelloni piippaa ehdottaen taukoa. Sovitaan, että pidetään 15 minuutin tauko. Muutamat osallistujat jäävät tauolla jutustelemaan Teams kokoukseen.  

Kokouksen päätyttyä osalla ei ole erityinen hoppu seuraavaan palaveriin, he jatkavat erään tuotteeseen liittyvän puutteen tarkastelua ja pohdiskelua vielä tovin. Keskustelussa syntyi idea tuotemuutokseen. Sovittiin että sitä tarkennetaan uudessa kokoontumisessa. 

Jämäkästi viedyssä kokouksessa saattaa jäädä pimentoon ongelmia, jotka tulisivat esiin rennossa, vapaamuotoisessa keskustelussa. Heikkojen signaalien huomaaminen ja rohkeus poiketa agendalta ottamalla ongelma keskusteluun, vaatii etäkokouksessa enemmän tarkkaavaisuutta, kuin perinteisessä kasvokkain käydyssä keskustelussa. 

Portfolio Kanban

Kanban taulu -näkymät ovat korvaamaton apu tuote- ja palvelukehitystiimien tuotannonohjaukselle​. Toimintamallin etuja on jo ehditty käsittelemään aiemmassa blokikirjoituksessa.

Ketterissä toimitusmalleissa toteutustyön väli- ja lopputulokset siirtyvät työnkulussa vauhdikkaasti ja tapahtumia on sellaisia määriä, että kokonaistilanteen hahmottaminen ja tietoisuus siitä, missä mennään vaikeutuvat.

Tarvitaan siis uusia välineitä hankkeiden tilan seurantaan ja kokonaisuuksien hallintaan. Tähän tarpeeseen vastaa Portfolio Kanban.

Porfolio Kanban nojaa samoihin periaatteisiin, kuin kehitystiimien töiden hallintaa ohjaavat taulunäkymät. Erona on tarkastelutarkkuus, joka Portfolio Kanbanissa on tyypillisesti projekti/hanketasolla. Mikä tahansa muukin töitä kokoava yhteinen luokittelu tai rakennetieto voi toimia tarkastelun lähtökohtana.

Alla on esimerkki perusmuotoisesta näkymästä, jossa esitetään organisaation hankkeet elinkaarivaiheittain. ​Elinkaarivaiheet ovat sarakkeina ja hankkeet kortteina kussakin sarakkeessa.

Toimintamalliin kuuluu, että hanke siirtyy sovituilla periaatteilla vaiheesta toiseen ja kussakin vaiheessa on kulloinkin vain halittavissa oleva määrä työtä (Work In Progress rajat).

Toimintamallin soveltamiseen kuuluu oleellisesti myös jatkuvan kehittämisen periaate, eli toimintaa hienosäädetään ja kehitetään jatkuvasti käytössä olevien tietojen perusteella.

Hankkeiden KPI tietoa visualisoidaan erilaisilla liikennevaloilla. Mittarit mietitään organisaation omista lähtökohdista. Nämä voivat pohjautua hankkeiden suoritetietoihin tai hankkeen luokittelutietoihin esim. strategianmukaisuudesta, riskeistä ym. Hankkeiden priorisointi tapahtuu luontevasti suoraan näkymässä vaikuttamalla hankkeiden järjestykseen kunkin vaiheen sisällä.

Huolella mietityssä Portfolio Kanban näkymässä on mahdollista visualisoida koko organisaation toimintaa hankkeiden toimitusmalleista riippumatta. Sekä perinteisen että ketterän toimitusmallin hankkeet esitetään samassa näkymässä huolehtimalla näille vertailukelpoiset mittarit sekä keskeisiltä osin sama elinkaarimalli. Näin erilaiset hankkeet kohtaavat yhdessä näkymässä ja näitä arvioidaan samoista lähtökohdista organisaation toiminnan kannalta merkittävissä päätöksentekopisteissä.

Portfolion hallinta Kanban näkymän kautta tehostaa toimintaa, nopeuttaa päätöksentekoa ja parantaa laatua:

-Turha työ vähenee ja toiminta on ennustettavampaa,​ kun kaikki tekeminen tuodaan näkyväksi.
-Tarkkaan mietityllä vaihemallilla ja sen aktiivisella hallinnalla nopeutetaan läpimenoaikoja.
-Laatu ja tehokkuus paranevat, kun huomio on työn alle otettujen hankkeiden valmiiksi saamisessa.
-Tekemisen esteet ja pullonkaulat tulevat näkyviksi ja ongelmat saadaan ratkaistua nopeammin.
-Toimintaympäristössä tapahtuviin muutoksiin on mahdollista reagoida nopeasti, kun oman toiminnan tilanne on selkeä ja hallinnassa.

Portfolio Kanban mallin toteuttaminen edellyttää käytännössä tietojärjestelmää, jossa koko organisaation toiminta on mallinnettuna perinteisinä projekteina ja/tai ketteränä kehittämisenä. Ota yhteys jos mielenkiintosi heräsi Portfoliohallinnan ratkaisuun, joka tarjoaa visuaalisen ja informatiivisen näkymän organisaatiosi toimintaan hankkeiden toimitusmalleista riippumatta.

Projektisalkun valinnan kriteerit neljällä sanalla

Esitän tässä neljä näkökulmaa, jotka tulisi jollain tavalla huomioida projektien valinnassa. Ne voi muotoilla selkeiksi kysymyksiksi 

Halu – Haluammeko me projektia?
Hyvyys – Onko projekti hyvä investointi?
Kyky – Onko meillä kyky toteuttaa projekti?
Riski – Onko meillä riittävä tieto projektin toteutettavuuden arvioimiseksi? 

Halu 

Strategian tulee kuvata halua, mihin organisaation voimavarat kohdistetaan. Projektien strategianmukaisuuden arvioinnissa on kyse siitä, että kohdennetaan valinnat sellaisiin projekteihin, jotka vievät organisaatiota strategian osoittamaan suuntaan. Eihän  kannata panostaa projekteihin, jotka eivät sovi “meidän organisaatiollemme” tai jotka kehittävät toimintaa väärään suuntaan. 

Strategianmukaisuuden arvioinnin yleinen malli kulkee läpi neljä vaihetta: 

  1. Määritellään organisaation strategiset tavoitteet: Mitä ovat tärkeimmät kehittämisen alueemme?
  2. Arvotetaan strategiset tavoitteet suhteessa toisiinsa: Mitkä kehittämisen alueet ovat tärkeimmät?
  3. Arvotetaan projektit suhteessa strategisiin tavoitteisiinKuinka paljon kukin projekti edesauttaa kunkin strategisen tavoitteen saavuttamista?
  4. Projektin suhteellinen strateginen arvo voidaan laskea, kun tiedetään paljonko projekti tuottaa eri strategisten painopistealueiden hyötyjä. Suhteellisen strategisen arvon mukaan projektit voidaan järjestää strategianmukaisuuden mukaan, joka kuvaa organisaation strategista halua toteuttaa kyseinen projekti. 

Halu on organisaatiota eteenpäin vievä voima. Siksi joskus valitsemme toteutukseen projekteja, joita kovasti haluamme, vaikka niiden kannattavuutta investointina emme kykenekään perustelemaanUsein puhutaan myös ns. pakkoprojekteista. Sellaisia ovat esimerkiksi turvallisuusvaatimusten edellytykset, lakisääteiset muutokset tai muut liiketoiminnan jatkuvuutta vaativat investoinnit. Tällaiset pakolliset projektit on kyettävä sopivalla tavalla tunnistamaan strategisiksi projekteiksi. 

Hyvyys 

Ei kannata toteuttaa huonoja investointeja, jotka vain syövät resurssit, mutteivät maksa itseään takaisin hyötyinä. Jotkin projektiehdotukset ovat parempia kuin toiset kannattavuutensa ja tuottamansa arvon mukaan. 

Investoinnin hyvyyttä voidaan arvioida saavutetuilla hyödyillä suhteessa panostuksiin. Hyvyyttä arvioitaessa otetaan myös huomioon kustannukset, jos projektia ei toteuteta, näin huomioidaan myös tarpeelliset ylläpitoinvestoinnit. 

Arvioinnissa huomioidaan sekä rahalliset, että ei rahalliset hyödyt. Ei rahallisia ovat esimerkiksi sidosryhmien tyytyväisyyteen, ihmisten terveyteen ja hyvinvointiin tai toiminnan tai tuotteiden laatuun liittyvät mittarit, joiden muuntaminen rahallisiksi arvioiksi voi olla haasteellista. Usein hyvyyttä kuvataankin sanalla vaikuttavuus. 

Hyvyyden tyypillisiä taloudellisia mittareita ovat esimerkiksi: 

  • Payback period – Takaisinmaksuaika 
  • ECV – Estimated Commercial Value – Arvioitu kaupallinen hyöty 
  • NPV – Net Present Value – Nettonykyarvo 
  • IRR – Internal Rate of Return – Investoinnin sisäinen korko 
  • ROI – Return On Investment  Sijoitetun pääoman tuotto 

Jo käynnissä olevien projektien hyvyyden tulisi olla parempi kuin muuten saman kaltaisten aloittamattomienYllä olevissa mittareissa esimerkiksi ECV, ei ota huomioon jo tehtyjä investointeja, näin se asettaa tavallaan jo aloitetut etusijalle, verrattuna aloittamattomiin.

Kyky 

Kuten tiedämme, elämä on onnellista, kun halut ja kyvyt ovat sopivalla tavalla tasapainossa. Resurssien saatavuus rajoittaa kykyä toteuttaa projektiehdotuksia. Yleensä projektiideoita on enemmän kuin taloudellisia ja henkilöstöresursseja niiden toteutukseen. 

Toteutuskyvyn arvioinnissa huomioitava sekä kuormitus että saatavuus 

  • Projektien rahoitustarpeen ennustettavuus ja rahoituksen riittävyys 
  • Henkilöresurssien saatavuus vs. projektien yhteenlaskettu kuormitus 
  • Ulkopuolisten resurssien käyttömahdollisuudet 
  • Mahdollisuudet projektien aikataulujen joustavaan muuttamiseen 
  • Projektitoimintamallin suorituskyky 

Kyvykkyyttä pitää arvioida suhteessa aikaan. Projektien taloudellinen suunnittelu ja resurssien tarve pitää arvioida aikajaksotetusti. Projektien kumulatiivinen resurssitarve arvioidaan myös aikajaksotettuna tarpeena. Tasapainotetussa salkussa on erikokoisia projekteja, joiden keskinäiset prioriteetit määritellään Halu- ja Hyvyys- mittarien avulla. Kun prioriteetit ovat selkeät, voidaan resurssikapasiteettitarvetta tasata projektien aikatauluja muuttamalla.

Riski

Toisen projektin nettonykyarvo on 10% suurempi kuin toisen. Kelpaako tämä tieto päätöksentekoon? Kuinka oikeita tai tarkkoja arviot ovat?  

Suunnitelmien ja arvioiden tieto ei koskaan ole eksaktisti oikeaa. Suunnitelma voi näyttää, että projekti valmistuu vuoden kuluttua huhtikuun kolmas päivä, tai kustannusarvio ennustaa, että projekti saadaan valmiiksi 567 843,63 Eurolla. Nämä arviot, mitä todennäköisemmin, eivät pidä paikkaansa. Kysymys onkin, kuinka tarkkoja suunnitelmat ovat. Millä todennäköisyydellä projekti myöhästyy kaksi viikkoa, entä kuinka todennäköistä on, että se viivästyy vuodella? Millä todennäköisyydellä budjetti ylitetään alle 15%, kuinka todennäköistä on, että ylitys onkin 50%? 

Koska lähtökohtaisesti salkunhallinnan tieto on aina väärää. Projektien valinnassa on arvioitava suunnitelmien luotettavuutta. Suunnitelmien arvioita saattaa vääristää lähtötietojen puutteellisuus, liiketoimintaympäristön ennustamattomuus, arvioijien subjektiivisuus ja arvioihin lisätyt varmuuspuskurit. 

Riskiä arvioimalla pyrimme saamaan tietoa arvioiden luotettavuudesta ja lopputuleman hajonnasta. 

Valmisteluvaiheessa riskiä voidaan kuvata riskimittarilla, jonka arvo lasketaan kaikille projekteille samalla tavalla. Sopivia välineitä riskimittarin tekemiseksi on esimerkiksi: 

  • Riskianalyysi määrämuotoisella tavalla tehtynä 
  • Riskiluokan arviointi objektiivisen kysymyslistan avulla 
  • Herkkyysanalyysit 

Salkun tasapainottamisen näkökulmasta emme voi valita salkkuun ainoastaan pienen riskin projekteja, jotka ovat helposti suunniteltavissa, ja kohtuullisella varmuudella saavuttavat tavoitteensa. Usein uusien asioiden aikaansaanti vaatii riskin ottamista. Riskitason tulee kuitenkin olla salkkutasolla hallittu, niin että riskiä otetaan tietoisesti.