Business Case F2012 Session 5 & 6

Business Case F2012 Session 5 & 6
Martin J. Ernst

Agenda – og tidsplan for dagen
Spørgsmål og afklaring Kravspecifikation &Fit cap analyse Pause Interessentanalyse Estimering Case: SAP Gruppearbejde På gensyn …

Fagligt indhold Målet med dette kursus er at gøre dig i stand til at bidrage til en virksomheds forretning ved at udarbejde en business case. Dette kursus vil lære deltagerne at udvikle en business case der kan give virksomheder og/eller de offentlige myndigheder et konkret værktøj til at vurdere om en investering er en god og lønsom idé – og hjælper med at følge op på investeringens effekter. Uden klare mål er det svært at styre it-projekter – og høste de konkrete gevinster. En del af de modeller og metoder deltagerne vil lære er at definere klare mål for din organisations it-investering – og en ramme for at måle om de langsigtede gevinster reelt bliver nået. Deltagerne vil få konkret og relevant viden om emner som er vigtige for en organisation, som feks.: • Hvad går den nye løsning ud på – og er der alternative veje at gå? • Kan investeringen svare sig – og hvilke typer gevinster, kan vi opnå? • Hvordan følger vi op på målene – og dermed sikrer os, at vi opnår gevinsterne? • Hvem er de ansvarlige i projektet – og hvad er de ansvarlige for?

Læringsmål Efter kurset skal den studerende kunne:
- Analysere og beskrive et it-behov, ud fra interessenternes strategiske behov til operationelle mål. - Redegøre for forskellige metoder til at kortlægge behov og mål, og kunne bruge de rigtige metoder i den givne situation. Herunder skal du kunne sikre sporbarheden mellem behov, mål og løsninger samt kunne sikre at business casen inddrages når væsentlige forhold ændres. - Redegøre for forskellige typer af business cases og kunne forklare fordele og ulemper ved hver type. - Anvende business cases til prioritering af projekter. - Anvende relevante teorier til at vurdere den nødvendige investering i et projekt. - Vurdere effekten af en løsning, herunder den økonomiske værdi og den strategiske betydning. - Forklare de strategiske fordele af et it projekt med brug af relevante business case baserede modeller. - Udarbejde en business case for et specifikt projekt. - Relatere business cases til andre metoder og teorier f.eks. PRINCE2 - Anvende Finansministeriets standardmetode til udvikling af business cases.

De næste par gange … Session Dato Tid Rum Tema Gruppe 1 & 2 04.02.12
Rum 4A14 og VCR Business Case struktur og strategiske Metoder og Modeller og Business Case - Løsningsbeskrivelse 3 & 4 Rum 4A14 Forretningsmodel og deres strategisk betydning 1 5 & 6 Kravspecification, Interessentanalyse og Fit-Gap analyse - plus praktiske anvendelse og eksempler + estimering + Ann Rosenberg 2 7 & 8 IT Governance & Business Governance 3 9 & 10 Business Case - Forretningsmæssige konsekvenser og forretningsmæssige værdier og økonomiske konsekvenser 4 11 & 12 Business Case review

Eksamensform Ekstern censur, 7-trins-skala, B4: Mundtlig eksamen med skriftlige arbejder men uden forberedelsestid ved eksamen Eksamensdatoer: Aflevering … 23. maj 2012 kl. 15 på studiekontoret. Mundtlig eksamen … 21. eller 22. juni Tider for de enkelte. kommer når fristen for eksamenstilmeldingerne er passeret. VIGTIGT: Dette er en akademisk eksamen. Dette betyder, at man ikke nødvendigvis får en god karakter bare fordi ens business case giver rigtig mange penge tilbage til organisationen. Den gode karakter nås ved et godt stykke akademisk arbejde.

Skabelon og forventinger …
Indholdsfortegnelsen skal som minimum indeholde skabelonen fra PRINCE2. Dertil har grupperne frihed til at supplere med hvad de finder nødvendigt. En del af den akademiske øvelse er også at argumentere for til- og fravalg af afsnit og informationer. Bilag og appendiks vil ikke som udgangspunkt indgå i evalueringen. Aflevering i 3 eksemplarer med sædvanlig forside (ITU standard). Miniprojektet forventes dermed at være: 7,5 ECTS report standard page span: 15 pages + 2 additional pages per group member (also counting the first member) Example: In a 7,5 ECTS report with 2 group members, 15 + (2 x 2) = 19 pages is the standard page span. If one person wrote this report alone, the upper limit would be 17 pages. A +/- 10% margin is considered within the normal range.

… og mulig indholdsfortegelse (og mulig omfang per afsnit)
Problemformulering/Afgrænsninger/Forudsætninger/Metodeovervejelser (1-2 sider) Selve business casen - PRINCE2 inspireret: - Ledelsesresumé (maks ½ side) - Årsag (1-2 sider) - Muligheder (2-3 sider) - Forventede positivt udbytte (1-2 sider) - Forventede negativt udbytte (1-2 sider) - Tidshorisont (1-2 sider) - Omkostninger (2-3 sider) - Tidshorisont (2-3 sider) - Investeringsvurdering (1-2 sider) - Betydende risici (1-2 sider) Konklusion/Perspektivering (2-3 sider) Appendiks/bilag (frit – men forventes ikke læst …)

To typer: Den teoretisk funderede konsulentrapport
Hovedvægt: Modelanvendelse, analyse, hypotesetest, forklarende og/eller løsnings- orienteret Krav: Sammenhæng mellem teori og caseanalyse og/eller løsningsopstilling Indhold: Problem- og modelbaserede analyser og løsninger Empiri: Udgangspunkt i enten empiriske problemer eller analyse af empiri ved hjælp af teori/modeller Den teoretiske opgave Hovedvægt: Modelvurdering ud fra teoretiske kriterier Krav: Teoretisk dybde Indhold: Teorier diskuteres og vurderes i forhold til hinanden og i forhold til meta- teori Empiri: Eksemplificering To typer:

Litteratur - generelt Obligatorisk litteratur - generelt:
Von Rossing: Business Model Management - changes the way you compete (filnavn: Von Rossing: Business Value Management a way to plan, create and realize value (filnavn: Von Rossing: Business Case Skabelon (filnavn: Von Rossing: Business Case Vejledning (filnavn: Von Rossing: Business Case Regneark (filnavn: Anbefalet: Johnson et al.: Exploring Strategy, 9th edition (eller en tidligere version) ISBN:

Litteratur Dagens litteratur:
Laursen: Vejledning til kravskabelon SL-07 - fra behov til løsning (filnavn: Laursen: Kravspecifikation – Kapitel 8 (filnavn: Søren Lauesen_Kravspecifikation_Chap08 kommer til at ligge på bloggen) Vejledning til statens business case-model v 1.2 (filnavn: Anbefalet: Johnson et al.: Exploring Strategy, 9th edition (eller en tidligere version) ISBN: Side

Kursusevaluering Der er traditionen tro en kursusevalueringen medio april (uge 15). Evalueringen bliver sendt ud fra central hånd. Og håndteret centralt. Jeres input bliver brugt – så gør os og jer den tjeneste at brug 5 min. på dette. Bl.a. skal underviserne kommentere undersøgelsen. Til undervisningen den 28. april vil jeg bruge ½ time på resultatet af denne undersøgelse. BØN: Jeg vil forsat gerne have løbende feedback, da det er for sent i forhold til nærværende kursus at gøre så meget ved det den 28. april. Ønske: Evaluer gerne også … - den virtuelle undervisningsform vs. trad. undervisning, - de lange undervisningsdage vs. korte dage hver uge - … etc.

Spørgsmål ?

Kravspecificering – hvorfor? Brug det til forventingsstyringen!

Integration og go-live
Det er vigtigt at holde for øje hvor i procssen kravspecificeringen sker BC Analyse Udbuds Planlægning Udbud Impl. Analyse Design Byg Test Integration og go-live Stabilisering

Processen for opstilling af krav
Work products 1 A description of the present work in the domain. 2 A list of the present problems in the domain. 3 A list of goals and critical issues (preliminary requirements). 4 Ideas for the large-scale structure of the future system. 5 Realistic possibilities. 6 Consequences and risks. 7 Commitment from stakeholders. 8 Conflict resolution between stakeholders. 9 Final requirements. 10 Priorities of requirements. 11 Checks to see that the requirements are complete, necessary, etc. Interaction diagrams, class models, etc. Source: S. Laursen

Kravspecificering – hvad er godt og skidt?
Dårlig eksempler på krav: Dårlige krav er typisk kendetegnet ved at være enten for uklare eller for specifikke. Det vil sige, at de ikke spidser de funktionelle krav til, eller at de forsøger at fortælle udvikleren, hvordan han eller hun skal gøre sit arbejde. Eksempler på uklare krav kunne lyde: - Systemet skal være brugervenligt - Sitet skal leve op til alle W3C’s standarder Disse krav kan se fornuftige ud ved første øjekast, men hvad betyder ”brugervenligt”, og hvilke W3C-standarder taler vi om? Bedre eksempler på krav: Eksempler på krav, der er for specifikke, kunne lyde: - Databasen skal anvende UTMF8 standard - SQLRecords for hver kunde skal have separate felter for titel, fornavn, efternavn, gade... - Systemet skal programmeres i PHP Også disse krav kunne virker fornuftige. Problemet er, at du ikke kan vurdere, om de giver mening, før du har set en række løsningsmuligheder fra de kompetente udviklere.

Typer af krav (fra en vinkel) …
Funktionelle krav Hvilke processer skal applikationen understøtte? Hvilken ledelsesinformation ønsker man for at kunne tage bedre beslutninger? Non-funktionelle krav Hvad kan man forvente af udvikling af applikationen på den lange bane? Hvilken support kan man forvente af leverandørerne? Hvilke referencer har de? Tekniske krav Hvilken platform kører de på, og hvilken arkitektur er anvendt? Hvordan kan integration gennemføres, og er det SOA-understøttet? Økonomiske krav Hvad koster det at implementere dette? Hvad koster det at drive løsningen de næste par år? Og hvad kan man realisere – og hvornår kan det realiseres? Hvordan ser business casen ud?

… og set med S. Laursens briller (og hvad siger K02?)
B. Overordnede behov B1. Forretningsmæssige mål B2. Tidligt bevis for gennemførlighed (proof of concept) B3. Tildelingskriterier C. Arbejdsopgaver systemet skal støtte C1. Indskriv patient inden ankomst - Opgaver kontra delopgaver - Kun få arbejdsopgaver - Undgå at beskrive data som delopgaver - Højniveau opgaver - oversigt, ikke krav D. Data systemet skal anvende D1. Diagnoser D10. Data i eksisterende systemer og standarder E. Andre funktionelle krav E1. Komplekse beregninger og regler E2. Udskrifter og rapporter E3. Udbygning af systemet F. Systemets integration med eksterne systemer F1. SKS F2. LabsysX F10. Integration med nye eksterne systemer G. Teknisk it-arkitektur G1. Brug af eksisterende hardware og software G2. Nyt hardware og software H. Sikkerhed H1. Adgangsret for brugere H2. Sikkerhedsadministration H3. Sikring mod tab af data H4. Sikring mod utilsigtet brugeradfærd H5. Sikring mod trusler I. Brugervenlighed og design I1. Indlæring og effektivitet i daglig brug I2. Tilgængelighed og Look-and-Feel J. Andre krav og leverancer J1. Andre standarder der skal følges J2. Uddannelse J3. Dokumentation J4. Datakonvertering J5. Installation K. Kundens leverancer L. Drift, support og vedligehold L1. Svartider L2. Tilgængelighed (driftseffektivitet) L3. Datalagring L4. Support L5. Vedligehold Source: S. Laursen

Use case … er det relevant?
Use Cases: Hold Functional Requirements in an easy to read, easy to track text format. Represents the goal of an interaction between an actor and the system. The goal represents a meaningful and measurable objective for the actor. Records a set of paths (scenarios) that traverse an actor from a trigger event (start of the use case) to the goal (success scenarios). Records a set of scenarios that traverse an actor from a trigger event toward a goal but fall short of the goal (failure scenarios). Are multi-level: one use case can use/extent the functionality of another. Use Cases Do Not … Specify user interface design. They specify the intent, not the action Detail Specify implementation detail (unless it is of particular importance to the actor to be assured that the goal is properly met)

Eksempel på use case (fra FESD)
Navn: Danner og afsender post til én modtager Aktør: Ver: Forfatter: Sagsbehandler 1.0 FESD-enheden Beskrivelse Dannelse og afsendelse af post dækker de aktiviteter, der er forbundet med at danne dokumenter fra en sag og afsende dem til en eller flere modtagere/adressater. Alternativt at gøre dem elektronisk tilgængelige på aftalt portal som led i afsendelsen. Afsendelse til ekstern modtager vil kunne ske af flere kanaler afhængigt af: hvilken type af modtager, der er tale om hvilken aftale, der er med den enkelte modtager ift. kommunikationsform … resten slettet … Starttilstand Starttilstanden for ”Danner og afsender post til én modtager” er, at aktøren har gjort det sagsbehandlingsmæssige, der skal til for at danne og afsende en postforsendelse til én modtager. Normalforløb: Trin Aktør System: 1 Vælger/bekræfter ønske om at danne og afsende post. Stiller relevante funktioner til rådighed. Det kan være mulighed for at: Se forslag til forsendelse og forsendelsesform Ændre forsendelse og forsendelsesform Tilknytte eller fjerne sagsdokument(er) fra forsendelsen. 2 Kvalitetssikrer og danner post Stiller relevante funktioner til rådighed Det kan være mulighed for at: åbne og redigere indhold af dokumenter omfattet af forsendelsen. se forsendelsen som den vil fremstå for modtageren (baseret på forsendelsesform) danne post iht. forsendelsesform 3 Signerer, afsender og journaliserer post underskrive/signere forsendelsen med digital signatur autokonvertere vedhæftede filer til tilgængeligt men ikke redigerbart format (fx Pdf) ved digital forsendelse (skal kunne til-/fravælges afhængigt af om modtager skal kunne arbejde videre med dokumentet/dokumenter). sende i relevant forsendelsesform autolåse dokumenter omfattet af posten/for-sendelsen journalisere eventuel udgående e-post og logge selve forsendelsen/systemhandlingen. Sluttilstand Posten, i form af relevante dokumenter, er signeret og afsendt til modtageren i brugerverificeret forsendelsesform. På sagen er aktuel version af dokumenter omfattet af forsendelsen låst som dokumentation for indhold på afsendelsestidspunktet. Selve afsendelsen er journaliseret som udgående post. Note Rækkefølgen af de enkelte trin skal kunne varieres i det omfang, de ikke er afhængige af oplysninger fra et tidligere trin. Der ønskes en høj grad af automatisering af de i usecasen beskrevne behov, i det omfang, det er muligt og relevant.

Fra AS IS over TO BE til FIT GAP
(What is today) TO BE (What is needed tomorrow) FIT GAP Analyses (what needs to be done) Plan (How and when are we doing that is needed to be done)

Mål/indhold/ omfang/kvalitet
Projekttrekanten og interessenterne – udfordringen er at få det hele til at gå op Projektet: Interessenter: Forventninger Krav Viden Tid/ deadlines Ressourcer/ økonomi Løsning Uddannelse Viden Mål/indhold/ omfang/kvalitet Udfordringen er mange gange, at der er langt mellem projektet og interessenterne. Selv om man har defineret ”kontrakten” og dermed trekanten, så kan interessenternes forventninger og krav ændre sig undervejs. Det får betydning for business casen og dermed projekts ”liv”. Derfor: Forståelse og styring af interessenter er en vigtig hjørnesten.

Interessent analyse – definition
Hvem er de væsentligst interessenter? Og hvad forventer de? Hvilken indflydelse har de? Hvordan skal de håndteres? Interessenters styrke og forventninger har væsentlig indflydelse på en organisations formål og hensigt En organisations formål og hensigt udtrykkes ofte i mission, vision, mål, værdier Som ofte udgør fundamentet i en strategi Business casen søger at støtte/forbedre stratgien … så det hænger sammen …

Interessentanalyse bruger også 2x2 matricer …

Mapning af berøringsflader for interessenterne

Interessenterne skal bl. a
Interessenterne skal bl.a. plejes med kommunikation og dertil hører en plan Stakeholder mgt. will: Align the stakeholders expectations Insure right communication at the right time to the right people Get the Business Case aligned in the organisation – and adjusted when needed

Change management ifølge John P. Kotter

Teoretiske positioner (bare en teaser) … - hvad siger de. Hvad skal vi
Teoretiske positioner (bare en teaser) … - hvad siger de? Hvad skal vi? Vil vi det? Lewin Kotter Senge Stacey & Shaw Hvad siger de egentlig, at vi skal? - være opmærksomme på de hæmmende og fremmende faktorer - planlægge forandringen omhyggeligt i den ”rigtige rækkefølge” step 1-8 -starte småt -lade forandringer gro langsomt -lade være med at planlæge det hele - forvente, at det er svært -involvere hele organisationen i at tale om, hvor organisationen skal forandre sig hen - Hvad er det så konkret vi skal gøre? - lave indledende analytisk arbejde, der afdækker, hvordan de forskellige mennesker arbejder i den ene og den anden retning -lave et solidt forarbejde - fokusere særligt på starten af en forandringsproces - tænke i pilotprojekter -sætte realistiske/uambitiøse mål -tænke mere i støtte undervejs end i stor start - være meget åben om formålet med forandringen -fokusér på væsentlige forskelle mellem den nuværende og ønskede adfærd – så konkret som muligt – gerne med metaforer invitere åbent til deltagelse i forandring lave en proces hvor der er udpræget forbindelse mellem de forskellige dele af organisationen, mulighed for feedback og informationsflow Vil vi det? - Ja, det kan bare være svært at skelne i praksis - Ja og nej. Vi anerkender konsulentens og kundens behov for overblik, men vi udfordrer omfanget af det overblik. - Ja og nej. Vi ved, at Senge rører ved noget centralt, når han beskriver organisationers evne til at gennemføre forandringer - Ja – hvis vi kan finde ud af det… - men nej til ”åben deltagelse”. Vi er nødt til at praje folk for at sikre, at vi får nogle magtfulde aktører med.

Estimering er en svær disciplin, som er en blanding af hvid magi, god struktur og en masse erfaringer Gæt Gæt (SPT-analyser: ”Slag på tasken”) Flere personers uafhængige skøn Der er dokumenterede undersøgelser, der viser, at 80% af alle IT projekter overskrider budgetter og eller kalendertid med mere end 50%. Beregninger Normtal og beregninger Nøgletal Formålet er at give en introduktion til praktiske metoder til estimering i projekter og en forståelse for estimeringsprocessen, samt hvilke forudsætninger der ligger til grund for det gode estimat. Erfaring Erfaringer og data fra tidligere projekter Sammenlign med lignende opgaver

Ordentlig og seriøs estimering kræver at projektfremgangsmetoden er afstemt med nøgleinteressenterne
Projekt kick-off / Organi-sering Arbejds-miljøgod-kendelse Road show Udannelse af THT Support Politikker omkring THT Informa-tions-strategi Kommuni-kationsplan TPL Coaching Forbere-delse til CRP CRP (for alle) Udarb. af arbejds-gangsbeskr. Indlæg på teknologi-udvalgs-møde Analyse af teknolo-giske GAPs Udbedr. af teknolo-giske GAPs Test af teknolo-giske GAPs Forbere-delse af udlevering Udlevering Planlægning af uddannelse Udarb. af uddannelse-mat. Forb. af super-brugertest Super-brugertest Gennemførelsese af uddannelse (opt.) Stabili-sering Udarb. af testcases Uddannelse af Super-brugerer Final test Overdrag-else til drift Analyse af teknolo-giske GAPs Udbedred-else af teknolo-giske GAPs Test af teknolo-giske GAPs Håndtermi-nalen ankomst-reg. Projekt-afslutning

Estimering bliver uendelig meget nemmere, hvis problemstilling er brudt ned overskuelige og kendte størrelser (WBS) Delaktiviteter er mere overskuelige og kan estimeres mere præcist. Usikkerheden minimeres ved at produktnedbryde til mindst mulige niveau. [det anbefales at aktiviteter maksimum må være 80 timers varighed]. Der skelnes mellem aktiviteter og leverancer (arbejde og udbytte).c Dokumentér forudsætningerne og husk at regne dem ind i estimatet. Forudsætninger: Risici og mitigering (handlingplan), Kompleksitet, Kvalitetskrav, Koordinering, Ledelsesaktiviteter, Reel arbejdstid pr. uge pr. medarbejder, Buffer, Timepriser, Valuta

Projekt Initierings Dokument (PID)
Usikkerheden omkring estimering bliver mindre og mindre efterhånden, som man bliver klogere på opgaven … Idéfase Kvalificering Start af Projekt Idéoplæg Idémodning Projekt Initierings Dokument (PID) Løsningsskitse Gennemsnitspriser uden rabat fra SKI’s rammekontrakter Usikkerhed: % Tidshorisont: 1-2 uger Løsningsbeskrivelse Priser, rabat mv. fra SKI’s Rammekontrakter (Best case/Worst case) Usikkerhed: 50-75% Tidshorisont: ½-1 måned Kravspecifikation Priser, rabat mv. fra SKI’s Rammekontrakter fra den udvalgte Leverandør eller ifm. miniudbud Usikkerhed: 25-30% Tidshorisont: 2-6 måneder Rødt Estimat Gult Estimat Grønt Estimat

… estimeringen skal følges tæt af i forbindelse med rapportering projektøkonomien til styregruppen, da man her får et EAC tal Budget: Disp.: Realiseret: EAC: Noter: Specificering xxx Interne timer (sat til 0). Estimat x timer. Projektledelse Interne timer (sat til 0) . Estimat x timer. Udførelse Spec. af infocenter løsning SME (100 timer á DKK 1400 i timen) Skærmdesign Interne timer (sat til 0). Estimat x timer. Hvor meget skal bruges Indkøbsprocessen Interne timer (sat til 0). Estimat x timer. Skal det være med? Opsætning af IDMS Opsætning alene. Vurderet til 1 t. per skræm plus (140) timer. IDMS licenser Priser fra DSB IT (101 skærme á 1260,-) Programmering Et skærmbillede vil tage en måned (140 timer * 2). Interne timer. Arkitekter/Ejend. 20 timer á 650 DKK Stativer + Arm Materialeomkostninger ( stander arm * 34) Opsætning Arbejdsløn (??) Skærme (inkl. chasing) Listepris fra leverandør for 110 skærme (á stykket) (-16) Uddannelse Uddannelse af 15 personer i selve løsningen (á en dag + forb.). Test af løsningen Projektdelt. (eksternt) 1000 timer á DKK 1200 DKK Projektdelt. (intern) Interne timer (sat til 0). Estimat 1500 timer. Projektledelse (eksternt) 1000 timer á DKK 1400 i timen SME og QA (eksternt) 110 timer á DKK 1400 i timen Risikoreserve Ca. 25% pga. den generelle risikoprofil er vurderet som høj risiko. Total: Xxx -> ILLUSTRATIVT!!!

Der er valgt tre metoder i forbindelse med dette kursus, som også kan bruges i en kombination med hinanden Delfi metoden En konsensus baseret estimerings metode Baseres på masser af interaktion og kommunikation 3 punkts estimering Middelværdien ud fra tre forskellige vurderinger Monte Carlo Middelværdien ud fra statisktik vurdering

Delfi-metoden er en procesorienteret metode, som bruges til at skabe konsensus via interaktion og kommunikation At etablere estimater At nedbryde leverancer i aktiviteter At få fælles forståelse for projektet En konsensus baseret estimerings metode Bruges til at estimere indsats Baseres på masser af interaktion og kommunikation Usikkerhed 5-7 personer giver et estimat…. Laveste og højeste redegør for deres forudsætninger og der estimeres igen…. Laveste og højeste redegør for deres forudsætninger og der estimeres igen….

Individuel forbere-delse
Der er principielt fire step i Delfi-metoden, hvor step 3 og 4 gentages efter aftale eller behov Vælg team PL udvælger estimeringsteam (3-7 personer) og en facilitator (evt, PL selv). Det skal være repræsentative kompetencer. Kickoff møde Brainstorm omkring antagelser, lav en WBS (Work Breakdown Structure) og skab enighed om enheder, der estimeres. Individuel forbere-delse Efter Kickoff møde laves 1. estimat af hver enkelt i teamet for hvert WBS element. Supplerende antagelser og ændringer til WBS dokumenteres. Estime-ringen Iterationer for at opnå konsensus. Synlighed for alle. Timeboks. PL etablerer endelig liste over aktiviteter, estimater og antagelser. PL og team reviewer resultatet.

Øvelse: Estimer udskiftningen af et tag
Der skal først opstilles en produktbeskrivelse med efterfølgende WBS struktur Alle sætte sig ned og beregner hvad det vil koste baseret på egne erfaringer og gæt Forslag fremlægges Højeste og lavest bud fremlægger deres forudsætninger Alle sætte sig ned og beregner hvad det vil koste baseret på egne erfaringer og gæt – OG de nye forudsætninger … og måske en runde til

3 punkts estimering er en metode til at opstille estimater baseret på tre vurderinger; det bedste, det optimistiske og det pessimistiske gæt Vi ser bort fra usikkerheden og gætter konsekvent lavere end middelværdien! Gæt kan kvalificeres væsentligt gennem en trepunktsestimering. Ved trepunktsestimering beregnes middelværdien M ud fra tre forskellige gæt: G: Bedste gæt – det, vi tror, er det mest sandsynlige O: Optimistisk gæt – bedste ud af at 100 gange gennemføre aktiviteten P: Pessimistisk gæt – værste ud af at 100 gange gennemføre aktiviteten, uden at nogen af de kritiske forudsætninger indtræffer Formel for beregning af estimat for M: M = (O + 3G + P) / 5.

Teorien bag 3 punkt estimering er baseret på vurderingen omkring spredning og sikkerhed
Ved trepunktsestimering er der 50 % sikkerhed for, at ressourceforbruget ikke bliver større end M. Hvis der ønskes en større sikkerhed end 50 %, må vi indregne spredningen. Spredningen S er et udtryk for det ”tillæg” til M, som man nødvendigvis må operere med for at opnå større sikkerhed for, at estimatet kan holde: 85 % sikkerhed: Ressourceforbruget er maksimalt M +S 97 % sikkerhed: Ressourceforbruget er maksimalt M +2S 99 % sikkerhed: Ressourceforbruget er maksimalt M +3S Formel for beregning af spredningen S: S = (P – O) / 5. En aktivitet er med den mest optimistiske vurdering estimeret til 20 timer Vo = 20 Den mest sandsynlige vurdering er estimeret til 30 timer Vg = 30 Den mest pessimistiske vurdering er estimeret til 50 timer Vp = 50 Vm kan beregnes til * = 32 timer 5 Dvs. at der er 50% sandsynlighed for at estimatet ikke overskrides inden for 32 timer S kan beregnes til : = 6 timer 5 Med anvendelse af 2*Standardafvigelse fås, at estimatet med 95 % sandsynlighed ligger inden for intervallet : Vm +/- 2*6 timer = timer, hvilket vil sige at : der er 97 % sandsynlighed for at estimatet ikke overskrides inden for 44 timer

Øvelse: Begynd at estimere et par af aktiviteterne fra jeres projekt

Estimeringseksempler fra Statens vejledning

Monte Carlo er en udviddelt versoin af 3-punkts-metoden

… og værdigfuld hvis de er skæve fordelinger

… og sidste eksempel

Spørgsmål ?

Business Case F2012 Session 5 & 6

Lignende præsentationer

Præsentationer af emnet: "Business Case F2012 Session 5 & 6"— Præsentationens transcript:

Lignende præsentationer

Om projektet

Feedback

Log ind

Logge ind via sociale netværk:

Business Case F2012 Session 5 & 6

Lignende præsentationer

Præsentationer af emnet: "Business Case F2012 Session 5 & 6"— Præsentationens transcript:

Lignende præsentationer

Om projektet

Feedback