Sådan optimerer du din proces med workflowstyring (med Marc Boscher fra Unito)

Læs transskriptionen:

Vi afprø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:

Spilder du en masse tid på at forsøge at finde de oplysninger, du har brug for? Det er jeg sikker på, at du gør. Og hvad mere er: Hvis du leder andre mennesker, er det utroligt frustrerende at se dit team bruge timer på at finde information. Virkeligheden er dog, at der ikke findes ét workflowstyringssystem, der passer til alle. Dit UX- og strategiteam kan måske godt lide at bruge Trello eller Asana, men når det gælder udviklerne, vil de næsten altid gerne bruge JIRA. Så hvordan håndterer du dette kaos? Hvordan beslutter du, hvem der vinder? En McKinsey-rapport viste faktisk, at de fleste medarbejdere bruger omkring otte timer om ugen på blot at finde information.

Den gode nyhed er, at der findes en måde at løse problemet på, og løsningen er et system til workflowstyring. Hvis du er interesseret i at spare tid for dig selv, dit team og dit budget, så lyt med til dagens podcast. Vi skal tale om at skabe og optimere et system til workflowstyring. Tak, fordi du lytter med. Jeg hedder Ben Aston. Jeg er digital projektleder og grundlægger af thedigitalprojectmanager.com. Vi arbejder for at hjælpe digitale projektledere med at levere bedre resultater og hjælpe mennesker, der leder projekter i en digital verden, med at få succes.

Hvis du vil i kontakt med vores fællesskab, skal du gå til the digital project manager dot com. Her finder du masser af ressourcer, hvor du kan opbygge dine kompetencer, få større selvtillid og begynde at levere bedre projekter. I dag har jeg selskab af Marc Boscher. Marc er webudvikler, der blev produktansvarlig, og nu er han administrerende direktør og grundlægger af Unito. Marc, velkommen til podcasten.

Marc Boscher:

Tak, fordi jeg måtte være med.

Ben Aston:

Fortæl os lidt om din historie. Hvordan går man fra at være webudvikler til projektleder og derefter produktansvarlig for til sidst at grundlægge sin egen virksomhed? Fortæl os lidt om den udvikling.

Marc Boscher:

Det tog nogle år, tror jeg. Jeg begyndte under dotcom-boblen, hvor tingene bevægede sig meget hurtigt. Jeg blev trukket ind i teknologien og videre over i produktområdet. Grundlæggende har jeg arbejdet med produkter i 20 år. Når man arbejder med produkter, får man den ret fantastiske mulighed, at man hele tiden observerer problemer. Man bliver ved med at sige: nogen burde løse det her, nogen burde løse det her, men man kommer aldrig rigtig til det. Jeg beholdt dog listen, og Unito opstod grundlæggende ud af et af de problemer, jeg hele tiden observerede.

Ben Aston:

Du siger altså, at du har arbejdet med produkter i 20 år, mens Unito er et relativt nyt produkt. Hvor kom inspirationen til specifikt at udvikle en løsning på dette problem fra?

Marc Boscher:

Produktstyring og til en vis grad også projektstyring kræver, at man arbejder med mange forskellige teams, grupper og kompetencer, og man har sjældent formel autoritet. Man er sjældent deres chef. Man er nødt til at lede gennem indflydelse. Det betyder, at man ikke selv kan bestemme, hvilke værktøjer de skal bruge. Derfor ender man ofte med at skulle arbejde med den blanding af værktøjer, som hvert af de teams, man samarbejder med, bruger. Jeg fandt derfor hele tiden mig selv springe mellem Zendesk, Asana, JIRA, GitHub og alle de andre værktøjer og betale prisen for det. Det var et af de øjeblikke, hvor man tænker: nogen burde løse det her.

Typisk løser man det ved at tvinge alle til at bruge det samme værktøj. Men efterhånden som API'er udviklede sig, opstod spørgsmålet: Kan vi forbinde disse værktøjer? Kan vi lade folk blive i deres eget værktøj og undgå, at projektledere spilder al deres tid på at løbe rundt og spørge, om folk er færdige, hvor langt de er, og derefter fortælle dem, at en person er forsinket, så det påvirker dem? Det var grundlaget for idéen, som voksede ud af et klassisk behov for selv at løse sit eget problem. Det havde altid været planen på et tidspunkt at starte noget, så vi prøvede det, tog springet og så, om det fik momentum. Det gjorde det, og her er vi i dag.

