Udførelses- og opfølgningsfasen

Præsentationer af emnet: "Udførelses- og opfølgningsfasen"— Præsentationens transcript:

1 Udførelses- og opfølgningsfasen

2 Efter denne lektion skal du:
Kunne forestå overvågning og rapportering af fremdrift i et projekt, f.eks. ved hjælp af restestimat-teknikken eller ”Earned Value” Kunne følge op på alle de vigtige ting i et projekt Kunne styre ændringer, f.eks. af krav, undervejs i et projekt Kende vigtigheden af sporbarhed i relation til styring af krav

3 Denne lektion X X X X FØR projektet besluttes
Planlægn. & spec. arbejdet Udfø-relse Aflevering og eval. Drift & vedl.hold Denne lektion X Project Scope Management Project Quality Management Project Human Resource Management Project Time Management Project Cost Management 6. Project Communication Management 7. Project Risk Management 8. Project Procurement Management 9. Project Integration Management X X X

4 Når projektet er i gang – og indtil det slutter – skal der følges op på:
Projektets ”Scope” Projektets estimat og omkostninger Projektets plan Projektets risici Projektets kvalitet Nøgleinteressenter

5 Opfølgning på projektets ”Scope”
Spørgsmål: Ændrer målet sig? Ændrer forudsætningerne sig? Ændrer behovet for projektet sig (= de forventede benefit)? Imødegås f.eks. ved: Tæt kontakt til ejer/sponsor Tæt kontakt til målgruppen, dvs. dem der skal bruge projektets resultat Brug styregruppemøde(r) og vær ikke for fin til lobbyvirksomhed

6 Opfølgning på projektets estimat og omkostninger
Spørgsmål: Svarer det faktiske timeforbrug til det estimerede? Havde vi glemt arbejdsopgaver i estimatet? Imødegås f.eks. ved: Tæt kontakt til projektgruppen Regelmæssig (ugentlig) rest-estimering Regelmæssig (månedlig) re-estimering

7 Tidsregistrering Hvis ikke man registrerer forbrugt tid, har man intet grundlag for seriøs opfølgning på fremdrift På den ene side skal man sørge for en nøjagtig og præcis registrering af forbrugt tid. På den anden side skal man sørge for at tidsregistreringen har hold i virkeligheden - og ikke bliver til det rene digt Det værste man kan gøre er, at kræve så og så mange timer registreret per dag/uge/måned af den enkelte

8 Restestimerings-teknikken
Revideret budget = Aktuelt forbrug + Restestimat Alle der arbejder på en aktivitet bliver bedt om at registrere hvor lang tid de har brugt, Samt hvor lang tid de forventer at der er tilbage Tallene summeres - som vist i eksemplet

9 Earned Value teknikken
Det totale antal timer i projektet estimeres. Hver aktivitet tildeles en procentværdi efter størrelse F.eks. vil en 50 timers aktivitet i et 2000 t. projekt få procentværdien 2,5 Når en aktivitet afsluttes siges værdien af den at være tjent (”Earned Value”) Vi har således tjent 2,5 når 50-timers aktiviteten afsluttes Earned value kan selvfølgelig vises grafisk (S-kurver)

10 Earned Value 2/3 Opgørelsestidspunkt Budgetteret arbejde
= 44 arb-enheder á 60 timer/styk Forventet arbejde udført på de forbrugte 3000 timer => 3000/60 = 50 arb.enheder Udført arbejde = 40 arb.enheder Og da 40/120 = 33,3% Så er det vores Earned Value Opgørelsestidspunkt

11 Earned Value 3/3 Vi har estimeret at projektets 120 arbejdsenheder (AE) vil tage 7200 timer at gennemføre (1 AE koster således 60 t. i gennemsnit) På opgørelsestidspunktet (tidspunkt 6) konstaterer vi at: Det budgetterede antal AE er 44 (svarende til 2640 t.) Der er gennemført 40 AE Men der er forbrugt 3000 timer (svarende 50 AE) Herefter kan vi lave et nyt estimat: 1 AE koster nu 3000/40 = Ca. 75 timer (nyt estimat) Nyt totalbudget = (120-40)*75 = 9000 timer

