Det Uregerlige Projekt

Der er fornylig udkommet en usædvanlig bog om projekter. Den minder ikke om nogen af de andre bøger om emnet jeg har læst. I stedet for at fokusere på projektlederen og hendes værktøjer er det selve projektet der er i centrum. Vi må forstå projektet, før vi kan tale om at styre det. Forfatteren Sven Bertelsen lægger grunden til en ny forståelse af projekters natur, som ifølge ham er forudsætningen for at vi kan få flere vellykkede projekter.

Sven har i mange år været en vedholdende inspirator og igangsætter under mantraet “bedre projekter”. Hans udgangspunkt er i byggeriet, men han har også hjulpet skibsværfter med at forbedre bundlinien og har været en inspirator for mange i softwarebranchen. Han har i mange år deltaget i bevægelsen “Lean Construction”, som har et stort tankefællesskab med lean og agil softwareudvikling.

Det Uregerlige Projekt er titlen på bogen, som er en teoretisk funderet praktikers opsummering af, hvad vi ved om projekter og ikke mindst hvor meget vi stadig mangler at vide. Den har stor relevans også for os, der ikke arbejder med byggeri. Et fag med en flere tusinde år gammel tradition, kan sagtens inspirere softwareudvikling, hvor vi med vores mindre end 100 år på bagen, dårligt er tørre bag ørerne endnu.

Bogen starter med at konstatere, at der slet ikke er sammenhæng mellem den økonomiske betydning af projektproduktion og den indsats der gøres for at forstå projekter og forbedre deres produktivitet og kvalitet. Med et slag på tasken anslår Sven at projektproduktionen står for mere end halvdelen af Danmarks BNP. Alligevel er evnen og viljen til at lære og blive dygtigere forsvindende lille.

I software verdenen kan vi jo bare kigge udover landskabet af de sidste årtiers kuldsejlede IT-projekter, med SKAT’s IT som det absolutte flagskib. Gælden på 65 milliarder, der ikke bliver inddrevet og hullet på 300 mill i kassen hver måned, og næsten som en biting er der prisen på 600 millioner for udvikling af EFI, det nu skrottede system til inddrivelse af restancer, og Accentures regning på 20-90 millioner for at undersøge hvorfor det gik galt. Og så har vi slet ikke nævnt svindlen med udbytteskat, som har kostet i nærheden af 10 miliarder kroner, og som man må antage, kunne have været afværget med nogle effektive IT-systemer. Til sammenligning koster et supersygehus mellem 4 og 6 milliarder!

Sven konstaterer at vores forståelse af projekter er forkert og mangelfuld, og at det forhold giver anledning til store problemer. Planer holder ikke fordi, de ikke kan holde. Punktum. Årsagen er, at man aldrig kan tage højde for alt det, der vil gå galt. Når man ser tilbage på et havareret eller forsinket projekt, og det er vel omkring 90% af alle projekter, vil man næsten altid kunne pege på, at der indtraf en række særdeles uheldige ting, som man ikke kunne have forudset, og som var årsagen til problemerne. Standard reaktionen er at trække på skuldrene og konstatere, at der jo ikke var noget galt med planen, da det, der gik galt jo netop var uforudsigeligt.

En af bogens vigtige pointer er, at der altid vil indtræffe noget usandsynligt, som vi ikke kan tage højde for, og som vi aldrig kan planlægge os ud af. Grunden er, at der er utroligt mange usandsynlige ting der kan ske, så selvom sandsynligheden for den enkelte hændelse er meget lille, er sandsynligheden for at en eller flere af dem indtræffer til gengæld meget høj.

Mange har oplevet at rende ind i en kollega eller en nabo på en ferierejse? Dybt forundret spørger man sig selv, hvordan det dog kan ske, at man møder et kendt ansigt så langt hjemmefra. Og havde man inden afrejsen proklameret “mon ikke jeg løber ind i naboen fra nummer 9 på min næste ferie”, ville sandsynligheden ganske rigtigt være mikroskopisk lille, men når det bare er en af mange andre usandsynlige ting, der kunne være sket, er det slet ikke så langt ude.

Når vi så har konstateret, at planer ikke kan holde, hvad skal vi så gøre? Skal vi helt opgive at planlægge og forfølge mål? Det skal vi naturligvis ikke. Vi har stadig brug for planer og ikke mindst mål for, hvor projektet skal føre os hen.

For bedre at forstå vore muligheder for at planlægge, laver bogen en sammenligning mellem projekter og strømmende vand. Vand kan enten være i roligt flow eller i en turbulent fase, hvor det er uforudsigeligt. Det vi ønsker med projekter er, at de holder sig i flow og gerne tæt på den turbulente fase, da det er her, der bliver flyttet de største vandmængder, hvilket svarer til den største produktivitet.

Uforudsete begivenheder kan få et strømmende projekt til at overgå til den turbulente fase. Hvor kaos indtræder og al forudsigelighed forsvinder.

De uforudsete begivenheder kan vi ikke undgå, men vi kan undgå at de får projektet til at blive turbulent, eller hvis overgangen til turbulens er indtrådt, kan vi med målrettet arbejde bringe det tilbage til flow igen. Opskriften er at gøre projektet i stand til at reagere på de uforudsigelige begivenheder hurtigt og effektivt. Derved kommer de aldrig til at skubbe projektet over kanten til turbulens, eller kaos, mere end bare kortvarigt.

