Sitkeä valitus IT-projekteista ei koske sitä, että ne epäonnistuisivat täysin, vaikka jotkin niin tekevätkin. Kyse on siitä, että ne eivät onnistu olemaan ennustettavia. Ohjelma, joka valmistuu kuusi kuukautta myöhässä ja neljäkymmentä prosenttia budjetin yli, on vahingollinen, mutta portfolio, jossa mikä tahansa yksittäinen projekti saattaa valmistua ajallaan tai venyä vuoden, ilman luotettavaa tapaa tietää etukäteen kumpi, on syövyttävä aivan eri tavalla. Se tekee liiketoimintatason suunnittelusta mahdotonta. Se opettaa johtoa pehmustamaan jokaisen arvion ja aliarvioimaan jokaisen sitoumuksen, mikä puolestaan opettaa toimitustiimeille, että arviot ovat teatteria. Koko järjestelmä ajautuu matalan luottamuksen tasapainoon, jossa kukaan ei usko suunnitelmaan ja jokainen suojelee itseään.

Tällä on nyt suurempi merkitys kuin vuosikymmen sitten yhdestä nimenomaisesta syystä. IT-muutos ei ole enää erillinen tapahtuma, jonka liiketoiminta ajoittain sulattaa. Se on jatkuvaa, ja se on kietoutunut liikevaihtoon, sääntelyyn ja asiakaskokemukseen tavoilla, jotka jättävät vain vähän pelivaraa. Kun ydinpankkijärjestelmän migraatio venyy tai ERP-konsolidointi juuttuu paikalleen, seuraukset eivät rajoitu IT-budjetin riviin. Ne kaskadoituvat kaupallisiin sitoumuksiin, vaatimustenmukaisuuden määräaikoihin ja työn tilanneiden johtajien uskottavuuteen. Ennustamattomuuden hinta on noussut jopa siellä, missä yksittäisen epäonnistumisen hinta ei ole noussut.

Epämukava totuus on, että suuri osa ennustamattomuudesta valmistetaan heti alussa, ennen kuin ainuttakaan riviä koodia on kirjoitettu tai ainuttakaan palvelinta otettu käyttöön. Sitä valmistetaan kohtelemalla arviointia neuvotteluna, sitoutumalla laajuuteen, jota ei koskaan aidosti ymmärretty, ja omaksumalla toimitustapa, joka on valittu kulttuurisen mukavuuden eikä työn todellisen luonteen perusteella. Ennustettavuus määräytyy suurelta osin päätöksistä, jotka tehdään silloin, kun projektia on vielä halpaa muovata. Sieltä kurinalaisuuden on lähdettävä.

Perustavanlaatuisin päätös missä tahansa IT-projektissa ei ole se, mikä viitekehys otetaan käyttöön. Se on diagnoosi siitä, missä epävarmuus asuu. Karkeasti ottaen epävarmuutta toimituksessa esiintyy kahdessa muodossa, ja ne vaativat vastakkaisia vastauksia. Ensimmäinen on toteutuksen epävarmuus: tiedämme täsmälleen, mitä meidän on rakennettava, mutta sen rakentaminen on laajaa, monimutkaista tai riskialtista. Toinen on vaatimuksen epävarmuus: osaisimme rakentaa sen pätevästi, kunhan vain tietäisimme, mitä se on, mutta oikea vastaus selviää vasta todellisesta käytöstä saadun palautteen kautta. Näiden kahden sekoittaminen on useimpien menetelmiin liittyvien epäonnistumisten alkulähde.

Kun hallitseva epävarmuus koskee toteutusta ja vaatimus on aidosti vakaa, suunnitelmavetoinen toimitus ei ole jäänne, jota tarvitsisi hävetä. Se on oikea työkalu. Konesalimigraatiolla, kiinteään lakisääteiseen määrittelyyn perustuvalla sääntelyraportoinnin muutoksella tai hyvin ymmärretyn valmisohjelmiston käyttöönotolla uusissa toimipisteissä on kaikilla tiedettävissä oleva laajuus, ja ne hyötyvät valtavasti yksityiskohtaisesta etukäteissekvensoinnista, riippuvuuksien kartoituksesta ja kriittisen polun hallinnasta. Sellaisen työn teeskenteleminen löytöretkeksi tuhlaa sen ainoan edun, jonka se tarjoaa, eli kyvyn suunnitella se kunnolla.

