TOGAF vs PM

Kuten eilen tuli luvattua laitan tähän vähän tajunnanvirtaa TOGAF:in ADM:n ja pitkälle jalostetun projektinhallinnan yhteensovittamisesta.

(Nyt on hyvä hetki lopettaa tämän postin lukeminen, jos odottaa kuulumisia. Tämä on sitä mitä mä teen työkseni, ei kuulumisia tänään, sorry! Huomenna jo voikin sitten olla jotain tosi jännää...)

Niille sinnikkäille ketkä vielä jatkavat (palkkamme tulevat tod. näk. samalta tililtä) ensin vähän orientoivaa johdattelua.
TOGAF (The Open Group Architecture Framework) on yritysarkkitehtuuri viitekehys, jonka ytimessä on arkkitehtuurin kehitysmetodi - ADM. ADM:ssä on kuvattu 8 askeleen iteraatio, miten liiketoiminnan keksimästä kehitystarpeesta on jalostettu neljä erilaista arkkitehtuuria ja valvottu arkkitehtuurien rakentaminen ratkaisuksi ja luonnollisesti dokumentoitu arkkitehtuuri ratkaisun tuotantoon siirron jälkeen.
- Kaikki projektipäälliköintiä työkseen tekevät ehkä jo huomasivatkin, että tässä on liittymiä PM:äään... kyllä, ei, ehkä?

Projektin hallinnan kannalta, IT-palvelun hankintaprojekti luultavimmin alkaa liiketoimintalähtöisestä tarpeesta (saada lisää IT-palveluja) tehdä parempaa tulosta. (Kyllä/ei/ehkä?) Tässä taitaa olla useampia tapoja keittää kahvia... mielipietiä otetaan vastaa: saappaat jalassa vai ilman?
JOS vastaus edelliseen olisi KYLLÄ, heti kun liiketoimintatarve on todettu IT-hankinnan arvoiseksi, käynnistyisi projektissa vaihe, jossa kirjataan vaatimukset IT-hankinnalle. Kunnollisten työkalujen puutteessa on voitu jopa kehittää dokumentti tms. pohjia joihin vaatimukset kirjataan. Periaatteessa organisaation voisi olla järkevää jatkaa tätä projektia, kunnes IT-hankinta on ongelmitta toimitettu ja käyttöönotettu. (Tämähän on arkipäivää tällä teollisuudenalalla). Käyttöönoton jälkeen pallo siirtyykin sitten ITIL-prosessien syövereihin, näistä voin kertoilla sitten kun haluan olla todella puuduttava.
Minkä suurempi organisaatio(ja minkä enemmän kokemusta sillä on IT-hankinnoista) sen todennäköisemmin se on jo ehtinyt kehittää varsin toimivan projektityön hallinta / kontrollointi menetelmistön. Ollaan voitu jopa perustaa projektitoimisto, josta projektitoimintaa ohjataan.

Nyt kun yritysarkkitehtuuria lähdetään rakentamaan em. organisaatioon, kohdataan varsin kiintoisia haasteita. Projektitoimisto esm. voi tuntea asemansa uhatuksi, jne. Yritysarkkitehtuurin kehittämisen kannalta kehittynyt projekti / hakekulttuuri on kuitenkin siunaus. Sehän tarkoittaa, että organisaatiossa on jo opittu työskentelemään kurinalaisesti. Mikä ON hyvä asia.

Hankinnan alun vaiheisiin TOGAF iteraation vaiheet A - D tuovat arvokasta SISÄLTÖÄ, projektin hallinnon huolehtiessa AIKATAULUSTA ja HALLINNOSTA. Eli osapuolet TÄYDENTÄVÄT toisiaan saumattomasti.
TOGAF:n näkökulmasta:
vaihe A, antaa työkalut tehdä tietoon (Baseline) perustuvat kriteerit tehdä go / no go päätös hankinnalle.
Vaiheissa B - D voidaan iteroida, kunnes vaatimukset on kasattu. (Target arkkitehtuurin määrittelemiseksi voidaan käynnistää OMA projekti.)
Vaiheissa E - F muodostetaan ratkaisun rakennuspalikoista projekteja, TOGAF auttaa siis projektinhallintaa määrittelemään sisällöllisesti mielekkään kokoisia projekteja!
Vaiheessa G TOGAF auttaa valvomaan projektin pysymistä sisällöllisesti (arkkitehtuuri) oikeilla raiteilla ja tukee taas näin projektinhallintaa varmistamaa, että tilaus tuli toimitetuksi eikä vain projektin päivät käytetyksi.
Vaiheessa H jutellaan ITIL kavereiden kanssa ja päivitetään Target arkkitehtuuri Baselineksi.

Tästähän voikin sitten seuraava iteraatio / liiketoiminnan kehittämisen tarve jatkaa. Tässä kohtaa on hyvä havaita että näinä on voinut käydä jo edellä kuvatun projektin/hankeen ollessa vielä kesken. Toisen projektin käynnistyessä, jos kaikki huomio on projekteissa, voi käydä niinkin, että kaksi samanaikaisesti pyörivää projektia päätyvät konfliktiin jos huomio on VAIN PROJEKTIN hallinnassa. Yritysarkkitehtuuri tuo tähän arkkitehtuurin näkyvyyden yli projektien, yritysarkkitehtuurissa kun katsellaan maisemia.

Tietysti on muistettava, että TOGAF ei ole oikotie onneen, vaan työkalu. (Työkaluillahan on joskus yhtä helppoa rikkoa, kuin rakentaa) Työkalujen käytössä on aina muistettava noudattaa turvallisuus määräyksiä (Älä laita sormia pyörivään terään!).

Niille tosi sinnikkäille, jotka luitte tänne asti: Miettikää ja kommentoikaa!

Kiitos