Styring af omfangskryb (med Suze Haworth)

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:

Velkommen til DPM-podcasten, hvor vi går ud over teorien for at give ekspertråd om, hvordan man leder bedre digitale projekter. Tak fordi du lytter med. Jeg er Ben Aston, grundlægger af The Digital Project Manager. Hvis der er én ting, der afsporer næsten ethvert projekt, er det omfangskryb. Vi ved alle, at det er dårligt. Vi ved alle, at vi gerne vil undgå det. Men hvordan genkender man det i alle dets forskellige former? Hvad forårsager det? Hvem har skylden? Og vigtigst af alt: Hvordan håndterer man det faktisk? Alt dette bliver afsløret i dagens podcast, hvor vi taler om kryb i projektets omfang.

Denne podcast præsenteres af Clarizen, førende inden for virksomhedsprojekter og projektstyringssoftware.

Læs mere på clarizen.com

I dag har jeg Suze Haworth med. Suze er en af vores faste DPM-eksperter hos The Digital Project Manager, og hun arbejder som freelance senior digital projektleder i London i Storbritannien. Hun har mere end 10 års erfaring fra bureauer, og hun har oplevet meget omfangskryb, så hun er en fantastisk person at tale med i dag. Suze, velkommen.

Suze Haworth:

Hej Ben.

Ben Aston:

Suze, vi talte lige sammen, før vi begyndte at optage. Kan du fortælle lidt om den slags projekter, du arbejder på for tiden, og nogle af de udfordringer, du står overfor?

Suze Haworth:

Ja, jeg arbejder i øjeblikket freelance hos et bureau i London, så jeg er lidt delt mellem en senior projektlederrolle og en projektdirektørrolle på tværs af to kunder. Den ene arbejder jeg for hos IKEA, som er en stor detailhandels- og e-handelsvirksomhed. Vi laver et designsystem for dem, nærmere bestemt et slags prototype-designsystem. Derudover arbejder jeg også for en anden e-handelsforhandler i Storbritannien. Så lige nu er der mange detailhandelsprojekter. Hvad angår udfordringer, er det altid svært at tale om dem, især når de stadig er aktuelle. Men jeg tror-

Ben Aston:

Er det den besværlige kunde?

Suze Haworth:

Ja. Nej, faktisk ikke. De er virkelig gode – det er jeg nødt til at sige.

Ben Aston:

Det er du.

Suze Haworth:

Det er rigtigt. De er meget gode kunder, som jeg arbejder med for tiden. Jeg tror, at det både er det gode og det dårlige ved projekter og ved generelt at være projektleder: at arbejde med mennesker. Det er fantastisk. Jeg elsker at arbejde med forskellige mennesker, karakterer og særheder. Men nogle gange når man også et punkt, hvor man bliver frustreret over at forsøge at få ting ud af mennesker, der ikke ønsker at gøre tingene. Så ja, det har jeg oplevet lidt af på det seneste.

Ben Aston:

Sjov og ballade. Fortæl os om projektet med at bygge et designsystem, for jeg synes, det er et interessant projekt, og faktisk er det den slags projekt, vi ser flere og flere af. Tidligere kunne alle måske godt lide at behandle hvert projekt som et særligt snefnug, og de kreative ville gerne være kreative. Så fortæl os: Hvad er et designsystem? Hvad er det projekt, du faktisk arbejder på? Og hvordan ruller I det ud?

Suze Haworth:

Det er faktisk virkelig spændende, for som du siger, vinder designsystemer mere og mere indpas i den digitale verden. Grundlæggende fungerer de som et slags stilbibliotek for virksomheders og brands' digitale design. De fastlægger et grundlag af designede komponenter, moduler og skabeloner, som alle designere eller udviklere, der arbejder med brandet, kan bruge til at udvikle deres egne designs og deres kode. Det er altså et grundlag, som fremmer effektivitet – genbrugelig kode og genbrugelige designs – samt effektivitet og ensartethed i virksomheden.

En virksomhed som IKEA er et enormt brand med mange forskellige bureauer, mennesker og organisationer, der arbejder for dem. Et sådant designsystem kan fastsætte en standard, som designere og udviklere kan arbejde efter. For eksempel kan en knap eller en opfordring til handling på en side være ensartet på tværs af flere platforme, enheder, apps og andre digitale egenskaber.

Ben Aston:

Fortæl mig om processen med at styre projektet. Det kan jo være et projekt, hvor man lige så godt kan spørge, hvor langt et stykke snor er. Hvordan griber I det an? Hvad startede I med? Hvad itererer I på? Hvornår slutter produktet?

Suze Haworth:

For IKEA er det sådan, at mange brands faktisk laver dette som et internt projekt. IKEA søgte dog eksternt efter støtte og hjælp, og de ville have os involveret i designet. Det synes jeg er meget klogt, fordi vi kan komme ind udefra og gennemgå tingene med et mere objektivt blik, som ikke er så indlejret i virksomheden. Vi begyndte konceptuelt med at vurdere principperne, de centrale digitale principper, konceptet bag designet samt IKEAs brand- og designprincipper. Det var opstarten, altså et mere strategisk blik på den samlede oplevelse og designprincipperne. Derefter blev vi mere konkrete i designarbejdet og fastlagde et grunddesign baseret på eksisterende grundelementer som farver, typografi og gitre, hvorefter vi udviklede det videre.

Vi lavede derefter brugertests af designet på nogle få platforme, som vi valgte fra IKEAs digitale egenskaber. Derfra gik vi videre til at designe og bygge specifikke komponenter og placere dem på et designsystemwebsted, som i øjeblikket kun er internt. Det, vi arbejder på, er en fleksibel prototype, som i første omgang skal få det hele op at køre. Derefter udvikles den til en fuld løsning, når denne fase er afsluttet.

Ben Aston:

Fedt. Hvordan ser den fulde løsning ud? Er det en slags levende stilguide med kodestumper, som folk bare kan hente? Eller skabeloner, de kan hente? Er det den retning, det går i?

Suze Haworth:

Ja, jeg synes, at ethvert designsystemprojekt skal være en løbende, levende ting. Det har ikke en endelig afslutning. Det er ikke et produkt, man bare stopper med, og så er det det. Det skal udvikles. Vi er kun lige begyndt og har kun kradset i overfladen, når det gælder de første principper, grundelementer og komponenter. Derefter handler det om at gruppere komponenterne, udvikle moduler og også lave skabeloner. Så skal man finde ud af, hvordan man får folk til at bruge systemet og får det bredt ud, samt hvordan man får folk introduceret til det. Det er et enormt projekt, især med det store antal forskellige parter, der er involveret i virksomheden. Så vi er faktisk næsten kun lige gået i gang, selv om det har stået på i næsten et år.

Ben Aston:

Det lyder som et sjovt projekt. Jeg er altid nysgerrig efter at høre, om folk for nylig har fundet nogle værktøjer, eller hvad der gør deres liv fantastisk for tiden. Er der noget, du har fundet eller læst, som andre burde kende til?

Suze Haworth:

Jeg har ikke rigtig brugt andre værktøjer på det seneste, hvis jeg skal være ærlig. Jeg holder mig til det, jeg kender. Men det er ret ironisk, eftersom jeg er med i en podcast: Jeg har lyttet til flere podcasts på det seneste. Normalt hører jeg musik på vej på arbejde, hvor jeg har en times transport, men for nylig har jeg faktisk lyttet til en række podcasts. Det har været rigtig godt, fordi det er en anden måde at lære på, og man kan bruge tiden, mens man står i toget. Jeg havde nær sagt sidder, men jeg får aldrig en siddeplads. Så jeg bruger tiden ganske fornuftigt.

Ben Aston:

Er der nogle podcasts, du har fundet særligt nyttige eller interessante?

Suze Haworth:

Jeg er selvfølgelig nødt til at nævne The Digital Project Manager-podcasten. Det var givet på forhånd. Derudover lyttede jeg for nylig til en podcast for Drunken … efter min session på DPM Summit talte jeg med ham om, hvad min session handlede om. The Bureau of Digitalists på DPM Summit laver også nogle gode podcasts, og Brett, som driver konferencen, har for nylig udgivet en, der hedder Sprints and Milestones. Den er baseret på hans bog om digital projektledelse og er en ret nyttig ressource.

Ben Aston:

Godt stof. Så kom i gang med at lytte til podcasts. Noget, jeg selv har fundet interessant, og jeg ved ikke, om du har hørt om det, hedder Blinkist. Jeg må være ærlig: Jeg lytter ikke til ret mange podcasts, hvis overhovedet nogen, ud over min egen, hvor jeg selv taler. Men jeg tænker altid, at jeg virkelig burde læse den bog, og så køber jeg den enten og får aldrig læst den eller kommer aldrig videre. Blinkist har en funktion, hvor de laver meget koncentrerede resuméer af bøger. Det er lidt ligesom en-

Suze Haworth:

Jeg tror faktisk, jeg har hørt om det.

Ben Aston:

Det tager omkring 15 minutter at læse, eller man kan få resuméet læst op. Nogen læser bogens vigtigste pointer op. Det er lidt som en podcast, og det gode er, at man også kan sætte hastigheden op. Man kan ikke kun afspille det ved normal hastighed, men også ved dobbelt hastighed. Så tager det syv et halvt minut at læse eller lytte til en bog.

Suze Haworth:

Det er fantastisk. Det må jeg prøve, for jeg prøver også at læse lidt mere for tiden. Det ville være godt at få plads til flere bøger.

Ben Aston:

Det er mit lille bogtrick til jer alle: Blinkist. Nå, meningen var, at vi i dag skulle tale om omfangskryb. Så lad os tale om det. For dem, der ikke kender begrebet: Hvad er det, og hvorfor bør vi interessere os for det?

Suze Haworth:

Det er grundlæggende, når projektets omfang – altså leverancerne og alt det, man har aftalt, herunder funktioner i et projekt – udvider eller vokser i forhold til det, man oprindeligt blev enige om. Det sker uden, at man tager højde for den ekstra tid eller de ekstra ressourcer. Projektet kan påvirkes på mange måder, men det handler om, at ting begynder at snige sig ind, forlænger tidsplanen og får andre ting i projektet til at skride.

Ben Aston:

Så det er ekstra arbejde, som vi ikke havde taget højde for, og som påvirker vores budget, tidsplan og naturligvis omfanget – mængden af arbejde, vi udfører. Der er mange årsager til, at det sker. Vi er gode til at skabe mere arbejde for os selv. I den artikel, du har skrevet, er der en lang række årsager.

Suze Haworth:

Ja, der er mange.

Ben Aston:

Hvad vil du sige er de mest typiske årsager? Og bagefter kan vi tale om de mest snigende.

Suze Haworth:

Den mest almindelige er nok, at man ikke er tydelig om omfanget fra begyndelsen. Når man fastlægger leverancer og skriver en arbejdsbeskrivelse i starten af projektet, kan det give problemer, hvis man beskriver tingene for vagt eller ikke har en præcis definition af, hvad man faktisk leverer. Kunden eller interne personer kan fortolke det på forskellige måder, og så begynder projektet at vokse ud fra en vag beskrivelse af leverancerne.

Det første er altså at være tydelig om omfanget fra begyndelsen. Man skal også sikre sig, at den person, der godkender omfanget, er helt klar over, hvad vedkommende får. En arbejdsbeskrivelse er god til at opstille alle leverancerne og beskrive projektet, men det er ofte et langt dokument. Man giver det til kunden og forventer, at kunden læser, forstår og fordøjer alt indholdet. Derfor er det vigtigt at trække de centrale punkter, leverancer, tidsplaner og budget ud og forklare dem tydeligt. Selv hvis man tror, at kunden har læst det, er det vigtigt at gennemgå den indledende projektbeskrivelse sammen på et møde, så man er sikker på, at kunden forstår, hvad vedkommende får.

Jeg har set mange problemer opstå, når en arbejdsbeskrivelse er blevet godkendt, og folk senere siger: »Jeg troede, jeg fik det«, selv om det måske står mere specifikt et andet sted.

Ben Aston:

Så vi kan være uklare fra begyndelsen. Vi siger måske: »Ja, kunde, vi laver en sideskabelon til dig«, men vi definerer ikke, hvad der faktisk skal være i skabelonen. Ofte er udfordringen netop, at vi ikke har gjort det klart for kunden, hvad vi mener med en skabelon.

Suze Haworth:

Præcis. Det er de to ting: at fastlægge og forstå leverancerne tydeligt fra begyndelsen og sikre, at den person, der godkender omfanget, virkelig forstår, hvad man har sagt. Selv hvis man har været meget specifik, kan kunden stadig have en forestilling om, at vedkommende får noget andet, som faktisk ikke står i omfanget.

Ben Aston:

Så de to mest typiske tilfælde er, at vi ikke er tydelige, eller at kunden ikke forstår det.

Men hvad med den mere snigende side? Hvad er det mest usædvanlige omfangskryb, som sker, uden at man opdager det? Hvordan opstår det i de projekter, du har arbejdet på?

Suze Haworth:

Den typiske måde, projektledere ser omfangskryb på, er, at det kommer fra kunden. Kunden beder om noget ekstra, udvider ting eller vil have mere. Men det kan også komme fra interne teams og interessenter. Hvis interne teammedlemmer ikke har en klar forståelse af, hvad de skal lave, bevæger de sig i forskellige retninger og udvider ubevidst tidsplanen eller funktionaliteten. En designer kan designe noget, der ikke er gennemtænkt i forhold til, hvordan det påvirker udviklingsomfanget. Det kan ske helt utilsigtet, eller fordi de har en anden dagsorden og gerne vil bygge eller designe noget bestemt.

Det er måske mere overraskende, når det kommer indefra, fordi man forventer, at alle er på samme side, men det kan ske. Andre interne interessenter kan også få forretningsbehov flettet ind i projektet. De kan ønske, at man leverer mere af hensyn til kunderelationen, eller de kan have aftalt ting, som man ikke kendte til. Det er også en klassiker.

Ben Aston:

Jeg er helt enig. En af de mest snigende former for omfangskryb opstår internt, når der sker overforædling. Vores egne teams forsøger at gøre arbejdet ekstra flot, ofte inden for strategi, UX og design, men det kan også ske i udviklingen. Nogen vil gøre et virkelig fantastisk stykke arbejde eller tænker, at projektet kan blive noget, vi kan indsende til priser. Så lægger de ekstra arbejde i det, uden at nogen har talt om, hvem der betaler.

Suze Haworth:

Præcis.

Ben Aston:

Eller hvem der tager ansvaret. Folk kan gå deres egne veje og lave deres egen fortolkning af opgaven. En anden ting fra din artikel er kvalitetssikring. Når vi er i kvalitetssikringsfasen, har vi måske ikke defineret acceptkriterierne ordentligt, da vi skrev brugerhistorien. Eller vi har ikke sagt til kvalitetssikringsteamet, at de ikke behøver teste på IE9. Så finder de fejl i IE9, tester på BlackBerry eller noget tilsvarende, og pludselig bruger de masser af tid på noget, vi ikke bekymrer os om. Samtidig forsøger udviklerne at rette ting, der ikke behøver at blive rettet.

Suze Haworth:

Helt bestemt. Kvalitetssikring er et af de store områder, især i større projekter. I begyndelsen kan man estimere det nogenlunde ud fra det, man ved om udviklingsperioden, men det er svært at estimere, hvor meget kvalitetssikring der bliver behov for, hvor mange rettelser der skal testes igen, og hvor mange gentagelser der kommer. Det kan vokse og vokse, især hvis man ikke fastlægger parametrene fra begyndelsen.

Man skal fastsætte acceptkriterierne, vurdere browser- og enhedsmatricen og prioritere fejl og problemer. Hvilke fejl skal rettes, før man kan udgive? Hvilke har høj prioritet, og hvilke har lavere prioritet? Hvilke fejl kan man udgive med uden at løse dem, måske fordi de kun vedrører design eller overfladiske detaljer?

Det handler igen om at definere kerneomfanget så godt som muligt og fjerne usikkerheden fra begyndelsen. Det handler også om løbende kommunikation. Hvis kvalitetssikringen bruger mere tid på én bestemt enhed eller browser, skal man hurtigt være åben om det over for kunden eller interessenten.

Fortæl for eksempel, at IE kræver meget mere tid til kvalitetssikring, og foreslå alternativer. Man kan prioritere IE, hvis brugerbasen er stor, og behandle de andre browsere med en lavere prioritet. Det handler om hurtigt at synliggøre de problemer, hvor omfanget vokser, og samtidig tilbyde alternative løsninger.

Ben Aston:

Det er nyttigt. Vi har talt om uklart omfang, folk der går deres egne veje, og kvalitetssikring. Hvem har så skylden? For at håndtere det hjælper det ofte at identificere, hvem der har ansvaret – ikke for at pege fingre, men for at finde ud af, hvordan vi håndterer det. Vi har talt om kunden og om interne interessenter og teams, der overforædler arbejdet. Du nævner også tredjeparter, brugere og os som projektledere. I hvor høj grad er det vores problem og vores skyld?

Suze Haworth:

Det handler ikke om at bebrejde nogen, men om at afdække risiciene. Man bør se på, hvem i projektet der kan forårsage omfangskryb, og hvad de kan gøre. Det er en god måde at se på risiciene på forhånd.

Når det gælder os selv, ser vi ofte udad og spørger, hvad teamet eller kunden kan gøre. Men personligt handler det også om ikke at markere eller fremhæve, når der sker noget. Jeg indrømmer, at jeg selv har gjort det. Hvis der opstår et problem i et projekt, vil man gerne løse det og måske skjule det i stedet for hele tiden at fortælle kunden om alle problemerne og udsætte sig selv for den negative side af det, der foregår.

Man vil gerne holde projektet i gang og kæmpe mod tidsplanen, så man siger måske, at man kan få plads til det her eller det der, uden at gøre kunden opmærksom på det. Jeg tror, det er et stort område, hvor vi kan blive bedre.

Det er meget lettere at have samtalen, hvis man er ærlig og åben og hurtigt rejser problemet. Man kan tale det igennem og præsentere løsninger i stedet for blot at sige, at der er et problem, og derefter famle efter en løsning sammen med kunden. Først skal man erkende problemet og forstå, hvad det består i. Derefter kan man gå til kunden med nogle alternative løsninger.

Hvis omfangskrybet kommer internt, kan man undersøge, hvordan man trækker det tilbage, men stadig fortælle kunden, at det er sket. Hvis kunden beder om noget, der ligger ud over det aftalte, skal man ikke bare sluge det og forsøge at få plads til det. Se på konsekvenserne, find flere muligheder, og tal derefter med kunden om virkningen og om, hvad der for eksempel kan nedprioriteres.

Ben Aston:

Vi er allerede gået videre til, hvordan man håndterer det.

Suze Haworth:

Undskyld.

Ben Aston:

Det er helt i orden. Når vi har fastslået, at der sker omfangskryb, er det netop det, vi skal tale om. Som projektledere kan vi også være tydeligere om omfanget. Det hjælper at bede en anden projektleder om at gennemgå det, og kvalitetssikring eller en forretningsanalytiker er ofte gode til at finde huller og spørge, om man har tænkt på bestemte ting eller defineret dem ordentligt.

Vi skal også være bedre til kommunikationen. Vi må ikke bare kaste en arbejdsbeskrivelse over muren og håbe på, at kunden underskriver den. Det er bedre at gennemgå den sammen med kunden, så problemerne ikke opstår i første omgang.

Du siger også, at man ikke skal feje problemet ind under gulvtæppet. Som projektledere kan vi være fristede til ikke at tage det op, især hvis vi arbejder direkte med kunden. Vi ønsker at bevare relationen, så vi er ikke gennemsigtige fra begyndelsen, og til sidst bliver problemet for stort. Det, du beskriver i indlægget – at være proaktiv og transparent, prioritere og analysere konsekvenserne – er meget nyttigt.

En ting, du berører, er, at omfangskryb ofte forbindes med vandfaldsprojekter, hvor man planlægger meget i starten og derefter gennemfører fase for fase. Er det også et problem i agile projekter? Hvordan ser omfangskryb ud i et mere iterativt og fleksibelt projekt?

Suze Haworth:

Det, jeg gerne ville fremhæve i min artikel, er, at vi ser omfangskryb som noget negativt, fordi vi forsøger at holde os til et fast omfang, som vi har aftalt. Det gode ved agil udvikling og agile metoder er, at de handler om at omfavne forandring. Det er et af de centrale principper i agil udvikling. Forandring kan faktisk skabe et bedre produkt eller en bedre service. Det kan altså være godt at tillade forandring i projektet.

Forandring skal ikke ses som fjenden. Den kan være noget positivt. Det afgørende er, hvordan man håndterer den.

I et Scrum-baseret projekt aftaler man stadig, hvad man laver i den afgrænsede periode, altså sprintet. Man fastlægger, hvad der kommer i backloggen. Produkt Owneren eller kunden kan under et sprint forsøge at tilføje noget, efter at planen allerede er fastlagt. Det kan påvirke leverancen og udgivelsen.

Man skal sikre sig, at det nye ikke bare føjes oven i alt det øvrige. I stedet skal man omprioritere og sikre, at indsatsen for de nye historier eller epics opvejes ved at nedprioritere noget andet. Det sker altså også i agile projekter, men de kortere tidsafgrænsede perioder gør det lettere at håndtere ændringer.

Ben Aston:

Jeg kan godt lide at ændre samtalen og omfavne forandring. Når vi taler om omfangskryb, bliver det ofte en negativ samtale, fordi det typisk betyder flere omkostninger. Kunden beder om noget ekstra, som ikke var planlagt, og det kræver mere tid og budget.

En mere transparent og løbende dialog med kunden om budgettets begrænsninger gør det muligt at prioritere sammen. Kunden behøver ikke frygte, at en funktion, som var vigtig i begyndelsen, ikke bliver leveret, hvis man undervejs finder noget, der er vigtigere. Det er en god forandring. Den slags samtaler bør foregå gennem hele projektet og ikke først i den ellevte time, hvor man siger, at kunden enten skal betale mere eller undvære funktionen.

Suze Haworth:

Det er meget vigtigt løbende at tale om, hvad man leverer, fordi det i sidste ende skal handle om, hvad der er mest værdifuldt for brugerne. Hvis kunden siger, at de gerne vil have noget nyt, skal man ikke straks tænke, at det er umuligt, fordi planen allerede ligger fast. Spørg i stedet: Hvad er fordelen for brugerne? Hvorfor kommer kravet nu? Er der opstået et nyt behov?

Hvis det faktisk vil være mere nyttigt for brugerne, kan man sammenligne det med andre leverancer. Måske er den nye funktion vigtigere end en anden funktion, som derfor kan nedprioriteres. Det handler om løbende samtaler, at holde kunden involveret og analysere nye ønsker for at forstå deres egentlige værdi.

Ben Aston:

Det er et godt råd. Gør det til en samtale, og tænk på brugeren. Omfangskryb behøver ikke være negativt. Det kan være godt for brugerne, kunden, projektet og teamet. Det er ikke nødvendigvis noget, man skal løbe langt væk fra eller være bange for. Det kan være klogt at omfavne det.

Hvis man tænker: »Alle mine projekter ender altid over budget og bliver forsinkede. Vi har enorme problemer med omfangskryb«, hvad er så det ene råd, du vil give en person, hvis projekt er løbet fra dem?

Suze Haworth:

Hvis du bliver bedt om at komme ind i et nyt projekt, som lige skal til at begynde, er det bedste at fokusere på estimeringen og på, hvordan du afgrænser projektet. Sørg for, at du ikke arbejder isoleret. Estimér sammen med teamet, og gør estimaterne så gode som muligt, samtidig med at du husker, at de stadig kun er estimater. På den måde mindsker du risikoen for, at tidsplan og budget pludselig løber fra dig under leveringen.

Hvis du kommer ind i et igangværende projekt, skal du først gøre status. Find ud af, hvor langt over planen projektet er, og få et præcist billede af, hvad der mangler. Tal derefter åbent med kunden om problemerne og om, hvor projektet overskrider planen.

Ben Aston:

Fedt. Suze, mange tak fordi du ville være med. Det har været fantastisk at have dig med. Som en af vores DPM-eksperter medvirker Suze også i vores kommende kursus, der begynder i februar. Det hedder Mastering Digital Project Management. Hvis du ikke ved, hvad jeg taler om, men ved, at du har brug for projektlederuddannelse, så kig på det. Det er et syvugers intensivt kursus med interaktive videolektioner, opgaver, webinarer, gruppediskussioner og mulighed for coaching. Gå til DPMschool.com, og tilmeld dig, før kurset bliver fyldt op. Hvis du vil bidrage til samtalen om omfangskryb, kan du kommentere på indlægget og gå til ressourcesektionen på TheDigitalProjectManager.com for at tilslutte dig vores Slack-team, hvor der foregår mange interessante samtaler. Men indtil næste gang: Tak fordi du lyttede.