It’s all about change and change is here to stay

Happy New Year and welcome 2017 with all the change that it may bring!

2016 has gone almost too quickly. I have been absorbed in a couple of big organizational agile transformations, and change has certainly happened there. Going from a traditional mindset to an agile is a paradigm shift, and the step is quite a big one. But it can be done, and it doesn’t have to be so difficult.

It’s all about managing change

Resistance to change

Fear of change

Unwillingness to change

But fortunately, there are also frontrunners, and people who are curious about what good things agile might bring. They are your helpers.

But why is the shift from the classic to an agile mindset so difficult? Agile methods are supposed to be simple!!

Just looking at the Scrum guide, or papers about Kanban might tempt you to thinking that being agile is piece-of-cake. I don’t want to spoil anybody’s dreams, but this particular dream is only wishful thinking.

Work with Scrum or Kanban is based on the assumption that teams and organizations live by a set of values. Here they are:

kanban-and-scrum-values

But can we assume that people readily buy into or understand the value of transparency, commitment, respect, focus etc.? No, of course not! Actually, I have seen teams acting quite the opposite to these values and yet believed they were very agile.

They were doing mechanical Scrum or proto-Kanban, but had no real understanding of how agile systems work. Thus, the real benefits did not emerge.

The change of mindset is just as difficult for managers, many being strongly opposed to agile. They may support the shift in words, but in actions they work against it. Though there is massive evidence of improved service delivery or success with projects in agile organizations, they are not tempted to let go of their power. Even for the greater good.

Old organizational hierarchies are working against agile principles e.g. team self-organization, and delegation of decision power. Getting from the old ways of control-and-command to a real pull-system is not trivial. You must genuinely pursue this change, or it will not happen.

Meet team members Grumpy, Skeptical, and Know-it-all

I am currently writing a book about Kanban, and my angle is practical. What do you do, when reality is far from the wonderful picture of the competent team, the always-available Product Owner, the motivated individuals, the supportive managers that e.g. the Scrum guide tries to paint?

What happens when the prerequisites for making Scrum or Kanban work are not meet? Does it mean that you should give up? No, of course not, but you must be realistic about what can be achieved, and you must articulate the end goal.

Agile methods cannot change a bad culture, solve problems or remove complexity, but they sure put the spotlight on those. Then it is up to the organizations/teams how they want to react on the findings. To do nothing is also a choice. Probably a bad one.

The top-5 reasons for not wanting to embrace agility

In my work with customers I have met team members like Grumpy, Skeptical, and Know-it-all. Fortunately, a good many positive people too. But from the three first-mentioned you will typically hear the following reasons for resisting to become agile:

  1. We are SO different. Agile will never work for us
  2. Are you saying that what we have done for the past many years is wrong!!!
  3. We already have the optimal process in place. Agile will make things worse
  4. We are educated people, we have already figured out the best way for us
  5. We have worked with visual boards for ages – you can teach us nothing

I could write a lot about how to react to this, but it sums up to the 3 of them not having understood that they are part of a system that is greater than themselves, and that sub-optimization is bad for productivity.

More “dictatorship”, more action. less talk

Since there are as many opinions about agile as there are members in an organization, it’s likely that you will never reach consensus about your agile approach. Therefore, the people in charge of the change must articulate what they want to achieve.

Together with an agile specialist, they must determine where they want to go and the approach to getting there, and then insist that everyone follows that path. On the change journey, there will be plenty of time to explain how the values fit the approach, how good agile practice will lead to continuous improvement etc.

P.S. A hint: where Scrum is often disruptive and harsh on an organization, Kanban is the humane path to agility. With Kanban you look at the work, and seek to balance supply and demand.

PPS: My Kanban book will give you many more details

Posted in Adopting agile, Agile transformation, Change Management, Good practice, Kanban, Management, Organizational agility, Project efficiency, Scrum | Tagged , , , , , , | Leave a comment

Agile transformationer skal være i øjenhøjde med organisationen

Projekter skal hurtigst muligt skabe værdi for kunden. Det sikrer agile metoder . Men de virker kun optimalt, hvis hele organisationen taler det samme sprog og ledelsen er med på den agile vogn

Projekter, der er for længe undervejs. Time-to-market på nye produkter eller services, der er længere, end den behøvede at være. Produkter, der ikke opfylder brugernes behov. Lyder det velkendt?

I kan sikkert nikke genkendende.

De teknologiske fremskridt går så hurtigt, at det vil være de organisationer, der hurtigst kan omstille sig til ændrede markedsvilkår, der vinder.  Ville det så ikke være smart at gøre noget ved det?

I klassiske projektmetoder stiller man alle krav til produktet fra start, d.v.s på det tidspunkt, hvor man ved mindst. I den agile tilgang beskriver man – uanset hvad projektet skal levere – ikke alle detaljer fra start. Kunden beskriver det, der med sikkerhed er behov for, og så kommer detaljerne på senere. Man fremviser produktet undervejs i tilblivelsen, så kunden løbende kan verificere, at han får det, han virkelig har brug for og ikke det, han troede han havde brug for ved projektets start. I agile projekter er man klar til at håndtere ændringer i takt med at kunden bliver klogere på, hvad der kan lade sig gøre.

Kunden skal meget tættere på – så kom bare nærmere!

Mange organisationer er vant til at køre projekter efter de klassiske metoder. De har udviklet et fælles projekt-sprog og mener, at der er et solidt fundament for at drive projekter. Men ofte udebliver resultaterne, og så opstår ønsket om at ændre sig i en mere agil retning, men hvordan starter man en agil transformation?

Når organisationer arbejder agilt, er kunden og andre interessenter tættere på projektteamet hvilket giver den korteste vej fra behov til beslutning og eksekvering. Det skaber fokus. De traditionelle hierarkier giver for lang ventetid og for mange tilbageløb. Det er det spild, der skæres væk, så projekternes gennemløbstid kommer ned.

Det agile mindset er et paradigmeskift

alignment-vs-autonomy

Det agile mindset skal spredes til hele organisationen. Ikke kun i projektteamet. Agile metoder fungerer kun, når ledelsen bakker op, og der er faktisk tale om et paradigmeskift.

Agile er ikke bare en simpel proces, der kan rummes i et A4-ark. Det er et sæt nye værdier og en ny kultur, der skal indarbejdes, hvor topstyring ikke virker. I agile systemer uddelegeres mange beslutninger til de forretningsansvarlige og projekt-teamet, og det nytter ikke noget at være fokuseret på at undgå fejl, da det agile tankesæt netop handler om at prøve sig frem så man finder den bedste løsning.

Agilitet i øjenhøjde

Når jeg rådgiver virksomheder, der gerne vil være mere agile, så bruger jeg mit koncept, som hedder “kontekstbaseret projektledelse ®”. Med det som udgangspunkt ser vi på:

  • Hvor projektmoden virksomheden er
  • Hvor forandringsparat organisationen er
  • Hvilke problemer man gerne vil have has på
  • Hvordan governance-modellen ser ud

Der findes ikke en model, hvor ’one size fits all’. Projekter og kompetencerne hos projektlederne er jo forskellige, organisationer og projektteams er forskellige. Det handler om at vurdere hvor virksomheden er, hvor den gerne vil hen, og hvilke udfordringer vil man gerne have løst. Så arbejder vi med det, der gør mest ondt først, så tager vi det næste, osv. På den måde skabes de løbende forbedringer, som virkelig flytter noget, og gør det varigt.

Agil transformation – fra tanke til implementering

  1. Find ud af, hvor din organisation er i forhold til agil parathed.
  2. Afklar hvilke problemstillinger organisationen ønsker at gøre op med?
  3. Start op i et pilotteam, og brug erfaringerne til at afgøre, hvordan der kan rulles ud i større skala.
  4. Få styr på hegnspæle og råderum, keep it simple – og gå så bare i gang!

Har I også brug for at præstere mere uden at blive flere, så lad os sammen kigge på, hvordan I kan blive mere agile. Det er faktisk ikke særlig svært eller særlig dyrt at komme i gang. Det kræver bare lidt vedholdenhed 🙂

Kontakt mig på 5151 9297, så finder vi den nemmeste og bedste vej for jer.

 

 

Posted in Adopting agile, Agile, Agile implementation, Agile project management, Agile transformationer, God praksis, Organisatorisk agilitet, Uncategorized | Tagged , , , , , , , | Leave a comment

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