Ben Aston:

Fremragende. Fortæl mig lidt om de værktøjer, I integrerer internt. Jeg ved, at man kan forbinde projektstyringsværktøjer og projektstyringssoftware som Trello, Asana og JIRA. Hvilke værktøjer vælger du selv at forbinde, og hvordan fungerer det?

Marc Boscher:

Personligt er jeg lidt af en værktøjsnørd, så jeg bruger stort set dem alle. Det er virkelig spændende, når man opdager et design, der passer til den måde, man tænker på, og som er tilpasset ens rolle. Man opnår meget, når det gælder produktivitet, men ofte er den virkelige barriere at overbevise andre om at skifte værktøj.

Jeg tror, at meget af barrieren for at tage teknologi i brug i dag handler mindre om det tekniske, såsom at installere og udrulle softwaren. Det handler langt mere om at få folk til at bruge den. Vi har omkring et dusin værktøjer nu. Vi lancerede en ClickUp-integration for et par uger siden, en anden kommer i næste uge, og endnu en om tre eller fire uger. Vi producerer integrationer til værktøjer inden for projektarbejde og arbejdsstyring: Asana, Wrike og Trello. Vi begyndte også med udviklerværktøjer.

Det gælder GitHub, Bitbucket, GitLab og JIRA. Fokus er på at forbinde projektledere med tekniske teams eller forretningsbrugere med tekniske teams, som typisk ikke taler samme sprog – og bestemt ikke samme værktøjssprog. Med tiden har vi også tilføjet Zendesk som supportsystem, HubSpot på salgs- og CRM-siden samt marketingværktøjer. Det handler om at begynde at se på arbejde som noget, der ikke kun foregår inden for ét team eller én proces, men på tværs af hele organisationen. Det er et langt større og vigtigere problem, hvor der bruges og spildes enormt meget tid .

Ben Aston:

Når du siger, at du er værktøjsnørd: Har du for nylig opdaget nogle nye værktøjer, som har gjort dig begejstret, og som du mener, alle burde have?

Marc Boscher:

Alle de værktøjer, vi integrerer, er blandt markedets bedste. Men vi vil gerne tro på, at der ikke findes ét bedste værktøj for alle. Det afhænger virkelig af, hvad man forsøger at opnå, hvem man er, og hvordan man arbejder. Det er en grundlæggende overbevisning. Jeg anbefaler ikke ét frem for et andet. Det afhænger af situationen. Hele virksomhedens grundtanke er, at alle har deres eget værktøj – det, der gør dem mest produktive – og udfordringen er, at det aldrig er det samme værktøj. Der kommer nye værktøjer hver dag. Vi vælger typisk dem, der er populære, på vej frem og i vækst. De skal naturligvis også have et API-lag, så de kan integreres, men de fleste værktøjer i dag har den komponent og det økosystemssyn på verden.

Ben Aston:

Marc har skrevet et indlæg, som du kan læse på thedigitalprojectmanager.com. Det hedder Sådan opbygger du et system til workflowstyring. Der er nogle eksempler. For dem, der ikke har læst det: Kan du forklare lidt mere, hvad du mener med workflowstyring? Som projektledere forstår vi processer som den måde, vi får noget fra A til B på – A er projektets begyndelse, B er projektets afslutning, og der er nogle trin undervejs. Det er processen.

Det er de trin, vi tager for at få projekterne ud ad døren. Ideen er, at vi på rejsen fra A til B leverer og skaber værdi. Hjælp os med at forstå, hvad workflowstyring er, og hvor den passer ind i forståelsen af at komme fra A til B, samtidig med at vi arbejder inden for projektets begrænsninger og kan skabe værdi ved rejsens afslutning.

Marc Boscher:

Det minder meget om det, vi allerede kender, altså den samme proces. Folk bruger ofte workflows og processer som synonymer. Vi kan godt lide at tænke på processer som forholdsvis lineære sekvenser trin for trin, og det er sådan, vi naturligt tænker. Når vi planlægger projekter, begynder vi ofte med: Først skal du gøre dette, så skal du gøre dette, og derefter skal du gøre det.

