Blogi

Kohti onnistunutta kehitysprojektia, osa 9: Rikkinäinen puhelin ei toimi

Maanantai 29.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgKehityshankkeelle perustetaan johto- ja ohjausryhmät yleensä vasta siinä vaiheessa, kun nimet IT-palvelutalon tai -talojen kanssa ovat pahvissa. IT-palvelutaloilla on taipumus ajatella, että ylin päättävä elin miehitetään tasapuolisesti asiakkaan ja toimittajan edustajilla sekä mahdollisesti vielä kolmannen osapuolen, asiakkaan konsulttitoimiston, edustajalla. Todellisuudessa tällainen ryhmä on ohjausryhmä ja sen yli menee vielä pelkästään asiakkaan edustajista koottu johtoryhmä.

Jos projektia on valmisteltu pitkään, valmistelu tuskin on tehty yhden ihmisen voimin. Yleensä sitä on ollut tekemässä ryhmä, joka vastaa hyvinkin toteutusvaiheen ohjaus- tai johtoryhmää. Ikävä kyllä, usein henkilöt vaihtuvat ja se on sääli. Kari Leppälä toteaa kirjassaan Projektitoiminnan musta kirja, että kysymyksessä on yksi projektitoiminnan käsittämättömyyksistä.

Kun ihmiset vaihtuvat, tietojen siirto jää vähäiseksi. Kapulanvaihto jää tekemättä, eikä viesti mene perille. Valmistelun tehneet tietävät projektin tavoitteista ja taustoista paljon sellaista, joka olisi toteuttavalle porukalle hyödyllistä.

Projektiryhmäkin kasvaa, kun toteutus alkaa. Niinpä projektiin tulee paljon sellaista väkeä, jolla on kapea ja jopa vääristynyt käsitys projektin tavoitteista ja taustoista. Näiden asioiden tietoisuuteen viemiseen kannattaa kuitenkin käyttää aikaa ja vaivaa. Muuten jossain vaiheessa pidetään intohimoisesti kiinni ei-tärkeistä tavoitteista ja päästetään irti tärkeistä.

Pidä siis huoli, että linkki strategiaan ymmärretään vielä toteutus- ja käyttöönottovaiheissakin, samoinkuin vastaus kysymykseen: "Mikä ongelma tällä yritetään ratkaista?"

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, johtoryhmä, avainhenkilöt

Kohti onnistunutta kehitysprojektia, osa 8: Ota huomioon sopimusneuvotteluissa

Maanantai 22.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgVain harva kehityshanke voidaan toteuttaa ilman sopimuksia. Usein sopimus IT-palvelutalon kanssa on keskeisessä osassa kehityshankkeen toteutusta.

Sopimusneuvotteluissa kaksi osapuolta on eripuolilla pöytää. Asiakas ostaa palveluja ja tuotteita sekä toimittaja myy palveluja ja tuotteita. Kolmantena osapuolena voi olla asiakkaan valintakonsultti tai projektinomistajan/johtajan mentori. Mitä pienemmästä asiakasyrityksestä on kysymys, sitä harvemmin tällaiset sopimusneuvottelut tulevat vastaan ja sitä fiksumpaa on käyttää apuna ulkopuolista auttajaa. Itse olen toiminut tällaisena apuna useita kertoja.

Sopimusneuvottelutilanteessa - niin kuin koko kehitysprojektissa - IT-toimittaja pitää perustellusti asiakasta oman liiketoimintansa ja toimintaympäristönsä asiantuntijana. Näin tietysti onkin, joskaan läheskään aina asiakkaan edustajat eivät tunne edustamaansa yritystä läpikotaisin, eikä sitä, miten yritystä aiotaan tai voisi tulevaisuudessa kehittää.

Vastaavasti asiakas pitää IT-toimittajaa tarjoamiensa tuotteiden ja palvelujen asiantuntijoina. Näinkään ei aina ole. Asiantuntemusta on monen tasoista ja totuus tasosta voi joskus olla aika karu. Joka tapauksessa nämä ovat lähtöasetelmat ja niissä esiintyvät epävarmuudet luovat pohjaa sopimusneuvottelujen ja sopimuksen täytäntöönpanon ongelmille.

