Pidin joulukuussa Talentumin intranet-seminaarissa puheenvuoron otsikolla ”Fiksu hankejohtaminen intranet-projekteissa”. Otin käsittelyyn joukon projektijohtamisen perusasioita, joiden olen nähnyt korostuvan etenkin intranet-hankkeissa.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
19.3.2012
Otin myös tietoisesti IT-talon näkökulman, koska halusin avata pääosin asiakkaista koostuvalle yleisölle sitä miten toimittajapuoli ajattelee. Palautteen perusteella onnistuin tässä erityisen hyvin, koska palaute oli hyvin kiittävää ja yhdenkin palautteen mielestä valittu kulma oli jopa ”ärsyttävä”. Jälkimmäistä kohtaa pidän hyvänä asiana, koska se oli oikeastaan preseen valitun kulman tarkoituskin. Intranet-projekteissa on paljon asioita joita hyssytellään puolin ja toisin. Siksi on molempien puolien kannalta hyvä ymmärtää toisen osapuolen näkökulmaa.
Esityksen slaidit löytyvät SlideSharesta. Slaidit kertovat otsikot ja osan tarinoista, mutta ovat enemmän tai vähemmän vain yleiskuva esityksestä.
Tässä presen kymmenestä kohdasta viisi kohtaa hieman tarkemmin avattuna.
Kohta 1: Mallinna tavoitetila tiedonhallinnan kokonaisuudesta
Tiedonhallintaa organisaatioissa on tehty monissa paikoissa pienissä täsmäprojekteissa ja kokonaiskuva on monessa paikassa hukassa. Ennenkuin ryhdytään tekemään taas uutta projektia jonka huomataan kohta olevan päällekkäinen muiden järjestelmien tai työkalujen kanssa, niin kannattaa katsoa kokonaisuutta – ja mallintaa kokonaisuus vaikka legopalikkamaiseen kuvaan. Siten, että kaikki ymmärtävät, että mitä ollaan tekemässä nyt ja millaiseen kohtaan kokonaisuudessa uusi palanen istuu. Organisaatioissa on usein intranetin lisäksi monenlaisia tiedonhallintajärjestelmiä, kuten verkkolevyt, toimintajärjestelmä, dokumenttienhallintajärjestelmä, projektinhallintajärjestelmä, toiminnanohjausjärjestelmä (jonne usein tallennetaan myös dokumentteja), palautejärjestelmä, tapahtumien hallintajärjestelmä, raportointijärjestelmä ja joskus vieläpä useita extranet-järjestelmiä. Näistä kannattaisi mallintaa yhteen näkymään vähintään keskeiset tiedonhallintatyökalut, koska usein intranet-projekteissa saatetaan tehdä korvaavia toimintoja tai rakentaa liittymiä näihin muihin järjestelmiin.
Mallinnustyössä keskeinen tehtävä on määritellä, että mitkä tiedot asuvat missäkin järjestelmässä. Jos dokumentteja tallennetaan intraan, verkkolevyille, ryhmätyötiloihin, projektityötiloihin ja extraan, niin kaaos on lopputuloksena vaikka järjestelmät olisivat täydellisiä ja projektit aikataulussa valmiina. Tiedonhallinnassa pitääkin tasapainoilla kirkonkylämäisen keskitetyn mallin ja hajautetun ”lähiökaavan” välillä. Joskus on järkevää antaa tietojen hajautua, mutta sekin pitäisi tehdä tietoisesti. Aina tulisi kuitenkin pyrkiä kirkonkylämäiseen arkkitehtuuriin jossa on selkeät roolit jokaisella osakokonaisuudella – eikä tärkeitä tietoja jouduta hajauttamaan moneen paikkaan.
Tätä työtä voisi jopa sanoa ”käyttäjälähtöiseksi tiedonhallinnan suunnitteluksi” – vaikka tässä työssä ei aina käyttäjien mielipiteiden mukaan kannata täysin mennäkään. Käyttäjät kun haluavat yleensä, että ”olisi yksi järjestelmä jolla hoituisi kaikki”. Realistisempi käyttäjiltä tuleva vaatimus on yleensä: ”haluaisin ymmärtää mihin mikäkin tieto tallennetaan, ja mistä minkäkin tiedon voi löytää”.
Kohta 2: Johda tiekartalla
Kokonaiskuvan piirtämisen jälkeen on vuorossa tunnistettujen muutostarpeiden mallintaminen tiekarttamaiseen kuvaan. Yleensä tiedonhallintaa kehitettäessä nimittäin löytyy paljon enemmän kehitettävää kuin mihin on aikaa ja rahaa lyhyellä tähtäimellä. Siksi tiekartta kannattaa tehdä hankejohtamisen avuksi, ja etenkin tiekartta kannattaa hyväksyttää johtoryhmällä. Toinen asia joka tiekartan tekemisessä on syytä muistaa on, että siihen kannattaa laittaa yhtä lailla sisäiset muutosprojektit eikä pelkästään teknologiaprojektit. Etenkin tällä tavalla tiekartasta saa tehtyä myös johtoa kiinnostavan työvälineen.
Kohta 3: Johda budjetilla
Budjetti lienee projektijohtajan tärkein seurattava asia, mutta seurannan lisäksi budjettia voi käyttää hankkeistuksen apuna ja projektin käytännön johtamisen apuna. Budjetin kautta voi esimerkiksi määrittää oman projektimallin ja jopa potentiaalisten järjestelmien listan. Etenkin jos oma budjetti on alle 20 000 euroa intranetin suunnittelulle ja toteutukselle, niin toimittajavalinnan tekeminen on huomattavasti suoraviivaisempaa kun vaihtoehtoja on olennaisesti vähemmän. Toisaalta mitä pienempi budjetti, niin sitä enemmän kannattaa panostaa kokonaiskuvan tekemiseen ja tiekarttaan – ja tekniseen toteutukseen ei kannata yli 10 000 euroa käyttää ensimmäisenä vuotena.
Jos taas budjetti liikkuu välillä 50 000 – 80 000 euroa, niin valinnanvaraa alkaa jo olemaan niin paljon, että valintaprosessiin kannattaa panostaa hieman enemmän – ja kannattaa myös varautua siihen, että tarjolla olevat ratkaisut eroavat varsin paljon toisistaan. Valittavan ratkaisun räätälöinteihin myöskään ei kannata omaa rajallista budjettia uhrata. Fiksumpaa on sijoittaa rahat käyttöönoton tukeen ja ”pienien voittojen” saamiseen siinä vaiheessa kun järjestelmää lanseerataan käyttäjille. Tekniseen toteutusprojektiin tuskin kannattaa yli 40 000 euroa käyttää.
Yli 100 000 euron budjetilla joutuukin sitten ottamaan kantaa ihan toisella tavalla siihen, että mitkä asiat kelpaavat suoraan paketista ja mitkä räätälöidään. Tosin alle 200 000 euron budjetilla ei intranet-maailmassakaan kannata räätälöintiprojektista itseään löytää, koska silläkään rahalla ei vielä suuria integraatioita ja erityissovelluksia tehdä.
Budjetin osalta kannattaa eri vaiheisiin asettaa tavoitebudjetit, ja etenkin teknisen toteutuksen budjetin osalta on syytä olla tarkkana, koska toteutusbudjetti ei saisi ylittää 60% kokonaisbudjetista. Ihanteellinen 100 000 euron kokonaisbudjetti jakautuisikin mallilla 30/10/30/30, jolloin kokonaiskuvan määritys, hankkeistus, vaatimusmäärittely ja valinnat veisivät budjetista 30 000 euroa. Teknisen toteutuksen osuus olisi 10 000 euroa + 30 000 euroa, joka jakaantuisi toiminnalliseen määrittelyyn ja tekniseen toteutukseen. Viimeinen 30 000 euron osuus jäisi käyttöönottovaiheeseen, ja käytettäisiin tukemaan sisällöntuotantoa, sisältöjen siirtoa, lanseerausta ja ensimmäisen puolen vuoden käyttäjätukea ja -koulutuksia.
Tämänkaltainen ennakkoon asetettu budjettiraami on myös olennaista viestiä omaan organisaatioon hyvissä ajoin, ja näin yhtä lailla hallita oman organisaation odotuksia tulevaa intranettia kohtaan. Asiakkaan projektipäällikön harkittavaksi jää sitten se, että kuinka paljon budjetissa on vain asiakkaan projektipäällikön tiedossa olevaa puskuria. Nyrkkisääntönä voi pitää noin 20% osuutta. Täten 100 000 euron kokonaisbudjetti pitäisi ohjausryhmän ja projektiryhmän päätöksellä olla todellisuudessa 120 000 euroa ensimmäisen vuoden ajalle. Olettaen myös, että jatkuvat ylläpito- ja tukikulut on budjetoitu erikseen esimerkiksi IT:n vuosibudjettiin.
Kohta 4: Johda aikataululla
Asiakkaan näkökulmasta aikataulu on yksi tärkeimpiä onnistumisen mittareita. Siksi on myös hyvin tärkeätä, että aikataulu on aidosti realistinen. Ylioptimistinen aikataulu ei vain yksinkertaisesti kannata. Ohjelmistotyötä on hyvin vaikea tehostaa, koska pienet tiimit ovat lähes poikkeuksetta tehokkain tapa tehdä asioita. Pienet tiimit voivat olla myös hyvin realistisia aikatauluarvioissaan, joten kannattaa ihan aidosti kysyä aikatauluarviota toimittajalta – ja kuunnella vastaus ilman hyperventilointia. Valitettavasti monilla asiakkailla on taipumus kiristää aikatauluja argumenteilla ”ei siinä niin kauan voi kestää”, vaikka usein kyse on paljon enemmän asiakkaan puolelta vaadittavasta panostuksesta kuin toteutustiimin nopeudesta. Aikataulun nopeuttamiseen asiakkaalla on oikeastaan kaksi käytännöllistä keinoa: 1) Varmistaa, että omalla projektipäälliköllä on aidosti aikaa osallistua, seurata ja selvittää avoimia asioita koko matkan ajan. 2) Ottaa aivan toteutuksen alkuun 1-2 päivää yhteistä aikaa toteutustiimin kanssa ja perehdyttää tiimi kunnolla siihen mitä ollaan tekemässä ja miksi. Tämä motivoi tiimiä ja ennenkaikkea se lisää ymmärrystä siitä mitä todella ollaan tekemässä. Tämä kertapanostus projektin alussa voi nopeuttaa itse prosessia olennaisesti kun väärinymmärryksiä itse tekemisen tavoitteesta on ratkaisevasti vähemmän.
Asiakkaan näkökulmasta paras tapa myös saada aikataulu ja laatu hallintaan alusta alkaen on aloittaa tekeminen vasta siinä kohtaa kun tarvittava tiimi on oikeasti saatavilla. Monesti asiakkaat haluavat saada projektin käyntiin parin viikon sisällä sopimuksen allekirjoituksesta, ja ilman todella hyvää tuuria tämä onnistuu hyvin harvoin. Järkevämpää on kysyä toimittajalta milloin tiimin todella saa käyttöön, ja sopia kaikki aikataulut siitä eteenpäin (esimerkiksi kunnon perehdytys tiimille on fiksua antaa vasta siinä kohtaa kun projekti on todella lähdössä tai lähtenyt käyntiin).
Asiakkaan näkökulmasta on myös hyvä puskuroida aikataulutavoitteita. IT-toimittaja kannattaa laittaa tähtäämään sisäiseen lanseerausajankohtaan, jolloin siitä lipsuminen parilla viikolla (toimittajasta tai asiakkaasta johtuen) ei vielä aiheuta hyperventilointia. Yleensäkin on hyvä käytäntö jättää vähintään yhden kuukauden puskuri projektin aikataulutavoitteeseen ja sidosryhmille viestittävän aikataulutavoitteen väliin.
Kohta 5: On vain yksi projektipäällikkö
Yksi ”valistuneen itsevaltiaan” kaltaisesti toimiva projektipäällikkö on yksi tehokkaimmista tavoista saada projekti sujumaan, niin IT-toimittajan kuin asiakkaan oman organisaation näkökulmasta. Mitä enemmän asiakkaan projektipäällikkö muistuttaa projektiassistenttia, niin sitä enemmän on yleensä tiedossa aikataulu- ja laatuongelmia. Myös projektin omistajan on syytä pysyä taustalla, ja lähinnä raivata esteitä projektipäällikön edestä – eikä puuttua käytännön tekemiseen ja toteutukseen liittyviin yksityiskohtiin. Jokaisella projektilla pitäisi asiakasorganisaatiolla kuitenkin olla aina projektin johtoryhmä (tai ohjausryhmä) jonka tehtävä on saada raportteja omalta projektipäälliköltä tasaisesti ja ohjata pitkän tähtäimen päätöksentekoa.
Asiakkaan oman työn johtamisen kannalta on usein myös järkevää eriyttää sisältöprojekti erilliseksi projektiksi. Tämän projektin projektipäällikkö voi olla eri henkilö tai sama henkilö. Sisältöprojektin eriyttäminen mahdollistaa sen edistämisen irrallaan uudistusprojektista, ja myös budjetointimielessä on yleensä järkevää pitää sisältöprojekti erillään, koska esimerkiksi migraatiot vanhoista järjestelmistä tai verkkolevyjen siivoaminen/sulkeminen voivat osoittautua olennaisesti ennakoitua työläämmiksi ja kalliimmiksi projekteiksi.
Loput otsikot löytyvät presentaatioslaideista.
Loppuun voi todeta myös, että vuonna 2011 intranet-seminaareissa otettiin vihdoin iso askel viestinnällisistä intraneteista kohti sähköisiä työpöytiä, joiden aiheena ovat viestinnällisten toimintojen lisäksi myös ryhmätyötilat, dokumenttienhallinta, hakukone ja henkilökohtaiset tietotyövälineet.
