Unngå kaos i prosjektet: Et oppgjør med e-post og gule lapper

Når oppgavebehandlingen følges opp på epost kan det potensielt føre til kaos. Spesialiserte verktøy for oppgavehåndtering er nøkkelen om du skal få fullstendig oversikt over prosjektet.

En viktig del av et prosjekt er å sikre at alle har relevant og oppdatert informasjon knyttet til arbeidsoppgaver og status. Strukturert saksoppfølging gir bedre oversikt, noe som igjen gir prosjektene gevinster både på kort og lengre sikt.

Dessverre ser vi ofte at prosesser knyttet til prosjektoppgaver i de fleste virksomheter fremdeles håndteres ved hjelp av epost, der informasjon knyttet til en sak er et produkt av mange forskjellige eposter og møtereferater som har gått til forskjellige personer. Det er vanskelig å skille mellom hvem som har sagt hva, tenkt noe og besluttet et eller annet. Den som faktisk skal løse saken sitter med mangelfull informasjon og det er usikkert hvem som har ansvar for hvilke aktiviteter. For prosjektleder er det vanskelig å ha oversikt over hvem som jobber med saken og hva som er status. Det er vanskelig å få oversikt over antall saker og det totale arbeidsomfanget av alle saker i prosjektet, eller hvor mye tid som har medgått til å løse de enkelte sakene.

Det er som regel prosjektleder som har ansvar å skape orden i kaoset. Ved hjelp av Excel-lister og spesifikke epost-adresser for blant annet melding av feil, kommer man et stykke på vei, men dessverre krever dette ofte svært stor innsats og jo større prosjektet er, jo mindre heldig blir nesten alltid resultatet.

Dette innlegget er derfor et oppgjør med bruken av epost, gule lapper, regneark og møtereferater til oppfølging av prosjektoppgaver. I stedet bør man bruke tilpassede verktøy. Spesielt for software-prosjekter og service management-funksjoner har slike verktøy vært benyttet i en årrekke. HP Quality Center, Microsoft TFS og Jira er alle kjente eksempler. Det har imidlertid vært knyttet betydelige økonomiske investeringer til oppstart av disse systemene: Innkjøp av programvarelisenser og maskiner, modellering av prosesser og konfigurering av system, samt opplæring av brukere for å nevne noe.

Les også: Prosjektledelse: Ingen plan, ingen prosjektkontroll

Jira som eksempel

I Sopra Steria har vi i mange systemutviklingsprosjekter benyttet systemene over med stort hell. For eksempel er Jira et system som kan kjøres i skyen, til en forholdsvis lav kost og rask oppstart. Eventuelt kan systemet lisensieres for å kjøre på virksomhetens egne maskiner. For enkelthetens skyld vil dette innlegget ta for seg oppgavehåndtering på dette systemet.

Jira er relativt enkelt å ta i bruk, samtidig som det er rikt på funksjonalitet som kan benyttes etter hvert som kompetanse og behov utvikler seg. Kjernen i Jira er oppgaver eller saker. Disse kan være av forskjellige typer som for eksempel brukerhistorie, oppgave eller bug. Hver av disse oppgavetypene har en rekke felt som kan benyttes til å legge inn informasjon, overføre ansvar for oppgaven, eller endre status. Gevinsten består i at all informasjon knyttet til en sak er samlet på et sted, historikken på alle saker er lett tilgjengelig og hvem som har ansvar for neste steg er klart. Det er også enkelt å få oversikt over alle saker og ta ut oppfølgingslister som for eksempel antall ferdigstilte brukerhistorier, ikke påbegynte brukerhistorier eller brukerhistorier som er klare for test.

Dashboard som inneholder relevante rapporter kan skreddersys til den enkeltes behov, arbeidsprosesser og saksflyt kan automatiseres underveis og integrasjon med kildekodesystemer kan settes opp. Har virksomheten behov for funksjonalitet som ikke er implementert i Jira, kan plug-ins anskaffes for å løse spesifikke problemstillinger. Jira har et åpent API for integrasjon mot andre systemer.

Et typisk implementeringsløp kan være et prosjekt som starter med at alle feil legges inn og følges opp gjennom systemet, og allerede her er forretningsgevinsten opplagt. Prosjektet får oversikt over antall feil og hvor de er i løypa, i tillegg blir all informasjon om saken og kommentarer til denne knyttet til saken i Jira. Prosjektet unngår dermed lange og uoversiktlige epost-tråder. Neste steg kan være at alle brukerhistorier med tilhørende utviklingsoppgaver registreres. Alle har dermed god oversikt over hvem som jobber med hva og det er enkelt å følge opp fremdrift i prosjektet.

Les også: Prosjektledelse: Har du CTRL i digitaliseringsprosjektene?

Digitale kanban- og scrum-tavler