12 Vi har et projekt med ti aktiviteter
Earned Value eksempel Vi har et projekt med ti aktiviteter

13 Vi har nu registreret et forbrug
Kan være Earned Value

14 En udgave af Earned Value er, at vi kun tæller afsluttede aktiviteter

15 Vi kan også have at: Påbegyndt = 20% Afsluttet = 100%

16 Men egentlig skal Earned Value beregnes af det opdaterede estimat

17 Her er Earned Value = forbrug / nyt estimat
Var = 30 før

18 Earned Value begreber

19 Earned Value formler

20 Opfølgning på projektets plan
Spørgsmål: Er deltagerne motiverede? Kan deltagerne samarbejde? Arbejder de effektivt? Imødegås f.eks. ved: Tæt kontakt til projektdeltagerne - Mindst hver uge! Slå ørerne ud i kantinen og ved uformelle sammenkomster Inddragelse (forpligtelse) af deltagerne i estimering, planlægning og risikoanalyse

21 Opfølgning på projektets risici
Spørgsmål: Har risici ændret sig – omfang eller indhold? Er der nye risici? Nye muligheder for at forebygge eller imødegå? Værktøjer og metoder til at svare: Audit – dvs. nogen ude fra der kommer og kigger – af projektets risikohåndtering Regelmæssig (månedlig) risiko-granskning Fornyet risikoanalyse ifm. statusopgørelse f.eks. til styregruppemøde

22 Opfølgning på projektets kvalitet
Spørgsmål: Laver vi kvalitets – arbejde så vel som resultater? Værktøjer og metoder til at svare: Inspektion og reviews Kontroldiagram Paretodiagram, dvs. et søjlediagram ordnet efter forekomsthyppighed Statistisk stikprøveudtagning Flowcharting, dvs. mapning af hvor i en forretningsgang problemer opstår?

23 Kontroldiagram Et kontroldiagram er en grafisk fremstilling af resultaterne af en proces hen over tid. På diagrammet anføres en øvre og en nedre kontrolgrænse. Vi ved f.eks. at en teknikker kan sætte 8 nye PC’ere op om dagen +/- 2. 10 8 6 APR – – – – 29 30 Antallet af installerede PC'ere ligger uden for normalen den 12. og den 26. april Opgaven er nu at finde ud af hvorfor?

24 Opfølgning på nøgleinteressenter
Spørgsmål: Er der modstand mod forandring hos målgruppen? Bakker ejer/sponsor fortsat op? Er igangsætterne med? Hvad der kan gøres: Tag kontakt til målgruppen: Hvad bekymrer? Hvad motiverer? Gå forrest og selv være forandringsparat Få projektets ejer / sponsor til at fortælle om visionen offentligt Find, inddrag og motiver igangsættere tidligt

25 Glem aldrig dine interessenter!
Glem ikke interessenterne undervejs i projektet. Og glem dem slet ikke når du har mest travlt med kriser andet steds i projektet Gentag interessentanalysen med passende intervaller. Især i længerevarende projekter kan der ske betydelige ændringer undervejs Informér, informér og informér. Brug din styre-gruppe, lav nyhedsbreve, hold informationsmøder Hold ørerne åbne og lyt også til den uformelle snak

26 Lidt tal om kravstyring
Kilde: Capers Jones (1994). Assessment and Control of Software Risks Det gennemsnitlige antal ændringer af krav i en stikprøve på 60 projekter var på 35% (altså ca. 1/3 del af systemet blev ændret efter kravspecifikation) Det er indlysende at der er brug for formelle metoder til styring af disse ændringer af krav! Der er i gennemsnit 1% ændring pr. måned, hvilket svarer til at ca. 33% af systemet er ændret i et 3 årigt projekt. Denne frekvens af ændringer er højere end inden for f.eks. Elektronikindustri eller bygge & anlæg Jo kortere projekt jo færre ændringer !

27 Kravstyring – Hvornår? GODKENDT
Kravstyring af ændringer træder i kraft, når først kravspecifikationen er godkendt og “låst” ! Krav- Specifikation GODKENDT