Så rammer virkeligheden. Når folk begynder at arbejde, opdager man ting, og man er nødt til at samarbejde på tværs af et team. En anden skal involveres i det meget dynamiske miljø, som digitalt arbejde er i dag. Det er ikke så lineært eller så specifikt, og det er langt mindre forudsigeligt. Når vi tænker på en proces, kan det være en softwareudviklingsproces, en proces for styring af en marketingkampagne, en produktlancering eller en salgsproces. Hvert team skal definere sin proces, og der findes masser af rammeværk til det.

Men når man begynder at samarbejde på tværs af disse grænser, handler det langt mere om møder, Zoom-opkald og chat end om at bruge de værktøjer, der gør det muligt at styre arbejdet og gennemføre leveringen. Når vi tænker på workflowstyring, ser vi på et lag, der forbinder det hele på tværs af alle disse processer og sørger for, at alle detaljer er på plads.

Ben Aston:

Hvis vi siger, at workflowstyringssystemet tager højde for den slags “hvis dette, så det”-scenarier, og at jeg talte om processer som den måde, man kommer fra A til B på i et projekt, så er virkeligheden, at rejsen slet ikke er en lige linje. Det er typisk en række løkker og skift, hvor man bevæger sig fra den ene vej til den anden. Vi har brug for en måde at styre, at disse ting sker. Vi ved, at når vi måske præsenterer UX for kunden, udvikler vi samtidig stilfliserne.

Hvad sker der, når UX bliver godkendt, men stilfliserne ikke gør? Hvordan laver vi en løkke? Hvordan holder vi projektet i gang og sikrer, at de rigtige mennesker er forbundet og opdateret på samme tid, så udviklingen kan begynde? Det kan være, at designiterationerne ikke kan fortsætte. En mere kompleks og nuanceret forståelse kan hjælpe os med at blive mere effektive i den måde, vi leverer projekter på, fordi vi ikke længere behøver at opfatte projekter som en ren lineær proces, men som en række små cyklusser, der gradvist integreres med hinanden.

Vi har parallelle arbejdsspor for UX, design, udvikling og kvalitetssikring. Disse ting kan begynde at arbejde og fungere mere problemfrit og effektivt, når vi forbinder dem tættere. Er det grundideen med workflowstyring?

Marc Boscher:

Ja, absolut. Det handler om at anvende mange af principperne fra agil arbejdsmetodik, som har lært os ikke at forsøge at kontrollere alt, men at give folk mere frihed til at samarbejde, fjerne hindringer for deres samarbejde og arbejde i korte cyklusser. Værktøjerne står i dag i vejen, fordi alle har forskellige værktøjer og forskellige processer. Det første skridt i workflowstyring er derfor at gå derhen, hvor arbejdet foregår – at acceptere, at folk arbejder forskellige steder – og gå derhen.

Det betyder at integrere de værktøjer, hvor arbejdet foregår. Det andet skridt er at kortlægge workflowet på tværs af dem og forme arbejdets flow. Hvad er reglerne? Hvilke retningslinjer gælder? Sådan arbejder marketing med selvudvikling, eller når der kommer en funktion, som ikke behøver at involvere designerne, men skal involvere produktejerne og udviklerne. Det skal ske uden nødvendigvis at begrænse dem, men snarere ved at åbne muligheder for, at de kan samarbejde fra deres egne værktøjer uden at forlade dem.

Et enkelt eksempel kunne være, at du har din projektplan i et Gantt-diagram i et værktøj som Wrike eller Asana eller en anden form for tidslinje. En af aktiviteterne skal udføres af udviklerne. Den aktivitet bliver automatisk til en JIRA-opgave, men forbliver synkroniseret med JIRA-opgaven. Når en person bliver tildelt den, arbejdet begynder, den placeres i en sprint og bevæger sig gennem udviklingscyklussen, ved projektlederen i realtid, hvad der sker. Projektlederen kan se fremskridtet i sit eget værktøj.

Marc Boscher:

Projektlederen kan se afhængighederne til andre afdelinger, teams eller aktiviteter uden at skulle springe rundt mellem de steder, hvor arbejdet foregår. Først skal man anerkende, hvor arbejdet foregår. Derefter forbinder man værktøjerne og definerer reglerne: Når noget sker i dette projekt, vil jeg for eksempel se det i min projektplan. Når det er gjort, behøver folk ikke at forlade deres værktøjer. Alle oplysninger er tilgængelige, uanset hvor man befinder sig. Pludselig er samarbejdet langt rigere og har mindre friktion. Det er dér, man kan begynde at optimere og forbedre.

Ben Aston:

Du taler om en forståelse af, at forskellige teams gerne vil arbejde i forskellige værktøjer. Jeg begyndte med at sige, at dit design- eller UX-team sandsynligvis ikke ønsker at arbejde i JIRA, fordi JIRA kan være meget komplekst. Det smukke ved noget som Unito er, at det gør det muligt for folk at arbejde i det værktøj, der fungerer bedst for dem. Det er en vedvarende udfordring ved udrulning af værktøjer, fordi alle hele tiden leder efter ét værktøj, der kan styre dem alle og gøre alt på den måde, de ønsker.

Virkeligheden er, at hvert værktøj har en filosofi om projektstyring, og hvordan projekter bør styres og gennemføres. Afhængigt af denne filosofi bliver det nemmere eller sværere for forskellige teams i organisationen at samarbejde og arbejde sammen på forskellige måder. Jeg har prøvet at få designteams til at arbejde i JIRA, og det er reelt en umulighed, især når man bygger et komplekst workflow ind i JIRA.

Hvordan udtrækker man så processen og beslutter, hvor komplekst workflowstyringssystemet skal være? Fortæl os om processen for workflowdesign. Hvordan siger man: Vi går fra A til B, UX og design foregår, og udviklingen skal begynde? Hvordan indbygger man kontrolpunkter og automatiserer ting uden at gøre det overdrevent komplekst? Et af mine problemer med JIRA er, at man designer og designer et workflow og derefter sidder fast.

Marc Boscher:

Fra den første dag var målet, at forretningsbrugere selv skulle kunne sætte det op – altså ikke-tekniske personer. Det er afgørende, for hvis man vil forbinde to teams, kan man ikke kræve tekniske færdigheder eller vente på, at en udvikler opsætter integrationen. Det handler om visuel udformning og om at kunne angive regler på naturligt sprog.

Det handler også om at kortlægge, at én proces kan være langt mere detaljeret end en anden. I softwareudvikling kan man have trin med kvalitetssikring, peer review og staging. Der er mange individuelle trin, som man måske ønsker at følge i udviklingsprocessen. Men fra et marketingperspektiv er man måske blot interesseret i, om en funktion er klar til lancering, og hvor tæt den er på at være det. Man er ligeglad med detaljegraden.

Et workflowstyringssystem skal derfor kunne sige: I marketing er dette min proces og mit workflow. Hvordan svarer disse trin til ingeniørteamets trin? De behøver ikke være én til én. Ti detaljerede udviklingstrin kan blot vises som “under udvikling” for marketingteamet.

Det begynder med en samtale om, hvordan I arbejder, og hvordan I kan bringe arbejdet sammen. Derefter får forretningsbrugerne fleksibilitet til selv at opsætte og løbende ændre relationen. Man behøver ikke finde ud af alt på én gang. Man kan begynde med enkle regler: Når jeg tildeler noget til Ben, skal det vises i hans værktøj. Eller når jeg eskalerer en sag til udvikling fra et supportsystem, skal den vises i dette projekt i JIRA. Man kan starte enkelt. Når man ser informationsflowet og hvordan folk arbejder, kan man gradvist opnå større sofistikering og tidsbesparelser.

Ben Aston:

Jeg kan se, at der er noget, der ligner et workflow bag dig. Når man har den samtale, hvor man kortlægger processen, ser det ud som et proceskort bag dig.

Marc Boscher:

Det er faktisk en rest fra fortiden. Det er en kunderejse, der var kortlagt på en væg med post-its og den slags. Den findes ikke længere. Det er nærmest tapet. Vi arbejder alle på afstand nu.

Ben Aston:

Når du forsøger at samle forskellige teams, som arbejder i forskellige værktøjer, og forstå hvem der har brug for hvad, hvornår og i hvilket format, minder det om at udvikle en kommunikationsplan. Hvad skal jeg fortælle dig, i hvilket format og hvornår? Hvordan faciliterer du den samtale? Designer du det direkte i værktøjet, eller starter du med at tegne det på en tavle for at få det store billede?

Marc Boscher:

Vi så kunder tegne det. De brugte whiteboards. Derfor byggede vi en funktion direkte ind i værktøjet, så man visuelt kan kortlægge, hvor arbejdet foregår, og derefter styre arbejdsflowet. Man former grundlæggende flowet og beslutter, hvordan arbejdet skal bevæge sig fra ét team til et andet.

Det, du beskriver, er afgørende. Kunderne er meget dygtige til deres proces i deres eget team. De har styr på den, og der findes masser af dokumentation. Men når vi taler med dem om samarbejde på tværs af teamets grænser, ved de ofte meget lidt om, hvordan de andre arbejder. Projektledere ved dette bedre end nogen, fordi de hele tiden lever ved grænserne og krydser dem.

I stedet for at projektledere bruger deres tid på at oversætte, bygge bro, kopiere, indsætte og gentage, hvad nu hvis værktøjerne bare holdt op med at være en hindring? Kommunikationsflowet kunne gå direkte, og projektledere kunne gøre det, de virkelig er gode til: samle mennesker, holde styr på risici, reducere risici og fastlægge prioriteter uden det manuelle arbejde med at holde alle informeret. Det er ikke dér, værdien ligger, men det er desværre dér, vi bruger vores tid.

Ben Aston:

Så meget af tiden i budgetstyring går med at sikre, at folk ved ting, de burde vide, og at de har læst den opgave, der landede i deres indbakke, eller har set, at noget blev opdateret i Trello. Alle kommer til at arbejde forskelligt, og man må imødekomme det. Hvis du vil bruge Trello, så får vi det ind i Trello. Hvis du vil have en JIRA-opgave, så får vi det til at ske. At gøre det muligt for folk at arbejde på den måde, der passer dem bedst, er virkelig fremtiden.

Men lad os tale om, når det mislykkes. Hvilke udfordringer er der ved systemet? I mit hoved kan workflowet blive løsningen på alle problemer, fordi man er blevet enige om det, men så ender man med mange ting, der sker mange forskellige steder, og ting falder stadig mellem to stole. Jeg gætter på, at en udfordring er blind tillid til værktøjerne. Hvilke udfordringer har du set med et workflowstyringssystem?

Marc Boscher:

Kommunikation er altid afgørende, uanset om man har et system til at integrere to teams eller ej. Det ændrer sig ikke. Når man gør kommunikationen lettere, fordi folk kan bruge de værktøjer, de allerede anvender til at arbejde, kommunikere, samarbejde og opdatere personer, der ikke bruger deres værktøj, bliver det ganske enkelt nemmere.

Tænk på det som et orkester. Du har flere musikere, og de har hver deres instrument eller værktøj. Violinerne er i Trello, klaveret er i JIRA, og en dirigent – typisk projektlederen – forsøger at holde dem synkroniserede. Men man tvinger ikke alle til at skifte til violiner. Det er deres styrke, at de hver især har deres eget.

Som dirigent forsøger du heller ikke at gøre dem perfekte. Du har begrænsede værktøjer og forsøger blot at lede dem gennem processen. De er selvstændige, de skal hver især nå frem på deres egen måde, og de har hver deres måde at spille sammen på. Moderne digital projektstyring minder meget om dette. Du dirigerer og vejleder en gruppe, der er autonom. Alle har lært at spille deres instrument på deres egen måde og at optræde med det.

Det handler om at samle dem og holde dem i harmoni. Det første spørgsmål er, om de alle kan se dirigenten og hinanden. I dag sidder alle i deres egen lille boks, og i en fjernarbejdende verden er det endnu sværere. Orkestret er spredt over hele verden, der er forsinkelser, tidsforskelle og tidszoner, og det gør det meget sværere at holde harmonien. Man kan derfor forestille sig en workflowstyringsløsning som det, der dirigerer alle disse mennesker uden at ændre den måde, de arbejder på, på tværs af tidszoner og værktøjer.

Ben Aston:

Hvordan ser du, at dette udvikler sig? Når du ser på fremtidens arbejde, fremtidens projekter og dit værktøjs fremtid, hvordan ser du så udviklingen, og hvordan ændrer projektlederens rolle sig?

Marc Boscher:

Forhåbentlig bruger projektlederne mindre tid på manuelt arbejde og mere tid på at dirigere. Vi tror, at tendensen mod stadig flere værktøjer vil fortsætte, fordi det er billigt at bygge software, nemt at distribuere den og nemt for folk at tage den i brug. Derfor skal man gå derhen, hvor folk arbejder, og omfavne virkeligheden i stedet for at bekæmpe den. Når man har ladet mennesker og teams organisere sig selv, skal man stadig samle dem og holde dem synkroniserede.

Når man har et workflowstyringslag, der forbinder dem som lim, får man pludselig langt større indsigt i, hvad der sker. Du begyndte med spørgsmålet om, hvem der vinder. Det antyder, at nogen skal tabe og skifte til det andet værktøj. Vi tror på en fremtid, hvor ingen nødvendigvis behøver at tabe, og hvor værktøjerne fungerer problemfrit sammen. Vi håber at være den platform, eller vi tror, at workflowstyring er den platform, der gør dette muligt.

Ben Aston:

Hvis jeg er ny inden for proces- og workflowstyring, og jeg arbejder i et bureau eller studie med fem til ti personer, der bare forsøger at få ting ud ad døren, hvor begynder jeg så med procesdesign og workflowoptimering? Hvad gør man, hvis man ikke engang ved, at man har en proces, fordi man bare udfører arbejdet? Fortæl os om de første skridt i at forstå og designe den optimale proces. Hvordan når man frem til det punkt, hvor man kan automatisere ting?

Marc Boscher:

Der er altid lavthængende frugter. Adgangsbarrieren er lavere, end man tror. Det er ikke så komplekst. Alle kunder har deres egen måde at organisere sig på. Især mindre bureauer er ofte nødt til at tilpasse sig det, kunden bruger. Det betyder, at man bruger meget tid på at lære det værktøj, kunden kræver, og tilpasse sig deres proces.

Start med ét projekt. Hvad bruger kunden? Hvad er dit ideelle værktøj? Hvis du kan bruge det samme værktøj, kan du begynde at gentage processen. Hvis du internt kan holde dig til ét værktøj til levering af bureauets projekter, og kunden næste gang bruger et andet værktøj, så prøv at integrere dem. Hvad nu hvis du kunne koble de to værktøjer sammen? Det er langt mindre forstyrrende, og adgangsbarrieren er meget lav.

Man kan afprøve det på ét projekt. Det smukke ved at gå derhen, hvor arbejdet foregår, er, at det ikke kræver en udskiftning af alt eller en masse forarbejde. Man kan gøre det med ét lille team, ét projekt eller ét workflow. Det kan være at få marketing til at sende en ændringsanmodning til udvikling på webstedet eller at få support til at eskalere en sag til udvikling. Begynd dér, hvor du bruger mest tid, og gentag derefter processen.

Ben Aston:

Jeg tror, at en mere agil tilgang handler om at bygge, teste og lære, når vi designer og optimerer processen. Vi får det ikke rigtigt første gang. Find de lavthængende frugter og muligheder for at bygge processer, hvor de ikke findes. En god måde er at se på erfaringerne fra det seneste projekt. Hvor gik det galt? Hvorfor faldt tingene fra hinanden? Hvorfor begyndte designet to uger senere? Hvorfor begyndte udviklingen for tidligt?

Når man identificerer den slags gennem evalueringer, kan det være et godt sted at begynde at designe en proces. Derefter bygger og kortlægger vi processen, tester den og lærer, hvad der fungerer, og hvad der ikke gør. Det kan være et godt første skridt til at designe og optimere vores proces. Marc, mange tak, fordi du var med i dag. Det har været fantastisk at have dig med.

Marc Boscher:

Tak, Ben.

Ben Aston:

Hvis du vil lære mere og blive bedre til dit projektstyrings- og procesdesign, så gå til thedigitalprojectmanager.com. Her finder du masser af gode ressourcer. Du finder også vores medlemskab og onlineundervisning. Indtil næste gang: Tak, fordi du lyttede.