Samme informasjon bør ikke legges mer enn ett sted. Derfor bør de som i dag benytter scrum eller kanban avskaffe den fysiske tavlen med gule lapper, og heller anskaffe en flatskjerm som viser respektive tavler direkte fra oppgaveverktøyet. I Jira er både kanban- og scrum-tavler ferdig definert, og oppgaver kan dra og slippes fra et tavleområde til et annet. Status på saken blir da oppdatert i henhold til område på tavlen der saken slippes og man får dermed samme layout som på en «manuell» tavle. Gule lapper er jo heller ikke særlig effektivt når informasjon skal aggregeres. For eksempel vil en oppdatert oversikt i oppgaveverktøyet raskt gi oversikt over hvor mange oppgaver som er løst og hvordan prosjektet ligger an i forhold til planer og estimater. Da slipper prosjektleder å telle lapper og summere estimater på hver enkelt lapp.

Etter hvert som virksomheten og prosjektene blir bedre kjent med oppgaveverktøyet vil bruksområdet raskt kunne utvides. Hvorfor begrense oppgavetyper i Jira til test, bugs og utviklingsoppgaver? Hvorfor ikke benytte Jira til designoppgaver? Eller du kan registrere risiko som oppgaver og knytte tiltakene opp mot risiko som deloppgaver.

Vi har sett på hvordan oppgaveoppfølging ved bruk at eposter og møtereferater ikke gir nødvendig oversikt over hverken enkeltsaker eller total oversikt i prosjektene. Heldigvis er verktøyene som forbedrer situasjonen nå godt modne og tatt i bruk i mange prosjekter. Lever din virksomhet eller prosjekt fremdeles i en verden der oppfølging av oppgaver skjer på epost og regneark, er tiden moden for å ta skrittet til en bedre kontroll med moderne oppgaveverktøy. Terskelen for å komme i gang er lav, og begynner dere først med en enkel prosess er det enkelt å utvide bruken etter hvert.

Dette innlegget var først på trykk i Ukeavisen ledelse/Dagens perspektiv 15. mai 2017

 

Andreas Haavaldsen er ansatt som senior prosjektleder i Sopra Steria. Han har mer en 25 års erfaring fra IT-bransjen med fokus på ledelse av større prosjekter fra både kunde og leverandørsiden.

6 kommentarer om “Unngå kaos i prosjektet: Et oppgjør med e-post og gule lapper

  1. Uff – ikke alltid. De mest kaotiske prosjektene jeg har vært på har vært Jira-sekter. Og de med best kommunikasjon, innsikt og oversikt har vært dominerer av fysisk tavle. Etter Jira-overdose på et par prosjekter er jeg klar til å melde jeg meg ut av den kjerka.

  2. Hei Johannes
    Hyggelig at du tok deg tid til å lese bloggen og dele dine erfaringer. En fysisk tavle er nyttig å samles rundt og gir god oversikt der og da, men det blir fort til at det som står på lappene også må oppføres andre steder og så blir det biter med delvis overlappende informasjon som lever hver sine liv. Mitt poeng er at dette fører til kaos og derfor bør erstattes av et oppgavesystem.Hvorfor ikke spandere en stor skjerm for å vise innhold fra f.eks Jira som teamet kan samles rundt i «stå opp» møter, dermed får vi både det fysiske samlingsstedet og konsistent informasjon.

    Når det er sagt bør selvfølgelig ikke bruk av Jira erstatte at mennesker snakker sammen og nårJira diskusjonene blir lange bør nok noen de involverte samles til diskusjon og avklaring.

  3. Det første man må huske er at issues er arbeidsdokumenter – når prosjektet er ferdig er de verdiløse. Et verktøy som lurer folk til å investere ekstra i midlertidig informasjon er farlig. Det andre man må huske er at den fysiske handlingen med å holde, flytte, gi til noe eller flytte et kort mens man står rundt en tavle føler til en veldig annen dynamikk enn der hvor alle sitter henslengt rundt et bord mens teamleder oppdaterer Jira. Eller der teamleder noterer seg hva som skal gjøres ved stand-up møtet og tar det med seg tilbake til pulten.

    Dersom vi ikke samhandler når vi samles, så er det egentlig bedre om prosjektleder sitter i et hjørne og koser seg med Jira uten å involvere meg.

    Når det gjelder Jira er det et spesielt dårlig verktøy. Med en gang man pirker i det ser man at det er egentlig en bugtracker med en modell som var moderne på nittitallet. All prosjektstyringsfunksjonaliteten er hacks som prøver å tvinge et prosjekt, sprint og kanban-bilde på en datamodell som ikke var laget for det. Det synes.

  4. Om Jira er det beste verktøyet til dette kan sikkert diskuteres. Jeg støtter imidlertid fullt argumentet om at det er til stor hjelp for prosjektleder å ha et system som gir en samlet oversikt over de enkelte oppgavene, ansvarlig og status på disse. Jeg mener også at man bør gå bort fra å bruke e-post til å «raskt foreta» avklaringer som gjelder oppgaver, spesifikasjoner, avsjekk e.l. Av egen erfaring kan det føre til mye rot, og det blir vanskelig å finne tilbake til avklaringer som er gjort, hva man har blitt enig om osv. Også mener jeg at man bør bestemme seg for ETT system som brukes, ellers er det fort gjort at informasjon flyter rundt på ulike steder, og igjen gjør det vanskelig for prosjektleder å finne frem til riktig status.
    Johannes, har du kanskje et godt alternativ til Jira som du kunne anbefale?

Legg inn en kommentar