Redd prosjektet ditt med et prosjektinitieringsdokument (med Maik Stettner fra FCV Interactive)

Les transkripsjonen:

Vi prøver ut transkribering av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Ben Aston:

Takk for at du lytter. Jeg heter Ben Aston, og dette er podkasten til The Digital Project Manager. Denne podkasten presenteres av Clarizen, lederen innen programvare for virksomhets-, prosjekt- og porteføljestyring. Besøk clarizen.com for å lære mer.

Hvis det er én ting du kan være sikker på når det gjelder et prosjekt, er det at det aldri kommer til å gå helt etter planen. Men hvorfor sporer prosjekter av? Noen ganger er det ganske enkelt fordi vi går i gang med prosjekter for raskt. Vi ser at prosjektfristen nærmer seg, og ender derfor opp med å starte prosjektet i lett panikk. Men når ting begynner å gå galt, lurer vi på hvorfor.

Selv om vi vanligvis har all prosjektbakgrunnen, strategien, detaljene, kravene og suksessmålene lagret bakerst i hodet, kan vi ofte gjøre den feilen at alle andre derfor også burde kjenne til alt dette. Men virkeligheten er at hvis det ikke er dokumentert, er sjansen stor for at teamet vårt rett og slett ikke vet det.

Så i dag skal vi snakke om et verktøy vi kan bruke for å sørge for at alle er på samme side ved prosjektstart. Det er prosjektinitieringsdokumentet, eller det som kanskje oftere kalles prosjektbriefen i vår verden. Derfor skal vi gi deg en innføring i hvordan du kan lage et PID og bruke det til å gjøre prosjektene dine mer effektive.

I dag har jeg med meg Maik Stettner, en av vennene og kollegene mine. Maik er en av våre faste DPM-eksperter hos The Digital Project Manager. Velkommen, Maik.

Maik Stettner:

Hei. Hvordan går det?

Ben Aston:

Det går bra. Det er flott å ha deg med oss. Maik, la oss begynne med deg og fortelle litt om historien din. Vi jobber jo sammen, og vi har nå jobbet sammen i, hva er det, fem år?

Maik Stettner:

Ja, det er mellom fire og fem år nå.

Ben Aston:

Da jeg ansatte Maik, husker jeg at jeg tenkte: «Jeg vet ikke om denne fyren kommer til å klare det.» Du kommer fra en litt annen bakgrunn, ikke den tradisjonelle byråbakgrunnen. Fortell oss om historien din. Hvordan ble du prosjektleder i et digitalbyrå?

Maik Stettner:

Til sammen har jeg omtrent ti års erfaring fra ulike områder. Jeg begynte opprinnelig med spill og utgivelser, der jeg styrte lanseringer av spill i Europa og Nord-Amerika. Deretter gikk jeg videre til andre områder, som medisinske databaser, men alltid innen programvareutvikling og ting som har med prosjektledelse, ulike team og lignende å gjøre. I løpet av karrieren fikk jeg også erfaring fra byråverdenen med apputvikling og litt innledende webutvikling. Da vi hadde den første samtalen om å jobbe sammen, gikk jeg i praksis over til full webutvikling og byråarbeid.

Ben Aston:

Ja.

Maik Stettner:

Jeg har jobbet i det nåværende selskapet mitt, FCV, i omtrent fire år. Nå leder jeg prosjektlederteamet for byrået, og jeg har i praksis ansvar for den overordnede leveransen av prosjekter og for å sørge for at kundene er fornøyde med resultatene vi leverer.

Ben Aston:

Bra saker. For de som lytter og tenker at de kanskje er i en lignende situasjon – og dette får vi ganske ofte høre – det er folk som sier: «Jeg er prosjektleder og har erfaring med å lede programvareprosjekter, men nå vurderer jeg å gå over til et byrå og bli digital prosjektleder.» Hvordan opplevde du overgangen? Fra programvareverdenen til digital prosjektledelse i et byrå – hva var de viktigste forskjellene, kanskje når det gjelder hvordan du må lede mennesker eller prosjekter?

Maik Stettner:

