Slik leverer ProsessPilotene prosjekter. Metodikken, rollene og sjekklistene som sikrer rett leveranse, til rett tid og kvalitet, i alle prosjekter.
De beste prosjektene skapes når kunde og leverandør samarbeider godt og finner utfyllende roller i ett leveranseteam. Denne håndboken viser hvordan ProsessPilotene legger til rette for akkurat det — fra første forespørsel til overlevert løsning.
Siden oppsummerer prosjekthåndboken for kunder og ansatte. Er du kunde, gir den deg innsikt i hva du kan forvente av oss — og hva vi kommer til å forvente av deg.
Prosjektkontoret (PMO) eier leveransemetodikken og har det overordnede leveranseansvaret for alle prosjekter ProsessPilotene påtar seg.
Gode leveranser er definert av ProsessPilotenes kvalitetssystem: rett leveranse, til rett tid og kvalitet. For å sikre dette har ledergruppen etablert et prosjektkontor — Project Management Office — som samler alle regler og metoder ProsessPilotene jobber etter i prosjekthåndboken.
Prosjektkontoret ledes av en prosjektdirektør og er en faggruppe som trekker på prosjektledere på tvers av organisasjonen. Håndboken revideres fortløpende etter innspill fra kunder og ansatte, og alle endringer godkjennes formelt av ledergruppen.
Prosjekthåndboken er offentlig og deles gjerne med kunder — den er ProsessPilotenes eiendom, og denne siden presenterer innholdet i kortform.
Styrke faget prosjektledelse i ProsessPilotene
Etablere lik metodikk og arbeidsmåte i alle leveranser
Sikre kvalitet, fremdrift og kontroll i alle prosjekter
Risikostyre den totale prosjektporteføljen
Samordne rapportering av nøkkeltall fra alle prosjekter
Muliggjøre vekst og større prosjekter
Fire faser fra forespørsel til forvaltning. Prosjektprosessen overtar der salgsprosessen slutter, og avsluttes der forvaltningen tar over.
Prosesseier: Leder av salgsavdelingen
Salgsprosessen skaper prosjektgrunnlaget: en arbeidspakke som beskriver prosjektet, og for større leveranser også en overordnet løsningsbeskrivelse og et veikart. Målet er et grunnlag som er forstått av både kunden og de som skal levere.
Fasen er fullført når
Signert arbeidspakke og godkjent prosjektplan. Ansvaret overføres fra KAM til prosjektleder.
Registrere og kvalifisere forespørselen
Utarbeide arbeidspakken — bakgrunn, målsetning og verdiskapning
Detaljert leveranseliste med estimater
Rådgivning om arkitektur, test- og opplæringsstrategi
Prosjektering: WBS, RBS og tidsplan
Forankre plan og økonomiske rammer, signere arbeidspakken
Soft booking som blir hard booking av ressurser ved godkjenning
Prosesseier: Prosjektleder
Initieringen forankrer prosjektet hos alle deltakere. Fasen tar gjerne fire uker — og det er vel anvendt tid: grunnlaget som legges her avgjør hvor effektiv gjennomføringen blir.
Fasen er fullført når
Alle vet hvorfor prosjektet finnes, hva som skal leveres og hvilken rolle de har. Godkjenning i prosjekt- eller styringsgruppen starter gjennomføringen.
Allokere og mobilisere ressurser med tydelige roller og omfang
Gjennomgå arbeidspakke, plan, strategier og estimater — fange feil tidlig
Etablere strategier for informasjonsarkitektur, integrasjoner, test, datamigrering og opplæring
Sette opp Azure DevOps: WBS, brukerhistorier, testplan og opplæringsoppgaver
Planlegge første sprint i detalj og forberede kickoff
Gjennomføre kickoff — synliggjør prosjektets gevinst for kunden
Etablere møteplan, administrative rutiner og utviklingsmiljø
Prosesseier: Prosjektleder
Gjennomføringen leverer på arbeidspakken. ProsessPilotene bruker Prince2 Agile for agile prosjekter og Prince2 for fossefall. Alt arbeid dokumenteres i Azure DevOps, og timer føres via 7Pace.
Fasen er fullført når
En leveranse i samsvar med kravene i DevOps. Status følges med trafikklys-KPIer for fremdrift, omfang, tid, ressurser, risiko, økonomi og målsetning.
Planlegge: definere og estimere oppgaver i DevOps
Designe: spesifikasjon, prosessbeskrivelser og UX i WIKI
Utvikle løsningen i samsvar med krav i DevOps
Teste egne leveranser og kundens akseptansetester
Rulle ut: demonstrere, produksjonssette og lære opp
Evaluere hver sprint med retrospektiv
Prosesseier: Prosjektleder
Avslutningen lukker prosjektet kontrollert: leveransene godkjennes, erfaringene samles, og eierskapet overføres til forvaltning.
Fasen er fullført når
Styringsgruppen lukker prosjektet formelt, forvaltningsteamet overtar eierskapet, og kunden fortsetter dialogen med sin KAM.
Utarbeide sluttrapport og økonomistatus
Oppdatere liste over kjente feil, problemer og risiko
Revidere backlog med forslag til forbedringer for kunden
Demonstrere resultatet for styringsgruppen
Retrospektiv med prosjektgruppen og prosjektevaluering med kunden
Formelt lukke prosjektet i styringsgruppemøte
Overlevere til forvaltning og demobilisere ressurser
I agile prosjekter deles gjennomføringen opp i sprinter som følger et fast mønster: planlegge, designe, utvikle, teste, rulle ut — og evaluere før neste runde. Kunden bidrar med behov og ønsker direkte i DevOps, og hver sprint avsluttes med et retrospektiv.
Håndbokens viktigste verktøy i praksis: sjekklistene for planlegging, gjennomføring, avslutning og evaluering.
Planlegging
Alle forstår hvorfor prosjektet finnes og hva som er ønsket levert
Alle forstår sin rolle, sin leveranseplan og hva som er «out of scope»
Alle vet hvilke forventninger de kan stille til hverandre
Samhandling er avklart — kommunikasjon, dokumentasjon og bruk av DevOps
Strategier for test, opplæring, integrasjoner og informasjonsarkitektur er forankret
Tilgang til møterom, tekniske miljø, lisenser og passord er avklart
Møteplan og kalender er etablert
Prosjektplanen er forstått og sprintplan for første sprint er satt opp
Gjennomføring
Alle oppgaver dokumenteres i DevOps med presis tittel, kategori og estimat
Status, gjenstående og utført tid oppdateres fortløpende på egne oppgaver
Timer føres hver uke i Xledger — og i 7Pace når prosjektleder ber om det
Avvik over 10 % fra estimat varsles til prosjektleder
Avvik, bekymringer, problemer og risiko varsles — proaktivt, direkte og åpent
Egne leveranser enhetstestes og dokumenteres før overlevering
Innsjekket kode knyttes alltid til oppgaven i DevOps
Sprintene følger rutinene: sprintplanlegging, standups, prosjektgruppe- og styringsgruppemøter
Avslutning
Sluttrapport i samsvar med kravene i arbeidspakken
Økonomirapport med sluttstatus for prosjektet
Oppdatert liste over kjente feil og mangler
Oppdatert problemliste og risikomatrise
Revidert backlog i DevOps med anbefalinger til kunden
Evaluering fra prosjektgruppen og fra kunden
Demonstrasjon gjennomført for styringsgruppen
Overlevering til forvaltning er avtalt og gjennomført
Evaluering
Hva gikk bra i sprinten — og hva gjorde vi annerledes for å oppnå det?
Hva gikk ikke etter planen — uten å lete etter syndebukker?
Hva lærte vi som kan forbedre måten vi jobber på?
Hvilke konkrete forbedringer tar vi med inn i neste sprint?
Er definisjonen av «ferdig» fortsatt riktig for teamet?
Ved prosjektslutt: kunnskapen deles fra prosjektgruppen til hele ProsessPilotene
Rutine
Hva fikk jeg til siden sist?
Hva skal jeg gjøre nå?
Hvilke hindringer står i veien for fremdriften min?
Alt av oppdateringer fra møtet tilbakeføres til DevOps
Gjennomføring
Utvikling av en Dynamics 365-applikasjon
Utvikling av en nettside
Utvikling av en integrasjon
Utvikling av et web-API
Utvikling av et datavarehus
Tilhørende prosedyrer: estimering, endringer, problemer, workshopledelse og produksjonssetting
Sjekklistene forteller deg HVA som skal gjøres — veiledningene under viser deg HVORDAN, steg for steg.
Åtte definerte roller med tydelig mandat og ansvar. Sammensetningen varierer fra prosjekt til prosjekt, men nøkkelrollene skal alltid besettes.
Felles for alle roller
Uavhengig av rolle ventes det at du definerer og leverer på egne oppgaver med rett kvalitet, holder DevOps oppdatert, fører timer hver uke, varsler ved avvik over 10 % fra estimat — og er proaktiv, direkte, åpen, ærlig og forberedt.
ProsessPilotenes selger og kundens rådgiver, med totalt kundeeierskap på tvers av aktive prosjekter og løpende forvaltning.
Øverste ansvarlig og endelig beslutningstaker i et prosjekt eller en prosjektportefølje. I ProsessPilotene normalt samme person som KAM.
Har den daglige ledelsen av prosjektet og skal sikre avtalte leveranser til avtalt kvalitet, innenfor tids- og kostnadsrammene.
Rådgiver for de store linjene: informasjons-, applikasjons- og teknologistøtte, med TOGAF-rammeverket som grunnlag.
Eier løsningsarkitekturen og har det operative ansvaret for hva som leveres — der prosjektleder eier når det leveres.
Sikrer at løsningen har rett kvalitet i henhold til kravspesifikasjoner og avtaler. Egen rolle i store prosjekter og prosjekter med høy risiko.
Ansvarlig for brukeradopsjon: forankrer strategien hos kundens ledere, lager opplæringsplan og gjennomfører opplæringen.
Tilpasser løsningen til kundens krav — funksjonelt (Dynamics 365), teknisk (programmering) eller analytisk (innsikt, rapportering og datavarehus).
ProsessPilotene behersker flere metodikker — prosjektkontorets råd avgjør hvilken som passer leveransen.
Foretrukket metodikk i de fleste leveranser — tilpasses hver enkelt kunde og hvert prosjekt.
Foretrukket for support- og forvaltningsoppgaver, der arbeidet styres etter kapasitet og flyt.
Egner seg best når programvare skal skapes fra bunnen, eller et team jobber uten fast prosjektledelse.
Kan benyttes for små prosjekter med klar kravspesifikasjon og lav usikkerhet.
For kunder med flere parallelle prosjekter og leverandører baserer ProsessPilotene porteføljeledelsen på SAFe (Scaled Agile Framework), med styringsgruppe, prosjektgruppe og arbeidsgrupper på strategisk, taktisk og teamnivå.
Felles språk gir felles forventninger — de viktigste begrepene, og standardsatsene som gjør estimater og budsjetter forutsigbare.
Kontraktsdokumentet som definerer prosjektet: omfang, kostnad, risiko, kvalitet og leveranser. Overgangen fra salg til prosjekt skjer når arbeidspakken er signert.
Work Breakdown Structure — den hierarkiske oppdelingen av leveransen. ProsessPilotene bruker fire faste nivåer, som i DevOps tilsvarer Epic, Feature, brukerhistorie og oppgave.
Ressursnedbrytningsstrukturen definerer hvilke roller prosjektet trenger, avklarer rapporteringslinjer og danner grunnlaget for hvem som eier hva i DevOps.
En avgrenset tidsperiode med egen leveranseliste, ressursallokering og økonomisk ramme. I ProsessPilotene følger en sprint normalt kalendermåneden.
En oppgave er ferdig når kravene er innfridd og enhetstesting er bestått. En brukerhistorie, Feature eller Epic er ferdig når alt under er lukket, testet og dokumentert med release notes — ProsessPilotene setter «Resolved», kunden setter «Ferdig».
Grafisk fremstilling av alle leveranser til en kunde på én side, med tidslinjer, estimater og status. Vedlikeholdes fra faktiske data i DevOps.
Testarbeidet følger ISO/IEC 29119 med spesifikasjonsbaserte, strukturbaserte og erfaringsbaserte strategier. Målet er at 80 % av leveransene testes maskinelt, slik at gjentatt testing går automatisk for hver ny versjon.
ETC er gjenstående tid, EAC er utført pluss gjenstående. Når EAC overstiger estimert arbeid, varsler det budsjettsprekk — derfor skal gjenstående tid alltid holdes oppdatert i DevOps, av alle, uten unntak.
Epic
Feature
Brukerhistorie
Oppgave
Arbeidsmøter og administrasjon
30 %
Testing
20 %
Dokumentasjon
5 %
Bistand UAT
5 %
Produksjonssetting
3 %
Risikopåslag på summen
10 %
Eksempel fra håndboken
En leveranse med 1 200 timer ren konsulenttid får standardsatser som løfter den til om lag 1 944 timer. Med 10 % risikopåslag ender budsjettet på rundt 2 138 timer.
Standardiserte maler gjør hvert prosjekt gjenkjennelig — fra arbeidspakken som åpner prosjektet til sluttrapporten som lukker det.
Porteføljestyring
Veikart (roadmap)
Styringsgruppemal
Økonomirapport
Prosjektstyring
Arbeidspakke
Prosjektplan
Overordnet løsningsbeskrivelse
Testpolicy
Risikomatrise
Prosjektavslutning
Prosjektarbeid
Kickoff-presentasjon
Brukerhistorie-mal
Opplæringsplan
Mal
Bakgrunn — hva, hvor og hvorfor problemene finnes
Målsetning
Antatt verdiskapning
De viktigste leveransene med estimater
Beskrivelse av brukeropplevelser
Overordnet tidslinje og baseline
Økonomiske rammer
Antakelser og grensesnitt
Administrative rutiner og metodikk
Toleransegrenser og godkjenningsmetode
Signering ved oppstart og godkjent leveranse
Suksess måles ikke i produksjonssetting, men i at brukerne faktisk tar løsningen i bruk. Derfor forankres opplæringsstrategien hos kundens ledelse fra start.
Kundens superbrukere læres opp av ProsessPilotene, og trener deretter sine egne kolleger. Skalerer godt og bygger internt eierskap.
Dokumentasjonen gjøres om til e-læring som gjennomføres før kursdagen, slik at klasserommet kan brukes til øvelse i stedet for gjennomgang. Anbefalt tilnærming i håndboken.
Rundt 10 deltakere per kurs, i bolker på 45 minutter: introduksjon, teori, demonstrasjon, praktiske oppgaver og gjennomgang.
Kurs og veiledninger i eget tempo, med oppfølging og brukerstøtte tilgjengelig i etterkant.
Kunden sikrer at ansatte forstår effekten løsningen har for den enkelte og for bedriften — før opplæringen starter.
Gjennomføres slik det gir best effekt for målgruppen — «blended learning», en kombinasjon av e-læring og klasserom, anbefales.
Den viktigste delen: øve med realistiske arbeidsoppgaver, planlagte oppfølgingsaktiviteter og tilgjengelig brukerstøtte.
Kompetansesidene samler kursene, veiledningene og materiellet som støtter opplæringsstrategien over — for kunder og ansatte.