Skip to main content

Å velge riktig prosjektstyringsprogramvare kan være avgjørende for om teamet ditt lykkes. Det riktige verktøyet kan spare tid, forbedre nøyaktigheten, støtte krav til samsvar og hjelpe teamet med å få mer verdi ut av investeringen sin.

Men velger du feil prosjektstyringsløsning, blir du sittende fast med ineffektivitet, overskredne tidsfrister og frustrerte teammedlemmer.

Denne veiledningen er for prosjektledere, teamledere og alle som har ansvar for å styre prosjekter mot suksess. Enten du ønsker å forbedre samarbeidet eller effektivisere prosesser, hjelper jeg deg med å finne riktig prosjektstyringsverktøy for dine unike behov.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

4 ting du bør se etter når du velger prosjektstyringsprogramvare

Basert på min erfaring med bruk av prosjektverktøy fokuserer jeg på integrasjoner, skalerbarhet, rollebasert tilgang og rapportering som gjør prosjektdata tydelige:

1. Integrasjon med de eksisterende verktøyene dine

Quickbase integreres med verktøy som Procore for å automatisere arbeidsflyter før byggestart på tvers av plattformer.

Integrasjoner kobler prosjektstyringsprogramvaren til verktøy teamet allerede bruker, for eksempel chat, kalendere, kodelagre og fillagring.

Kontroller om viktige integrasjoner synkroniserer dataene arbeidsflyten din trenger, og se etter dupliserte poster eller manuelle oppdateringer. Spør: «Hvilke verktøy må utveksle informasjon for at denne arbeidsflyten skal fungere?»

For eksterne eller distribuerte team bør du også teste mobiltilgang og synkronisering i sanntid for å sikre at teammedlemmer kan administrere prosjekter fra ulike steder.

Byggeselskaper som bruker Xero til regnskap, bør for eksempel se etter prosjektstyringsprogramvare for bygg og anlegg som fungerer med Xero.

Test disse integrasjonene under en demonstrasjon eller gratis prøveperiode for å bekrefte at dataflyten fungerer problemfritt. Å redusere manuelle oppdateringer og feil er en viktig fordel med prosjektstyringsprogramvare for bygg og anlegg.

2. Skalerbarhet etter hvert som teamet vokser

Skalerbarhet betyr at programvaren kan håndtere flere brukere, prosjekter og mer komplekse arbeidsflyter etter hvert som teamet vokser. Se etter fleksible tillatelser, rapportering og tydelig prising når bruken øker, og unngå å betale for kapasitet du ikke trenger ennå. Spør: Hvilken teamstørrelse eller prosjektmengde vil utløse en oppgradering, og hva vil det koste?

Kontroller leverandørens alternativer for innføring, opplæring og kundestøtte, samt eventuelle ekstra gebyrer for å endre abonnement eller legge til funksjoner.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

3. Rollebasert tilgang og tillatelser

Hub Planners rollebaserte tillatelser
Hub Planners rollebaserte tillatelser sikrer at de riktige teammedlemmene får tilgang til relevante detaljer om planlegging, ressurser og prosjekter.

Rollebasert tilgang lar deg kontrollere hvem som kan vise, redigere, godkjenne eller administrere prosjektdata. Se etter detaljerte, lett reviderbare tillatelser som samsvarer med teamets ansvarsområder, og unngå verktøy som er avhengige av bred, delt tilgang. Spør hvilke personer som trenger tilgang til sensitive prosjektdetaljer, og hvilke handlinger de skal kunne utføre.

Kontroller også om du kan tilpasse arbeidsflyter, felt og maler, og automatisere rutineoppgaver som tildelinger, varsler og statusoppdateringer.

4. Rapportering og datasynlighet

Rapportering gjør prosjektaktivitet om til oversikter over fremdrift, arbeidsbelastning, risikoer og leveringstrender. Se etter rapporter du kan filtrere etter prosjekt, team og tidsperiode, og unngå oversikter som skjuler hvordan måltallene beregnes.

Spør: Hvilke beslutninger bør teamet ta basert på prosjektdata, og kan programvaren vise informasjonen som ligger til grunn for disse beslutningene?

Slik velger du prosjektstyringsprogramvare: En femtrinnsmodell

Bruk disse fem trinnene til å vurdere arbeidsflyten din, teste hvor godt verktøyet passer, og ta et veloverveid valg:

Trinn 1: Identifiser behovene dine

Før du åpner en eneste produktside, bør du snakke med menneskene som skal bruke verktøyet hver dag. Etter min erfaring er det å hoppe over dette steget det som får team til å velge programvare som ser flott ut i en demonstrasjon, men som stille blir forlatt etter en måned.

Start med å kartlegge hvordan arbeidet faktisk beveger seg gjennom teamet ditt – ikke hvordan det er ment å bevege seg. De to tingene er sjelden like, og avstanden mellom dem er der de virkelige kravene dine finnes.

Snakk med disse interessentene før du forplikter deg til noe:

  • Teamledere og individuelle bidragsytere: Hvilke trinn i den nåværende arbeidsflyten føles som ekstraarbeid? Hva ønsker de å se i begynnelsen av hver dag?
  • Ledere og sponsorer: Hvilke prosjektdata trenger de for å ta beslutninger, og hvor ofte?
  • IT eller drift: Hvilke krav til sikkerhet, samsvar eller integrasjoner vil påvirke hva dere faktisk kan bruke?

Når du har hatt disse samtalene, kan du bruke disse spørsmålene til å utforme kravene dine:

  • Hva er den primære arbeidstypen: oppgavebasert levering, løpende drift eller en blanding av begge?
  • Hvor mange personer trenger tilgang, og trenger de ulike tillatelsesnivåer?
  • Hvilke verktøy må programvaren koble seg til fra dag én?
  • Finnes det krav til samsvar, datalokasjon eller sikkerhet som begrenser alternativene dine?
  • Hvordan ser «suksess» ut om seks måneder, og hvordan vil du måle den?

Ved slutten av dette steget bør du ha en kort liste over det som er helt nødvendig, en separat liste over ting som hadde vært nyttige å ha, og et tydelig bilde av arbeidsflytene verktøyet må støtte. Dette skillet er viktigere enn de fleste team innser – det er når du slår sammen de to listene at du ender opp med å betale for mye for funksjoner ingen bruker.

Steg 2: Undersøk leverandører av programvare for prosjektstyring

Når du vet hva du trenger, er det på tide å se på hva som finnes. Jeg ville motstått fristelsen til å google «beste programvare for prosjektstyring» og klikke på det første resultatet. Slike lister kan lede deg mot de mest populære verktøyene, ikke det som passer best for teamets situasjon.

Bruk heller flere kilder og vurder hver av dem på ulike måter. Slik går jeg frem i denne fasen:

  • Anmeldelser fra andre brukere: Les anmeldelser fra personer med samme teamstørrelse, bransje og bruksområde som deg. Filtrer etter rolle – det en frilanser som jobber alene setter pris på, er annerledes enn det et ingeniørteam på 50 personer trenger.
  • Analytiker- og sammenligningssider: Bruk disse til å kartlegge markedet og forstå hvordan leverandørene posisjonerer seg. De er bedre for bredde enn dybde.
  • Forum og Slack-grupper: Disse synliggjør reelle frustrasjoner som leverandørene ikke vil reklamere med. Søk etter verktøynavnet sammen med ord som «problem», «begrensning» eller «byttet fra».
  • Leverandørens dokumentasjon: Gå rett til produktdokumentasjonen, ikke bare markedsføringsnettstedet. Dokumentasjonen forteller deg hva et verktøy faktisk gjør – markedsføringen forteller deg hva de vil at du skal tro at det gjør.
  • Nylige versjonsnotater eller endringslogger: Jeg sjekker alltid disse. En leverandør som jevnlig lanserer oppdateringer, er en leverandør som reagerer på tilbakemeldinger fra brukerne. En utdatert endringslogg er et varselsignal.

Bruk denne tabellen til å vurdere kvaliteten og hensikten til hver kilde du konsulterer:

KildetypeBest egnet tilVær oppmerksom på
AnmeldelsessiderReelle brukeropplevelserAktualitet og relevans for rollen
Leverandørenes markedsføringssiderForstå posisjoneringenOverdrevne muligheter
ForumKjente problemområderAvvikende meninger eller gamle innlegg
AnalytikerrapporterMarkedsforståelseSkjevhet mot verktøy for store virksomheter
ProduktdokumentasjonFaktisk funksjonsdybdeUfullstendig eller utdatert innhold


Ta hensyn til teamstørrelsen og virksomhetens behov når du undersøker leverandører. For eksempel er enkelte prosjektstyringsverktøy godt egnet for oppstartsbedrifter og små virksomheter, mens selvstendige som håndterer sine egne prosjekter kanskje prioriterer rimelige priser, enkel oppstart og enkel oppgavehåndtering fremfor avanserte funksjoner.

Ved slutten av dette trinnet bør du ha en arbeidsliste over leverandører som sannsynligvis dekker kravene dine – ikke en kortliste ennå, bare kandidater som er verdt å se nærmere på. Jeg ville siktet mot fem til åtte alternativer. Flere enn det gjør de neste trinnene raskt uhåndterlige.

Trinn 3: Lag en kortliste over prosjektstyringsverktøy

Nå har du en liste over kandidater og et tydelig bilde av hva du trenger. Dette trinnet handler om å redusere listen til tre eller fire verktøy som er verdt å teste grundig. Etter min erfaring hopper de fleste team over dette arbeidet og går rett til produktdemonstrasjoner – noe som betyr at de kaster bort timevis på salgspresentasjoner for verktøy som aldri ville passet.

Bruk disse kriteriene til å redusere den første listen til en håndterlig kortliste:

  • Dekning av ufravikelige krav: Støtter verktøyet alle punktene på listen over krav som ikke kan fravikes? Hvis bare ett mangler, bør du fjerne det. Ikke anta at du kan finne en omvei.
  • Tilpasning til prismodellen: Passer prismodellen til hvordan teamet ditt er organisert? Kostnader per bruker får ulik betydning for et team på 10 personer sammenlignet med en organisasjon på 60 personer. Regn ut de faktiske tallene.
  • Integrasjonsdybde: Kobler det seg til verktøyene teamet ditt bruker hver dag, eller oppgir det bare at de støttes? Det er en reell forskjell mellom en integrasjon som er innebygd, og en omvei via en tredjepart.
  • Tilpasning til distribusjon og sikkerhet: Oppfyller det IT- eller samsvarskravene dine? Undersøk om leverandørens vertsregioner og distribusjonsalternativer oppfyller kravene dine til datalagringssted.
  • Anmeldelsessignal: Hva sier personer med samme teamstørrelse og arbeidstype som deg faktisk? Én eller to dårlige anmeldelser diskvalifiserer ikke et verktøy, men et gjennomgående mønster gjør det.

Bruk denne tabellen til å sammenligne de gjenværende kandidatene før du bestiller demonstrasjoner:

EvalueringsfaktorHva du bør undersøke
Ufravikelige funksjonerAlle ufravikelige krav er oppfylt.
Pris for din teamstørrelseFaktisk kostnad, ikke introduksjonspris
IntegrasjonskompatibilitetInnebygde integrasjoner eller koblinger via tredjepart
Sikkerhet og samsvarDatalagringssted, SSO, tillatelser
Mønstre i brukeranmeldelserGjennomgående temaer, ikke avvik


Når du har snevret inn til den endelige kortlisten, er det på tide å kontakte leverandørene. Kontakt dem i løpet av samme uke hvis du kan – du får mer ut av samtalene når verktøyene fortsatt er friskt i minnet, og du kan sammenligne svarene side om side.

Når du bestiller demonstrasjoner, bør du ta med kravlisten din og be leverandørene vise deg de faktiske arbeidsflytene dine, ikke standardpresentasjonen deres. Det er den raskeste måten å finne ut om et verktøy passer, eller bare ser ut som om det gjør det.