Først og fremst er det mange likheter. Ting du møter i andre programvareutviklingsbyråer eller innen andre prosjektledelsesrelaterte områder, møter du også i et byrå. Du har tverrfaglige team, prosjekter sporer av av mange ulike grunner, og du kan bruke de samme taktikkene for å håndtere dette.

En av de største forskjellene for meg da jeg begynte, var å forstå og bruke hele tankegangen rundt tid og materiell og mindre arbeidsinkrementer i stedet for større leveranser. Kundene, særlig innenfor området jeg jobber med, ønsker mer åpenhet og større kontroll over mindre arbeidsdeler som blir utført. Det krever mer detaljert rapportering og mer arbeid med å være åpen og forklare kunden nøyaktig hva du gjør for å skape den graden av tillit. Det krevde litt mer innsats og tilpasning fra min side enn når du jobber i et produktselskap mot en lansering, som kanskje er intern.

Det var hovedforskjellen for meg. Samtidig var det interessant å se at når du jobber innen et helt annet område, spiller det egentlig ikke så stor rolle om du jobber med et databaseprosjekt, et spill eller et nettsted. Du møter ganske like problemer som kan overføres fra ett område til et annet. Hvis du bruker det du har lært i tidligere jobber – for eksempel god kommunikasjon og noen av de vanlige beste praksisene som prosjektleder – er sjansen stor for at du lykkes, uansett hva du bygger.

Ben Aston:

Det er bra. Du snakket om at man møter lignende utfordringer. Kan du fortelle oss, i rollen din nå, der du ikke bare leder prosjekter, men også team – prosjektlederteamet – hvilke typiske utfordringer håndterer du når du leder PMO-teamet og styrer en hel portefølje med ulike prosjekter og motstridende ressursbehov?

Maik Stettner:

Rollen min er mer helhetlig nå. Jeg sørger i praksis for at alt fortsetter å bevege seg fremover. Et av hovedfokusområdene mine er, som du allerede sa, vanligvis bemanning – å sørge for at vi har de riktige personene til den riktige jobben i riktig tidsrom.

Ben Aston:

Ja.

Maik Stettner:

Ofte må du inngå kompromisser når ting tar lengre tid, samtidig som du allerede har et annet prosjekt på gang. Da må du håndtere noen av disse justeringene og sørge for at kundene har en åpen kommunikasjonslinje til meg. Risikoen ved å være i en mer helhetlig rolle på høyere nivå, er at du i praksis blir den eneste andre personen som har ansvar for eskaleringer. Det er ikke en rolle du bare ønsker å ha, for da er det i praksis bare når folk er sinte at du får telefonene.

Ben Aston:

Ja.

Maik Stettner:

Men det er alltid bra å spille en mer aktiv rolle i ulike prosjekter for å utvikle dette tillitsforholdet, samtidig som du sørger for at ting er riktig organisert internt. Det kan gjelde bemanning, drift eller bare generell samhandling på tvers, siden vi har flere kontorer.

For oss er det viktig å sørge for at folk fra Toronto-kontoret kan jobbe godt sammen med Victoria-kontoret, for eksempel. Det er hovedfokuset mitt. Når det er sagt, har jeg fortsatt noen kunder jeg jobber svært tett med, og jeg driver fortsatt med en god del prosjektledelse, fordi det fortsatt er der lidenskapen min ligger. Jeg liker virkelig å jobbe med mennesker, så det kommer jeg ikke til å gi slipp på.

Ben Aston:

La oss gå tilbake til utfordringen med ressursstyring. Dette er noe alle som leder et prosjektlederteam eller jobber med ressursstyring vil møte. Du har motstridende prosjekter, to prosjektledere på teamet har begge frist på fredag, og begge trenger de samme ressursene. Hvordan prioriterer du? Hva er tilnærmingen din til porteføljestyring når du skal avgjøre hvem som får ressursene?

Maik Stettner:

Først ser jeg vanligvis på prosjektets prioritet. Har vi noen frister vi må overholde? Har vi lovet kunden noe? Må det lanseres på en bestemt dato? Jeg ser ganske enkelt etter om det finnes noe handlingsrom når det gjelder tidspunktene.

