Hvad du kan holde op med at gøre på dine projekter (med Patrice Embry)

Læs transskriptionen:

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Ben Aston:

Tak fordi du lytter med. Jeg hedder Ben Aston, og dette er podcasten for den digitale projektleder.
Vi får hele tiden at vide, hvad vi bør gøre, og jeg er en af de mennesker, der gør det. Der er et pres for at forbedre sig selv, gøre tingene rigtigt og faktisk også for at blive set gøre de rigtige ting. Men bør vi gøre alle disse ting hele tiden? Lyt videre til denne episode for at finde ud af hvordan du kan spare en masse tid ved at fjerne eller reducere nogle af de ting i din projektlederrutine, som du måske ikke har brug for på hvert projekt.
Vi taler om, hvordan du kan få noget af dit liv tilbage og bruge mindre tid på kontoret eller ved skrivebordet ved at fjerne seks ting, som du kan spare tid på. Denne podcast handler virkelig om at frigøre sig fra alle disse “burde” og nogle af “skal”-kravene og være lidt mere effektiv i den måde, vi gør tingene på.
I dag har jeg selskab af Patrice Embry, som faktisk – og det er jeg nødt til at rose hende for – sandsynligvis er den mest aktive deltager i vores Slack-team. Hvis du endnu ikke har tilsluttet dig, kan du måske tale med Patrice lige nu. Hvis du går til fællesskabssektionen hos The Digital Project Manager, kan du tilmelde dig der. Patrice er næsten altid til stede og chatter altid, så hun er en god person at kende.
Som en kort introduktion er Patrice freelance digital projektleder. Hun er certificeret Scrum Master II. Hun har arbejdet i branchen i meget lang tid hos mange forskellige bureauer og virksomheder. Lyt til nogle af vores andre podcasts for at få en bedre forståelse af den slags arbejde, hun har udført. Hun har arbejdet med det hele, så hun er en fantastisk person at kende.
Velkommen, Patrice.

Patrice Embry:

Hej. Tak fordi du inviterede mig.

Ben Aston:

Det var så lidt. Patrice, kan du fortælle os, om du arbejder på nogle spændende projekter lige nu, siden vi sidst talte sammen?

Patrice Embry:

Jeg har netop afsluttet en app, som jeg arbejdede på. Den hjælper folk, der leder efter kortvarige, hurtige jobs. Det er lidt ligesom Care.com, men endnu hurtigere, for folk, der virkelig har brug for at få udført disse kortvarige jobs. Det var en virkelig interessant app. Den er endnu ikke helt lanceret … den er i betaversion nu, så den er ikke helt klar til, at verden kan se den, men det var et meget interessant projekt, fordi jeg arbejdede sammen med mennesker fra hele verden.
Jeg har aldrig arbejdet sammen med nogen fra Nigeria før, så det var første gang, jeg sagde hej på igbo, og det var rigtig sjovt.

Ben Aston:

Det lyder som et svindelprojekt. Altså ikke selve projektet. Det er naturligvis klassiske nigerianske svindelnumre. Så udviklingsteamet var derude?

Patrice Embry:

Undskyld?

Ben Aston:

Var udviklingsteamet derude i Nigeria?

Patrice Embry:

Ja.

Ben Aston:

Nå, virkelig?

Patrice Embry:

Ja. Frontendudvikleren var i Nigeria. Backendudvikleren var i Mexico, og vores tekniske leder var i Sverige. Så var der mig uden for Philadelphia og kunden i Boston. Vi var spredt over det hele.

Ben Aston:

Det er mange tidszoner at arbejde med.

Patrice Embry:

Ja, det er det.

Ben Aston:

Det må ikke have været nemt. Hvordan fik du det til at fungere?

Patrice Embry:

Jeg fandt et tidspunkt, som alle nogenlunde kunne leve med, nemlig klokken 8 om morgenen østlig tid. Så vores europæiske venner syntes, det var lidt sent på dagen, det var ret sent for vores nigerianske ven, og Mexico var nødt til at stå lidt tidligere op, end han havde lyst til, men vi fik det til at fungere.

Ben Aston:

Fedt. Er appen til en startup, eller er den til …

Patrice Embry:

Ja. Det er … Jeg tror, det var en tjeneste, der opstod, fordi en kvinde gjorde dette for et par personer, og et par andre personer sagde: “Hej, kan du gøre det for mig?” Og sådan fortsatte det, indtil hun sagde: “Ved du hvad, jeg kan ikke længere selv håndtere koordineringen.” Og jeg tror, hun sagde: “Lad os lave en app til det.” Den er stadig helt i sin tidlige spæde fase, så jeg vil ikke fortælle for meget om den, men når den lanceres, skal jeg nok fortælle alle om den. Jeg tror, det bliver en rigtig god tjeneste for folk.

Ben Aston:

Fedt. Det lyder som et interessant projekt. Hvilke store udfordringer stødte du på? Var det ligetil, eller ramte du nogle vanskelige steder undervejs?

Patrice Embry:

Det var lidt vanskeligt, fordi kunden virkelig ikke var særlig fortrolig med computere. Hun var heller ikke særlig fortrolig med apps. Hun havde et normalt niveau af viden om, hvordan ting fungerer. Som du ved, har man i teknologibranchen ofte en lidt større forståelse af, hvordan ting fungerer, så der var en del forklaring.
Det var lidt som at forklare en ven, der ikke arbejder ved en computer hver dag, hvordan forskellige ting fungerer. Så der var en del af det. Nogle gange er det først, når man bliver virkelig involveret i et projekt som dette, at man opdager de ting, ingen nogensinde havde tænkt på. Testningen, som er grunden til, at den er i beta nu, var virkelig intensiv, fordi vi hele tiden sagde: “Nå ja, det her er en vej, vi aldrig har gået ned ad før.” Det gjorde det udfordrende, men det var også meget sjovt. Det var sjovt at arbejde sammen med alle, og det er en virkelig god idé. Jeg er ret tilfreds med den.