Kun hallitseva epävarmuus koskee vaatimusta, suunnitelmavetoisesta lähestymistavasta tulee aktiivisesti haitallinen, koska se pakottaa ennenaikaiseen sitoutumiseen päätöksiin, joiden pitäisi pysyä avoimina. Tässä mukautuva toimitus ansaitsee paikkansa: lyhyet syklit, toimivat inkrementit ja tiheä kontakti todellisiin käyttäjiin muuntavat tuntemattoman tunnetuksi nopeimmalla kestävällä tahdilla. Iteroinnin tarkoitus ei ole nopeus itsessään. Se on vaatimusriskin järjestelmällistä poistamista. Tiimi, joka iteroi mutta ei koskaan altista inkrementtejään aidolle käyttäjäpalautteelle, on omaksunut rituaalin ilman mekanismia eikä saa siitä mitään.

Rehellinen kanta, ja se jota tässä artikkelissa puolustetaan, on, että useimmat merkittävät ohjelmat sisältävät molempia epävarmuuden lajeja eri suhteissa eri osiensa välillä. Kypsä harkinta ei ole julistaa koko hanketta ketteräksi tai vesiputousmalliksi vaan pilkkoa se osiin, soveltaa suunnitelmavetoista tiukkuutta siellä, missä laajuus on vakaa, ja mukautuvaa löytämistä siellä, missä se ei ole, sekä hallita niiden välistä saumaa tietoisesti. Tuossa saumassa asuu todellinen taito.

Useat kehityskulut ovat muovanneet IT-projektien johtamista viime vuosina, ja on syytä erottaa olennainen muodikkaasta. Olennaisin on siirtymä projektiajattelusta tuoteajatteluun niissä IT-maiseman osissa, jotka ovat pitkäikäisiä. Maksualusta tai asiakasportaali ei ole projekti, joka päättyy; se on tuote, joka jatkuu, jota rahoitetaan jatkuvasti ja jonka omistaa vakaa tiimi. Tuolle työn luokalle projektirakenteesta kiinteine päättymispäivineen ja tiimin hajauttamisineen valmistumisen jälkeen on tullut aktiivinen rasite, koska se optimoi luovutuksen eikä sen kestävän omistajuuden mukaan, joka pitää ohjelmiston terveenä.

Samaan aikaan, ja jossain määrin jännitteessä tuoteliikkeen kanssa, riippuvuuksien hallinnan kurinalaisuus laajassa mittakaavassa on formalisoitu. Kun organisaatiot ajavat kymmeniä tiimejä jaettua arkkitehtuuria vasten, toimituksen sitova rajoite on harvoin minkään yksittäisen tiimin tuottavuus. Se on niiden välinen koordinointikustannus: jaetut palvelut, integraatioiden sekvensointi, alustakyvykkyydet, joista useat virrat ovat riippuvaisia. Skaalatut toimitusviitekehykset ovat hyödyllisimmältä ytimeltään yritys tehdä nämä tiimien väliset riippuvuudet näkyviksi ja aikatauluttaa ne ennen kuin niistä tulee syy siihen, että kaikki ovat jumissa.

Kolmas muutos on jatkuvan toimituksen kypsyminen ja tuotantoon johtavan polun automatisointi. Kun muutoksen käyttöönotto on harvinainen, manuaalinen ja korkeariskinen tapahtuma, talous ohjaa kohti suuria eriä ja pitkiä julkaisusyklejä, mikä puolestaan ohjaa kohti raskasta etukäteissuunnittelua. Kun käyttöönotto on automatisoitu, testattu ja rutiininomainen, pienistä inkrementeistä tulee halpoja julkaista, ja koko toimituksen rytmi voi siirtyä kohti sitä tiheää palautetta, josta mukautuva työ on riippuvainen. Suuri osa siitä, mikä luetaan metodologian ansioksi, on itse asiassa tämän insinöörikyvykkyyden seurausta. Tiimi ei voi iteroida merkityksellisesti kohti arvoa, jos se pystyy julkaisemaan vain kahdesti vuodessa, riippumatta siitä, mikä viitekehys seinälle on kirjoitettu.