Det spiller også en rolle om noe er ferdigstilt i kontrakten. Vi må sørge for at alt blir gjort. Er prosjektet bare ute etter å komme videre og gjøre kunden en tjeneste? Det er bra, og det gjør vi gjerne hvis vi har tid. Men hvis det andre prosjektet skal lanseres om tre dager, kan vi sannsynligvis ikke hente noen derfra.

Det er utgangspunktet. Ideelt sett skjer det ikke, fordi prosjektlederen bør forutse visse overskridelser og legge inn buffere. Det høres kanskje rart ut, men jeg forventer også at teamet mitt kjemper for ressursene de trenger.

Ben Aston:

Ja.

Maik Stettner:

Ofte er de for snille. De sier gjerne: «Nei, du kan få denne personen én dag.» Til syvende og sist fører det til at alles arbeid blir forsinket. Jeg liker ikke å snappe eller stjele ressurser – det er helt uaktuelt – men i ressursmøter forventer jeg at noen står opp for tiden de trenger og overlater problemet til ressurslederen, slik at vedkommende kan skaffe hjelp eller finne ut hvordan dette kan balanseres.

Ben Aston:

Kanskje det er et kanadisk ressursproblem.

Maik Stettner:

En kanadisk stillingskrig, helt klart.

Ben Aston:

Kanadiere er for snille, og som europeere kan vi vel si det. Eller er det bare kanadiere som har lov til å spøke med disse degenererte menneskene?

Maik Stettner:

Nettopp. Jeg ser definitivt annerledes på dem i Europa også.

Ben Aston:

Jeg er alltid interessert i verktøy. Har du nylig funnet eller begynt å bruke noen verktøy der du tenker: «Dette er fantastisk. Hvorfor begynte vi ikke med dette tidligere?» Hva består verktøykassen din av, og hva fungerer godt?

Maik Stettner:

Tenker du på ressursstyring?

Ben Aston:

Ressursstyring eller prosjektstyringsverktøy generelt.

Maik Stettner:

Vi bruker faktisk en ganske standard verktøykasse for tidsstyring, og MS Project blir ofte litt overveldende for kunden. Nå eksperimenterer vi mye med skybaserte produkter. Project har for eksempel en Office 365-versjon. Vi ser også på ulike programmer for tids- og ressursstyring. Jeg har ikke funnet den perfekte løsningen, fordi vi har en ganske skreddersydd prosess som dessverre også delvis er manuell.

Personlig tror jeg ikke det ideelle verktøyet for behovene våre finnes. Målet mitt ville vært å bygge eller kjøpe noe og deretter tilpasse det til de individuelle behovene.

Ben Aston:

Hva er det du ikke ser i verktøyene som ville gjort dem levedyktige? Eller er det bare prosessen som er så innviklet eller kompleks at verktøyene ennå ikke kan håndtere den?

Maik Stettner:

Ikke nødvendigvis. Den er faktisk ganske enkel. Det jeg ser etter, er i praksis et verktøy som kobler enkel tidsstyring og timeføring, eller de ansattes timelister, sammen med ressursplanlegging. Noe som Resource Guru eller andre verktøy som lar deg kartlegge hva du trenger, men som også kobler dette til den økonomiske siden. Når du jobber med tid og materiell, er den enkle beregningen antall timer multiplisert med faktureringssatsen. Deretter kan hele rapporteringsløpet settes opp gjennom systemet.

Det høres enkelt ut, men det er mye å ta hensyn til når prosjekter endres underveis og systemene skal håndtere dette. Det kan forstyrre rapporteringen og føre til så mye ekstra manuelt arbeid at måltallene ikke stemmer. Jeg har egentlig ikke funnet den perfekte løsningen ennå.

Ben Aston:

La oss snakke om artikkelen du skrev om prosjektinitieringsdokumenter, eller PID-er. Som jeg nevnte i innledningen, går prosjekter galt, og jeg tror ofte det skyldes at vi ikke starter dem ordentlig. Vi gjør antakelser om hva teamet vet, eller gir dem en mengde dokumenter og sier: «Gå inn på fellesområdet og les dokumentene. Alt står der.» Vi tror de kommer til å sette seg inn i alt og komme ajour, og når de så mislykkes på spektakulært vis, skjønner vi ikke hvorfor. Men egentlig er det fordi de ikke forstår prosjektet.