Ben Aston:

Hvilke værktøjer brugte du til at styre alle disse forskellige mennesker i forskellige tidszoner? Hvordan håndterede du de forskellige krav fra det indledende oplæg, som virkede lidt løst, og hvordan styrede du så projektet?

Patrice Embry:

Ja, det var virkelig løst. Der var ikke ret mange ekstra penge at gøre godt med, hvilket passer fint med det, vi taler om i dag. Jeg havde ikke mange timer, jeg kunne bruge på alle mulige ting. Jeg var nødt til at være meget selektiv med, hvad jeg gjorde, og hvad jeg ikke gjorde, fordi jeg ikke ville bruge budgettet på mine egne timer. Jeg ville spare så mange timer som muligt til selve udviklingen.
Vi brugte Slack, fordi det var gratis. Vi brugte Trello, fordi det var gratis. Vi brugte en masse Google Dokumenter, fordi de var gratis. Vi var nødt til at finde ud af, hvordan vi kunne få alle disse ting til at fungere for os uden nogen af betalingsfunktionerne, fordi vi skulle være så omkostningseffektive som muligt for virkelig at få dette til at fungere for kvinden og projektet.

Ben Aston:

Så hvordan fandt du dette projekt? Var det bare en anbefaling fra en ven af en ven, fordi det lyder som en startup … ja, det lyder sådan.

Patrice Embry:

Ja. Du kender mig. Du nævnte, at jeg hele tiden er på Slack, og din Slack er ikke den eneste Slack, jeg hele tiden er på. Som freelancer er man nødt til hele tiden at sørge for, at kommunikationslinjerne er åbne med alle, så man kan få så meget information som muligt. Jeg taler med mange mennesker om mange ting.
Jeg kan ikke huske alle de mange begivenheder, der førte mig til projektet, men det var nok en masse: “Hej, jeg tror, jeg kender en person, som jeg måske har hørt om fra et andet sted. Er der nogen, der kender nogen, der kan dette?” Det var sikkert en masse af den slags, men ja, jeg netværker meget, så ting kommer til mig på meget mærkelige måder.

Ben Aston:

Sammensatte du projektteamet?

Patrice Embry:

Nej.

Ben Aston:

Var det noget, du gjorde?

Patrice Embry:

Nej, det gjorde jeg ikke. Jeg blev placeret i en gruppe af mennesker, og så fandt vi ud af, hvad alle skulle gøre. Jeg skulle ikke finde ressourcerne til dette projekt. Jeg var virkelig glad for det team, jeg blev sat på, og jeg kommer til at kommunikere med dem fremover. Forhåbentlig kommer vi alle til at arbejde på et projekt sammen igen, for jeg satte virkelig pris på det, alle bidrog med.

Ben Aston:

Ja, det er fedt. Jeg synes altid, det er interessant at arbejde på den slags projekter, hvor kunden måske ikke er så fortrolig med området, men det betyder også ofte, at der er meget fleksibilitet, hvilket er fantastisk. Det er skønt at have en kunde, der stoler på dig, ikke rigtig ved, hvad de laver, men siger: “I er eksperterne, så fortæl mig bare, hvad vi bør gøre.” Og så tænker man: “Ah, det her er det bedste.” Ja, man kan gøre mange af de rigtige ting.
Ulempen er, at man får den smerte, der kommer med: “Okay, prøv at trykke Control F5.”

Patrice Embry:

Der var meget af det. Men du har ret i, at det er godt at huske, især når man laver en app til den brede befolkning: Ikke alle kommer med det samme niveau af viden om, hvordan man gør ting. På en måde var det faktisk godt, at vi var nødt til at gå tilbage til det grundlæggende, fordi vi også skulle huske at gå tilbage til det grundlæggende i selve appen. Vi kunne ikke bare tage for givet, at folk forstod, at de kunne bruge fingeren til at rulle og dermed se resten af formularen.
Vi var nødt til at gøre det tydeligt, at man skulle rulle. Det fungerede faktisk godt for projektet.

Ben Aston:

Godt. Lad os tale om det, du nævnte, og som jeg talte om tidligere. Vi talte på Slack om sandheden bag, hvordan vi faktisk styrer projekter. På den ene side er der teorien, og som jeg sagde, udgiver vi hos The Digital Project Manager artikler om, hvordan vi bør køre projekter, eller den rigtige måde at gøre det på, altså bedste praksis, som vi kan implementere i vores projekter.
Jeg tænkte, det kunne være interessant at tale om den faktiske sandhed eller virkelighed i, hvordan vi styrer projekter i hverdagen, når der er så mange ting, der skal gøres. Især hvis man har fået ordentlig projektlederuddannelse som PMP og kender PMBOK, alle processerne, arbejdsgangene, de forskellige registre og statusrapporter, så bliver det hele hurtigt til ét stort administrativt mareridt.
Sandheden er nok, at vi altid er overbelastede, og at der altid er dokumentation, man kunne opdatere, eller ting, man kunne gøre. Jeg syntes, det kunne være interessant at tale om, hvorvidt vi gør ting, fordi de er de rigtige ting at gøre, eller om vi bruger for meget energi på de forkerte ting. Vi talte lidt om idéen med start, stop, fortsæt. Hvad bør vi begynde at gøre? Hvad bør vi holde op med at gøre eller reducere? Hvad kan vi fortsætte med at gøre?
Jeg vil gerne høre dit perspektiv, begyndende på et højt niveau: Hvad er de ufravigelige ting? Når du først kommer ind på et projekt, måske endda det projekt, du lige talte om, hvad er så de ting, hvor du siger: “Okay, som minimum skal jeg sikre mig, at disse ting er på plads, ellers går projektet i stå eller løber af sporet, før vi overhovedet er begyndt?”

Patrice Embry:

For mig er det altid tidsplanen og kravene. Derefter kommer budgettet. Budgettet er vigtigt på forskellige måder i forskellige projekter, men jeg tror ikke, man nogensinde kan slippe for at have en tidsplan, en rimelig detaljeret tidsplan. Man kan virkelig ikke slippe for kravene, for ellers har man ingen idé om, hvad man laver, og teamet har heller ingen idé om, hvad de laver. Det er de to ting, der absolut skal være på plads. Efter min mening er de ufravigelige.

Ben Aston:

Jeg vil bare være sikker: Når du taler om krav, mener du så ikke en arbejdsbeskrivelse? Hvilket format har kravene så?

Patrice Embry:

Det er et godt spørgsmål, for de behøver ikke nødvendigvis være i et dokument. Men man skal vide, hvad omfanget er, og også hvad der ligger ud over omfanget. Hvad skal denne ting kunne? Hvis jeg ser på en arbejdsbeskrivelse, tager den normalt nogle ting for givet. Alt er ikke beskrevet i arbejdsbeskrivelsen, og der vil være et ekstra lag af ting, der skal gøres, tales om eller overvejes, samt funktioner, der skal være på plads, for at omfanget kan realiseres. Det er den slags krav, jeg taler om.
De skal defineres. Folk skal vide, hvad de er. De kommer til at styre, hvad folk gør. Ellers har man virkelig ingen idé om, hvad man bygger. Det er den type krav, jeg taler om.

Ben Aston:

Ja, det er så rigtigt. For mig handler det om estimering, tidsplan og arbejdsbeskrivelse, når jeg først lander på et projekt og skal skabe et fælles udgangspunkt. Det er den slags dokumentation, jeg forsøger at finde, for hvis man ikke kender tidsplanen eller kravene, er der ingen måde, man kan styre og kontrollere projektet på. Hvis man ikke ved, hvordan det skal være, ved man ikke, om man er på rette spor.

Patrice Embry:

Hvordan ved vi, om det er færdigt? Hvordan ved vi, om det ikke er gået i stå? Ja, præcis.

Ben Aston:

Når man overtager et projekt, er noget af det, man typisk opdager, at tingene altid er en smule forældede, når man modtager dem. Især kravene eller arbejdsbeskrivelsen. Det er sådan: “Nå ja, vi talte om det, og vi blev enige om at gøre noget andet.”
Hvis det er de ufravigelige ting, hvordan vedligeholder du dem så gennem hele projektet for at sikre, at alle er på samme side?

Patrice Embry:

Jeg minder folk om tidsplanen hver uge eller hver gang, vi mødes for at tale om projektet. Måske er det mere end én gang om ugen. Måske hver anden uge. Det afhænger af projektet, men jeg minder altid folk om, hvor vi er i tidsplanen. Hvad er vores næste deadline, og normalt også hvad deadlinen derefter er, så vi ved, hvad vi arbejder hen imod.
Jeg minder dem om slutdatoen, og hvad vi arbejder hen imod. Det er ikke nødvendigvis lanceringsdatoen, men ofte hvornår vi skal være i kvalitetssikring eller brugertest. Jeg minder alle om det, og hvis det ændrer sig, sørger jeg altid for at fortælle folk det. Hvis vi er i fare for at misse noget, er det dér, folk hører mest fra mig.
Hvad angår kravene, forsøger jeg at holde dem så opdaterede som muligt. Det er rart, når de ligger i et samarbejdssystem som Trello eller noget lignende, hvor man kan fortsætte med at tale om, hvad noget skal være, se hvordan ting udvikler sig, og se, hvad det seneste er, vi har sagt, at vi vil gøre for en funktion. Alt dette kan samles ét sted og gøres søgbart.
Hvis det er sådan, man arbejder, skal man holde det opdateret. Hvis man ikke bruger den slags værktøjer, handler det om at holde en eller anden form for dokumentation opdateret med de ting, man har besluttet med kunden, ting man har besluttet at udskyde for at spare tid, eller ting, man ved, skal tilføjes senere. Det er en konstant opdatering af den dokumentation, man har, uanset hvilken form den har.

Ben Aston:

Ja, helt sikkert. Jeg skriver ofte en arbejdsbeskrivelse og udsteder derefter ændringsanmodninger eller opdateringer til arbejdsbeskrivelsen, typisk som et Word-dokument, hver gang projektet ændrer retning. Det er for at have kundens underskrift på: “Ja, jeg ved, at vi foretager denne ændring, og jeg godkender den.”
Det papirspor og det at holde styr på tingene kan være virkelig vigtigt, især hvis man har flere kunder, eller hvis der er forvirring om, hvem der faktisk har ansvaret for projektet.

Patrice Embry:

Absolut.

Ben Aston:

Lad os tale om nogle af de ting, vi måske ikke behøver gå så meget i dybden med eller overkonstruere. En af de ting, du taler om i artiklen, er detaljerede budgetter og projektopdelinger. Vil du fortælle lidt om det?