Etter hver demonstrasjon bør du sammenligne verktøyene ut fra de samme kravene, kostnadene og integrasjonsbehovene. Når det er mulig, bør teammedlemmer teste en reell arbeidsflyt i løpet av en gratis prøveperiode. Dokumenter avveiningene og identifiser verktøyet du foretrekker å anbefale i beslutningsgrunnlaget.

Ved slutten av dette trinnet bør du ha et foretrukket verktøy å anbefale, tydelige grunner til valget og et reservealternativ ved behov.

Trinn 4: Utarbeid beslutningsgrunnlaget

Et beslutningsgrunnlag er ikke bare en formalitet for å få godkjent budsjettet. Etter min erfaring er det den tydeligste måten å kvalitetssikre om du faktisk har valgt riktig verktøy – og å avklare forventningene før noen inngår en avtale.

Ved slutten av dette trinnet bør du ha et dokument på én eller to sider som interessentene dine kan lese på fem minutter og forstå avveiningen du ber dem om å gjøre.

Følg denne prosessen for å utarbeide et beslutningsgrunnlag som tåler grundig gjennomgang:

  • Kvantifiser dagens kostnad ved å ikke gjøre noe: Estimer hvor mye tid teamene bruker på manuelle omveier, statusoppdateringer og koordineringsoppgaver i dag. Selv omtrentlige tall fungerer – poenget er å vise at dagens situasjon ikke er kostnadsfri.
  • Oppsummer forventet avkastning og resultater: Knytt de forventede gevinstene til konkrete arbeidsflytproblemer du identifiserte i trinn 1. Fokuser på resultater interessentene dine allerede bryr seg om: raskere leveransesykluser, færre oversittede frister og bedre oversikt over arbeidsbelastningen. Ikke lov resultater du ikke kan knytte tilbake til en funksjon.
  • Lag et realistisk kostnadsestimat: Ta med lisensiering, oppstart, eventuelt integrasjonsarbeid og intern tid brukt på konfigurering og opplæring. De fleste team undervurderer implementeringskostnadene ved å ignorere de to siste punktene. Ta høyde for forventet teamstørrelse om 12 og 24 måneder, ikke bare dagens antall ansatte.
  • Lag en tidsplan for implementeringen: Del utrullingen inn i faser. En trinnvis tilnærming er enklere å få godkjent og enklere å komme seg etter hvis noe ikke fungerer. Vis hvilke team som tas om bord først, og hva «ferdig» betyr for hver fase.
  • Beskriv risikoene og hvordan du vil håndtere dem: Adopsjonsrisiko er vanligvis den største. Ta direkte opp hva planen din er hvis folk går tilbake til e-post og regneark. Pek også på integrasjonsrisiko, kompleksitet knyttet til datamigrering og eventuell kontraktsmessig binding.

Bruk denne tabellen til å strukturere beslutningsgrunnlaget før du presenterer det for interessentene:

Element i beslutningsgrunnlagetDette bør inkluderes
Grunnlag for dagens kostnaderTid brukt på manuelt arbeid, tapte overleveringer og statusmøter
Forventede resultaterLeveringshastighet, oversikt og koordineringsarbeid
Total eierkostnadLisensiering, konfigurering, opplæring og integrasjonsarbeid
Tidsplan for implementeringTrinnvis utrulling, milepæler og rekkefølge for når teamene tas om bord
Risikoreduserende tiltakAdopsjonsplan, alternativer for tilbakeføring og kontraktsvilkår


Jeg ville holdt det endelige dokumentet kort. Hvis du trenger mer enn to sider for å argumentere for saken, har du sannsynligvis ikke destillert den godt nok. Målet er ikke å dekke alle detaljer – det er å gjøre avveiningen tydelig og beslutningen enkel.

Prisene mellom verktøyene varierer astronomisk. Det er viktig å vurdere hvor mange brukerlisenser du trenger, hvordan gjestebrukere håndteres, og hvilke tillegg som kreves, fordi kostnadene raskt kan løpe løpsk.

Harvey Eckstein

DPMs kjøperguide for prosjektstyringsprogramvare

Få en fullstendig gjennomgang av hvordan du kjøper riktig prosjektstyringsprogramvare med vår komplette kjøperguide:

Få kjøperguiden for prosjektstyringsprogramvare

