Bestillingsbeskrivelse
Introduksjon
Dette er et samkjøringsverktøy, ikke en prosjektplan. Som et samkjøringsverktøy for leveranser, prioritering og avhengigheter, er det ikke bindenende for time- eller kostnadsestimater.
Det kan dukke opp ting som endrer ressursestimatet, avhengighetene og fristene, og da skal rutinen være å oppdatere bestillingsbeskrivelsen slik at man fortsetter å være samkjørt og eventuelt tar en ny godkjennelsesvurdering.
Utfyltle bestillingsbeskrivelser
På disse sidene (lesebegrenset) finner du aktuelle og tidligere bestillingsbeskrivelser:
Mal for bestillingsbeskrivelse
Bestilling [Tittel]
- Roller
- Tjenesteeier (produkteier):
- Mottaksansvarlig:
- IT-leder (Utviklingseier):
- Utviklingsansvarlig (utviklingskoordinator):
- Oppgavebeskrivelse
- Overordnet UiO mål (Effektmål / Gevinstmål som denne leveransen er delaktig i)
- Viktighet: 1-4 (1 er høyest, følger nytteverdien og hastegraden til det overordnede målet)
- Leveranse: Deskriptiv for omfanget av denne bestillingslappen.
- Delleveranser: Mål man kan rapportere fullføring på underveis. SMARTe mål om mulig (specific, measurable, attaniable, relevant og timely) Utgangspunkt for ressursestimatet.
- Forutsetninger og avhengigheter for gjennomføring: Arbeid utenom ressursestimatet (F.eks tjenesteier må skaffe en spesifikk lisens for at utviklingen kan begynne):
- Ressursestimat (ikke bindene):
- Utviklingskostnad (Timer og ny infrastruktur i IT-avdelingen som utviklingsansvarlig holder kontroll på. (F.eks 200t og 20knok for OKD-server)):
- Etableringskostnad (Eiers kost ved igangsettelse, som tjenesteier må avklare og holde styr på. (F.eks 30knok for lisens og etableringskost hos ekstern leverandør /avtalepartner)):
- Driftskostnader IT-avdelingen (IT-avdeling løpende kostnader i timer og infrastruktur, under Utviklingseiers ansvar):
- Driftskostnader for tjenesteier (estimerte løpende kostnader under eiers ansvar)
- Avtalt kostnadsføring (tjenestekategori og/eller kostnadspost for kostnader):
- Planlagte datoer:
- Forutsetninger og avhengigheter levert: Planlagt dato
- Dato for demo-løsning (opsjon): (Planlagt dato + arbeidstid til test)
- Leveransedato: (Planlagt dato + arbeidstid til leveranse).
- Godkjent: Ja/Nei + [Dato]
- Versjonsdato: [Versjon]+[Dato]
Veiledning:
Rollebeskrivelser
- Tjenesteeier (produkteier) [hos "kunde"]
- BDM – representant (håndterer enten kostnadsgodkjennelsen eller får den godkjent hos BDM / budsjettansvarlig)
- Oppover – representant for ledelsen.
- Tilgjengeliggjører ressurser for ibruktagelse og akseptansetesting
- Beslutter godkjennelse
- Gevinstrealisering ansvarlig, ved at leveransen taes i bruk og har en ansvarlig for aktivt eierskap videre (behovsavklaringer til videreutvikling, etc).
- Mottaksansvarlig [hos "kunde"]
- Helhetlig gjennomførende
- Deltar i arbeidsmøter, testing og utvikling
- Avklaringer og kommunikasjon mot egen organisjon
- Hovedkontaktpunkt mot utviklingsansvarlig
- Ansvarlig for mottak for å sikre ibruktagelse og fullføring
- Oppfølgende på at det er lagt til rette for gevinstrealisering med aktivt eierskap etter leveranse (behovsavklaringer til videreutvikling, etc).
- IT-leder (utviklingseier) [i IT-avdelingen]
- Gjennomfører fakturering mot kunde (f.eks EA)
- Ressursallokerer og forberedende avklaringer i IT-avdelingen
- Strategisk koordinator for platform / IT-miljø
- Stopper utvikling / drift av tjenester som har mistet eierskap
- Utviklingsansvarlig (utviklingskoordinator): [i IT-avdelingen]
- Kontaktpunkt for bestiller
- Gjennomfører utvikling og holder leveransemøtet for mottaksansvarlig (med IT-leder og tjenesteier invitert).
- Koordinerer IT-avdelingens andre ressurser for arbeidet.
- Involverer mottaksansvarlig.
- Lager bestillingsbeskrivelse, og videre oppdaterer estimater på kostnad og tid.
Eksempel: Seksjonssjef på USIT (IT-leder) og Seksjonssjef på EA (Tjenesteier) sier «Ja, dette prioriterer vi og betaler for», også er det fagledere EA (Mottaksansvarlig) og fagledere USIT (Utviklingsansvarlig) som planlegger jobben, gjennomfører jobben, akseptansetester jobben også bruker fagpersoner på EA det. All progresjonen skjer mellom faglederne der de koordinerer på hhv EA-siden og på IT-avdelingen-siden.
Oppgaveflyten for å lage bestillingsbeskrivelse
- Scenario 1: Første igangsetting:
- Det kommer en bestilling i en eller annen kanal som ender opp hos utviklingsansvarlig (typisk via via). Det virker som en bestilling som trenger avklaring på leveranse, prioritering, tidsramme, avhengigheter og godkjenning på kostnad. DET ER TID FOR bestillingsbeskrivelse!
- Eier-rollene kobles på - for å definere rollene. Resultatet er en rolleliste og en beslutning om å lage en bestillingsbeskrivelse (godkjennelse til å lage mandat, ville vært prosjektversjonen).
- Utviklingsansvarlig lager utkast til bestillingsbeskrivelse i samråd med Mottaksansvarlig, enten med møte i forkant eller etterkant. Her er eierne inkludert/invitert og orientert.
- tjenesteier gir godkjennelse på versjonsutkastet til bestillingsbeskrivelsen. (Denne kan fint publiseres for å dele med tjenesteier, men da uten utfyllt GO/NOGO).
- Utviklingsansvarlig publiserer siste versjon av bestillingsbeskrivelsen, og vi er good2go.
- Scenario 2: Stort revisjonsbehov på ressursbruk (over 20% ????) og tidsfrist
- Utviklingsansvarlig oppdager et revisjonsbehov (på en av de mange måtene dette kan skje).
- Utviklingsansvarlig lager utkast til bestillingsbeskrivelse i samråd med Mottaksansvarlig, enten med møte i forkant eller etterkant. Her er eierne inkludert/invitert og orientert.
- Tjenesteier gir GO/NOGO på versjonsutkastet til bestillingsbeskrivelsen. (Denne kan fint publiseres for å dele med tjenesteier, men da uten utfyllt GO/NOGO).
- Utviklingsansvarlig publiserer siste versjon av bestillingsbeskrivelsen, og vi er good2go.
- Scenario 3: Lite revisjonsbehov på tidsfrister
- Utviklingsansvarlig og Mottaksansvarlig avklarer løpende (mail, chat, kaffe)
- Oppdaterer ikke bestillingsbeskrivelsen