PurePPM kjernefunksjonalitet

• Strategiske mål, effektmål og gevinster i en sammenhengende kjede: strategisk mål → effektmål → gevinst → initiativets gevinstforpliktelse → program og prosjekt.
• Gevinstforpliktelse: Virksomheten eier gevinstmålene, og hvert initiativ forplikter seg til en målbar andel av dem. Porteføljen viser løpende hvor mye av gevinsten som er dekket av tiltak, og om den realiseres.
• Primær og sekundær målkobling med vekting, slik at et tiltak kan bidra til flere mål uten at bidraget telles dobbelt.
• Strategiveiviser med KI: Eksisterende strategidokumenter leses inn, og PurePPM foreslår mål, effektmål, strategiske gevinster, risikoer og interessenter. Brukeren godkjenner hvert forslag før noe lagres.

• Porteføljehierarki med rotportefølje, delporteføljer, programmer og initiativer (prosjekter). Nøkkeltall rulles opp til nivået over.
• Livsløp etter virksomhetens egen prosjektmodell: Faser og beslutningsporter defineres i versjonerte styringsmaler, ikke i hardkodede faser.
• Status og helse per dimensjon (for eksempel kostnad, tid, omfang, risiko og gevinst) med trafikklys og begrunnelse. Status rapporteres fra prosjekt og aggregeres oppover.
• Ukentlige øyeblikksbilder (snapshots) av nøkkeltall gir historikk og trender over tid.

• PurePPMs egen prioriteringsscore: en egenutviklet modell som rangerer de besluttede tiltakene på seks kriterier:

  • strategisk bidrag, regnet gjennom kjeden mål → effektmål → gevinst
  • tillit til at gevinsten blir realisert
  • leveranseevne (kapasitet, toleranse, kompleksitet, interessenter og RAID)
  • nytte mot kostnad
  • hvor mye av virksomhetens kapasitet tiltaket legger beslag på
  • konflikt om de samme ressursene

  Virksomheten setter vektene selv. Scoren er forklarbar: for hvert tiltak vises hva som former den og hvor stor del av grunnlaget som finnes. Alt regnes fra dataene, ikke anslått av KI. Kandidater som ennå ikke er besluttet, får en egen kandidatscore og kan aldri flytte rangeringen til de besluttede.

• Prioritering mot rammen: Tiltakene legges mot porteføljens budsjettramme år for år, i prioritert rekkefølge. Rapporten viser hvilke som får plass, hvilke som ikke gjør det, og hvor stort finansieringsgapet er. Det gir et etterprøvbart grunnlag for å si nei eller utsette, i stedet for at porteføljen vokser fordi alt får et ja.
• Egne styrings-KPI-er: strategisk bidrag, tillitsgrad og leveranseevne per initiativ, og styringsscore for porteføljen. Rangeringshistorikk og ukentlige øyeblikksbilder viser hvor stabil prioriteringen er over tid.
• Strategisk innretting (alignment): viser hvor godt porteføljen dekker de strategiske målene, og hvor det er hull eller overlapp.
• Business case med nåverdi (NPV) og avkastning (ROI) per initiativ.
• Ikke-besluttede tiltak holdes utenfor den offisielle prioriteringen og vises for seg, slik at idéer ikke blandes med vedtatte tiltak.

Governance-modulen gjør virksomhetens egen prosjektmodell kjørbar i stedet for et dokument på intranettet. Og den er enkel å tilpasse: hvert prosjekt kan få en prosjektmodell som passer størrelsen og kompleksiteten, med egne maler, egne sjekklister og egne beslutningspunkter. Virksomhetens superbrukere gjør tilpasningen i løsningen selv, uten utvikling og uten konsulent.

Prosjektmodell per prosjekt

Velg blant ferdige modeller eller virksomhetens egne, og tilpass faser og porter for det enkelte prosjektet

Egne maler

Styringsmaler, rapportmaler og beslutningsgrunnlag per port, versjonert slik at endringer ikke forstyrrer pågående prosjekter

Sjekklister

Per beslutningsport, med mulighet for begrunnet overstyring per prosjekt

Gate-overganger

Prosjektet går til neste fase først når porten er besluttet: godkjent, sendt tilbake eller stanset, med begrunnelse og sporbarhet

Beslutningsstøtte

Beslutningsgrunnlag generert fra registrerte data, med KI-vurdering, status og anbefaling først, og kapasitetsbildet for de berørte ressursene

Oversikt og oppfølging

Hvor hvert prosjekt står i modellen, hva som venter på beslutning, hvem som skal beslutte, og hva den enkelte skal følge opp

• Katalog av prosjektprosesser: Flere ferdige styringsmodeller følger med, blant annet en standard stage-gate-modell og Prosjektveiviseren 4.0 (Digitaliseringsdirektoratets modell for offentlig sektor). Virksomheten kan også lage sine egne, for eksempel én modell for store investeringsprosjekter og en enklere for mindre tiltak.
• Prosess etter kompleksitet: Ved en egen prosessvalg-port velges riktig modell for hvert prosjekt. Prosjekter uten valg følger virksomhetens standard. Små tiltak slipper tung metodikk, og store får full styring.
• Tilpassbare faser: Faser og beslutningspunkter kan få nye navn, legges til, settes inn og omrokeres. Endepunktene er låst: idé og business case først, gevinstrealisering og avslutning sist. Gevinstrealiseringen kan dermed aldri hoppes over.
• Beslutningsporter med sjekklister, krav til beslutningsgrunnlag og godkjennerroller per port. En port kan kreve at prosjektleder er utpekt, og den kan låse budsjettbaselinen.
• Styringsenheter og roller (for eksempel prosjekteier, styringsgruppe, porteføljeråd og programstyre), med ansvar knyttet til konkret portefølje, program eller prosjekt.
• Beslutningsflyt: Den som forbereder legger frem et beslutningsønske, og beslutningstaker varsles når det er klart. Beslutninger som ligger utenfor eget mandat, eskaleres til riktig styringsnivå.
• Møtestøtte: Saker kan foreslås til møter i styringsenhetene, og beslutninger protokolleres med begrunnelse og utfall.
• Beslutningshistorikk: Hver beslutning (godkjenne, sende tilbake, stanse, endre) spores med hvem, når, på hvilket grunnlag og med hvilket utfall.
• Mine oppgaver: samler det den enkelte har ansvar for å forberede, vurdere eller beslutte.

Budsjettmodulen bygger på én kjerneregel: prosjektet kan foreslå mer penger, men det kan ikke bevilge seg selv mer penger. Ingen penger flytter seg av seg selv. Hver bevegelse er en eksplisitt, besluttet og sporbar transaksjon.

• Budsjett, prognose og påløpt per initiativ, med budsjettbaseline og historikk. Bare investeringer (Capex) trekker på rammen.
• Ramme per portefølje og år, med risikobuffer som en egen andel. Rammen fordeles nedover til underporteføljer og programmer.
• Rammevakt: Et underliggende nivå kan aldri få mer enn forelderen har disponibelt, og forelderen kan ikke senkes under det barna holder.
• Forslag → beslutning → vedtatt: En vedtatt ramme er låst for direkte endring. Endringer skjer bare via endringssak, overføring eller frigiving, og historikken viser hele kjeden fra vedtak til ny ramme.
• Fire øyne uten unntak: Den som ber om en budsjettendring, kan ikke godkjenne den. Det gjelder også administratorer.
• Eskalering: Prosjektleder registrerer kostendringen, og nivået over (program, portefølje eller et møte forankret der) godkjenner og tar samtidig stilling til toleransen.
• Toleranser: Avvik måles mot prognosen. Brudd, både over- og underforbruk, gir automatisk et utkast til endringssak til nivået over.
• Finansieringskilde i beslutningen: Beslutteren velger eksplisitt om økningen dekkes av frie midler, risikobuffer, omdisponering, økt ramme eller midler fra et overordnet nivå. Bruk av buffer blir dermed et sporbart valg.
• Overføring mellom år: Ubrukte midler kan settes av til neste år, og midler kan forskutteres når neste års ramme er vedtatt.
• Frie midler per portefølje, og full transaksjonslogg: hvem, når, kilde, mottaker, beløp, begrunnelse og verdi før og etter.
• Ressurskostnader beregnet fra planen (WBS og ressursbehov) inngår i budsjett og prognose.
• Ikke levert i dag: P50/P85-analyse, kontraktsøkonomi og automatisk innlesing fra ERP.

Styringsreglene over er kodet og i ferdigstilling. Estimatusikkerhet (±%) på planlagte kostnader er besluttet som neste steg.

• RAID-register per initiativ: risiko og muligheter, antagelser (som planen bygger på), problemer med tiltak, beslutninger, hendelser og avhengigheter, hver med egne statuser, eier og historikk.
• Risiko med sannsynlighet, konsekvens, restrisiko, tiltak og eier.
• Porteføljelogg for hendelser og beslutninger på porteføljenivå.
• To lag: globale usikkerheter som påvirker hele porteføljen, og risiko og muligheter knyttet til strategiske mål.
• Risikomatrise på porteføljenivå med historikk for usikkerhetene.
• Risikoappetitt kan defineres og brukes som referanse.

Ressursmodulen svarer på spørsmålet de fleste porteføljer feiler på: har vi nok folk med riktig kompetanse til å gjennomføre det vi har sagt ja til?

• Ressurspooler per rolle eller fagdisiplin, med tilgjengelig kapasitet per periode og en virksomhetskalender med arbeidsdager, helligdager og timer per dag.
• Ressursbehov før personer: Planen dimensjoneres mot rolle og pool (for eksempel «løsningsarkitekt 50 % i Q2–Q4») uten at navngitte personer må velges. Hver aktivitet kan ha flere behov, og dekningsgrad (dekket, delvis dekket, udekket) vises per behov, per aktivitet og per pool.
• Bemanning: Navngitte personer tildeles behovene. Ett behov kan dekkes av flere personer, og én person kan dekke flere behov. Overbooking og rolleavvik vises med en gang. Det samme gjelder når en tildelt person ikke har rollen behovet krever.
• KI-foreslått bemanning med synlig begrunnelse: Forslagene rangeres etter rolle, pool, kompetanse og ledig kapasitet, og begrunnelsen vises alltid. Et eksempel: «Rolle ✓ · Pool ✓ · Kapasitet ⚠ 60 %».
• Innsats i prosent av tid, ikke som løse persondager. Det gir et direkte grunnlag for avrop mot ressurseier.
• Porteføljebildet: et tidsvektet varmekart over belastning per pool og periode, konflikter på tvers av tiltak og «mangler» (årsverk minus dekket minus foreslått) for hele porteføljen.
• Kapasitet ved beslutning: Når et tiltak skal godkjennes i en beslutningsport, ser beslutningstaker samtidig toppbelastning for de berørte ressursene og en tidslinje per person. Kapasiteten blir en del av beslutningsgrunnlaget, ikke noe man oppdager etterpå.
• Simulering (Professional-planen): flytte oppstart, legge til eller fjerne allokering og se konsekvensen for belastning og tidslinje, uten å endre den faktiske porteføljen. Flere simuleringer kan lagres.
• Ikke levert i dag: budsjettrammescenario som beregner hvilke tiltak som faller under en ny ramme, og hva det betyr for gevinstene.

Planmodulen er prosjektlederens arbeidsflate for oppgavestyring. Den har fire perspektiver på samme plan: planlegging (hva skal skje, når og i hvilken rekkefølge), fremdrift (hvordan ligger vi an), ressursbehov (hvilken kapasitet og kompetanse trenger planen) og bemanning (hvem skal gjøre jobben).

• Aktiviteter og underaktiviteter i en nummerert hierarkisk struktur (WBS), med milepæler, varighet og avhengigheter mellom aktivitetene. Den samme aktiviteten følger brukeren på tvers av alle fire perspektivene.
• Bemanning per aktivitet: Navngitte personer tildeles oppgavene, med andel, periode og forslag fra KI (se kapittel 7).
• Ressurskostnad fra planen: Kostnaden for interne ressurser beregnes fra aktivitetene i WBS-strukturen og ressursbehovet, og den inngår i budsjett og prognose.
• Fremdrift mot plan: status og prosent ferdig per aktivitet, med «faktisk mot planlagt» på summeringsnivå.
• Planbaseline og logg over planendringer. Gjeldende plan og baseline vises eksplisitt.
• Arbeidskalender som tar hensyn til helligdager og virksomhetens arbeidstid.

• Gevinster med baseline, planlagt og realisert verdi, måleenhet, måleplan og gevinsteier.
• Målinger over tid: En gevinst regnes som levert når sluttmålingen er ført, ikke ut fra dato eller fase.
• Direkte og indirekte gevinster summeres hver for seg.
• Frister ligger på forpliktelsen, slik at det er tydelig hvem som skal levere hva og når.
• Oversikt over gevinstrealisering på tvers av porteføljen.

• Interessentregister per initiativ og portefølje, med påvirkning og interesse.

• Rapportmotor med maler: statusrapporter, porteføljerapporter, rapporter til beslutningsporter og initiativdokumenter (mandat, business case, styringsdokument, sluttrapport og gevinstrealisering). Alt genereres fra registrerte data, og virksomheten kan lage egne maler.
• Versjonering: Rapporter og styringsdokumenter lagres i versjoner, slik at det er sporbart hva som ble lagt fram når. Rapportene som lå til grunn for en beslutning, følger beslutningen.
• Status og anbefaling først, deretter fakta og detaljer. Rapporten skrives på virksomhetens språk, uten interne feltnavn.
• Dashbord for portefølje, program og initiativ, med ukentlige øyeblikksbilder som gir trender over tid.
• Publisering til SharePoint: Rapporter og styringsdokumenter kan skrives til SharePoint via MCP. Dette er testet.

De fleste KI-løsninger for prosjektstyring legger en språkmodell oppå dokumenter og lister. PurePPM gjør det motsatte. Mål, gevinster, forpliktelser, beslutninger, rammer, toleranser, ressursbehov og risiko er strukturerte objekter med regler, og KI-en arbeider på disse sammenhengene.

Systemet regner, KI vurderer. Grunnprinsippet er at KI-en aldri finner på tall:

• Faktaseksjonene i rapportene (økonomi, fremdrift, avvik, toleranse, gevinsttotaler og belastning) skrives deterministisk av systemet. KI skriver bare vurdering, anbefaling og begrunnelse.
• Tallkontroll: Hvert tall i KI-teksten må finnes i grunnlaget. Hvis ikke, gjør systemet ett korrigeringsforsøk, og deretter vises en synlig advarsel.
• Validerte tiltak: KI-forslag om å utsette, stanse, omdisponere eller bruke buffer kontrolleres mot dataene før de vises. Ugyldige forslag fjernes og listes med grunn.
• «Ikke vurdert» i stedet for gjetning: Mangler grunnlaget, settes ingen farge og ingen prosent.
• Ferskt beslutningsgrunnlag: Gate-anbefalingen hentes på nytt ved beslutning, og panelet varsler hvis dataene er endret siden anbefalingen ble laget.

Hva løsningen finner av seg selv:

• gevinster som er overforpliktet eller dobbelttelt, og effektmål ingen tiltak bidrar til
• finansieringsgap per år mot samlet ramme, og hvilke tiltak som ikke får plass innenfor rammen når de legges inn i prioritert rekkefølge
• ressurskonflikter, med avhengighetene som trues (hvem leverer, hvem venter, når) og gevinstene som forsinkes, i kroner
• et alternativ i planmotoren når tiltak kolliderer: inntil ti alternativer med verdiforskjell per år, og forslag om tidligere oppstart der det er ledig kapasitet
• toleransebrudd i prognosen, som automatisk blir et utkast til endringssak
• statusforslag med begrunnet farge og tydelig markering av hva som ikke er vurdert
• utkast til business case med budsjettforslag basert på lignende tidligere saker

Rapporttyper: dyp porteføljeanalyse, prioriteringsråd, budsjett- og allokeringsråd, ressurskonfliktanalyse, gevinstevaluering, prediktiv risiko, interessentkoordinering og porteføljeoptimalisering, i tillegg til gate-anbefaling og statusrapport.

Kontroll: Forslag som endrer data, må godkjennes av en bruker. KI-leverandøren velges per kunde: europeisk, OpenAI-kompatibel eller lokalt kjørt modell (for eksempel Ollama eller vLLM), slik at data kan bli i virksomhetens eget miljø. Selvhostede modeller er enkle å sette opp. PurePPM kan ikke garantere kvaliteten på en modell kunden selv velger, men modeller med resonnering og tilstrekkelig kontekstvindu fungerer godt. Tallkontrollen og valideringen virker uansett modell.

Erfaringsdatabase (under utvikling): Den bygges på samme modell. Grunnlaget registreres allerede strukturert: beslutninger med begrunnelse og utfall, toleransebrudd, endringssaker og om gevinsten faktisk ble levert.

• Import fra SharePoint-basert prosjektportal er testet og fungerer. Eksisterende prosjekt- og porteføljedata kan leses inn, slik at løsningen ikke starter med blanke ark.
• KI-assistert import av strategi og eksisterende tiltak fra dokumenter. Brukeren godkjenner alt før det lagres.
• Oppå eksisterende portal, ikke i stedet for: PurePPM kan lese fra en SharePoint-basert prosjektportal, aggregere porteføljen og skrive rapporter tilbake, mens prosjektene fortsetter i kjent verktøy. Overgangen kan dermed skje gradvis, uten at daglig drift blir skadelidende.

PurePPM er bygget for MCP (Model Context Protocol) fra bunnen, i begge retninger. MCP er den åpne standarden for hvordan KI-assistenter og systemer deler data og verktøy på en styrt måte.

• PurePPM som MCP-server: Porteføljemodellen eksponeres som cirka 30 styrte verktøy med OAuth 2.1. Virksomhetens egne KI-assistenter og agenter kan spørre porteføljen og foreslå oppdateringer, med tilgangsstyring og menneskelig godkjenning før noe skrives.
• Jobb med PurePPM utenfor løsningen: En porteføljeforvalter eller controller kan bruke sin egen KI-assistent (for eksempel Copilot eller en annen MCP-kompatibel assistent) og kombinere PurePPM med andre kilder i samme arbeidsflyt: SharePoint-dokumenter, e-post, økonomitall og fagsystemer. Et eksempel er å be om et utkast til styringsgruppenotat som henter status og gevinst fra PurePPM og referatet fra SharePoint. Tilgangsstyringen i PurePPM gjelder fullt ut, og endringer krever godkjenning.
• PurePPM som MCP-klient: Konnektorrammeverket kobler til andre systemers MCP-servere. Lesing fra og skriving til SharePoint er testet. Der et system har en MCP-server, blir integrasjonen konfigurasjon og ikke utvikling, og tilgangene kan utvides uten nytt integrasjonsprosjekt.
• REST-API: Løsningen er bygget på et internt REST-API, men det eksponeres ikke for kunder i dag. Det kan åpnes ved behov. MCP er det anbefalte grensesnittet.
• Nye integrasjoner blir billige: Konnektorer mot ERP, Power BI, arkiv og andre fagsystemer lages når kundene trenger dem. Med MCP er en ny kilde konfigurasjon og tilgangsstyring, ikke et nytt integrasjonsprosjekt. Systemer uten MCP pakkes inn i en tynn MCP-adapter én gang, og kan deretter brukes både av PurePPM og av virksomhetens egne KI-assistenter.

• Single sign-on via OIDC (for eksempel Entra ID) per kunde, SCIM 2.0 for automatisk brukeradministrasjon og MFA-policy. Kunden eier tilgangsstyringen.
• Rollebasert tilgang (RBAC), med ansvar knyttet til konkret portefølje, program og prosjekt.
• Kundeisolasjon på databasenivå (row-level security i PostgreSQL).
• Fire tilgangsnivåer per ressurs (lese, kommentere, redigere, eie), pluss egen godkjenningsrett for beslutningsporter. Tilgang arves fra portefølje til program og initiativ.
• Eksterne aktører (rådgivere, innleide, leverandører) kan inviteres og få tilgang til bare de prosjektene de skal se.
• MFA er påkrevd for administratorer, og kunden kan kreve det for alle brukere.
• Revisjonslogg for endringer, tildelinger, datatilgang og MFA-hendelser, tilgjengelig for administratorer.
• Norsk og engelsk brukergrensesnitt.

PurePPM er bygget for virksomheter som ikke kan akseptere at styringsinformasjon blir eksponert for utenlandsk jurisdiksjon.

• Eierskapets jurisdiksjon avgjør, ikke bare hosting-region. PurePPM bruker ingen amerikanskeide databehandlere for kunde-, support- eller salgsdata. Regelen gjelder alle leverandørkategorier: hosting, database, e-post, overvåking, feilsporing og support.
• Norskeid selskap, med utvikling og drift i Norge. Ingen utenlandsk kapital eller styringsinnflytelse.
• Hele stacken på europeisk infrastruktur: europeisk eid skyleverandør (Frankrike) for beregning, database, lagring, e-post og hemmeligheter. Kodeplattform og CI kjører også på europeisk infrastruktur.
• Ingen ekstern identitetsleverandør i kjeden. PurePPM utsteder egne tokens og føderer mot kundens Entra ID via OIDC. Kunden eier identitetene og tilgangsstyringen.
• Kunden velger hvor KI-behandlingen skjer: kun europeisk leverandør, global, eller egen modell i eget miljø. Navn på ressurser og interessenter kan pseudonymiseres før en forespørsel forlater løsningen.
• Kryptering i hvile og under overføring. Daglige, krypterte sikkerhetskopier lagres i en annen EU-region, og nøkkelen ligger utenfor skyleverandøren. Gjenoppretting er testet.
• Exit uten innlåsing: full eksport av alle data i åpent format (strukturert JSON), sletteattest ved avslutning, og åpne standarder (MCP, OIDC, SCIM, PostgreSQL).
• Strukturert mot EU-kommisjonens Cloud Sovereignty Framework (v1.2.1). PurePPM har en egenvurdering per objektiv, og scorer sterkest på eierskap, jurisdiksjon, data og KI, og operativ kontroll.
• Forberedt for ISO 27001 i både organisasjon og løsning: ISMS med kontrollbibliotek mot ISO 27001:2022 Annex A og NSMs grunnprinsipper for IKT-sikkerhet, policyer, runbooks for hendelser og gjenoppretting, og tekniske kontroller. Sertifiseringsrevisjonen er ikke bestilt, av kostnadshensyn, og kan settes i gang ved kontrakt.
• Publisert liste over underleverandører, og fastsatte frister for å rette sårbarheter: kritiske innen 7 dager, høye innen 30 dager.