28 Krav-styring: Eksempel på en procedure
Check og afslut ændring Opret projekt Igangsæt Ændrings - junta Estimer og planlæg Vurder Kons e kven ser ved afvi s ning Æn dring opstår Projekt leder Log af ændringer Udfyld formular gruppe løsnings muligheder Afvist Luk ændring Krav-styring: Eksempel på en procedure

29 Krav og behov tid1 tid2 Ønsker Nyt behov Behov Udviklings proces
Fortolk--ning Behov Kommu- nikation Produkt Ønsker Krav specifikation Krav og behov Behov Ønsker

30 Problemet ved at fremtage krav
Systemkrav ændrer sig over tid Det er svært for de fleste at artikulere krav Funktioner og processer er svære at beskrive Slutbrugere har svært ved at fortælle hvad de ønsker sig eller vil have Det er svært at motivere brugerne Kan måske ikke lide idéen om et nyt system Belønningen – i form af det nye system – kommer ikke før til allersidst – måske år frem I tiden!.

31 Krav har mange ansigter …
Mange interessenter Brugere, administratorer, ejere, udviklere … Mange konkurrerende aktiviteter Fremtagning, modellering, specifikation, dokumentation … Krav bruges til mangt og meget Kommunikation, kontrakter, udvikling ...

32 Os og Dem Scharer, Datamation, 1981. Hvordan brugerne ser os
Hvordan vi ser brugere De ved ikke hvad de vil have De kan ikke formulere hvad de ønsker sig De har for mange behov der er politisk motiveret De kan ikke prioritere deres behov De nægter at tage ansvar for systemet Er uvillige til kompromisser Hvordan brugerne ser os De forstår ikke forretningen De opfører sig underligt i forhold til politiske fohold I organisationen Vil fortælle os hvordan vi skal udføre vores arbejde De siger NEJ hele tiden De er altid over budgettet De er altid for sent De er ude af stand til at tilpasse sig ændrede behov

33 Brugernes forsvars-strategier
Køkkenvasken Smid alting ind som krav Røgslør Bed om mere – så er der noget at forhandle med Det samme som idag Dovenskab eller mangel på viden

34 Definition af sporbarhed
Sporbarhed: Evnen til at følge “livet” for en artefakt, dvs. hvor kom det fra, og hvad resulterede det i Sporbarhed af krav: Evnen til at følge et kravs liv Forlæns: Fra kravspecifikationen til design, til udvikling (produktion) og test Baglæns: Hvor kom kravene fra? F.eks. møde, interview, fokusgruppe, analyse af arbejdsgange etc.

35 Vigtigheden af sporbarhed
Det amerikanske forsvarsministerium (DOD) bruger årligt 4% af “Life Cycle Cost” Virtuelle teams der laver softwareudvikling Outsourcing af IT Fokus på genbrug Re-engineering af store gamle systemer (“legacy systems”) Evolutionære processer – hvor systemerne gror frem, blad for blad, gren for gren

36 Hvor har vi problemet med sporbarhed?
Procesviden ved udvikling af store systemer Håndtering af konflikter ved samarbejde i.f.m. udvikling; Hvad er besluttet?, Hvad er implementeret? Organisationens hukommelse; Hvad gjorde vi, og hvorfor?

37 Ramesh & Jarke (2001) Empiriske studier i mere end 30 organisationer: Offentlige, luftfart, forsvar, kommunikation, elektronik, medicinal, systemintegration Forskningsmetoder: Case studier (3) Fokusgrupper med forskellige interessenter (30) Strukturerede individuelle interviews (125) Studier af sporbarheds-dokumenter (30) Analyse af CASE-værktøjer (8)

38 Forskellige slags sporbarhed
Afhængighed. F.eks. at dette krav til brugergrænsefladen afhænger af krav til den valgte hardware-platform Tilfredsstiller. F.eks. dette krav tilfredsstilles af dette design Udvikling. F.eks. at dette krav blev ændret 3 SEP som en videreudvikling af tidligere krav fra 4 JAN Rationale. F.eks. hvorfor vi besluttede at krav skulle med. Hvad var argumenterne og begrundelsen for det trufne valg