Patrice Embry:

Min baggrund er, at jeg startede et sted, hvor der var meget af: “Sådan fungerer alt præcis.” Jeg var et tandhjul i et meget stort hjul sammen med mange andre projektledere, der lavede mange forskellige ting. Vi var mange, og vi skulle alle gøre alting på samme måde. Der var meget af: “Sådan gør man.”
Det var først, da jeg begyndte at arbejde for mindre bureauer og derefter blev freelancer, at jeg tænkte: “Man kan ikke altid gøre alle de ting, for det bliver virkelig svært at holde budgettet intakt, hvis man gør, og man har måske heller ikke tiden.” Da jeg arbejdede på det større bureau og gjorde alle de ting, man skulle gøre, var et af dem et virkelig detaljeret budget. Det var gammeldags. Jeg laver stadig mine budgetter på den gammeldags måde. Jeg lægger dem i et regneark med pivottabeller, betinget formatering og celler, der henviser til andre celler. Man kunne se, hvor mange procent der var færdige, hvad der var tilbage, hvordan det forholdt sig til budgettet, og hvor langt vi var fra vores fremskrivninger. Fremskrivningerne blev lavet ugentligt pr. rolle.
Det er ret omfattende. For det meste fungerer det rigtig godt for mig, fordi jeg kan besvare ethvert spørgsmål når som helst, hvis jeg holder budgettet så detaljeret. Men hvis det kræver mange flere af mine timer at vedligeholde et så detaljeret budget, og det ikke er noget, kunden går op i, eller noget den person, der underskriver din lønseddel, går op i – hvis det ikke er kunden, men dit bureau eller den, du arbejder sammen med – så skal du sikre dig, at det, du leverer, er det, der er brug for.
For mig ville det være ikke at have en så detaljeret budget- og fremskrivningsopdeling, som jeg er vant til. Det tog mig lidt tid at blive tryg ved det, men der er et niveau af rapportering, som du måske ikke behøver lave. Mit forslag til folk, der tænker: “Skal jeg virkelig gøre alt det her?” er at spørge sig selv: Hvad har jeg brug for at gøre? Hvor meget af det har jeg brug for at gøre? Kan jeg gøre mindre? Vil det skade budgettet, hvis jeg gør mere? Vil det skade projektet, hvis jeg gør mindre? Find ud af det, og lad være med bare at lave omfattende budgetopdelinger af pligtfølelse. Gør det i stedet, fordi det er godt for projektet.

Ben Aston:

Det er virkelig nyttigt. Jeg er dog nysgerrig: Sætter du din projektledelsestid som en procentdel af det samlede antal timer for det team, du styrer, eller gør du det typisk pr. opgave?

Patrice Embry:

Jeg plejede at gøre det procentbaseret, men da jeg arbejdede på større bureauer, fandt jeg ud af, at det var godt at have arbejdet mange forskellige steder, været på mange forskellige bureauer og lavet mange forskellige ting i stedet for kun at have arbejdet ét sted i ti år. Jeg har en masse interessant erfaring med alle mulige ting. Jeg plejede at gøre det som en procentdel, og det fungerer rigtig godt, hvis man har noget, der kan absorbere de ting, man ikke havde tænkt på. Jeg kunne bruge en procentdel, hvis det betød, at jeg ikke behøvede tænke for meget over, hvor meget jeg ville overskride budgettet. Jeg fandt ud af, at jeg virkelig er nødt til at se på hver enkelt opgave. Jeg er ret pertentlig med estimeringer og har et meget stærkt syn på dem.
Jeg ser typisk på opdelingen af alle projektets opgaver. Hvis jeg vil bruge en procentdel af tiden, gør jeg det som en procentdel af tiden for opgaven. Jeg bruger ikke længere en procentdel af hele projektet, fordi jeg føler, at det for de mindre virksomheder og for mig som freelancer ikke er målrettet nok til virkelig at dække det, jeg har brug for. Jeg gør det ikke længere som en procentdel af helheden.
Jeg synes, det er fint at gøre sådan, og hvis det fungerer for dig, bør du fortsætte. Jeg har bare fundet ud af, at det på det seneste ikke dækkede det, jeg havde brug for.

Ben Aston:

Nå, jeg forstår. Det var altså ikke, fordi det var for meget, men fordi du ikke havde timer nok?

Patrice Embry:

Ja. Jeg havde ikke timer nok, eller …

Ben Aston:

Hvilken procentdel brugte du?

Patrice Embry:

Jeg plejede at arbejde sammen med account managers, og jeg pressede på for at bruge 20 % af helheden til account management. Derudover 20 % til projektledelse, og det er meget.

Ben Aston:

Det er meget. Det er jo 40 %.

Patrice Embry:

Det er meget. Det fungerede ikke altid … Det er problemet med procentdele: De tager ikke højde for alt. De projekter, jeg arbejdede på, var … Det er en hel dåse orme, vi åbner her, men hvis det beløb, der faktureres, ikke er rigtigt fra starten, er din procentdel meningsløs.
Hvis nogen ikke har prissat det ordentligt, kommer din procentdel stadig ikke til at passe. Jeg fandt ud af, at det ikke fungerede, fordi jeg ikke havde timer nok. Det var ikke kun mig, der ikke havde timer nok; det var som regel ingen, der havde timer nok. Det var simpelthen prissat forkert. Derfor skal man gå tilbage og sikre sig, at ens estimeringer er rigtige. Man vil gerne tjene penge på projektet. Det var måske ikke, fordi procentdelene ikke fungerede for mig, men fordi procentdelene var baseret på et tal, der ikke var rigtigt fra starten.

