Prompter for Prosjektledelse

Skriv et prosjektmandat for prosjektet [navn på prosjekt] hos [bedrift]. Prosjektmål: [mål]. Prosjekteier: [oppdragsgiver]. Prosjektgruppe: [sammensetning]. Budsjett: [budsjett]. Ønsket ferdigstillelse: [frist]. Bakgrunn for prosjektet: [kontekst].

Struktur: Kontekst og problem som skal løses (3 linjer), målbare resultatmål, omfang (hva er inkludert), hva som eksplisitt er EKSKLUDERT (like detaljert som det inkluderte for å unngå «scope creep»), leveranser med akseptansekriterier, daterte milepæler, roller og ansvar (hvem beslutter, hvem utfører, hvem er rådgivere, hvem skal informeres), identifisert risiko med tiltak ([antatte risikoer]), forutsetninger og avhengigheter.

Formuler hver seksjon slik at eventuell uenighet kommer frem NÅ ved gjennomlesing, heller enn midt i prosjektet. Avslutt med 3 kritiske spørsmål som styringsgruppen må avklare før oppstart.

Transformer mine rånotater fra møtet til et strukturert referat. Møte: [tema for møtet] den [dato], deltakere: [deltakere]. Her er notatene mine: [rånotater].

Format: Beslutninger (tydelig formulert, inkludert hvem som besluttet), tiltak (tabell: oppgave, ansvarlig, frist; hvis noe mangler i notatene, skriv «MÅ AVKLARES» i stedet for å gjette), diskusjonspunkter uten beslutning (maks 2 linjer hver), utsatte punkter med dato for neste diskusjon.

Regler: Maksimalt én side. Ingen omformuleringer som endrer meningen i det som ble sagt. Unngå vage vendinger som «man ble enige om å se nærmere på saken». Avslutt med en liste over «MÅ AVKLARES» som sendes til deltakerne for godkjenning.

Bryt ned følgende prosjekt i arbeidspakker og lag en fremdriftsplan. Prosjekt: [beskrivelse og sluttveleveranse]. Frist: [dato]. Tilgjengelig team: [personer og kapasitet, f.eks. 2 personer i 50 % stilling]. Kjente begrensninger: [f.eks. kundegodkjenning, avhengighet av leverandør, ferieavvikling].

Fremgangsmåte: Del opp i arbeidspakker der hver del produserer en kontrollerbar leveranse (ikke lag en pakke for «koordinering»), bryt hver pakke ned i oppgaver på 0,5 til 3 dager, identifiser avhengigheter mellom oppgaver og den kritiske linjen, legg inn eksplisitt buffer på usikre oppgaver i stedet for skjult buffer overalt.

Lever: Strukturert liste over arbeidspakker og oppgaver med estimater, ukeplan med milepæler for godkjenning, markering av kritisk linje, og de 3 oppgavene som må starte umiddelbart fordi de styrer resten. Gi beskjed dersom fristen [dato] er urealistisk med beskrevne ressurser, bruk tall for å begrunne dette fremfor å presse estimatene.

Skriv en ukentlig statusrapport for prosjektet [navn på prosjekt] til [mottakere, f.eks. styringsgruppen]. Data for uken: Fremdrift [gjort vs. planlagt], utfordringer [problemer], risikoendringer [risiko], budsjettbruk [brukt vs. budsjett], beslutninger som ventes [blokkerende beslutninger og hvor lenge de har ventet].

Strengt format på én side: Prosjektstatus (grønn/gul/rød) med ÉN setning som begrunner fargen, 3 høydepunkter fra uken, fremdrift vs. plan (én linje per aktiv arbeidspakke), risiko og flaskehalser (kun det som er endret siden sist), beslutninger som ventes med navn på beslutningstaker og konsekvens ved forsinkelse, prioriteringer for neste uke.

Regler: Et prosjekt går aldri tilbake til grønt uten å forklare hva som løste problemet. Et gult punkt to uker på rad blir rødt. Ventende beslutninger skal inkludere dato for når forespørselen først ble sendt.

Forbered en evaluering (retrospektiv) for prosjektet [navn på prosjekt] som nettopp er avsluttet [resultat: i tide, forsinket med X, avbrutt]. Deltakere: [deltakere og roller]. Varighet: [f.eks. 1,5 time]. Viktige hendelser: [hva gikk bra/dårlig, eventuelle gnisninger].

Lever: En detaljert agenda (åpning med fokus på «vi leter etter årsaker, ikke syndebukker», individuell refleksjon før felles diskusjon for å unngå gruppetenkning, diskusjon av hovedpunkter, beslutninger), de nøyaktige spørsmålene som må stilles for å unngå floskler («når visste vi egentlig at tidsplanen sprakk? hva hindret oss i å si fra?»), og en teknikk for å snakke om [eventuelt sensitivt tema] uten at det blir en rettssak.

Format for lærdom: Hvert punkt skal gjøres om til en kjøreregel for neste prosjekt («for fremtiden skal vi...»), med en ansvarlig for implementering. Maks 5 regler: flere enn det vil ikke bli fulgt.

Du er en erfaren prosjektdirektør. Hjelp meg å bygge en mulighetsstudie for prosjektet [navn på prosjekt] vurdert av [bedrift]. Problem eller mulighet i bunn: [kontekst]. Forventede gevinster: [hva håper vi på]. Maksimalt budsjett: [beløp]. Kjente alternativer: [alternativer, inkludert å ikke gjøre noe].

Strukturer dokumentet i 6 deler: Problemet som skal løses og kostnaden ved å la være, mulige opsjoner (inkludert status quo) med fordeler og ulemper, grovt estimat på kostnad og tid per opsjon (intervaller), forventede gevinster knyttet til målbare indikatorer, hovedrisiko for hver opsjon, begrunnet anbefaling.

Krav: Hver gevinst må knyttes til en kontrollerbar indikator, ellers klassifiseres den som «ikke-målbar antakelse». Formuler 5 go/no-go beslutningskriterier som komiteen kan sjekke av. Avslutt med en liste over manglende informasjon som svekker studien og hvem som må levere denne.

Skriv et prosjektskjema på én side for et mindre prosjekt. Prosjekt: [beskrivelse i 2 setninger]. Bestiller: [bestiller]. Involverte personer: [personer og tilgjengelig tid]. Ønsket ferdigstillelse: [dato]. Eventuelt budsjett: [beløp eller ingen].

Format: Maksimalt én side. Mål i én målbart setning, sluttveleveranse og hvordan vi ser at den er ferdig, hva som er utenfor omfang (minst 3 linjer, dette er den viktigste delen), hvem som tar beslutninger ved uenighet, milepæler (maks 3), hovedrisiko og tiltak.

Krav: Ingen prosjektledelses-sjargong, bruk språk som alle forstår. Hvis informasjonen min ikke er tilstrekkelig for et punkt, skriv «MÅ AVKLARES med [person]» i stedet for å finne på noe. Avslutt med 2 spørsmål som må stilles bestiller før start.

Jeg starter prosjektet [navn på prosjekt] for [bedrift] og skal kartlegge behov før omfanget låses. Personer som skal intervjues: [liste over profiler, f.eks. ledelse, sluttbrukere, support, IT]. Forventet leveranse: [antatt leveranse]. Tilgjengelig tid per intervju: [varighet].

Lag en tilpasset intervjuguide for hver profil: 8 til 10 åpne spørsmål fra det generelle til det spesifikke. Skill mellom spørsmål om dagens situasjon (problemer, manuelle løsninger, volum) og fremtidige behov. Legg til 2 «kontrollspørsmål» per profil for å avdekke skjulte behov, f.eks. «hva gjør du når dagens verktøy ikke strekker til?».

Krav: Unngå ledende spørsmål og ja/nei-spørsmål. Lag også en mal for oppsummering: uttalte behov, avledede behov, motstridende behov mellom profiler, og talende sitater.

Gjør disse behovene om til brukerhistorier (user stories) som et utviklingsteam kan bruke. Prosjekt: [navn og kort beskrivelse]. Brukere: [brukerprofiler]. Behov: [liste over behov, selv om de er vage].

For hvert behov, produser: Brukerhistorie i formatet «Som [profil], ønsker jeg [handling], slik at [verdi]», 3 til 5 akseptansekriterier formulert binært (kan sjekkes med ja eller nei, ikke bruk ord som «rask» eller «brukervennlig» uten terskelverdier), og spørsmål til bestiller dersom behovet er for uklart.

Krav: En historie må kunne gjennomføres på få dager, foreslå ellers oppsplitting. Påpek behov som egentlig er ferdige løsninger og omformuler dem til faktiske behov. Presenter resultatet i en tabell: Historie, akseptansekriterier, estimert størrelse (S/M/L), åpne spørsmål. Avslutt med en liste over avhengigheter mellom historiene.

Hjelp meg å prioritere backloggen for prosjektet [navn på prosjekt]. Oppgaver som venter: [liste over forespørsler med kort beskrivelse]. Teamets kapasitet: [kapasitet, f.eks. 15 dagsverk per måned]. Hovedmål for kvartalet: [mål]. Interne interessenter som presser på: [eventuell politisk kontekst].

Evaluer hvert punkt på to akser: Verdi (bidrag til kvartalsmål, antall berørte brukere, kostnad ved å ikke løse problemet) og estimert innsats (relativ størrelse). Sorter i 4 kategorier: Gjør nå (høy verdi, lav innsats), planlegg (høy verdi, høy innsats), fyllmasse (lav verdi, lav innsats), og avvis/utsett eksplisitt (lav verdi, høy innsats).

Krav: Press fra interessenter er ikke et verdikriterium, men list opp avslag som krever en forklarende melding. Lag tabellen med begrunnelse per linje, og skriv deretter de 3 vanskeligste avslagene på en kort og saklig måte.

Lag et veikart (roadmap) for de neste 2 kvartalene for [produkt eller prosjekt] hos [bedrift]. Årsmål: [mål]. Mulige prosjekter: [liste over kandidater]. Teamets kapasitet: [størrelse og tilgjengelighet]. Allerede inngåtte avtaler: [ufravikelige forpliktelser].

Organiser veikartet per kvartal. Formuler hvert punkt som et forventet resultat, ikke en funksjon («redusere saksbehandlingstid» i stedet for «utvikle modul X»). Per kvartal: Maks 2-3 hovedpunkter, ønsket resultat, indikator for suksess, avhengigheter.

Krav: Hold av 20 % av kapasiteten til uforutsette ting og skriv dette eksplisitt. List opp hva som bevisst er utelatt og hvorfor. Lag to versjoner: En detaljert for teamet og en på 5 linjer for ledelsen. Marker prosjekter der verdien er for uklar til å prioriteres ennå.

Hjelp meg å estimere ressursbehovet for prosjektet [navn på prosjekt]. Innhold: [liste over arbeidspakker eller oppgaver]. Team: [profiler og erfaring]. Historikk: [sammenlignbare prosjekter og faktisk tidsbruk, hvis kjent].

For hver arbeidspakke: Gi et estimat i intervall (optimistisk, sannsynlig, pessimistisk) heller enn ett tall. Oppgi forutsetninger (hva må være sant for at det skal holde) og faktorer som kan føre til det pessimistiske scenarioet.

Krav: Hvis historikk finnes, sammenlign estimatet med faktisk tidsbruk tidligere og forklar avviket. Legg systematisk til tid som ofte glemmes: feilretting etter test, koordinering, opplæring, planlagt fravær. Presenter totalen i 3 scenarioer med prosentvis avvik mellom optimistisk og pessimistisk. Hvis avviket er over 100 %, nevn hvilken info som trengs for å redusere usikkerheten.

Sett opp et komplett budsjett for prosjektet [navn på prosjekt] hos [bedrift]. Planlagte interne timer: [timer per profil og timepris hvis kjent]. Eksterne kjøp: [liste]. Varighet: [varighet]. Ramme: [beløp].

Lag først budsjettet per post: Interne kostnader, eksterne tjenester, lisenser/verktøy, andre kostnader, og en buffer for uforutsette utgifter (begrunn prosentsatsen ut fra usikkerhet). Sjekk om dette samsvarer med rammen og varsle om eventuelle overskridelser med en gang.

Lag deretter en modell for månedlig oppfølging: Tabell for brukt vs. budsjett per post, estimat på gjenstående arbeid (ikke bare gjenstående penger), prognose for sluttsum, og 2 terskelverdier som utløser varsling til prosjekteier. Avslutt med de 3 vanligste årsakene til budsjettsprekk i slike prosjekter og hvordan de oppdages tidlig.

