Kantega
Published in

Kantega

Prosjektlederen er død — leve prosjektlederen?

Jeg er en av dem som har vært aktiv i Kantega for å få vekk prosjektlederen som rolle. Flere vil nok si at jeg er den som har vært mest aktiv. Og nå lurer jeg på om jeg har slått barnet ut med badevannet…

Grunnen til at jeg tenkte at rollen som prosjektleder måtte bort forstår jeg nå at var fordi prosjektlederidealet med å levere på tid-kost-omfang (også kalt jerntriangelet) fungerer bare i noen spesifikke situasjonerer. En prosjektleder som streber etter tid-kost-omfang-idealet vil ikke fungere i IT-bransjen, det står jeg fortsatt for. Men, det jeg har skjønt gjennom arbeidet med Nærings-PhD, er at jeg kunne gått en annen vei der jeg kjempet for å berike rollen som prosjektleder.

Først, la oss se på prosjektdiagnosemodellen til Boonstra & Reezigt. De deler inn i to dimensjoner: forutsigbarhet og kompleksitet.

Høy forutsigbarhet = ingen overraskelser

  • Klart mål​
  • Alle involverte kjenner prosjektet​
  • Tydelige krav​
  • Teknologien er tilgjengelig og kjent​
  • Alle prosjektressurser er tilgjengelige og tilstrekkelige​
  • Prosjektet har få uforutsigbare avhengigheter til andre prosjekter​

Dette blir ofte løftet fram som idealet av et prosjekt. Men, hvor mange prosjekter er egentlig slik? Det viktigste som gjør at et prosjekt har høy forutsigbarhet er at du har gjort akkurat det samme — eller nesten det samme mange ganger før. Altså repetisjon. I den fysiske verden er repetisjon ofte nødvendig. Hvis du er snekker og skal bygge 15 rekkehus så må du faktisk bygge hvert eneste av de 15 husene. Klart du får et forutsigbart prosjekt etterhvert da.

Men, når du skal bygge noe i den digitale verden trenger du ikke bygge 15 like programmer: du kan f.eks. gi alle tilgang til samme versjon i skyen, eller du kan “lagre som”. Det betyr at i utgangspunktet starter alle digitale prosjekter — og her inkluderer jeg også det som i dag kalles produktteam — med en mye lavere forutsigbarhet.

Lav forutsigbarhet = overraskelser vil komme, vet ikke hvor…

  • Målene tilpasses etterhvert som man får innsikt eksternt fra eller mer informasjon​
  • Interessenter endrer mening underveis fordi de lærer eller ikke innså hva som trengtes​
  • Teknologien er relativt ukjent​
  • Uklart om man får de prosjektressurser man trenger​
  • Prosjektet avhenger av andre prosjekt som pågår samtidig

For deg og meg som har jobbet i IT-bransjen noen år kjenner vi oss godt igjen i at IT-prosjekter har lav forutsigbarhet.

Den andre aksen i Boonstra & Reezigt sin diagnosetabell er kompleksitet. Eksempel på lav kompleksitet​ kan være:

  • Kontekst (intern/ekstern): det er enten få interessegrupper involvert eller enigheten mellom interessegruppene er høy​
  • Innhold: et teknisk enkelt problem som kan løses i isolasjon av en ekspert fra ett fagfelt. ​

Høy kompleksitet​

  • Kontekst: det er en sjanse for konflikt om prosjektet mellom interne og eksterne interessegrupper. For eksempel er det ikke noen enighet om målet og hva slags ressurser som skal brukes, om hvordan man skal implementere det, eller om effektene på organisasjonen. ​
  • Innhold: folk fra flere fagdisipliner må kombinere innsikten sin for å løse et ikke-trivielt problem.

Her vil det nok variere mer. Inn i diagnosemodellen beskriver Boonstra & Reezigt hvordan man bør jobbe i de forskjellige variantene av forutsigbarhet og kompleksitet.

Tabell med inndeling i høy og lav forutsigbarhet (F), og lav og høy kompleksitet (K). Måten å jobbe på når F er høy og K lav er det som kalles plan-drevet (med jerntriangelet). Når Fer lav og K lav kan man jobbe smidig (korte sprinter og langsiktig fleksibilitet). Mens når K er høy og F høy har man tid til å gjøre grundige analyser og forhandlinger med de forskjellige interessentene. Når K er høy og F lav kjører man scenarieplanlegging eller eksperimenter.
Diagnosemodell for prosjekter, Boonstra & Reezigt 2019

Og der kom befrielsen for meg i å akseptere at ok, hvis det finnes prosjektledere som klarer å se forskjellen på når man må jobbe etter jerntriangelet, og når man må jobbe på andre måter så kan det være lurt med en prosjektleder.

Enda mer inspirasjon til å si “leve prosjektlederen” fikk jeg fra en artikkel om noen prosjektledere i NASA som opponerte mot det strenge prosedyreregimet der og laget sin egen og mye mer fleksible modell. Laufer et al (2015) beskriver disse fire rollene som prosjektlederen bør holde på med. Og dette er noe av det som jeg lurer på om vi har slått ut med badevannet. Hvem er det f.eks. som forutser store forstyrrelser og sørger for at de ikke skjer?

Beskrivelse av de fire rollene en prosjektleder har, hentet fra Laufer et al-artikkelen. De fire rollene er: utvikle samarbeidet, integrer planlegging og review med læring, forebygg store forstyrrelser, hold oppe farten og momentet.
De fire rollene til en prosjektleder, Laufer, Hoffman, Russel & Cameron, 2015

Når det er sagt så ble jeg påmint et annet problem med prosjektledere i den samme artikkelen:

In fact, a recent study indicates that project managers submit biased reports as often as 60 percent of the time.

Og det problemet må man også ta tak i. Men, jeg vil tro at i veldig mange av tilfellene så er dette ikke et problem med at prosjektlederen ikke vet hva som foregår. Heller så handler dette om at det finnes et omland rundt prosjektlederen av kravstillere som insisterer på at alle prosjekter skal kjøres etter jerntriangelet — uansett hvor lav forutsigbarhet det er i innholdet, intern kontekst eller ekstern kontekst. Dermed tvinger man prosjektledere til å påstå ting som det ikke er mulig å forutsi.

Som f.eks. når noe skal være ferdig. Hvor god er du selv på å vite hvor lang tid det vil ta deg å gjøre noe du ikke har gjort før? For eksempel: Hvor lang tid vil det ta deg å gå fra deg til der jeg bor? Det kommer an på. Først må du vite hvor jeg bor, så må du finne ut hvor langt unna det er. Til å hjelpe deg da har du kart. Når vi lager nye IT-løsninger så stiller vi ofte uten kart, og med en forventning om at vi skal lage noe som skal fungere for utrolig forskjellige mennesker — og helst skal fungere perfekt for alle sammen. Vi elsker utfordringene det gir, men innimellom blir vi sliten av å bli presset inn i en forventning om at vi skal kunne si når løsningen er ferdig, hvor mye den vil koste, og hva den skal inneholde.

Heldigvis er det flere som har innsett at Boonstra & Reezigt har rett; man må jobbe forskjellig og man må forvente forskjellig. Og som sagt: når man har prosjektledere som har skjønt det, så er det bare å si leve prosjektlederen!

Referanser

Boonstra A, Reezigt C (2019) Complexity-Predictability Project Diagnosis model Procedia Comput Sci 164:337–342 doi:https://doi.org/10.1016/j.procs.2019.12.191

What successful project managers do: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1058.1621&rep=rep1&type=pdf

Laufer et al-artikkelen er pensum i faget TPK4200 på NTNU der jeg er så heldig å få holde en gjesteforelesning i september.

I Kantega skaper vi de gode løsningene, de som forbedrer livene til hver av oss. Gjennom innovasjon og bærekraftig teknologi, og gjennom godt samspill. Det skjer mer da. Her på bloggen blir du kjent med flere sider av oss.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kristin Wulff

Kristin Wulff

Kantega, innovasjonsprosesser og ledelse.

More from Medium

The Mangle of Federalism

Are you a frequent traveller looking to save time packing? Mari Kondo has the solution.

Here’s why truly smart managers expand their impact by looking at the big picture

IT CONSULTING AND STAFFING RECRUITER SPOTLIGHT ON HOLLY SMITH, SR. TECHNICAL RECRUITER