•CV=BCWP−ACWP — Kostnadsavvik (positiv = under budsjett)
•SV=BCWP−BCWS — Tidsavvik (positiv = foran plan)
Nøkkelformler per tema
Prosjektkonseptet
•NPV=−I0+t=1∑T(1+r)tCFt — Netto nåverdi for prosjektinvestering
Vanlige feil å unngå
Prosjektkonseptet
•Blander effektmål og resultatmål — effektmål er virkningen ETTER prosjektet, resultatmål er hva prosjektet LEVERER
•Formulerer for vage mål som ikke oppfyller SMARTE/ROTUR — 'forbedre beredskapen' er ikke målbart, mens 'responstid under 8 minutter for 95 % av utrykninger' er det
•Glemmer at effektmål realiseres ETTER prosjektet og at prosjektet alene ikke kan garantere effekten — det krever tiltak i basisorganisasjonen
•Forveksler prosjekttyper i PSO-modellen — et IT-prosjekt er typisk S-prosjekt, men implementering i organisasjonen gjør det til et SO-prosjekt
Prosjektlederen
•Beskriver bare 'god kommunikasjon' uten å konkretisere — sensor forventer spesifikke tiltak som møtestruktur, verktøy og ansvarfordeling
•Glemmer den kulturelle dimensjonen i distribuerte prosjekter — tidssoner, arbeidskulturer og språkbarrierer er reelle utfordringer
•Forveksler prosjektleders og prosjekteiers ansvar — prosjekteier er IKKE operativt ansvarlig for daglig fremdrift
•Diskuterer konflikthåndtering uten å referere til teorien (Thomas-Kilmann eller tilsvarende) — eksamen krever teoriforankring
Prosjektlederen
•Glemmer at storming-fasen er normal og uunngåelig — undertrykker konflikter i stedet for å fasilitere dem
•Antar at smidig metodikk fungerer i alle prosjekter — krever høy psykologisk trygghet og samlokalisert team
Eksamenstips
Prosjektkonseptet
•Effektmål/resultatmål med SMARTE eller ROTUR har kommet på ALLE tre eksamenene (H2024, V2025, H2025) — ha et godt oppsett klart
•Skriv alltid SMARTE-sjekken eksplisitt: 'S: Spesifikt fordi...', 'M: Målbart fordi...' osv. — dette viser sensor at du behersker verktøyet
•Formuler minst ett effektmål og to-tre resultatmål, og vis tydelig kobling mellom dem
Prosjektlederen
•Prosjektleders kompass har kommet eksplisitt på V2025 og implisitt på de andre — ha en klar forståelse av alle fire retninger
•Teambygging-spørsmål krever konkrete tiltak, ikke generelle fraseer — bruk RACI, kickoff, kommunikasjonsplan som eksempler
•Ved konflikthåndtering: beskriv konflikten, identifiser type (sak vs. relasjon), velg strategi fra Thomas-Kilmann og begrunn valget
Prosjektlederen
•Når caset beskriver et nytt eller utfordrende team, anvend Tuckmans faser eksplisitt og kommenter hvilken fase teamet er i nå
•Ved spørsmål om «få teamet til å fungere»: kombiner Tuckman med psykologisk trygghet (Edmondson) — det viser modenhet
•Bruk Belbin når oppgaven nevner rollefordeling eller mangel på spesielle ferdigheter (kreativitet, struktur, samhold)
•Skill alltid mellom oppgaverelaterte og relasjonelle konflikter ved konfliktdrøfting — det er sensors lakmustest
•BV=BCWS−ACWP — Budsjettavvik
•CPI=ACWPBCWP — Kostnadsytelsesindeks (>1 er bra)
•SPI=BCWSBCWP — Tidsytelsesindeks (>1 er bra)
•ECAC=CPIBCAC — Estimert total kostnad
•ETAC=SPIBTAC — Estimert total varighet
•CPIrest=BCAC−ACWPBCAC−BCWP — Nødvendig CPI for å holde budsjett
Nettverksplanlegging
•EF=ES+Varighet — Tidligste slutt
•LS=LF−Varighet — Seneste start
•Slakk=LS−ES=LF−EF — Flyt/slakk
•Forseringskostnad/tidsenhet=Tnormal−TcrashCcrash−Cnormal — Kostnad for forsering
•Koble usikkerhetene til caset — 'motstand fra ansatte' er relevant i KI-prosjektet, 'grunnforhold' er relevant i byggeprosjektet
Avslutning og gevinstrealisering
•Gevinstrealiseringsplan har kommet på H2024 og H2025 — bruk tabellformat med gevinst, type, indikator, ansvarlig og tidspunkt
•Suksessfaktorer ble spurt om på V2025 — ha tre generiske klare (ledelsesstotte, brukermedvirkning, tydelig mandat) som du tilpasser caset
•Erfaringsoverføring ble spurt om på H2024 — koble til Scrum (Sprint Retrospective som læringsarena)
Smidig prosjektledelse (Scrum)
•Spørsmålet «leverandøren skal bruke klassisk Scrum — hva innebærer dette?» besvares systematisk: roller, artefakter, møter, sprintlengde, definisjon av ferdig — og deretter hva det betyr for DEG som kunde (du må stille produkteier, delta i demo hver sprint og akseptere at omfanget ikke er låst)
•Skriv alltid hva som er fast og hva som flyter: i fossefall er omfanget fast og tid/kostnad flyter, i smidig er tid/kostnad fast og omfanget flyter. Dette ene poenget gir uttelling i nesten alle drøftinger
•Bruk casen: pek på hvilke deler av prosjektet som egner seg for Scrum (programvare, tjenestedesign) og hvilke som ikke gjør det (grunnarbeid, støp, myndighetsgodkjenning), og begrunn med kravusikkerhet og delbarhet
•Fartsberegning er enkel matematikk, men husk å oppgi prognosen som et spenn basert på laveste og høyeste observerte fart — det viser modenhet
•Nevner du smidig kontrakt, må du si noe om at fastpris på detaljert kravspesifikasjon ikke lar seg forene med løpende omprioritering
•Blir du bedt om å knytte smidig til kunnskapsoverføring: retrospektivet er den innebygde læringsmekanismen, og demoen er den innebygde kvalitetssikringen
Prosjektleders kompass
•Oppgaven ber nesten alltid om TRE retninger — velg dem ut fra casens kjennetegn og si eksplisitt hvorfor akkurat disse er kritiske i dette prosjektet
•Mange sterke eksterne aktører peker mot «utover», politisk eller uavklart eierskap mot «oppover», stram fastpriskontrakt mot «bakover», nytt fagområde mot «framover»
•Vær konkret på tiltak: navngi møtefrekvens, rapporteringsformat, fullmaktsgrenser og hvem som deltar. Generelle råd om «god kommunikasjon» gir lite uttelling
•Si også hva det koster å nedprioritere de tre andre retningene, og hvordan de dekkes gjennom delegering — det viser lederforståelse
•Koble kompasset til andre pensummodeller: utover = interessentanalyse, oppover = mandat og styringsgruppe, framover = usikkerhetsanalyse, bakover = avviksanalyse og opptjent verdi
•Retningen «innover» blir oftest glemt av kandidatene, og er derfor et enkelt sted å skille seg ut — men bare hvis du knytter den til noe konkret, som prioritering av egen tid og risikoen for å bli flaskehals
Ressursutjevning
•Beregn ALLTID nettverket først (ES, EF, LS, LF, slakk) — uten slakktallene kan du ikke vite hva som kan flyttes
•Tegn histogrammet periode for periode og skriv summen over hver søyle. Sensor må kunne se hvilke perioder som bryter taket
•Kritiske aktiviteter flyttes aldri først. Regelen er minst slakk først: den kritiske går, den med slakk venter
•Ved konflikt om én person: sett den kritiske aktiviteten først. Motsatt rekkefølge kan forlenge prosjektet selv om slakken ser rikelig ut
•Kommenter alltid at aktiviteter du flyttet helt ut i slakken, er blitt kritiske — planen er blitt mer sårbar
•Samme metode gjelder når begrensningen er kroner per uke i stedet for personer. Bytt bare ut «håndverkere» med «kostnad» i histogrammet
•Avslutt med alternativene og en anbefaling: utglatting, innleie eller overtid, forlengelse, eller redusert omfang — med begrunnelse
Investeringsanalyse (NPV)
•Sett opp en tidslinje med alle inn- og utbetalinger før du regner. Investeringen i år 0 skal IKKE diskonteres
•Er kontantstrømmen lik hvert år, spar tid med annuitetsfaktoren r(1+r)T(1+r)T−1 i stedet for å diskontere år for år
•Internrente finnes ved interpolasjon: regn nåverdien ved to renter, én positiv og én negativ, og interpoler mellom dem. Vis begge beregningene
•Oppgaven ber ofte om både nåverdi OG tilbakebetalingstid OG en vurdering. Vurderingen må være begrunnet — et blankt «ja, gjennomfør» gir lite uttelling
•Interne timer og tapt arbeidstid hos deltakerne skal med i kontantstrømmen. Å regne dem som gratis er en klassisk feil
•Nevn hvem som eier gevinsten og når den kan måles — det knytter investeringsanalysen til gevinstrealisering, som ofte er neste deloppgave
•Regn alltid ut hvor mye gevinstene kan svikte før nåverdien blir null. Det er en enkel følsomhetsanalyse som løfter besvarelsen
Suksessfaktorer og suksesskriterier
•Slå fast skillet mellom kriterier (målestokk, måles etterpå) og faktorer (årsak, ledes underveis) i første avsnitt — det er nesten alltid det oppgaven egentlig sjekker
•«Flerdimensjonale suksesskriterier» besvares med de fem dimensjonene, ETT eksempel fra casen per dimensjon, og en begrunnelse for hvorfor flere dimensjoner trengs
•Begrunnelsen for flere dimensjoner er tredelt: ulike interessenter måler ulikt, effekten kommer etter leveransen, og jerntrekanten alene kan gi feil dom
•Bruk strukturen faktor → hvorfor akkurat i denne casen → konkret tiltak → konsekvens hvis den svikter. Tre faktorer behandlet slik slår ti faktorer ramset opp
•Alle kriterier skal ha indikator, målverdi og måletidspunkt. «God brukertilfredshet» er ikke et kriterium; «minst 4,0 av 5 målt 3 måneder etter» er det
•Kobles ofte til gevinstrealisering: dimensjonen forretningsmessig resultat måles først 1–2 år etter, og krever navngitt gevinsteier i linjen
•Husk å nevne at vektingen mellom dimensjonene bør avtales med prosjekteier i tidligfasen