La oss snakke om hvordan vi kan gjøre dette bedre, hvordan vi kan skrive bedre prosjektbrief­er, eller for å bruke prosjektledelsesspråket, lage et prosjektinitieringsdokument. La oss sette scenen litt. Kan du fortelle oss om prosessen din for å starte prosjekter, og hvor prosjektinitieringsdokumentet eller prosjektbriefen passer inn? Når lager du det, og hvordan kommer du frem til punktet der du kan skrive det?

Maik Stettner:

La oss anta at du har en ny kunde. Du er begeistret fordi den overordnede kontrakten er signert. Det er kanskje en overordnet rammeavtale eller noe som sier at selskapet ditt og det andre selskapet skal begynne å jobbe sammen. Neste steg for meg er alltid å finne ut hvordan vi gjør dette om til mer konkrete trinn og konkrete vilkår.

Vanligvis tenker man på en arbeidsbeskrivelse som neste steg. Problemet er at alt er svært overordnet så tidlig i prosjektet, og bare et anslag over hva dere til slutt kommer til å gjøre. Prosjektinitieringsdokumentet, men også oppstartsmøter, er gode verktøy for å bli kjent med kunden og høre om det finnes andre behov eller drivere som ikke ble tatt med i de første arbeidsbeskrivelsene.

Vanligvis lager vi først et utkast til arbeidsbeskrivelsen. Deretter bestemmer teamet seg internt i byrået, og vi gjennomfører en intern oppstart for å få alle inn i arbeidet. Så har vi en ekstern oppstart med kunden på et mer overordnet nivå: Dette skal vi gjøre, dette er teamet, slik samarbeider vi, og dette er omfanget vi har definert per nå.

For meg er prosjektinitieringsdokumentet eller prosjektbriefen neste steg mot å gjøre ting mer konkrete. Så tidlig i prosessen må du imidlertid behandle det som et levende dokument, fordi det ikke er helt klart i detalj hvor prosjektet vil ende. Det er likevel et svært godt verktøy for å gi forretningskontekst og sørge for at de grunnleggende prosjektparameterne er tydelige, både for kunden og for det interne teamet.

Ben Aston:

Du starter altså med en overordnet arbeidsbeskrivelse, eller en juridisk avtale mellom deg og kunden. Dette er punktet der grunnlaget i arbeidsbeskrivelsen og rammeavtalen er lagt, mens prosjektbriefen bygger videre på dette og definerer enkelte ting tydeligere.

I artikkelen din beskriver du noe av det dokumentet bør inneholde. Du snakker om å gi kontekst, spesifisere prosjektparametere, lage en prosjektstruktur, avklare hvem som er hvem i prosjektet og håndtere risiko. La oss begynne med kontekst. Når du setter sammen dette dokumentet og skal gi prosjektteamet kontekst, hvordan gjør du det uten å forvirre dem eller overbelaste dem med informasjon? Hvordan finner du ut hva som er støy, og hva som faktisk vil være nyttig? Hva er de viktigste tingene du prøver å ta med i kontekstbeskrivelsen?

Maik Stettner:

Jeg tror det handler om hvorfor kunden gjennomfører prosjektet, og hvilke problemer som skal løses på et overordnet nivå. Finnes det forretningsmessige drivere? Ønsker de å øke salget eller lære en målgruppe mer om det de gjør? Er det et arbeid med ny merkevare? Det viktigste spørsmålet er hvordan suksess defineres. Hvordan vet vi til slutt, selv om vi fortsatt er på et ganske overordnet nivå, om vi har lykkes?

Det kan være så enkelt som bedre salgssamtaler, eller for eksempel et selvbetjent nettsted som henter alt innhold fra et innholdsstyringssystem. Det er viktig å legge grunnlaget for teamet slik at de vet hva de arbeider mot. Selv om trinnene ikke er detaljert beskrevet ennå, hjelper det deg å ramme inn det overordnede arbeidet.

Hvis du for eksempel arbeider med et prosjekt for å endre merkevaren, og målet er å reposisjonere selskapet, kan noen ved slutten av prosjektet spørre: «Men hvorfor økte ikke salget mitt?» Da kan du gå tilbake og si: «Dette var ikke egentlig målet med prosjektet eller konteksten for det. Det kan likevel ha en positiv effekt, men det var ikke hovedfokuset.»

Det er alltid bra å ha en oversikt over hva som først ble diskutert, og å være enig med kunden om det overordnede målet.

Ben Aston:

Det er nyttig. Konteksten for prosjektet er alltid viktig, med mindre det faktisk bare er vedlikeholdsarbeid der du ikke trenger å kjenne den overordnede strategien. Men hvis vi lager noe nytt, er konteksten – hvorfor kunden gjennomfører prosjektet, hva vi prøver å løse, forretningsmålene og hvordan suksess ser ut – avgjørende. Den gir teamet bakgrunnsinformasjonen de trenger for å utforme løsningen. La oss snakke om prosjektparametere. Du nevnte dette i forbindelse med konteksten. Vi rammer inn hvordan prosjektet passer inn i det store bildet av det kunden strategisk prøver å oppnå. Men hvilke parametere prøver du å definere i selve briefen? Du begrenser i praksis teamet. Hva prøver du å ramme inn, og på hvilke måter er det nyttig å begrense teamet?

Maik Stettner:

Du vil ikke begrense ekspertene. Problemet er at hvis du gir dem full frihet, kan de arbeide med et helt annet prosjekt enn det du så for deg. Det er derfor viktig å gi dem rammen og grunnleggende begrensninger, som budsjett, tidslinje og den overordnede planen. Ideelt sett har du estimert dette sammen med deler av teamet, så det bør ikke være nytt for dem. Folk bør vite at kunden har et bestemt budsjett.

Det er svært verdifullt å gå gjennom disse tingene. Teamet må forstå at det ikke er en begrensning, men det som er avtalt at dere skal levere til kunden for et bestemt budsjett. Hvis noe endrer seg, for eksempel at noen trenger mer tid, er det teamets oppgave å finne ut hvordan det likevel kan fungere. Ha denne diskusjonen på et overordnet nivå, og ikke gi teamet inntrykk av at du gjør livet vanskelig for dem. Gjør det mulig for dem å gjøre det de må, og sørg for at de vet at du støtter dem når det gjelder mulige budsjettøkninger, risikoer eller endringer i tidsplanen.

Til syvende og sist må teamet være trygt på at de kan levere, og begeistret for å starte prosjektet, akkurat som kunden. De ønsker også å få ting gjort.

Ben Aston:

La oss snakke om noen andre ting som også bør være med. Vi skal ikke avsløre hele artikkelen for dem som ennå ikke har lest den, men én siste ting jeg vil ta opp, er prosjektstruktur, arbeidsnedbrytingsstruktur og en enkel ressursplan i prosjektinitieringsdokumentet eller prosjektbriefen. Når ting er ganske udefinerte i begynnelsen av prosjektet, hvordan lager du en plan – en foreløpig plan – før prosjektet har startet og du egentlig vet hvordan det kommer til å utvikle seg?

Maik Stettner:

For å være ærlig er det sannsynligvis et best mulig anslag på det tidspunktet. Du bygger trolig på arbeidsbeskrivelsen, det som allerede finnes, eller estimatet teamet laget. Det er fortsatt mange usikkerheter. Er kunden rask til å svare? Trenger vi et antall revisjoner? Er dette godt nok definert? Det er mange muligheter, og planen du lager, vil kanskje ikke bli gjennomført nøyaktig slik.

Men som jeg sa tidligere, er det nettopp derfor jeg mener at selv et omtrentlig anslag på en plan hjelper byrået og de andre prosjektteamene med å sikre riktige ressurser og holde teamet stabilt. Selv en litt ambisiøs innledende plan, som du kanskje fortsatt må få kunden til å godkjenne, hjelper deg å kartlegge ting fra ditt perspektiv og forstå noe av kompleksiteten teamet må håndtere.