Ennustettava toimitus on yhtä paljon työn rakenteen ominaisuus kuin sen johtamisen. Ainoa voimakkain vipu on pilkkominen inkrementteihin, joista jokainen tuottaa jotain esiteltävää ja ihanteellisesti jotain käytettävää. Tämä ei ole projektihallinnollinen hienous. Inkrementti, joka tuottaa toimivan ohjelmiston, pakottaa integraatio- ja testauskysymykset vastattaviksi varhain ja toistuvasti sen sijaan, että ne lykättäisiin loppuvaiheeseen, jossa ne räjähtävät kaikki yhtaikaa. Klassinen big bang -integraation epäonnistuminen, jossa kuukausia erikseen rakennetut komponentit yhdistetään lopussa ja havaitaan yhteensopimattomiksi, on inkrementtien suunnittelun epäonnistuminen ennen kuin se on johtamisen epäonnistuminen.

Riippuvuusarkkitehtuuri on toinen periaate. Jokainen riippuvuus tiimien, järjestelmien tai toimittajien välillä on aikataulurajoite ja riski. Hyvä toimitussuunnittelu pyrkii minimoimaan ja sekvensoimaan nämä tietoisesti: tunnistamaan, mitkä komponentit ovat kriittisellä polulla, mitkä jaetut kyvykkyydet on oltava olemassa ennen kuin riippuvainen työ voi alkaa, ja mitkä ulkoiset sitoumukset, kuten toimittajan toimitus tai sääntelyviranomaisen hyväksyntä, ovat tiimin hallinnan ulkopuolella ja vaativat siksi varhaisinta huomiota ja varovaisinta puskurointia. Myöhään havaitut riippuvuudet ovat kalleinta lajia, koska siihen mennessä kun ne nousevat pintaan, vaihtoehdot niiden ratkaisemiseksi ovat kaventuneet.

Kolmas periaate on suunnitella peruutettavuutta silmällä pitäen siellä, missä vaatimus on epävarma, ja kestävyyttä silmällä pitäen siellä, missä se on vakiintunut. Päätökset, jotka on halpa peruuttaa, voidaan tehdä nopeasti ja tarkistaa palautteen valossa; päätökset, jotka on kallis peruuttaa, kuten järjestelmän ytimessä oleva tietomalli tai sellaisen alustan valinta, josta kaikki muu tulee riippumaan, ansaitsevat suhteettoman tarkkaa harkintaa ennen kuin ne lukitaan. Hyvin johdettu projekti käyttää huolellisen analyysinsä siellä, missä peruuttaminen on kallista, ja etenee nopeasti siellä, missä se ei ole, sen sijaan että soveltaisi yhtenäistä rituaalia jokaiseen valintaan. Näiden kahden sekoittaminen, triviaalin murehtiminen samalla kun peruuttamaton kiirehditään, on yleinen ja hiljainen ongelmien aiheuttaja.

Joustavuudeksi puettu laajuuden hiipiminen. Mukautuvaa toimitusta käytetään usein väärin luparuutuna olla koskaan lukitsematta laajuutta lainkaan. Aito iterointi hienosäätää ratkaisua kohti vakaata tavoitetta; kurinalaton muutos korvaa yhden tavoitteen toisella muutaman viikon välein ja kutsuu sitä reagointikyvyksi. Erottava tekijä on se, ovatko muutokset lähentymässä. Projekti, jossa jokainen sykli tuo lopputuloksen lähemmäs johdonmukaista tavoitetta, oppii. Projekti, jossa jokainen sykli lisää uuden tavoitteen, ei hallitse laajuutta, se hylkää sen, eikä se valmistu.

Vesimeloniraportti. Vihreä ulkoa, punainen sisältä. Tämä on luonnollinen tuote siitä, että projekteja arvioidaan ohitettujen välitavoitteiden eikä toimivan ohjelmiston ja realisoituneen arvon perusteella. Kun mittari on valmistuneiden tehtävien prosenttiosuus, tiimi voi raportoida yhdeksänkymmentä prosenttia kuukausien ajan, samalla kun se vaikea, integroiva, arvoa tuottava kymmenen prosenttia jää koskematta. Parannuskeino ei ole parempi raportointikuri. Se on sen muuttaminen, mitä mitataan, niin että edistyminen tarkoittaa esiteltäviä, testattuja ja käytettäviä inkrementtejä eikä suunnitelmaa vasten mitattua aktiivisuutta.

Riippuvuuksien kieltäminen. Tiimit suunnittelevat oman työnsä huolellisesti ja kohtelevat kaikkea rajojensa ulkopuolella jonkun toisen ongelmana, joka ratkeaa itsestään aikataulussa. Harvoin se ratkeaa. Riippuvuudet, joita projekti ei omista, ovat juuri niitä, jotka todennäköisimmin venyvät, ja niitä, joita tiimi vähiten pystyy jouduttamaan, kun ne venyvät. Ulkoisten riippuvuuksien tekeminen näkyviksi, niille omistajien osoittaminen ja niiden realistinen puskurointi on epäglamouroista työtä, joka erottaa aikataulunsa pitävät ohjelmat niistä, jotka eivät pidä.

Sidosryhmien epäselvyys. Monet projektit pyörivät kuukausia ilman selvää vastausta siihen, kuka todella päättää. Kun rahoittaja, käyttäjät ja rahoittajat haluavat hienovaraisesti eri asioita eikä yksikään vastuullinen omistaja sovita niitä yhteen, projekti imee ristiriidan sisäänsä vellomisena, käsitellen uudelleen ratkaistuja päätöksiä eikä miellyttäen ketään. Selvyys siitä, kuka omistaa lopputuloksen, ketä on kuultava ja ketä vain informoidaan, ei ole byrokratiaa. Se on mekanismi, jonka avulla projekti voi todella tehdä päätöksiä ja pitää ne tehtyinä.

Arviointi sitoumuksena. Arvio on todennäköisyyspohjainen väite epävarmasta tulevaisuudesta. Sillä hetkellä, kun sitä kohdellaan lupauksena, se lakkaa olemasta rehellinen, koska turvallisin luvattava arvio on pehmustettu, ja pehmustaminen tuhoaa sen informaation, joka arvion oli tarkoitus kantaa. Terve toimitus pitää arvioinnin ja sitoumuksen erillään: arviot ohjaavat suunnittelua avoimesti, ja sitoumukset tehdään tietoisesti, epävarmuus tunnustaen eikä siitä neuvotellen.

Nashuan lähestymistapa IT-projektien johtamiseen alkaa diagnoosista, ei menetelmästä. Ennen kuin suosittelemme mitään toimitusmallia, pyrimme selvittämään, missä tietyn ohjelman epävarmuus todella asuu, komponentti komponentilta, koska tuo lukema määrää kaiken jatkon. Tämä on tarkoituksellisesti epämuodikasta työtä. Se vastustaa halua julistaa yksi metodologia koko maisemalle ja hyväksyy sen sijaan, että ohjelma saattaa tarvita suunnitelmavetoista tiukkuutta vakaalle, riippuvuuksia täynnä olevalle ytimelleen ja mukautuvaa löytämistä niille osille, joiden vaatimuksia vielä opitaan. Hallitsemme näiden tilojen välistä saumaa ensiluokkaisena huolenaiheena emmekä jälkiajatuksena.

Toteutuksessa pidämme kiinni pienestä joukosta kompromissittomia kurinalaisuuksia. Inkrementit suunnitellaan tuottamaan toimivaa ja testattua ohjelmistoa varhain ja usein, niin että integraatioriski kohdataan jatkuvasti eikä sitä lykätä. Riippuvuudet, erityisesti tiimin hallinnan ulkopuoliset, tehdään näkyviksi, niille osoitetaan omistaja ja ne puskuroidaan alusta alkaen. Laajuutta hallitaan johdonmukaista tavoitetta vasten, ja muutos otetaan vastaan siellä, missä se lähentyy tuota tavoitetta, ja haastetaan siellä, missä se vain laajentaa sitä. Ja pidämme arvioinnin rehellisenä erottamalla sen sitoumuksesta, niin että suunnitelmat kantavat todellista informaatiota eivätkä puolustavaa pehmustusta. Ennen kaikkea arvioimme edistymistä esiteltävän toimivan ohjelmiston ja realisoituneen arvon todisteiden perusteella, emme ohitettujen välitavoitteiden lukumäärän perusteella, koska jälkimmäistä on helppo väärentää ja edellistä ei.

