Få styr på kravene (med Kelly Suter fra BI Worldwide)

Læs transskriptionen:

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

Ben Aston:

Velkommen til DPM-podcasten, hvor vi går videre end teorien for at give ekspertråd om projektledelse, så du kan lede bedre digitale projekter. Tak fordi du lytter med. Jeg er Ben Aston, grundlægger af The Digital Project Manager. Så vær ærlig: Har din kunde nogensinde vendt tilbage ved projektets afslutning og sagt: “Hey, det dér ramte I virkelig plet med. Det er præcis det, vi ønskede, det er nøjagtigt det, du sagde, I ville gøre i begyndelsen af projektet, og det er fantastisk, hvordan det er lykkedes jer at få det hele med uden at tabe noget undervejs.”

Jeg har på fornemmelsen, at det ikke er sket. Og det skyldes sandsynligvis, at dine krav ikke blev fastlagt ordentligt. Så hvordan håndterer du krav, så du ikke ender i et totalt rod senere i projektet, men giver kunden og udvikleren det, de har brug for, for at få arbejdet gjort? Det er det, dagens podcast handler om: projektkrav.

Den måde, vi definerer et projekt og funktionalitet for vores kunder på, så alle ved, hvad der bliver leveret. Grundlæggende mener jeg, at krav er et kommunikationsværktøj, men det er virkelig svært at få dem rigtigt på plads. Hvis vi definerer kravene for løst, giver vi os selv større fleksibilitet, men vi får måske ikke præcis det tilbage, som vi ønskede. Og hvis vi definerer dem for stramt, vil vi opdage, at der måske mangler en masse ting. Så hvordan finder vi den rette balance?

I dag taler jeg med Kelly Suter. Kelly er teknisk projektleder hos BI Worldwide og en af vores faste Deakin-eksperter hos The Digital Project Manager. Hej Kelly.

Kelly Suter:

Hej, og tak fordi jeg måtte være med, Ben.

Ben Aston:

Det er fantastisk at have dig med. Jeg tror, det er vores anden podcast, ikke?

Kelly Suter:

Jo, det er det.

Ben Aston:

Vi lavede en podcast for lang tid siden. Så til dem, der har glemt, hvem du er: Vil du give os et overblik over, hvordan du kom ind i projektledelse? Du har taget en interessant vej, synes jeg, og ikke helt ulig de fleste projektledere. Vi havde aldrig forestillet os, at vi skulle være projektledere, da vi voksede op. Men fortæl os lidt om din historie. Hvordan endte du som digital projektleder?

Kelly Suter:

Jeg begyndte faktisk min professionelle karriere som sportsreporter. Jeg havde læst kommunikation med fokus på public relations og medier, og da jeg indså, at aviser ikke længere var en branche i vækst, besluttede jeg mig for at kigge over mod PR-branchen. Jeg arbejdede som PR-medarbejder i omkring tre år for ét brand, Sesame Street Live, og jeg opbyggede virkelig stærk erfaring med det brand. Derefter kendte jeg en person, som arbejdede hos en specialiseret e-handelsvirksomhed, et digitalt bureau med fuld service, der fokuserede på e-handel.

Hun sagde: “Vi har ikke en projektledelsesafdeling her. Har du lyst til at blive projektleder?” Og jeg sagde: “Hvad er det?” Min far havde faktisk et grafisk designbureau, så jeg var vokset op med et vist kendskab til bureauprocesser og vidste, at det var hektisk og altid i bevægelse. Men jeg tænkte: “Ja, det lyder interessant. Lad os se, hvad I har gang i.” Jeg tog derhen, og den første bog, jeg nogensinde læste, var skrevet af Meghan McInerny og hed People, Pixels, and Process. Jeg ved ikke, om jeg siger titlen i den rigtige rækkefølge, men jeg læste den og anvendte den så godt, jeg kunne, på det bureau, jeg stod over for. På det tidspunkt var vi 12 personer, og vi byggede skræddersyede brochurewebsites og e-handelswebsites.

Efter cirka fire år havde jeg opbygget et team på syv projektledere, og vi kunne anvende den proces, der hele tiden udviklede sig. Derefter tænkte jeg, at jeg følte mig godt tilpas med Magento, Drupal, Cantego, WordPress og den slags, men jeg ville gerne udvide min tekniske viden. Derfor søgte jeg en stilling som teknisk projektleder hos BI Worldwide, hvor jeg arbejder nu. Jeg ville tilbage til projektlederverdenen, tættere på projekterne og skærpe mine tekniske værktøjer. Det er her, jeg er i dag. Det har været virkelig spændende. Det føles, som om tiden er fløjet af sted, men jeg elsker det.

Ben Aston:

Jeg er altid nysgerrig: Er det her på en måde dit drømmejob nu? Det lyder, som om du har været igennem en rejse, hvor du har været sportsreporter, arbejdet for Sesame Street og nu arbejder med teknologi som projektleder. Hvad vil du være, når du bliver voksen?

Kelly Suter:

Det er et rigtig godt spørgsmål. Jeg tror, det, jeg bedst kan lide ved det, jeg arbejder med nu, og det, jeg for nylig arbejdede med hos Irish Titan, en anden udviklingsvirksomhed, er at komme ind i situationer, hvor en proces ikke rigtig findes endnu eller netop er begyndt at udvikle sig. Det betyder ikke, at teamet ikke er utrolig dygtigt eller allerede leverer gode resultater, men jeg elsker at tage udfordringerne op og finde ud af, hvilken proces der kan fungere. Jeg kan godt lide at give teams den lettelse, der kommer af at have noget at arbejde med og læne sig op ad, altså at etablere en proces.

Så jeg tror, mit drømmejob er at være en slags brandmand, for at bruge et bedre ord, for virksomheder i vækst eller nystartede virksomheder. At komme ind og sige: “Okay, vi ved, at vi har implementeret denne proces. Lad os se jer bruge den på dette projekt og på det næste.” Jeg elsker virkelig en saftig udfordring.

Ben Aston:

Fint. Fortæl mig så: Hvilke udfordringer arbejder du med nu? Du nævnte idéen om at slukke brande og forsøge at få styr på processer i et bureau. Men hvilke udfordringer møder du dag efter dag, eller hvilken særlig udfordring arbejder du med lige nu?

Kelly Suter:

Lige nu vil jeg sige, at min største udfordring blandt alle de ting, vi hele tiden kæmper med, er at få teamet til at bakke op om dokumentation på en måde, der ikke er kedelig. Jeg vil ikke lyde, som om jeg bare sælger emnet for denne podcast, men jeg synes virkelig, det er svært, når man har en engageret kunde og et engageret team, at få fuld opbakning til at sige: “Okay, vi behøver ikke sænke tempoet eller miste momentum, men vi er nødt til at dokumentere.” Derefter skal dokumentationen skabeloniseres, og man skal dække sine baser tilstrækkeligt.

Det behøver ikke være så omstændeligt, som det kan blive. Men man skal dokumentere nok til, at logik og proces ikke går tabt, hvis man skifter team, bliver forfremmet eller får en anden rolle. Jeg har set teams, der konstant genopfinder den dybe tallerken, enten i deres produktudvikling eller i deres dokumentation. De overkonstruerer noget, der ellers kunne være skabeloniseret eller gjort mere effektivt.

Så lige nu handler det for mig om at få teamet med. Jeg dokumenterer noget, hvor den seneste dokumentation er fra 2014. Det har fungeret for alle, også kunden, men vi ønsker ikke, at det skal fortsætte sådan. Senere, når man skal revidere det, er det rart at have alting samlet og på plads.

Ben Aston:

Så du arbejder med udfordringerne ved at definere processer, skabe dokumentation og forbedre processer. Når du gør det, bruger du så nogle bestemte værktøjer? Hvad gør dit liv lettere lige nu? Hvordan leverer du det, og hvad bruger du til det?

Kelly Suter:

Når det gælder dokumentation, bruger jeg Google Suite. Jeg følger princippet om ikke at reparere noget, der ikke er i stykker. Hvis kunderne ikke har sikkerheds- eller privatlivsproblemer med oplysningerne i den dokumentation, man formaliserer, er Google Suite og Google Docs gode løsninger. Man får et delt arbejdsområde og mulighed for at angive, hvem der kun må se, hvem der må kommentere, og hvad der kun må deles internt med teamet.

Man behøver ikke bekymre sig om versionsstyring, og senere kan man eksportere dokumentet som PDF og gøre det til et formelt dokument, der kan underskrives. Når det handler om selve skrivearbejdet, er det det, vi bruger. InVision er et rigtig godt værktøj til kreative gennemgange og kommentarer, når man samler den kreative del. Designerne kan lægge alle deres designs eller wireframes ind, og derefter kan kunden eller den interessent, der gennemgår materialet, kommentere. Når designene er færdige, kan man annotere dem i InVision og eksportere dem til dokumentationen, fordi visuelle elementer sammen med dokumentation er meget nyttige.

Hvis man ikke har InVision, fordi det er en løsning, man skal betale for, og den kan blive dyr, kan man bruge Sketch. Sketch er et gratis værktøj fra Evernote, som man kan bruge til at annotere på en enkel og flot måde. Man uploader sine designs, tilføjer tal eller bogstaver, alt efter hvordan man vil annotere dem, og arbejder videre derfra.

Jeg prøver altså ikke at gøre det mere kompliceret end nødvendigt. Jeg har brug for en måde at importere mine designs, annotere dem, lægge dem ind i dokumentationen og derefter skrive ordene. Det er de løsninger, der har fungeret for mig, når det handler om dokumentation.

Ben Aston:

Det er godt. Jeg vil gerne gå lidt dybere ned i din udvikling som digital projektleder. Nu er du teknisk projektleder, men jeg forstår, at du bærer flere forskellige hatte. Du er projektleder, BA, forretningsanalytiker og SCRUM-master. Hvordan adskiller en teknisk projektleder sig fra en digital projektleder? Er det det samme? Og hvordan fungerer det for dig at bære alle de forskellige hatte?

Kelly Suter:

Det er et rigtig godt spørgsmål. I min rolle her føler jeg mig meget heldig, fordi den er unik. Hos BIW arbejder jeg både som teknisk projektleder og med mere traditionel projektledelse. Jeg arbejder med projektledelse af livebegivenheder og med projektledelse af kursusindhold, hvilket udgør omkring en fjerdedel af mit arbejde. De resterende tre fjerdedele er teknisk projektledelse, og det vil variere alt efter, hvor man kigger.

Man kan finde digital, teknisk og agil projektledelse, men man er stadig projektleder. Den største forskel mellem den digitale projektlederrolle, jeg havde tidligere, og den rolle, jeg har nu som teknisk projektleder, er efter min mening graden af forståelse, der kræves af det digitale arbejde, man udfører. Hvor teknisk bliver arbejdet?

Da jeg var digital projektleder, havde jeg fingrene i alle de bevægelige dele. Jeg arbejdede måske på et lidt højere niveau, men jeg vidste, at jeg skulle forstå indholdsstrategi, informationsarkitektur, wireframing og kreativt arbejde. Når det gjaldt udvikling, tænkte jeg mere: “Okay, jeg ved, at I skal gennemgå disse data, og jeg ved, at I skal finde ud af, hvordan dataene skal se ud som eksport til lageret. Sig til, når I er færdige.”

I rollen som teknisk projektleder er jeg meget længere nede i detaljerne, især når det gælder udvikling. Jeg styrer stadig leverancer fra kreativt arbejde, digital strategi og kvalitetssikring, men i udviklingsdelen kan jeg på et projekt være nødt til at være tættere på kvalitetssikringen. Ved kodegennemgange og udgivelser arbejder jeg side om side med den ledende udvikler og siger: “Det her er de krav, jeg har skrevet. Hvordan stemmer de overens med den kode, du ser, før vi markerer punktet som færdigt?”

Den anden forskel er, at jeg selv skriver de tekniske krav. Jo tættere man er på kravene, desto større ansvar har man, og desto mere skal man være involveret, når spørgsmålene senere dukker op.

Som digital projektleder styrede jeg kravene og sørgede for, at de rigtige personer fik dem gennemført. Som teknisk projektleder skriver jeg dem faktisk selv. Jeg er altså længere nede i skyttegravene, når det gælder udvikling.

Ben Aston:

For personer, der ikke kender begreber som funktionelle krav eller forretningskrav, er det altså det, du arbejder med: at udforme funktionelle krav og forretningskrav. Det er ofte et lidt uklart og forvirrende område, fordi udviklere kan sige: “Det er projektlederens opgave,” eller: “Det er forretningsanalytikerens opgave. Det er ikke min opgave at definere tingene.” På den anden side kan forretningsanalytikeren eller projektlederen sige: “Jeg kan ikke definere det her. Jeg ved ikke, hvilke muligheder der findes.” Du befinder dig tydeligvis et sted midt imellem. Hvordan griber du den proces an?

Kelly Suter:

I begyndelsen af ethvert projekt, eller når man kommer ind på et nyt team eller i en ny virksomhed, er det vigtigt at forstå roller og ansvar. Selvom de måske er defineret, kan de udvikle sig eller ændre sig afhængigt af kunden. Hvis vi for eksempel arbejder med en skræddersyet integration, kan jeg sige: “Denne integration er som et lager, en database med alle disse forskellige produkter. Jeg har brug for, at de er tilgængelige med det samme, at de viser præcis, hvor mange T-shirts der er på lager, og hvor mange der findes i små, mellemstore og store størrelser. Dataene skal opdateres dagligt på dette tidspunkt.”

Jeg kan fortælle udvikleren, hvad jeg har brug for, men udvikleren går måske et niveau dybere, som jeg ikke kan nå, og som jeg ikke forstår. Jeg kan ikke lade som om, jeg forstår det, og det ønsker jeg heller ikke. Jeg vil sætte mig ned og sige: “Okay, jeg tager ansvar for kravene frem til dette punkt. Kan du hjælpe mig med resten og stille de fem hvorfor-spørgsmål?” Det er noget, jeg også nævner i min artikel: “Hvorfor skal dette udfyldes på denne måde?” Fordi det er sådan, kunderne køber produktet. Og hvorfor? Og hvorfor?

På et tidspunkt må man trække en grænse og sige: “Okay, udvikler, jeg har brug for, at du hjælper med at skrive resten af kravene for denne funktion, fordi jeg ikke kan gøre det, og jeg vil ikke risikere, at noget falder mellem to stole, fordi jeg ikke forstår det.”

Det er en balance. Man skal identificere fra begyndelsen, hvad man selv kan gøre. Jeg er blevet spurgt: “Hvorfor gør du det her, når forretningsanalytikeren burde gøre det?” eller “Burde læringsstrategen ikke gøre det?” Mit svar er: “Jo, det kan I sagtens bede teamet om. Men så skal I spørge jer selv, hvor meget af deres budget I vil afsætte til kravarbejdet, og derefter skal alle gennemgå og kontrollere det. Eller hvor sparer I mest budget, og hvor er I mest effektive: ved at gøre det selv eller få en anden til at gøre det?”

Det er en balance, og den ændrer sig. Så længe folk ikke tager det personligt, hvem der ejer hvad, men i stedet spiller hinandens styrker gode, skal det nok fungere. Men der skal være kommunikation om det.

Ben Aston:

Hvis man hører det her og tænker: “Hvad er et forretningskrav egentlig, og hvad er funktionelle krav?” Man arbejder måske i et bureau eller studie, hvor man bare laver design, afleverer det til udviklerne og får det bygget. Du taler om at lave dokumentation. Er det ikke det modsatte af det, vi bør gøre? Burde vi ikke være agile og fleksible?

Hvad er din holdning? Hvad er disse dokumenter, og hvorfor er de vigtige?

Kelly Suter:

Når jeg taler om dokumentation af forretningskrav, kalder jeg det fremover BRD, og funktionel kravspecifikation kalder jeg FRD. BRD’en kan sammenlignes med et introduktionskursus. Det er ofte de overordnede punkter: Vi skal have dette oversat til spansk og mandarin. Vi skal levere ti forskellige kurser. Det skal være live i april. Vi skal kunne understøtte en brugerdatabase på 6.000 personer eller den tilsvarende trafik.

Det kan være indholdet i en BRD. Det er grundlæggende: “Det her er det, vi har talt om indtil videre. Sørg for, at I bevæger jer i den rigtige retning.” Det er en formalitet og et kontrolpunkt, hvor begge parter bekræfter: “Okay, vi er enige.” Der står naturligvis også, at vi vil definere tingene mere detaljeret senere. Hvis noget falder uden for scope eller overskrider budgettet, giver vi besked, omprioriterer og beslutter, hvad der skal med, og hvad der skal flyttes til fase to.

FRD’en er et helt andet kontrolpunkt, og der sker meget mellem BRD og FRD. Hvert punkt og mere til foldes ud i større detalje. Hvis vi skal oversætte til spansk og mandarin, skal vi så bruge en ekstern leverandør? Skal vi skrive kode, så det bliver mere automatiseret? Skal en administrator manuelt indtaste tre forskellige sprog i indholdsstyringssystemet?

Alle disse punkter foldes ud. BRD’en er et kontrolpunkt, hvor man siger: “Vi er på samme side.” Samtidig ved man godt, at FRD’en vil vokse. Man opdager måske, at kunden nu forstår, at oversættelse ligger uden for budgettet, og derfor flyttes det til fase to. Det dokumenterer man i FRD’en og fokuserer derefter på at definere resten.

Den ene udvikler sig altså til den næste, og FRD’en er i praksis en plan eller tegning for udviklingen – eller det bør den være.

Ben Aston:

BRD’en er det, vi definerer i begyndelsen af projektet. Den definerer grundlæggende, hvordan succes ser ud fra et forretningsperspektiv. Hvordan skal projektet skabe succes? Hvilke ting skal vi berøre? Den funktionelle kravspecifikation er derimod stedet, hvor vi definerer, at en bestemt funktion skal fungere på en bestemt måde. Hvis et website skal være tilgængeligt og læsbart for mennesker i Kina, skal det være på mandarin og lokaliseres. Det er her, vi går ned i detaljerne.

Hvordan ser du på det agile? Der er udviklere, som siger: “Vis mig kravene. Jeg kan ikke gøre noget uden krav.” Og når man giver dem kravene, siger de: “Sådan bør vi ikke arbejde. Vi bør være agile, levere en lille del af funktionaliteten og iterere. Vi behøver ikke al den dokumentation.” Hvordan finder du balancen mellem en iterativ tilgang og mere agile arbejdsformer, hvor man begrænser dokumentationen og tester og lærer, samtidig med at du forsøger at definere funktionaliteten så grundigt som muligt?

Kelly Suter:

Man finder balancen ved at have en fælles forståelse fra begyndelsen. Ja, det kan indebære dokumentation, hvor man siger: “Vi leder projektet gennem en agil proces. Det betyder dette. Det har vi brug for fra kunden, og det har vi brug for internt.” Man skal have en solid intern opstart og sige: “Her er det produkt, vi arbejder på.”

Lige nu bygger vi for eksempel software, der knytter point til læring. Man gennemfører kursusmateriale, klarer sig godt eller mindre godt og gør fremskridt. Der er en logik, hvor pointene forbindes med en markedsplads, hvor de kan bruges. Vi ved ikke, hvad vi ikke ved.

Kunden ved, at de vil have produktet, og at de vil have det i januar. De stoler på os, fordi vi har arbejdet sammen om flere projekter tidligere. Vi har ikke tid til at dokumentere alt, selvom det ville glæde mit hjerte, så jeg må blive tryg ved at sige: “Fint. Det her er slutmålet.”

Vi definerer ikke alle mellemtrin på forhånd eller opbygger alle opgaver og deler dem op i sprints. I stedet holder vi ugentlige standupmøder og siger: “Du arbejder med badges, du arbejder med certifikater, du arbejder med ranglisten, og du arbejder med købsoplevelsen.”

Hver anden uge laver vi en udgivelse og præsentation for kunden. Kunden ved, at det, de ser, ikke er færdigpoleret. Det handler om at få funktionaliteten på plads. Der er API’er i bagenden, som håndterer pointene, deres værdi og forbindelserne mellem dem.

Standupmøderne er uvurderlige. Som projektleder kan man dokumentere dem: “Det her viser vi i dag. Vi viser badges i relation til dette kursusmateriale. Det her kan I forvente at se, fordi det er det, vi har lavet i den seneste uge. Og her er de spørgsmål, vi måske har til jer.”

Når man holder standupmødet med kunden og viser arbejdet, kan kunden sige: “Det troede jeg ikke.” Den tillid betyder, at de kan udtrykke deres bekymringer, vi kan svare på dem, og vi kan lægge en plan for den følgende uge. Det svære, men nødvendige, er hele tiden at holde øje med udviklingen.

Man må spørge: “Hvordan går det mellem nu og det færdige produkt? Skal vi måske droppe certifikaterne, fordi vi skal fokusere på noget andet?” Det handler om konstant kommunikation, løbende dokumentation og tillid.

Ben Aston:

En af de ting, der ofte kan sætte et projekt på pause helt fra begyndelsen, er, hvis man venter, indtil alt er defineret. Hvis man siger, at man ikke kan gøre noget, før de funktionelle krav for hele projektet er defineret, tager det meget lang tid.

Jeg kan godt lide idéen om, at de funktionelle krav giver udviklerne en definition af præcis, hvad de skal bygge, kunden klarhed over, hvad de får, og kvalitetssikringen mulighed for at vide, hvad den skal teste imod. Man udvikler kravene undervejs og gør så meget, som er nødvendigt for at holde projektet i bevægelse.

Men det tager selvfølgelig tid at dokumentere alt det. Hvordan gør du konkret? Skriver du en opgave i JIRA, eller hvordan ser arbejdsgangen ud?

Kelly Suter:

Når jeg har en færdig FRD, har alle gennemgået den, og kunden har godkendt den. Jeg præsenterer den for udviklingsteamet. Nogle udviklere vil have kravene udleveret og vide præcis, hvilke opgaver de skal udføre. Andre siger: “Fortæl mig ikke, hvordan jeg skal løse opgaven. Det er ikke den rækkefølge, jeg selv ville bruge.” Man kan komme skævt fra start, hvis man ikke respekterer det.

Jeg spørger derfor: “Vil I helst selv opbygge opgaverne, eller vil I have, at jeg gør det?” Når de har gennemgået FRD’en, er de ofte okay med, at jeg opbygger opgaverne. Jeg laver en opgave for hvert linjepunkt og organiserer historierne efter sidetype. Det kan være en registreringshistorie, en forside eller en produktside. Derefter laver jeg underopgaver for hvert linjepunkt på den pågældende sidetype.

Udviklerne skal altid selv estimere deres tid. Hvis virksomheden giver mulighed for det, bør den person, der skal udvikle funktionen, estimere den. Lad ikke de bedste udviklere estimere alt, hvis en juniorudvikler bagefter skal bygge det.

Fordi udviklerne har læst kravene og kender forventningerne, bør der være en minimal forskel mellem estimatet og dokumentationen. Jeg bruger JIRA fra Atlassian til opgavestyring. Når alt er oprettet i backloggen, får udviklerne det estimeret og prioriteret efter, hvordan de vil gribe opgaverne an. Derefter deler jeg dem op i sprints baseret på arbejdsuger på cirka 30–35 timer, hvis de kun arbejder på dette ene spor.

Hvis man arbejder agilt og ønsker kvalitetssikring for hver opgave, skal kvalitetssikringsressourcen eller projektlederen tilføje en linje i hver billet, der beskriver, hvordan man tester, om opgaven er lykkedes.

Ben Aston:

Jeg vil gerne berøre estimering. Når projekterne bliver mere tekniske, bliver det en større udfordring. I begyndelsen vil kunden gerne vide, hvad projektet koster, men vi kender ikke hele funktionaliteten. Du talte om en agil proces, hvor man arbejder med kunden og måske har en løbende aftale, så man ikke behøver estimere hele projektet på forhånd.

Hvordan håndterer du det i begyndelsen, når du skal give en kunde et estimat på for eksempel 200.000? Baserer du det på forretningskravene? Hvordan laver du et tidligt overslag, før de funktionelle krav er defineret, og hvordan oversætter du senere overslaget til de faktiske funktionelle krav og mere præcise estimater?

Kelly Suter:

Det er et omfattende spørgsmål. Hvis jeg selv kunne bestemme som projektleder, ville jeg sige, at jeg 90–95 % af tiden ikke har mulighed for at bidrage med en reel vurdering af et estimat. Jeg kan måske sige: “Jeg taler med denne kunde, og de har en god idé. Tror du, vi kan nå det i marts?”

Så har jeg naturligvis straks hundrede spørgsmål. Når jeg får mulighed for at lave et overslag, vil jeg først vide, hvad vi tidligere har gjort. Virksomheder har normalt et eller andet specialområde. Folk, der siger, at de er platformuafhængige, kan levere alt og gøre alt, får det svært i salgsarbejdet.

Jeg finder ud af, hvad vi har bygget før, og ser på ligheder i brugerbasens størrelse eller virksomhedens størrelse. Derefter bruger jeg tidligere projekter som sammenligningsgrundlag. Et e-handelsprojekt i Magento kunne eksempelvis tidligere tage seks til otte uger med to udviklere. Det giver ikke et præcist antal timer eller kroner, men det giver et prisniveau at tage udgangspunkt i.

Til salg og forretningsudvikling ville jeg sige: “Vi ved det ikke endnu.” Hvis der ikke er integrationer eller tilpasninger, og løsningen bruges næsten direkte fra standardpakken, kan man sige, hvad den cirka vil koste. Men det er svært at estimere præcist. Derfor er en udviklingsleder eller en teknisk projektleder ofte den person, der kan tale på afdelingens vegne.

Det hjælper at have et enkelt ark med pejlemærker: Hvis det handler om e-handel, et læringsstyringssystem eller noget andet, har man noget at sammenligne med. Men det er et svært spørgsmål.

Ben Aston:

Du taler om analog estimering. Tidligt i et projekt, hvor vi bliver bedt om et overslag, men endnu ikke kender de funktionelle krav, er den bedste metode at spørge en udvikler, hvor lang tid et lignende projekt tog. Der er mange variable i et e-handelswebsite, så man kan kun sige: “Her er tre projekter, der minder om det, I beskriver. Her er den lave ende, her er den høje ende, og jeres projekt ligger måske et sted imellem.”

Man bør undgå at forpligte sig til tallet, før kravene er bedre defineret. Man kan forklare, at en del af afklaringsfasen er at definere kravene, og at man kan estimere mere præcist, når de er på plads.

Kelly Suter:

Jeg laver altid to hurtige øvelser. Den første er trekanten med scope, tidsplan og budget. Ved projektets opstart beder jeg kunden rangere dem fra et til tre efter vigtighed. De siger ofte: “Alle tre,” og så griner vi. Derefter siger jeg: “Men hvis I virkelig skal vælge, hvilken rækkefølge er vigtigst?” Det kan ændre sig undervejs. Når et nyt regnskabsår begynder, er budgettet måske ikke længere det vigtigste. Øvelsen hjælper med at tale om det ukendte.

Den anden øvelse er god, bedre og bedst. Hvis kunden har et bestemt budget, siger jeg: “Jeg vil lige så gerne som jer holde os inden for budgettet. Men hvis en integration dukker op, eller en ekstern leverandør får noget til at ligge uden for scope, kan vi gøre dette, men det koster mere end budgettet. Hvis vi holder budgettet, er dette det, I ikke får. Eller vi kan finde en mellemvej.”

På den måde får kunden mulighed for at træffe den svære beslutning, i stedet for at projektlederen bare siger: “Det kommer ikke til at ske.” Det er de to øvelser, jeg finder mest nyttige, når det gælder tid, scope og budget. Samtidig føler kunden, at de deltager i beslutningen og tager del i forretningsvalget.

Ben Aston:

Det er en god måde at gøre det til et samarbejde på. Kunder kan nogle gange presse os til at forpligte os på et budget, hvilket er særligt vanskeligt ved en fast pris og ved tekniske projekter med nye integrationer eller platforme. Jeg kan godt lide din tilgang med at hjælpe kunden med at forstå, at mere funktionalitet kræver mere arbejde.

Hvis nogen lytter og tænker: “Det lyder fantastisk. Hvis jeg kan definere sammen med udviklerne, hvad de skal bygge, kan det være, at de ikke har prøvet det før. Måske har de kun fået wireframes og designs og derefter gået direkte i gang med udviklingen.” Hvad er det første skridt for en person, der vil begynde at skrive krav?

Kelly Suter:

Hvis man er digital projektleder for første gang, ved man mere, end man tror. Man lever allerede i den digitale tidsalder og er omgivet af smartphones, tablets og teknologi. Man har allerede været udsat for digital adfærd, lært vaner og klaret sig i den tekniske tidsalder.

I stedet for straks at google en skabelon til teknisk dokumentation og forsøge at udfylde hullerne, skal man træde et skridt tilbage og spørge: “Hvad laver vi for denne kunde?” Hvis vi bygger en registreringsside til en begivenhed, har den en forside og en webformular. Hvad skal vi definere? Find hvert element på siden og spørg: “Hvad gør det på mobil og på computer?” Begynd der.

Forestil dig, at du skal forklare det for nogens bedstemor, som stadig har sin gamle Nokia-telefon. Forklar det højt for dig selv. Gå derefter til udvikleren og spørg: “Har jeg forstået det rigtigt?” Udvikleren vil sætte pris på, at du stiller spørgsmålene og forsøger at definere noget på en måde, der også gør det muligt for udvikleren at lykkes.

Når du begynder at arbejde med kravdokumentation, skal du dele det op i elementer af det, du bygger, og forklare hvert element. Hvis du ser på din første kravspecifikation, lyder den måske mere samtaleagtig, end den burde, og du har måske været inkonsekvent med den samme funktion på forskellige sider. Det er okay. Det kommer til at udvikle sig.

Det er et digitalt projekt for kunden, og det er ikke noget, de nødvendigvis laver hele tiden. Du repræsenterer din virksomhed, gruppe eller team som ekspert. Gå processen igennem sammen med kunden, og husk, at du ved mere, end du tror, fordi vi alle lever i den digitale verden.

Ben Aston:

Det er virkelig nyttigt. Krav handler i høj grad om at stille spørgsmål og finde svar. Når man begynder at definere krav, kan man tænke: “Er det her et dumt spørgsmål? Er det ikke åbenlyst?” Men intet er nødvendigvis åbenlyst. Man kan begynde med at spørge sig selv, hvad man skulle forklare sin mor eller bedstemor.

Man skal også huske, at kravene er et kommunikationsværktøj. Dokumentationen gør det muligt for alle at være enige om, hvad der faktisk skal udføres. Når der er klarhed over leverancen, spilder man mindre tid på forventningsafstemning, og alle ved, hvad der skal leveres. Det tager tid at skabe dokumentationen, men den betaler sig mange gange igen, fordi man undgår omarbejde og skuffede kunder, der får noget andet end det, de forventede.

Kelly, tusind tak fordi du ville være med. Det har været fantastisk at have dig med.

Kelly Suter:

Tak, det sætter jeg pris på.

Ben Aston:

Som en af vores DPM-eksperter medvirker Kelly også i vores kursus Mestring af digital projektledelse. Hvis du ikke ved, hvad jeg taler om, men ved, at du har brug for uddannelse i projektledelse, så kig på det. Vi har et intensivt syvugerskursus med interaktive videolektioner, opgaver, gruppediskussioner og webinarer. Gå til dpmschool.com og tilmeld dig. Kurset starter i februar.

Hvis du vil bidrage til samtalen om krav og om, hvordan vi arbejder med dem, kan du gå til ressourcesektionen på thedigitalprojectmanager.com og deltage i vores Slack-team, hvor der foregår mange interessante samtaler. Du kan også kommentere på indlægget. Men indtil næste gang: Tak fordi du lyttede.