Ben Aston:

Ja, helt sikkert. Jeg er vant til, at projektledelse bør udgøre 20 % af de samlede projektomkostninger, og account management kommer oveni, men det er ikke helt 20 %. Jeg synes, det vigtige her er, at vi har talt om krav, og det handler om projektets krav. For os handler det om at tilpasse vores detaljerede budget og vores fremskrivninger til den kunde, vi arbejder for, og om ikke at overdrive eller overkonstruere det.
Det handler også om kundens appetit og villighed til at betale for det. Hvis man har en kunde, der er meget risikobevidst og vil kende den mindste detalje om ressourceopdelingen og hvordan det kommer til at udvikle sig gennem hele projektet, så er det også et spørgsmål om uddannelse. Det koster penge at gøre det.
Jeg ved, at der findes noget projektstyringssoftware, hvor man indtaster alle disse tal i begyndelsen, og hvis tidsregistrering og projektstyring er integreret i ét smukt system, kan det gøre det hele for dig. Virkeligheden er, at det for de fleste projekter, vi arbejder på, er en manuel proces. Vi får timesedler fra et sted, skal indtaste dem i et regneark og lave beregninger. Det er en stor og dyr opgave.
Hvis du vælger den lettere løsning og siger, at du ikke vil levere en detaljeret budgetopdeling, hvordan sikrer du så, at du holder dig på sporet? Hvad er din lettere metode, hvis du ikke går så meget i detaljer?

Patrice Embry:

Tidligere ville jeg for eksempel have opdelt den samlede fremskrivning af timerne og fordelt budgettet på timer og fremskrivninger for hver rolle. Jeg ville normalt indtaste de faktiske tal og derefter justere fremskrivningerne for resten af projektet. Hvis jeg for eksempel havde brugt for meget tid i denne uge, ville jeg sige: “Okay, så skal jeg hente det et andet sted, og mine fremskrivninger for de andre uger ændrer sig lidt. Jeg blev færdig hurtigere, så jeg har mere tid, og derfor kan jeg justere fremskrivningerne.”
Det er det første, jeg ville skære væk, hvis jeg vidste, at jeg ikke havde tid, budget eller kapacitet til at have et så omfattende budget. Du ville have dine fremskrivninger fra begyndelsen og kunne se, hvor du var, men du ville ikke nødvendigvis justere hver eneste fremskrivning, hver gang du opdaterede dit budgetark. For mig ville det have været én gang om ugen. Det tog faktisk en del tid at finde ud af, hvordan jeg skulle gøre det.
Fordelen er, at jeg meget tidligt ved, hvor vi får problemer. Man kan hejse et rødt flag meget tidligere, men det tager meget tid. Det koster mig penge at gøre det, så der er andre måder, man kan identificere røde flag på. Det ville nok være det første, jeg fjernede.
Det næste, der skulle væk, ville være alle de beregninger, jeg lavede for at kunne skære og vende hvert eneste stykke information på fem forskellige måder. Man går tilbage til det grundlæggende: Er vi på budget? Er vi i fare for at overskride det? Har vi timer nok tilbage til at gøre de ting, vi skal? Ligner procentdelen, der er færdig, nogenlunde den procentdel af budgettet, der er brugt? Ja? Fint. Lad os komme videre.
Man skal ikke lave regnearket eller bruge værktøjet til det yderste, men bare fokusere på det grundlæggende.

Ben Aston:

Det er virkelig nyttigt. En ting, man skal bemærke, er, at vi taler om, hvordan vi tilpasser vores tilgang til forskellige projekter og kunder. Hvis du driver et stort projekt med mange ressourcer, skal du naturligvis være opmærksom på, at forbruget går meget hurtigere. Din mulighed for at ændre retning, hvis du bruger 50.000 af budgettet hver uge, er begrænset. På bare en halv uge har du brugt 25.000.
Vi skal også tænke over, hvordan vi tilpasser vores overvågning af budgettet på store projekter. Rapportering er en anden ting, men graden af detaljer, vi går ned i, skal også tilpasses det samlede budget.
Hvis du har et meget mindre team og kun få ressourcer, er konsekvensen af at vente længere med at kontrollere dataene naturligvis ikke lige så alvorlig.

Patrice Embry:

Jeg ville stadig kontrollere alt hver uge, men jeg ville ikke gå amok i analysen af det, jeg så. Jeg ville tage det lidt mere for pålydende. Tro det eller ej, jeg har mødt kunder eller entreprenører, der har hyret mig som underleverandør. Der er en kunde og en anden person, der betaler mig, men som ikke er kunden, mere som en account manager. De havde solgt noget til kunden til en fast pris og sagde derefter til mig: “Jeg er egentlig ligeglad. Her er dit budget, men jeg er ikke bekymret for, om vi overskrider det.” Og jeg tænkte: “Okay.”
Det er fantastisk, men samtidig tænker man, at hvis der ikke er nogen rammer omkring noget, kan det hurtigt løbe løbsk. Uanset om du ville have mig til at lave et budget eller ej, ville jeg gøre det alligevel, fordi det ville være uansvarligt af mig ikke at gøre det. Jeg er nødt til at kunne vise, hvad alle har lavet, og hvor lang tid de har brugt. Selv hvis han siger: “Penge er ikke noget problem.” Det lyder som en god ting, men det gav mig faktisk lidt angst, fordi jeg tænkte: “Hvordan ved vi, om vi gør det rigtigt?”

