Prosjektledelse – teori og praksis

Hvordan blir du en virkelig god prosjektleder?

Dagens prosjektlederkurs kan lære deg mye – men ikke det du faktisk har mest bruk for når du skal kjøre et prosjekt.

Systeks prosjektledere har meget lang erfaring som ledere for både store og komplekse IT/telecom prosjekter og kan gi deg det du trenger for å lykkes. Med Scrum og agile metoder så har vi i dag langt større kontroll over prosjektene enn for kun noen år siden, men samtidig tror vi at man må kunne mer enn formelle metoder for å sikre suksess. Det finnes en del viktige områder en prosjektleder må mestre. Merk at dette ikke er triks du kan lære deg på 10 minutter, dette krever hardt arbeid. Her er noen metoder:

  • Å starte prosjektene med riktig utgangspunkt: Altfor mange prosjektledere tar på seg prosjekter uten å få satt krav til omverdenen. Sørg for at du har rammene rundt deg i orden før du starter. Det kan være urealistiske forventinger til produktet, at du ikke får prioritering- men må klare tidplanen etc. Med andre ord: Før du tar på deg et prosjekt må du si noe lignende dette: «Jeg kjører dette prosjektet kun hvis jeg får disse ressursene, kan holde på i X måneder og kunden skriver under kravspesifikasjonen slik at alle vet hva vi lager».
  • Å velge riktige mennesker: Få tak i de riktige personene, og jobb mye med å få riktige team. Når teamene er oppe og kjører er det prosjektlederens oppgave å få teamene til å holde farten oppe og rydde unna forhindringer.
  • Å ha god magefølelse og gode kommunikasjonsevner: En dyktig prosjektleder kan føle på kroppen når et prosjekt går bra eller ikke – men dette krever både mye erfaring og at prosjektlederen snakker nok med sine team – og sine kunder. Og det gjelder å se de store linjene: Det hjelper ikke å bomme med kun 2% på budsjettet hvis produktet ikke kan brukes, eller hvis plattformen to uker før leveranse viser seg å ha for lav ytelse.
  • Å bruke den gylne middelvei for metodikk og formaliteter: I store organisasjoner er det lett å gå i «dokumentasjons-fellen». Bruker du mer tid på å diskutere en mal enn innholdet, er du i faresonen. Tilsvarende for små team og bedrifter hvor kun koden står i sentrum, og man etter en stund ikke vet hvordan designen ble til, eller hvor mye som er testet.

Og husk alltid at utviklingsprosessen er til for prosjektet og ikke omvendt!