Kommunikasjon inn, planlegging ut

Kommunikasjon inn, planlegging ut

KRONIKK: Hvilken av de to er nøkkelen til prosjektsuksess?

"Skjer 'a?" Det er nesten vanskelig å tenke tilbake på tiden før mobiltelefon. Tiden da man måtte planlegge "vi møtes ved kinoen klokken åtte, og dersom noe går galt, så møtes vi i stedet ved billettluka ni". Tiden da man måtte legge igjen en beskjed, eller låne en telefon for å ringe hjem for, ja nettopp, høre om noen hadde lagt igjen beskjed.

Normalen i dag er at man har en omtrentlig plan "og så ringes vi når vi er på vei til byen." Fordelen er at man kan tilpasse seg. "Jeg har hørt at Johannes feirer 35 år. Skal vi stikke innom i stedet for å gå på bar?" Og når ting går galt, kan man endre planer, i stedet for å måtte vente en halvtime på de andre.

Dette er et eksempel på hvordan kommunikasjon erstatter planlegging. Slik kan det også være i prosjekter. Hvis man er enige om hva målet med prosjektet er og kommuniserer hyppig, så kan detaljene komme underveis.

Kommunikasjon

Hvor viktig er egentlig kommunikasjon på prosjekter? For å svare på dette spørsmålet, publiserte Kjetil Moløkken-Østvold og Kristian Marius Furulund i 2007 et forskningstudie av 18 sammenlignbare prosjekter. Resultatet viste at prosjekter med daglig kommunikasjon med kunden hadde cirka 10% avvik fra sine budsjetter, mens prosjekter uten daglig kommunikasjon hadde nesten 60% avvik.

Effekten av kommunikasjon på prosjekter er virkelig. Hvordan kan så denne kommunikasjonen foregå i det daglige?

"Sitt-ned-møte"

Mange bruker "daglige stå-opp møter" i Scrum. Teamet står rundt tavla og koordinerer utførte, pågående og kommende oppgaver sammen med kunden. En blogpost inspirerte prosjektet mitt til å utvide stå-opp møtet med et "nesten daglig sitt-ned møte" når det er hensiktsmessig. Etter stå-opp møtet sitter kunden og utviklerne sammen og går gjennom detaljene:

  • Kunden har med seg en liste med forbedringer fra tidligere funksjoner. Enkle forbedringer retter utvikleren der og da. Litt større oppgaver noterer utvikleren seg for å gjøre i løpet av dagen. Store oppgaver blir tatt inn i fremtidige planer.
  • Utvikleren viser kunden de tingene som var ferdige i går. Kunden kommer med direkte feedback der og da, og noterer seg hva han skal se gjennom på egen hånd.
  • Kunden går gjennom detaljene for funksjonalitet som utvikleren skal starte på og besvarer spørsmål.

Felles mål

"Measure twice, cut once" er det noen som sier. Men på utviklingsprosjekter er det ikke sikkert at det å beskrive noe grundig forbedrer sjansene for å lykkes. De eneste gangene jeg har opplevd at en kunde ikke kommer med ytterligere tilbakemelding første gang hun ser produktet er når jeg har en kunde som egentlig ikke bryr seg. Eller når jeg har brukt alt for lang tid på å dekke alle eventualiteter, inkludert de som ikke var viktige.

I et vellykket prosjekt vil prøving, visning og tilpasning være normalen. Jo tidligere prosjektet får tilbakemeldingene, desto bedre og billigere blir prosjektet. Og jo mer detaljerte planer vi legger i prosjektet, desto vanskeligere blir det å tilpasse seg tilbakemeldingene.

Felles mål, daglig kontakt, daglig tilbakemelding og daglig tilpasning kan være oppskriften som gjør prosjektet ditt til en suksess.

("Fagtanken" gir fagfolk og foredragsholdere anledning å skrive i Computerworld It-karriere om sine tanker rundt trender og utviklinger)

Les om: