Balansering av ressurser i Monday – Fred Baker – KUN FOR MEDLEMMER

[00:00:00] Mhm.

Galen: Hei alle sammen, og velkommen til vår praktiske økt om hvordan man bruker Monday til å planlegge, balansere og administrere ressursene i et prosjektteam. For dere som ikke kjenner oss fra før: Jeg heter Galen, og dette er den sertifiserte Monday-konsulenten Fred Baker.

Fred, takk for at du ble med i dag.

Fred: Takk, Galen.

Galen: Greit. La oss gå rett på ressursplanlegging. Jeg har et lite scenario her. Jeg vet at du har satt opp sandkassen din, så la meg forklare utgangspunktet. Scenarioet jeg ser for meg, er at jeg leder et team med prosjektledere i et lite digitalt byrå.

Vi har et par prosjektledere som kjører flere parallelle prosjekter, og alle varierer i størrelse, tidsplan og kompleksitet. Men viktigst av alt deler alle disse prosjektene teammedlemmer fra utviklings- og kreativavdelingene. Det jeg egentlig ønsker å vite, er dette: Hva er den beste måten for prosjektlederne mine i dette scenarioet å prognostisere teamressurser på tvers av prosjektene sine ved hjelp av Monday? Og [00:01:00] mer spesifikt: Hvordan vet jeg om vi har overfordelt noen teammedlemmer? Og hvis jeg har overfordelt et teammedlem, hvordan kan jeg bruke Monday til å balansere ressursen slik at personen ikke overskrider kapasiteten sin? Det er omtrent dette scenarioet jeg ønsker å utforske.

Jeg tenkte at vi kanskje kunne begynne med det grunnleggende. Hvis du raskt kunne vise meg hvordan du ville fordelt ressurser på et par prosjekter, kan vi deretter gå inn i problemområdet: «Vent litt, denne personen jobber 12–16 timer om dagen. Er det greit?»

Fred: Ja, ja, ja. Det er et veldig godt scenario. Det første jeg vil si, før noe annet, er at det jeg viser deg, bare er én av 7 000 forskjellige måter man kunne gjort dette på. Det fine med Monday – og jeg tror jeg sa dette tidligere – er at jeg sier til kundene at Monday egentlig er som en eske med legoklosser.

Du kan bygge hva du vil med den. Det finnes mange forskjellige måter å gjøre én og samme ting på. Problemene oppstår vanligvis når folk prøver å tilpasse Monday til prosessen sin, eller prosessen sin [00:02:00] til Monday. Det finnes noen nyttige verktøy. Arbeidsbelastningswidgeten, som jeg har åpnet her – eller, dette er faktisk arbeidsbelastningswidgeten.

La meg formulere meg riktig. Denne arbeidsbelastningswidgeten er en av de nyere funksjonene de har lansert det siste året eller så. Det er sannsynligvis den beste måten å få en idé om kapasiteten på. Du kan se i dette eksempelet at det i uke 25 ser ut som om jeg har 61 prosent kapasitet. Du kan stable ting oppå hverandre, og jeg skal komme nærmere inn på dette, men du kan legge flere prosjekter oppå hverandre og si: «Greit.»

Det ser ut som Fred faktisk er med på mange prosjekter på dette tidspunktet. Dermed begynner du å se 93 prosent kapasitet. Vi kan legge til litt mer og se hvordan det ser ut, men du kan komme helt opp i rødt. Du kan altså se visuelt når folk er overbelastet, eller når de ikke er så belastet, slik som i uke 29 her.

Um, og den er koblet til et prosjektstyre. Dette ville vært prosjektstyret, [00:03:00] og dette kunne vært et overordnet prosjektstyre. Det overordnede styret er i praksis en porteføljevisning der alle prosjektene dine ligger, med én rad for hvert prosjekt.

De kan være plassert i ulike grupper eller hva det måtte være. Vanligvis finnes det en overordnet visning som hele teamet eller prosjektlederen kan se på. Derfra kan det kanskje finnes et detaljert styre, som er en mer spesifikk visning. Du kan for eksempel ha alle prosjektene dine her, og deretter et svært spesifikt webdesignprosjekt for en stor kunde, eller noe annet som er koblet til det overordnede styret, men som har et prosjektnivå med alle detaljene.

Vi starter prosjektet, samler inn ressurser, lager en trådmodell, gjennomfører en gjennomgang og så videre. Alt dette ville blitt kartlagt i detaljstyret, men ikke i det overordnede styret. Det overordnede styret sier bare: «Hei, vi bygger et nytt nettsted for DPM.»

Galen er eieren, Fred er prosjektlederen, og her er kanskje hvem som er tildelt prosjektet. Dette ville [00:04:00] vært et overordnet styre, altså alle prosjektene dine. La oss legge til et prosjekt til her. Jeg kaller det bare DPM og legger meg selv til.

Det finnes mange forskjellige måter å sette dette opp på. Det jeg har satt opp her, er bare mange ulike eksempler. Ett av dem er en prosjektoppstart: Når skal prosjektet faktisk starte? Jeg setter det til den 26., slik at det vises i inneværende uker. Du kan bruke enten en bestemt dato eller en tidslinje.

La oss si at dette skal gå fra den 26. til 31. juli. Det er sannsynligvis langt fra nok tid til å bygge et faktisk nettsted.

Galen: Jobb raskt. Hmm. Mm.

Fred: Ja, ja, ja. La oss si at dette skal ta hundre timer, bare for å bruke noen tall. Dette er altså det totale antallet prosjekttimer, og dette er bare en kolonne jeg har laget.

Det er i bunn og grunn en tallkolonne, og vi har satt den til å vise timer, men den kunne vist hva som helst – eller ingenting. Nedenfor har vi et sammendrag av disse verdiene. Så [00:05:00] du kan se totalsummen. Hvis du bruker dette for prosjekter, kan du spørre: «Hvor mange totale prosjekttimer har jeg?»

Jeg har 375 timer i prosjekter. Det kan være helt annerledes, men poenget her er å se hva den totale forpliktelsen din er. Det gir litt innsikt. Så har vi prosjektuker, som jeg har en sum for her. Dette er totalsummen av ukene, ikke start og stopp. Denne tidslinjen viser start og stopp, men la oss si at dette skal ta.

Jeg tror jeg la inn omtrent seks uker i tidslinjekolonnen. Vi sier derfor seks uker her. Du kan se summen nederst, og tidslinjen her viser også summen. Så har jeg en tjenestetype. Jeg la bare inn noen eksempler, men kanskje du har forskjellige typer prosjekter: søkemotoroptimalisering, webutvikling og lignende. De vises her, og dette er bare en måte å filtrere dem på. Du kan sortere etter dette eller gjøre hva du vil, slik at du får en annen visning. Det finnes også ulike måter å registrere tid på, som kanskje passer – eller ikke passer – til det du gjør her.

Dette er en tidsregistreringskolonne. Du kan enten trykke på start og stopp for å registrere tid, eller komme inn her og legge den inn manuelt. Jeg kan for eksempel si at Fred jobbet med dette den 27. fra klokken ni om morgenen til 10.34. Da har jeg registrert én time og 34 minutter.

Dette er satt opp slik at det skal brukes senere i scenarioet. Vi har også en rekke andre kolonner. Denne er den tildelte ukentlige forbrukstakten. Tanken er at hvis det er 100 timer i prosjektet og vi holder på i ti uker, har vi én time per uke som skal brukes. Du tildeler ganske enkelt den totale prosjektforpliktelsen. Dette gjelder ikke bare Fred, men hele prosjektet. Hvis du har fem [00:07:00] personer på prosjektet, legger du inn dette her.

DPM er automatisk beregnet til seks timer per uke, fordi jeg har 100 timer fordelt på seks uker og har satt dette opp til å beregnes automatisk. I dette tilfellet sier systemet at prosjektet varer i seks uker. Fordi jeg allerede har registrert én time og 34 minutter, beregner det at vi har 98 timer – eller 98,43 timer – igjen. Dette er bare formelkolonner vi har satt opp for å beregne verdiene.

Du kunne satt dette opp annerledes, men dette er en rask, automatisert formel. Nå kommer jeg til arbeidsbelastningsdelen. Vi har en planlagt ukentlig forbrukstakt og en faktisk ukentlig forbrukstakt. Du trenger kanskje ikke bruke alle disse. Den tildelte ukentlige forbrukstakten kan for eksempel si at prosjektet krever seks timer per uke, mens den planlagte ukentlige forbrukstakten kan være annerledes.

Som prosjektleder kan du se at vi i gjennomsnitt trenger seks timer per uke, men at vi i uke én, to og tre faktisk kommer til å bruke ti timer per uke. Da kan du endre dette til ti timer. I uke fire, fem og seks skal vi kanskje bruke fem timer. Dette endrer du manuelt. Dette er den planlagte ukentlige forbrukstakten.

Så har vi planlagt ukentlig forbrukstakt per person. Denne er 16,7, som samsvarer med verdien her. Denne er fem i stedet for ti, fordi det er to personer på prosjektet. Det betyr at jeg og George begge får fem timer. Du kunne satt opp dette annerledes. Kanskje trenger grafikeren noe annet, men dette er bare en rask formel jeg satte sammen.

Den faktiske ukentlige forbrukstakten – la meg finne formelen – er prosjektets registrerte tid i timer delt på antallet uker prosjektet har pågått. Det handler altså om hvor mange timer vi har [00:09:00] registrert, og hvor mange uker vi faktisk er kommet inn i prosjektet.

Hvis vi er tre uker inne i prosjektet, beregner den faktiske ukentlige forbrukstakten hvor mange timer vi faktisk har utført så langt. Her er grunnen til at seks uker er med. Beklager, det er en stund siden jeg så på denne delen. Dette er hvor mange uker prosjektet varer, beregnet automatisk, og hvor mange uker som gjenstår.

Dette er altså noen av tingene som er satt opp automatisk. Dette viser hvor mange timer per uke du må jobbe for å bli ferdig i tide. Hvis det ikke er noen uker igjen, men det fortsatt gjenstår 36 timer i prosjektet, må vi jobbe 36 timer denne uken for å bli ferdige i tide. Det er sannsynligvis ikke realistisk, med mindre det er [00:10:00] fire eller fem personer på prosjektet.

Det er noe man bør følge med på. Så har vi noen andre kolonner jeg la inn, for eksempel planlagt prosjektforbruk til dags dato. Det viser hvor mange timer vi faktisk planla å bruke til nå, og deretter har vi faktisk forbruk til dags dato.

Da kan du få et forholdstall som viser om du ligger omtrent der du trodde du skulle ligge. Alt dette går inn i tabellen. Det som går inn i selve arbeidsbelastningswidgeten, er prosjektidene, de individuelle – jeg tror det er de tildelte ukentlige timene – som mates inn i denne visningen.

Du kan endre dette, men jeg tror det er slik jeg har satt det opp. Ja, det er prosjekttidslinjen og prosjekttimene jeg har valgt for arbeidsbelastningseksempelet. I dette tilfellet kan du se at jeg nå er overbelastet i uke 26, [00:11:00] 28 og 29 fordi jeg har dette DPM-prosjektet.

Hvis jeg ser at jeg er overbelastet, kan jeg gjøre et par ting. Vi kan flytte prosjektet til et tidspunkt der jeg er mindre opptatt, hvis det er mulig. Du kan dra tidslinjen ned. Du kan omfordele prosjektet eller tildele noen andre. Fred er tildelt her, og det er mye, så la oss legge til George også. Nå er George med, og vi har redusert belastningen noe.

Det er fortsatt for mange timer for både Fred og George, men nå deles belastningen mellom dem i stedet for å ligge på Fred alene. Vi kan også dra tidslinjen lenger ned. Nå ser det ut som om vi ikke er overbelastet. La oss gå én uke til. Da kan vi håndtere dette hvis vi starter i uke 29.

Det er slike ting du kan gjøre. En annen ting jeg gjorde her, men ikke snakket om, var å klikke på prosjektet. I arbeidsbelastningsvisningen kan disse elementene skjules, slik at du kan se visningen per person. Du kan se hva som skjer i uke 28. Det ser ut som om de er på kapasitet.

Så kan du utvide visningen og se alle prosjektene de er med på. Hvis du vil redigere prosjektet, klikker du på det. Da åpnes denne kortvisningen, som er relativt ny i Monday. De hadde ikke denne i fjor. I kortvisningen kan du redigere alt jeg nettopp gikk gjennom i tabellen.

Jeg kan for eksempel si at dette prosjektet faktisk bare er på 80 timer, ikke 100. Da reduserer vi kapasitetsproblemet. Når kapasitetsproblemet er redusert, kan jeg kanskje forkorte tidslinjen.

Galen: Det jeg liker med dette, hvis jeg forstår det riktig, er at du har laget noen egendefinerte felt for ting som timer og hvordan du fordeler ressursene i prosjektet. Du bruker formler til å forstå forbruket og ressursfordelingen.

Men så legger Monday et lag oppå dette med visningen under arbeidsbelastningsfanen. Der er det enkelt å visualisere og simulere hvordan det ville se ut å balansere ressursene. Du kan også klikke deg inn i visningen, som i praksis er den kompakte tabellvisningen, og arbeide videre der.

Du kan si: «Greit, noen av disse variablene har faktisk endret seg. Vi ligger foran planen, det tar ikke så lang tid som vi trodde, eller det tar dobbelt så lang tid.» Da driver dette samtalen videre: «Greit, kunde eller sponsor, her er alternativene våre.»

Forbruket er høyere enn vi trodde. Vi kan legge til George, og da balanseres ressursene, men George kan ikke begynne før midten av juli. Der har du samtalen. Hvis de sier at de ikke vet om de tror på deg, kan du vise dette – særlig internt.

Her er de fem prosjektene du har bedt meg om å kjøre. Vi deler ressurser mellom dem. Røde prikker er dårlige. [00:14:00] Blå prikker er greie.

Fred: Du kan til og med se hvor nær kapasiteten du er. Kanskje ønsker vi å holde alle på 70 prosent. Da vil jeg kanskje legge litt mer arbeid på Fred. Her ser vi 90 og 94 prosent. Da kan jeg ta bort noe eller flytte på noe. Fordi du lager prognoser, kan du håndtere mye av dette før det faktisk blir et problem.

Det som er spesielt nyttig med denne visningen, er at den fungerer som et personlig Gantt-diagram. Det finnes et Gantt-diagram for hele prosjektet, som jeg skal vise om litt, der du kan se alle prosjektene dine. Men her er det mer som Galens personlige Gantt-diagram.

Jeg kan se hvor mange prosjekter han er med på de neste sju ukene, eller så lenge du vil. Du kan vise et helt år eller mer. Du får en tidslinje, og jeg kan si: «Det ser ut som Galen kommer til å bli overveldet i april hvis jeg ikke gjør noe.»

Da kan jeg finne ut hvordan vi skal starte andre kvartal på riktig måte, flytte noe, legge til en ressurs eller kanskje utsette noe som ikke har høyeste prioritet. Det gir mye spillerom. Fordi visningen er visuell, er den særlig nyttig når du kommuniserer oppover i organisasjonen. Folk har ofte et mer overordnet perspektiv og mindre tid til å gå inn i detaljene.

Du trenger ikke legge frem alle tallene. Du kan bare si: «Se her. Røde prikker er dårlige, og det er seks overlappende prosjekter. Jeg foreslår at vi flytter dette prosjektet.» Da kan de svare ja eller nei uten å måtte gå gjennom en masse tabeller.

Galen: Ja, jeg liker dette veldig godt. Jeg hadde et spørsmål om detaljnivå. Vi snakket om at jeg kanskje bare trenger å legge til en designer i noen dager underveis i et prosjekt, mens vi fordeler ressurser basert på planlagt eller tildelt forbrukstakt.

Hvordan ville du lagt inn en designer og tildelt ressurser til vedkommende? Det ser ut som om dette forutsetter et fast antall timer per uke for hver person på et prosjekt.

Fred: Ja.

Galen: Per person på prosjektet.

Fred: Denne løsningen gjør det. Det finnes også andre måter å sette det opp på. Du kan ha en tidslinje for hele prosjektet, og deretter en tidslinje for et underpunkt – jeg har ikke satt opp akkurat dette på den måten, men la oss late som prosjektet går fra januar til en senere dato.

La oss si at hele prosjektet går fra denne datoen til denne datoen. Nå lager jeg dette litt på sparket, så bær over med meg. Her er tidslinjen for designeren. Innenfor perioden fra 12. juni til 31. juli trenger vi designeren fra den 8. til den 18.

Greit. Da tildeler vi George til dette. [00:17:00] Nå skal du kunne se dette underpunktet. En annen nyttig ting er at du kan vise sammendrag av underpunktene på overordnet nivå.

Hvis du klikker på tidslinjen og velger «vis sammendrag på overordnet element», opprettes en egen tidslinjekolonne. Dette er prosjektets tidslinje, mens dette er sammendraget av de individuelle tidslinjene.