Ben Aston:

Det er også næsten altid misvisende, for når folk siger: “Penge er ikke noget problem,” eller: “Det er okay, at vi overskrider budgettet, bare rolig,” er der stor forskel på at overskride budgettet med 10.000 og med 100.000 eller 500.000.

Patrice Embry:

Efter et stykke tid bliver det noget, man ikke engang bemærker. Man ser det ikke længere. Man kan være så langt over budgettet, at det bogstaveligt talt ikke længere betyder noget, og så går alle amok. Det er forfærdeligt. Jeg har arbejdet på projekter som det, og det er frygteligt.

Ben Aston:

Det punkt, hvor teamet siger: “Nå ja, vi overskred budgettet for tre måneder siden.”

Patrice Embry:

Så hvem bekymrer sig?

Ben Aston:

Så bruger folk bare mere og mere tid på projektet, og situationen bliver værre og værre. Så snart det resterende budget er nul, tænker man: Skal jeg begynde at skrive negative tal?
Vi har kort berørt statusopdateringer, som er et af dine punkter i artiklen om, hvor omfattende en statusopdatering bør være. I en statusrapport, som vi sender til kunderne, giver vi typisk en opdatering om budgettets tilstand, hvor meget vi har brugt i denne uge, hvad vi laver, og hvad vi planlægger at gøre i næste uge. Der er også andre ting, man kan tage med, som budgetopdelinger og prognoser, risici og problemer. Man kan putte hvad som helst i en statusrapport. Hvordan tilpasser du den?

Patrice Embry:

Det er sjovt, for jeg føler nogle gange, at vi som projektledere ubevidst ser statusrapporterne som et spejl af den værdi, vi tilfører projektet. Hvis din statusopdatering ikke ser omfattende ud, betyder det så, at du ikke er en god projektleder?
Jeg vil ikke have, at nogen siger til mig: “Hvad bruger du alle disse timer på? Hvad laver du egentlig?” Nogle gange putter vi alt ind i statusrapporterne for at vise vores værdi, vise at vi holder styr på det hele eller vise bureauets værdi, fordi vi laver alle disse ting. Det tager meget tid og kræfter at opdatere det, og måske har du ikke brug for det.
I mit seneste arbejde med den app, jeg talte om, var kunden ikke særlig teknisk. Det eneste, hun gik op i, var, om tingene gik godt, om vi ville nå den dato, vi havde lovet, og om vi ventede på noget fra hende. Hun ville bare ikke være en flaskehals. Det meste af tiden deltog hun ikke engang i statusmøderne, fordi hun havde travlt med andre ting, og det var ikke en prioritet for hende. Hun ville bare vide tre ting: Går det godt? Holder vi tidsplanen? Har vi brug for noget fra mig?
Jeg sad og lavede disse statusrapporter og tænkte: “Hvorfor gør jeg det her? Det behøver jeg ikke.” Jeg lavede en hel sektion om, hvad vi fik gjort i sidste uge, hvad vi planlægger at gøre i denne uge, og hvad … Hun var ligeglad med alt det.
Jeg vil gerne tro, at hun stolede på mig, men det var nok mere, fordi hun ikke havde tid. Men vi siger, at hun stolede på mig. Hun stolede på, at jeg sørgede for, at alt fungerede, og hun ville bare vide, at alt var i orden.
Det er én type kunde. Der findes masser af kundetyper. Pointen er virkelig, at du skal tænke på din kunde på dette projekt og på, hvad de går op i. Lad være med at fylde rapporten med andre ting bare for at vise din værdi. Du kan sandsynligvis fjerne en del fra dine statusrapporter, hvis du kun fokuserer på det, du har brug for, eller det, kunden ønsker.

Ben Aston:

Det er et virkelig godt råd. Især fordi vi ofte, når vi starter på et projekt, tager den sidste statusrapport fra det projekt, vi arbejdede på, ændrer kundenavn og dato og siger: “Den her er god. Lad os bruge den.”
Så opdager man, at man har tilføjet oplysninger og detaljer, som den tidligere kunde bad om, og tænker: “Ja, det var faktisk nyttigt. Lad os gøre det igen.” Så ender man med en oppustet statusrapport. Og så giver man kunden detaljer, som de egentlig ikke er interesserede i. De vil bare vide, om alt går godt eller ej. Vi ender med at give dem oplysninger, de ikke har brug for.
Jeg synes, man skal tænke på, hvordan man først kan skære det ned til det absolut nødvendige. Hvis kunden vil have flere oplysninger, kan de bede om dem, og så kan vi tilføje dem. Men man skal være tryg ved at sige: “Det er alle de oplysninger, vi behøver at give dem.” Når det begynder at tage timer at udarbejde en statusrapport, bør det være et rødt flag for, at noget ikke er helt rigtigt.

Patrice Embry:

Jeg har haft kunder, der bad mig om ting. Jeg har haft kunder, der bad om en anden måde at se budgettallene på eller flere oplysninger om noget af det, vi lavede. Jeg har været nødt til at sige til dem: “Jeg har afsat tid til disse statusrapporter, og lige nu bruger jeg x antal timer om ugen på at forberede dem. Hvis du vil have, at jeg fortsætter sådan, er det fint, men hvis du vil have noget tilføjet, kommer det til at koste mindst en ekstra time pr. statusrapport eller en halv time.”
Det lyder måske ikke af meget, før man opdager, hvor mange timer det bliver over resten af projektet. Er du sikker på, at du vil have mig til at gøre det? De fleste gange siger de: “Kan du ikke bare gøre det én gang, så ser vi, om vi skal fortsætte, eller også er det ikke så vigtigt. Jeg syntes bare, det kunne være interessant at vide.” På den måde kan man ofte tale folk fra det.

