IT-projekter er pr. definition komplekse, og det er være IT-projektleder (PL) er en mangefacetteret og svær rolle at udfylde godt. Du leder teams, styrer budgetter, kontrakter, planer og de risici, som måske rammer dig. Du skal gøre dine chefer og interessenter tilfredse, og du styrer måske underleverandører.

For at strukturere disse forskelligartede opgaver har de fleste organisationer implementeret en projektmetode. Mange inspireret af PMI, PRINCE2 eller IPMA m.fl. Men hvorfor ser vi så stadig så mange projekter, der fejler?

Gennem de sidste 10 år har PMI lavet en årlig undersøgelse og udgivet resultaterne i en rapport, “Pulse of the Profession”. Rapporten har gennem årene vist, at kun ca. halvdelen af de projekter, vi starter, gennemføres inden for den afsatte tid og budget. Desværre viser den seneste rapport fra februar 2016 en nedslående tendens. Flere projekter fejler i 2015 sammenlignet med 2014. Se nedenfor:

Agilitet har ført til så meget Scrum, but…

De tunge procesbaserede projektmetoder har projektlederen i centrum og fokuserer mere på at levere alle kravene i en kravspecifikation end den kvalitet og værdi, som reelt efterspørges. Der er implicit sat lighedstegn mellem kravspecifikationen og den ønskede kvalitet/værdi, hvilket bestemt ikke altid er tilfældet.

Da Scrum dukkede op i 1990erne, svingede pendulet i den modsatte retning. Der kom større focus på teamet, og projektlederen blev taget helt ud af projektligningen. I det mindste i teorien. Scrum arbejder med et defineret sæt roller, møder og artefakter, og introducerede et helt nyt ordforråd.

Selvom undersøgelser viser, at en agil projekttilgang giver større projektsucces, har Scrum ikke været løsningen på alle vores projektproblemer. Der er nemlig en række faktorer, der afgør om man får succes eller fiasko på sine Scrum-projekter:

• Organisationens modenhed og forståelse af agile sammenhænge
• Team-modenhed og -kompetencer
• Hvorvidt team-medlemmer er allokeret til flere/mange projekter
• Effektive product ownere, der forstår rollen
• Accept af transparens og visualisering

Virkeligheden viser, at forudsætningerne for god Scrum kun sjældent er til stede. Agile teams skal fungere i ikke-agile organisationer. Projekt-teams forstår ikke Scrums DNA og hvad det kræver af teamet. Product Owner rollen bliver ofte ikke udfyldt effektivt, og det er ikke alle, der er begejstrede for transparens. Nogle føler sig intimiderede af, at alle ved, hvad alle andre laver og at åbent diskutere produktivitet og fremdrift.

Scrum er heller ikke nemt at få til at fungere i en stærk ”control-and-command” kultur, ligesom det er en stor udfordring at skalere Scrum til program- og porteføljeniveau. Hvordan tackler vi risici, afhængigheder, snitflader m.v. mellem flere Scrum teams, der arbejder på ét produkt? Scrum virker fint på mindre software-projekter, men knap så godt på program- eller porteføljeniveau.

For at gøre en lang historie kort: Hverken de traditionelle metoder eller Scrum har givet os de projektresultater, som vi øsker. Begge kan løse nogle af vores projektproblemer, men ikke dem alle.

Sådan gør Kanban livet som projektleder lettere

Da jeg i sin tid faldt over Kanban, gik det op for mig, at det måske var den løsning, jeg ledte efter. Bl.a. fordi Kanban respekterer de roller, titler, hierarkier m.v., som findes i en given organisation, og så starter optimeringsrejsen fra dette udgangspunkt. Kanban er lige så meget et mindset som en metode.

At gå i detaljer med Kanban-metoden bliver for omfattende. Men én ting der giver stor mening fra et projektlederperspektiv er, at man arbejder altid med de vigtigste aktiviter først, så hurtigt man kan. Denne adfærd fremmes i kraft af de seks Kanban-praksisser:

1. Visualisér aktiviteterne
2. Begræns igangværende arbejde
3. Styr og optimér flow
4. Lav eksplicitte regler
5. Implementér iterativ feedback
6. Gå efter forbedringer i fællesskab, og vha. ’eksperimeter’

Kanban har visse ligheder med Scrum. F.eks. visualisering og iterativ feedback, men tilgangen er helt forskellig. Men Kanban kan du håndtere forskellige typer af arbejde på én tavle, tavlen er aldrig tom, og du fokuserer på flow. D.v.s. at gøre dine aktiviteter færdige. Mantraet er: “Stop starting – start finishing”.

Dette er virkelig tiltrængt. Det forhindrer nemlig projektaktiviteter i at være 90, 95, 98% færdige i evigheder. Men det bedste af det hele er, at du slipper for at lave detaljerede projektplaner, aktivitetslister, Excel-ark m.v.

Kanban viser og måler alle arbejdstyper

Jeg har prøvet, men det har været umuligt at planlægge mit projektlederarbejde i sprints, men med Kanban kunne jeg synliggøre og måle alle mulige forskellige aktiviteter. F.eks.:

• Tekniske aktiviteter
• Gentagne PL-aktiviteter (F.eks. møder, status- og risikorapportering)
• Opgaver med deadlines
• Underleverandørarbejde
• Uplanlagte aktiviteter

Mens det giver mening at begrænse igangværende arbejde på de aktiviteter, vi selv kontrollerer, så gør det ikke på underleverandørarbejde. Jeg visualiserer alligevel underleverandøraktiviteter og deadlines og følger op på disse. På den måde får du et holistisk overblik over dit projekt på din Kanban-tavle. Det giver også værdi at visualisere og måle aktiviteter, som tidligere var usynlige. F.eks. uplanlagt arbejde. Jeg måler, hvor meget tid, der bruges på aktiviteter, der kommer ”ind fra venstre” og de tilhørende omkostninger.

Med Kanban kan du faktisk organisere dit arbejde i alle slags organisationer, hvis ellers du kan få lov. Det eneste du skal bruge og gøre er følgende:

1. En stor tavle, farvede PostIts og magneter
2. Afstem forveningerne med din styregruppe, (hvis du har en).
3. Forklar:
   1. Hvordan en simplere projektrapportering stadig holder dem i kontrol,
   2. Hvordan simple metrikker viser tendenser, uønsket varians og fremdrift
   3. Hvordan visualisering altid viser den virkelige projektstatus
4. Aftal med dit team, hvordan I vil arbejde med Kanban (nej, Kanban er ikke kun en stor aktivitetstavle)
5. Beslut jer til at følge princippet: “Stop starting – start finishing”
6. Vis forudsigelighed og stabilitet (som kommer automatisk, når i har udført ovenstående 5 punkter)

Løser Kanban så alle dine projektudfordringer?

Selvfølgelig ikke. Men svaret på dårlige projektresultater har hidtil være at tilføje flere kontrolmekanismer, bureaukrati, processer og kompleksitet til projektmetoden. Det har kun gjort den vanskelligere at bruge som projektleder og samtidig gjort det vanskelligere for resten af organisationen, at forstå deres rolle i projektsystemet.

Der vil altid være beslutninger, dilemmaer og kompleksitet i IT-projekter, som ingen metode kan fikse. Men Kanban har bestemt gjort mit liv som projektleder nemmere, og som den vigtigste bonus har resultatet været hurtigere projekter og højere succesrater. Det er da værd at tage med!