Det finnes noen utfordringer med dette når det gjelder automatiseringer, fordi det fungerer mer som en speilkolonne enn en vanlig kolonne. Men du kan se at tidslinjen nå går fra den 8. til den 18., og du kan holde pekeren over den for å se at det er elleve dager.

Hvis noen andre trenger noe i samme tidsrom, strekker tidslinjen seg, og du kan se at noe allerede er fylt ut. La oss gå til designer-visningen. Forhåpentligvis har jeg satt opp underpunktene. Vi burde kunne se at George har et prosjekt, men jeg husker ikke hvilket.

Det er prosjekt A. La oss finne prosjekt A. Han var allerede tildelt prosjekt A. Jeg fjerner ham og tildeler meg selv til prosjekt A. Nå burde vi kunne se det, med mindre jeg har satt opp feil visning. Jeg har ikke konfigurert dette for underpunkter.

Galen: Det går bra. Konseptuelt forstår jeg det, fordi du faktisk oppretter et underpunkt for at en designer skal komme inn i to dager i begynnelsen av august. Du legger det inn der, og det vises i ressursfordelingen hvis underpunktene er satt opp.

Fred: Ja, jeg satte dem nettopp opp i innstillingene. Jeg la til underpunktene i arbeidsbelastningseksempelet. Nå er George satt opp, og du kan se at designeren er tildelt i denne delen av tidslinjen.

Hvis du vil sette det opp slik, har du hele tidslinjen øverst, og så detaljene her. Det kan oppstå et problem hvis han også er tildelt overordnet nivå. Det kan derfor være best å ha en prosjektleder tildelt hele prosjektet, og deretter designer, utvikler, kvalitetssikrer og tekstforfatter som underpunkter.

Da kan du se hvor designeren er, hvor utvikleren er, og så videre.

Galen: Jeg liker dette. Da jeg jobbet i et byrå, var vi svært detaljerte i ressursfordelingen. En designer kunne komme inn i to timer på en bestemt dag. Vi jobbet nedenfra og opp: Vi sa at designeren trengtes her, her, her og her, og så ble alt summert opp.

Men i mange prosjekter i dag, særlig hvis du bruker en mer smidig arbeidsmetode eller har et fast team, hvorfor skulle du [00:20:00] gjøre dette nedenfra og opp? Da sier du kanskje: «Jeg trenger fire personer på denne oppgaven i åtte uker.» Det er slik vi fordeler ressursene.

Særlig i interne prosjekter utenfor kundetjenester kan teammedlemmene jobbe 50 prosent på prosjekter og 50 prosent med vanlig drift. Hvis de har en arbeidsuke på 40 timer, har vi 20 timer i uken til prosjektarbeid. Da tildeler vi dem til prosjekter, og under strategiplanleggingen ser vi om dette vil fungere.

Fred: I Monday kan du egentlig gjøre det på begge måter. Det er en eske med legoklosser. Hvis du vet hvordan du skal bruke verktøyet og kjenner prosessene dine, kan du få dem til å fungere godt sammen 90 prosent av tiden.

Når det oppstår problemer, finnes det ofte en app eller noe annet du kan bruke for å automatisere prosesser. Det finnes altså måter å sette dette opp på begge måter. Hvis du sier at dere gjør det på én bestemt måte, betyr ikke det at dere ikke kan bruke Monday. Det betyr bare at dere trenger noen som kan hjelpe dere med å finne ut hvordan dere gjør det i Monday.

Det er en av favorittdelene mine: Jeg gjør aldri det samme to ganger. Noen kommer til meg med en utfordring, og hver gang må jeg stoppe opp og tenke: Hvordan gjør vi dette egentlig? Hva er den beste måten å oppnå det på?

Noen ganger blir det en omfattende omvei med mange automatiseringer, men den fungerer. Andre ganger er løsningen sømløs og umiddelbar. Uansett er verktøyet tilpasningsdyktig.

Jeg tror det er derfor verktøy som Monday har tatt så mye markedsandel fra Microsoft Project. Microsoft Project var en gang gullstandarden innen prosjektstyringsprogramvare, men det var lite fleksibelt, dyrt å lisensiere og hadde en bratt læringskurve.

Du kan lære Monday på en time, eller i løpet av noen få timer. Utfordringen er at du virkelig må forstå hvordan verktøyet passer med prosessene dine. Det er der folk får problemer.