Sopimusehdotus, josta neuvotteluissa keskustellaan, on useimmiten toimittajan laatima. Se on tehty toimittajan näkökulmasta. Asiakas ja asiakkaan tilanne on sopimuksessa kuvattu staattisena ikään kuin asiakas ei kehittyisi tai muuttuisi mitenkään sopimuksen soveltamisperiodin aikana. Kun ottaa huomioon, että sopimusnivaskaan kuuluu varsin pitkällä tähtäimellä sovellettavia osia, kuten tuki- ja ylläpitosopimuksia, kysymyksessä on puute.

Se, mitä sopimus aina sisältää, on saman tien hankittavien tuotteiden ja palvelujen hinnat ja ylläpitomaksut. Joskus ylläpitomaksuja ja lisähankintojen hintoja on sidottu tai jäädytetty joitakin vuosia eteenpäin. Harvemmin on otettu huomioon, että asiakas voi joutua supistamaan toimintaansa tai myymään osiaan pois. Kuitenkin nämä ovat aivan normaalia yritystoimintaa.

Yrityksen osan, etenkin tytäryhtiön, myyminen on tietojärjestelmien käyttöoikeuslisenssien ja sopimusten näkökulmasta vaarallista puuhaa, ellei asioita ole otettu huomioon jo sopimuksia neuvoteltaessa. Nimittäin, kun tytäryhtiö myydään, on se saman tien käyttöoikeuslisenssien osalta sopimuksettomassa tilassa. Tietojärjestelmiä ei saa käyttää ja usein yrityskauppa on sovittu ostajan kanssa siten, että liiketoiminta jatkuu saumattomasti omistajanvaihdoksesta huolimatta.

Ongelma on ratkaistavissa kahdella tapaa. Toisessa asiakas sopii IT-palvelutalon (ja sen päämiesten) kanssa ennen yrityskauppaa väliaikaisesta käytöstä. Tämä edellyttää IT-palvelutalon edustajien sisällyttämistä sisäpiiriin ja pahimmillaan kymmeniä neuvotteluja lyhyessä ajassa ja lähtöasetelma asiakkaan puolelta on huono. Tämäkin kuuluu valitettavasti koettujen asioiden piiriin.

Toinen tapa on sopia jo alkuperäisiä sopimuksia tehtäessä väliaikaisen käytön periaatteista ja hinnoista. Tällä vältetään vähintään sopimuksettomaan tilaan joutuminen, kiireiset neuvottelut ennen yrityskauppaa ja parhaassa tapauksessa mahdollistetaan ilman lisäneuvotteluja ja -sopimuksia yrityskaupan toimeenpano. Tällaisia erikoisehtoja olen päässyt neuvottelemaan muutaman asiakkaan sopimuksiin ja ainakin yksi raportoi, että tuleva yritysjärjestely helpottui olennaisesti, kun se oli alunperinkin otettu huomioon sopimuksia laadittaessa.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, sopimusneuvottelu

Kohti onnistunutta kehitysprojektia, osa 7: Yhteensopivuusongelmat ovat yleisiä

Maanantai 15.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgYritysten ja yhteisöjen tietojärjestelmäkokonaisuudet ovat yhä monimutkaisempia, mikä vaikeuttaa uusien kehityshankkeiden läpivientiä.

Kirjassa Miksi tietojärjestelmäprojekti epäonnistuu? jaoin yhteensopivuusongelmat kahteen luokkaan: käyttöönotettavan tietojärjestelmän yhteensopivuus yrityksen tai yhteisön kokonaisarkkitehtuuriin ja käyttöönotettavan tietojärjestelmäkokonaisuuden sisäiset yhteensopivuusongelmat. Kolmantena on tietysti vielä käyttöönotettavan tietojärjestelmän yhteensopivuus käyttäjiin, mutta käsitellään sitä erikseen muutosjohtamisen yhteydessä.

Kokonaisarkkitehtuurityö on sitä, että luetellaan organisaation periaatteet ja valinnat sekä niiden suhteet toisiinsa. Tehokkaassa ympäristössä periaatteet ja valinnat tukevat toisiaan niin, että niiden määrä on pienin mahdollinen. Usein tarvitaan kuitenkin vaihtoehtoisia, rinnakkaisia valintoja, jotta kaikki haluttu mahdollistuu.

Kokonaisarkkitehtuurityöhön kuuluu myös olemassa olevan kokonaisarkkitehtuurin kelpoisuuden tarkistaminen aika ajoin. Minkä ohitse aika on ajanut, mikä ei vastaa enään tarkoitustaan, mihin kohdistuu muutospaineita? Kokonaisarkkitehtuuria ei pidä hakata kiveen.

Toinen olennainen asia on kokonaisarkkitehtuurin poikkeusten käsittely. Onko kokonaisarkkitehtuurilla vain ohjaava vaikutus? Silloin kaikki saattavat tehdä miten huvittaa, jolloin poikkeuksiakaan ei tarvitse käsitellä. Lopputulos on sekamelska. Tai onko sillä määräävä vaikutus? Jos näin, poikkeuksia pitää olla mahdollista tehdä, mutta ne vaativat käsittelyn. Silloin kehityshankkeiden tarvitsevat poikkeukset kokonaisarkkitehtuuriin vaativat ja saavat arvoisensa käsittelyn.

Myyjät lupaavat helposti semmoistakin, mikä ei onnistu. He eivät välttämättä ole lunastamassa aikanaan lupauksiaan, vaan sen tekee toimittamista tekevä lunastusosasto. Niinpä kannattaa kuunnella omia ja toimittajan asiantuntijoita herkällä korvalla. Jos asiantuntija sanoo: "Kyllä se periaatteessa onnistuu", se ei tarkoita, että "kyllä se onnistuu", vaan, että "ei se käytännössä onnistu".

Yhteensopivuuskysymyksiin kannattaa suhtautua vakavasti.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, arkkitehtuuri

Kohti onnistunutta kehitysprojektia, osa 6: Vältä räätälöintejä!

Maanantai 8.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgKirjan Miksi tietojärjestelmäprojekti epäonnistuu? haastattelujen tekemisen yhteydessä ja yrityksiä tietojärjestelmäprojektien valmistelussa auttaessani sain kuulla kauhutarinoita loppuun asti räätälöidyistä valmisohjelmistoista. Siis siitä, että valmisohjelmiston käyttöönottoprojektissa järjestelmää puukotettiin niin paljon, että edes projektinaikainen - saati käytönaikainen - versionvaihto ei enää onnistunut.

Olenkin sanonut, että on hetteisellä tietojärjestelmien käyttöönoton suolla on kaksi reittiä, jotka ovat suhteellisen turvallisia: (koeteltujen) valmisohjelmistojen käyttöönotto ilman räätälöintejä ja ohjelmointiprojekti. Näiden välissä on upottava räätälöintirämeikkö, jolle ei kannata mennä.

Valmisohjelmiston soveltuvuuden vertailussa usein mieleen hiipii ajatus, että "tämä olisi meille sopiva, jos tuo ja tuo asia muutettaisiin". Seis! Nyt on nirvana-virhepäätelmä lähellä! Nirvanahan houkuttelee meidät etsimään täydellistä ratkaisua ja hylkäämään kaikki tilannetta parantavat mutta epätäydelliset ratkaisut.

Parempi tapa on miettiä, onko tarjolla oleva valmisratkaisu käyttöönotettavissa sellaisenaan. Tuhoaako jokin puute kilpailukykymme? Jos tuhoaa, ratkaisu ei ole oikea meille. Mutta muussa tapauksessa valmisjärjestelmä on mahdollinen ilman räätälöintejä.

Jos omat vaatimukset ovat "ihan aikuisen oikeasti" niin erikoisia, että mikään valmisohjelmisto ei niihin vastaa, voi olla ohjelmointiprojektin eli kokonaan uuden tietojärjestelmän kehitysprojektin paikka. Sen lainalaisuudet ovat osin toiset kuin valmisjärjestelmän käyttöönotossa. Yhteistä on nirvana. Pitää välttää ajatusta, että "kaiken luvatun on oltava valmista heti kerralla" ja varauduttava vaiheittaiseen käyttöönottoon. Sekin on muutosjohtamisen paikka.

Ohjelmointiprojektissa on omat vaikeutensa ja riskinsä. Valmista ei siinäkään välttämättä tule, vaikka rahaa kuluu. Lisäksi kaava, jolla 80 % ominaisuuksista saadaan 20 %:lla kuluista ja 95 % 50 %:lla, panee miettimään product backlogin vihoviimeisten tekemisten takaisinmaksuaikaa.

Joka tapauksessa on varauduttava vaikeuksiin ja muutosjohtamiseen. Varautuminen on viisautta, ei vaikeuksien esiin manaamista.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, räätälöinti, standardiohjelmisto

Kohti onnistunutta kehitysprojektia, osa 5: Onko ratkaisu etukäteen valittu?

Maanantai 1.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgTarjolla oleviin ratkaisuihin - niin tietoteknisiin kuin muihinkin - on helppo ihastua ja jopa rakastua. Ihastuminen ja rakastuminen ovat monissa yhteyksissä hyvä asia, mutta kehitysprojektissa näin ei välttämättä ole. Uskomme helposti, että ihastumisen tai rakastumisen kohde on ainoa vaihtoehto, joka tekee meidät onnellisiksi. Se estää meitä tutkimasta vaihtoehtoja. edessä on vaihtoehdottomuus.

Ystävän tai tuttavan hyvät kokemukset omassa ympäristössään nyt meillekin tarjolla olevasta ratkaisusta saattavat harhauttamaan meidät uskomaan, että juuri tuo sama on meillekin saatava. Peliin voi astua myös kilpailuhenki, jonka mukaan kyllä meilläkin tuo juttu otetaan käyttöön. Myös myyjät ovat hyviä saamaan meidät uskomaan, että heidän tarjoamansa tuote on paras ratkaisu.

Jos ratkaisu valitaan etukäteen, kaikki vaihtoehtojen tutkimiset ovat turhia. Konseptointi voi olla turhaa, ja helposti projektin valmisteluun osallistuva henkilökunta turhautuu. Selviytyminen edellyttää asennemuutosta, jossa unohdetaan vaihtoehdot ja aletaan miettiä, mitä valitulla ratkaisulla voidaan tehdä ja miten.

Jos on onnea, lopputuloksena voi olla onnistunut lopputulos. Osin tämä riippuu siitä, kuinka projektiorganisaatio ja liiketoimintajohto sitoutuu ennalta valittuun ratkaisuun. Jos sitoutumista ei ole, projekti kannattaa lopettaa heti. Asiaan vaikuttaa myös projektin koko. Jos projekti on laajuudeltaan pieni ja nopea, onnistumisen mahdollisuudet tässäkin tapauksessa ovat paremmat, varsinkin jos ratkaisu osoittautuu käyttöönottovaiheen jälkeen hyväksi.

Parempi vaihtoehto on, että projektin valmistelu viedään läpi vaihtoehtoja tutkien. Mietitään, missä on yrityksen kilpailuetu nyt ja tulevaisuudessa, ja varmistetaan, että näitä ei projektin lopputulosten käyttöönoton myötä menetetä. Ratkaisun tarvitsee muilta osin olla vain riittävä, joskin silloin on varauduttava isoon muutosjohtamiseen.

Ratkaisun kiinnittäminen aikaisessa vaiheessa on kuin oikopolku. Monet suunnistajat tietävät, että harvoin oikopolku säästää aikaa. Usein se on harhapolku.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, toimintatapamuutos, muutosjohtaminen