Udførelses- og opfølgningsfasen

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. FØR projektet besluttes Planlægn. & spec. arbejdet Udfø-relse Denne lektion Aflevering og eval. Drift & vedl.hold • 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 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 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 = 3000 + (120-40)*75 = 9000 timer

12. Vi har et projekt med ti aktiviteter Earned Valueeksempel

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 EarnedValue beregnes af det opdaterede estimat

17. Her er EarnedValue= 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. 10 8 6 APR 1 2 3 4 5 – 8 9 10 11 12 – 15 16 17 18 19 – 22 23 24 25 26 – 29 30 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. 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 • 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 ! Kilde: Capers Jones (1994). Assessment and Control of Software Risks

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

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

29. Krav ogbehov tid1 tid2 Ønsker Nyt behov Behov Udviklings proces Fortolk--ning Produkt Kommu- nikation Behov Ønsker Krav specifikation 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. 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 Os og Dem Scharer, Datamation, 1981.

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 1.2.3 til brugergrænsefladen afhænger af krav 4.5.6 til den valgte hardware-platform • Tilfredsstiller. F.eks. dette krav tilfredsstilles af dette design • Udvikling. F.eks. at dette krav 7.8.9 blev ændret 3 SEP som en videreudvikling af tidligere krav 7.8.9 fra 4 JAN • Rationale. F.eks. hvorfor vi besluttede at krav 4.5.6 skulle med. Hvad var argumenterne og begrundelsen for det trufne valg