PARHAAT KÄYTÄNNÖT
Pavel Haimi, 12.1.2012, 11:21Hyvin suunniteltu on puoliksi tehty
Valtaosa it-hankkeista ja projekteista epäonnistuu. Merkittäviä julkisia epäonnistuneita projekteja puidaan mediassa lähes viikoittain.
Tämä on jäävuoren huippu, sillä organisaatioiden sisäisiä kehitysprojekteja alkaa ja päättyy jatkuvasti. Suurin osa projekteista ei pääse tavoitteisiin tai tavoitellut hyödyt eivät realisoidu. On myös projekteja, joiden tuloksia ei voida mitata eikä arvioida. Syitä epäonnistumiseen on monia. Yksi merkittävimmistä on puutteellinen suunnittelu.
Hyvin usein projektien toteutus käynnistyy hyvin kevyen esiselvityksen perusteella. Kunnollista määrittelyä ei tehdä, ja tärkeät tekijät jäävät huomioitta.
Jo tässä vaiheessa, projektien alkutaipaleella, käynnistyy ketju, joka lopulta johtaa epäonnistumiseen. Huonosti määriteltyä projektia ei voida johtaa, toteutus ja päätöksenteko ontuu, tavoitteet ja laajuus muuttuvat lennossa, tuotantoonsiirto muuttuu sähläämiseksi – samoin jatkuva tuki.
Mitä huonosti määritelty projekti tarkoittaisi hyökkäystaistelussa?
Kuvitellaan tilanne, jossa vihollisen tukikohta täytyy valloittaa. Huonosti määritelty projekti tarkoittaa epämääräisen taistelujoukon lähettämistä huonosti tiedusteltuun kohteeseen epämääräisen varustuksen ja kaluston kera.
Taistelun vaiheet, tavoite ja tehtävät jäävät epäselväksi. Joukon johtaja on kyvytön johtamaan joukkoa, ja lopulta hyökkäys johtaa suunnattomiin tappioihin ja päättyy katastrofiin.
Oikeampi tyyli on muun muassa tiedustella hyvin tavoiteltu kohde, määritellä tarkkaan taistelevat joukot, sopia tavoitteista ja yksityiskohtaisista tehtävistä, määritellä tarvittavat ampumatarvikkeet ja kalusto.
Jokaiselle taistelijalle kerrotaan isommasta kuvasta ja lisäksi erikseen heiltä vaadituista tuloksista. Tällöin myös joukon johtaja kykenee johtamaan taistelijoita ja tehtäviä aivan eri tasolla. Tulos – paljon parempi.
Tukikohdan valloitus ei kuitenkaan yksin takaa onnistumista vaan tukikohta täytyy myös pitää.
Tässä täytyy suunnitella ja määritellä perusteellisesti niin ikään tarvittavat joukot, puolustusaseman poterot, tarvittavat ampumatarvikkeet, tehtävät, kalusto ja huoltoreitit. Puolustustaistelun johtaminen siirretään puolustusjohtamisen ammattilaiselle.
Service Design Package – kokonaissuunnitelma kehitettävästä palvelusta
Service Design Package esiteltiin ensimmäistä kertaa ITIL 3 julkaisussa. SDP on kokonaissuunnitelma kehitettävästä palvelusta (kuten taistelusuunnitelma hyökkäys- ja puolustustaistelusta). Jalostettuna ja hyvin sovellettuna väline toimii loistavasti määrittelyn, toteutuksen ja jatkuvien palveluiden tehostajana.
Service Design Package –dokumentin avulla kuvataan muun muassa:
- kehitettävä palvelu ja tavoitteet
- peruste palvelun kehittämiselle
- nykytilan prosessit
- tavoitetilan prosessit
- palvelun omistajuus
- palvelun hyödyntäjät
- palvelun käyttövolyymit
- palvelun käytettävyysvaatimukset
- palvelun riippuvuus muista palveluista
- palvelun integrointi muihin palveluihin
- palvelun tavoitteet
- vaatimukset toiminnallisuudelle
- vaatimukset teknologialle
- laskentakapasiteetti
- palvelun tekninen arkkitehtuuri
- palvelun valvonta (sis. E2E)
- palvelun lisenssit
- palvelun tietoturva
- vaatimukset tietoliikenteelle
- vaatimukset palvelun varmistamiseksi
- vaatimukset kahdentamiselle ja jatkuvuuden turvaamiselle
- vaatimukset integraatioliittymille
- vaatimukset testaamiselle
- vaatimukset palvelun operoinnille ja jatkuvalle ylläpidolle
- vaatimukset ohjeistukselle palvelun operoimiseksi
- service Deskin ohjeistus
- vaatimukset jatkuvan tuen johtamiselle
- vaatimukset jatkuvan tuen osaamiselle
- vaatimukset hankinnoille ja sopimuksille
- vaiheistus
Yllä oleva luettelo on otos ja soveltava esimerkki Service Design Package -dokumentin sisällöstä. Dokumentin laatiminen varmistaa, että kaikki tekijät tulevat huomioiduiksi.
Valmiista kuvauksesta johdetaan tarkemmat määrittelyasiakirjat (Functional Design Document ja Technical Design Document), projektisuunnitelma, tehtäväluettelo ja jatkuvan palvelun suunnitelma.
Service Design Package kuvaa perusteellisesti tavoitellut lopputulokset ja liimaa hyökkäys- ja puolustustaistelun yhtenäiseksi kokonaisuudeksi.
Oikeampi metafora tästä "oikeasta" tavasta lienee vihollisen leirin tarkkailu ja hyökkäyksen suunnittelu jota tehdään kaukana kentältä kuukausien tai jopa vuosien ajan. Kun hyökkäyksen hetki koittaa, on vihollinen jo aikaa sitten siirtynyt muualle. Hyökkäys kuitenkin viedään loppuun asti tarkalleen suunnitelman mukaisesti koska näin on päätetty.
Tällähän se on tuhottu jo vaikka kuinka monesti?
Hyvin suunniteltu tarkoittaa oikeasti sitä, että tiedetään mihin pyritään ja osataan kommunikoida se. Sitten pitää osata muuttaa taktiikkaa ja menetelmiä tavoitteen saavuttamiseksi.
JULHa-hankkeet onnistuvat säännöllisesti siksi että on kuviteltu että voi suunnitella hyvin ja pitävästi. Jo viikko projektin käynnistyisen jälkeen huomataan että se aukoton suunnittelu ei onnistunutkaan, mutta näillä on pakko mennä koska soppari tietystä toteutuksesta on tehty ja ei ole varaa uusia koko esisuunnitteluvaihetta.
Kolumnin kirjoittaja voisi vielä kertoa joitain onnistuneita projekteja missä SDP on ollut käytössä.
Ontuvia sota-analogioita jatkaakseni: erikoisyksiköthän toimivat hyvin itsenäisesti valiten parhaat tavat toimia kulloisessakin tilanteessa ja ympäristössä. Sama pätee softankehitykseen: ratkaise ongelma siihen sopivalla tavalla sen tullessa eteen.
PARHAAT KÄYTÄNNÖT
Sonja Laakkonen, 16.11.2011 15:38Voiko tietohallintolain ohittaa yksityissektorilla?
Ilmoituksesi käsitellään seuraavan työpäivän kuluessa.