Et af midlerne er, at man vælger planlægningshorisonter af en varighed, som sikrer at man kan reagere på ændrede omstændigheder hurtigt. Et andet vigtigt element er at skubbe beslutningskompetence ned til de mennesker, der udfører arbejdet, fordi de, i de fleste tilfælde, kan træffe bedre og hurtigere beslutninger end dem, der er langt fra problemerne

Projektstyring ændrer sig i denne tænkning fra at være styring til at være pleje og pasning af det rolige flow. “Hvis forudsætningerne er tilstede bygger huset sig selv”, siger Sven et sted i bogen. I en mere praktisk model har Sven og Lean Construction defineret 7 strømme, som alle skal plejes for at sikre at at projekt har den nødvendige fremdrift. De syv strømme er: Plads, information, foregående arbejder, mandskab, materiel, materialer og ydre omstændigheder. I softwareverdenen ser disse strømme anderledes ud, men de fleste kan med lidt også genfindes i softwareprojekter. Tænk: afklaringer, afgængigheder til andre, kompetencer, arkitektur der understøtter det man skal udvikle, for bare at nævne nogle stykker.

På samme måde som vi har Scrum, XP og SAFe i den agile verden har Lean Construction systemet Last Planner, der bl.a arbejder med 3 planlægningshorisonter og klare mål for produktivitet, problemløsning og uddelegering af planlægningsarbejdet.

Bogen er tankevækkende og underholdende læsning og når læser bogen ud fra en software baggrund, giver den stof til eftertanke og handling på en række områder.

Ved at forstå projekter som kaotiske og ved at angribe dem på deres egne betingelser, vil meget være nået. Særligt i det, vi traditionelt betegner som store vandfaldsprojekter, som lider af alle de samme udfordringer og problemer, som et stort byggeprojekt lider under.

Men også i den agile verden kan vi blive inspirerede. I byggeri og andre “hårde” projekter, er der nogle tydelige begrænsninger, som man skal optimere indenfor. Tyngdekraften gør at man nødvendigvis må starte med fundamentet og ikke kan bygge 3. sal som det første. Alle de forskellige fag, der skal arbejde sammen og komme efter hinanden, kræver en planlægning der i høj grad tager højde for afhængigheder og varierende gennemløbstid. Det er på mange måder sammenligneligt med det vi oplevever i store projekter, hvor specialiserede teams laver komponenter til andre teams og hvor der er mange forskellige platforme der skal spille sammen - Mainframe, Web og Mobil for eksempel. Ligeledes er der stærke begrænsninger i projekter, der involverer udvikling af “devices” hvori der indgår både software, mekanik og elektronik.

Til gengæld kan Sven og dermed byggeriet også lære noget af agil softwareudvikling, hvor vi er nået til at forstå, at vi i stedet for projekter, hellere skal tale om produkter, som har ikke har en hård afslutning, men mange releases og er bemandet med faste teams der har et produktionsapparat til rådighed, der er bygget og optimeret gennem længere tid.

Udvikling af T- formede projektdeltagere er også et vigtigt element i god agil udvikling. Vi gør meget ud af at skabe multifunktionelle teams, hvor man udover at have et speciale også kan række ind over andre arbejdsprocesser. Det virker som om de mere fysisk funderede brancher, særligt byggebranchen, hænger fast i nogle mere konservative traditioner, hvor det stadig kun er tømreren, der kan slå et søm i og hvor den eneste der kan skrue rør sammen er smeden. Med vore dages teknologi og bløde processer som supervision og sidemandsoplæring, må det være muligt at bløde op på de hårde faggrænser. Det har haft en kollosal effekt i softwareudvikling på alle de flaskehalse, der står i vejen for det frit strømmende projekt.

Endelig er vi blevet dygtigere til at gøre ændringer billige og derved flytte læring og eksperimenter ud i selv programmeringen. Det vil i byggeriet svare til at flere beslutninger tages på byggepladsen, måske i samarbejde med bygherrer og brugere? Det ville i dag nok være utænkeligt, med den meget hierarkisk opdelte byggeproces og med arkitekters og ingeniørers status, der kan sammenlignes med urørlige hospitalsoverlægers.

Softwareudvikling har netop flyttet sig voldsomt ved at lave produkter, der hele tiden ændres og forbedres. Vi har endnu tilgode at se det byggeri der løbende forbedres og opgraderes og ikke bare bygges og rives ned efter 20-30 år eller måske i bedste fald renoveres?

Bent er partner i konsulenthuset BestBrains og interesseret i alt der bidrager til at gøre softwareudvikling mere produktiv og succesrig. Han er en svoren og kritisk tilhænger af agile og lean metoder, dog uden nogen form for religiøse overtoner. Han blogger om agil udvikling.

Kommentarer (2)

Bent Jensen Blogger

Det er snart nogle år siden jeg læste den, men den gjorde indtryk på mig den gang. Særligt eksemplerne på projekter, hvor man moser på med skyklapper, uden flot ignorerer alle de røde lygter der lyser, og den næsten tvangsmæssige optimisme, man kan finde i mange projekter, og som bl.a. har til resultat, at man gør folk der påpeger problemer og risici til negative "troublemakers". Det mønster er jeg stødt på en del gange.

Log ind eller opret en konto for at skrive kommentarer