Kohtasimme viime vuonna yrityskauppojen jälkeen pakottavan tarpeen siirtyä uuteen Salesforce-ympäristöön. Salesforce on ollut meille koko olemassaolomme ajan äärimmäisen kriittinen järjestelmä, jonka ympärillä pyöritämme kaikkea paitsi laskutusta. Kuten varmaan voit jo arvata, niin edessämme oli valtava migraatiotyö, jonka yhteydessä joutuisimme tekemään mittavaa refaktorointia, arkkitehtuuriuudistusta ja uusien toiminnallisuuksien kehittämistä.

Emme siltikään osanneet odottaa, kuinka massiivisesta ja monimutkaisesta operaatiosta olisi kyse. Myöskään minä en projektipäällikkönä arvannut, kuinka sakeaan soppaan joutuisin kauhani upottamaan.

Migraatio ei ollut pelkästään tekninen uudistus, vaikka teknisenä harjoituksenakin se oli massiivinen. Kyse oli siitä, että joutuisimme toimimaan projektissa sekä toimittajan että asiakkaan roolissa. Muutos kosketti jokaista meidän työntekijää myynnistä HR:ään, joten migraatiossa oli otettava huomioon kaikkien toiveet ja vaatimukset.

Myynti ja markkinointi käyttivät Salesforcea. Koko myyntiputki uusien liidien käsittelystä myyntimahdollisuuksien hallitsemiseen ja toteuttaviin projekteihin oli mallinnettu järjestelmään. Järjestelmässä pyöritettiin myös kaikkea asiakkuudenhallintaan, liikevaihdon ennustamiseen, projektinhallintaan, työajanseurantaan ja henkilöstönhallintaan liittyvää. Lisäksi järjestelmässä oli integraatiot laskutusjärjestelmään sekä muutamaan kevyempään markkinoinnin työkaluun.

Kun totesin alussa, että käytämme Salesforcea kaikkeen paitsi laskutukseen, niin en liioitellut yhtään.

Kaaoksen keskellä

Projektin lähtötilanne oli suoraan sanottuna kaoottinen. Meillä oli käytössä ympäristö, jota oli ”puukotettu” oikealta ja vasemmalta viimeisen viidentoista vuoden ajan. Ympäristö oli näin ollen vailla yhtenäistä dokumentaatiota tai selkeää omistajuutta.

Organisaatiomme sisälsi sekä teknistä että liiketoiminnallista tietoa, mutta tieto oli ikävällä tavalla hajaantunut. Moni meidän Salesforce-ympäristöämme vuosien varrella kehittänyt asiantuntija oli jo ehtinyt lähteä talosta, kun lähdimme toteuttamaan projektia. Tehtävää siis oli paljon!

Haluatko lukea lisää muutoshankkeista ja niiden johtamisesta? Nappaa tuore Fiid-julkaisumme, jonka teemana muutosjohtaminen.

Oikeat ihmiset oikeille paikoille – tiimi kasaan

Projektin alkaessa kaikki ymmärsivät, että avain menestykseen oli dynaamisessa ja monitaitoisessa tiimissä, jonka jäsenet täydentäisivät toisiaan kuin palapelin palaset. Yhden ihmisen varaan ei voinut laskea.

Tiimiin valittiin kattava otos asiantuntijoita: mukana oli liiketoiminnan edustajia myynnistä, toimituksesta ja HR-puolelta sekä teknisiä asiantuntijoita.

Teknisen tiimin muodostivat projektipäällikkö, arkkitehti, kehittäjät ja markkinointikonsultti. Jokainen tiimiläinen toi mukanaan oman näkökulmansa ja tärkeää tietotaitoa, mikä oli elintärkeää projektin onnistumiselle. Kustakin funktiosta valittiin mukaan mainitut vastuuhenkilöt ja lisäksi kolmesta neljään avainhenkilöä tuomaan lisää asiantuntemusta ja uusia näkökulmia.

Projektipäällikkönä olin vastuussa siitä, että uusi ympäristö olisi käyttövalmis kriittisten toimintojen osalta ilman käyttökatkosta. Ratkaisuarkkitehti toimi myös hands-on -konfiguroijana ja oli myös teknisten ratkaisujen avaintekijä. Yksi kehittäjistä vastasi metadatan migraatiosta ja koodin refaktoroinnista ja toinen vastasi datan migroinnista. Markkinointikonsultti vastasi tietysti MCAE:n konfiguroinnista ja liidiputkesta.

Projektin tueksi kutsuttiin myös kourallinen muita konsultteja, jotka toivat mukanaan uusia näkökulmia ja erikoisosaamista, mikä rikastutti tiimin kokonaisvaltaista ymmärrystä ja strategista näkemystä.

Kahden suunnan lähestymistapa: top down ja bottom up

Savotta tuntui aluksi mahdottomalta, sillä tehtävää oli niin paljon. Kun ensijärkytyksestä selvittiin, aloimme hahmotella prosessia yhdessä. Lähestyimme projektia kahdesta suunnasta: top down ja bottom up. Top down -lähestymistavassa keskityimme liiketoiminnalle kriittisiin prosesseihin ja toiminnallisuuksiin. Bottom up -lähestymistavassa taas purettiin teknologia palasiksi ja käytiin läpi raakaa metadataa.

Ajatus ensimmäisestä Top down -työpajasta tuli tunnetusta deittisovelluksesta, jossa oikealle tai vasemmalle pyyhkäisemällä voi valita mieluisat kumppanit. Kasasimme järjestelmästä lähes kaikki olemassa olevat toiminnallisuudet, pinnan alla pyörivät automaatiot, objektit, sovellukset ja nappulat lapuille. Lappuja kerääntyi valtavasti.

Toiminnallisuuksien laputtaminen olikin suuri pohjatyö. Sen jälkeen pyysimme funktioiden edustajia pyyhkäisemään lappuja eri laatikoihin. Laatikot olivat Yes, No ja Redo. “Yes” tarkoitti, että toiminnallisuus on ehdottomasti tarvittava ja toimii sellaisenaan hyvin. “No” tarkoitti, ettei toiminnallisuutta tarvita jatkossa. “Redo” puolestaan merkitsi, että toiminnallisuutta tarvitaan, mutta sitä pitää kehittää paremmaksi.

Ensimmäinen kierros oli jo suuri helpotus, sillä saimme karsittua työlistalta paljon asioita.

Seuraavaksi vuorossa oli priorisointi. Ensimmäisen swaippauskierroksen jälkeen Yes- ja Redo-laatikoiden laput priorisoitiin. Nämä laput jaettiin One day, Nice to have ja Def must have at go-live -otsikoiden alle niiden kiireellisyyden pohjalta. Tulos oli toivottu: meille syntyi priorisoitu backlog.

Objekti kerrallaan

Yksi avain projektin onnistumiseen oli Skyvia-työkalu, joka on datan mäppäys- ja migrointityökalu. Skyvian avulla datan mäppäys helpottuu, ja kaikesta tehdystä migraatiosta jää jälki, toisin kuin esimerkiksi Dataloaderia käytettäessä. Tämän työkalun käyttäminen oli meille ehdottomasti oikea valinta.

Migraatiota harjoiteltiin objekti kerrallaan siten, että luotiin aina uusi sandbox-ympäristö, johon dataa migroitiin yksi objekti kerrallaan. Näin voitiin rakentaa valmis automatisoitava ketju migroitavaa dataa.

Projektin haasteeksi muodostuivat arkkitehtuurimuutokset. Kaikki “managed package” -tyyppiset toteutukset jätettiin historiaan ja kaikki halutut ominaisuudet toteutettiin kustomoituina ratkaisuina. Lisäksi osittain muutettiin prosesseja myynnin ja projektitoimituksen välillä. Uusista ominaisuuksista työllistävimpiä olivat ne, jotka liittyivät aikamerkintöjen helpottamiseen ja henkilöiden resursoinnin suunnittelutyökaluun.

Vain yksi mahdollisuus onnistua

Jo projektin alkuvaiheessa kävi selväksi, ettei vanhaa ja uutta järjestelmää voinut käyttää päällekkäin. Oli vain yksi mahdollisuus onnistua. Paineet onnistumiselle olivat siis valtavat.

Itse migraatio kesti lopulta kaksitoista tuntia. Vanha ympäristö lukittiin tuolloin käyttäjiltä.

Datamigraatiopäivä oli perjantai, joten datan tarkistusta ja viilausta oli mahdollista tehdä myös viikonlopun aikana. Kaikki sujui lopulta hyvin. Maanantaiaamuna kaikki noin yhdeksänkymmentä käyttäjää kirjautuivat uuteen ympäristöön. Korjauksia ja ei-kriittisten ominaisuuksien kehitystä jatkettiin seuraavien viikkojen aikana, ja kuukauden viimeisenä päivänä laskut lähtivät asiakkaille normaalisti. Migraatio onnistui!

Opettavainen matka itsestä, tiimistä ja työskentelytavoista

Migraatioprojektista jäi käteen useita oppeja. Ensinnäkin top down -suunnasta lähestyminen toimi hyvin. Samoin projektissa oli hyvä luetteloida kaikki ominaisuudet, sillä se selkeytti etenemistä. Oli myös kriittisen tärkeää saada mukaan eri funktioiden edustajat. Edustajista koostui timanttinen tiimi, joka oli todella merkittävässä roolissa migraation onnistumisessa.

Projekti ei ollut toki helppo, vaan aika ajoin hyvinkin stressaava. Migraation aikana oli oltava valmis tekemään kovia päätöksiä sekä hallitsemaan scopea, kun aikataulu oli jo lukittu.

Lisäksi migraatiossa datan laadun on oltava lähes täydellistä, joten sen tarkistamista ei voi liikaa korostaa. Tiimin kommunikointi oli avainasemassa, koska kaikki liittyi kaikkeen ja pienikin muutos yhdessä toiminnallisuudessa vaikutti muiden tekemiseen.

Kommunikoinnissa oli hyvä muistuttaa tiimiä myös siitä, että nyt ollaan oikeasti puhtaalla pöydällä. Oli aika hypätä rohkeasti kohti uutta, eikä miettiä, miten asiat oli aikaisemmin totuttu tekemään.

Migraatioprojekti ei ollut vain tekninen uudistus, vaan se oli matka, joka opetti meille paljon itsestämme, tiimistämme ja siitä, miten me työskentelemme. Se oli todiste siitä, että suuristakin haasteista voidaan selvitä yhtenäisenä tiiminä ja vahvalla suunnitelmalla.

Meille se oli myös silmiä avaava kokemus siitä, miltä asiat näyttävät meidän asiakkaidemme näkövinkkelistä sekä siitä, mitä kaikkea asiakkaamme joutuvat merkittävien transformaatioprojektien aikana tekemään ja kokemaan.

Vaikka teemme asiakkaidemme kanssa erittäin läheistä yhteistyötä ja olemme transformaatiohankkeissa tukena koko matkan ajan, niin emmehän me tietenkään koskaan näe kaikkea. Emmekä myöskään aina tiedä, minkälaisen paineen alla asiakkaan avainhenkilöt joutuvat työskentelemään. Yhtä kokemusta rikkaampana koemme ymmärtävämme asiakkaitamme nyt entistä paremmin.

Jos teillä on suunnitteilla tai meneillään migraatioprojekti tai jokin muu merkittävä muutoshanke, niin ota rohkeasti yhteyttä!

Onko sinulla kokemusta IT-projektista, joka meni maaliin ajallaan ja budjetissa? Onnittelut! Olet ollut mukana projektissa, jossa projektin laajuuden hallinta on ollut kunnossa.

Nuo kolme projektinhallinnan kulmakiveä, eli aika, raha ja projektin laajuus, ovat keskenään sidoksissa niin, ettei yhtä voi kasvattaa ilman toista. Silti tuntuu olevan enemmän sääntö kuin poikkeus, että projektin laajuus lähtee salakavalasti kasvamaan projektin aikana – ja kah – siinä on se pirullinen Scope Creep!

