Aiheeseen liittyvät linkit:
- Etsi Robyn LinkedInistä
- Seuraa Robynia Twitterissä
- Seuraa Robynia Instagramissa
- Kuinka kehittää teknisiä taitoja: 5 tapaa projektipäällikölle kehittää osaamistaan
- Lue lisää projektin laajuuslausuman kirjoittamisesta (esimerkkien kera)
- Kuinka rakentaa asiakkaan luottamus näillä asiakkaan perehdytysstrategioilla
- Digitaalinen käyttöönotto: mallit, esimerkit, haasteet ja vinkit
- Ryhdy Beyoncé-tason tehokkaaksi näillä viidellä niksillä
- Digitaalisen projektipäällikön podcast – Apple Podcasts
- Projektinhallintakoulutus
- Liity digitaalisten projektipäälliköiden yhteisöön
Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmiston avulla. Anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole aina täysin tarkka.
Ben Aston:
Olet hermostunut ja pitelet puhelinta kylmän hien vallassa. Asiakas on vihainen. Hän uhkaa puhelimessa lopettaa projektin eikä maksaa työstä. Ja tähän asti kaikki on sujunut todella hyvin. Hän oli täysin rento, ja niin olit sinäkin. Hän halusi sivustonsa uudistettavan. Kuulosti yksinkertaiselta. Etkä oikeastaan vaivautunut kirjoittamaan mitään ylös, koska… no, tuntui vain siltä, että kaikki ymmärsivät asian. Kaikki olivat rentoja, mutta nyt eivät enää ole. He oikeastaan luulivat saavansa uudelleenbrändäyksen tämän uudistetun verkkosivuston lisäksi. Nyt vatsasi on solmussa, koska tiedät mokanneesi tämän. Mitään ei kirjoitettu ylös, ja kyse on heidän sanastaan sinun sanaasi vastaan. Olen jo stressaantunut pelkästään tämän sanomisesta. Jos siis haluat paljon vähemmän stressiä, kuuntele tätä podcastia ja selvitä, miksi laajuusmäärittelyt ovat niin tärkeitä, miten niitä kirjoitetaan ja miten niitä käytetään projektissa.
Kiitos, että kuuntelet. Olen Ben Aston, Digital Project Managerin perustaja. Tervetuloa DPM-podcastiin. Tehtävämme on auttaa projektipäälliköitä onnistumaan ja projekteja hallinnoivia ihmisiä toimittamaan parempia projekteja. Olemme täällä auttamassa sinua viemään projektiosaamisesi seuraavalle tasolle. Tutustu osoitteeseen thedigitalprojectmanager.com ja lue jäsenyyden kautta tarjoamastamme koulutuksesta ja resursseista. Tätä podcastia tukee Clarizen, yritysten projektien ja projektisalkkujen hallintaohjelmistojen johtava toimittaja. Vieraile osoitteessa Clarizen.com ja lue lisää.
Tänään seurassani on Robyn. Robyn on yksi DPM:n vakituisista asiantuntijoista. Kätevästi hän asuu aivan lähistöllä. Hän pitää emojeista, listojen tekemisestä ja pennuista. Hän on kokiksi kouluttautunut projektipäällikkö, jolla on yli kymmenen vuoden kokemus projektinhallinnasta toimistoissa ja startup-yrityksissä. Hän on myös pian paremmin käytettävissä toimeksiantotöihin. Jos siis etsit sopimusperusteista projektipäällikköä, etsi hänet LinkedInistä. Robyn, kiitos paljon, että liityit seuraamme tänään.
Robyn Birkedal:
Hei Ben. On aina mukava olla kanssasi.
Ben Aston:
Haluan aloittaa palaamalla listojen tekemiseen ja pentuihin. Oletko tehnyt tänään listan?
Robyn Birkedal:
Olen. Tämä kuulostaa todella nörtiltä, mutta minulla on yksi lista päivän tärkeimmistä tavoitteista, yksi lista suunnittelijassani ja lisäksi Google-kalenteri. Tarvitsen siis ilmeisesti kolme erilaista listaa kerrallaan. Et näe takanani olevaa muistilappuseinääni, joka on rikospaikkani.
Ben Aston:
Se on siis listojen taka-arkisto.
Robyn Birkedal:
Eri kategorioissa olevia asioita, joita yritän saavuttaa henkilökohtaisesti ja ammatillisesti, tai vain erilaisia sisältöideoita sinulle.
Ben Aston:
Onko sinulla myös pentu seurassasi?
Robyn Birkedal:
Minulla on kahdeksanvuotias pentuni. Rakastan tietenkin koiria paljon enemmän kuin kissoja, ja kaikki voivat väittää vastaan. Emojit ovat viime aikoina tuntuneet vähemmän innostavilta. Mutta taisin tarkoittaa juuri tuota ilmettä.
Ben Aston:
Minä olin aivan tuollainen viime vuonna.
Robyn Birkedal:
En tiedä.
Ben Aston:
Listat ovat siis sinulle selvästi tärkeitä. Löydätkö niistä inspiraatiota? Olen utelias tietämään, mistä saat inspiraatiota. Mitä luet tai kulutat juuri nyt saadaksesi inspiraatiota ja pysyäksesi sen avulla liikkeessä?
Robyn Birkedal:
Voi, tämä on hyvä kysymys. Voisin puhua tästä puoli tuntia juuri nyt. Digital Project Manager on tietenkin jatkuva inspiraation lähde. Pidin hetken taukoa siitä, että olin aktiivisesti mukana Slack-yhteisössä, ja nyt palattuani kaipasin monia siellä olevia ystäviäni. Se on ollut todella ilahduttavaa, samoin kuin paikalliset ystäväni ja yhteisöni. Haluan kuitenkin nostaa esiin yhden todella hienon Portlandin yhteisöryhmän, jossa olen ollut vuosien ajan mukana. Sen nimi on PDXWIT eli Portland Women in Technology. Arvostan todella yhteisöä, joka järjestää hyvin organisoituja ja laadukkaita taitojen kehittämiseen keskittyviä tapahtumia, mentorointia ja pääsyn työpaikkoihin yhteisöissä. He ovat opettaneet minulle paljon monimuotoisuudesta ja osallisuudesta. Kannustan siis teitä kaikkia luomaan jotakin vastaavaa tai tutustumaan heihin osoitteessa pdxwit.org.
Ben Aston:
Hienoa. Missä yrität kehittyä? Meillä kaikilla on tällä hetkellä hieman enemmän aikaa. Minusta tuntuu, että minulle tarjotaan jatkuvasti mestarikursseja, kuntoilua ja kaikenlaista muuta. Kun ajattelet sitä, mikä inspiroi sinua, mitä haluaisit tehdä? Työskenteletkö uuden harrastuksen parissa, opetteletko uutta ohjelmointikieltä tai paneudutko johonkin muuhun? Mitä teet?
Robyn Birkedal:
En ole työskennellyt Drupalin parissa noin seitsemään vuoteen, joten olen viime aikoina yrittänyt ottaa kiinni siitä, missä sen kanssa mennään. Muuten ajattelen tätä: Ben, olet tuntenut minut vuosia, ja tämä tuntuu melkein aidolta salaisuudelta, jonka jaan kanssasi ääneen. Harkitsen nimittäin eri sertifiointien suorittamista. Esimerkiksi PMP-sertifikaatin hankkimista tai jonkin turvallisen menetelmän opiskelua. En edes tiedä vielä tarkalleen, mistä siinä on kyse, mutta tutkin, haluanko tehdä sen jatkossa. Haluan tutustua paremmin näihin menetelmiin sen sijaan, että pysyttelisin vain tutussa.
Ben Aston:
Hienoa. Onnea matkaan. Oletko löytänyt viime aikoina jotakin muuta, joka tekee elämästäsi parempaa? Mikä pieni asia tuo hymyn kasvoillesi tai hetken iloa?
Robyn Birkedal:
Tämäkin on hieman noloa. En tiedä, miksi olen tänään niin hermostunut, mutta olen todella nauttinut kotona työskentelystä. Taustalla pyörii YouTube TV:stä yksi kanava, johon minulla on tilaus. Se on käytännössä sataprosenttisesti surffauskanava. Portlandissa asuessani rannalle kestää puolitoista tuntia. En ole surffaaja enkä tiedä surffauksesta mitään, mutta olen todella nauttinut sen katselusta. Taustalla pyörii ilmeisesti tunnelmallinen surffaus-tv:n mestaruuskilpailu, ja olen nyt aivan ihastunut moniin ihmisiin, kuten Andy Ironsiin, sekä Kelly Slaterin tapaukseen. Olen oppinut siitä paljon, mikä on oudoin viimeaikainen asia, joka on tehnyt elämästäni paremman.
Ben Aston:
Kuka on suosikkisurffaajasi?
Robyn Birkedal:
Ehdottomasti Kelly Slater.
Ben Aston:
He olivat täällä. Se oli hyvä alku pelastusvaihtoehdoksi. Minun pieni julkkishetkeni oli se, että surffasin Kelly Slaterin kanssa Havaijilla.
Robyn Birkedal:
Et voi vain sanoa noin. Se ei toimi.
Ben Aston:
Olimme tulossa vedestä ja hän menossa veteen tyttöystävänsä kanssa. Kohtasimme ja sanoimme: hei Kelly. Joten surffasimme hänen kanssaan.
Robyn Birkedal:
Olitte siis vedessä samaan aikaan.
Ben Aston:
Niin, tarkoitan, että…
Robyn Birkedal:
Kuulostaa siltä, että olitte siellä suurten aaltojen keskellä Kellyn kanssa.
Ben Aston:
Niin. Siksi se on julkkishetkeni. Palataan kuitenkin vakavaan aiheeseen ja rannalta laajuusmäärittelyihin. Aloitetaan miksi-kysymyksestä. Yritin alussa kuvata, miksi laajuusmäärittelyistä pitäisi välittää. Projektit menevät pieleen, syntyy väärinkäsityksiä ja laajuusmäärittelyt voivat pelastaa nahkamme. Mikä on sinun syysi? Onko sinulla kauhutarinoita tilanteista, joissa laajuusmäärittelyjä ei ollut? Puhuin siitä johdannossa. Miksi laajuusmäärittelyt innostavat sinua?
Robyn Birkedal:
Ehdottomasti. Jo pelkästään johdantoasi kuunnellessani ajattelin, kuinka tuo trauma palasi mieleeni ja kuinka se tulee aina palaamaan. Laajuusmäärittelyt ovat erittäin tärkeitä, koska niiden avulla varmistetaan, että tiimilläsi ja asiakkaallasi on selkeä yhteinen käsitys tärkeimmistä vaatimuksista. Lopulta ne määrittävät, miten voit epäonnistua ja miten se tapahtuu. Tässä yritämme suojautua asiakkaan ja oman tiimimme kanssa syntyviltä konflikteilta sekä pyrkiä yhtenäistämään kaikkien näkemykset ja välttämään oikeudenkäyntejä.
Ben Aston:
Yritämme siis selventää ja yhtenäistää ymmärrystä mahdollisimman paljon. Laajuusmäärittelyt ovat erinomaisia juuri siksi, että niissä tämä ymmärrys kirjataan muodollisesti. Joskus voimme ajatella, että olemme kaikki samalla sivulla ja ystäviä keskenämme. Usein tilanne on itse asiassa pahempi silloin, kun olemme ystäviä, koska kaikki voivat vain olettaa muiden ymmärtävän toisiaan. Sitten mukaan hiipii sanoja, kuten päivitys tai virkistys, jotka ovat todella monitulkintaisia. Laajuusmäärittelyt vähentävät harmaiden alueiden epäselvyyttä ja tekevät asioista paljon mustavalkoisempia.
Robyn Birkedal:
Ehdottomasti. Vaikka olen työskennellyt tällä alalla kymmenen vuotta, käytetyt termit muuttuvat jopa neljännesvuosittain. Ennen kuin puhumme tarkemmin siitä, mitä laajuusmäärittelyt ovat ja miten niitä käytetään, haluan sanoa, että niiden kirjoittamista aliarvostetaan tässä tehtävässä. Se on työn kuivin osa ja yleensä vaikein vaihe projektin käynnistämisessä. Kukaan ei halua ottaa siitä vastuuta. Se on sinun tehtäväsi. Haluan kuitenkin sanoa, että itse pidän siitä. Olen melko nörtti, mutta projektin alussa käytetty aika varmistaa projektin tehokkaan tulevaisuuden.
Ben Aston:
Puhutaan siitä kaikkein perustavimmalla tasolla. Jos joku miettii hetken, mikä laajuusmäärittely on, miten kuvailisit sitä?
Robyn Birkedal:
Erilaisia termejä on valtava määrä, kuten mainitsit puhuessasi virkistyksestä ja uudistamisesta. Miten ne eroavat työmäärityksestä? Voimme varmasti keskustella tästä edestakaisin, mutta ymmärrän laajuusmäärittelyn yksinkertaisesti tapana kuvata työ, jonka toimituksesta sovitaan. Se kuvaa projektin perustavanlaatuisia rajoitteita ja rajoja. Siinä kerrotaan, mitä toimitetaan, mitä ei toimiteta, mitä toimituksesta oletetaan ja mitä lisäselvennyksiä tarvitaan.
Ben Aston:
Laajuusmäärittelyllä kuvaamme työn laajuutta ja kirjaamme sen muodollisesti. Sanomme, mitä teemme ja mitä emme tee. Jos emme pysty määrittelemään tarkasti, mitä teemme tai emme tee, kuvaamme ainakin prosessin ja sen, millainen prosessi on. Ihmiset kysyvät joskus, tarvitsevatko he työmäärityksen tai miltä ketterä työmääritys näyttää. Haasteena on edelleen määritellä, mitä teemme ja mitä emme tee. Toimitusten määrittelemisen sijaan voimme kuitenkin kohdistaa huomion tavoitteeseen, jonka haluamme saavuttaa, sekä prosessiin, jota seuraamme siihen päästäksemme.
Robyn Birkedal:
Ehdottomasti. Tähän liittyy muutamia perusasioita, joita kannattaa noudattaa, ja puhumme niistä kohta. Ei kuitenkaan ole olemassa yhtä mallia, jota jokainen digitaalinen projektipäällikkö käyttää. Kaikki eivät tee samaa asiaa, eikä mallia voi vain kopioida ja liittää. Jokainen yritys ja jokainen projekti tai ohjelma on erilainen. Tässä tavoittelemme johdonmukaisuutta, joka suojaa selustaamme — tai kuten artikkelissani sanoin, pelastaa nahkamme. Sinun täytyy suojella tiimiäsi ja liiketoiminta-aloitetta.
Ben Aston:
Onko sinulla tarinoita tilanteista, joissa et määritellyt laajuutta niin perusteellisesti kuin olisi pitänyt, ja mitä siitä seurasi?
Robyn Birkedal:
Tämä on liukas rinne. Aiemmissa tehtävissäni minua on neuvottu välttämään liiallista yksityiskohtaisuutta, koska se voisi altistaa meidät oikeudellisille toimille. Jos kirjoitat liikaa, harmaa alue antaa enemmän mahdollisuuksia neuvotella. Olen kuitenkin onnistunut parhaiten silloin, kun olen lisännyt mahdollisimman paljon yksityiskohtia. Oli kyse sitten vesiputousmallista tai ketterästä menetelmästä, määrittele kaikki lausunnossa ja tarkista se asiakkaan kanssa. Kokemuksen myötä oppii, ettei kaikkea tehdä aina täydellisesti ja että asiakas voi ymmärtää jonkin asian eri tavalla. Olennaista on navigoida tilanteessa ja käyttää alussa aikaa niin hyvin kuin pystyy.
Ben Aston:
Oma kauhutarina liittyy suureen kulutuselektroniikka-asiakkaaseen, jolle loimme mukautettuja animaatioita. Asiakas halusi varmistaa, että olimme ostaneet animaation käyttöoikeudet. Ostimme viiden vuoden käyttöoikeuden, jotta voisimme käyttää animaatioita haluamallamme tavalla viiden vuoden ajan. Olimme kuitenkin luomassa animaatiota vain yhtä kampanjaa varten ja tarvitsimme sitä korkeintaan vuoden. Ajattelimme, että ostamme viisi vuotta varmuuden vuoksi, jos haluaisimme käyttää sitä seuraavana vuonna.
Myöhemmin asiakas palasi ja sanoi, että meidän olisi pitänyt ostaa oikeudet pysyvästi, kaikkiin medioihin ja kaikkiin formaatteihin. Olimme ostaneet oikeudet vain viideksi vuodeksi. Tästä tuli valtava kiistakapula, koska animaatiostudio tiesi olevansa vahvoilla ja saattoi veloittaa meiltä mitä tahansa. Lopulta koko asiakassuhde hajosi yhden puutteellisesti määritellyn laajuusmäärittelyn vuoksi. Kyse oli vain siitä, kuinka pitkäksi aikaa kolmannen osapuolen animaatioiden käyttöoikeudet ostettiin. Pienellä väärinkäsityksellä voi olla valtavat seuraukset. Joskus ihmiset aloittavat riidan vain siksi, että voivat.
Näihin asioihin täytyy suhtautua vakavasti, sillä ne voivat kaataa projektin lisäksi koko asiakassuhteen. Puhutaan siis laajuusmäärittelyjen kirjoittamisesta ja prosessista. Miten ne laaditaan? Miten päätät, mitä kirjoitat, jos haluat välttää sekä liian tarkan että liian väljän määrittelyn?
Robyn Birkedal:
Ennen sitä kolme asiaa. Ensinnäkin en ole lakimies enkä anna virallista oikeudellista neuvontaa. Puhun lähinnä mainosalalla saamistani kokemuksista. Toiseksi haluan lähettää sinulle myötätuntoa tuon tilanteen vuoksi. Tiedän nuo pysyvät käyttöoikeudet, ja yhden vuoden, viiden vuoden ja pysyvän käyttöoikeuden ero on valtava. Siinä oli hyödyllinen opetus.
Työympäristöissämme laajuusmäärittelyt voivat tarkoittaa monia asioita. Niitä voidaan kutsua arvioiksi, työn laajuudeksi, sopimukseksi tai tarjoukseksi. Ne ovat kokonaisuus, joka voi esiintyä useissa eri muodoissa. Olen käyttänyt esimerkiksi työmääritystä, sopimusta ja tarjousta. Ne eivät kuitenkaan ole salassapitosopimus, pääpalvelusopimus, itsenäisen toimeksisaajan sopimus tai palvelutasosopimus. Näiden määritelmistä voi lukea lisää artikkelistani. Haluan siis korostaa, ettei tämä ole ainoa asiakirja, joka asiakkaalle täytyy toimittaa, vaan yksi sen osa.
Ben Aston:
Ehdottomasti.
Robyn Birkedal:
Palataan alkuperäiseen kysymykseesi. Kysyit, miten kirjoitan ne ja mikä on prosessini.
Ben Aston:
Niin.
Robyn Birkedal:
Käytän yleensä sisäisen tiimini valmiita malleja. Olen onneksi työskennellyt useissa hyvissä työpaikoissa, joissa malli on ollut jo valmiina. Säilytän myös aiempien työmääritysten versioita henkilökohtaisessa kansiossa, jotta voin tarkistaa, miten olen laatinut määrittelyn brändiprojektille, digitaaliselle projektille, virkistykselle tai uudistamiselle. Digital Project Manager on myös erinomainen resurssi. Sinä kirjoitit hyvän artikkelin työmäärityksen kirjoittamisesta, ja siinä on myös malli.
Ben Aston:
On erittäin tärkeää rakentaa oma laajuusmäärittelypankki, jota voi vähentää, käyttää uudelleen ja kierrättää. Kun kuvaamme työn toimittamista, kuvaamme yleensä samoja asioita: kuinka monta konseptia kehitämme, kuinka monta kommenttikierrosta teemme, millainen asiakkaan vuorovaikutus ja palautekierros on sekä millaisia lopullisia toimituksia tuotamme. Jos toimitamme samankaltaisia asioita yhä uudelleen ja noudatamme samaa prosessia, laajuusmäärittelyjä voi kierrättää melko helposti.
Jos et ole vielä tutustunut julkaisuun, käy osoitteessa thedigitalprojectmanager.com/project-scope-statement. Siellä on paljon laajuusmäärittelyjä. Osa on yleisiä ja niitä voi käyttää uudelleen omissa projekteissa vaihtamalla nimet. Osa on tarkempia ja edellyttää projektin ymmärtämistä. Kierrätettäviä määrittelyjä voivat olla esimerkiksi se, kuka maksaa kuvien tai videoiden lisensoinnin, kuka siitä vastaa, kuinka nopeasti asiakkaan on hyväksyttävä työ tai annettava koottu palaute sekä kuinka monta hyväksyntäkierrosta tehdään.
Puhutaan hyvistä ja huonoista laajuusmäärittelyistä. Tämän voi tehdä kahdella tavalla, tai kyse voi olla jatkumosta löysän ja erittäin tarkan laajuusmäärittelyn välillä. Kumpikaan ääripää ei ole automaattisesti hyvä tai huono. Mikä tekee laajuusmäärittelystä hyvän tai huonon?
Robyn Birkedal:
Se on suuri kysymys. Voisimme puhua siitä tuntikausia. Arvostan erityisesti sitä, että hyödynnetään aiempien laajuusmäärittelyjen pankkia ja pyydetään nykyisiltä työtovereilta tai ystäviltä samanlaisia, tehokkaiksi todettuja malleja, jotta kaikkea ei tarvitse aloittaa tyhjästä. Hyödynnä DPM-yhteisöä ja muita ihmisiä. Voin kuitenkin kertoa viisi asiaa, joilla voit suojata nahkasi. Haluatko kuulla ne?
Ben Aston:
Kyllä, anna tulla.
Robyn Birkedal:
Tämä perustuu omaan kokemukseeni. Ensimmäiseksi määrittele miksi. Kutsun tätä osaa yleensä yleiskatsaukseksi, koska se kuulostaa hieman muodollisemmalta. Tässä ensimmäisessä osassa määritellään työ, kerrotaan miksi projekti tai ohjelma on olemassa, miksi se toteutetaan ja mitä sillä saavutetaan. Olemme kaikki kirjoittaneet yleiskatsauksia esseisiin, ja nyt käytämme samaa ajatusta aikuisina. Annan tämän yleensä asiakkuuspäällikölle, joka voi viedä sen asiakkaalle ja hankkia keskeiset suorituskykymittarit. Tässä ei tarvitse kertoa kaikkea. Pidä se lyhyenä ja ytimekkäänä. Tarvitsemme kehyksen ja arvolupauksen, joka ohjaa muuta työtä ja johon voimme palata.
Ben Aston:
Miksi aloittaminen on erittäin tärkeää, koska jos kaikki muu epäonnistuu, se toimii suojaverkkonamme. Jos voimme osoittaa, että toimitus vastaa alkuperäistä tarkoitusta, olemme vahvoilla. Jos tarkoituksena oli rakentaa jotakin, joka lisää tilaajien määrää, asiakas ei ehkä pidä toteutustavasta, mutta jos voimme osoittaa, että tilaajien määrä kasvaa, olemme saavuttaneet tavoitteen. Kun pääsemme yhteisymmärrykseen siitä, miksi työtä tehdään, meillä on yhteinen perusta.
Robyn Birkedal:
Tämä toimii kaikissa projektimenetelmissä. Meidän on aina tiedettävä, miksi etenemme. Olen havainnut hyödylliseksi kirjoittaa tämän Slack-kanavan alkuun tai tiimin muihin dokumentteihin ja jakaa sen kaikkien kanssa, jotta tiimit ovat samalla sivulla. Toinen vinkkini on hyväksymisprosessin kuvaaminen. Tämä voi tuntua perustavalta, mutta juuri tässä asiat ovat aiemmin kärjistyneet.
Kannustan laatimaan ainakin perustason tekstin, joka kuvaa toimitusten hyväksymisprosessin. Milloin asiakkaan tulee antaa palautetta? Kuka palautteen antaa ja miten se toimitetaan? Voit aloittaa lausunnossa perustasolta, mutta sitä pitää täydentää ennen työn käynnistymistä. Palautteesta ja hyväksymisprosessista kannattaa puhua asiakkaan kanssa suullisesti ja kirjata se sitten lausuntoon.
Ben Aston:
Ehdottomasti. Se on hyvää neuvontaa.
Robyn Birkedal:
Kolmas vinkki on tunnistaa, mitä todella toimitetaan. Tämä on yleensä laajuusmäärittelyn suurin osa. Se voi olla hyvin yksityiskohtainen ja laaja vesiputousprojektissa tai prosessikeskeisempi ketterässä lähestymistavassa. Sen tulee kertoa täsmällisesti, mitä ihmiset saavat, milloin he saavat sen ja miten he saavat sen. Suosin yksityiskohtaisuutta ja haluan määritellä tarkasti kommenttikierrokset, sopimusmerkinnät, migraation, ylläpidon, konfiguroinnin, laadunvarmistuksen, kuvien käyttöoikeudet ja lopullisen käyttöönoton.
Ben Aston:
Olen samaa mieltä: jos voimme määritellä asian, määritellään se ja rajataan se. Jos emme tiedä tarkalleen, mitä toimitamme, käytän hiekkasäkkiperiaatetta. Määritellään vähintään se, minkä varmasti toimitamme. Jos uskot kehittäväsi neljä konseptia, lupaa mieluummin kaksi. Jos uskot rakentavasi sivulle enintään viisi komponenttia, määrittele ja sovi viidestä, vaikka niitä voisi lopulta olla kuusi tai seitsemän.
Hiekkasäkkiperiaate voi auttaa löytämään yhteisen perustan ja todennäköisimmän lopputuloksen. Silloin et sitoudu seitsemään moduuliin, vaan lupaat viisi ja voit ylittää odotukset. Älä sitoudu liikaa. Jos lupaat seitsemän mutta tarvitsetkin vain viisi, asiakas voi pyytää hyvitystä.
Robyn Birkedal:
Näin on käynyt minulle. Se auttaa myös hallitsemaan tiimin sisäistä työtä. Suunnittelijalla, kehittäjällä tai strategilla voi olla erilainen käsitys työmäärästä. Strategi voi esimerkiksi sanoa, että tarvitaan 20 mallipohjaa. Kun näistä keskustellaan etukäteen, voimme vähentää sisäistä vaihtelua emmekä ainoastaan hallita asiakasta.
Neljäs vinkkini on määritellä, mikä sisältyy projektiin ja mikä ei. Sijoitan tämän yleensä eri osaan kuin toimitukset. Kun olen tunnistanut toimitukset, teen kattavan listan suojatakseni sen, minkä tiedän ja mitä en tiedä. Kutsun tätä rajoiksi. Laajuusmäärittelyissä pidän tästä osasta riippuvuuksina ja oletuksina. Siinä kerrotaan esimerkiksi, että palautteen tulee olla kirjallista ja tulla sovitulta henkilöltä. Jos käyttöönottoja on useita tai asiakas päättää olla etenemättä käyttöönottoon, määritellään, että käyttöönoton siirtäminen johtaa muutostilaukseen, koska se vaatii tiimiltä lisäaikaa ja resurssien uudelleenjärjestelyä.
Toiseksi pidän poissulkemista koskevasta osiosta eli projektin ulkopuolisista asioista. Siinä luetellaan kaikki, mitä asiakas saattaa pyytää mutta mitä et toimita. Esimerkiksi kuvien pysyvät käyttöoikeudet, koulutusdokumentaatio, ylläpito, fonttien lisenssimaksut ja digitaaliset tyylioppaat. Lista voi jatkua loputtomiin, mutta tarkoitus on varmistaa, ettet joudu vastuuseen asioista, joista ei ole sovittu.
Ben Aston:
Tai ehkä niistä on puhuttu, mutta väärinkäsitykset syntyvät juuri siinä. Näitä kutsutaan myös kielteisiksi laajuusmäärittelyiksi: luetellaan kaikki, mitä emme varmasti tee. Asiakas voi sanoa haluavansa verkkosivuston uudistamisen ja puhua samalla uudelleenbrändäyksestä. Myöhemmin käy ilmi, ettei budjetti riitä täydelliseen uudelleenbrändäykseen. Silloin määrittelyyn kannattaa kirjata, ettei projektiin sisälly uudelleenbrändäystä.
Voit myöhemmin palata kirjaukseen ja sanoa asiakkaalle, että uudelleenbrändäystä ei sisällytetty projektiin. Kun kirjoitat kielteisiä laajuusmäärittelyjä, ennakoi kaikki asiat, joita asiakas voisi kuvitella saavansa mutta joita hän ei saa. Palaa käymiisi keskusteluihin, muista esiin nousseet ajatukset ja lisää ne listaan.
Robyn Birkedal:
Pidän tuosta. Tähän ei ole yhtä oikeaa tapaa. On tärkeää kuunnella vaistoaan ja luetella kaikki tavat, joilla projekti voisi mennä huonosti. Jotkut esihenkilöt ovat sanoneet, että katastrofeja ennakoin liikaa. Minulle on kuitenkin hyödyllistä hahmotella, mikä voi mennä pieleen, ja tiivistää se sitten. Näin ajattelen eteenpäin ja yritän vähentää riskejä projektin alkuvaiheessa.
Viides ja viimeinen vinkki on hieman kiistanalainen: laadi laajuusmäärittelymatriisi. Olen aiemmin käyttänyt tuntikausia aktiivisen projektin aikana dokumenttien, tiedostojen, Slackin, sähköpostien, luonnostiedostojen ja joskus koodinkin versiohistorioiden tutkimiseen selvittääkseni, mitä oikeastaan sovittiin. Se ei ollut selkeää ja kulutin siihen paljon projektitunteja. Opin, että voin tehdä työn etukäteen ja seurata toimituksia heti laajuusmäärittelyn laatimisen yhteydessä. Näin ymmärrämme selkeästi, miten lausuntoa toteutetaan.
Ben Aston:
Ajatuksena on, että työmäärityksestä ei tule vain kertaluonteinen dokumentti, vaan sitä käytetään koko projektin ajan. Kun toimitukset sijoitetaan matriisiin ja niitä seurataan, voimme muistuttaa asiakasta tai sidosryhmiä siitä, että otamme dokumentin vakavasti ja käytämme sitä. Se on hyvä tapa seurata etenemistä ja pitää dokumentti sekä keskustelu elävänä.
Robyn Birkedal:
Aivan. En ole aina jakanut matriiseja suoraan asiakkaalle. Joskus pidän ne projektin sisäisessä kansiorakenteessa. Otan ne kuitenkin esiin, jos syntyy kiistaa, jotta minulla on heti tarvittavat resurssit asian ratkaisemiseen ilman tuntikausien selvitystyötä.
Ben Aston:
Kuulostaa helpolta, eikö? Jos noudatat näitä vinkkejä, kaikki sujuu varmasti täydellisesti. Vai sujuuko? Kerro suurimmista haasteista tai tilanteista, joissa laajuusmäärittelyt menevät pieleen.
Robyn Birkedal:
Ongelma ei ole aina sääntöjen noudattaminen, vaan joustavuus ja jokaisen projektin käsitteleminen erikseen. Aiemmin ajattelin, että koska tämä on mallini, seuraan sitä aina. Meidän täytyy kuitenkin olla joustavampia ja ymmärtää, että asiakkaat ovat eri tasoilla sen suhteen, miten he haluavat toimia. Siinä ongelmat yleensä syntyvät. Olen vuosien aikana muuttunut joustavammaksi lähestymistavassa, mutta samalla tiukemmaksi siinä, mihin oikeasti sitoudumme.
Ben Aston:
Yksi suurimmista haasteista on päättää, kuinka täsmällinen määrittelyn pitää olla. Projektin alussa voi olla vaikeaa kirjoittaa laajuusmäärittelyä, jos toimitukset eivät ole täysin selvillä. Saatamme sanoa, että toimitamme X:n, Y:n ja Z:n, mutta selvitys- tai suunnitteluvaiheen jälkeen Z osoittautuu tarpeettomaksi tai liian kalliiksi.
Kannattaa ajatella suunnitteluhorisonttia. Laajuusmäärittelyjä on hyvä kirjoittaa, mutta niitä ei pidä venyttää liian pitkälle tulevaisuuteen. Jos olet siirtymässä selvitysvaiheeseen, kirjoita ensin vain selvitysvaiheen määrittely. Sano, että seuraavan vaiheen laajuus ja määrittely laaditaan osana nykyistä vaihetta. Liian pitkälle ulottuva määrittely on yksi suurimmista haasteista, koska luulemme tietävämme, mitä tapahtuu, vaikka emme usein tiedä.
Robyn Birkedal:
Yksi toinen haaste tuli mieleeni: asiakas hyväksyy laajuusmäärittelyn, mutta kaikkia sidosryhmiä ei ole otettu mukaan. Se voi vahingoittaa projektia. Siksi suullinen läpikäynti ja yhteinen linjaussessio ovat erittäin hyödyllisiä.
Ben Aston:
Suullinen läpikäynti on tärkeä, koska emme halua asiakkaan allekirjoittavan asiakirjaa lukematta tai ymmärtämättä sitä. Haluamme asiakkaan ymmärtävän, mihin hän sitoutuu. Laajuusmäärittelyn ei ole tarkoitus olla oikeudellinen asiakirja, vaan keskustelun väline, jonka avulla asetetaan odotukset samalle tasolle.
Emme halua päätyä tilanteeseen, jossa menemme oikeuteen selvittämään, mitä työmääritys tarkoittaa ja päättääkö tuomari tai asianajaja, toimitettiinko työ vai ei. Tarkoitus on päästä samalle sivulle. Kun käymme laajuusmäärittelyt asiakkaan kanssa läpi, emme yritä huijata häntä tai tulkita sanoja omaan eduksemme. Haluamme yhteisen ymmärryksen, jotta asiakas on tyytyväinen projektin lopputulokseen ja tuotettuihin asioihin.
Älä siis ajattele tätä oikeudellisena asiakirjana. Jos asia etenee niin pitkälle, olemme epäonnistuneet ja kaikki todennäköisesti menettävät rahaa ja asiakkaan. Tarkoitus on yhdenmukaistaa odotukset, jotta kaikki ovat tyytyväisiä työn toteutukseen ja tuotoksiin. Se on keskustelumme tärkein oppi.
Robyn Birkedal:
Mikään ei ole hienompaa kuin tunne siitä, että laajuusmäärittelyn voisi kopioida suoraan oikeudellisesti sitovaan asiakirjaan ja varmistaa, että sana ”linjassa” toteutuu asiakkaan ja sisäisten osapuolten välillä.
Ben Aston:
Päästään siis yhteisymmärrykseen. Robyn, kiitos paljon, että liityit seuraamme. On ollut hienoa saada sinut mukaan.
Robyn Birkedal:
Kiitos kutsusta.
Ben Aston:
Haluaisin kuulla sinulta, joka kuuntelet: millaisia vinkkejä ja niksejä sinulla on laajuusmäärittelyihin ja työmäärityksiin liittyen? Mihin sijoitat määrittelysi? Miten tuotat ne? Mikä toimii ja mikä ei? Kerro kommenteissa epäonnistumisistasi ja onnistumisistasi. Jos haluat oppia lisää ja edetä työssäsi, liity DPM-jäsenyyden kautta yhteisöömme osoitteessa thedigitaprojectmanager.com/membership. Saat pääsyn Slack-tiimiimme, vertaisryhmään, mentorointiin, malleihin, työpajoihin, vastaanottoaikoihin, kyselytunteihin, sähköisiin kirjoihin ja muuhun. Jos pidit kuulemastasi, tilaa podcast ja pysy yhteydessä osoitteessa thedigitalprojectmanager.com. Ensi kertaan asti, kiitos kuuntelusta.