Otamme myös vakavasti projektin inhimillisen arkkitehtuurin: sen selvittämisen, kuka omistaa lopputuloksen, kuka päättää ja miten nuo päätökset pidetään tehtyinä. Suuri osa siitä, mikä näyttää toimituksen epäonnistumiselta, on itse asiassa ratkaisematonta sidosryhmien epäselvyyttä, joka ilmenee vellomisena, ja kohtelemme vastuunjaon selkeyttämistä ensiluokkaisena toimitustyönä emmekä hallintorasitteena, joka pitäisi minimoida.

Ero, jonka Nashua tuo, ei ole omistusoikeudellinen menetelmä, joka lupaa saada epävarmuuden katoamaan. Sellaista menetelmää ei ole olemassa, ja yritykset, jotka väittävät toisin, myyvät mukavuutta eivätkä toimitusta. Ero on johdonmukaisesti sovellettu harkinta: halukkuus diagnosoida rehellisesti, valita suunnitelmavetoinen ja mukautuva toimitus niiden ansioiden eikä muodin perusteella, tehdä riippuvuudet ja vastuunjako näkyviksi ennen kuin niistä tulee tekosyitä, ja vaatia läpi koko työn, että projekti on sen arvoinen, mitä se antaa käyttäjien käsiin ja realisoi arvona, ei sen, mitä se raportoi suunnitelmaa vasten. Tuo harkinta on tulosta siitä, että on toimittanut riittävästi ohjelmia tietääkseen, missä ne todella menevät pieleen.

Tähän liittyy myös käytännöllinen seuraus, joka muuttaa sen, mitä työn sallitaan olettaa. Kun toimeksianto vaatii kyvykkyyttä, jota ei vielä ole olemassa, sen ei tarvitse odottaa hankintasykliä tai toimittajan tiekarttaa. enterprise platform on rakennettu mukautumaan lähes mihin tahansa ominaisuuteen ripeästi, agenttipohjaisen kehitystyön avulla: tarvittava kuvataan selkokielellä ja tuotetaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alaisena, niin että nopeus ei koskaan tule johdonmukaisuuden, tietoturvan tai hallinnan kustannuksella. Vaikutus on strateginen eikä vain kätevä. Se siirtää tee tai osta -rajaa, pitää optionaalisuuden halpana ja antaa arkkitehtuurin seurata strategiaa sen sijaan, että strategia taipuisi sen mukaan, mitä sattui olemaan hyllyllä.

Se, mikä sitoo tämän yhteen, on kieltäytyminen antamasta toimituksen muuttua teatteriksi. On suoraviivaista pyörittää projektia, joka näyttää hyvin johdetulta, tuottaa itsevarmaa raportointia ja täyttää jokaisen hallinnollisen tarkistuspisteen samalla kun se hiljaa epäonnistuu tuottamaan mitään arvokasta. On paljon vaikeampaa, ja paljon harvinaisempaa, pyörittää sellaista, joka pysyy rehellisenä epävarmuudestaan, kohtaa riskinsä varhain, pitää laajuutensa lähentymässä ja mittaa itseään toimivia lopputuloksia vasten. Tuolle vaikeammalle polulle Nashua sitoutuu, koska se on ainoa, joka tekee IT-muutoksesta aidosti ennustettavan eikä vain hyvin dokumentoidun. Organisaatiot, joiden kanssa työskentelemme, oppivat luottamaan eivät lupaukseen siitä, ettei mikään mene pieleen, vaan varmuuteen siitä, että kun jokin menee, se nähdään varhain, nimetään selkeästi ja hoidetaan silloin, kun se on vielä halpaa korjata.