Topp-produkter, markedsoversikt & alt annet du trenger å vite før du kjøper programvare.

By submitting this form, you agree to receive the PM Software Buyer's Guide, our newsletter, and occasional emails related to The Digital Project Manager. For details, review our privacy policy. You can unsubscribe at any time.

Trinn 5: Implementer prosjektstyringsprogramvaren og ta brukerne om bord

Å velge riktig verktøy er bare halve jobben. Etter min erfaring er det under implementeringen at de fleste utrullinger mislykkes i det stille – ikke fordi programvaren var feil, men fordi teamet ikke var godt nok forberedt på å faktisk bruke den.

Målet med dette trinnet er å gå fra «vi har valgt et verktøy» til «teamet jobber konsekvent i det». Denne overgangen skjer ikke av seg selv. Den krever bevisst kommunikasjon, tydelig eierskap og en tilbakemeldingssløyfe som fanger opp problemer før de blir vaner.

Før du går i produksjon, må du sørge for at du har dekket disse grunnleggende elementene i utrullingen:

  • Informer tidlig og forklar hvorfor: Fortell teamet hva som skal endres, når endringen skjer, og – viktigst av alt – hvorfor den er bedre enn det dere erstatter. Folk tar i bruk verktøy raskere når de forstår grunnen til byttet.
  • Utnevn en ansvarlig for utrullingen: Noen må være ansvarlig for oppsett, konfigurasjon og feilsøking. Dette trenger ikke å være en heltidsrolle, men det kan ikke være alles jobb, for da blir det ingens jobb.
  • Del opp utrullingen etter team eller arbeidsflyt: Ikke prøv å migrere alt på én gang. Begynn med ett team eller én arbeidsflyt, få det til å fungere godt, og utvid deretter. Dette begrenser konsekvensene hvis noe går galt.
  • Bygg opplæringen rundt det faktiske arbeidet: Generelle gjennomganger fester seg ikke. Gå gjennom de faktiske prosjektene og oppgavene teamet skal håndtere i verktøyet, ikke et demonstrasjonsscenario. Det er det som gjør at opplæringen fungerer.
  • Sett av tid til tilbakemeldinger: Velg en dato – to til fire uker etter lansering – der dere aktivt samler inn innspill. Jeg ville gjort dette i et kort møte, ikke gjennom en spørreundersøkelse. Du får høre ting i samtaler som folk ikke ville skrevet ned.
  • Definer hva «ferdig» betyr: Bli enige om hva vellykket bruk innebærer før dere lanserer. Er det en prosentandel av oppgavene som registreres i verktøyet? Statusoppdateringer som skjer uten påminnelser? Sett en tydelig terskel, slik at dere vet når den er nådd.

Bruk denne tabellen til å holde oversikt over de viktigste beslutningene dere må ta før lansering:

Beslutning om utrullingDette må defineres
Omfang ved lanseringHvilket team eller hvilken arbeidsflyt som starter først
Ansvarlig for utrullingenHvem som håndterer oppsett, tilgang og brukerstøtte
OpplæringsformatDirekte økt, asynkron video eller skriftlig veiledning
Mekanisme for tilbakemeldingerHvordan og når dere samler inn innspill etter lansering
SuksesskriterierHvordan bruk ser ut etter 30 og 90 dager


Ved slutten av dette trinnet bør teamet arbeide i verktøyet – ikke bare logge inn. Det er en viktig forskjell. Antallet innlogginger øker i den første uken. Det er jevnlig bruk uten påminnelser som viser at utrullingen faktisk fungerte.

Hva skjer videre?

Hvis du trenger litt mer hjelp til å velge riktig prosjektstyringsprogramvare for teamet ditt, kan det være lurt å se på listen over krav til prosjektstyringsprogramvare en gang til for å se hvor du kan begrense alternativene dine.

Du kan også lage en forespørsel om tilbud på prosjektstyringsprogramvare for å få mer informasjon fra potensielle leverandører om hva de tilbyr.

Før du går …

Vil du ha en praktisk visuell sjekkliste som hjelper deg med å huske trinnene? Det ordner jeg! Last ned den visuelle sjekklisten vår her: