Derfor skal du være knivskarp, når roller og ansvar skal fordeles på dit projekt

I alle projektmetoder sker en tydelig fordeling af roller og ansvar. I Scrum er rollerne som Scrum Master, Product Owner og Teamet og de tilhørende ansvarsområder klart beskrevet. I Kanban styres flow i arbejdet ved at balancere udbud og efterspørgsel og med en rollefordeling baseret på, hvordan den enkelte organisation arbejder. Man bruger gule lapper og noterer, hvem der laver hvad.

I PMI, IPMA og PRINCE2 er roller og ansvar for styregruppe, projektleder og team også klart beskrevet, og interessentstyring og kommunikation er i fokus. (Husk lige, at dine projektressourcer også er interessenter). Processerne er klart defineret med input og output til hvert procestrin.

Hvorfor går det så alligevel galt?

Det går galt, fordi mennesker ikke kan sættes på formel!

Forestil dig, at en projektleder kommer og fortæller, at der er brug for dig på et projekt. Du kan noget, som de har brug for om 3 måneder. Du synes, at det lyder fornuftigt, og foreslår, at projektlederen aftaler nærmere med din chef. Derefter hører du intet, men 5 minutter i 3 måneder er projektlederen tilbage, og spørger, om du snart er færdig. ”Med hvad” siger du. Du har nemlig glemt alt om den leverance, som projektlederen for 100 år siden fortalte dig om, og derefter klappede af med din chef, men ikke lige fik fulgt op på.

Dette er sat lidt på spidsen, men det sker igen, og igen, at man antager, at når man én gang har talt om tingene, eller sendt et mail med en deadline, så kommer leverancen præcis til tiden. Man glemmer, at det projekt, der er vigtigst i verden for mig, ikke betyder noget for kollegerne. For dem er projekter typisk en sten i skoen, fordi de altid kommer oven i de opgaver, de egentlig er ansat til at lave.

Antagelser er roden til alt ondt! Glem straks:

  1. Jeg antog, at…
  2. Jeg følte, at…
  3. Jeg forestillede mig, at…

Lav tydelige aftaler, kommunikér klart og følg op. Ikke kun én gang, for folk glemmer eller udskyder projektopgaven, eller håber, at den går væk. Ikke fordi de vil genere dig, men fordi de har travlt med alt muligt andet end dit projekt.

Giver ledelsen da ikke plads til deltagelse på projekter for alle, der har projektarbejde?

Svaret er et rungende NEJ! I mine +20 års arbejde med IT-projekter har jeg aldrig set nogen organisere sig, så der er plads til projektdeltagelse i organisationen.

Det betyder, at når man skal bruge en medarbejder på sit projekt, så må man kæmpe som besat, fordi når denne trækkes ud fra sit daglige arbejde, så er der noget der ligger stille, bliver forsinket eller måske endda falder på gulvet. Men får man ikke medarbejderen til rådighed, kan man ikke komme videre med sit projekt. Altså pest eller kolera.

Mens man diskuterer ressourcesituationen, forsinker man projektet, og forsinkede projekter belaster projektbudgetterne. Sådan er det bare.

Dette kan du selv gøre som projektleder

Insistér på, at folk bliver allokeret til dit projekt i ”hele klumper”

Du skal for enhver pris undgå, at få projektressourcer, der er allokeret et par timer hist og pist. Ofte bliver især nøgleressourcer smurt tyndt ud på flere projekter – 10% hér og 15% dér. Dette er ”skrivebordsallokeringer”, som gør det umuligt, at få opgaven løst optimalt, og det er uproduktivt. Konsekvensen er nemlig, at en aktivitet, der tager 3 dage, hvis man får tre hele dage til det, pludselig er flere uger undervejs og tager længere tid, fordi man hopper til og fra opgaven.

Så er vi tilbage til forsinkede projekter og belastet projektøkonomi. I din plan ligger de estimerede 3 dage i et samlet stræk. Hvis virkeligheden er, at de 3 dage er hakket op og fordelt over flere uger og derfor er underestimeret, så bliver projektet forsinket.

Som minimum må du kommunikere den økonomiske og tidsmæssige konsekvens af dårlig ressourceallokering.

Lav klare aftaler med dem, der skal levere på dit projekt

At vise i din plan, at du skal bruge en bestemt kompetence, er ikke ens betydende med, at du får, hvad du skal bruge. Lav klare aftaler om, hvem du kan få på dit projekt, hvornår, og kommunikér konsekvenserne af evt. manglende kompetencer.

Vigtigt! Få dine ressourcer til at bekræfte, at de har påtaget sig opgaven, ved, hvad der skal til, og har afsat den nødvendige tid. Det er ikke nok, at du får at vide, at de ”vil gøre deres bedste”. Don’t we all? De skal sandsynliggøre, at de kan levere til tiden.

Summa summarum

Vær meget eksplicit, når du fastlægger roller og ansvar på dit projekt, lav præcise aftaler og kommunikér ofte. Dine kolleger regner den nemlig ikke ud, og ”Nogen” har aldrig fået noget fra hånden.

Posted in Best Practice, Forventningsafstemning, Interessentstyring, Kommunikation, Ledelse, Project efficiency, Project Management, Projektøkonomi, Projektledelse, Projektmetode, Projektmodenhed, roller og ansvar | Tagged , , , , , , , , | Leave a comment

En historie om projektspild og hvordan det kan undgås

Forsinkede projekter betyder, at millioner og atter millioner hældes i kloakken

Mange mener, at projektledelse bare er sund fornuft. Gid det var så vel, men var det så enkelt, så ville man ikke se det kæmpespild, som man har på sine IT-projekter. Her tænker jeg ikke på Polsag, EFI, EPJ eller andre kæmpeskandaler, som alle hører om.

Jeg tænker på det spild, der sker hver eneste dag på de projekter, der ryger under radaren, fordi et par millioner hér og dér ikke er så interessante at sætte fokus på. Eller måske er disse småkatastrofer interessante nok. De er bare ikke til at få øje på, med mindre man selv arbejder på dem.

Disse løbske projekter koster virksomheder – private og offentlige – et ukendt, formentlig stort, millionbeløb år efter år. Tænk, hvad man kunne udrette med de penge, hvis ikke man hældte dem direkte i kloakken.

Hvorfor er der så ikke nogen, der råber højt om disse projekter?

  • Måske fordi man ikke er stolt af at have arbejdet på et forsinket projekt.
  • Der mangler måske erkendelse af, at projekterne gennemføres af projektledere eller –teams uden de nødvendige kompetencer
  • Måske foregår de under en ledelse, der ikke sit ansvar bevidst og ikke giver den nødvendige opbakning og strategiske retning.

Eller måske tænker man: ”vi er jo kun en måned forsinkede – det er jo ingenting!”

Mange bække små….

Dette simple regnestykke viser, at man med et lille projektteam på 5 personer til en intern timepris på 300 kr. (hvilket næsten med garanti er for lavt sat) vil spilde 11.250 kr. pr. dag = 230.000 kr. for hver måneds forsinkelse.

Hertil kommer forsinket opstart af nye projekter, planlagte gevinster, som høstes med forsinkelse, evt. ekstra licensomkostninger m.v. For ikke at tale om evt. ekstra omkostninger til eksterne konsulenter. Her slipper man ikke med 300 kr. pr. time.

Allerede her, vil jeg slå én ting fast: Forsinkede IT-projekter eller projekter, der overskrider de økonomiske rammer, er ikke en naturlov.

Jeg gentager lige: Forsinkede og for dyre IT-projekter er ikke en naturlov.

Hvorfor bliver man så ved med at gøre de ting, man ved ikke virker?

Uanset hvordan man vender det, så er IT-projektledelse en ganske kompliceret disciplin. Jo før man erkender dette, des hurtigere kan man finde en løsning. Men hvor starter misèren?

En del af problemet består i, at man forsøger at sætte denne komplicerede disciplin på formel, og tror, at det er tilstrækkeligt.

Ideen om struktur er bestemt rigtig god, men når formlen enten er en projektmetode, der er voldsomt kompliceret (traditionelle metoder), eller ikke er omfattende nok (agile metoder), så skal det gå galt. Begge dele resulterer nemlig i, at det for de fleste projekt-ledere bliver svært at få det overblik, der er forudsætningen for at lykkes med sit projekt.

Det synspunkt bygger på mine konkrete erfaringer med IT-projekter gennem 25 år.

Jeg har arbejdet i store internationele virksomheder, der bruger veletablerede projektmetoder, men i en så omfattende ramme, at ingen kan finde rundt i den. Resultatet er, at deres projektledere anvender metoden på hver sin måde.

Jeg har arbejdet hos kunder, der har hægtet sig på PRINCE2, men ikke forstår de sammenhænge, der er i metoden, og hvad den kræver af organisationen. Det virker heller ikke.

Jeg oplever tit, at kunder ønsker at høste fordelene ved at arbejde agilt, men ikke er villige til at foretage den investering, det kræver at få de agile systemer til at fungere. Agile metoder stiller bl.a. krav til ledelsen og til teamet, der ofte mangler viden om, hvordan fx. Scrum eller Kanban fungerer.

Ingen af disse eksempler virker særlig godt, men man bliver alligevel ved med at arbejde sådan, fordi man:

  • Føler sig tryg ved det kendte, selvom man godt ved, at det ikke virker
  • Ikke tror, at det kan være anderledes med IT-projekter (men det kan det!)
  • Blot følger med strømmen, og tror, at hvis en metode virker for naboen, så virker den også her
  • Ikke vil kaste sin gode, gamle metode over bord, som man måske har investeret meget i. Dette på trods af dårlige projektresultater

Hvad kan man så gøre, for at stabilt få sunde(re) projekter?

Man skal forstå, at IT-projektledelse ikke kun er sund fornuft, og at en (agil) projektcertificering svarer til at få et kørekort. Man kender trafikreglerne, men er ikke nødvendigvis en god bilist endnu. Nogle bliver det aldrig.

Man skal vide, at en certificering er en god genvej til at forstå, hvad man skal rette sin opmærksomhed imod som projektleder, men at man ikke kan læse sig til erfaring.

Man skal vide, at projektlederen er dybt afhængig af en ledelse, der tager ansvar for den forretningsmæssige og strategiske retning, samt af et kompetent projektteam.

Man skal have en projektmetode på plads, der passer til organisationen og dens projektmodenhed, og det er en god tommelfingerregel, at småt er godt!

Det er helt afgørende, at man som virksomhed, projekt- eller IT-afdeling overvejer:

  1. Hvordan er kulturen hos os. Er vi topstyrede eller uddelegerer vi gerne?
  2. Er vi meget hierarkiske og traditionelt opbygget, eller har vi en flad organisation?
  3. Hvis vi vil stramme op på vores projektkultur, ved vi så, hvordan man gør?
  4. Hvis vi vil være mere agile, forstår vi så, hvad det indebærer?
  5. Hvordan skal vi uddanne vores organisation, så den bliver bedre til at levere projekter?
  6. Skal vi have en specialist ind, som kan rådgive om den bedste og enkleste vej frem?

Én ting er sikkert: Man kan købe sig til meget metoderådgivning for bare én måneds forsinkelse til 230.000 kr. for et 5-mands projektteam, jf. ovenfor. Den investering tjener sig hjem mange gange, når man kan levere projekter til tiden igen og igen.

Jeg anbefaler Context-based Project Management. Det er en light-metode, der kombinerer agil og traditionel god projektpraksis, og tilpasses den enkelte virksomhed. Metoden sikrer, at projektgrundlaget er i orden, den giver overblik og er intuitiv at bruge. Også for mindre erfarne projektledere. Det behøver nemlig ikke at være så svært!

Vil du vide mere, så kontakt mig på info@xvoto.dk

Posted in Agile, Agile combined with traditional PM methods, Best Practice, Ledelsesansvar, Organisatorisk agilitet, Project Management, Projektcertificeringer, Projekter og forretning, Projektledelse, Projektledercertificeringer, Projektmetode, Projektmodenhed, Projektteams | Tagged , , , , , , , , | 1 Comment

Skal – skal ikke – Om certificering af projektledere: Er det unødvendig spild af tid og penge eller er det dumt at lade være?

Der er jævnligt debatter i gang om, der er nogen værdi i projektledercertificeringer eller ej. Disse debatter bærer tit præg af nærmest religiøse holdninger enten for eller imod certificeringer. Problemet i den slags debatter er, at det er umuligt at bevise, om man har ret, uanset hvilken holdning man har. Projektledelse er jo ikke en eksakt videnskab, hvor man kan sætte to streger under facit.

Man kan dog dokumentere – det gør f.eks. PMI i deres Pulse of the Profession, at organisationer, der fokuserer på at løfte kompetencerne hos deres projektledere og har aktivt deltagende projektsponsorer m.v., har større succes med deres projekter, end de organisationer, der ikke aktivt arbejder med dette.

Virksomhedens projektkultur og -modenhed afgør om man stabilt lykkes med sine projekter

Mine erfaringer gennem ca. 25 år er helt i tråd med ovenstående, men med den tilføjelse, at de organisationer, der bruger tid og penge på at gøre deres projektledere skarpere, typisk er dem, der allerede har opnået en vis modenhed, og derfor har forståelse for kompleksiteten i projekter. De har erkendt, at den succesfulde projektleders kompetencebredde, ikke bare kommer af sig selv.

I disse mere modne organisationer ved ledelsen også, hvordan den selv bedst kan understøtte sine projekter og projektledere – og gør det! Bl.a. ved at bidrage med:

  • On-demand strategisk eller forretningsmæssig beslutningstagen
  • Løbende at holde sig godt informeret om projektet, og ikke mindst
  • At sikre, at resten af organisation bidrager med nødvendige ressourcer, viden m.m.

De ved, at en projektleder ikke kan eller skal være en enmandshær.

Der er kontant afregning, hvis man lader projektlederne i stikken

Hvis ikke man arbejder på at løfte hele organisationens projektmodenhed, så vil man se, at nogle projekter lykkes, mens andre kører direkte i hegnet. Man vil se, at nogle projektledere lykkes oftere end andre, måske pga. af deres personlige gennemslagskraft, men selv de dygtigste vil fejle ind imellem, fordi de ikke får de nødvendige betingelser for succes. Bl.a. i form af ledelsesopbakning og rådighed over ressourcer med de nødvendige kvalifikationer og tilstrækkelig tid til projektet.

Mange af os har sikkert mødt projektledere, der var certificerede, men temmelig uduelige, eller nogle gudsbenådede projektledere, der aldrig har været i nærheden af en certificering. Nu findes der jo også personer, der har haft kørekort i årevis, men stadige er elendige bilister, eller nyudklækkede bilister, der kører som en drøm. Men ville man nogensinde drømme om at sende folk ud i trafikken hvis ikke de kender trafikreglerne?

Nej vel? Det er oven i købet forbudt!

Det modsatte er ofte tilfældet i projekter, hvor det er en ofte brugt floskel, at projektledelse ”bare er sund fornuft”. Derfor betror man projekter og store budgetter til folk, der ikke har kvalifikationerne til opgaven, men alligevel siger ja tak. Måske fordi de ikke ved, hvad det egentlig er, de siger ja til.

Det skal jo gå galt. Og det gør det!

Tallene taler for sig selv.

Er der sammenhæng mellem fejlede projekter eller ukvalificerede projektledere og projektledercertificeringer?

Nej, selvfølgelig ikke!

Projektcertificeringer gør ikke projektledere dårligere til deres arbejde, og den certificerede projektleder kommer utvivlsomt hjem med noget viden, som han/hun i det mindste selv kan bruge.

Men vælger man en projektmetode, der ikke passer til ens organisation, så kan det fra et virksomhedssynspunkt sagtens være spild af tid og penge at certificere sine projektledere i denne metode.

Er en organisation meget hierarkisk opbygget vil en agil metode typisk ikke være særlig velegnet, og er den projektumoden, vil det oftest være en for stor mundfuld at vælge f.eks.  PRINCE2.

At man vælger den forkerte metode, gør bare ikke metoden i sig selv ubrugelig.

Ser man på de etablerede certificeringer både agile og ikke-agile, så kræver de alle, at man har styr på rammerne for projekterne, samt viden om, hvordan man sikrer robust styring af disse rammer.

Check f.eks. PMI’s ISO-certificerede projektstandard. Her finder man 10 videnområder, som jeg ikke kan forestille mig, at nogen professionel projektleder ville finde unødvendige eller ligegyldige. Her er 6 af dem:

  • Scope management
  • Communication management
  • Time management
  • Quality management
  • Risk management
  • Stakeholder management

Alle de gængse projektcertificeringer – både agile og traditionelle – behandler disse videnområder i én eller anden form. Der er bare forskellige måder at gøre det på.

Hvad er så problemet og hvad er løsningen?

De fleste organisationer har en projektmetode i én eller anden udstrækning, men problemet er, at mange vælger en metode, uden at gøre sig klart, om organisationen kan rumme den, og hvad det kræver at få metoden til at fungere. Man vælger tit ”det de andre gør”, uanset hvad konkrete projektresultater viser.

Mange går efter en agil metode, fordi det på papiret ser ud til at være nemt og giver en højere succesrate. Problemet er bare, at intet er gratis eller kommer af sig selv. Agile metoder kræver oven i købet et helt ændret mindset, og det betyder, at man er nødt til at investere i uddannelse. Ikke kun af et par Scrum Masters, men bredt og in-house så hele organisationen forstår de nye agile sammenhænge i virksomhedens kontekst, og hvad eget bidrag til sunde, agile projekter skal være.

Det rækker heller ikke at kun uddanne eller certificere enkelte projektledere i en eller anden metode. For tændt af den hellige ild, kommer de nycertificerede tilbage i organisationen, som ikke aner, hvad denne certificering går ud på, og derfor ikke kan agere fornuftigt og dermed få hele projektsystemet til at fungere.

Hvis man skal have sundere projekter og vil have noget ud af at uddanne eller certificere sine projektledere, så kræver det især at:

  1. Man nøje overvejer, hvilken metode der passer bedst, og tænker kontekstbaseret
  2. Organisationens ledere arbejder målrettet på at blive gode projektsponsorer
  3. Leveranceteams forstår, hvad det kræver at være velkvalificerede teammedlemmer
  4. Man er villig til at uddanne hele sin projektorganisation, så der bliver fælles fodslag
  5. Man investerer løbende i at vedligeholde projektlederkompetencerne
  6. Nyansatte uddannes i den projektmetode, der følges, så de hurtigt kommer i omdrejninger

Et par afsluttende bemærkninger og tips

For at opsummere, så har projektcertificeringer naturligvis værdi. Man får ”kondenseret viden” ofte opbygget over mere end 50 år, men man får kun gode resultater ud af disse certificeringer, som kan være ganske komplekse, hvis man uddanner alle sine projektledere og er nogenlunde konsekvent i sin brug af projektmetoden hjemme i organisationen.

Kan man klare sig uden projektcertificeringer?

Ja, naturligvis! Det vigtigste er, at man undgår en ”hver-projektleder-gør-det-de-selv-synes” situation, men har nogle stærke rammer omkring sine projekter. Man kan sagtens få en god, praktisk projektuddannelse, og en effektiv (evt. agil) metode implementeret, uden at skulle kaste sig ud i omfattende og dyre certificeringer.

Det jeg har set virke bedst, er at:

  1. Inden man kaster sig ud i det store certificeringsridt, så overvejer man først, hvor skoen trykker på ens projekter, og vurderer hvad ens organisation kan rumme
  2. Derefter overvejer men, hvor man godt kunne tænke sig at være ift. struktur, opfølgning, rapportering m.v.
  3. SÅ vælger man, hvilken metode, der passer bedst, og oftest er en letvægtsmetode mere end nok. Keep it simple, og undgå at komplicere projekterne unødigt

Derefter uddanner man sine projektledere, og de bedste resultater opnår man, når man uddanner hele flokken in-house, i stedet for kun en enkelt eller få projektledere. Denne investering får du igen mange gange i kraft af optimeret projektgennemførsel og mindre spild, fordi tingene gøres rigtigt første gang!

  • Vil du vide mere om hvilke projektmetoder, der passer bedst til din organisation og dine projekter?
  • Kunne du tænke dig at få opkvalificeret dine projektledere eller dine egne projektkompetencer?
  • Vil du have en Scrum Master eller Product Owner certificering eller vide mere om Kanban?
  • Vil du have en gennemgang af din projektmetode for at sikre at den er fit-for-purpose?
  • Eller har du bare spørgsmål vedr. projektmetode generelt?

Så er du velkommen til at kontakte mig på: info@xvoto.dk. Du kan også læse mere på http://www.xvoto.dk

Posted in Best Practice, Ledelsesansvar, Projektcertificeringer, Projekter og forretning, Projektledelse, Projektledercertificeringer, Projektmetode, Projektmodenhed, Projektteams | Tagged , , , , , , | 1 Comment

Kører din virksomheds IT-projekter også af sporet?

Dette er et enkelt, men sikkert irriterende spørgsmål at få, for sandsynligheden for, at du må svare:

  1. Ja, jævnligt, eller
  2. Ja, det er mere reglen end undtagelsen, eller
  3. Ja, men det gør IT-projekter da altid!

er ganske overhængende. I hvert fald, hvis du skal give et ærligt svar.

Ifølge undersøgelser foretaget af Project Management Institute (PMI), og dokumenteret i Pulse of the Profession fra 2015, så er raten på succesfulde projekter, flatlinet på ca. 64% de seneste 4 år. Det er et gennemsnit, der dækker over, at nogle organisationer lykkes rigtig godt, mens andre har virkelig dårlige resultater.

Nedenstående grafer, ligeledes fra PMI’s Pulse of the Profession, viser, hvordan højt performende organisationer og organisationer med høj agilitet skiller sig ud i forhold til low performers og ikke-agile organisationer.

PMI Pulse 2015 agile org PMI Pulse 2015 high perf. org

Det vil sige, at:

Forsinkede og for dyre projekter, der ikke leverer de aftalte mål, ikke er nogen naturlov.

Derfor er projektuddannelse ikke spild af tid:

Der bliver skrevet meget om, hvorfor de traditionelle projektlederuddannelser fejler, og nærmest bliver betragtet som ligegyldig spild af tid. Det er en noget frisk påstand, og svarer nogenlunde til, at man siger, at alt det der med at tage kørekort er spild af tid. Kør du bare ud i trafikken, og håb på det bedste!

Det synspunkt er der nok ikke mange, der vil bakke op omkring. Man slipper ikke folk løs i trafikken uden, at de har dokumenteret, at de kender trafikreglerne, og man burde heller ikke slippe projektledere løs på projekter, før de har dokumenteret, at de har kompetencerne til at lede dem. At have en projektlederuddannelse eller en certificering gør dig ikke automatisk til en god projektleder – man kan trods alt ikke læse sig til erfaring, men det giver dig forudsætningerne for med tiden at blive det.

Forskellen på projektledelse og trafik er, at du kan miste dit liv i trafikken, hvor vi ”kun” mister penge i projekter. I fejlede offentlige projekter er det dog vores allesammens penge – og mange af dem! Penge, som igen og igen hældes direkte i kloakken!

Hvis vi bliver i trafikanalogien, så kræver det et særligt kørekort at køre bil, motorcykel, lastbil, osv. Men de samme færdselsregler gælder for alle trafikanter. I projektverdenen er det typisk sådan, at man kun uddanner projektledere – hvis man da overhovedet gør det – inden de slippes løs med måske adskillige projektmillioner, mens det er yderst sjældent, at man uddanner projektteams, mellemledere og topchefer i deres roller og ansvar på projekter, og hvad deres bidrag er som forudsætning for succesfulde projekter. Derfor sidder projektledere ofte klemt fast mellem et projektteam og en ledelse, der ikke har de nødvendige projektkompetencer og/eller den nødvendige projektmodenhed.

Det må jo gå galt. Og når det så helt forudsigeligt gør det, ja, så ryger skylden direkte over på projektlederne, dårlige projektlederuddannelser eller andet, der er centreret omkring projektlederen. Der er en udbredt modvilje mod at erkende, at:

Projekter er systemer, der typisk trækker tråde fra bund til top i en organisation.

Kloge ord fra en topchef om ledelsens ansvar i projekter:

Jeg blev helt opløftet, da jeg for et par uger siden læste en klumme i Børsen, skrevet af Jan Amtoft, som er tidligere IT-direktør i bl.a. Lego og FLSmidth. Han påpeger, at:

”Topledelsen må have digital transformation som en af sine kernediscipliner og bør inkludere en digital frontkæmper” og at ”Linjeledelsen har ansvar for personalets indsats og engagement samt for resultaterne. Den bør følge stemningen og aktivt gribe ind over for negative kræfter blandt både medarbejdere, ledere og andre interessenter”.

Grunden til, at jeg blev opløftet var, at hér var der endelig en topchef, der ville erkende, at sunde projekter ikke kun er projektledernes ansvar. Projektlederne skal selvfølgelig have gode lederkompetencer, og stå helt i front og tage ansvar, når det gælder planlægning, opfølgning, styring, rapportering m.v. Men ansvaret for projektets succes er delt med linjelederne, som skal sørge for, at projektteamet er optimalt bemandet og topcheferne, der skal være til stede for nødvendige strategiske beslutninger, og som skal undgå at udstikke rammer, der er for snævre, eller have opskruede forventninger til, hvad der reelt kan lade sig gøre.

Hovedproblemerne men også løsningsforslag:

Men hvad gør vi så ved det?

Jeg arbejder som projektleder hos både offentlige og private kunder, og bliver ofte inviteret til at holde indlæg på konferencer, i virksomheder mv. om agile metoder, agil projektledelse, og ikke mindst Context-based Project Management®. (Sidstnævnte er Xvotos svar på en løsning, som virker i den virkelige projektverden, når man gerne vil være lidt mere agil, men ikke ønsker at lægge den mere traditionelle projektstyring helt til side. Se mere på Xvoto – Context-based Project Management.)

Det, jeg ser på mine projekter, og det jeg hører fra deltagerne på konferencer m.v., er stort set enslydende, og stemmer helt overens med PMI’s observationer og klummen af Jan Amtoft:

Projektlederne har svært ved at få den nødvendige kontakt til og beslutningskraft fra deres ledelse.

Det giver forsinkelser.

De er frustrerede over at måtte arbejde med projektteams, der ikke har de rette kompetencer.

Det giver dårlig kvalitet i løsningen.

De føler ikke, at der er lydhørhed, når de beder deres ledere om at få ressourcer på projektet, der ikke er spredt over adskillige andre projekter eller opgaver.

Det giver unødvendigt spild.

Der er målt på ovenstående, det er dokumenteret, og vi ved det godt, men vi reagerer ikke på det. Vi fortsætter ud af det samme spor, og vi får de samme resultater. Vi krydser fingre for, at miraklernes tid ikke er forbi, men der sker ikke mirakler på IT-projekter.

Vejen frem:

Vi må arbejde på sagen, vi må gøre noget nyt, og vi må erkende, at en projektleder ikke er den enmandshær, som projekters succes står og falder med. Projektlederen er en ekstremt vigtig brik, men selv den dygtigste projektleder kan ikke skabe gode projekter uden:

  1. Et kompetent projektteam
  2. Et projektteam, der er allokeret i nødvendigt omfang
  3. En projektsponsor, der står bag projektlederen. Både af navn og af gavn
  4. En ledelse, der kender deres rolle og ansvar i projektet, og har beslutningskraft
  5. En organisation, der er uddannet til at arbejde i og håndtere projekter

Hvordan kommer vi derhen?

Først må vi erkende, at projekter er systemer, der involverer andet og mere en projektlederen. I nogle tilfælde er det hele organisationen, der skal involveres.

Derefter skal du:

  • Lægge dig fast på den vej, du mener, vil virke bedst i din organisation. Er den agil, eller er den mere traditionelt gearet?
  • Hvis du ønsker at blive mere agil, så find ud af, hvilken agil metode der vil passe bedst i din kontekst. Er det Scrum, er det Kanban eller noget helt andet?
  • Når du har valgt metode, så erkend, at projektmetoder ikke er intuitive. Uddan, uddan og uddan!
    • Dine projektledere
    • Dine projektteams
    • Dine ledere

Det optimale er, at lade uddannelsen foregå i din egen virksomhed, så du ikke kun får en enkelt eller få projektledere uddannet, som får nogle kompetencer med hjem, som ingen andre forstår, men får uddannet alle i den valgte fælles model.

Når du har gjort dette, er du på vej til at få en mere moden projektorganisation, der med tiden vil ende som en high performing organisation. Hvis du er lidt tålmodig, så vil dette ske over tid. Men det er en transformation, der ikke sker natten over.

Én ting er dog sikker: Forsætter du som nu, så må du kigge langt efter øget projektsucces.

Vil du vide mere om agile metoder, agil projektledelse eller Context-based Project Management®, så check vores hjemmeside www.xvoto.dk, hvor du også kan skrive dig op til vores nyhedsbrev og få gratis tips, kontakte os eller melde dig på vores kurser i Scrum, Kanban, Context-based Project Management® m.v.

Posted in Agile combined with traditional PM methods, Agile implementation, Agile project management, Best Practice, Kanban, Ledelse, Ledelsesansvar, Nødlidende projekter, Organisatorisk agilitet, Project efficiency, Projektledelse, Projektmetode, Projektmodenhed, Scrum | Tagged , , , , , , , , , , , , | Leave a comment

Don’t Forget These 3 Factors when You Go Agile

When organizations decide to adopt agile, this is what often happens: You are so keen on your decision to go agile, you may even have top management buy-in, but in the hype of the agile transformation, you forget to consider below 3 factors. This is dangerous because they can in fact cause your agile implementation to fail.

These are the 3 pitfalls you should always avoid:

  1. Failing to recognize organizational resistance to the agile transformation
  2. Not applying a structured use of agile and taking the “how-difficult-can-it-be” approach
  3. Forgetting project management good practice

1. Organizational Resistance:

You will find resistance to change at all levels in the organization. On the team-level, most team members may be convinced of the value of agile, but very often, a few team members do not buy in to the agile concepts:

  • They are not comfortable with visualization. They do not like or want to discuss what they are working on, what they have completed, etc.
  • They are not keen on sharing information but want to be the indispensable specialists
  • Some team members just prefer getting an order. They do not like to be made accountable for their own work and are reluctant to assume responsibility

On the managerial level, there are also obstacles when going agile:

  • Some managers are more comfortable with the command and control approach. They lack the confidence that their teams can best decide how to best get from A to B
  • Managers do not like to delegate decision power (to Product Owners). They are too busy maintaining their own position and are sub-optimizing on the department level
  • They do not know enough about how they can best support agile teams and continue with “business-as-usual”, so the waterfall mindset lives on

2. A Structured Use of Agile:

Project management methods have been available since the sixties, they have expanded ever since, and have become quite complex. Therefore, it is tempting to look to agile methods because they look so simple – at least on the surface. When making the agile choice, organizations tend to forget project management good practice and to set some ground rules about how Scrum, or Kanban etc. should be used across the organization.

If your company is born agile, this may not be a problem. Everyone has worked agile from the very start and everyone knows the playing rules. However, most companies have used a traditional PM method such as PMI, PRINCE2, or IPMA, for numerous years. Then, when there is a move towards higher agility, and some or all project teams have started to use Scrum or Kanban, each team does it their way.

One purpose of using a method in the first place is to get a common vocabulary so everyone working on projects have the same understanding of the language used, the way teams should collaborates, how progress is documented, how KPIs are measured, etc.

It is easy to get e.g. a Scrum Master certification, and to understand WHAT should be in place in terms of events, roles, and artifacts, but HOW you do the work is not part of the certification. It’s important to understand that Agile is not intuitive! Therefore, you must describe the HOW, i.e. the way your chosen agile method should be used in your organization.

Furthermore, just as you need to be in control of your traditional project portfolio, the same is just as relevant for the agile portfolio. You usually have a limited amount of money to invest in projects, and therefore, you need to prioritize them – some provide more business value than others. You should keep track of how well your project money is spent, and follow up using the same set of KPIs so you are comparing apples with apples.

3. Forgetting Project Management Good Practice

One single thing that must be emphasized is that the nature of your projects will not change just because you start using agile methods and techniques to control them.

  • The vision of the project remains the same
  • The project complexity and risks are the same
  • The budget is the same
  • The team is the same

Many believe that their projects will be easier to do if they use agile methods to control them. This is not correct. Agile does not reduce complexity or remove risks, but there will be transparency, so your problems/impediments/blockers/challenges become visible as soon as they arise and you can act on them immediately.

Most traditional methods cover projects end-to-end, whereas agile methods e.g. Scrum focusses on the development phase, but: What happens from the project idea turns up in the horizon until the development starts? What happens when the development phase is over? How do you hand over to daily operations? What about the end-users? What about benefits realization? None of this is covered in e.g. Scrum, but should be, so why not make good use of relevant elements from traditional good practice?

I am suggesting keeping an open mind to different methods and avoiding dogmatic thinking. We are probably all working on projects because we enjoy it. We love the challenge, we like working in teams, and it gives us a kick when we succeed.

From the business perspective, it would most likely increase your project success if you considered the following:

  1. If you have a PMO, decide what KPIs you will put in place for your agile projects. If you do not have a PMO, consider the agile KPIs anyway! Also decide how status reporting should take place
  2. Train your organization in agile from the bottom to the top. What is the required behavior from top- and mid-level management in support of agile? What is expected from team members in terms of accountability and what responsibilities do the agile teams have? What is expected from Product Owners? It is not enough to train a few Scrum Masters if you want agile to work well
  3. Becoming agile requires a cultural change, and since culture eats strategy for breakfast but probably also for lunch and dinner, be clear on what change you would like to see, put some goals in place, measure the results, and act on the findings.

The Agile Journey

Will not happen overnight. Moving from traditional project management to agile is a paradigm shift. From push to pull systems from a control-and-command culture to a trust culture where authority is delegated. This takes time, but a good structure with some control mechanisms will most likely help you get the wanted results quicker.

When starting on the journey be prepared to see an initial decrease in productivity, but trust that this investment will pay off very quickly. Train the organization. When everyone knows what is expected from them, you are more likely to get the results that you want.

Last but not least: even if the results on agile project are better on average than the results on traditional projects, there is still room for improvement. You will most likely get part of the way to increased project success by applying selected good practice from traditional methods to agile and thus combining the two approaches based on the context.

If you want to know more about, how Xvoto can help with a successful agile implementation? Read more (in Danish) or contact us via our website http://www.xvoto.dk.

Posted in Adopting agile, Agile, Agile implementation, Agile project management, Organizational agility, PMO, Project Management | Tagged , , , , , , | Leave a comment

The Top 4 Manager Contributions to Successful Agile Implementations

Lately, I blogged about management behavior that will make or break a robust agile implementation. I mentioned that agile transformations are only likely to succeed if heavily supported by the management. It is a prerequisite for a robust agile implementation that managers act according to agile principles themselves, and:

  1. Are available for timely strategic decision making as required
  2. Provide the frame for true delegation of operational decision power to the operational level
  3. Foster an environment of trust at all levels in the organization
  4. Accept that errors will happen (and understand that they always did)

Only four bullets, but all easier said than done.

Here is why:

Bullet #1 – Timely Strategic Decision-Making:

Top-level managers often do not see the necessity to involve themselves in projects on an ongoing basis. Yes, they allocate (a lot of) money to projects, and yes, they do get upset, when projects overspend or get delayed, but usually they do not see themselves as more than an escalation point for their Project Managers.

They may be dealing with change requests once damage has occurred, but they don’t realize that they could have helped prevent the damage from occurring, by being more directly involved in the projects they have invested in. By simply being available for “on demand” decision-making.

Some agile methods try to cover this lack of business involvement by having a Product Owner (PO) representing the business with all decision power vested in him or her. This role, however, is one that I have never truly seen work as intended. Here are a few reasons:

  1. Politics: Managers will not leave decision power to others
  2. The organization do not trust the PO to make the right decisions
  3. The PO do not understand the purpose and nature of the role
  4. The PO has not been educated to fulfil the role

The result of lacking will or ability from the management layer to involve themselves in projects, and helping with timely decision-making, is suffering agile projects.

Bullet #2 – True Delegation of Operational Decision Power:

Many projects fail. That might be why there is resistance to delegate decision power to Project Managers (PMs) or to POs as “their results prove that they are not able to handle that kind of responsibility”.

However, as long as inexperienced, not sufficiently trained PMs are asked to manage projects that are too complex for them to handle, it is no wonder that projects fail. Here are a few reasons why managers delegate projects to PMs that are not ready for it:

  1. Managers do not realize that (IT) projects are complex by nature
  2. The more experienced PMs are not available, but they still want to start the project
  3. Many believe that as long as a project method is in place, all is fine
  4. There is a “how-hard-can-it-be” attitude when it comes to project management

However, complexities on projects typically do not originate from systems but from people, politics, and organizational behaviors. How PMs might handle these complexities is not explained in any method.

Not understanding the complex nature of projects will, not surprisingly, lead to poor project results. Much would be achieved if organizations would start having look at:

  • How they allocate PMs to projects depending on skills vs. project complexity
  • Whether their project method is fit for purpose (it is usually too complex)
  • The way they educate their PMs internally. (A certification is not enough)

Bullet #3 – Fostering An Environment of Trust:

Having seen many projects fail, managers may not trust their PMs to do things right. Therefore, they insist on having the last say in project matters although they are the least involved, and therefore cannot make the best decisions. Other than poor decisions, which can be bad enough, this causes waiting time, lost resources, and delays.

Organizations do buy in to agile methods, but they often do not realize what big implications this will have on organizational behavior. If you work in a control-and-command type organization, the shift to agile where trust is a prerequisite, may be too big a leap and will not work.

If, on the other hand, organizations really want to realize the benefits of going agile, they must analyze exactly how and where changes are required from top to bottom in the organization. Agile comes with a price in terms of behavior. Here are some reasons why this price is not willingly paid:

  1. Managers do not want to move away from the systems they have used for many years.
  2. Known false sense of security and poor results feel more comfortable than trying “the agile unknown”
  3. Company culture and politics may hinder a trusting environment. The transformation is simply too difficult
  4. Managers don’t see their role in facilitating the transformation to agile and walking the talk

Bullet #4 – Accept That Errors Will Happen And Always Have:

Projects are taking organizations to where they have never been before. No matter how thorough you are and how well you plan, you cannot predict the future – particularly not if the future lies years ahead. Therefore, project teams will make mistakes, estimates will be wrong, contracts may be bad, etc.

Furthermore, project teams, are often forced to deliver under conditions regarding scope, cost, or time that everyone knows are too optimistic. Thus, you are planning for disaster from the very start, and to keep your budgets, deadlines etc., you start cutting corners. You cut quality, reduce test activities etc. This will also result in errors. Errors that could have been avoided by setting realistic project goals.

Error-free projects do not exist and never have. With agile techniques, you can avoid many errors from getting out to customers or end-users, but to get to that point, managers must realize that they must:

  1. Support their agile teams by helping the whole organization  becoming  more agile and by being agile themselves
  2. Stop forcing unrealistic project baselines on their project teams. Reality cannot be changed anyway
  3. Not expect the impossible. Error-free systems or projects do not exist, but insist on building quality into your project processes
  4. Facilitate a learning culture and allow time for reflecting on improvement opportunities

It may sound like quite a mouthful, but if the goal is increased project success, you have to do something different tomorrow compared to what you do today. If nothing moves, nothings changes.

Posted in Agile, Agile failure, Agile implementation, Agile project management, Best Practice, Management, Management responsibility, Organizational agility, Project Management Methods, Uncategorized | Tagged , , , , , | Leave a comment

Management Behavior that Will Make or Break a Robust Agile Implementation

A couple of months ago the following statement was made at a conference by a business manager: “We want better projects, so the management of our company has decided that everyone will start working agile from January 2015”.

I was puzzled. Very puzzled. Did he honestly believe that the whole company would wake up one Monday morning in January 2015 realizing that a whole new era had begun, and everyone would leave all their old habits, attitudes and approaches behind and start being agile?

It made me wonder. Several things, actually:

“If the decision is already made, why don’t they start their agile journey today?”

“Do people really think that transforming a business from a traditional to an agile approach to projects will happen just like that?”

“Have they realized that the decision to work agile means that the management will also have to change their ways?”

“Do they know that doing agile is not the same as being agile?”

Making the transformation to becoming an agile business is a significant endeavor that will not happen overnight and just because top management gives the order. There are too many old habits to be broken, and many agile principles are counter-intuitive compared to traditional ways of managing projects, people and teams.

Once the decision has been made:

It requires determination

It requires training

It requires a will to change at all levels

The Managers’ Contribution to Successful Agile Implementations

One thing is, however, certain – an agile transformation is only likely to succeed if heavily supported on an ongoing basis by the management. It is also a prerequisite for a robust agile implementation that managers too are acting according to agile principles.

This means among other things:

  1. Being available for timely strategic decision-making when required
  2. Providing the frame for true delegation of operational decision power to the operational level
  3. Accept that errors will happen (and understand that they always did)
  4. Fostering an environment of trust at all levels in the organization

Only 4 points – how difficult can that be?

If (agile) project managers were managing their projects in an environment that lived these 4 points, it would result in a significant leap forward to increased project success. So why not just do it?

Well, mainly because it is not that simple. Organizational culture is a powerful thing that is not easily changed. Working agile will impose significant changes to the organization that may have worked according to traditional principles for maybe 10 – 20 years or more. It may look simple but it is not.

The Price of Becoming Agile

There are many good reasons for wanting to get more agility into organizations. First of all the numbers are very convincing. Check the agile communities or Project Management Institute’s annual “Pulse of the Profession”. Research shows that project success rates are significantly higher in agile projects.

Who would not want that?

However, everything comes with a price.

The price for a robust agile implementation is a change in the behavior towards projects throughout the organization, but changes in organizational behavior will usually not happen until managers make the move and change their own behavior:

  • Managers must accept that supply and demand must be balanced, and they should only start as many projects as the organization is able to handle.
  • Spreading key resources (bottlenecks) over too many projects only makes matters worse. Stop starting and start finishing projects rather than having them drag on due to lack of resources. Stop multitasking. It generates enormous waste.
  • Make the organization’s priorities clear to everyone. When help is needed on projects from other departments, is this more important than their “real” job? Has time for project work been prioritized and allocated so other tasks are not suffering?
  • Delegate operational decision power to the (agile) project managers, Product Owners, etc. Waiting for decisions generates lots of wasted time, and the decisions will usually be better when made by those that are directly involved in the projects.
  • Be ready to make strategic decisions on an “on demand” basis, but understand that good decisions require a deeper understanding of the projects. Don’t just scratch the surface, and be a Project Sponsor not only by name.
  • Understand that projects are complex and are taking the organization to new places. Therefore, the project team will most likely make mistakes. However, it is better to make mistakes, correct them and progress, than making no mistakes and stand still.

Once the above is in place, trust will automatically grow in the organization.

Most of the above concerns organizational agility and not what method is used on your projects: Scrum, Kanban, PRINCE2, PMI etc. The agile transformation can be started any time, but will only work if you are ready to make the necessary investments on the management level.

The result will be healthier projects and fewer failures, and since projects are such a big part of the work done in organizations, why not gain the benefit sooner by starting from the top-level with the agile journey today?

Posted in Agile, Agile failure, Agile implementation, Agile implementations, Agile project management, Best Practice, Management, Management responsibility, Organizational agility, Project efficiency, Uncategorized | Tagged , , , , , , , | 6 Comments

Så galt kan det også gå, når man præsenterer nye ideer

I sidste uge var jeg i Amsterdam. Jeg skulle holde indlæg om, fordelene ved at kombinere traditionelle og agile projektmetoder, og hvad der skal til, for at få kombinationen til at virke optimalt. Indlægget var naturligvis velforberedt, og min mission var bl.a. at gøre opmærksom på, at alle metoder har deres fordele, men at en kombination af god praksis fra traditionelle og agile metoder, kan fylde nogle af de huller, som findes i de respektive metoder.

Alle metoder er blevet til for at løse konkrete problemer. I 1960’erne, hvor projektledelse var en relativ ny og umoden profession, var der behov for at få en konsistent model for projektstyring. Her så PMI og IPMA dagens lys, og senere kom PRINCE2 til. Hver metode/standard har deres styrker.

Ingen af disse metoder angiver dog retningslinjer for, hvordan projektteamet og f.eks. en udviklingsproces skal ledes. Dette blev i 1990’erne forsøgt afhjulpet, da Scrum blev ”opfundet” primært til software-udvikling, ligesom Kanban, som en anden agil metode, er velegnet til at styre bl.a. videnarbejde og projekter.

De agile metoder beskriver på deres side ikke, hvad der sker før projektet er en realitet, og hvad der udover team-aktiviteterne skal til for at gennemføre et succesfuldt projekt. F.eks. styring af økonomi, kommunikation, interessenter, risici m.v. Projektlederen er faktisk helt ude af billedet i Scrum.

Kanban tager hensyn til de eksisterende forhold, titler, processer m.v., men giver heller ikke eksplicitte retningslinjer om projektstyringsaktiviteter. I Kanban respekteres projektledere og –metode, men der tages ikke stilling til hvor Kanban ender og traditionel projektledelse begynder.

Fordelene ved at kombinere

Derfor har jeg i de sidste 3-4 år set en indlysende fordel ved at kombinere god praksis fra f.eks. PMI og PRINCE2 med agile metoder. Jeg har arbejdet med agilitet i planlægningen af traditionelle PM-opgaver, KPI-opfølgning, rapportering m.v., og har samtidig styret agile teams agilt. Jeg har set kombinationen fungere igen og igen.

Jeg sparet værdifuld tid ved at lægge MS Project på hylden og bruge et Kanban board til projektplanlægning, og jeg har statusrapporteret på den enklest mulige måde. Dette har både jeg, Project Ownere og styregrupper haft stor glæde af. De har sparet tid, og jeg har brugt mindre tid, end jeg plejede, på at skabe præcis det samme overblik.

Så kom jeg til Amsterdam!

Med disse erfaringer i bagagen gik jeg på konferencescenen, og fortalte begejstret om fordelene ved at kombinere traditionelle og agile metoder, hvordan man kan gøre det, og hvad man skal være opmærksom på. Og så blev jeg ellers mødt af adskillige sæt korslagte arme og hovedrysten.

Med til historien hører, at en af de foregående talere havde dokumenteret, hvordan denne branche jævnligt oplevede +100% overskridelser af budget og tid, hvilket alle var enige i ikke var godt nok. Min forventning var derfor, at mine ideer ville blive modtaget med kyshånd, men jeg tog grundigt fejl!

Jeg spurgte forsamlingen hvor mange, der havde erfaring med agile projekter. Én rakte hånden op. Jeg, metodepragmatikeren, havde altså vovet mig ind i en ultra-traditionel forsamling. Og de reagerede præcis som sådan. Selvom de netop havde bekræftet, at forsinkelser og meget fordyrede projekter var dagens orden i deres branche, så lå det bestemt ikke i kortene, at overveje at prøve noget nyt. Det fik mig til at tænke på disse 2 ting:

1: David Anderson’s Ironic Groundhog Day Resolution:  “I will continue to do what I’ve always done, while expecting things to improve and the outcome to change!”, og

2: Arthur Schopenhauers regel om sandheder: ”Enhver sandhed gennemgår tre faser: Først bliver den latterliggjort, så bliver den kraftigt modarbejdet, og til sidst bliver den accepteret som indlysende”

Deltagerne foretrak at gøre, som beskrevet ovenfor under punkt 1, nemlig fortsætte ad det spor, som de selv mente gav for dårlige resultater. Jeg blev ramt af Schopenhauers fase a og b. Nogle deltagere lavede grin med tanken om, at noget så ”tilfældigt” som agile metoder skulle kunne bruges i deres sektor, og flere argumenterede stærkt for, at agile metoder aldrig kunne virke, fordi man jo ikke ville ane, hvor det hele ville ende.

Denne diskussion kunne jeg umuligt vinde. Der var ikke tid nok, og I et lokale fuld af ”traditionalister”, som, kombineret med stor uvidenhed om, hvad agilitet er, lukkede øjne og ører for enhver mulig værdi af agile! Hér måtte jeg opgive. Dét sker ikke tit.

En one-size-fits-all-metode findes ikke. Nogle projekter ledes bedst på traditionel vis, og andre v.h.a. agile metoder. Hvad der virker optimalt afhænger af organisationens modenhed, kompetencer, teamstruktur, projektforståelse, agilitet m.m.

Sikkert er det, at jeg fik en uventet lektion i modstand mod forandring. Det skal dog ikke forhindre mig i ufortrødent at fortsætte med at fortælle om mine gode erfaringer med agil projektledelse og kombinationen af agil og traditionel god praksis. Det gør jeg bl.a. i den nye, uafhængige projektforening, APMA – Agile Project Management Association. Er du også interesseret i agil projektledelse, så er du velkommen i foreningens LinkedIn gruppe.

Posted in Agile, Agile combined with traditional PM methods, Agile project management, Best Practice, Kanban, Project efficiency, Project Management Methods, Projektledelse, Projektmetode, Projektmodenhed, Projektteams, Scrum | Tagged , , , , , , , | 2 Comments

The Simple Reasons Why Agile Implementations Often Fail

I returned a few days ago from the annual PMI conference in Belgium, where I was giving a speech about the pitfalls in project communication. One of my main points was that too many different languages are being spoken in terms of projects in most organization. This is particularly true when it comes to agile projects.

  1. The project manager and team speaks one language. Probably Scrum or Kanban with all their special concepts and vocabulary
  2. The PMO speaks another language. One of tradition, where there is usually focus on traditional KPIs – cost, scope, time -, which are not in focus in the agile team
  3. Yet another language is spoken on the management level, where the focus naturally is on strategy, overall performance, business benefits and such

What only few companies realize is that having a common project vocabulary would result in fewer misunderstandings, and unnecessary iterations, and furthermore, expectations management would be far easier.

So what does that have to do with failure in agile implementations?

Well, more than one should think. Many companies want to go agile because the numbers and hard facts are very convincing. A lot of research has been done e.g. by PMI, where the annual Pulse of the Profession documents higher project success rate in agile organizations.

The key words here are “agile organizations”, because it is not enough to let project teams go agile, if the rest of the organization does not follow suite.

Access to the Management Layer:

Business agility also lies in the ability for the team to get access to business representatives for clarifications, and strategic decisions as and when needed, rather than having the team’s productivity decrease while waiting for the next steering committee meeting.

The Mental Change

Another reason for failure with agile implementations lies in the fact that it is a big mental change to go from traditional to agile project execution. Here are a few reasons:

  • Not everybody likes visualization and daily follow-up on progress and productivity
  • Agile transparency makes it difficult to hide and easy to determine where things go wrong. It could be due to:
    • Organizational disturbances
    • Lack of Product Owner competency and time
    • Task switching, when team members are allocated to several projects
    • Lack of management involvement
    • Too many defects due to poor testing procedures
    • Lack of team commitment
  • Many project organizations find it difficult to leave traditional thinking. They might have managed projects “the old way” for many years, and are reluctant to move to agile
  • Many resources may have been spent building the existing method. There is reluctance to take steps that make it look like all these resources are thrown in the waste basket
  • Year-long habits are hard to break no matter how bad these habits are

Nothing Comes From Nothing

Yet an important reason for agile failure is the belief that you can get something for nothing. This is usually not possible, and certainly not when transforming your organization to becoming (more) agile.

Agility should never be inherent in project teams only. It should be a mindset that seeps through the whole organization from top to bottom. If the management layer, the PMO, the IT department etc. do not work with the same sense of urgency concerning the business’ projects that is required from the project teams, there will be a disconnect between the strategic and the executing layer. The result being that the benefits from moving to agile will not be realized to their full potential.

Moving to increased agility might be difficult step to take, but let me remind you of the following, very discouraging fact: For many years the project success rate has stabilized around 50%. That is not impressing given the fact that very extensive project methods have been available for more than 50 years. These methods grow and grow, while the success rate remains unchanged. Therefore, I would argue that there is really nothing to lose trying to become more agile.

Why not combine?

In fact, going agile does not have to be all or nothing. There is no good reason why you should not use good practice from both traditional and agile methods. This statement may upset some traditionalists and agilists, but as Kanban by definition respects the systems that exist in the organization, why not use some of the traditional tools, processes etc. from your current methods that really work and combine them with Scrum or Kanban?

Here Are the Simple Reasons for Agile Failure in Short

  1. Too much silo mentality. No common language concerning projects
  2. Lack of business involvement in the projects, the business has decided to start and fund. NB! Project performance is reflected directly on the bottom line.
  3. Mental barriers e.g. regarding visualization
  4. Difficulty with letting go of old habits and resistance to change
  5. Lack of education in agile from top to bottom

All this can be fixed. It just requires a conscious decision, preferably top-down, some enthusiasm and a bit of confidence. Agile does work, but it requires a dedicated effort.

If you want to hear more, please contact: annette@xvoto.dk

Posted in Agile, Agile combined with traditional PM methods, Agile failure, Agile project management, Agile Project Management Association, Best Practice, Kanban, Project efficiency, Project Management Methods, Scrum | Tagged , , , , , , | Leave a comment

Den (måske) overraskende sandhed om ledelsens ansvar i projekter

Nogle ofte oversete fakta om projekter

Uanset om projekter foregår i offentlige eller private virksomheder, så gælder de samme mekanismer og regler. Projekters natur og indbyggede dynamik kan ikke ændres uanset hvem, der måtte ønske det eller ligefrem insistere på det. IT-projekter er pr. definition komplekse, og ingen leder, direktør eller topchef kan ændre det faktum. Det svarer næsten til at ville ændre tyngdekraften. Men det, ledere, direktører og topchefer kan gøre, hvis de ønsker bedre projektresultater, er at involvere sig. Virkelig involvere sig i de projekter, de selv har besluttet sig for at sætte igang, og som påvirker deres forretning – sommetider dramatisk.

Det, man ofte som projektleder bliver spurgt om af ledelsen er, om man leverer projekterne til tiden og uden økonomiske overskridelser. Det er bestemt både valide og rimelige spørgsmål, men det, der virkelig ville flytte noget, og som projektledere virkelig har behov for, men faktisk aldrig bliver spurgt om, er f.eks., hvad ledelsen kan gøre for at bane vejen for projektet, om der er organisatoriske problemer, som ledelsen kan hjælpe med at løse, eller om man har fået de rigtige og nødvendige ressourcer stillet til projektets rådighed.

Det typiske scenarie er, at ledelsen i form af en styregruppe er tilgængelig på månedlige styregruppemøder, og har man brug for at få truffet strategiske, ledelsesmæssige beslutninger, så må man som projektleder pænt vente til det næste styregruppemøde. DET giver forsinkelser, og denne organisering er ineffektiv, dyr og giver dårlige resultater.

Kæmpespild, som nemt kunne undgås

Et simpelt regnestykke viser, at et lille projekt, der binder et team på blot 5 personer til en intern timepris på 300 kr. (hvilket er meget konservativt sat), spilder ca. 250.000 kr. for hver måneds forsinkelse. Dette er vel at mærke rigtige penge. Samtidig udskydes realiseringen af de gevinster, man ønsker at opnå med projektet tilsvarende. Selvom man ser bort fra følgeeffekterne og kun indregner det konkrete timespild, så er der stadig tale om uhyggeligt store beløb, som alene spildes på grund af dårlig projektgennemførelse.

Det mest ærgerlige er, at det ville være temmelig nemt at formindske dette spild markant. Det første skridt til forbedrede resultater er at erkende, at IT-projekter ofte påvirker hele organisationen og derfor kræver dens aktive medvirken fra top til bund. Projekter lever ikke i isolation i projektafdelingen. Denne erkendelse mangler oftest i ledelseslaget.

Ledelsen bliver derfor uforvarende en medvirkende årsag til de mange forsinkede og dyre projekter, fordi de ikke tager deres helt nødvendige del af ansvaret, og medvirker til at geare organisationen til højere projektmodenhed. Denne type projektkulturændringer kan kun gennemføres ”top down”.

Endvidere ville det give øjeblikkelige positive resultater, hvis man fra ledelsens side afpassede antallet af projekter med organisationens aktuelle kapacitet. Jo flere projekter en medarbejder bliver tilknyttet, jo dårligere bliver resultatet. Man vil opleve et spild på ca. 20% af kapaciteten, hvis man er tilknyttet 2 projekter, og er man på 3, spildes hele 40% af den samlede kapacitet. Det viser diverse målinger  helt entydigt. Alligevel fortsætter man ad denne vej, selvom det er både ulogisk og irrationelt.

Check f.eks. følgende: http://www.infoq.com/articles/multitasking-problems, http://research.microsoft.com/pubs/101728/chi2004diarystudyfinal.pdf
http://www.apa.org/research/action/multitask.aspx

De enkle skridt, som topledelsen straks bør tage

Når projektresultaterne ikke er, som man ønsker, så er reaktionen typisk, at projektlederne ikke er kompetente nok og skal uddannes. Det sker desværre ofte, at man betror projekter og ofte store millionbeløb til projektledere, der ikke har de nødvendige forudsætninger for at gennemføre dem. Det er naturligvis altid risikabelt. For disse medarbejdere kan mere uddannelse sandsynligvis hjælpe, men en stor del af ansvaret for fejlede projekter ligger faktisk entydigt i ledelsens manglende ægte interesse og involvering og organisationens manglende projektforståelse og -modenhed.

Derfor skal den ledelse, der ønsker at forbedre succesraten på organisationens projekter gøre følgende:

  1. Første skridt: erkende, at projekter = forretning, og at resultaterne af organisationens projekter havner direkte på bundlinjen. Man skal selvfølgelig involvere sig dybt i sin forretning.
  2. Næste skridt: forstå, at projektledere er fuldstændig afhængige af ledelsens ægte opbakning. Denne opbakning bliver først anvendelig, når lederne forstår, hvad de kan og skal bidrage med. Ledelsen er nødt til at sætte sig ind i, hvordan projekter påvirker organisationen fra top til bund.
  3. Derefter: iværksætte initiativer, der afklarer organisationens virkelige projektkapacitet. Projekter foregår typisk samtidig med, at projektdeltagerne har deres ”almindelige” arbejde. Der skal derfor afsættes plads til projekter, hvis man skal undgå, at noget falder på gulvet
  4. Overordnet: få styr på prioriteringen af projektporteføljen, så man anvender sine knappe ressourcer på de aktiviteter, der giver højest værdi. Ikke alle projekter er lige vigtige, og som man siger i Kanban-verdenen: ”Stop starting, start finishing”.

Foretages disse skridt ikke, så er det mere held end forstand, hvis det lykkes at få mere end 50% af sine projekter bragt helskindet i mål.

Som bonusinformation kan det nævnes, at PMI’s forskning på området viser, at effektiv ledelsesinvolvering i projekter hæver succesraten med op mod 30%. Tankevækkende, ikke?

Vil du vide, hvordan du bedst kommer i gang med disse 4 skridt? Kontakt info@xvoto.dk

Posted in Best Practice, Ledelse, Ledelsesansvar, Nødlidende projekter, Organisatorisk agilitet, Projekter og forretning, Projektledelse, Projektmodenhed, Projektteams, Uncategorized | Tagged , , , , , , , | 3 Comments