Jeg har nettopp lest bøkene The Goal: A process of ongoing improvement” av Eliyahu M. Goldratt og The Phoenix Project” av Gene King og Kevin Behr. Begge bøkene anbefales på det varmeste. The Phoenix Project bygger på grunnlaget som legges i The Goal og bøkene bør leses i rekkefølge.

Bøkene er i romanform og beskriver ledere som sliter med lønnsomheten i henholdsvis en fabrikk (The Goal) og et firma som er helt avhengig av IT (The Phoenix Project). Bøkene følger lederne på reisen der de sakte men sikkert lærer å snu motgang til medgang. Det er nettopp reisen og hvordan hovedpersonene lærer underveis, og tilslutt innser hva som gjør at man kan lykkes, som ga meg de store a-ha opplevelsene.

Jeg vil løfte frem ett av hovedpoengene fra The Phoenix Project.

Ifølge The Phoenix Project finnes det 4 typer arbeid i IT prosjekter.

  • Forretningsprosjekter - Prosjekter som leverer verdi for forretningen.
  • Interne IT-prosjekter - Infrastruktur og tekniske prosjekter som muliggjør en god gjennomføring av forretningsprosjekter. Eksempelvis støtte av automatisk bygg, testing og utrulling.
  • Endringer - Endringer, feilrettinger og forbedringer til de to foregående prosjekttypene.
  • Ikke-planlagt arbeid - Alt arbeid som ikke er planlagt. Eksempelvis hendelser i produksjon og manuelle rettelser basert på følgefeil.

De tre første typer arbeid faller i kategorien “planlagt arbeid”. Den siste typen arbeid som ikke er planlagt, fører ofte til forsinkelser og følelsen av man ikke er i stand til å planlegge og gjør at man mister kontroll.

Det er viktig å ha et bevisst forhold til ikke-planlagt arbeid, og særlig hvor stor andel av totalt arbeid det utgjør. Siden det tross alt er arbeid som ikke er planlagt faller det ofte utenfor verktøyene man planlegger prosjektene i og måler prosjektene med. For å ha forutsigbarhet trenger man også å vite hvor mye tid som til enhver tid går til ikke-planlagt arbeid. Her er noe av det man burde ha oversikt over:

  • Hvor mye tid går til ikke-planlagt arbeid totalt?
  • Hvem er det som utfører dette arbeidet?
    Blir det utført av nøkkelressurser som dermed blir flaskehalser for utføring av annet planlagt arbeid?
  • Er alt dette arbeidet nødvendig?
    Om arbeidet ikke er nødvendig, hvorfor blir det utført?
    Kanskje det er noen i organisasjonen som hopper bukk over etablerte rutiner for å få gjennomført en viss type arbeid?
  • Om det er nødvendig, kan man automatisere arbeidet?
    Da vil det falle inn under kategorien IT-prosjekt og kan planlegges.

Man kan umulig få kontroll på planene sine hvis man ikke vet hvor mye kapasitet som lekker ut i ikke-planlagt arbeid. Ved å måle hvor mye ikke-planlagt arbeid som blir gjort kan denne type arbeid kvantifiseres og identifiseres, m.a.o. kartlegges. Da kan man jobbe målrettet med å kvitte seg med det som ikke er verdiskapende og gjøre en kost nytte vurdering rundt hva som bør automatiseres. En tendens jeg har opplevd i flere av de prosjektene jeg har deltatt er at det sakte men sikkert går utover alt planlagt arbeid. Over tid blir det så mye av det at alt planlagt arbeid stopper opp.

Hvordan manifesterer dette seg?

Fra et forretningsperspektiv ser man at leveranser blir forsinket. Dette forverrer seg gjerne over tid.

Fra et ledelsesperspektiv ser det ut som at IT ikke klarer å levere i henhold til plan. Dette gjør tilliten tynnslitt. Noe som kan resultere i at man kompenserer ved å innføre kontrollrutiner som skaper mer arbeid. En lite hyggelig spiral å være i!

Fra et IT perspektiv ser man at teknisk gjeld ikke nedbetales. Flere og flere behov som kommer fra forretning blir gjennomført med suboptimale løsninger, såkalte “shortcuts”. Man ender opp med å ta snarveier fordi det ikke er tid til å gjennomføre nødvendige designendringer ved nye leveranser. Eller man er blitt så vant til å ta snarveier at man ikke reagerer lengre. Mengden ikke-planlagt arbeid blir dermed større. På et eller annet tidspunkt må man betale renters rente.

Jo lengre man følger denne praksisen, jo verre blir det. Etterhvert som man får gjort mindre og mindre av det man planlegger, bygger backloggen over ønsket funksjonalitet seg opp. Når planlagt arbeid blir liggende gradvis lengre og lengre i backloggen vil planleggingsarbeidet bli gradvis mindre og mindre relevant, noe jeg har  skrevet om tidligere.

Hvordan kan man forebygge dette?

Det første man trenger er en bevisstgjøring på tvers av organisasjonen om at ikke-planlagt arbeid er et problem. Så må man forstå omfanget og jobbe systematisk med å eliminere denne typen arbeid. Arbeid som er nødvendig må enten automatiseres eller legges til i planene slik at man kan få bedre forutsigbarhet med tanke på fremtidige leveranser. Det som ikke er nødvendig må elimineres.

Om du synes dette er relevant så anbefaler jeg deg å lære enda mer om denne problemstillingen ved å lese bøkene The Goal: A process of ongoing improvement” av Eliyahu M. Goldratt og The Phoenix Project” av Gene King og Kevin Behr jeg nevnte innledningsvis.