Prosjektstyring og prosjektgjennomføring Prosesser, tidsplanlegging, risikostyring G&H: kap 16, 17,19 Kirsten Ribu 02.09.2005 1
I dag Prosessmodeller og prosjekter Prosjektplanlegging, inkl. tidsplanlegging Risikostyring 2
Hva er et prosjekt? Fra latin: projectus - noe som er kastet fram Et prosjekt er en arbeidsoppgave med følgende egenskaper: En engangsoppgave: Noe man ikke har gjort før og ikke kommer til å gjøre igjen med det første. Skal lede fram til et bestemt resultat Er ofte tverrfaglig og berører mange i organisasjonen: krever forskjellige typer ressurser Er begrenset i tid 3
Hva er en prosess? En prosessmodell? Prosess: Ethvert arbeid (en prosess) består av to ting: beslutninger og handlinger (Eks. Fylle ut selvangivelsen: Ta beslutninger ut fra skattereglene -> fylle ut riktige felt og gjøre beregninger) Prosessmodell: En abstrakt representasjon av en systemutviklingsprosess Eks: Fossefallmodellen, Spiralmodellen Inkrementell modell RUP, XP Oppgaver: Er det noen forskjell på en modell og en metode? Hva slags prosessmodell vil dere bruke i prosjektoppgaven? 4
Planlegging Ressurser: mennesker (kunnskap og erfaringer) tid Problemdefinering tolkning av oppdraget: forhandling mellom interesser vurdering: kan oppdraget gjennomføres med tilgjengelige ressurser? Planlegging av arbeidet oppdeling i arbeidsoppgaver samordning av arbeidsoppgavene 5
Oppdeling i arbeidsoppgaver Hva skal gjøres? Hvem skal gjøre det? Samordning av arbeidsoppgavene Hvordan henger delresultatene sammen? Hvordan skal ressursene fordeles? Planleggingsverktøy: milepælplan: resultater koblet med tid ansvarskart: hvem er ansvarlig for hva 6
Noen ord om gruppearbeid Vær forberedt til prosjektmøtene Lytt til andre: prosjektarbeid er samarbeid. Vær positiv: Unngå å kommentere negative sider ved prosjektet. Negativitet har en tendens til å spre seg. Si fra: Ta opp ting som trykker/irriterer. Gi konstruktiv kritikk: Hva kan gjøres bedre og hvordan? Kulturelle forskjeller: Prøv å forstå bakgrunnen for uttalelser og holdninger 7
Prosjektarbeid Fordel roller med tilhørende oppgaver Organiser arbeidet Lag regler for hvordan arbeidet skal utføres Lag tidsplan Oppgaver: møteledelse referat oppfølging og kontroll av vedtak ledelse av oppgaveløsning versjonskontroll timeføring 8
Roller og regler En person kan gjerne ha flere roller. Rollene kan gjerne byttes eller omdefineres i løpet av prosjektperioden. Forslag til roller med oppgaver: Prosjektleder: møteledelse, oversikt, oppfølging og kontroll av vedtak Webansavarlig Kontaktperson kontakt og avtaler med omgivelsene: prosjektsted, kursledelse, andre grupper Skrive-ansvarlig fordeling og oppfølging av skrivejobber, versjonskontroll Programmeringsansvarlig Det bør være regler for møter: tidspunkt, varighet, taletid beslutninger: beslutningsdyktighet, dokumentasjon, ansvar referat: ansvar, omfang forføyninger: reaksjoner ved regelbrudd 9
Vanlige problemer i gruppearbeid: Ujevn arbeidsinnsats blindpassasjerer ildsjeler ulikt ambisjonsnivå de som bare vil bestå de som har høye ambisjoner ulikt kunnskapsnivå verdensmestere de som eier prosjektet ulik tolkning av oppgaven Hvordan finne balanse mellom at alle skal lære det de ikke kan alle gjør det de kan best alle skal lære mest mulig alle gjør det de kan 10
Løsninger For å unngå konflikter: gjør avtaler om ansvarsfordelingen dokumenter alle beslutninger (skriv referat med beslutninger) kommuniser også skriftlig (f.eks. e-post) meld fra dersom du må bryte en avtale Ved konflikter: ta tak i konflikten før den er stor prøv først å løse den selv ta opp problemet med de(n) det gjelder bli enig om løsning: måte og tidsfrist søk hjelp hos lærer dersom konflikten synes uløselig 11
Prosessmodell 12
Ulike typer prosessmodeller De røde er viktige i dette kurset: Evolusjonær (prototyping) Inkrementell (RUP/varianter av RUP) Agile metoder (parprogrammering, XP extreme programming) fossefall gjenbruksbasert spiral-modellen 13
Prosessmodell - faser Forstudium/Forprosjekt Feasability study (Hvilke muligheter har vi?) Kravspesifikasjon (Hva skal systemet gjøre?) Design (Hvordan skal systemet lages?) Programmering (Lage systemet) V&V (Validering og verifikasjon) / Testing Har vi bygd riktig system/produkt? (validering) Har vi bygd systemet/produktet riktig? (verifikasjon) Videreutvikling/Vedlikehold/Endring 14
Hvorfor er bruk av prosessmodell viktig? Det å anskaffe et IT-systemer ikke som å kjøpe bil. Det er et vesentlig kjennetegn at det er usikkerhet om hva som kreves, og det er derfor naturlig at kravene forandrer seg underveis. Det er ikke profesjonelt å bruke dette som en unnskyldning for at det gikk galt. Store prosjekter må legges opp slik at de kan håndtere slike endringer. Eksperimentering, prototyper og prøvedrift er nettopp teknikker for å håndtere dette. 15
TRESS-90 Skrekkeksempel - TRESS-90 - Trygdeetatens store EDBsatsing på 90-tallet. I Tress-90 satset man stort. Innledende eksperimenter med ny utviklingsplattform ble i følge pressen ikke helt gjennomført. Det ble tidlig kjøpt inn nye maskiner til trygdekontorene, og store ressurser ble brukt før man fikk praktiske erfaringer med de nye løsningenes holdbarhet. 16
Forts I store prosjekter er lite tilbøyelig til å revidere sentrale vurderinger. I stedet satser man mer og mer, hardere og hardere, på å nå de målene man opprinnelig satte seg. På den måten kan man unngå et direkte nederlag, men samtidig øker innsatsen vesentlig. Noen ganger går dette godt, men det er tydelig at enkelte prosjekter burde vært revurdert og stanset på et langt tidligere tidspunkt. Den som har ansvar for et stort utviklingsprosjekt bør derfor finne fram til mekanismer som kompenserer for denne tendensen. I praksis vil dette blant annet bety at ansvarlige ledere må skaffe seg kompetente rådgivere som er uavhengige av det aktuelle prosjektet. Kilde: Førsteamanuensis Pål Sørgaard, Institutt for Informatikk, Universitetet i Oslo http://heim.ifi.uio.no/~paalso/artikler/fiasko/fiasko.html 17
SINTEFS rapport SINTEFs eksterne prosjektrevisjon viste bla at: Programmeringsfasen ble startet uten å være i nærheten av et stabilt design. Reell brukermedvirkning på en del viktige områder som brukergrensesnitt kom sent Interne prosjektavhengigheter ble dårlig håndtert Ingen kritisk sti => alle aktiviteter ble oppfattet som like viktige for å holde leveransetidspunktet Kvalitetssikring uten myndighet Personer ble tatt ut av prosjektet på avtalt dato, uavhengig om oppgaven var ferdigstilt eller ikke Kontrollfunksjoner, avtaler og innkjøp syntes å gå ut fra at kartet (valgt prosessmodell) var mer riktig enn terrenget (reell prosess). Konsekvensen var at prosjektet kom ut av styring! 18
Prosjektplanlegging Prosjektplanlegging 19
Sammenheng prosess prosjekt Faser i prosjektmodellen blir til overordnede aktiviteter og milepæler i prosjektplanen (NB! Prosjektplanen vil inneholde flere og mer detaljerte aktiviteter) Relasjon mellom faser i prosjektmodellen blir til Gantt-diagram eller lignende i prosjektplanen. Innhold i faser i prosjektmodellen blir til leveranser, dokumentasjon, verifikasjon og validering, risikostyringsaktiviteter m.m. i prosjektplanen 20
Tidsplan Gantt diagram 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4 Start T1 T2 M1 Slakk T7 T3 M5 T8 M3 M2 T6 T5 T9 M4 M7 T10 T11 M6 M8 T12 Finish 21
Prosjektmodell vs. prosjektarbeid Prosessmodellen vil ofte være organisasjonens valg av felles arbeidsmåte for å sikre gjenbruk av erfaring og forutsigbare leveranser. Prosjektplanen er prosjektleders virkemiddel for å sikre leveransene under rammebetingelsene som settes av prosessmodellen 22
23
Prosjektplanlegging Forslag til prosess for utarbeidelse av prosjektplan (iterativ prosess): Finn person(er) som kan utarbeide prosjektplan (bør inkludere den kommende prosjektleder - eierskap til plan er viktig) Forstå så mye som mulig av kravene til leveransene (kravspesifikasjon), samt andre viktige rammer for prosjektet (f eks leveransefrist og kostnadsrammer). Velg prosessmodell ut fra rammevilkår (marked, risiko for endring av krav, kundemodenhet, kompetanse i organisasjonen) Definer milepæler, leveranser (datoer) og aktiviteter Estimer tidsforbruk (timeforbruk) per aktivitet Analyser om tilgjengelig ressurser finnes Vurder risiko og reforhandle leveranseinnhold om nødvendig 24
Forprosjekt Formålet med forprosjektet er å kartlegge om et prosjekt er gjennomførbart. Første oppgave er å sette seg inn i markedet og kundens behov slik at man har en god innsikt i krav. Ved å utvikle et konsept allerede i forprosjektet vil man kunne få konkrete tilbakemeldinger både internt hos oppdragsgiver og i markedet svært tidlig i prosjektet. Arbeidet med planlegging og budsjettering blir dermed mer konkret. 25
Tidsplanlegging 26
Avhengigheter Det er avhengigheter mellom enkeltaktiviteter eller større deler av et prosjekt En aktivitet = et avgrenset stykke arbeid (programmere, utarbeide spørreskjema) Har et antatt tidsforbruk Kan ikke starte før en eller flere andre aktiviteter er avsluttet Bruker bestemte ressurser (mennesker) Har et navn 27
Aktivitetsdiagram med avhengigheter aktivitetsnettverk 4/7/99 start 8 days T1 15 days T2 14/7/99 15 days M3 M1 25/7/99 T7 T3 5 days T6 20 days 4/8/99 M4 15 days T9 25/8/99 M6 T11 7 days 10 days T4 25/7/99 M2 10 days T5 11/8/99 M7 15 days 5/9/99 M8 18/7/99 M5 T10 10 days T12 25 days T8 Finish 19/9/99 28
Kritisk sti i diagrammet Aktivitetsdiagram viser avhengigheter i prosjektet Sett opp aktiviteter i et nett Noter antatt tidsforbruk per aktivitet (dager) Alle aktiviteter ender i milepæler (M) Før man kan gå fra en milepæl til neste må alle stier til milepælen være komplette. Eks: Aktivitet 9 (T9) kan ikke starte før T3 og T6 er ferdige Minimum tid = den lengste vei i grafen = Kritisk sti Slakk: aktiviteter som ikke ligger på kritisk sti. Dersom det er forsinkelser her vil det ikke påvirke tidsplanen totalt. 29
Personallokering 30
Risikostyring 31
Risikostyring Identisfisere Analysere Planlegge Overvåke 32
Risikofaktorer Risiko Type Beskrivelse Endring i bemanning Styringsendring Hardware Endring i krav Underestimering CASE verktøy Endring i teknologi Prosjekt Prosjekt Prosjekt Prosjekt og produkt Prosjekt og produkt Produkt Forretning Erfarne medarbeidere slutter før prosjektet er ferdig Ny ledelse med andre prioriteringer Nødvendig hardware blir ikke levert til avtalt tid Flere endringer enn planlagt Prosjektet er blitt estimert til mindre enn det viser seg å være Verktøyet dekker ikke behovene Underliggende teknologi erstattes av ny teknologi Konkurranse Forretning Et konkurrerende produkt 33er på markedet før systemet er ferdig
Risikostyringsprosessen Risk identification Risk analysis Risk planning Risk monitoring List of potential risks Prioritised risk list Risk avoidance and contingency plans Risk assessment 34
Analyse-eksempel Risiko Sannsynlighet Følge Umulig å få godt nok kvalifiserte folk høy katastrofal Nøkkelpersoner er syke i prosjektperioden middels alvorlig Komponenter som skal gjenbrukes har alvorlige feil middels alvorlig Omfattende endringer i kravene mye design må gjøres om middels alvorlig Prosjektet er underestimert høy alvorlig Økonomiske problemer i organisasjonen, reduksjon i budsjett lav katastrofal Ikke tid til opplæring av medarbeidere middels akseptabelt 35
Prosjektplan Mal for plan: Wordfil Leveranse: Beskrivelse 36
37
Neste uke Grupper: Begynne å beskrive systemet dere skal lage Begynne med prosjektplanlegging og fylle ut prosjektplan: framdrift, milepæler, risiko og risikohåndtering Forelesning: Objektorientert systemutvikling. Kravspesifikasjon og use case modellering G&H: kap 6, 8 UML Distilled: kap 2, 3 38