Ben Aston:

Det er så rigtigt. Når man forklarer konsekvensen af det, nogen beder om, og siger: “Hvis du vil have en ekstra time om ugen i de næste 25 uger …”

Patrice Embry:

Er du sikker?

Ben Aston:

“… er du så klar over, at det kommer til at koste dig fem tusind?” Og så siger de: “Nej, det er ikke så meget værd.”

Patrice Embry:

Præcis.

Ben Aston:

Okay, fint, så lader vi være. Den ene undtagelse er, hvis du arbejder på et risikofyldt projekt, eller hvis du ved, at ting kan gå galt. I så fald ville jeg ikke gå efter det absolutte minimum, men fremhæve risiciene i statusrapporten og forsøge at have en løbende samtale om dem. Vi må ikke skære så meget ned, at vi ikke længere dækker os ind.
Når projekter går galt, må vi ikke stå uden dokumentation for, at vi nogensinde gjorde opmærksom på det, der kunne gå galt.

Patrice Embry:

Absolut.

Ben Aston:

Det kan lade sig gøre.

Patrice Embry:

Tommelfingerreglen må være, at man skal være meget sikker, før man fjerner noget. Man skal være sikker på, at man ikke har brug for det. Man skal være sikker på, at man kan tilføje det igen, hvis man får brug for det. Dit sikkerhedsniveau kommer enten af, at du har arbejdet med kunden før, arbejdet på den type projekt før eller været projektleder i lang tid. Uanset hvor tryg du er ved at gøre den slags, skal du lade det være din guide, så du ikke fjerner noget, du faktisk har brug for.

Ben Aston:

Helt sikkert. Lad det være en advarsel. Næste punkt er alle Scrum-ceremonierne. Når vi bruger Scrum, er der ceremonier, og det er det, der gør Scrum til Scrum. Hvis du har gennemført din Scrum Master-uddannelse, er det dette, du lærer. Du bruger to dage på at lære det. Det handler om disse ceremonier: Scrum-planlægning, Scrum-gennemgange og retrospektiver. Men virkeligheden er, at når du har lagt alle disse ting ind i dit projekt, og du kører en sprint på en uge eller to uger, bruger du måske en hel eller to hele dage på møder om planlægning, gennemgang og ceremonier. Det kan tage meget tid.
Dit forslag er måske, at man ikke behøver gøre dem alle hele tiden, eller at man kan slå dem sammen.

Patrice Embry:

Jeg kender mennesker, der er meget Scrum-orienterede. De bliver virkelig oprørte, hvis man foreslår at gøre noget lidt anderledes. Jeg tror, de fleste certificerede Scrum Masters mener, at man ikke skal gøre ting, der ikke er nødvendige for et projekt. Det kan de fleste nok blive enige om. Spørgsmålet er bare, om de mener, at det er disse ting.
Hvis man har en session til oprydning i backloggen, derefter en sprintplanlægning, derefter en sprintgennemgang, og det hele ligger på forskellige dage eller tidspunkter, kan det hurtigt blive overvældende, hvis man ikke har budgettet til det.
Igen handler meget af det om, hvorvidt man har tid og budget. Hvis man har det, så gør det. Hvis ikke, kan man overveje at samle oprydning, planlægning og gennemgange. Man kan få noget ud af det ved at skabe momentum. I stedet for at gøre én ting, stoppe, gøre noget andet og så vende tilbage til det samme projekt for at planlægge, kan man bruge momentum fra backlog-oprydningen og gennemgangen til planlægningen. Det kan være meget givende, fordi man lige har talt om, hvad der skete, og hvad der ligger i backloggen.
Igen skal man bruge sin dømmekraft. Hvis det føles, som om man bruger tre timer på noget, der kunne klares på 90 minutter eller en time og et kvarter, bør man måske se nærmere på det.

Ben Aston:

Jeg synes, det er virkelig nyttigt at sige, at disse ting ikke behøver være separate hele tiden. Især retrospektiver, hvor idéen er løbende forbedring, og hvor vi hele tiden udvikler den måde, vi styrer projektet på.
En af de ting, du nævner i din artikel, er at holde det enkelt, for eksempel med retrospektiver. Jeg har selv lavet retrospektiver, hvor man sender en spørgeskemaundersøgelse ud til alle, indsamler feedbacken og laver statistikker som: “49 % sagde, at projektet var en katastrofe, 25 …” Hvad skal man egentlig bruge det til? Hvad vil man gøre ved det efter dette øjeblik?
Jeg synes, man skal samle tingene, holde dem relevante i forhold til den katastrofe, der er sket eller ikke er sket. Nogle gange laver man retrospektiver og tænker: “Ved du hvad? Denne sprint var fin.”

Patrice Embry:

Alt er godt. Alt er fantastisk. To tommelfingre op.

Ben Aston:

Okay. Der er ingen grund til at overkonstruere den slags rapporter. Bare kom videre. Man behøver ikke bruge en time mere på det. Nogle gange bliver vi fanget i: “Okay, det her er, hvad jeg skal gøre.”

Patrice Embry:

Ja.

Ben Aston:

I stedet for at være pragmatisk og sige: “Lad os bare få projektet færdigt.”

Patrice Embry:

Ja. Det er enten det, eller også får statusrapporter os til at føle, at vi viser vores værdi over for kunderne og retfærdiggør vores eksistens. Retrospektiver kan nogle gange få os til at føle, at vi retfærdiggør vores eksistens over for interne interessenter, bureauets ejere eller virksomhedens ejere. Så igen: Spørg dig selv, hvor hjælpsomt det bliver, og om det er fem timers arbejde værd. Er det to timers arbejde værd? Har jeg fem timer? Har jeg to timer? Har jeg 30 minutter? Jeg har 30 minutter. Lad os bare afgøre, om vi synes, det var et godt projekt eller ej, og hvis der var én tydelig ting, der var galt, så lad os identificere den og komme videre.

Ben Aston:

Godt. Til sidst skal vi tale om opstartsmøder. For mig er det et virkelig interessant punkt. I din artikel foreslår du, at man måske ikke behøver holde et opstartsmøde, men i stedet kan sende en e-mail. Det synes jeg er fascinerende, for det har jeg aldrig gjort. Hvordan får du det til at fungere? Man starter et nyt projekt, samler et team, alle får tildelt ressourcer, og så sender man bare en e-mail, hvor der står: “Det her skal I gøre”?

Patrice Embry:

Ja.

Ben Aston:

Vi ses om en uge.

Patrice Embry:

Ja. Du ved hvad …

Ben Aston:

Hvordan fungerer det?

Patrice Embry:

Jeg ved godt, det lyder vanvittigt, men det begyndte jeg på, da jeg arbejdede på et medicinalbureau, hvor vi lavede mange af de samme projekttyper for forskellige kunder. Jeg vil ikke sige, at det var formelagtigt, men der var ikke mange nye og mærkelige ting, vi lavede for hver tale eller hvert materiale. Det fungerede faktisk rigtig godt til tryksager, for jeg arbejdede med tryksager i en periode. Teamene bestod næsten altid af de samme mennesker. De var alle tilknyttet de samme kunder, så de kendte deres roller. Det var én af de ting, jeg ville gøre på et opstartsmøde: sikre, at alle kendte deres roller.

Ben Aston:

Okay.

Patrice Embry:

Alle kendte allerede deres roller. Der var to designere, altid én udvikler og altid to account managers. Alle vidste, hvad de skulle lave. Så vi satte os sammen og tænkte: “Jeg har så meget at lave, at jeg ikke engang har 30 minutter til at bruge på dette opstartsmøde.” Så det handlede mere om: “Hvis alle kender deres rolle, ved hvem kunden er og har arbejdet på et lignende projekt før, hvad er det så, de har brug for at vide?” De skal vide, hvad der gør dette projekt anderledes end de andre lignende projekter. Så jeg beskrev de ting. De skal vide, hvad tidsplanen er, hvilket jeg alligevel tager med til et opstartsmøde. Jeg kunne tale om tidsplanen, men de vil gerne se den, interagere med den og absorbere den. De kan ikke nødvendigvis give mig spontan feedback på den under mødet, og jeg vil gerne give dem deres første opgaver.
Det kan jeg gøre i en e-mail, hvis alle kender resten. Og de var faktisk meget glade for, at jeg ikke tog mig tid til at få dem til at sidde og tale om alt det, de allerede kendte, eller høre mig gentage de samme ting. Hvis du laver projekter, der er meget gentagelige, og du har de samme personer til at udføre de samme ting, behøver du måske ikke et opstartsmøde. Du kan sende en opstarts-e-mail. Jeg gjorde det ofte, og det fungerede rigtig godt.

Ben Aston:

Ja, jeg kan godt se, at det kan fungere, når man laver noget gentageligt. I mit tilfælde er der altid en ny person på projektet, eller også er der et nyt element. Men mere generelt handler det om at spørge: “Hvad gør vi, fordi vi altid gør det?” I stedet for det, du taler om: “Hvad har folk virkelig brug for at vide for at kunne gå i gang?”
En af de ting, hvor vi nogle gange spilder tiden og overkonstruerer, er at skrive briefinger. Du taler om at sende en e-mail med en brief i. Nogle gange har vi en briefskabelon med afsnit, hvor man tænker: “Jeg skal bare kopiere og indsætte det samme igen og kun ændre tre ord.” Jeg gjorde det i sidste uge. Hvis du har det samme team, skal du se på, hvordan du briefer folk, og forsøge at gøre briefingprocessen mere effektiv, så du ikke bruger tid på at gennemgå ting, alle allerede kender.

Patrice Embry:

Ja.

Ben Aston:

Fokuser bare på: “Okay, folkens, det er det, vi forsøger at gøre. Det er det, jeg har brug for, at I gør. Det er den opgave, vi skal have løst. Er alle med på det?” Lad være med at være formelagtig i den måde, vi griber alt an på, med skabeloner til alting. Jeg tror, den vigtigste læring fra vores samtale i dag er: Behandl hvert projekt som noget særligt. Bare fordi du gjorde et godt stykke arbejde sidst og brugte masser af kræfter på det, betyder det ikke, at du skal anvende præcis den samme proces, dokumentation og grundighed på hvert eneste projekt af enhver type. Pointen er, at vi kan gøre tingene forskelligt. Vi behøver ikke gøre alting på samme måde hver gang. Tilpas det til projektet.

Patrice Embry:

Absolut.

Ben Aston:

Fedt. Patrice, tusind tak fordi du ville være med. Det har været fantastisk at have dig med. Hvis du vil bidrage til den samtale, vi har haft i dag, kan du kommentere på Patrices indlæg eller gå til fællesskabssektionen på thedigitalprojectmanager.com og deltage i samtalen der. Men indtil næste gang: Tak fordi du lyttede.