5 gode råd til at håndtere skisma i agil projektledelse

Agil projektmetodologi er nærmest blevet latent viden for alle os der beskæftiger os med IT-implementeringer. De famøse sprintcirkler sidder på rygraden, og vandfaldsmodellen er næsten blevet et fyord.

Trods bred accept af metoden i både litteraturen og praksis møder vi change managere alligevel en række udfordringer omkring det at arbejde agilt, som vi gerne vil dele. Som change manager er vi nemlig skiftevis modtager og videreformidler af f.eks. disse budskaber:

”Hvorfor skal vi nu igen forklare forretningen, at vi først kommer med MVP (minimal viable product) og ikke hele løsningen?”

”Hvorfor kan IT ikke bygge en komplet løsning, som virker og skaber værdi for mig som bruger?”

Det tegner et billede af misforståelse mellem projektet og forretningen – noget som selvsagt udfordrer løsningens værdi og den overordnede ibrugtagning. Vi giver her vores bud på hvordan I komme misforståelserne til livs.

Klassiske misforståelse mellem projektet og forretningen

Det er vores oplevelse, at de fleste IT-projektteams er meget modne i forhold til den agile metode, men at forretningen og brugerne stadig forventer færdige end-to-end løsninger. Det skaber en forventningskløft. Brugerne holder igen med at bruge systemet, fordi det i deres øjne ikke er færdigt, og implementeringsteamet presser brugerne til at få succes med de mindre delleverancer.

Herved opstår et skisma; IT vil ikke bygge noget der ikke bliver brugt – og brugerne vil ikke bruge noget der ikke er færdigt.

Heldigvis er ønskerne ikke uforenelige, men det kan til tider være et minefelt at navigere i for implementeringskonsulenterne. Fra projektet side bør man derfor blive bedre til at:

1. Vær ærlig omkring hvad I leverer på den korte bane (6-12 måneder) og undgå at overdrive fordelene – brugerne bliver bare skuffet og mister motivation og engagement

2. Gentag hvorfor funktionalitet bliver udviklet i mindre dele, så det rent faktisk skaber værdi. Italesæt fordelene ved at forretningen løbende er inddraget i udviklingsprocessen

3. Træk tempo ud af sprints, så I minimerer dårlige løsninger, der ikke er gennemtestet. Der skaber bare ekstra frustration hos brugerne

4. Tag input fra brugerne som gaver. Det viser engagement og interesse. Find en god og struktureret måde at indsamle input, så alt bliver vurderet og besvaret. Det skaber tillid.

5. Vælg jeres implementeringskonsulenter med omhu. De skal elsker at stå i krydsilden mellem forretningen og IT.

Hvis I kan genkende udfordringen og vil høre mere, så er du meget velkommen til at række ud, ed@changepeople.dk eller 61318097.

Scroll to Top