Galen: Det liker jeg. Jeg setter deg kanskje litt på prøve nå, for det er tydelig at verktøyet utvikler seg raskt. Du viste meg noen grensesnitt som ikke var der for et par måneder siden. Har en av de mer komplekse omveiene dine noen gang blitt fullstendig ødelagt av en endring?

Fred: Jeg har egentlig hatt det motsatte problemet. Monday er veldig flinke til å unngå å ødelegge ting. De er forsiktige, og det setter jeg pris på.

Problemet er at du kan bruke mye tid på å finne ut hvordan du lager en porteføljevisning på høyt nivå med detaljerte visninger under. Du kartlegger alt manuelt og blir veldig god på det. Så lanserer Monday noe som porteføljeverktøyet, som kom for en måned eller to siden, men som bare er tilgjengelig for virksomhetskunder.

Det er en overordnet visning der alle prosjektene dine vises, og alt kommuniserer med hverandre. Du kan opprette ulike styrer og så videre. Det er det samme vi har gjort på den vanskelige måten, bare at det nå er vakkert, enkelt og fungerer.

Jeg har aldri opplevd at de har ødelagt noe vi har satt sammen. Men jeg er vant til å bære bagasjen, og plutselig har jeg fått en trillebår.

Galen: Ja.

Fred: Da tenker jeg: «Greit, dette kan jeg bruke.» Når det skjer, er det bra, men noen ganger skulle du ønske at funksjonen hadde kommet tre uker tidligere.

Galen: I det minste lytter produktteamene.

Fred: Absolutt. Som partnere blir vi informert om nye funksjoner. De er flinke til å kommunisere dette, så vi har vanligvis en idé om hva som kommer. De har aldri ødelagt noe.

Noe interessant er at de begynner å dele produktet opp i flere produkter. Dette er arbeidsstyringsproduktet, som er et generelt verktøy for alt mulig. Kundene begynte å bruke det og spurte om de kunne bygge et CRM i det.

Vi begynte å lage CRM-løsninger med inntaksskjemaer, kontaktopplysninger og lignende. Monday innså at de kunne gjøre dette bedre med en egen plattform, og bygget derfor en CRM-plattform. Den kom for omtrent ett til halvannet år siden.

I starten var den litt uferdig. Noen ting kunne du ikke redigere, men de har jobbet mye med den det siste året. Nå er CRM-plattformen fantastisk og svært konkurransedyktig.

Den er kanskje ikke like tilpasningsdyktig som Salesforce, men den er mye mer tilgjengelig. Den er enklere å lære, og den er funksjonell. Du har e-post og aktiviteter, kan se når du har kommunisert med folk, og kan følge dem gjennom salgspipelinen.

Det finnes mange funksjoner som ikke eksisterte for seks måneder siden. Nå er det et svært konkurransedyktig CRM-system. Jeg skulle ønske jeg hadde større behov for det i den lille virksomheten min, for jeg har lyst til å bruke det. Vi bruker det for kunder, men jeg ville brukt det selv hvis jeg drev mer med markedsføring.

De har også et utviklerprodukt for utviklingsteam, som konkurrerer med Jira. Hvis du vil bruke Scrum-arbeidsflyter, kan du bruke utviklerproduktet. De har også et nytt produkt i betaversjon som snart skal lanseres, kalt Service. Det gjelder brukerstøtte, supportsaker og lignende.

Du kan få en e-post gjennom et inntaksskjema, opprette saken i styret, spore alle supportsakene, gi saken et nummer, kontakte folk, føre notater og overføre eierskap. Det er like enkelt som alt annet jeg har vist her.

Det er det jeg mener er den virkelige styrken ved Monday: Det tar ikke lang tid å lære. Hvis du lærer opp et team, kan du få noen til å sette opp et robust system og lære opp teamet i løpet av en helg.

Beklager, jeg kommer meg etter en liten forkjølelse i brystet. Men jeg synes virkelig dette er et fantastisk verktøy. Jeg vet at vi bare har noen minutter igjen. En annen ting jeg raskt ville vise, er Gantt-diagramvisningen.

Galen: Å ja.

Fred: Hei, Google, slutt å avbryte – teknologi, altså. Gantt-diagramvisningene kan brukes for hele prosjektet, og du kan sette dem opp på mange forskjellige måter.

Det fine er at de gir deg en visning som ligner på den vi hadde i arbeidsbelastningswidgeten, men du kan se helheten tydeligere. Her ser du datoperioden, prosjektene, når de starter og når de flyttes. Du kan dra ting rundt.

Du kan også ha avhengigheter. Prosjekt Z er for eksempel avhengig av prosjekt D. Hvis du flytter prosjekt D fremover, kan du sette opp avhengigheter slik at det ene prosjektet starter før det neste. Jeg hadde ikke konfigurert dette i eksempelet, men du kan flytte prosjektene rundt.

Poenget er at denne visningen er organisert etter prosjekter. Du kan også organisere etter tildelt person. Da kan du se Fred og George på de ulike prosjektene. Du kan også gruppere etter tjeneste.

Hvis jeg går tilbake til begynnelsen, viste jeg kanskje webdesign og tilpasset arbeidsflyt. Disse er satt opp på samme måte. Dette er tilpasset arbeid, dette er CRM, og dette er forbedring av arbeidsflyt. Du kan definere kategoriene selv.

Jeg kan se at jeg har fire arbeidsflytimplementeringer i andre og tredje kvartal, men tre av dem overlapper. Kanskje det er for mye, og jeg vil strekke ut ett av prosjektene. Du kan begynne disse samtalene før det blir et problem.

Det finnes også andre måter å sette det opp på. Dette er kanskje en oppstartsdato eller startdato. Det er mye interessant du kan gjøre. Instrumentpaneler er også svært nyttige, og jeg skal bare vise dem kort.

Dette henter data. Jeg har ikke så mye data her, men du kan se hvor mange timer som gjenstår, den gjennomsnittlige forbrukstakten og fordelingen av prosjekttyper. Du kan bruke en hvilken som helst type diagram, tabell eller arbeidsbelastningsvisning i dette instrumentpanelet.

Du trenger altså ikke ha en egen arbeidsbelastningsfane. Du kan legge arbeidsbelastningen inn blant mange andre elementer i et instrumentpanel. [00:29:00] Mulighetene er egentlig uendelige.

Galen: Jeg liker disse visningene. Jeg liker hvor tilpasningsbare de er. Du kan se hvordan dette kunne fungert i et ekte prosjektscenario: Du har detaljvisningen for deg selv, ulike visninger for driftsleder, trafikkleder og ressursleder, og en visning du kan bruke til å fortelle en historie til ledergruppen eller prosjektsponsorene uten at de må gå inn i alle detaljene.

Det kan brukes til å styre samtalen på en svært tydelig måte og tilpasses slik organisasjonen din arbeider.

Fred: Det er én annen ting jeg raskt vil vise. Da vi satte dette opp, var det faktisk nyttig for meg, fordi George – sønnen min – bygget dette, og jeg hadde ikke sett så mye på det som jeg burde.

Det jeg ba ham gjøre, var å dokumentere det. Hvis det oppstår en liten feil i Monday, er det vanligvis noe helt ubetydelig, som et nettleserproblem, og det løses raskt.

Dette er dokumentasjonen for styret vi nettopp så på. Her har vi visningene, hovedtabellvisningen, beskrivelsen og alle de ulike kolonnene. Det står hva hver kolonne er. Her er hvor lang tid prosjektet er beregnet å ta, her er formelkolonnen, og her er formelen som brukes.

Nedenfor har vi arbeidsbelastningswidgeten med de ulike delene. Jeg fikk dem ikke til å dokumentere Gantt-diagrammet, men du kan hente inn tabeller, styrer og visninger og legge til widgeter og mye annet i Monday-dokumentene.

Dette er en svært god praksis fordi dokumentasjonen ligger i konteksten. Tenk på det som en standard arbeidsprosedyre for hvordan dette styret fungerer, eller som prosjektnotater. Her har vi prosjektet og alle notatene. Jeg kan merke deg og si at Galen arbeider med denne delen. Her er handlingspunktene, og du kan få oppdateringer i dokumentet.

Det er en god måte å holde alt i riktig kontekst på.

Galen: Jeg liker det. Alt er samlet.

Fred: Ja.

Galen: Fantastisk. Fred, tusen takk for at du tok deg tid til å vise oss ressursfordeling, nedbrytning av forbruk, Gantt-diagrammer og alt det andre. Takk for at du delte kunnskapen din om Monday.

Mhm.