Rädda ditt projekt med ett projektdirektiv (med Maik Stettner från FCV Interactive)

Läs utskriften:

Vi provar att skriva ut våra poddar med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte är korrekt 100 % av tiden.

Ben Aston:

Tack för att du lyssnar. Jag heter Ben Aston och det här är podden The Digital Project Manager. Den här podden presenteras av Clarizen, ledaren inom programvara för företags-, projekt- och portföljhantering. Besök clarizen.com för att läsa mer.

Om det är en sak man kan vara säker på när det gäller ett projekt så är det att det aldrig kommer att gå helt enligt planen. Men varför spårar projekt ur? Ibland beror det helt enkelt på att vi kastar oss in i projekt för snabbt. Vi ser projektets deadline komma allt närmare och börjar därför projektet i lätt panik. När saker sedan börjar gå fel undrar vi varför.

Även om vi vanligtvis har projektets bakgrund, strategi, detaljer, krav och framgångsmått någonstans i bakhuvudet gör vi ofta misstaget att anta att alla andra också känner till allt detta. Men verkligheten är att om det inte är dokumenterat är chansen stor att teamet helt enkelt inte vet.

Så i dag ska vi prata om ett verktyg som vi kan använda för att få alla på samma sida vid projektets start. Det är ett projektdirektiv, eller det som oftare kallas projektbrief i vår värld. Vi ska ge dig en inblick i hur du kan skapa ett projektdirektiv och använda det för att göra dina projekt mer effektiva.

I dag har jag sällskap av Maik Stettner, en av mina vänner och kollegor. Maik är en av våra interna DPM-experter på The Digital Project Manager. Välkommen, Maik.

Maik Stettner:

Hej. Hur är det?

Ben Aston:

Bra. Det är roligt att ha dig med oss. Maik, låt oss börja med dig och berätta lite om din bakgrund. Vi arbetar ju tillsammans och har gjort det i, är det fem år nu?

Maik Stettner:

Ja, det är mellan fyra och fem år nu.

Ben Aston:

När jag anställde Maik minns jag att jag tänkte: ”Jag vet inte om den här personen kommer att klara det.” Du kommer från en något annorlunda bakgrund, inte den traditionella byråbakgrunden. Berätta om din historia. Hur blev du projektledare på en digital byrå?

Maik Stettner:

Sammanlagt har jag ungefär tio års erfarenhet inom olika områden. Jag började ursprungligen inom spel och utgivning, där jag hanterade lanseringar av spel i Europa och Nordamerika. Därefter gick jag vidare till andra områden, som medicinska databaser, men alltid inom programvaruutveckling och sådant som har att göra med projektledning, olika team och liknande. Under karriären fick jag också viss byråerfarenhet av apputveckling och inledande webbutveckling. När vi först pratade om att arbeta tillsammans gick jag i princip helt över till webbutveckling och byråarbete.

Ben Aston:

Ja.

Maik Stettner:

Jag har arbetat på mitt nuvarande företag, FCV, i ungefär fyra år. Nu leder jag projektledningsteamet på byrån och ansvarar i grunden för den övergripande leveransen av projekt och för att säkerställa att kunderna är nöjda med resultaten.

Ben Aston:

Bra. För dem som lyssnar och befinner sig i en liknande situation – kanske har de erfarenhet av att hantera programvara men överväger att gå över till en byrå och bli digital projektledare – hur upplevde du övergången? Vilka var de viktigaste skillnaderna mellan programvaruvärlden och världen inom digital projektledning, exempelvis när det gäller hur man hanterar människor eller projekt?

Maik Stettner:

Först och främst finns det många likheter. Sådant man möter inom andra programvaruutvecklingsbyråer eller andra projektledningsområden möter man även på en byrå. Man har olika team, projekt spårar ur av många olika orsaker och man kan använda samma metoder för att fånga upp problemen.

En av de största skillnaderna för mig var att förstå och tillämpa idén om att vara mycket fokuserad på tid och material och mindre arbetsdelar i stället för större leveranser. Kunder, särskilt inom det område där jag arbetar, vill ha större insyn och mer kontroll över mindre arbetsdelar. Det innebär mer detaljerad rapportering och större ansträngning för att vara transparent och förklara exakt vad man gör för att skapa förtroende.

Det var den största skillnaden för mig. Samtidigt var det intressant att se att man även inom helt andra områden stöter på liknande problem. Det spelar inte så stor roll om man arbetar med ett databasprojekt, ett spel eller en webbplats. Många problem kan överföras från ett område till ett annat. Om man använder erfarenheterna från sitt tidigare arbete – god kommunikation och vanlig god praxis som projektledare – är chansen stor att man lyckas, oavsett vad man bygger.

Ben Aston:

Det låter bra. Du nämnde att man stöter på liknande utmaningar. I din nuvarande roll hanterar du inte bara projekt utan även team. Vilka typiska utmaningar möter du när du leder projektledningsteamet och hanterar en hel portfölj av olika projekt med motstridiga resurskrav?

Maik Stettner:

Min roll är mer övergripande nu. Jag ser till att allt fortsätter att röra sig framåt. Ett av mina viktigaste fokusområden är resurssättning och att säkerställa att vi har rätt personer för rätt arbete under rätt tidsperiod.

Ofta måste man kompromissa när saker tar längre tid samtidigt som ett annat projekt redan är planerat. Då måste man hantera de justeringar som krävs och se till att kunderna har en öppen kontaktväg till mig. Risken med en mer övergripande roll är att man blir den enda andra personen som ansvarar för eskaleringar, vilket inte är den enda roll man vill ha – då ringer folk bara när de är arga.

Det är ändå bra att vara aktiv i olika projekt och bygga förtroendefulla relationer, samtidigt som man säkerställer att organisationen är rätt uppbyggd. Det kan handla om resurser, verksamhet eller samarbete mellan våra olika kontor. För oss är det viktigt att medarbetare från Toronto kan arbeta bra tillsammans med kollegorna i Victoria. Jag arbetar fortfarande nära vissa kunder och gör en hel del projektledning, eftersom det är där mitt engagemang finns.

Ben Aston:

Låt oss gå tillbaka till utmaningen med resurshantering. Du har två projektledare som båda har deadline på fredag och behöver samma resurser. Hur ser din prioriteringsprocess ut? Hur avgör du vilket projekt som får företräde?

Maik Stettner:

Jag tittar först på projektets prioritet. Har vi någon deadline? Har vi lovat kunden något? Måste något lanseras ett visst datum? Jag försöker se om det finns någon flexibilitet i tidsplanen.

Det spelar också roll om något exempelvis är fastställt i avtalet. Om ett projekt bara vill komma vidare och göra kunden en tjänst kan vi göra det om vi har tid. Men om det andra projektet ska lanseras om tre dagar kan vi förmodligen inte ta någon därifrån.

Det är grunden. Helst ska situationen inte uppstå, eftersom projektledaren bör förutse vissa överskridanden och lägga in buffertar. Jag förväntar mig också att teamet själva kämpar för de resurser de behöver.

Ben Aston:

Ja.

Maik Stettner:

Ofta är de för snälla och säger: ”Du kan få den här personen en dag.” I slutändan leder det till att allas arbete skjuts upp. Jag tycker inte om att plocka resurser från andra projekt, men på resursmöten förväntar jag mig att någon står upp för den tid som behövs och för problemet vidare till resursansvarig, som får lösa det.

Ben Aston:

Kanske är det ett kanadensiskt resursproblem.

Maik Stettner:

Definitivt ett kanadensiskt dödläge.

Ben Aston:

Kanadensare är för snälla, det kan vi européer säga. Eller är det bara kanadensare som får skämta om sådana degenererade typer?

Maik Stettner:

Precis. Jag ser dem definitivt annorlunda här i Europa.

Ben Aston:

Jag är alltid intresserad av verktyg. Har du nyligen upptäckt eller börjat använda något verktyg som fått dig att tänka: ”Det här är fantastiskt. Varför började vi inte använda det tidigare?” Vilken verktygslåda tycker du fungerar bra?

Maik Stettner:

Menar du för resurshantering?

Ben Aston:

Resurser eller projektledningsverktyg i allmänhet.

Maik Stettner:

Vi använder en ganska standardiserad uppsättning verktyg för tidshantering. MS Project kan ofta kännas överväldigande för kunden, så vi experimenterar mycket med molnbaserade produkter. Project har exempelvis en version för Office 365. Vi tittar också på programvara för tids- och resurshantering. Jag har inte hittat den perfekta lösningen eftersom vi har en ganska skräddarsydd process som delvis fortfarande är manuell.

Personligen tycker jag att det ideala verktyget för våra behov inte riktigt finns. Mitt mål skulle vara att bygga eller köpa något och sedan anpassa det efter de individuella behoven.

Ben Aston:

Vad saknar du i de verktyg som finns? Vad skulle göra dem användbara, eller är processen helt enkelt så komplicerad att verktygen ännu inte kan hantera den?

Maik Stettner:

Inte nödvändigtvis. Det är egentligen ganska enkelt. Jag söker ett verktyg som kopplar samman enkel tidshantering och bokning av timmar – eller medarbetarnas tidrapporter – med resursplanering. Något som Resource Guru eller liknande, där man kan planera behoven och sedan koppla dem till den ekonomiska sidan. När man arbetar med tid och material är den enkla matematiken antalet timmar multiplicerat med faktureringspriset. Därefter vill man få hela rapporteringsflödet på plats.

Det låter enkelt, men mycket måste beaktas när projekt förändras. Det kan påverka rapporteringen och skapa så mycket manuellt arbete att mätvärdena inte längre stämmer. Jag har ännu inte hittat den perfekta lösningen.

Ben Aston:

Låt oss prata om artikeln du skrev om projektdirektiv. Som jag nämnde i inledningen går projekt ofta fel eftersom vi inte startar dem ordentligt. Vi antar vad teamet känner till eller ger dem en mängd dokument och säger: ”Gå till den delade enheten och läs dokumenten. Allt finns där.” Sedan blir vi förvånade när de misslyckas, trots att de inte riktigt förstår projektet.

Hur kan vi skriva bättre projektbriefar eller skapa bättre projektdirektiv? Berätta om din process för att starta projekt och var projektdirektivet eller projektbriefen passar in. När skapar du det och hur kommer du fram till den punkt där dokumentet kan skrivas?

Maik Stettner:

Anta att du har en ny kund. Alla är entusiastiska eftersom det övergripande avtalet är undertecknat. Det kan vara ett övergripande ramavtal som säger att företagen ska börja arbeta tillsammans. Nästa steg är att göra detta mer konkret.

Vanligtvis tänker man på en arbetsbeskrivning. Problemet är att allt i början är på mycket hög nivå och bara en uppskattning av vad ni faktiskt kommer att göra. Projektdirektivet och uppstartsmöten är bra verktyg för att förstå kunden och upptäcka andra drivkrafter som kanske inte togs upp i den ursprungliga arbetsbeskrivningen.

När den första arbetsbeskrivningen har tagits fram – kanske fortfarande som ett utkast – gör teamet en intern uppstart för att gå igenom arbetet. Därefter har man en extern uppstart med kunden på en högre nivå: detta är vad vi ska göra, detta är teamet, så här samarbetar vi och detta är den omfattning vi har definierat.

Projektdirektivet eller projektbriefen är nästa steg mot att göra arbetet mer konkret. Tidigt i processen måste det dock ses som ett levande dokument, eftersom det ännu inte är helt klart vad alla detaljer kommer att innebära. Det är ett bra verktyg för att ge affärsmässig kontext och säkerställa att de grundläggande projektparametrarna är tydliga både för kunden och det interna teamet.

Ben Aston:

I din artikel beskriver du att dokumentet bör innehålla kontext, projektparametrar, projektets arbetsstruktur, vem som gör vad och riskhantering. Hur ger man teamet tillräcklig kontext utan att förvirra eller överbelasta dem? Hur avgör man vad som är brus och vad som faktiskt är användbart?

Maik Stettner:

Det handlar om varför kunden genomför projektet och vilka problem som behöver lösas på en övergripande nivå. Finns det affärsmässiga drivkrafter? Vill kunden öka försäljningen, utbilda en målgrupp eller genomföra en omprofilering? Den centrala frågan är hur framgång definieras. Hur vet vi i slutet om vi har lyckats?

Det kan handla om bättre försäljningssamtal eller en självbetjäningswebbplats som gör innehåll tillgängligt genom ett innehållshanteringssystem. Det är viktigt att ge teamet rätt utgångspunkt så att de vet vad de arbetar mot. Även om stegen ännu inte är detaljerade hjälper kontexten till att rama in arbetet.

Om man exempelvis arbetar med en omprofilering och målet är att ompositionera ett företag kan någon i slutet fråga varför försäljningen inte ökade. Då kan man gå tillbaka till dokumentet och visa att detta inte var projektets mål. Dokumentet fungerar som en historik över vad som diskuterades och hjälper kunden och teamet att enas om det övergripande målet.

Ben Aston:

Det är särskilt användbart när man skapar något nytt. Att förstå varför kunden driver projektet, vilket problem vi försöker lösa, vilka affärsmålen är och hur framgång ser ut ger teamet bakgrundsinformation som hjälper dem att forma lösningen. Låt oss prata om projektparametrar. På vilka sätt är det bra att begränsa teamet?

Maik Stettner:

Man vill inte begränsa experterna för mycket. Men om man ger dem helt fria händer kan de arbeta med ett helt annat projekt än det man föreställt sig. Därför är det viktigt att ange ramarna och grunderna: budget, tidslinje och övergripande schema.

Helst har teamet varit med och uppskattat detta, så det ska inte vara något nytt. Det är värdefullt att gå igenom förutsättningarna. De är inte begränsningar utan det som har överenskommits: vad ni ska leverera till kunden inom en viss budget.

Om någon behöver mer tid är det teamets uppgift att avgöra hur arbetet ändå kan genomföras. Ha en diskussion på hög nivå och ge inte teamet intrycket att du gör livet svårt för dem. Hjälp dem att göra sitt arbete och visa att du står bakom dem vid möjliga budgetökningar, risker och förändringar i tidsplanen.

Ben Aston:

Du nämner också en projektstruktur, arbetsstruktur och en plan för resurser. Hur skapar man en första grovplan när projektet fortfarande är odefinierat?

Maik Stettner:

Ärligt talat är det antagligen en kvalificerad gissning. Man utgår från arbetsbeskrivningen eller den uppskattning som teamet har tagit fram. Många saker är fortfarande osäkra, exempelvis hur många revideringar kunden behöver. Planen kanske inte kommer att hålla exakt.

Men även en ungefärlig plan hjälper byrån och andra projektteam att planera resurser och skapa stabilitet. En ambitiös första plan kan behöva kundens godkännande och kunden kan säga att mer tid behövs, men den hjälper ändå till att synliggöra arbetet och förstå vad teamet måste gå igenom.

Man kanske upptäcker att en designer behövs trots att det inte hade planerats. När teamet diskuterar detta tidigt förstår projektledaren arbetets detaljer och kan ställa rätt frågor och vägleda kunden. En grov plan är bättre än ingen plan alls, eftersom den skapar diskussion och kan göras mer detaljerad när tiden går.

Ben Aston:

Att ha någon form av plan är bättre än att inte ha någon plan alls, eftersom planen alltid kan utvecklas. Om teamet får en plan kan de reagera på den och säga att den är orealistisk. Det ger en startpunkt för diskussion i stället för ett tomt papper.

Projektdirektivet låter som ett mycket formellt dokument, men det behöver inte vara stort och formellt. I grunden ger vi kontext, parametrar och en plan. Vilka andra former kan projektbriefen ha, och hur förändras dess roll under projektets livscykel?

Maik Stettner:

Guiden jag tog fram är ett exempel på vad man kan ta med. Det finns viss minimiinformation som bör finnas i ett projektdirektiv eller en projektbrief, men det finns andra sätt också. Riskhantering kan exempelvis vara ett separat dokument. En RACI-matris kan kopplas till statusrapporter och liknande.

Det behöver inte alltid vara väldigt formellt. Det viktiga är att alla är överens. Det kan ligga på SharePoint eller BaseCamp, och det kan uppdateras genom samtal. Om man senare upptäcker att försäljningsdelen saknades måste den läggas till, vilket naturligtvis kan påverka projektets omfattning.

Så länge det finns något skriftligt – även ett formellt e-postmeddelande – som människor kan enas om och bekräfta är det tillräckligt. Det behöver inte undertecknas och stämplas av alla, men alla måste känna till det och acceptera det, eftersom det är det som ska levereras och ligga till grund för arbetet.

Ben Aston:

Den goda nyheten är att Maik har skapat en bra mall som du kan använda för din projektbrief eller ditt projektdirektiv. Läs artikeln för att ladda ner den. Maik, tack för att du var med i dag. Det har varit roligt att ha dig här.

Maik Stettner:

Tack för att jag fick vara med.

Ben Aston:

Som en av våra DPM-experter kan du glädja dig åt att Maik medverkar i vår kommande kurs, som börjar i september och heter Att bemästra digital projektledning. Det är en sju veckor lång intensivkurs med interaktiva videolektioner, veckovisa uppgifter, gruppdiskussioner och möjlighet till coachningssessioner. Besök digitalprojectmanagerschool.com och anmäl dig innan kursen blir full.

Om du vill bidra till samtalet om projektdirektiv eller projektbriefar kan du gå till resursdelen på digitalprojectmanager.com och gå med i vårt Slack-team. Där hittar du många intressanta diskussioner. Kom också ihåg att kommentera artikeln och dela den. Tack för att du lyssnade.