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

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

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

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

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

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

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

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

Der er kontant afregning, hvis man lader projektlederne i stikken

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

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

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

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

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

Tallene taler for sig selv.

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

Nej, selvfølgelig ikke!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Et par afsluttende bemærkninger og tips

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

Kan man klare sig uden projektcertificeringer?

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

Det jeg har set virke bedst, er at:

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

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

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

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

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

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

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

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

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

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

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

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

Det vil sige, at:

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

Derfor er projektuddannelse ikke spild af tid:

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

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

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

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

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

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

Kloge ord fra en topchef om ledelsens ansvar i projekter:

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

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

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

Hovedproblemerne men også løsningsforslag:

Men hvad gør vi så ved det?

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

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

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

Det giver forsinkelser.

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

Det giver dårlig kvalitet i løsningen.

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

Det giver unødvendigt spild.

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

Vejen frem:

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

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

Hvordan kommer vi derhen?

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

Derefter skal du:

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

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

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

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

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

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

Don’t Forget These 3 Factors when You Go Agile

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

These are the 3 pitfalls you should always avoid:

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

1. Organizational Resistance:

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

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

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

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

2. A Structured Use of Agile:

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

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

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

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

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

3. Forgetting Project Management Good Practice

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

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

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

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

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

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

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

The Agile Journey

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

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

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

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

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

The Top 4 Manager Contributions to Successful Agile Implementations

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

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

Only four bullets, but all easier said than done.

Here is why:

Bullet #1 – Timely Strategic Decision-Making:

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

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

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

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

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

Bullet #2 – True Delegation of Operational Decision Power:

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

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

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

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

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

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

Bullet #3 – Fostering An Environment of Trust:

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

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

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

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

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

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

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

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

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

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

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

Management Behavior that Will Make or Break a Robust Agile Implementation

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

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

It made me wonder. Several things, actually:

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

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

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

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

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

Once the decision has been made:

It requires determination

It requires training

It requires a will to change at all levels

The Managers’ Contribution to Successful Agile Implementations

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

This means among other things:

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

Only 4 points – how difficult can that be?

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

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

The Price of Becoming Agile

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

Who would not want that?

However, everything comes with a price.

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

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

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

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

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

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

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

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

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

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

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

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

Fordelene ved at kombinere

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

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

Så kom jeg til Amsterdam!

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

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

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

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

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

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

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

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

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

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

The Simple Reasons Why Agile Implementations Often Fail

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

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

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

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

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

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

Access to the Management Layer:

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

The Mental Change

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

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

Nothing Comes From Nothing

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

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

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

Why not combine?

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

Here Are the Simple Reasons for Agile Failure in Short

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

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

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

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

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

Nogle ofte oversete fakta om projekter

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

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

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

Kæmpespild, som nemt kunne undgås

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

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

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

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

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

De enkle skridt, som topledelsen straks bør tage

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

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

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

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

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

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

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

Here are the 4 Questions that I Always Get When I Introduce Kanban as THE Method to Plan and Control Projects and to Increase Project Quality While Keeping the Team Stress-free and the Customer Satisfied

…and of course you will also get my 4 (almost) simple answers to these questions

But First a Little Background Information:

For several years I have been working with Kanban as the planning and controlling mechanism on my projects which are mainly IT projects/programs. I have seen Kanban work again and again even in very complex scenarios in both the public and private sector.

I have also dug into the theory behind Kanban – I recently became LKU Accredited Kanban Trainer -, and can give the academic reasons behind why it works so well on any type of project or knowledge work. But the empirical evidence might be more interesting.

It really puzzles me that even if organizations – managers and project managers – agree that their project performance is too poor (it’s a fact that still approx. 50% of all projects fail) they are still very reluctant to try something new.

I can’t help asking the question: “Why do you stay on a path that will very likely lead you to a 50% project failure rate, when there are more successful alternatives? Why not try Kanban – try it out small scale – what have you got to lose?”

A Few (of Many) Advantages:

I admit that I have become a huge fan of Kanban. It is fairly simple, it is visual, and you can always see the true state of the project. It is also a fact that you cannot overload a Kanban system. This means that: 1. your team never gets stressed-out.

You keep your focus on quality, and save enormous amounts of overhead time, while concentrating on the real project work so you can deliver with predictability. You always work on the most important stuff, you always have your priorities in order, and you only release what is complete (done done). This means that: 2. your customer too is very satisfied.

But now to the 4 questions that I always get asked:

Question #1: How do you handle dependencies? There are always dependencies.
Answer #1: Kanban does handle dependencies. You can turn tickets with dependencies into a special work item type, or give them a special class of service. Or you can note the known dependencies in a special part of the Kanban board. Either way you will be reminded of them daily and are not likely to forget them.

Question #2: What about detailed estimates? If you don’t have thorough estimates, how do you know, when you can expect to be done?
Answer #2: Kanban uses what already exists in the organization. Kanban is evolutionary. If you want to make detailed estimates you can continue that practice. That’s your choice. But let me ask you this: “Did you ever see project estimates that never changed?” If your answer is: “No”, then why should you spend time on trying to hit bull’s eye, which is next to impossible anyway, when a ball park estimate will work just as well?

Question #3: How do you know that the team is working on the right things, when you don’t have a project plan?
Answer #3: Of course you have a plan! First of all you have a clear vision of the end product, and of course you are working according to customer requirements/user stories/use cases.

Furthermore, at any given time, you know exactly what the customer/Product Owner has decided are the 5-10 most important things that the team needs to complete next. Since you cannot foresee the future, and cannot know what lies ahead several months from now, you don’t waste time worrying about it, but only focus on the next top priorities that you know are relevant (because your customer said so).

Question #4: What about deadlines? How can you finish on time, if you don’t work with deadlines?
Answer #4: There is more than one answer to that. If you feel more comfortable noting deadlines on your Kanban tickets, just go ahead and do so. But if it is just a normal project task, there really is no need for estimates, because the Kanban system in itself will ensure that all tasks are completed asap.

When you work on the most important items, and you complete them one at a time, i.e. no task switching and no multitasking which prevents you from wasting valuable time, the flow will be optimized and the tasks completed as quickly as the team is able to. In fact productivity on Kanban projects has been measured to rise by several 100% compared to the running Projects the traditional way.

An important principle in Kanban is “Stop starting, start finishing”. Simple as that!

If you want to know more about Kanban, and how it can help increase your project success without hazzle, please contact: info@xvoto.dk. If you are interested in Kanban courses, check out www.lku.dk

Posted in Agile, Agile project management, Kanban, Project efficiency, Project Management Methods | Tagged , , , , , | Leave a comment

5 (almost) Secret Factors about Agile Project Management

Agile projects were put on a formula by the Scrum inventors in the nineties, but what about agile project management? What IS agile project management?

Factor 1:

In Scrum there is no such thing as a project manager, but on real world projects,  of course there are project managers. Organizations do not change overnight and become agile from top to bottom, and this creates a big gap between what managers, PMOs and others expect in terms of project reporting, risk, communications management etc. and what the agile teams can deliver. Of course there must be a project manager in place to handle this.

Factor 2:

Usually people think that an agile project manager is a PM that works with Scrum teams. This, however, is a definition that is much too narrow. An agile PM is someone who is able to work context based. The Agile PM is able to work in traditional project environments, in agile environments, or in a combination of both. The agility lies in the ability to shift and use diffent techniques and tools depending on the context.

The agile PM understands, and therefore is able to work with teams whether they work the old fashioned waterfall way or with Scrum.

Factor 3:

The existing methods force PMs to work in “method silos”. Those silos can be either traditional, such as PRINCE2, PMI, IPMA, etc., and they can be agile, such as Scrum, Kanban, etc. However, none of the agile frameworks offer any guidance as to how to project manage important PM areas such as risk, communication, and stakeholder management, etc.

These areas don’t just disappear when you decide to work with agile teams. Therefore, there is a need to break down those method silos, appreciate that there is good stuff to be found in all of them, and become brilliant at speaking several “method languages” and learn to pick the right things from the methods and work context based.

Factor 4:

Context based project management (CBPM)® is not difficult. In fact it dramatically reduces complexity in project management, by leaving out any document, template, meeting etc. that does not provide immediate value, and cannot pass the “so-what-test”.

The so-what-test is when you ask yourself: “what would happen, if we cancelled this meeting, did not write this document, did not give this presentation?”. If the answer is: “Nothing!” you simply cut away that activity. Think about how much time you spend on meetings that do not produce any results in terms of improved project performance.

CBPM® is truly agile and it’s lean. It can be used in both public and private organization, in traditional project organizations, and in organizations that wish to become more agile in their project thinking, and the way they handle projects, no matter what project method is in use.

Factor 5:

Is probably the most secret factor. Agile project management defined by the ability to shift your PM approach depending on the context and working horisontally using the best of all breeds rather than in method verticals/silos, is a new way of thinking project management. But where to go if you want to know more?

The anwer is: APMA – Agile Project Management Association. This is a new independent organization  where PMs and other with an interest in projects can discuss their ideas and thoughts, share knowledge with their peers in a network based environment.

APMA is unaffiliated and wants to keep an open mind to using what has proven to work on real projects, no matter where the good approaches come from. At this moment we are working via a Linkedin group (APMA – Agile Project Management Association), but that’s just the start.

Summing up….

So why start to think differently anyway? Many methods exist, so why not just use one of them?

The short answer is that after having been in use for more that 50 years, the results are still not good enough. Research shows that approx. 45% of all projects fail. The losses are too big, and we simply have to do better.

If we want to do better, the first step is to break down the artificial barriers between the different traditional methods, and traditional and agile methods, and keep an open mind to using what have been proven to work.

If you are eager to know more about APMA or Context Based Project Management, check out APMAs Linkedin group or contact info@xvoto.dk

Posted in Agile, Agile combined with traditional PM methods, Agile project management, Agile Project Management Association, APMA, Project efficiency, Project Management Methods, Projektledelse, Projektmetode | Tagged , , , , , , , | Leave a comment