Udførelses- og opfølgningsfasen

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

Men egentlig skal Earned Value beregnes af det opdaterede estimat

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

Earned Value begreber

Earned Value formler

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

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

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?

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 1 2 3 4 5 – 8 9 10 11 12 – 15 16 17 18 19 – 22 23 24 25 26 – 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?

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

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

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 !

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

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

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

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!.

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 ...

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

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

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.

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

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?

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)

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