Scaled agile frameworks and methods? Don’t waste your time and money in an attempt to make the unworkable work

It has been a while since I have had a chance to write on my blog, and have I missed it!

You may be a busy person too and want to go directly to my latest article on TechBeacon about why you should save your time and money to scale agile if your organization is not ready for it: http://techbeacon.com/are-scaled-agile-frameworks-worth-trying

If you are interested in reading a bit more about agile transformation at first: Please continue reading 🙂

For the past several months I have been heavily involved in introducing and coaching companies in how to introduce agile thinking and principles. These organizations were looking for better project results, improved lead times (=time-to-market), better flow, fewer internal blockings, less waste in their system etc.

These are traditionally organized organizations with too many silos, and not enough collaboration between the silos. As always, there are dependencies between the silos. These are often handled too late causing delays, ripple effects on other projects or initiatives. AND they cause a lot of frustration at all levels.

No doubt the transformation to a more agile approach will improve performance and project results in these companies, but the main reason why I believe that these transformations will actually happen, is the strong management support behind the initiatives and an honest desire to change the organization. Knowing that this change will not come over night.

If you don’t have back-up and support from the management layer, a transformation from traditional project thinking to agile will not happen. You may see improvement on the team level here and there, but nothing significant seen from the helicopter perspective.

Agile systems require a different way of managing people, teams, and projects, and this is not intuitive. In fact it is a paradigm shift. It takes time to adjust your old (bureaucratic) habits to new agile ways, and this adjustment in a whole organization will take years.

Someone has to say it: There is no easy way. No free lunch. No silver bullet. If there were, we would have found it ages ago.

When you start an agile transformation, there is often a desire to scale it to the program level. However, it does not make sense to scale e.g. Scrum, if Scrum is not working properly in your organization. If the roles are not filled by people with the right skillset, if the Product Owner don’t have the authority to make decisions, if there is no agile mindset, agile just will not work, and scaling it will only make things more complicated.

That caused me to write an article about why you should save your time and money to scale agile if your organization is not ready for it. My article has been published on TechBeacon, and you can read the details here: http://techbeacon.com/are-scaled-agile-frameworks-worth-trying

Enjoy! If you have questions or comments please feel free to make them here or send me a mail on annette@xvoto.dk.

Posted in Adopting agile, Agile, Agile implementation, Agile project management, Agile transformation, Good practice, Management responsibility, Organizational agility, Project efficiency, Project Management Methods, Uncategorized | Tagged , , , , , , , | Leave a comment

Sådan gør Kanban livet som projektleder lettere

If you wish to read this article in English, please go to TechBeacon: http://bit.ly/Knbn4PM

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:

PMI Pulse Report 2016 state of proj. outcomes

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!

Posted in Adopting agile, Agile, Agile failure, Agile implementation, Agile project management, Best Practice, God praksis, Kanban, Management, Organisatorisk agilitet, Organizational agility, Project efficiency, Project Management, Project Management Methods, Project maturity, Projektledelse, Projektmetode, Projektmodenhed, Projektteams, Scrum, Uncategorized | Tagged , , , , , , , , , , | Leave a comment

3 ting du som leder kan gøre noget ved med det samme og få øjeblikkelig positiv effekt på dine projekter

Forskning har gennem de sidste mange år vist, at en af de faktorer, der har størst betydning for projekters succes er aktiv ledelsesopbakning. De organisationer, der præsterer godt og stabilt på deres projekter har for 81% vedkommende aktive projektsponsorer. Du kan fordybe dig i tal og detaljer her: PMI Pulse of the Profession 2015

Når nu alt peger på, at stærk ledelsesopbakning giver mere succesfulde projekter, så skulle man tro, at lederne står i kø for at give opbakning til deres projektledere. Men her bliver man skuffet. Som projektleder oplever man meget ofte, at ens projektsponsor, styregruppe m.fl. kun holder sig overfladisk orienteret om de projekter, de er overordnet ansvarlige for.

Projekter opleves tit som et nødvendigt onde, der ikke som sådan kommer ledelsen ved: ”Vi har jo en projektafdeling”, lyder det.

Ofte opfatter ledelsen udelukkende sig selv som et eskallationspunkt, og giver ikke sine projekter den løbende bevågenhed, der er så afgørende for, om deres projektledere kan levere sunde, succesfulde projekter.

Hvad er god ledelsesopbakning?

Ledelsesopbakning kan jo være mange ting, men for lige at starte med, hvad det ikke er, så er det langt fra nok, lejlighedsvis at spørge sin projektleder:

  • Nå, leverer du så mit projekt til tiden?
  • Overholder du det budget, du har fået?
  • Hvad med kvaliteten? Er den OK?

Dét er simpelthen for letkøbt og et udtryk for, at automatpiloten er sat til.

Her er de 3 områder, hvor det virkelig halter, og hvor du som leder med fordel kan sætte ind

1. Prioritering af projektporteføljen, så det er helt tydeligt, hvilke projekter, der er vigtigst og har størst forretningsmæssig værdi

Det vi ofte ser ”derude”, at der er et antal prioritet 1 projekter, et antal prioritet 2 osv. Hér savner vi, at ledelsen tager ansvar for en ægte prioritering.

Ligesom i sportens verden kan der kun være én nr. 1, én nr. 2, én nr. 3 osv. Det kan ikke være anderledes. Men denne mekanisme er ofte sat ud af kraft i projektverdenen, og man hører ofte, at ”alle projekter har topprioritet”.

Det kan jo ikke passe.

Hvis alt er vigtigt, er intet vigtigt.

Der være et projekt, der er vigtigere end alle andre.

Derefter et andet, der er nr. 2 på listen osv.

Ofte mangler der også overblik over hvilke projekter, der er i gang i virksomheden. Det sker oven i købet, at flere afdelinger arbejder på hvert deres projekt, der skal løse det samme problem. Den ene afdeling ved bare ikke, at de andre også er i gang. Det er rendyrket spild!

Hold styr på din projektportefølje og prioritér den. Det forbedrer automatisk projektresultaterne

2. Lad være med at starte flere projekter ad gangen, end der er kapacitet og kompetencer til

Hvis du mod al fornuft gør det alligevel, så betyder det, at dine ressourcer smøres for tyndt ud. Jo flere projekter de fordeles på des værre.

Folk bliver nødt til at multitaske, hvilket er ineffektivt og giver projektspild. Det stresser medarbejderne, og kvaliteten lider. Konsekvensen er typisk forsinkede projekter og en blødende projektbundlinje.

Når man ikke afpasser udbud og efterspørgsel i sin organisationen, så får man projekter, der fortsætter i det uendelige. Dét er dyrt, det binder ressourcer, og de gevinster, man ønsker at høste kommer sent

Man kan ikke ophæve tyngdekraften, og man kan heller ikke presse flere projekter ind i en organisation, end der er kapacitet til og samtidig regne med gode projektresultater.

Gør alle inklusive din bundlinje en tjeneste og afpas udbud og efterspørgsel.

3. Sidst men ikke mindst: Træf robuste, rigtige og rettidige ledelsesbeslutninger baseret på konkret og præcis viden

Projektledere kan typisk træffe beslutninger inden for de afstukne projektrammer, mens strategiske projektbeslutninger træffes af ledelsen.

Det ses ofte, at ens projektsponsor, styregruppe m.v., der er ultimativt ansvarlig for projekterne, kun holder sig overfladisk orienteret, og ikke ved nok om projekterne til at kunne træffe de rigtige beslutninger første gang.

Samtidig kan ledere godt lide at træffe beslutninger.

Dét er en farlig coctail, der ofte giver tømmermænd i form af forsinkede, dårlige eller ligefrem forkerte beslutninger.

Det betyder, at man må i tilbageløb og lave ting om. Dét er frustrerende, og det er dyrt!

Som leder må du ikke undervurdere betydningen af at være tæt på dine projektledere. Hvis du sætter dig godt ind i de projekter, du har ansvaret for, og kan du træffe ”on-demand” beslutninger, så vil du straks se en positiv effekt på projektresultaterne.

Du får lige den hurtige opsummering af de 3 gyldne regler:

  1. Prioritér projektporteføljen efter forretningsværdi
  2. Lad være med at starte flere projekter op end organisationen har kapacitet til
  3. Træf rettidige, sunde og velgennemtænkte projektbeslutninger baseret på konkret viden

Du behøver ikke at gøre alle 3 ting på én gang, men når du ser resultaterne, er det svært at stoppe🙂

Posted in Best Practice, Ledelse, Ledelsesansvar, Management, Management responsibility, Project efficiency, Project maturity, Projekter og forretning, Projektmodenhed, roller og ansvar | Tagged , , , , , , , | Leave a comment

This is why you need to be razor sharp when specifying roles and responsibilities on your project

All project management methods include an activity to specify roles and responsibilities. In Scrum the roles as Scrum Master, Product Owner and the Team as well as their separate areas of responsibility, are clearly defined. In Kanban, flow is controlled by balancing supply and demand, and Kanban respects the roles that are in place in each individual organization. In both systems you use Post-its and note who does what etc.

In PMI, IPMA and PRINCE2, the roles and responsibilities for the steering committee, the Project Manager and the Team are also clearly defined, and there is emphasis on stakeholder and communication management. (Don’t forget that your project team members are also stakeholders). All processes are clearly defined with input and output for each process step.

So why do projects still fail?

They fail, because you cannot fit people into a formula!

Imagine that a project manager comes up to you and says that you are needed on a project. Your skills will be needed in 3 months’ time. You think that it sounds reasonable and suggest that the project manager makes further arrangements with your manager. After this, you don’t hear anything before “5 minutes to 3 months”, when the project manager returns and asks if you will be done soon? “What with?” you ask. In fact, you have forgotten all about the delivery that the project manager asked for approximately 100 years ago, cleared with your manager, but didn’t follow up upon.

This might be pushing things to extremes, but it happens over and over again, that you assume that once you have discussed something once, or if you have sent an email with a deadline, then the delivery will be ready exactly on time. You forget that a project, which may be the most important in the world for you, is not necessarily important to your colleagues. To them projects are typically a stone in the shoe, because they always result in extra work on top of the tasks, that they were hired to do.

Assumptions are the root to all evil!! You must immediately forget:

  1. I assumed that…
  2. I felt that…
  3. I imagined that…

Make clear agreements, communicate precisely, and follow up. Not only once but several times, because people forget or postpone the project task, or they hope that it will go away. Not because they want to make it difficult for you, but because they are busy with everything else but your project.

But does management not leave room for participation in projects for all the project workers?

The answer is a loud and clear NO!! During my + 20 years working with IT projects, I have never seen any organizations organize themselves in a way that leaves room for the employees to participate in projects.

This means that when you need a resource on your project, you have to fight like crazy, because when this person is taken away from his daily work, there are activities that will not be done, will be delayed or might even fall between two stools. But if the resource is not put at your disposal, you cannot proceed in your project. So you end up stuck between a rock and a hard place.

While you discuss the resource situation, your project is delayed, and delayed projects result in exceeded project budgets. That is a fact.

This is what you can do as a project manager

Insist that resources are allocated to your project in “whole pieces”.

You have to avoid – at any cost – that you get resources that are allocated a few hours here and there. You very often see that especially key resources are spread too thin on several projects – 10% here and 15% there. These are “desk allocations” making it impossible to carry out any activity effectively, and it is very unproductive. The consequence is that a task, which is estimated to 3 days, on condition that you have 3 days in a row to complete it in, suddenly takes several weeks to complete, and exceeds the estimated 3 days, because your resources have to do a lot of task switching.

Which brings us straight back to delayed projects and project budgets at risk. In your plan, the 3 estimated days are 3 consecutive days. If reality shows, that the 3 days are chopped up and distributed over several weeks – and thereby underestimated – the project will be delayed.

As a minimum, you have to communicate the consequences of poor resource allocation, which will be exceeded budgets and time delays.

Make explicit agreements with your project team

Just to show in your project plan that you need a certain competence, does not mean that your will get what you need. Make clear agreements on, exactly who you can expect to be allocated to your project, exactly when the resource will be available, and also communicate the consequences of a potential lack of required competencies.

Important! Ask your resources to confirm that they have accepted their tasks, and that they know, what it takes to complete them. Make sure that they have enough time. It is not enough that they tell you that, “they will do their best”. Don’t we all? They have to convince you that they can deliver on time.

To sum it all up

Be very explicit, when you specify roles and responsibility on your project, make precise agreements and communicate often. Your colleagues will not “figure it out”, and “somebody” has never made anything happen – only real people get things done!

Posted in Management responsibility, Project efficiency, Project Management, Project Management Methods, Project maturity, Resource allocation, Roles and responsibilities, Uncategorized | Tagged , , , , , | Leave a comment

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