Trenger du for eksempel en designer du ikke hadde tenkt på? Hvis du får teamet til å snakke om slike ting tidlig, forstår du som prosjektleder kompleksiteten i leveransen. Det hjelper deg å stille de riktige spørsmålene og styre kunden på en god måte. Selv en grov plan eller et anslag er bedre enn ingen plan, fordi folk kan snakke om den, og ting vil sannsynligvis bli mer detaljerte og mer realistiske etter hvert.

Ben Aston:

Det beskriver i det minste perspektivet om at en plan er bedre enn ingen plan, fordi du alltid kan videreutvikle den. Når du starter et prosjekt og setter deg ned med teamet for å gå gjennom prosjektbriefen, uten en reell plan for hvordan det skal leveres, og ingen har tenkt gjennom avhengighetene eller kundens rolle, starter du med svært lite fremdrift: «Ok, team, hvordan skal vi få dette gjort?»

Hvis du kommer til dem med en plan, har de i det minste noe å reagere på og si: «Maik, du er gal. Hvordan i all verden skal vi gjøre det?» Det gir et utgangspunkt for diskusjon i stedet for et blankt ark der alle bare ser på hverandre og lurer på hvordan dette skal leveres. En eller annen plan, selv om det er feil plan, er bedre enn ingen plan.

Vi har snakket om prosjektbriefen og prosjektinitieringsdokumentet, som høres ut som et svært formelt dokument. Men det trenger ikke være et stort og alvorlig dokument. Vi gir i hovedsak kontekst, parametere og plan. Hvilke former kan prosjektbriefen ta, og hvordan ser du for deg at rollen utvikler seg gjennom prosjektets livssyklus?

Maik Stettner:

Veiledningen jeg laget, er egentlig et eksempel på ting du kan ta med. Det finnes absolutt et minimum av informasjon som bør være med i et prosjektinitieringsdokument eller en prosjektbrief, men det finnes også andre måter å gjøre dette på. Du kan for eksempel lage en risikostyringsplan og samle dette i noe annet, eller bruke et RACI-diagram som kobles til statusrapporter og lignende.

Det trenger ikke alltid være veldig formelt. Det viktige er at alle er enige om det. Det kan publiseres i SharePoint eller BaseCamp, og selv om det videreutvikles og diskuteres, er det helt greit. Hvis prosjektet for eksempel kommer til et punkt der alle er enige om at «da vi avgrenset dette, glemte vi salgsaspektet, så vi må ta det med», har det naturligvis konsekvenser for omfanget som må håndteres.

Så lenge det er et dokument – selv en formell e-post – noe skriftlig som folk kan være enige om og som blir bekreftet, mener jeg det er tilstrekkelig. Det trenger ikke nødvendigvis signeres og stemples av alle parter, men som et minimum må det bekreftes, og alle må være komfortable med det, fordi det er dette som skal leveres og arbeides etter.

Ben Aston:

Hvis du fortsatt tenker etter å ha hørt dette at alt høres bra ut, men lurer på hvor du skal begynne, er den gode nyheten at Maik har laget en svært god mal du kan bruke til prosjektbriefen eller prosjektinitieringsdokumentet. Se artikkelen for å laste den ned. Maik, tusen takk for at du gjorde dette i dag. Det har vært flott å ha deg med.

Maik Stettner:

Takk for invitasjonen.

Ben Aston:

Bare hyggelig. Som en av DPM-ekspertene våre kan jeg fortelle at hvis du likte det Maik snakket om, kommer du til å bli glad for å høre at Maik skal delta på vårt kommende kurs, som starter i september, og heter Mestre digital prosjektledelse. Hvis du ikke vet hva jeg snakker om, men vet at du trenger opplæring i prosjektledelse, bør du ta en titt. Det er et intensivkurs på sju uker med interaktive videoleksjoner, ukentlige oppgaver, gruppediskusjoner og mulighet for veiledning. Gå til digitalprojectmanagerschool.com og meld deg på før kurset blir fullt.

Hvis du vil bidra til samtalen om prosjektinitieringsdokumenter eller prosjektbrief­er, kan du gå til ressursseksjonen på digitalprojectmanager.com og bli med i Slack-teamet vårt. Der finner du mange interessante diskusjoner. Husk også å kommentere artikkelen og dele den. Men frem til neste gang: Takk for at du lyttet.