Dette kan du slutte å gjøre i prosjektene dine (med Patrice Embry)
Presset for å gjøre det riktige og bli sett på som en som gjør det riktige, er enormt. Men bør vi virkelig gjøre alle disse prosjektstyringsoppgavene hele tiden? Ben Aston snakker med Patrice Embry om hvordan du kan spare tid ved å kutte ut det overflødige fra rutinene dine innen prosjektstyring.
Les transkripsjonen:
Vi prøver ut transkripsjon 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 Digital Project Manager-podkasten.
Vi får hele tiden høre alle tingene vi burde gjøre, og jeg er en av dem som faktisk gjør det. Det finnes et press om å forbedre seg selv, gjøre ting riktig og faktisk bli sett på som en som gjør de riktige tingene. Men bør vi gjøre alle disse tingene hele tiden? Fortsett å lytte til denne episoden for å finne ut hvordan du kan spare masse tid ved å kutte ut eller redusere enkelte ting i prosjektleder rutinene dine som du kanskje ikke trenger i hvert prosjekt.
Vi skal snakke om hvordan du kan få tilbake noe av livet ditt og tilbringe mindre tid på kontoret eller ved skrivebordet ved å kutte ut seks ting som kan spare deg for tid. Denne podkasten handler virkelig om å frigjøre seg fra alle disse «burde»- og «må»-kravene og bli litt mer effektiv i måten vi gjør ting på.
I dag har jeg med meg Patrice Embry, som faktisk – og dette må jeg berømme henne for – sannsynligvis er den mest aktive deltakeren i Slack-teamet vårt. Hvis du ikke har blitt med ennå, kan du kanskje snakke med Patrice akkurat nå. Hvis du går til fellesskapsseksjonen på Digital Project Manager, kan du registrere deg der. Patrice er nesten alltid til stede og prater, så hun er en god person å kjenne.
Som en kort introduksjon er Patrice en frilansende digital prosjektleder. Hun er sertifisert Scrum Master II. Hun har jobbet i bransjen svært lenge, i mange ulike byråer og selskaper. Sjekk ut noen av de andre podkastene våre for å få en bedre forståelse av hva slags arbeid hun har gjort. Hun har jobbet med alt mulig, så hun er en flott person å kjenne.
Velkommen, Patrice.
Patrice Embry:
Hei. Takk for at du inviterte meg.
Ben Aston:
Bare hyggelig. Patrice, kan du fortelle oss om det er noen interessante prosjekter du jobber med akkurat nå siden sist vi snakket sammen?
Patrice Embry:
Jeg avsluttet nettopp en app jeg jobbet med, som hjelper folk som ser etter kortvarige og raske oppdrag. Litt som Care.com, men enda raskere, for folk som virkelig trenger at slike kortvarige jobber blir gjort. Det var en veldig interessant app. Den har ikke blitt lansert ennå … den er i betaversjon nå, så den er ikke helt klar for verden, men det var et veldig interessant prosjekt fordi jeg jobbet med mennesker fra hele verden.
Jeg har aldri jobbet med noen fra Nigeria før, så dette var første gang jeg sa hei på igbo, og det var veldig morsomt.
Ben Aston:
Det høres ut som et svindelprosjekt. Ikke selve prosjektet, altså. Dette er åpenbart klassisk nigeriansk svindel. Så utviklingsteamet var der?
Patrice Embry:
Unnskyld?
Ben Aston:
Var utviklingsteamet i Nigeria?
Patrice Embry:
Ja.
Ben Aston:
Å, virkelig?
Patrice Embry:
Ja. Designeren for brukergrensesnittet var i … utvikleren av brukergrensesnittet var i Nigeria. Utvikleren av backend-løsningen var i Mexico, og den tekniske lederen vår var i Sverige. Så var det meg utenfor Philadelphia og kunden i Boston. Vi var spredt overalt.
Ben Aston:
Det er mange tidssoner å forholde seg til.
Patrice Embry:
Ja, det er det.
Ben Aston:
Det må ha vært lite morsomt. Hvordan fikk du det til å fungere?
Patrice Embry:
Jeg fant et tidspunkt alle kunne leve med, nemlig klokken 08.00 østkysttid. De europeiske kollegene våre syntes det var litt sent på dagen, det var ganske sent for vår nigerianske kollega, og Mexico måtte stå opp litt tidligere enn han ønsket, men vi fikk det til å fungere.
Ben Aston:
Kult. Er appen for en oppstartsbedrift, eller er den for …
Patrice Embry:
Ja. Det er en … Jeg tror det var en tjeneste som oppsto fordi en kvinne gjorde dette for et par personer, og noen andre spurte: «Hei, kan du gjøre det for meg også?» Det fortsatte slik helt til hun sa: «Vet du hva, jeg klarer ikke å håndtere dette … jeg kan ikke koordinere alt alene lenger.» Og jeg tror hun tenkte: «La oss lage en app for dette.» Den er fortsatt helt i startfasen, så jeg vil ikke fortelle for mye om den ennå, men når den lanseres, skal jeg sørge for å fortelle alle om den. Jeg tror det blir en veldig nyttig tjeneste for folk.
Ben Aston:
Kult. Det høres ut som et interessant prosjekt. Hvilke store utfordringer møtte du? Var det enkelt, eller støtte du på noen vanskelige problemer underveis?
Patrice Embry:
Det var litt vanskelig fordi kunden egentlig ikke var særlig datakyndig. Hun var heller ikke spesielt erfaren med apper. Hun hadde et normalt kunnskapsnivå om hvordan ting fungerer. Som du vet, har man i teknologibransjen gjerne litt større forståelse for hvordan ting fungerer, så det ble mye forklaring.
Det var omtrent som å forklare en venn som ikke bruker datamaskin hver dag hvordan ting fungerer. Det var litt av dette. Noen ganger er det først når man blir ordentlig involvert i et prosjekt som dette, at man oppdager ting ingen har tenkt på. Testingen, som er grunnen til at den nå er i betaversjon, var svært omfattende, fordi vi stadig sa: «Å, dette er en vei vi aldri har gått før.» Det gjorde prosjektet utfordrende, men det var veldig morsomt. Det var morsomt å jobbe med alle, og det er en virkelig god idé. Jeg er ganske fornøyd med den.
Ben Aston:
Hvilke verktøy brukte du for å håndtere alle disse forskjellige menneskene i ulike tidssoner? Hvordan hentet du inn de ulike kravene fra den innledende briefen, som virket litt løs, og hvordan styrte du egentlig prosjektet?
Patrice Embry:
Ja, den var veldig løs. Det var ikke særlig mye ekstra penger å bruke, noe som passer godt med det vi snakker om i dag. Jeg hadde ikke mange timer til å bruke på alt mulig. Jeg måtte være svært selektiv med hva jeg gjorde og ikke gjorde, fordi jeg ikke ville bruke opp budsjettet på mine egne timer. Jeg ville spare så mange timer som mulig til selve utviklingen.
Vi brukte Slack fordi det var gratis. Vi brukte Trello fordi det var gratis. Vi brukte mange Google-dokumenter fordi de var gratis. Vi måtte finne ut hvordan vi kunne få alt dette til å fungere uten noen betalte funksjoner, fordi vi måtte være så kostnadseffektive som mulig for å få dette prosjektet i gang for denne kvinnen.
Ben Aston:
Så hvordan fant du prosjektet? Var det bare en anbefaling fra en venn av en venn, siden det høres ut som en oppstartsbedrift?
Patrice Embry:
Ja. Du kjenner meg. Du nevnte at jeg er på Slack hele tiden, men Slack-kanalen din er ikke den eneste jeg alltid er på. Som frilanser må du hele tiden sørge for at kommunikasjonslinjene dine er åpne med alle, slik at du kan få inn så mye informasjon som mulig. Jeg snakker med mange mennesker om mange ting.
Jeg husker ikke den lange rekken av hendelser som førte meg til dette prosjektet, men det var mye av typen: «Hei, jeg tror jeg kjenner en person som kanskje har hørt om dette fra et annet sted. Er det noen som vet om noen som gjør dette?» Det var nok mye slikt, men jeg driver mye med nettverking, så ting kommer til meg på ganske merkelige måter.
Ben Aston:
Var det du som satte sammen prosjektteamet?
Patrice Embry:
Nei.
Ben Aston:
Var det noe du gjorde?
Patrice Embry:
Nei. Jeg ble satt inn i en gruppe med mennesker, og så fant vi ut hvem som skulle gjøre hva. Jeg trengte ikke å finne ressursene til dette prosjektet. Jeg var veldig fornøyd med teamet jeg ble satt sammen med, og jeg kommer til å kommunisere med dem i fremtiden. Forhåpentligvis får vi alle jobbe sammen igjen, fordi jeg virkelig satte pris på det alle bidro med.
Ben Aston:
Ja, det er kult. Jeg synes det alltid er interessant å jobbe med slike prosjekter, der kunden kanskje ikke er så erfaren, men det betyr ofte også at det er mye fleksibilitet. Det er fantastisk å ha en kunde som stoler på deg, ikke helt vet hva de gjør, men sier: «Dere er ekspertene, bare fortell meg hva vi bør gjøre.» Og da tenker man: «Dette er den beste tiden.» Man kan gjøre mange av de riktige tingene.
Ulempen er at man får den smerten som følger med: «Greit. Prøv å trykke Ctrl F5.»
Patrice Embry:
Det var mye av det, ja. Men vet du hva, det er bra å huske på, særlig når man lager en app for folk flest. Ikke alle har samme utgangspunkt når det gjelder kunnskap om hvordan ting fungerer. På en måte var det bra at vi måtte gå tilbake til det grunnleggende, fordi vi måtte huske å gjøre det samme med selve appen. Vi kunne ikke bare ta for gitt at folk forsto at de kunne bruke fingeren til å bla og dermed se resten av skjemaet.
Vi måtte gjøre det tydelig at man måtte bla. Det fungerte faktisk godt for dette prosjektet.
Ben Aston:
Bra saker. La oss snakke om det du nevnte, og som jeg snakket om tidligere. Vi diskuterte på Slack sannheten om hvordan vi faktisk styrer prosjekter. På den ene siden finnes teorien, og som jeg sa, publiserer vi på Digital Project Manager artikler om hvordan vi bør drive prosjekter, eller den riktige måten å gjøre det på, altså beste praksis vi kan innføre i prosjektene våre.
Jeg tenkte det kunne være interessant å snakke om den faktiske sannheten eller virkeligheten i hvordan vi styrer prosjekter fra dag til dag, når det er så mye som skal gjøres. Særlig hvis du har fått ordentlig prosjektlederopplæring, som PMP, og kjenner PMBOK, alle prosessene og arbeidsflytene du burde ta i bruk, samtidig som du har alle disse ulike registrene og statusrapportene. Da blir det fort et stort administrativt mareritt.
Sannheten er at vi alltid er overbelastet, og det finnes alltid dokumentasjon du kunne oppdatert eller ting du kunne gjort. Derfor syntes jeg det var interessant å snakke om hvorvidt vi gjør ting fordi det er det riktige, eller om vi bruker for mye innsats på feil ting. Vi snakket nettopp om ideen om «start, stopp, fortsett». Hva bør vi begynne å gjøre? Hva bør vi slutte å gjøre eller redusere? Hva kan vi fortsette å gjøre?
Jeg vil gjerne høre perspektivet ditt på hvilke ting som er helt ufravikelige. Når du kommer inn i et prosjekt, kanskje et som ligner på det du nettopp snakket om, hva er det du tenker: «Som et absolutt minimum må jeg sørge for at disse tingene er på plass, ellers stopper prosjektet helt opp eller sporer av før vi har begynt»?
Patrice Embry:
For meg handler det alltid om tidsplan og krav. Deretter kommer budsjettet. Budsjettet er viktig på ulike måter i ulike prosjekter, men jeg tror aldri du kan komme unna å ha en tidsplan, en ganske detaljert tidsplan. Du kan virkelig ikke klare deg uten krav, for ellers vet du ikke hva du gjør, og teamet ditt vet heller ikke hva de skal gjøre. Dette er de to tingene som absolutt må være på plass. Etter min mening er dette de ufravikelige kravene.
Ben Aston:
Bare for å være tydelig: Når du snakker om krav, mener du da ikke en arbeidsbeskrivelse? Hvilket format har kravene da?
Patrice Embry:
Det er et godt poeng, for de trenger ikke nødvendigvis å stå i et dokument. Men man må vite hva omfanget er, og også hva som ligger like utenfor omfanget. Ett steg videre enn omfanget: Hva må dette faktisk gjøre? Hvis jeg ser på en arbeidsbeskrivelse, tar den vanligvis enkelte ting for gitt. Ikke alt er beskrevet i arbeidsbeskrivelsen, og det vil finnes et nytt lag med ting som må gjøres, diskuteres eller vurderes, samt funksjoner som må være på plass for at omfanget skal bli realisert. Det er dette jeg snakker om.
De må defineres. Folk må vite hva de er. De vil styre det folk gjør. Ellers vet du egentlig ikke hva du bygger. Det er denne typen krav jeg mener.
Ben Aston:
Ja, det stemmer virkelig. For meg handler det om estimat, tidsplan og arbeidsbeskrivelse når jeg først kommer inn i et prosjekt og skal avstemme forventningene. Det er denne typen dokumentasjon jeg prøver å finne, fordi hvis du ikke kjenner tidsplanen eller kravene, finnes det ingen måte å styre og kontrollere prosjektet på. Hvis du ikke vet hvordan det skal være, vet du ikke om du er på rett spor.
Patrice Embry:
Hvordan skal vi vite om det er ferdig? Hvordan skal vi vite om det ikke har stoppet opp? Ja, nettopp.
Ben Aston:
Vanligvis er det nettopp disse tingene som, når du arver et prosjekt, ofte er litt utdaterte når du mottar dem. Særlig kravene eller arbeidsbeskrivelsen. Det kan være: «Ja, vi snakket om det og ble enige om å gjøre noe annet.»
Hvordan avstemmer du dette, hvis det er de ufravikelige kravene, og sørger for at alle er på samme side gjennom hele prosjektet?
Patrice Embry:
Jeg minner folk på tidsplanen hver uke, eller hver gang vi møtes for å snakke om prosjektet. Det kan være mer enn én gang i uken, eller annenhver uke. Det avhenger av prosjektet, men jeg minner alltid folk på hvor vi er i tidsplanen, hva neste frist er, og vanligvis også fristen etter den, slik at vi vet hva vi arbeider mot.
Jeg minner dem på sluttdatoen og hva vi arbeider mot. Ikke nødvendigvis lanseringsdatoen, men vanligvis når vi må være i kvalitetssikring eller brukerakseptansetesting. Jeg minner alle på dette, og hvis det endrer seg, sørger jeg alltid for å informere folk. Hvis vi står i fare for å miste noe, er det da folk hører mest fra meg.
Når det gjelder krav, prøver jeg å holde dem oppdatert så mye som mulig. Det er fint når de ligger i et system som Trello eller Jira, der man kan fortsette å diskutere hva noe skal være, se hvordan ting utvikler seg og finne den siste versjonen av det vi sa vi skulle gjøre for en funksjon. Alt kan samles på ett søkbart sted. Det kan man finne ut av.
Hvis det er slik dere arbeider, må dere holde dette oppdatert. Hvis dere ikke bruker slike verktøy, handler det om å holde en form for dokumentasjon oppdatert med ting dere har bestemt sammen med kunden, ting dere har bestemt for å spare tid, eller ting dere vet at dere må legge til senere. Det er en kontinuerlig oppdatering av dokumentasjonen dere har, uansett hvilken form den har.
Ben Aston:
Ja, absolutt. For meg skriver jeg ofte en arbeidsbeskrivelse og sender deretter endringsforespørsler eller oppdateringer til arbeidsbeskrivelsen, vanligvis som et Word-dokument, hver gang prosjektet endrer retning. Da har jeg en kundesignatur på: «Ja, jeg vet og forstår at vi gjør denne endringen, og jeg godkjenner den.»
Hele papirsporet med å holde oversikt over dette kan være svært viktig, særlig hvis du har flere kunder eller det er forvirring rundt hvem som faktisk har ansvaret for prosjektet.
Patrice Embry:
Absolutt.
Ben Aston:
La oss gå videre og snakke om noen av tingene. Hvis de ufravikelige kravene er arbeidsbeskrivelsen, kravene, tidsplanen og estimatet, kan vi snakke om noen av tingene vi nevnte, som vi kanskje ikke trenger å gå helt i dybden på eller overkonstruere. En av tingene du snakker om i artikkelen, er detaljerte budsjetter og prosjektoppdelinger. Vil du si litt om det?
Patrice Embry:
Jeg startet i en bakgrunn der det var mye av typen: «Slik fungerer absolutt alt.» Jeg var et tannhjul i et svært stort maskineri med mange andre prosjektledere som gjorde mange ting. Vi var mange, og alle måtte gjøre alt på samme måte. Det var mye «slik gjør man ting».
Det var først da jeg begynte å jobbe for mindre byråer og senere frilans, at jeg tenkte: «Du kan ikke alltid gjøre alt dette, for det blir veldig vanskelig å holde budsjettet intakt, og du har kanskje ikke tid.» Da jeg jobbet i det store byrået og gjorde alle tingene man måtte gjøre, var et av dem et svært detaljert budsjett. Det var gammeldags. Jeg lager fortsatt budsjettene mine ganske gammeldags. Jeg legger dem i et regneark med pivottabeller, betinget formatering og celler som viser til andre celler. Da kunne man se prosentandelen som var fullført, hva som gjensto, hvordan dette sto mot budsjettet og hvor langt unna vi var prognosene. Prognosene ble laget ukentlig per rolle.
Det er ganske omfattende, og det fungerer stort sett svært godt for meg, fordi jeg kan svare på ethvert spørsmål når som helst hvis jeg holder budsjettet så detaljert. Men hvis det å holde budsjettet så detaljert krever mange flere av arbeidstimene mine, og det ikke er noe kunden bryr seg om, eller noe den som betaler lønnen din bryr seg om – enten det er kunden, byrået eller noen du arbeider med – må du sørge for at det du leverer, er det som trengs.
For meg ville det bety å ha en mindre detaljert oppdeling av budsjett og prognoser enn jeg er vant til. Det tok litt tid å bli komfortabel med det, men det finnes et nivå av rapportering du kanskje ikke trenger å gjøre. Mitt forslag til folk som tenker «Trenger jeg virkelig å gjøre alt dette?» er å spørre seg selv hva man faktisk må gjøre. Hvor mye av dette trenger du å gjøre? Kan du gjøre mindre av det? Vil det skade budsjettet om du gjør mer? Vil det skade prosjektet om du gjør mindre? Finn ut av dette i stedet for å lage omfattende budsjettoppdelinger av ren pliktfølelse. Gjør det heller fordi det er bra for prosjektet.
Ben Aston:
Det var nyttig. Jeg lurer likevel på om du setter prosjektleder tiden som en prosentandel av det totale antallet timer i teamet du styrer, eller om du vanligvis gjør det per oppgave?
Patrice Embry:
Tidligere gjorde jeg det prosentvis, men da jeg jobbet i større byråer, oppdaget jeg fordelen ved å ha jobbet mange forskjellige steder, i lang tid og med mange ulike typer arbeid. Jeg har en interessant bakgrunn innen mange områder.
Jeg pleide å gjøre det prosentvis, og det fungerer svært godt hvis du har noe som kan absorbere ting du ikke hadde tenkt på. Jeg kan bruke en prosentandel hvis det betyr at jeg slipper å tenke for mye på hvor mye jeg kommer til å overskride. Jeg har funnet ut at jeg virkelig må se på hver enkelt oppgave. Jeg er ganske nøye med estimering og har et sterkt syn på det.
Vanligvis ser jeg på hele prosjektets oppdeling av oppgaver. Hvis jeg skal bruke en prosentandel av tiden, beregner jeg den som en prosentandel av oppgaven. Jeg bruker ikke lenger en prosentandel av totalen, fordi jeg føler at det for mindre aktører og for meg som frilanser ikke er målrettet nok til å dekke det jeg trenger. Jeg beregner det ikke som en prosentandel av helheten lenger.
Jeg synes det er helt greit å gjøre det slik, og hvis det fungerer for deg, bør du fortsette. For meg har det i det siste ikke dekket det jeg trengte.
Ben Aston:
Jeg forstår. Det var altså ikke for mye, men at du ikke hadde nok timer?
Patrice Embry:
Ja. Jeg hadde ikke nok timer, eller …
Ben Aston:
Hvilken prosentandel brukte du?
Patrice Embry:
Jeg var vant til å jobbe sammen med kundeansvarlige, og jeg foreslo 20 % av totalen til kundeoppfølging. I tillegg 20 % til prosjektledelse, og det er mye.
Ben Aston:
Det er mye. Det er jo 40 %.
Patrice Embry:
Det er mye. Prosentandeler tar ikke høyde for alt. Prosjekttypene jeg jobbet med … Dette er en hel boks med problemer vi åpner, men hvis grunnlaget som faktureres ikke er riktig fra begynnelsen, er prosentandelen meningsløs.
Hvis noen ikke har priset prosjektet riktig, vil heller ikke prosentandelen bli riktig. Jeg fant ut at det ikke fungerte fordi jeg ikke hadde nok timer. Det var ikke bare jeg som manglet timer; vanligvis manglet ingen nok timer. Prosjektet var rett og slett ikke priset riktig. Det bringer oss tilbake til at estimatene må være riktige. Du vil tjene penger på prosjektet. Det kan hende at prosentandelene ikke fungerte for meg fordi de var basert på et tall som var feil fra starten.
Ben Aston:
Ja, det er helt riktig. Jeg er vant til å si at prosjektledelse bør utgjøre 20 % av den totale prosjektkostnaden, og at kundeoppfølging kommer i tillegg, men ikke nødvendigvis så mye som 20 %. Det viktige her er at vi snakket om krav, altså kravene til prosjektet. Vi må tilpasse den detaljerte budsjett- og prognosemodellen til kunden vi jobber for. Vi trenger ikke overdrive eller overkonstruere dette.
Det handler også om kundens interesse og vilje til å betale for det. Hvis du har en svært risikoavers kunde som vil kjenne hver minste detalj i ressursoppdelingen og hvordan den vil utvikle seg gjennom hele prosjektet, er det en pedagogisk oppgave. Det koster penger å gjøre dette.
Jeg vet at det finnes prosjektstyringsverktøy der du legger inn alle tallene i begynnelsen, og hvis tidsregistrering og prosjektstyring er integrert i ett system, kan det gjøre alt for deg. I virkeligheten er dette en manuell prosess for de fleste prosjektene våre. Vi henter timene fra et sted, legger dem inn i et regneark og gjør beregninger. Det er en stor og kostbar oppgave.
Hvis du velger en enklere tilnærming og sier at dere ikke skal levere en detaljert budsjettoppdeling, hvordan sørger du da for at du holder kursen? Hva er din enklere metode når du ikke er så detaljert? Hvordan gjør du det?
Patrice Embry:
Tidligere ville jeg ha delt opp den samlede prognosen for timene og laget budsjett og prognoser for hver rolle. Jeg førte vanligvis inn faktiske tall og justerte deretter prognosene for resten av prosjektet. Jeg kunne si: «Jeg brukte for mye denne uken, så jeg må hente det inn et annet sted. Prognosene for de andre ukene må derfor endres litt. Jeg ble ferdig raskere, så jeg har mer tid og kan justere prognosene.»
Det er det første jeg ville kuttet ut hvis jeg visste at jeg ikke hadde nok tid, budsjett eller kapasitet til å ha et så omfattende budsjett. Du ville fortsatt ha prognosene fra begynnelsen og kunne se hvor du lå an, men du ville ikke nødvendigvis justere hver eneste prognose hver gang du oppdaterte budsjettarket. For meg ville det normalt vært én gang i uken. Det tok ganske mye tid å finne ut hvordan jeg skulle gjøre dette.
Fordelen var at jeg tidlig visste hvor vi kom til å få problemer. Du kan heve et rødt flagg mye tidligere, men det tar mye tid. Det koster meg penger å gjøre dette, så det finnes andre måter å identifisere røde flagg på. Det ville trolig vært det første jeg kuttet ut.
Alle beregningene jeg gjorde for å kunne dele opp og analysere hver informasjonsbit på fem forskjellige måter, ville vært det neste. Gå tilbake til det grunnleggende: Holder vi budsjettet? Står vi i fare for å overskride det? Har vi nok timer igjen til å gjøre det vi må? Ligner prosentandelen som er fullført, på prosentandelen av budsjettet som er brukt? Ja? Flott. Da fortsetter vi.
Ikke lag regnearket eller bruk verktøyet til det ytterste. Fokuser på det grunnleggende.
Ben Aston:
Dette var nyttig. Det er viktig å merke seg at vi snakker om hvordan vi skalerer tilnærmingen vår for ulike prosjekter og kunder. Hvis du driver et stort prosjekt med mange ressurser, må du selvsagt være klar over at forbrukstakten blir mye høyere. Evnen til å endre kurs blir mindre hvis du bruker 50 000 på budsjettet hver uke. Etter en halv uke har du brukt 25 000.
Vi må også tenke på hvordan vi tilpasser budsjettoppfølgingen i store prosjekter. Rapportering er én ting, men hvor detaljert vi går inn i tallene, må også tilpasses totalbudsjettet.
Hvis du har et mye mindre team og bare noen få ressurser, er konsekvensen av å vente litt lenger før du kontrollerer dataene, naturligvis ikke like stor.
Patrice Embry:
Jeg ville fortsatt kontrollert alt hver uke, men jeg ville ikke overanalysert det jeg så. Jeg ville tatt tallene litt mer for pålydende. Tro det eller ei, jeg har møtt kunder eller oppdragsgivere som har leid meg inn. Det finnes en kunde, og det finnes noen som betaler meg, men som ikke er kunden, mer som en kundeansvarlig. De hadde solgt noe til kunden til fastpris og sa til meg at de ikke brydde seg om budsjettoverskridelser. Jeg tenkte: «Greit.»
Det er fantastisk, men samtidig tenker man at hvis man ikke har noen rammer rundt noe, kan det løpe fullstendig løpsk. Uansett om du ville at jeg skulle lage et budsjett, kom jeg til å gjøre det, fordi det ville vært uansvarlig å la være. Jeg må kunne vise hva alle har gjort i den tiden de har brukt. Selv når han sier: «Penger er ikke noe problem.» Det høres flott ut, men det gjorde meg faktisk litt nervøs, fordi jeg tenkte: «Hvordan skal vi vite om vi gjør dette riktig?»
Ben Aston:
Det er også nesten alltid misvisende, fordi når folk sier «penger er ikke noe problem», eller «det går fint at vi overskrider budsjettet», er det stor forskjell på å overskride budsjettet med 10 000 og med 100 000 eller 500 000.
Patrice Embry:
Etter en stund blir det noe du ikke legger merke til lenger. Du ser det ikke engang. Du kan være så langt over budsjett at det bokstavelig talt ikke spiller noen rolle, og så gjør alle akkurat som de vil. Det er forferdelig. Jeg har vært med på slike prosjekter, og det er fælt.
Ben Aston:
Når teamet sier: «Å ja, vi overskred budsjettet for tre måneder siden.»
Patrice Embry:
Så hvem bryr seg?
Ben Aston:
Da bruker folk bare mer og mer tid på prosjektet, og situasjonen blir verre og verre. Når det som gjenstår av budsjettet er null, begynner man å lure på om man skal føre negative tall.
Noen må holde oversikt. Vi var inne på statusoppdateringer, som er et av punktene dine i artikkelen om hvor omfattende statusoppdateringen bør være. I en statusrapport som vi sender til kundene, pleier vi å oppdatere budsjettstatus, hva vi brukte denne uken, hva vi gjør og hva vi planlegger å gjøre neste uke. Det finnes også andre ting man kan ta med, som budsjettoppdelinger, prognoser, risikoer og problemer. Man kan putte hva som helst i en statusrapport.
Hvordan tilpasser du den?
Patrice Embry:
Det er morsomt, for jeg føler at vi som prosjektledere noen ganger ubevisst opplever statusrapportene som et uttrykk for verdien vi tilfører prosjektet. Hvis statusoppdateringen ikke ser omfattende ut, betyr det da at du ikke er en god prosjektleder?
Jeg vil aldri at noen skal si til meg: «Hva gjør du med alle disse timene? Hva gjør du egentlig?» Noen ganger føler jeg at vi putter alt inn i statusrapportene for å vise verdien vår, vise at vi holder oversikt over alt eller vise byrået at vi gjør alle disse tingene. Det tar mye tid og innsats å oppdatere alt, og du trenger kanskje ikke gjøre det.
I det siste arbeidet jeg gjorde med appen, var kunden ikke særlig teknisk erfaren. Alt hun brydde seg om, var om ting gikk bra, om vi kom til å holde datoen vi hadde sagt, og om vi ventet på noe fra henne. Hun ville ikke være en flaskehals. Det meste av tiden deltok hun ikke engang i statusmøtene, fordi hun var opptatt med andre ting, og dette var egentlig ikke en prioritet for henne. Hun ville bare vite tre ting: Går det bra? Kommer vi til å bli ferdige i tide? Trenger dere noe fra meg?
Jeg laget disse statusrapportene og tenkte: «Hvorfor gjør jeg dette? Jeg trenger ikke gjøre det.» Jeg hadde en hel del om hva vi hadde gjort forrige uke, hva vi planla å gjøre denne uken, og hva … Hun brydde seg ikke om noe av dette.
Jeg liker å tro at hun stolte på meg, men egentlig hadde hun nok bare ikke tid. Men vi sier at hun stolte på meg. Hun stolte på at jeg sørget for at alt fungerte, og hun ville bare vite at det gikk bra.
Dette er én type kunde. Det finnes mange typer kunder. Poenget er å tenke på kunden i det aktuelle prosjektet og hva de bryr seg om. Ikke fyll rapporten med andre ting bare for å vise verdien din og si: «Se på alt jeg har gjort, eller alt vi har gjort.» Du kan sannsynligvis kutte ut en god del fra statusrapportene hvis du bare fokuserer på det du trenger, eller det kunden ønsker.
Ben Aston:
Det er et godt råd. Når vi starter på et prosjekt, er vi ofte – jeg er skyldig i dette – fristet til å ta den forrige statusrapporten, endre kundenavn og dato og si: «Denne var god. La oss bruke den.»
Så oppdager du at du har lagt inn informasjon og detaljer som den forrige kunden ba om, og tenker: «Ja, det var nyttig. La oss gjøre det igjen.» Dermed ender du noen ganger opp med en oppblåst statusrapport. Kunden er egentlig ikke interessert i alle detaljene, men vil bare vite om alt går bra eller ikke. Vi ender med å gi dem informasjon de ikke trenger.
Jeg synes vi bør tenke på hvordan vi kan redusere dette til det absolutte minimum i utgangspunktet. Hvis kunden virkelig ønsker mer informasjon, kan de be om det, og da kan vi legge det til. Men vi må være trygge på at dette er all informasjonen de trenger. Når det begynner å ta timer å lage en statusrapport, bør det være et rødt flagg om at noe ikke er riktig.
Patrice Embry:
Jeg har hatt kunder som har bedt meg om ting. Jeg har fått spørsmål om en annen måte å se budsjettallene på eller mer informasjon om arbeidet vi gjorde. Da har jeg måttet si: «Jeg har budsjettert med en viss tid til disse statusrapportene, og akkurat nå bruker jeg et visst antall timer i uken på å lage dem. Hvis du vil at jeg skal fortsette slik, går det fint, men hvis du vil at jeg skal legge til noe, vil det ta minst en ekstra time per statusrapport.»
Det høres kanskje ikke mye ut, før du innser hvor mange timer dette blir i løpet av resten av prosjektet. «Er du sikker på at du vil at jeg skal gjøre det?» Som regel sier de: «Kan du gjøre det én gang, så ser vi om vi trenger å fortsette?» Eller: «Det er ikke så viktig, jeg syntes bare det kunne være interessant å vite.» Da kan man ofte snakke dem bort fra det.
Ben Aston:
Det stemmer. Når du forklarer konsekvensen av det noen ber om og sier: «Hvis du vil ha én ekstra time i uken de neste 25 ukene …»
Patrice Embry:
Er du sikker?
Ben Aston:
«… er du klar over at dette kommer til å koste deg 5 000?» Da sier de: «Nei, det er ikke verdt så mye.»
Patrice Embry:
Nettopp.
Ben Aston:
Greit, da lar vi være. Jeg vil likevel legge til ett forbehold: Hvis du jobber med et risikofylt prosjekt, en vanskelig kunde eller et prosjekt der du vet at ting kan gå galt, ville jeg ikke bare valgt minimumstilnærmingen. Da ville jeg løftet risikoene i statusrapporten og sørget for en løpende samtale om dem. Vi må ikke redusere rapporteringen så mye at vi står uten dokumentasjon på at vi noen gang sa fra om noe som kunne gå galt.
Når prosjekter går galt, vil vi ikke stå igjen uten bevis på at vi noen gang tok opp problemet.
Patrice Embry:
Absolutt.
Ben Aston:
Det bør være mulig.
Patrice Embry:
Tommelfingerregelen er at du må være svært trygg før du fjerner noe. Du må være sikker på at du ikke trenger det, og at du kan legge det til igjen hvis du skulle få behov for det. Tryggheten kan komme av at du har jobbet med kunden før, jobbet med denne typen prosjekt før eller vært prosjektleder lenge. Uansett hvor komfortabel du er med å gjøre dette, bør det være veiledende. Det hjelper deg å sørge for at du ikke kutter ut noe du faktisk trenger.
Ben Aston:
Helt klart. La det være en advarsel. Neste punkt du tar opp, og som jeg synes er svært interessant, er alle Scrum-seremoniene. Når vi bruker Scrum, finnes det seremonier, og det er det som gjør Scrum til Scrum. Hvis du har tatt Scrum Master-kurs, er det dette du lærer. Du bruker to dager på å lære om disse seremoniene: Scrum-planlegging, Scrum-gjennomganger og retrospektiver. Men i virkeligheten, når du legger alt dette inn i prosjektet, kjører du kanskje en sprint på én uke, eller en sprint på to uker, og bruker deretter én eller to dager på møter, planlegging, gjennomganger og seremonier. Det kan ta mye tid.
Forslaget ditt er kanskje at man ikke trenger å gjøre alle disse tingene hele tiden, eller at man kan slå dem sammen.
Patrice Embry:
Jeg kjenner folk som er svært Scrum-fokuserte. De blir opprørt hvis du foreslår å gjøre noe litt annerledes. Jeg tror de fleste sertifiserte Scrum Mastere er enige i at man ikke bør gjøre ting som ikke er nødvendige for et prosjekt. Det alle kan være enige om, er at man må vurdere om dette faktisk er nødvendig.
Hvis du har et møte for å bearbeide produktkøen, deretter et sprintplanleggingsmøte, så en sprintgjennomgang, og alt skjer på ulike dager eller tidspunkter, kan det raskt bli krevende hvis du ikke har budsjett til det.
Igjen handler mye om hvor mye tid og budsjett du har. Hvis du har tid og budsjett, kjør på. Hvis ikke, kan du vurdere å slå sammen bearbeiding, planlegging og gjennomgang. Det kan gi deg bedre fremdrift. I stedet for å gjøre én ting, stoppe, gjøre noe annet og så komme tilbake til det samme prosjektet for å planlegge, kan du dra nytte av fremdriften fra bearbeidingen av produktkøen og gjennomgangen når du planlegger. Det kan gi bedre innsikt, fordi du nettopp har snakket om hva som skjedde, og hvilke oppgaver som ligger i produktkøen.
Bruk skjønn. Hvis det føles som om du bruker tre timer på noe som kunne vært gjort på 90 minutter eller én time og 15 minutter, bør du kanskje se nærmere på det.
Ben Aston:
Forslaget om at disse ikke alltid trenger å være separate aktiviteter, er svært nyttig. Særlig retrospektivene, som du også nevnte. Målet med retrospektiver er kontinuerlig forbedring, og vi utvikler hele tiden måten vi styrer prosjektet på.
Du nevner i artikkelen at man bør holde det enkelt, for eksempel med retrospektivet. Jeg har selv gjennomført retrospektiver der vi sender ut en spørreundersøkelse, samler inn tilbakemeldinger og lager statistikk: 49 % mente at prosjektet var en katastrofe, 25 % … Er det egentlig nyttig? Hva skal du gjøre med det? Hva skal du gjøre med det etter dette øyeblikket?
Vi bør slå sammen ting og tilpasse dem til hvor alvorlig problemet faktisk var. Noen ganger gjør vi en retrospektiv og tenker: «Vet du hva? Denne sprinten gikk helt fint.»
Patrice Embry:
Alt er bra. Alt er flott. To tomler opp.
Ben Aston:
Greit. Da trenger vi ikke overkonstruere slike rapporter. Bare gå videre. Ikke bruk en time til på det. Noen ganger blir vi fanget i tanken om at dette er det vi skal gjøre.
Patrice Embry:
Ja.
Ben Aston:
I stedet for å være pragmatiske og si: «La oss bare få dette prosjektet ferdig.»
Patrice Embry:
Ja. Det er enten det, eller at statusrapportene får oss til å føle at vi viser kundene verdien vår og rettferdiggjør vår egen eksistens overfor dem. Retrospektiver kan noen ganger få oss til å føle at vi rettferdiggjør vår eksistens overfor interne interessenter, eiere av byråer eller selskapseiere. Som vi sier om alt dette: Spør deg selv hvor nyttig det blir, og om det er verdt fem arbeidstimer, to arbeidstimer eller 30 minutter. Jeg har 30 minutter. La oss bare finne ut om vi synes dette var et godt prosjekt, og hvis det var én åpenbar ting som var galt, identifiserer vi den og går videre.
Ben Aston:
Bra. Til slutt kan vi snakke om oppstartsmøter. For meg er dette veldig interessant. I artikkelen din foreslår du at man kanskje ikke trenger et oppstartsmøte, men kan sende en e-post i stedet. Det synes jeg er fascinerende, for det har jeg aldri gjort. Hvordan får du det til? Du starter et nytt prosjekt, setter sammen et team, alle får ressurser, og så sender du bare ut en e-post som sier: «Dette skal dere gjøre»?
Patrice Embry:
Ja.
Ben Aston:
Vi sees om en uke.
Patrice Embry:
Ja. Vet du hva …
Ben Aston:
Hvordan fungerer det?
Patrice Embry:
Jeg vet at det høres sprøtt ut, men dette begynte jeg med da jeg jobbet i et legemiddelbyrå, der vi gjorde mange av de samme prosjekttypene for ulike kunder. Jeg vil ikke si at det var formelbasert, men det var ikke mange nye og uvanlige ting vi gjorde for hvert enkelt stykke materiell. Dette fungerte faktisk veldig godt for trykksaker, fordi jeg jobbet med trykksaker en stund. Teamene besto nesten alltid av de samme personene. De var tilordnet de samme kundene, så alle kjente rollene sine. Det var én av tingene jeg ville tatt opp i et oppstartsmøte – å sørge for at alle kjente rollene sine.
Ben Aston:
Riktig.
Patrice Embry:
Alle kjente allerede rollene sine. Det var to designere, alltid én utvikler og vanligvis to kundeansvarlige. Alle visste hva de skulle gjøre. Så kunne vi samles i et rom og tenke: «Jeg har så mye å gjøre at jeg ikke engang har 30 minutter til å bruke på dette oppstartsmøtet.» Da ble spørsmålet heller: «Hvis alle kjenner rollen sin, kunden og har jobbet med lignende prosjekter før, hva trenger de egentlig å vite?» De trenger å vite hva som skiller dette fra de andre lignende prosjektene. Derfor beskriver jeg dette. De trenger å vite tidsplanen, som jeg uansett tar med i et oppstartsmøte. Jeg kunne snakke om tidsplanen, men de vil se den, samhandle med den, se på den og ta den inn over seg. De kommer ikke nødvendigvis til å gi spontan tilbakemelding på den i møtet, og jeg vil gi dem de første oppgavene sine.
Hvis alle kjenner resten, kan jeg gjøre dette i en e-post. De var faktisk veldig fornøyde med at jeg ikke brukte tid på å samle dem for å snakke om alt og få dem til å høre meg gjenta de samme tingene som alltid. Hvis du gjør svært gjentakbare prosjekter med de samme personene, trenger du kanskje ikke et oppstartsmøte. Du kan sende en oppstartse-post. Jeg gjorde dette ofte, og det fungerte svært godt.
Ben Aston:
Jeg kan se at det kan fungere når du gjør noe gjentakbart. I mitt tilfelle har jeg alltid noen nye i prosjektet, eller et nytt element. Men mer generelt bør vi kanskje tenke over hva vi gjør bare fordi vi alltid gjør det. Det du snakker om, er hva folk faktisk trenger å vite for å kunne begynne på arbeidet.
Jeg synes vi noen ganger bruker for mye tid og overkonstruerer briefene våre. Du snakker egentlig om å sende en e-post med en brief. Brief er viktig og nyttig, men det finnes ofte deler der du må kopiere og lime inn det samme på nytt og bare endre tre ord. Hvis du har det samme teamet, bør du se på hvordan du briefer folk og gjør prosessen mer effektiv, slik at du ikke bruker tid på å gjenta ting alle allerede vet.
Patrice Embry:
Riktig.
Ben Aston:
Fokuser på: «Dette prøver vi å gjøre. Dette trenger jeg at du gjør. Dette er oppgaven vi må få gjort. Er alle komfortable med det?» Ikke vær for formelstyrt i måten du tilnærmer deg alt på.
Patrice Embry:
Absolutt.
Ben Aston:
Hovedpoenget fra samtalen vår i dag er at du bør behandle hvert prosjekt som unikt. Ikke tro at du må bruke nøyaktig samme prosess, dokumentasjon og grundighet på hvert eneste prosjekt bare fordi du gjorde en god jobb sist og brukte mye tid på det. Poenget er at vi kan gjøre ting annerledes. Vi trenger ikke gjøre alt på nøyaktig samme måte hver gang. Tilpass det til prosjektet.
Patrice Embry:
Absolutt.
Ben Aston:
Flott. Patrice, tusen takk for at du ble med. Det har vært flott å ha deg her. Hvis du vil bidra til samtalen vi har hatt i dag, kan du kommentere på innlegget til Patrice eller gå til fellesskapsseksjonen på thedigitalprojectmanager.com og delta i samtalen der. Men frem til neste gang: Takk for at du lyttet.