Opprett et risikoregister for prosjektet [navn på prosjekt]. Kontekst: [beskrivelse, frist, viktighet]. Antatte risikoer: [identifiserte risikoer]. Eksterne avhengigheter: [leverandører, andre team, godkjenninger].

Utfyll listen min med typiske risikoer for denne typen prosjekt innen 4 kategorier: Menneskelige (oppsigelser, overbelastning, manglende kompetanse), tekniske, organisatoriske (beslutningsvegring, scope creep), og eksterne. For hver risiko: Konkret beskrivelse av hva som skjer, sannsynlighet (lav/middels/høy), konsekvens (lav/middels/høy), risikoverdi, tidlige varselstegn, forebyggende tiltak, kriseplan (hvis risikoen inntreffer), og ansvarlig.

Krav: Formuler hver risiko som en hendelse («leverandøren leverer én måned for sent»), aldri som et vagt tema («forsinkelser»). Sorter etter viktighet og begrens listen til de 10 viktigste. Spesifiser rutine for gjennomgang: hyppighet og spørsmål som skal stilles.

Kartlegg interessentene i prosjektet [navn på prosjekt] hos [bedrift]. Identifiserte aktører: [liste over personer eller enheter]. Hva prosjektet endrer for dem: [antatt påvirkning]. Kjente støttespillere og motstandere: [kontekst].

Plasser hver aktør på to akser: Innflytelse (kan de stoppe eller akselerere prosjektet?) og holdning (støttende, nøytral, skeptisk). For hver innflytelsesrik aktør: Hva har de å vinne eller tape, sannsynlig motargument formulert med deres egne ord, og tilpasset tiltak (involvering i beslutninger, fast info, en-til-en samtale før lansering).

Krav: Ikke forveksle organisasjonskartet med reell innflytelse; påpek aktører uten formell tittel som har stor påvirkningskraft. Lag planen i en tabell: Aktør, nåværende posisjon, nødvendig posisjon for suksess, tiltak, ansvarlig, frist. Avslutt med de 2 viktigste personene å snakke med denne uken.

Lag en kommunikasjonsplan for prosjektet [navn på prosjekt]. Målgrupper: [f.eks. prosjekteier, team, berørte brukere, andre avdelinger]. Prosjektets varighet: [varighet]. Kjente milepæler: [lansering, viktige datoer]. Tilgjengelige kanaler: [f.eks. møter, e-post, intranett, Slack/Teams].

Definer for hver målgruppe: Hva de trenger å vite (og kun det), hyppighet, kanal, format (2 linjer, én side, møte), og hvem som sender meldingen. Skill mellom løpende kommunikasjon (fremdrift) og hendelsesbasert kommunikasjon (oppstart, feil, ferdigstillelse).

Krav: All kommunikasjon må svare på mottakerens spørsmål «hva betyr dette for meg?», ellers skal det fjernes fra planen. Skriv utkast til oppstartsmelding og lanseringsmelding. Presenter planen i en tabell, og list opp de 3 vanligste kommunikasjonsfeilene i slike prosjekter og hvordan denne planen unngår dem.

Lag en RACI-matrise for prosjektet [navn på prosjekt]. Hovedaktiviteter: [liste over aktiviteter eller leveranser]. Aktører: [personer eller funksjoner]. Kjente uklarheter: [f.eks. to personer tror de bestemmer over samme tema].

For hver aktivitet, tildel roller: R (Responsible/Utfører), A (Accountable/Beslutter og ansvarlig – kun én per linje), C (Consulted/Rådgiver før), I (Informed/Informeres etterpå). Forklar kort tildelinger som ikke er åpenbare.

Kvalitetskrav: Aldri to A-er på samme linje. Ingen linjer uten en R. Påpek hvis noen er C på nesten alt (flaskehals) eller hvis noen mangler roller helt. Presenter matrisen i en tabell. List opp de 3 punktene med størst risiko for konflikt og din anbefaling for å sikre disse. Nevn spørsmål som må avklares i teamet før matrisen sendes ut.

Forbered oppstartsmøtet for prosjektet [navn på prosjekt]. Deltakere: [deltakere og roller]. Varighet: [f.eks. 1 time]. Status på planlegging: [mandat godkjent eller under arbeid]. Sensitive punkter: [spenninger, skepsis, tidligere mislykkede prosjekter].

Lever: Detaljert agenda (hvorfor dette prosjektet nå, konkret sluttresultat, hva som er utenfor omfang, hvem gjør hva, milepæler, kjøreregler for teamet, spørsmål), de 3 viktigste budskapene deltakerne skal sitte igjen med, og hvordan man håndterer [sensitivt punkt] uten at det ødelegger møtet.

Krav: Kick-off skal ikke være en enveis presentasjon. Legg inn 2 punkter der deltakerne bidrar (f.eks. lyn-risikoanalyse). Lag også utkast til invitasjon med agenda og forberedelser, samt en liste over hva som MÅ være avklart FØR møtet for å unngå et uklart prosjekt.

Forbered neste styringsgruppemøte for prosjektet [navn på prosjekt]. Deltakere: [medlemmer]. Varighet: [varighet]. Status: [fremdrift, utfordringer, budsjett]. Beslutninger jeg trenger: [beslutninger med alternativer]. Temaer som kan ta for mye tid: [sensitive temaer].

Lag en agenda basert på beslutninger, ikke status: Hver beslutning får et eget punkt med tid, forberedte alternativer (2-3 stykk med fordeler/ulemper og anbefaling), og konsekvens dersom beslutningen utsettes. Statusgjennomgang gjøres på maks 10 minutter basert på dokumenter sendt på forhånd.

Lever: Agenda med tidsbruk, nøyaktig formulering av beslutningsbehov, teknikk for å avbryte digresjoner om [sensitivt tema] på en høflig måte, og mal for beslutningsreferat som skal sendes innen 24 timer. Avslutt med liste over hva som må sendes deltakerne 48 timer før møtet.

Strukturer presentasjonen til styringsgruppemøtet for [navn på prosjekt]. Månedsdata: Fremdrift [gjort vs. plan], budsjett [brukt vs. totalt], risiko [status], beslutninger som trengs [liste], høydepunkter [hendelser].

Lag en oversikt over 10 lysbilder: Oppsummering (statusfarge, hovedbudskap, beslutninger), fremdrift per arbeidspakke med avvik, budsjettutvikling, risiko med endret verdi, dypdykk i månedens største utfordring med anbefaling, beslutningspunkter (ett per bilde), neste steg.

For hvert bilde: Tittel formulert som et budskap («Arbeidspakke 2 tar igjen forsinkelsen», ikke «Status AP2»), innhold i maks 5 kulepunkter, og hva som skal sies muntlig (som ikke står på bildet). Krav: Ingen repetisjon av kontekst som alle kjenner. Bruk avrundede tall. Avslutt med en sjekk: Hvis de kun leser bilde 1, har de fått med seg det viktigste?

Etabler en rutine for endringshåndtering i prosjektet [navn på prosjekt]. Kontekst: [kilde til endringer, f.eks. kunden legger til ønsker fortløpende, ledelsen ombestemmer seg]. Eksisterende fora: [møter]. Tilgjengelig buffer: [tid og penger].

Definer: Et minimalt endringsskjema (beskrivelse, hvem spør, begrunnelse, reell hast), 4 faste spørsmål for vurdering (konsekvens for tid, budsjett, andre deler av prosjektet, og hva skjer om vi sier nei), hvem som beslutter ut fra konsekvensens størrelse (foreslå beløpsgrenser), og hvordan beslutninger logges.

Skriv også 3 standard svar: Endring akseptert med konsekvens, endring utsatt til senere fase, endring avvist med begrunnelse. Krav: Rutinen må få plass på en halv side. Ingen endringer skal aksepteres muntlig uten å logges. Avslutt med hvordan man presenterer dette for den mest krevende interessenten uten å skape dårlig stemning.

Hjelp meg å forberede forhandling om en urealistisk frist. Prosjekt: [navn på prosjekt]. Ønsket frist: [dato]. Min vurdering: Vi trenger [realistisk tid] fordi [årsaker: estimert arbeidsmengde, avhengigheter, teamets kapasitet]. Prosjekteier: [profil og hva de er opptatt av]. Bakgrunn for datoen: [hvorfor akkurat denne datoen, hvis kjent].

Lag: En faktabasert fremstilling av gapet (arbeidsmengde vs. kapasitet med enkle tall), og 3 ærlige alternativer: Hold datoen ved å redusere omfanget (spesifiser hva som tas ut), hold omfanget ved å flytte datoen, eller øk ressursene med kostnad og begrensninger (nye folk er ikke produktive fra dag én).

Krav: Aldri si «det er umulig» uten alternativer. Aldri aksepter et kompromiss i møtet uten at det er regnet på. Forbered svar på 3 sannsynlige innvendinger, inkludert «finn en løsning» og «vi får se hvordan det går». Format: Én side argumentasjon pluss tabell med de 3 alternativene.

Lag en innhentingsplan for prosjektet [navn på prosjekt], som er [varighet] forsinket mot fristen [dato]. Årsaker: [årsaker til forsinkelse]. Gjenstående arbeid: [oppgaver med estimater]. Team: [sammensetning]. Handlingsrom: [mulig ekstra budsjett, hva kan forhandles på omfang].

Start med en diagnose: Skyldes forsinkelsen for lave estimater, scope creep, manglende ressurser eller eksterne blokkeringer? Svaret styrer planen. Lag deretter planen basert på reelle virkemidler: Kutt i omfang, endret rekkefølge for å jobbe parallelt, fjerning av unødvendige oppgaver, eller målrettet forsterkning kun på kritisk linje.

Krav: Forbudt å «presse» eksisterende estimater uten begrunnelse. Forbudt å kutte i testfase. Lever: Ny og pålitelig fremdriftsplan, hva som er ofret for å få det til, 2 forutsetninger for at planen skal holde, og en melding til prosjekteier som tar ansvar for forsinkelsen uten å bortforklare.

Forbered eskalering av en blokkering i prosjektet [navn på prosjekt]. Blokkering: [beskrivelse, f.eks. manglende beslutning, ressurser ikke tildelt]. Varighet: [siden dato]. Hva er forsøkt: [oppfølging og tiltak]. Mottaker av eskalering: [person og nivå]. Involverte parter: [aktører og eventuelle gnisninger].

Skriv meldingen: Oppsummering av blokkeringen (3 saklige linjer med datoer), konkrete konsekvenser av å vente (tapte dager, kostnad, truede milepæler), 2-3 alternativer for løsning med min anbefaling, og hvilken beslutning som trengs innen når.

Krav: Ingen personangrep; la fakta og datoer tale for seg. Mottakeren skal kunne ta en beslutning kun ved å lese denne meldingen. Lag også en 60-sekunders muntlig versjon, og en melding til de involverte slik at de ikke blir overrasket over eskaleringen.

Organiser oppfølging av tiltak i prosjektet [navn på prosjekt] mellom møtene. Dagens situasjon: [f.eks. oppgaver blir bare halvferdige, purringer føles som kontrollering]. Møtefrekvens: [hvor ofte]. Verktøy: [f.eks. Excel, Planner, Jira, Slack/Teams].

Foreslå et komplett system: Format på tiltakslisten (oppgave med verb og kontrollerbar leveranse, én ansvarlig, frist, status), rutine for oppdatering (hvem, når, tidsbruk), og en gradvis purre-mekanisme: Automatisk påminnelse 2 dager før frist, individuell saklig melding på fristdagen, og nevnelse i møte først ved andre gangs overskridelse.

Lag maler for purremeldinger på 3 nivåer, korte og uten bebreidelse. Krav: Oppgaver uten frist eller ansvarlig avvises umiddelbart. Listen skal ikke overstige det teamet faktisk kan håndtere. Avslutt med hvordan dette presenteres for teamet som en støtte heller enn kontroll.

Design et dashboard for prosjektet [navn på prosjekt]. Prosjekttype: [type og leveranse]. Varighet: [varighet]. Kritiske punkter: [f.eks. stram tidsplan, budsjett, kvalitet]. Tilgjengelige data: [kilder: timelister, budsjettverktøy, Jira/Planner].

Velg ut maks 6-8 indikatorer fordelt på 3 blokker: Fremdrift (faktiske leveranser ferdigstilt vs. plan, ikke prosentvis fullføring av påbegynte oppgaver), Helse (forsinkede oppgaver, ventende beslutninger og alder på disse, økende risiko), Ressurser (brukt vs. budsjett, arbeidsbelastning i teamet).

For hver indikator: Definisjon, kilde, oppdateringsfrekvens, begrunnet varslingsgrense. Krav: Dropp subjektive mål («80 % ferdig») til fordel for binære (ferdig/ikke ferdig). Hver indikator må utløse en mulig handling når den blir rød. Beskriv en 15-minutters ukentlig gjennomgang: Rekkefølge, spørsmål og når man skal varsle utenfor teamet.

Skriv en månedsrapport for prosjektet [navn på prosjekt] til [mottakere, f.eks. ledergruppen]. Månedsdata: Leveranser [hva er gjort], avvik [forsinkelser/overskridelser], budsjett [brukt vs. plan], risiko [endringer], beslutninger tatt [liste], varsler [kritiske punkter].

Format: Én side. Overordnet kurs i 2 setninger (vil prosjektet lande på tid og budsjett, ja/nei, og hva har endret seg denne måneden), månedens leveranser knyttet til milepæler, avvik med årsak og tiltak (ingen avvik uten plan), budsjettstatus med prognose for slutt, varsler som krever ledelsens involvering med eksplisitt forespørsel.

Krav: Ledelsen leser mange slike rapporter; unngå selvskryt og fyllmasse. Hvert varsel må føre til et konkret behov (beslutning, ressurser). Avvik og dårlige nyheter skal stå først, ikke gjemmes nederst på siden.

Hjelp meg å prioritere ressurser mellom flere konkurrerende prosjekter. Pågående prosjekter: [liste med frist, viktighet og status]. Delte ressurser: [personer som jobber på flere prosjekter og dagens fordeling]. Konflikt: [beskrivelse av ressurskonflikten]. Hvem tar den endelige avgjørelsen: [instans eller person].

Lag først et ærlig situasjonsbilde: Hvem jobber med hva i reell prosent (ikke teoretisk), og hvor er folk booket over 100 %. Foreslå deretter en prioriteringsmatrise basert på: Verdi for bedriften, kostnad ved forsinkelse, tidsvindu (mulighet som lukkes), og eksterne forpliktelser.

Bruk matrisen på dagens konflikt og lag 2 scenarioer for ressursfordeling. Vis tydelig hva hvert prosjekt vinner og taper i hvert scenario, inkludert ny sluttdato. Krav: Ikke løs konflikten ved å overbelaste folk eller love 50 % på 3 ulike prosjekter. Valgt scenario må kunne begrunnes overfor prosjektlederne som «taper» kampen om ressursene.

Forbered planlegging av neste sprint for teamet [team] i prosjektet [navn på prosjekt]. Sprintlengde: [varighet]. Kapasitet: [personer til stede, planlagt fravær, faste oppgaver utenom sprint: support, møter]. Prioritert backlog: [oppgaver med estimert størrelse]. Rest fra forrige sprint: [uferdige oppgaver].

Strukturer møtet: Beregn reell kapasitet (tilgjengelig tid minus faste oppgaver og buffer for uforutsette ting), formuler sprintmålet i én setning som beskriver resultatet (ikke en liste med oppgaver), velg oppgaver innenfor kapasitetsgrensen (start med rest fra sist), sjekk at alle oppgaver er forstått og godt nok definert til å starte.

Krav: Avvis oppgaver uten akseptansekriterier. Hvis bestiller presser på for mer enn kapasiteten tillater, må svaret være et valg mellom oppgaver, aldri en stille aksept av overtid. Lever agenda for møtet, forslag til sprintmål, og 3 tegn i løpet av sprinten på at målet ikke vil nås.

Forbered evaluering (retrospektiv) for teamet [team]. Varighet: [f.eks. 45 min]. Stemning i teamet: [kontekst, f.eks. slitent rituale der ingen sier noe, nylige gnisninger, nytt team]. Hendelser i sprinten: [hva skjedde]. Tiltak fra forrige gang: [status på disse].

Lever: Detaljert agenda som starter med status på forrige retrospektivs tiltak (hvis tiltak aldri gjøres, dør ritualet). Velg et format tilpasset [stemning i teamet] med instruksjoner, oppfølgingsspørsmål når diskusjonen blir overflatisk, og metode for utvelgelse: Maks 2 forbedringstiltak valgt av teamet, hver med ansvarlig og frist i neste sprint.

Krav: Ingen vage tiltak som «kommunisere bedre»; hvert tiltak skal beskrive en observerbar endring. Temaer utenfor teamets kontroll (organisasjon, ledelse) logges separat for eskalering, ikke dvel ved dem. Foreslå 2 alternative formater for å variere ritualet fremover.

Sett rammene for det daglige statusmøtet (daily standup) for teamet [team] i prosjektet [navn på prosjekt]. Dagens situasjon: [f.eks. møtet varer i 30 minutter, føles som rapportering til sjefen, folk faller av]. Teamstørrelse: [antall]. Arbeidsform: [kontor, hjemmekontor, hybrid].

Foreslå målformat: Maks varighet, fast tidspunkt, og fokus på koordinering: Hva ble ferdig i går, hva blokkerer eller kan blokkere i dag, hva trenger jeg hjelp til fra andre. Alt som ikke er koordinering (tekniske diskusjoner, problemløsning) noteres og tas etter møtet med kun de berørte.

Gi: Kjøreregler som hindrer rapportering til sjefen (teamet snakker til hverandre, rullerende møteleder), setninger for å avbryte digresjoner høflig, tilpasninger for [arbeidsform], og 3 tegn på at møtet har mistet sin verdi med tiltak for hvert tegn. Avslutt med en melding til teamet som forklarer det nye formatet uten å kritisere det gamle.

Hjelp teamet [team] med å definere «Definition of Done» (DoD) for prosjektet [navn på prosjekt]. Type leveranser: [f.eks. programvare, kursmateriell, utredninger]. Kjente problemer: [f.eks. oppgaver meldes ferdig men må åpnes igjen, ujevn kvalitet, feil oppdages sent].

Bygg en DoD i 3 nivåer: Hva gjør en oppgave «ferdig» (sjekkliste: fagfellevurdering, testet, dokumentert, godkjent av hvem), hva som eksplisitt er utelatt for å være realistisk, og godkjente unntak med regler for hvordan disse logges i stedet for å skjules.

Krav: Maks 8 kriterier, alle skal kunne sjekkes med ja/nei. Ingen kriterier som teamet ikke har ressurser til å oppfylle (da vil de bli ignorert ved første tidspress). Lever også: Metode for å få teamet til å eie definisjonen (workshop), regler for pågående arbeid, og rutine for revisjon etter noen uker.

Organiser brukertest (UAT) for prosjektet [navn på prosjekt]. Leveranse som skal testes: [beskrivelse]. Testere: [profiler og tilgjengelighet]. Planlagt varighet: [varighet]. Eksisterende akseptansekriterier: [kriterier, eller ingen].

Lag: En testplan med testcaser basert på reelle brukssituasjoner (ikke per skjermbilde), hver case beskrevet med inndata, handling og forventet resultat; prioritering av caser (kritisk for lansering, viktig, kjekt å ha); regler for klassifisering av feil med eksempler for å unngå diskusjoner; rutine for feilretting og re-testing.

Lever også mal for akseptanseprotokoll: Hva er testet, feil per nivå, beslutning (godkjent, godkjent med merknader og dato for utbedring, avvist) og signaturer. Krav: En test uten realistiske data beviser ingenting; forklar hvordan testdata forberedes. Merknader må ha ansvarlig og frist, ellers blir de aldri løst.

Forbered lanseringsplan for [leveranse/system] i prosjektet [navn på prosjekt]. Planlagt dato: [dato]. Berørte brukere: [hvem og hvor mange]. Tilgjengelig tidsvindu: [f.eks. helg, natt, kontortid]. Aktører: [personer og roller]. Mulighet for tilbakerulling (rollback): [ja/nei/delvis, og hvordan].

Lag: Sjekkliste for forberedelser (tekniske krav, godkjenninger, kommunikasjon, backup sjekket, nøkkelpersoner tilgjengelige), lanseringsplan time-for-time med ansvarlig og suksesskriterium for hvert steg, go/no-go beslutningspunkter (hvem bestemmer og hva kreves), plan for tilbakerulling (hvilke tegn utløser dette og hvordan gjøres det), og overvåking de første dagene.

Krav: Hvert steg må ha et kontrollerbart suksesskriterium. Tilbakerulling må beskrives like detaljert som selve lanseringen, da denne utføres under stress. Avslutt med utkast til melding til brukerne før og etter lansering.

Sikre driftskontinuitet under migrasjon fra [gammelt system/prosess] til [nytt system/prosess] hos [bedrift]. Planlagt overgangsperiode: [varighet]. Kritiske aktiviteter: [aktiviteter som ikke kan stoppe]. Berørte team: [team]. Kjente risikoperioder: [f.eks. årsoppgjør, høysesong].

Svar på spørsmålene som ofte velter overganger: Hvilket system er «master» for ulike data i overgangsfasen (klare regler), hvordan unngå dobbelregistrering (eller hvordan organisere det hvis det er nødvendig), hvem håndterer saker som startet i gammelt og slutter i nytt system, og hvordan fryses/synkroniseres data ved endelig overgang.

Lever: Tabell over kritiske aktiviteter med driftsmodus under overgangen, regler for datakvalitet per tilfelle, plan for utvidet brukerstøtte de første ukene, og de 3 mest sannsynlige feilscenarioene med tiltaksplan for hver.

Forbered avslutning av prosjektet [navn på prosjekt], der leveransen ble godkjent [dato]. Prosjektelementer: [involverte leverandører, budsjett, dokumentasjon, team]. Gjenstående punkter: [eventuelle merknader fra akseptansetesten].

Lag en komplett sjekkliste for avslutning: Kontrakter (sluttoppgjør leverandører, lukking av merknader, fjerning av tilganger for eksterne), Økonomi (stoppe timeføring, regnskap brukt vs. budsjett med forklaring på avvik, lukke budsjettposter), Dokumentasjon (arkivering, hva skal være søkbart om 2 år og for hvem), Personell (omplassering av teammedlemmer, personlig takk på riktig nivå), Overlevering (hvem overtar driftsansvar og support).

Krav: Skill mellom hva som blokkerer avslutning og hva som kan gjøres etterpå. Et prosjekt som er «98 % ferdig» i 6 måneder er dyrt; sett en endelig sluttdato. Lever også mal for sluttrapport på én side: Nøkkeltall, suksesser, avvik og hvor lærdom er arkivert.

Organiser overlevering av prosjektet [navn på prosjekt] fra [utgående leder] til [innkommende leder]. Bakgrunn for bytte: [årsak og tilgjengelig tid]. Prosjektstatus: [fremdrift, kritiske punkter, kommende milepæler]. Mulig overlapp: [varighet].

Lag en overleveringspakke som prioriterer det som ikke står i dokumentene: Beslutningshistorikk og begrunnelser, muntlige avtaler med kunde eller prosjekteier, sensitive personrelasjoner og politikk, risikoer som overvåkes uformelt, og reell status på arbeidspakker utover offisiell rapportering.

Planlegg overlappet: Møter der utgående leder introduserer innkommende personlig (prosjekteier, kunde, team), rekkefølge på temaer etter viktighet, og melding om byttet som skaper trygghet. Krav: Overleveringen skal verifiseres; lag en liste med spørsmål som ny leder må kunne svare på etter overlappet. List opp det som ikke ble overlevert med kontaktinfo for nødstilfeller.

Forbered oppstart for [nyansatt, profil] som blir med i prosjektet [navn på prosjekt] den [dato]. Prosjektstatus: [fremdrift og kontekst]. Forventet rolle: [oppgaver]. Teamets tilgjengelighet for oppfølging: [reell begrensning].

Lag en plan for de 2 første ukene: Pensumliste for dag 1 (mandat, siste statusrapport, risikoregister, ordliste), 4 møter med nøkkelpersoner og mål for hvert møte, en første nyttig og avgrenset oppgave i uke 1 (velg ut fra [rolle]), og en fadder med 10 minutter daglig sjekk.

Krav: Unngå 15 passive møter på rad; man lærer best ved å gjøre. Forklar det som ingen sier høyt: Relasjoner mellom aktører, sensitive temaer, og hvordan beslutninger egentlig tas. Lever fremdriftsplan for 2 uker, prioritert leseliste, og spørsmål den nyansatte bør kunne svare på etter 15 dager for å bekrefte god oppstart.

Hjelp meg å håndtere en konflikt i prosjektteamet mitt. Kontekst: [saklig beskrivelse av konflikten mellom to personer, uten dømming] i prosjektet [navn på prosjekt]. Effekt på prosjektet: [f.eks. informasjon holdes tilbake, anspent stemning i møter, forsinkelser]. Min rolle: [prosjektleder, med/uten personalansvar]. Historikk: [hvor lenge har det vart, hva er prøvd].

Foreslå en tretrinns plan: Først individuelle samtaler (spørsmål for å forstå hver versjon uten å ta parti, unngå fellen med å være dommer), deretter felles møte (rammer for møtet, hvordan holde fokus på fakta når det blir personlig, hvordan lande 2-3 konkrete kjøreregler), og til slutt oppfølging (hvordan sjekke at avtalen holdes uten å overvåke).

Krav: Hold deg til rollen som prosjektleder; saker som hører hjemme hos HR eller linjeleder skal identifiseres og sendes videre. Ingen av partene skal utpekes som skyldig foran teamet. Angi tegn på når saken må eskaleres umiddelbart.

Hjelp meg å følge opp en leverandør som ikke leverer i prosjektet [navn på prosjekt]. Leverandør: [selskap og tjeneste]. Avvik: [daterte fakta: forsinkelser, manglende kvalitet, bytte av kontaktperson, brutte løfter]. Kontrakt: [hva sier avtalen om leveranser, frister, bøter]. Avhengighet: [hvor lett kan de byttes ut].

Lag en trappetrinnsplan: Først et korrigeringsmøte (saklig liste over avvik mellom avtale og faktiske leveranser med datoer; agenda for møtet som krever en tidsfestet forbedringsplan heller enn unnskyldninger), deretter tett oppfølging (korte milepæler, klare kriterier for å friskmelde leveransen, skriftlig referat etter hvert punkt), og til slutt forberedelse av alternativ dersom de ikke forbedrer seg (startes diskret nå hvis avhengigheten er stor).

Krav: Alt dokumenteres skriftlig etter muntlig dialog; dette er bevis ved eventuell tvist. Vær saklig og hold deg til kontrakten. Lever: Tabell over avvik, utkast til innkalling, møteagenda, og objektive kriterier for å avslutte samarbeidet.

Skriv en kravspesifikasjon for anskaffelse av [tema, f.eks. nytt nettsted, verktøy, tjeneste] for [bedrift]. Behov: [beskrivelse av behov og problem]. Teknisk og organisatorisk kontekst: [dagens situasjon, begrensninger]. Budsjettramme: [intervall eller ikke oppgitt]. Tidsplan: [frister].

Struktur: Presentasjon av bedriften og kontekst (halv side), problemet som skal løses og mål formulert som ønskede resultater (beskriv behovet, ikke løsningen, med mindre det er tvingende grunner), omfang og avgrensninger, ufravikelige krav (tekniske, lovpålagte, tidsmessige), forventede leveranser, utvelgelseskriterier med vekting, prosess for anbudet (spørsmålsfrist, innlevering, presentasjoner), og krav til format på tilbudet for enkel sammenligning.

Krav: Hvert krav må kunne testes ved levering. Skill mellom «må-krav» og «bør-krav». Avslutt med 5 spørsmål til leverandørpresentasjonen som avslører om de faktisk har forstått behovet.

Lag en sammenligningsmatrise for tilbudene på [tema for anbudet]. Tilbud: [antall tilbud og kort oppsummering: pris, tid, tilnærming]. Viktige kriterier for oss: [prioriteringer, f.eks. overholdelse av frist, oppfølging, totalkostnad, soliditet]. Observasjoner: [f.eks. ett tilbud er mistenkelig lavt, ett er veldig generelt].

Bygg matrisen: Kriterier gruppert i kategorier (forståelse av behov, foreslått metodikk, teamets faktiske erfaring, totalkostnad over tid inkludert det som ikke står i tilbudet, relevante referanser, kontraktsvilkår), begrunnet vekting, og poengskala med beskrivelse for å redusere subjektivitet.

Bruk matrisen på de beskrevne tilbudene og påpek: Uforklarte prisavvik (lav pris betyr ofte redusert omfang, lag kontrollspørsmål), om teamet i presentasjonen faktisk er de som skal gjøre jobben, og skjulte driftskostnader. Lever utfylt tabell, oppfølgingsspørsmål per tilbyder, og en 5-linjers begrunnet anbefaling.

Lag en plan for endringsledelse for [prosjekt, f.eks. nytt verktøy, ny prosess] hos [bedrift]. Berørte grupper: [grupper, antall og hva endres for dem]. Kjente bekymringer: [antatt motstand]. Tidsplan: [viktige datoer]. Ressurser: [tid, budsjett, ambassadører].

For hver gruppe: Hva endres konkret i hverdagen (gevinster OG tap – fortielse av tap skaper problemer senere), nødvendig støttenivå (info, kurs, tett oppfølging), og hovedbudskap sett fra deres ståsted.

Strukturer planen i tid: Før (annonsering, nettverk av interne ambassadører med høy troverdighet, opplæring), Under (utvidet brukerstøtte, system for tilbakemeldinger, synlig utbedring av rapporterte feil), Etter (måling av faktisk bruk fremfor kursdeltakelse, håndtering av gjenværende motstand).

Krav: Ingen plan basert på «mer kommunikasjon» uten å si hva til hvem. Hvert tiltak må ha ansvarlig og dato. Lever planen som tabell per målgruppe og en samlet tidsplan.

Design en opplæringsplan for sluttbrukere ved innføring av [verktøy eller prosess] hos [bedrift]. Brukere: [profiler, antall, teknisk modenhet, lokasjon]. Hva må de kunne: [oppgaver per profil]. Begrensninger: [tid, budsjett, lanseringsdato].

Lag et opplegg per profil heller enn ett felles kurs: For hver profil, de 5-10 viktigste handlingene basert på deres hverdag (ikke en gjennomgang av alle knapper), tilpasset format (kort gruppeseanse, video, en-til-en ved pulten), varighet, og dokumentasjon (oppgaveark på én side heller enn en tykk manual).

Planlegg seansene tett opp mot lansering; kurs som holdes 6 uker før bruk blir glemt. Planlegg for de som er borte og for lokal støtte per avdeling.

Krav: Mål suksess ut fra faktisk bruk etter lansering (evne til å utføre kjerneoppgaver, antall supporthenvendelser) og ikke bare oppmøte. Lever planen i tabellform og en prioritert liste over materiell som må lages.

En kritisk hendelse har rammet prosjektet [navn på prosjekt]: [hendelse, f.eks. mislykket lansering, datatap, tjeneste nede, alvorlig avvik oppdaget]. Konsekvenser: [hvem er rammet og hvordan]. Status: [hva vet vi, hva vet vi ikke]. Målgrupper: [ledelse, ansatte, kunder, partnere].

Lag en kommunikasjonsplan: Den første meldingen sendes raskt og sier hva vi vet, hva vi ikke vet, hva vi gjør og når neste oppdatering kommer (lov et tidspunkt for info, ikke et tidspunkt for løsning hvis det er usikkert). Følg opp til avtalt tid selv om det ikke er nytt. Til slutt, melding om løsning med tiltak for å unngå gjentakelse.

Tilpass meldingen: Ledelsen vil ha konsekvens og beslutningsbehov, brukere vil vite hvordan de skal jobbe nå, kunder vil vite om deres data er trygge. Krav: Ingen spekulasjon om årsak før den er klar, ingen skyldfordeling, ingen tidsløfter som brytes (det ødelegger all tillit). Lever ferdige meldinger og regler for hvem som snakker med hvem.

Hjelp teamet [team] hos [bedrift] med å skrive OKR for [kvartal]. Bedriftens prioriteringer: [prioriteringer]. Teamets faste oppgaver: [drift]. Planlagte prosjekter: [ideer]. Teamstørrelse: [antall].

Lag maks 2-3 mål (Objectives): Hvert mål skal være en inspirerende, men konkret tilstand (ikke en liste med oppgaver), knyttet til bedriftens mål. For hvert mål, 2-4 nøkkelresultater (Key Results): Målbare med startverdi og målverdi, som måler et resultat og ikke en aktivitet («redusere saksbehandlingstid fra X til Y» i stedet for «innføre verktøy Z»).

Krav: Daglig drift skal ikke inn i OKR, det styres separat. Et nøkkelresultat som vi ikke vet hvordan vi skal måle i dag, må omformuleres eller fjernes. Påpek mål som teamet ikke har full kontroll over. Lever forslag til OKR, spørsmål til team-workshop, og rutine for oppfølging (15 min per uke, og hva skjer ved avvik).

Forbered kvartalsgjennomgang av OKR for teamet [team]. Kvartalets OKR: [mål og resultater med oppnåelse]. Viktige hendelser: [kontekst: uforutsette ting, endrede prioriteringer]. Deltakere: [deltakere]. Varighet: [varighet].

Strukturer møtet i 3 deler: Ærlig poengsetting av hvert nøkkelresultat basert på reelle tall (et ikke-målt resultat er ikke nådd), analyse av avvik (skille mellom utførelse, for ambisiøse mål eller ytre hendelser), og beslutninger for neste kvartal (hva videreføres, hva avsluttes, hva justeres).

Krav: Gjennomgangen skal ikke være en forsvarstale; dropp kontekst-bilder og gå rett til tallene. Et mål nådd 100 % med en gang tyder på for lav ambisjon, mens 20 % tyder på dårlig utførelse eller planlegging. Lever agenda, poengskala, analysespørsmål per resultat, og mal for oppsummering som sendes ut etterpå.

Forbered en post-mortem for hendelsen [beskrivelse] som skjedde [dato] i prosjektet [navn på prosjekt]. Kjent tidslinje: [hendelsesforløp med klokkeslett]. Involverte: [aktører]. Stemning: [kontekst, f.eks. noen føler seg utpekt, ledelsen leter etter en ansvarlig].

Strukturer dokumentet og møtet: Faktisk tidslinje gjenskapt i fellesskap (time-for-time, uten tolkning), årsaksanalyse som går dypere enn menneskelig feil (en menneskelig feil er et symptom: hva tillot at den skjedde, og hva burde fanget den opp før konsekvensen?), hva fungerte bra i håndteringen, og forebyggende tiltak.

Kjøreregler: Vi leter etter hvordan systemet sviktet, ikke hvem som gjorde feil. Den som sier «jeg gjorde en feil» hjelper teamet og skal ikke straffes. Krav: Maks 5 tiltak, hver med ansvarlig og frist. Prioriter tiltak som fjerner muligheten for feil fremfor «være mer forsiktig». Lever mal for dokumentet og agenda for møtet.

Hjelp meg å gjøre om erfaringer fra [team eller bedrift] til faste standarder. Grunnlag: [kilder: evalueringer, sluttrapporter, post-mortems, faste tilbakemeldinger]. Dagens problem: [symptom, f.eks. de samme feilene gjentas, rapporter leses aldri].

Fremgangsmåte: Grupper lærdom etter tema og finn gjengangere (prioriter disse), gjør hver lærdom om til en konkret kjøreregel formulert i én setning med en utløser («ved oppstart av hvert prosjekt skal vi gjøre X»), og definer hvor disse reglene skal bo for å bli sett (integrert i dokumentmaler og sjekklister heller enn i et støvete arkiv).

Krav: Maks 10 regler totalt, hver regel har en eier. Planlegg en halvårlig revisjon for å slette utdaterte regler; et regelverk som bare vokser, dør. Lever forslag til regler sortert etter når de brukes, hvor de skal integreres, og melding til teamet.

Forbered prosjektet [navn på prosjekt] til en revisjon eller kvalitetskontroll utført av [revisor: internrevisjon, kunde, sertifiseringsorgan, ledelse] den [dato]. Omfang: [hva skal sjekkes]. Reell status: [styrker og svakheter, dokumentasjon status]. Hva står på spill: [f.eks. videre finansiering, kundetillit, sertifisering].

Organiser forberedelsene: Liste over dokumentasjon som må være klar (mandat, beslutninger, risikostyring, referater, økonomi) med fokus på det som mangler, spørsmål revisor sannsynligvis vil stille, og en ærlig strategi for kjente svakheter: Erkjenne dem, vis at de er identifisert og styrt, og legg frem en datert handlingsplan.

Krav: Aldri pynt på dokumenter eller tilbakedater noe; en ærlig svakhet med en troverdig plan er bedre enn en fasade som sprekker. Brief de som skal intervjues på fakta, ikke på «innøvde svar». Lever sjekkliste for dokumentasjon, sannsynlige spørsmål med svarforslag, og en tidsplan for forberedelsene.