Asiakkaalle Scope Creep tarkoittaa joko venyvää aikataulua tai kasvavaa budjettia – yleensä molempia näistä. Kun kehitystyötä suunnitellaan, lähdetään liikkeelle keskimääräisistä arvioista ajan ja työmäärän suhteen. Toimittaja haluaa tehdä tarjouksen, joka on houkutteleva, mutta riittävän kokoinen toimivan järjestelmän toteuttamiseen. Ja vaikka kokemusta olisi kuinka paljon, ovat arviot silti aina arvioita, ei lupauksia tulevaisuudesta.

Toimittajalle siten pienikin Scope Creep aiheuttaa paineita pysyä aikataulussa ja budjetissa sekä projektipäällikölle harmaita hiuksia tämän estämiseen. Helposti lähdetään karsimaan “näkymättömästä työstä”, eli testaamisesta ja parhaiden käytäntöjen noudattamisesta versionhallinnan suhteen.

Tämä aiheuttaa väistämättä laadun heikkenemistä ja saa toimittajan näyttäytymään epäammattimaisena.

Vaikka suomen kielestä kovin nautinkin, ei Scope Creepille löydy sopivaa suomennosta. Suonette anteeksi temin käytön tästä eteenpäin.

Kun projektit vain paisuvat ja paisuvat

Syitä Scope Creepille on monia. Projektin koosta ja luonteesta riippuen voi olla hyvin vaikeaa arvioida etukäteen projektin kokonaiskustannuksia tai vaadittavaa aikaa maaliviivan ylittämiseen.

Monesti projekteille on kuitenkin määritelty reunaehtoja, kuten maksimibudjetti tai deadline. Oli toimitusmalli mikä hyvänsä, vesiputous tai ketterät menetelmät, pätevät niissä samat lainalaisuudet laajuuden hallinnan suhteen. Yksinkertaisuuden vuoksi käytän tässä ketterän menetelmän työkaluja ja termistöä.

Laajuuden hallinta lähtee projektin tavoitteiden määrittelystä.

Mitä tällä projektilla halutaan saavuttaa? Mihin lopputuotoksen pitäisi pystyä? Mitä toimintoja loppukäyttäjällä pitää olla käytettävissä? Mikä on riittävä taso toiminnallisuuksien automaatiotasolle tai käyttäjien käyttökokemukselle?

Näiden kysymysten vastaukset antavat pohjan työmääräarvioille. Nykyisin IT-projektien laajuutta arvioitaessa osataan jo ottaa melko hyvin huomioon kaikenlaiset projektin aikana vastaan tulevat yllätykset sekä myös testaukseen, tuotantoon viemiseen ja dokumentointiin tarvittava aika. Siitä huolimatta on vaikeaa vetää tiukkaa raja siihen, kuinka laaja projektin tulisi olla. Erityisen hankalia arvioitavia ovat integraatiot järjestelmien välillä.

Ketteryys ei tarkoita suunnitelmallisuuden puuttumista

Ketterässä toimitusmallissa ei monien ennakkoluuloista huolimatta heitetä suunnitelmilla vesilintua. Päinvastoin, jatkuva arviointi ja yksinkertainen matematiikka pitävät huolen siitä, että kokonaisuus pysyy hallussa.

Ketterän kehityksen perustyökaluihin kuuluvat backlog ja käyttäjätarinat. Backlog on työtehtävien lista, joka pitää sisällään kaikki projektiin kuuluvat tehtävät ja toiveet. Tehtävät on kirjoitettu käyttäjätarinan muodossa, jonka formaatti on muotoa <Kuka> tarvitsee <mitä> ja <miksi>. Käyttäjätarina on nimensä mukaisesti käyttäjän silmin kuvaama liiketoiminnallinen tarve, ei tekninen selostus tai tehtävä luoda nappi x paikkaan y.

Backlogilta poimitaan prioirisoinnin mukaisesti käyttäjätarinoita toteutettavaksi sprintille. Sprintti on ajanjakso, jonka aikana toimittajatiimi kehittää valitut tehtävät, jotka ovat sprintin päätteeksi valmiit siirrettäväksi tuotantoon. Sprintin pituus voidaan määritellä projektin tai kehitysmallin perusteella. Yleinen pituus on kaksi viikkoa, mutta se voi olla mitä tahansa viikon tai kuukauden välillä.

Käytit sitten apuna projektinhallintaohjelmistoa tai taulukkolaskentaa, oleellista on, että backlogin käyttäjätarinat on arvioitu työmäärän suhteen ja priorisointia tehdään jokaisen sprintin yhteydessä. Näin repsahtavaan laajuuteen ehditään puuttumaan ajoissa.

Käyttäjätarinan kuvauksessa tulee käydä ilmi valmiin määritelmä. Kun kyseinen käyttäjätarina saa hyväksyntätestauksessa vihreää valoa, se suljetaan ja toiminnallisuus siirretään sprintin päätteeksi tuotantoon. Kuulostaa yksinkertaiselta, eikö? Olisikin niin!

Valmiin määritelmä on aina tulkitsijasta kiinni, eikä pelkkä tekninen toiminta takaa asiakkaan tyytyväisyyttä. Kömpelö käyttäjäkokemus voi olla teknisesti periaatteessa toimiva, mutta niin vaikea käyttää, että se laskee käyttöastetta ja siten asiakkaan saamaa arvoa.

Vaikeissa tapauksissa onkin hyvä laskea käytettävyyden hiomiseen käytetty aika pelkän teknisen toteutuksen lisäksi. Kun pitää mielessä asiakkaan liiketoiminnallisen tavoitteen osana projektin ydintä, on helpompi tehdä oikeita valintoja laajuuden hallinnan suhteen.

Läpinäkyvyys hyödyttää kaikkia

Läpinäkyvyys projektin suunnittelun ja toimituksen osalta poistaa painetta toimittajapuolelta laajuuden hallinnassa.

Asiakkaan on helpompi ymmärtää kokonaiskuva ja riippuvaisuudet osien välillä, kun niistä viestitään avoimesti ja säännöllisesti. Ylimääräiset pyynnöt ja toiveet vähenevät, kun koko toteutus on laskettu auki lukujen valossa.

Asiakkaankin on helppo nähdä, ettei uusia toiminnallisuuksia ehditä tekemään annetussa ajassa, kun kaikki työtehtävät on arvioitu etukäteen.

Mikään määrä ruotimista käyttäjätarinoiden osalta ei riitä, jos projektin omistaja ei osaa tai halua tehdä kipeitä valintoja. Koska sitä onnistuminen toden totta vaatii. Yhden asian priorisoimista toisen edelle.

Kun pannaan kova kovaa vastaan, kaikki käyttäjätarinat eivät ole samanarvoisia. Tarpeet voivat myös muuttua projektin aikana; siksi priorisoinnin tulee olla jatkuvaa.

Toimituspuolella voit olla titteliltäsi Scrum Master tai Projektipäällikkö. Siihen ei kuitenkaan kuulu käyttäjätarinoiden priorisointia. Se on puhtaasti asiakkaan tehtävä, oli projektin sisällä titteli mikä hyvänsä. Olen todennut hyväksi välineeksi hintalapun käyttämisen, kun asiakas haluaa venyttää käyttäjätarinan sisältöä.

Asiakas: “Muuten hyvä tää toiminnallisuus mut saisko tohon jokaiselle ruudulle meidän logon kivasti vilkkuvaloilla höystettynä?”

Minä: “Saa. Karkea arvio sille on kaksi päivää. Jätetäänkö jotain pois tulevalta sprintiltä vai nostetaanko budjettia x eurolla?”

Yhtäkkiä lisäpyynnöt vähenevät kummasti, kun pienemmällekin asialle annetaan kaksi konkreettista vaihtoehtoa, joilla on seurauksia.

Konsultin tai koodarin työstä tulee käsinkosketeltavaa, eikä iso projekti ole enää vain epämääräinen musta aukko, joka imee rahaa. Olemme yhtä tiimiä, joilla on sama tavoite: saattaa projekti maaliin annetussa ajassa ja budjetissa. Ilman Scope Creepiä.