Embed Size (px)
DESCRIPTION
Produkteier- og prosjektlederrollen i smidige prosjekter.
Citation preview
Produkteierrollen, kundens medvirkning og forankring i linjen - sett fra en Leverandør
Anne Kristine Næss
Bakgrunn fra offentlig sektor.
Jobbet med både fossefallsprosjekter og halvsmidige prosjekter fra 2004-2007.
Siden 2007 har jeg stort sett bare jobbet i og med smidige prosjekter.
E-post: [email protected]
Blogger: http://gevinstrealisering.blogspot.com/ http://agileandadaptive.blogspot.com/
Linkedin: http://no.linkedin.com/in/kristinenaess
Om meg
EDB 2010
Page 2
Hovedspørsmål: Utviklerne lever i stadig smidigere omgivelser – men gjør produkteieren?
Hvor viktig er det at produkteieren tar aktivt del i smidige prosjekter?
Hvordan beholder man fokus på gevinster før, under og etter en leveranse?
Hvordan skaper man effektive feed-backsløyfer gjennom smidig?
Disposisjon:
EDB 2010
Page 3
EDB 2010
Page 4
Teamet:
Forstår kundens behov
Tar ansvar for egen fremdrift
Reflekterer over forbedringsmuligheter i hver sprint
Prøver raskt ut tiltak
Prosjektet:
God rolleforståelse hos produkteier og scrum master
Opplegg for endringsledelse og gevinstrealisering
Suksessfaktorer ved smidig
Behov
Grov-skisse
av behov
Løsningen blir sjelden smartere enn tanken bak den
EDB 2010
Page 6
Produkteier
Scrumteamet
Bedret behovs-
forståelse
EDB 2010
Page 7
Som vi har hørt, er det sjelden nok med én
Typiske roller og ansvarsoppgaver:– Bestiller – Spesifikatør– Produktkøansvarlig – Prosjektleder – Orakeltjeneste– Koordinator – Endringsleder– Innføringsansvarlig – Opplæringsansvarlig– Håndterer interessentene– Kommunikasjonsleder – Osv.
Akhilleshælen i et hvert prosjekt
Produkteieren
Product Owner
EDB 2010
Page 8
Kjente argumenter?
Produkteier
Jeg må sile behovene fra
systembrukerne, så de kan ikke
snakke med dere direkte.
Jeg husker ikke helt hvorfor, men
dette har vært prioritert lenge.
Jeg har ikke anledning til å skaffe avklaringer på dette
nå, men bruk de overordnede
beskrivelsene.
Fra unik kunnskap til delt kunnskap
EDB 2010
Page 9
Produkteier
Scrum team
Fagavdeling
Systembrukere
Hva kan gå galt?
EDB 2010
Page 10
Får ikke tak i kunden
Teamet jobber saktere, venter på avklaringer
Teamet må gjette seg frem til en mulig løsning
Teamet lar være å løse visse krav Kunden
kjenner ikke løsningen
Prosjektet når ikke opprinnelige mål
Første symptom Neste symptom Kundens problemer
Teamet jobber saktere Forsinkelser i prosjektets fremdrift
• Forsinket ferdigdato/redusert scope
• Budsjettoverskridelser • Ressurser forsvinner ut
Teamet må gjette seg frem til løsning
Funksjonelt dårlig løsning: • Effektivitetstap• Kvalitetstap• Lavere brukerfornøydhet• Økte forvaltningskostnader
Teamet lar være å utføre oppgaver
Manglende behovsunderstøttelse
• Oppgaver må utføres manuelt• Arbeid må gjøres om igjen pga.
feil
Kunden kjenner ikke løsningen
Mangelfulle forberedelser innen overlevering/mottak/innføring
• Sjokkopplevelse for mottakerne• Vanskelig å drifte og forvalte• Det tar lengre tid å
overta/implementere løsningen• Uteblitte eller forsinkede
gevinster
Hva kan gå galt?
EDB 2010
Page 11
Kunden må være tilstede fra initiell behovsfase til gjennomføringsløpet til godkjenning og implementering.
Slutte med «multitasking» og lave allokeringsgrader i prosjektene.
Jobbe fysisk sammen med scrumteamet i større grad.
Hvordan løse dette?
EDB 2010
Page 12
Gevinster
Vil kunden ikke ha gevinster?
EDB 2010
Page 14
Scrumteamet
Produkteier
Tiske, hviske
EDB 2010
Page 15
Investeringsanmodning
Prosjektplan/produktkø
Hva er viktigst nå?
EDB 2010
Page 16
Økt inntjening/bedre ressursutnyttelse• Prosessforbedringer• Bedre verktøystøtte
Økt medarbeidertilfredshet• Økt brukervennlighet• Økt involvering og eierskap
Økt kvalitet• Prosessforbedringer • Bedre verktøystøtte
Gevinstplanen
EDB 2010
Page 17
MålGevinst
Tiltak:Muliggjøre
gevinst
Tiltak:Minimere
risiko
Arbeidspakke A: Automatisert ”datafangst”
Sikre at saksbehandlerne forstår og tar i bruk den
nye funksjonaliteten
Sikre at frigjort tid blir brukt til å bygge ned
restanser
Bedre ressurs-utnyttelse
Forretningsendringer
Forbedret arbeidsprosess
IT-resultat
Sikre tilstrekkelig ytelse og lav nedetid i hele
systemløsningen
Nye/endrede behov?
Redusert saksbehandlingsti
d
Feedback-sløyfer og kommunikasjon
Feedback-sløyfer
EDB 2010
Page 19
Tre nivåer av feedbacksløyfer
EDB 2010
Page 20
Kontraktsinngåelsen • Initiell Behovsanalyse• Initiell Løsningsskisse
Sprinten • Daily scrum• Sprint review/demo• Sprint retrospetiv/tilbakeblikk
Releasen • Akseptansetest (og eventuelle andre tester)• Bruk av ferdig løsning
Å spille hverandre gode
EDB 2010
Page 21
Flere obligatoriske felter gir lengre
saksbehandlingstid og økt misnøye med løsningen.
Spille hverandre gode: Leverandøren
EDB 2010
Page 22
Flere obligatoriske
felter gir lengre saksbehandlings
tid og økt misnøye med
løsningen.
Flere forhåndsutfylte
felter
Enkle og veldefinerte
nedtrekkslister
Bedre gjenbruk av masterdata
Spille hverandre gode: Kunden
EDB 2010
Page 23
Flere obligatoriske felter gir lengre
saksbehandlingstid og økt misnøye med løsningen.
Aktiv endringsledelse
i forkant
Forenkling av rutiner
God opplæring
Måling av effekt
EDB 2010
Page 24
Økt effektivitet: klokketid og kalendertid
Økt medarbeidertilfredshet: spørreundersøkelse
Økt kvalitet:
antall klagesaker per tidsintervall og resultat av stikkprøver
Kontinuerlig forbedring
EDB 2010
Page 25
Økt effektivitet: redusert klokketid og kalendertid
Er vi fornøyde med de siste målingene?
Hva skyldes eventuelle avvik?
Hvilke endringer bør vi gjøre:a) i systemene våre?
b) med selve arbeidsprosessen?
Å gi de avklaringene som er nødvendige– Synliggjøre mål– Avklare relevante behov– Gi en absolutt prioritering– Vurdere foreslått løsning gjennom demo/review
Å holde i sin del av gevinstrealiseringsplanen?– Gjennomføre relevante forretningsmessige tiltak– Gjennomføre målinger– Sørge for gode feedback-sløyfer tilbake til scrum teamet
Kundens forpliktelser
EDB 2010
Page 26
