Slik velger du programvare for prosjektstyring
Å 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 ditt med å få mer verdi ut av investeringen.
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.
Have an account? Log In
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
Integrasjoner kobler prosjektstyringsprogramvare til verktøy teamet ditt allerede bruker, for eksempel chat, kalendere, kodelagre og fillagring.
Kontroller om viktige integrasjoner synkroniserer dataene arbeidsflyten din trenger, og se etter duplikate 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 teammedlemmene kan håndtere 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 tydelige priser når bruken øker. 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 abonnementer eller legge til funksjoner.
3. Rollebasert tilgang og tillatelser
Rollebasert tilgang lar deg kontrollere hvem som kan se, redigere, godkjenne eller administrere prosjektdata. Se etter detaljerte, enkle tillatelser å revidere 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 synlighet i data
Rapportering omgjør prosjektaktivitet til visninger av fremdrift, arbeidsbelastning, risikoer og trender for levering. Se etter rapporter du kan filtrere etter prosjekt, team og tidsperiode, og unngå instrumentpaneler som skjuler hvordan målingene beregnes.
Spør: Hvilke beslutninger bør teamet ditt ta basert på prosjektdata, og kan programvaren vise informasjonen som ligger bak disse beslutningene?
Slik velger du prosjektstyringsprogramvare: En modell i 5 trinn
Bruk disse fem trinnene til å vurdere arbeidsflyten din, teste hvor godt verktøyet passer, og ta et trygt 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 trinnet det som får team til å velge programvare som ser flott ut i en demo, 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 gapet mellom dem er der de reelle kravene dine finnes.
Snakk med disse interessentene før du bestemmer deg for noe:
- Prosjektledere: Hva registrerer de manuelt som burde være automatisk? Hvor glipper ting?
- 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?
- Ledelse og sponsorer: Hvilke prosjektdata trenger de for å ta beslutninger, og hvor ofte?
- IT eller drift: Hvilke sikkerhets-, samsvars- eller integrasjonsbegrensninger 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 tilgangsnivåer?
- Hvilke verktøy må programvaren kunne koble seg til fra dag én?
- Finnes det samsvars-, datalagrings- eller sikkerhetskrav som begrenser alternativene dine?
- Hvordan ser «suksess» ut om seks måneder, og hvordan vil du måle den?
Ved slutten av dette trinnet bør du ha en kort liste over krav, en separat liste over ønskede funksjoner og et tydelig bilde av arbeidsflytene verktøyet må støtte. Dette skillet betyr mer enn de fleste team innser – når du slår sammen de to listene, ender du opp med å betale for mye for funksjoner ingen bruker.
Trinn 2: Undersøk leverandører av prosjektstyringsprogramvare
Når du vet hva du trenger, er det på tide å se på hva som finnes. Jeg ville motstått fristelsen til å google «beste prosjektstyringsprogramvare» og klikke på det første resultatet. Slike lister kan lede deg mot de mest populære verktøyene, ikke det riktige verktøyet for teamets situasjon.
Bruk heller flere kilder og vurder hver av dem på forskjellige 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 selvstendig frilanser verdsetter, er annerledes enn det et ingeniørteam på 50 personer trenger.
- Analytiker- og sammenligningsnettsteder: Bruk disse til å kartlegge markedet og forstå hvordan leverandørene posisjonerer seg. De egner seg bedre for bredde enn dybde.
- Forum og Slack-grupper: Disse avdekker reelle frustrasjoner som leverandørene ikke vil reklamere med. Søk etter verktøynavnet sammen med ord som «problem», «begrensning» eller «byttet fra».
- Leverandørdokumentasjon: Gå rett til produktdokumentasjonen, ikke bare markedsføringsnettstedet. Dokumentasjonen forteller deg hva et verktøy faktisk gjør – markedsføringen forteller deg hva de ønsker at du skal tro at det gjør.
- Nylige versjonsmerknader 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 bruker:
| Kildetype | Best egnet til | Vær oppmerksom på |
|---|---|---|
| Anmeldelsesnettsteder | Brukernes faktiske oppfatning | Hvor nylig innholdet er publisert, og relevans for rollen |
| Leverandørenes markedsføringsnettsteder | Forstå posisjoneringen | Overdrevne funksjoner |
| Forum | Kjente problemområder | Avvikende meninger eller gamle innlegg |
| Analytikerrapporter | Markedskontekst | Skjevhet mot verktøy for store virksomheter |
| Produktdokumentasjon | Faktisk funksjonsdybde | Ufullstendig eller utdatert innhold |
Ta hensyn til teamstørrelsen og virksomhetens behov når du undersøker leverandører. For eksempel er noen prosjektstyringsverktøy godt egnet for oppstartsbedrifter og små virksomheter, mens personer som håndterer sine egne prosjekter kan prioritere rimelige priser, enkel oppstart og enkel oppgavehåndtering fremfor avanserte funksjoner.
Ved slutten av dette trinnet bør du ha en foreløpig liste over leverandører som sannsynligvis oppfyller kravene dine – ikke en kortliste ennå, bare kandidater som er verdt å undersøke nærmere. Jeg ville siktet mot fem til åtte alternativer. Flere enn det gjør de neste trinnene raskt uhåndterlige.
De beste prosjektstyringsverktøyene du bør vurdere
Here's my pick of the 10 best software from the 10 tools reviewed.
Clicks on the links below may earn a commission, which supports our independent testing and review of software and services. Learn more about how we stay transparent.
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 demonstrasjoner – noe som betyr at de kaster bort timer på salgspresentasjoner for verktøy som aldri ville passet.
Bruk disse kriteriene til å redusere den opprinnelige listen til en håndterlig kortliste:
- Dekning av nødvendige funksjoner: Støtter verktøyet alle punktene på listen over ufravikelige krav? Hvis bare ett mangler, bør du fjerne verktøyet. Ikke anta at du kan omgå mangelen.
- Prisstruktur: Passer prismodellen til hvordan teamet ditt er organisert? Kostnader per bruker slår ulikt ut for et team på 10 personer sammenlignet med en organisasjon på 60 personer. Regn ut de faktiske kostnadene.
- Integrasjonsnivå: Kobler det seg til verktøyene teamet ditt bruker daglig, eller viser det dem bare som støttede verktøy? Det er en reell forskjell mellom en innebygd integrasjon og en løsning via en tredjepart.
- Egnethet for implementering og sikkerhet: Oppfyller det IT- eller samsvarskravene dine? Kontroller om leverandørens plassering av driftsmiljøer og implementeringsalternativer oppfyller kravene dine til hvor dataene lagres.
- Tilbakemeldingsbildet: 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:
| Vurderingsfaktor | Dette bør du kontrollere |
|---|---|
| Nødvendige funksjoner | Alle ufravikelige krav er oppfylt. |
| Pris for din teamstørrelse | Faktisk kostnad, ikke inngangspris |
| Integrasjonskompatibilitet | Innebygde integrasjoner eller koblinger via tredjepart |
| Sikkerhet og samsvar | Hvor dataene lagres, SSO, tillatelser |
| Mønstre i brukeranmeldelser | Gjennomgående temaer, ikke avvikende tilfeller |
Når du har redusert listen 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 direkte.
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 om det bare ser slik ut.
Etter hver demonstrasjon bør du sammenligne verktøyene mot de samme kravene, kostnadene og integrasjonsbehovene. Når det er mulig, bør du la teammedlemmer teste en faktisk arbeidsflyt i løpet av en gratis prøveperiode. Dokumenter avveiningene og identifiser verktøyet du foretrekker, slik at du kan anbefale det i beslutningsgrunnlaget.
Ved slutten av dette trinnet bør du ha et foretrukket verktøy å anbefale, tydelige begrunnelser for 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 på – og å avklare forventningene før noen begynner å forhandle om en kontrakt.
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 vurdering:
- Beregn dagens kostnad ved å ikke gjøre noe: Estimer hvor mye tid teamene bruker på manuelle løsninger, statusoppdateringer og koordineringsoppgaver i dag. Selv omtrentlige tall fungerer – poenget er å vise at dagens situasjon ikke er kostnadsfri.
- Oppsummer forventet ROI og resultater: Knytt de forventede gevinstene til konkrete arbeidsflytproblemer du identifiserte i trinn 1. Fokuser på resultater interessentene allerede bryr seg om: raskere leveransesykluser, færre oversittede frister og bedre oversikt over arbeidsmengden. Ikke lov resultater du ikke kan knytte 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 å overse de to siste punktene. Ta høyde for den forventede teamstørrelsen 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 gjør det lettere å komme seg videre hvis noe ikke fungerer. Vis hvilke team som innføres først, og hva det vil si at hver fase er «ferdig».
- Beskriv risikoene og hvordan du vil håndtere dem: Risiko knyttet til bruk er vanligvis den største. Ta direkte opp hva planen er dersom folk går tilbake til e-post og regneark. Nevn også integrasjonsrisiko, kompleksitet ved datamigrering og eventuell binding til en leverandør.
Bruk denne tabellen til å organisere beslutningsgrunnlaget før du presenterer det for interessentene:
| Element i beslutningsgrunnlaget | Dette bør tas med |
|---|---|
| Basiskostnad i dag | Tid tapt på manuelt arbeid, overleveringer som glipper og statusmøter |
| Forventede resultater | Leveringshastighet, oversikt og koordineringsarbeid |
| Totale eierkostnader | Lisensiering, konfigurering, opplæring og integrasjonsarbeid |
| Tidsplan for implementeringen | Trinnvis utrulling, milepæler og rekkefølge for innføring i teamene |
| Risikoreduserende tiltak | Plan for innføring, alternativer for tilbakerulling 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 på tvers av verktøy varierer astronomisk. Det er viktig å vurdere hvor mange brukerlisenser du trenger, hvordan gjester håndteres, og hvilke tillegg som kreves, fordi kostnadene raskt kan løpe løpsk.
DPMs kjøpsguide for programvare for prosjektstyring
Få en fullstendig gjennomgang av hvordan du kjøper riktig programvare for prosjektstyring, i vår komplette kjøpsguide:
Få kjøpsguiden for programvare for prosjektstyring
Trinn 5: Implementer programvaren for prosjektstyring og lær opp brukerne
Å velge riktig verktøy er bare halve jobben. Etter min erfaring er det under implementeringen at de fleste utrullinger i det stille mislykkes – ikke fordi programvaren var feil, men fordi teamet ikke var 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 live, må du sørge for at du har dekket disse grunnleggende punktene for utrullingen:
- Informer tidlig og forklar hvorfor: Fortell teamet hva som skal endres, når det skal skje og – viktigst av alt – hvorfor den nye løsningen er bedre enn det dere erstatter. Folk tar i bruk verktøy raskere når de forstår årsaken til endringen.
- Utnevn en ansvarlig for utrullingen: Noen må være ansvarlig for oppsett, konfigurering og feilsøking. Dette trenger ikke å være en heltidsrolle, men det kan ikke være alles jobb, for da blir det ingens jobb.
- Faseinndel utrullingen etter team eller arbeidsflyt: Ikke prøv å migrere alt på én gang. Start 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 dette som gjør at opplæringen treffer.
- Sett av et tidsrom for tilbakemeldinger: Velg en dato – to til fire uker etter lanseringen – hvor dere aktivt samler inn tilbakemeldinger. 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 lanseringen. Er det en prosentandel av oppgavene som er registrert i verktøyet? Statusoppdateringer som skjer uten påminnelser? Sett en tydelig målestokk, slik at du vet når dere har nådd den.
Bruk denne tabellen til å holde oversikt over de viktigste beslutningene dere må ta før lansering:
| Beslutning om utrulling | Hva som må defineres |
|---|---|
| Lanseringsomfang | Hvilket team eller hvilken arbeidsflyt som starter først |
| Ansvarlig for utrullingen | Hvem som håndterer oppsett, tilgang og brukerstøtte |
| Opplæringsformat | Live-økt, asynkron video eller skriftlig veiledning |
| Mekanisme for tilbakemeldinger | Hvordan og når dere samler inn tilbakemeldinger etter lanseringen |
| Suksesskriterier | Hvordan bruken ser ut etter 30 og 90 dager |
Ved slutten av dette trinnet bør teamet ditt arbeide i verktøyet – ikke bare logge inn. Det er en viktig forskjell. Innloggingene øker kraftig den første uken. Det som viser at utrullingen faktisk fungerte, er konsekvent bruk uten påminnelser.
Hva skjer videre?
Hvis du trenger litt mer hjelp til å velge riktig prosjektstyringsprogramvare for teamet ditt, kan det lønne seg å se en gang til på listen over krav til prosjektstyringsprogramvare for å se hvor du kan snevre inn alternativene dine.
Du kan også lage en RFP for prosjektstyringsprogramvare for å få mer informasjon fra potensielle leverandører om hva de tilbyr.
Før du går videre …
Vil du ha en praktisk visuell sjekkliste som hjelper deg med å huske trinnene? Det ordner jeg! Last ned den visuelle sjekklisten her:
