Pessimister? - dem skyder vi da! - Risikostyring del 1

God artikel. Glæder mig til del 2.

En klassisk prince2 projektleder som ikke har erfaring med software udvikling projekter, hvor der deltager lidt ældre personer som typisk har lavet det samme i de sidste 20 år, går på med krum hals. Vi bliver indkaldt til møder, hvor vi skal tegne projektet som et dyr og udføre andre team building opgaver. Den slags seancer bliver (af de lidt ældre personer) takseret til holdningen om, at det er pop-smart, ikke en skid interessant, vil ikke deltage og dets lige. Det skaber reelt en kile imellem projektlederen og en del projektdeltagere, idet grundlaget for respekt overfor ledelsen ikke længere er tilstede og som resulterer i bagtaleri, nedprioritering af opgaver, lav arbejdsinsats, ... Tilsidst bliver en-to (afhængig af hvordan man tæller) af de ældre personer fyret for negativitet, hvorefter projektet kommer i mål. Hvem er den skyldige? (dansk kultur siger jo, at vi skal udpege en skyldig) Projektlederen som ikke har erfaring med "den lidt ældre, jeg har set alt" persontypen og som derfor burde have undladt at bruge de bløde team building events? Projektdeltagerne som latterliggører projektlederen og som modarbejder implementationsflowet? Humlen er som regel nok et sted midt imellem.

De fleste glemmer, at en af de nødvendige elementer i succes er kommunikation, og at den foregår på modtagerens side. Medarbejderen som kritisk over for elementer i en plan har måske en masse erfaring, som gør hans input meget værdifuld at få frem. Hvis han tager på et åbent møde denne kritik kan projektlederen nemt gå i baglås fordi han ikke vil tabe ansigt - måske var det bedre at tage det en-til-en? Hvis han udtrykker sin bekymring med en negativ, måske ironisk tone, så kan det igen lede til at projektlederen går i baglås. Hvis målet er, at vise at projektdeltageren er klog/erfaren/kræver respekt, så er det en nem måde at vinde på. Hvis målet er, at få den bedste og mest realistiske plan så tidlig som muligt så mød projektlederen som ligemand og mere privat. Omvendt, en projektleder som ikke kan finde ud af teknikker som "lad os tage den efter mødet", "godt input - jeg kikker lige det efter med det aspekt", .. og i stedet lukker af for medarbejdere som giver værdifuldt input, ja de har endnu noget at lære...

Tak for et super godt oplæg og ikke mindst Jakub Nielsens indlæg.

Det er jo kommunikationen der er det essentielle her - evnen til at tilpasse sine budskaber og ikke mindst evnen til at kunne lytte.

Det er jo altid et budskab bag, når man vil kommunikere, uanset måde/medie og den opgave projektlederen havde, var i mit perspektiv bl.a. at "sælge" opgaven. Men hvis ikke han er i stand til at kapere "kritiske" kommentarer, mener jeg ikke han er færdig med at lære...
Projektlederen skal da lære at håndtere sådanne situationer, da han med garanti vil stå i lignende situationer fremover.
Når det er sagt, har jeg nu også arbejdet med kollegaer, der var notorisk negative/kritiske overfor alt og det kan altså være en hemsko af de større, så man skal nøje sondre imellem negativitet/kritisisme.

Håber på en god diskussion med spændende holdninger/tilkendegivelser....

Særligt ved it-projekter, hvor mange mennesker over længere tid skal producere forskellige dele til et samlet produkt, er professionelt samarbejde krævet. Det kedelige er at samarbejde, ikke bliver undervist på universiteterne inden for IT, ifølge hvad jeg kan konstatere (Skulle Syddansk Universitet påstå noget andet, tager jeg gerne samtalen). Jeg taler ikke om metoder som Scrum, Vandfald m.v., men om s-a-m-a-r-b-e-j-d-e. Samarbejde består i sin kerne ikke i at den ene skruer det ene sted, mens den anden skruer det andet sted på samme produkt, eller at de gør det i en bestemt takt, men at de to har en positiv kommunikation om at konstruere produktet - meget fladt udtrykt.
Andre aspekter af samarbejde er respekt, at kunne se ens egne mangler i øjnene og bidrage med hvad man er stærk til - altså at give slip på stolthedder, 'storhedsvandvid', falsk forudfattethed - det at kunne gøre det på andres måde, stå tilbage med sine forslag og tage imod andres, og arbejde på dem med samme begejstring som var det ens egne. Angsten for at tabe ansigt eller se ud som den dumme er også ofte kernen til at gøre noget helt forkert. Selv unge mennesker har svært ved at træde ud af deres 'komfortzone'. - Og så er der en masse andre aspekter end lige de her nævnte. Samarbejde mellem mennesker er faktisk et helt studie i sig selv.
Og: Hvis ikke universiteterne løfter opgaven, bliver problemet bare skubbet ud på arbejdsmarkedet. Jeg tvivler på om de danske virksomheder har resurserne til at undervise de nye medarbejder fagligt i samarbejde - altså bredt; ikke bare indarbejde folk. Virksomhederne har jo allerede udfordringen at blive bevidst om hvordan deres egen virksomhedskultur indvirker på deres produktivitet (Der findes ikke bare grufulde historier her, men også grufuldt mange af dem og grufuldt mange nye). Samarbejde kan ikke være en præ-universitetslære, da andre faggrupper ikke har samme udprægede behov for samarbejdsevner. Ikke mindst er disse kvalifikationer vigtige for at skabe/understøtte større virksomhedsenheder i Danmark inden for IT. Hvis Danmark/virksomhederne altså har en forestilling om at eksportere IT.

Enig i, at det handler om kommunikation, respekt og samarbejde. Det handler vel også om motiv. Den erfarne projektdeltager kan vælge at byde ind med erfaringer for at påpege projektlederens naive tilgang eller for at berige projektet. Omvendt kan projektlederen vælge at opfatte påpegede faldgrubber fra erfarne projektdeltagere som negative og arrogante forsøg på at pille projektlederen ned eller som konstruktivt input til projektet. Med andre ord, klassikeren: gå altid efter bolden – ikke manden.

Jeg er ganske overbevist om at denne problemstilling eksisterer i de fleste brancher.

Pessimist er hvad en optimist kalder en realist.

Jeg er meget enig i blog indlæget, fordi det er også min erfaring at 'pessimisme' i sådanne situationer ofte (naturligvis ikke eksklusivt) bygger på erfaring fra tilsvarende situationer/projekter og et ønske om at forsøge at begrænse et flyvsk omfang, mere end meget andet.

@Bent
Tak for et interessant indlæg, glæder mig til del 2.
Ja, det må være irriterende sådan at få kritiske spørgsmål til sin tidsplan, særligt hvis man tror fast på den. Men så har man jo heller ikke fattet at en plan bare er en plan, lige som et estimat bare er et estimat. Det lyder i hvert fald ikke særlig agilt.
Jeg oplever sjældent det problem internt på agile teams. Jeg oplever det ofte mellem projektteamet og 'forretningen'. Det er hvad Craig Larman intelligent har kaldt "the contract negotiation game"

@Jakub
Som jeg ser det, vil det oftest være projektlederens opgave at eskalere et sådan problem, da hun/han oftest ikke har bemyndigelse til at gøre noget ved det (ikke har linieansvaret for projektteamet). Så det vil være "ledelsens" ansvar at gøre noget ved problemet; det ligger ikke mellem team og projektleder som du beskriver. Og det ser jo også ud til at ledelsen valgte at gøre noget ved problemet; måske lidt drastisk ved at skille sig af med et par medarbejdere. Og siden at projektet kom i mål, kan man jo argumentere at de valgte rigtigt.
Og det er også ledelsens ansvar når de sender en projektleder ind i et team. Og hvis pågældende ikke har de rette kvalifikationer, så er det også ledelsens ansvar.

@Frank, det kan være du ikke har oplevet problemet internt i et team, men det er jo alene et spørgsmål om, hvem der mærker konsekvensen. Der er ikke noget "bare" i en plan eller et estimat. Der tages beslutninger ud fra det - budget fordeles. Forventninger opbygges. Det skal tages aldeles alvorligt.

Derfor skal indvendiger også høres, forudsætninger tydeliggøres.

At forudsætninger kan svigte og planer og estimater derfor have behov for ændringer er noget helt andet. Det er rigtig mange projekter der gennem tiden har fået at vide, at det var ærgeligt... nu har I fået den sum penge og den tid - få det til at virke.

Den slags har man ikke lyst til at opleve alt for mange gange - og tror da slet ikke en udvikler eller andre bærere vil synes det er fedt. For det første - og eneste offer - når tid og økonomi er låst... er kvaliteten.

Der er altså ikke noget "bare" over planer og estimater

@Martin IP
Jo, der er præcis noget "bare" om planer og estimater. De er nemlig "bare" planer til noget ændrer sig - og "bare" estimater, ikke garantier.

og hvis man ikke forstår det, så vil man løbe ind i alle mulige problemer som du og andre har beskrevet. Men det er ikke hverken planernes eller estimaternes skyld.

og selvfølgelig kan og skal man tage beslutninger på baggrund af foreløbige planer og estimater - men man skal bare ikke tro fast på at de holder. Man skal forstå at de "bare" er planer og estimater.

at der er taget mange gale beslutninger, og at der har været mange katastrofale konsekvenser for projekter og mennesker er heller ikke planer eller estimaters skyld. Jeg ville fx ikke basere mit produkt eller firmas overlevelse på en plan over hvad der 'skal' ske ½-1 år ude i fremtiden

alt det her er noget den agile udvikling har lært os over de sidste 10+ år. Og har givet os redskaber til at imødegå. Fx at vi arbejder i iterationer og leverer potentielt deployable kode hver iteration

og du har IKKE ret i at det eneste mulige offer er kvaliteten når tid og økonomi er låst. Selv den gamle 'project iron triangle' (scope, schedule, cost) vil svare at så må scope ændre sig. Og ja, det er der nogen der ikke forstår. Man må så bare håbe at de ikke tager beslutninger i nogen virksomhed

Du kan forøvrigt læse om den tilsvarende 'agile trekant' i Jim Highsmiths meget indsigtsfulde whitepaper: http://www.thoughtworks.com/sites/www.thoughtworks.com/files/files/adapt...

Under en diskussion omkring et måske kommende projekt, havde vi inviteret en meget skeptisk kollega, efter en kort introduktion af problemområdet, sagde han noget i retningen af: "det får i aldrig til at virke, de løsninger i laver er for langsomme til den slags systemer og data ændrer sig alt for ofte og jeres release-cycle er for lang" hvorefter han forlod mødet.

Bom, han havde jo ret! Det system vi skulle lave var meget anderledes i forhold til hvad vi ellers gør og laver. Systemet var meget afhængigt af at vise store mængder af data, hastighed var essentielt og data definitionen blev ændret fra tid til anden - det skulle være muligt at lave ændringer i systemet lige så hurtigt (så data og system fulgtes ad).

Havde vores skeptiske kollega ikke sagt noget til os i den situation, havde vi måske lavet løsningen som vi plejer. Men vi blev trodsige og blev enige om at vi ville lave en løsning, der ville virke - basta! Efter en snak, et par tegninger på en tavle og et par nætters søvn vente vi tilbage med en løsning, der kunne løse problemet på en elegant måde og som faktisk også kunne bruges til mange andre systemer.

Måske har man lettere ved at være skeptisk overfor andres arbejde end overfor det arbejde vi selv sidder med? Jeg er relativt skeptisk selv og elsker at stille spørgsmålet: "sidste gang vi gjorde X fejlede vi, hvad er ændret siden da, der overbeviser os om at vi ikke fejler denne gang?" :-) Derfra kan man tage en "5 Whys" og så ender man tit med at få en meget interessant samtale.

Agilt eller ej, lad være med at tro at udviklingsmetoder løser noget i sig selv.

Det handler meget mere om mennesker - har man de rette folk så kan man principielt køre "kaos" og stadig have success med det.
Har man de forkerte folk, så kan man trække nok så mange processer og metodikker ned over hovedet på dem og det vil stadig fejle.

YAGNI eller "Enough is enough" eller den klassiske: "Solve today's problems today and trust that you can solve tomorrow's problems tomorrow".

Det kan faktisk godt lade sig gøre at lade datamodellen udvikle sig undervejs, det hjalp mig meget at læse denne case link.

Jeg synes det gennemsyrer alt hvad vi laver. Der mange løsninger af en user story, mange udviklere vil gerne lave gold plating, men vi stiller altid spørgsmålet: "hvad er den mest simple løsning på problemet?" Det skal løses ordentligt og koden skal være i god kvalitet, men vi skal ikke over-designe løsningen med en masse gejl vi ikke får brug for alligevel.

Nogle gange siger vi noget i retningen af: "nu laver vi det sådan her, så kan vi altid lave det mere avanceret senere", men jeg kan ikke huske hvornår vi lavede noget om eller mere avanceret.

Jeg kommer sådan til at tænke på bogen Rework, hvor de siger: "planning is guessing", når man vender sig til det bliver alle aspekter af livet nemmere. :)