--- title: "Skriv en prosjektbeskrivelse som gir sammenlignbare tilbud" description: "Hva en prosjektbeskrivelse for programvare bør inneholde for presise tilbud: problem, brukere, systemer, data, budsjettramme, hva som er åpent, feil å unngå." canonical: https://sdk.enterprises/no/insights/writing-a-software-project-brief language: no --- # Skriv en prosjektbeskrivelse som gir sammenlignbare tilbud Oppdatert: 2026-09-26 > En god prosjektbeskrivelse for programvare beskriver problemet, brukerne, systemene som er involvert, og hvordan suksess ser ut, og lar løsningen stå åpen, slik at partnerne kan foreslå den. Send alle partnerne den samme beskrivelsen med en budsjettramme og en tydelig liste over hva som er fastsatt, så blir forslagene du får tilbake presise nok til å sammenlignes. ## En prosjektbeskrivelse finnes for å gjøre svarene sammenlignbare En prosjektbeskrivelse har én oppgave: å la flere partnere forstå problemet ditt godt nok til å foreslå en måte å løse det på, med et estimat du kan stole på. Hvis hver partner fyller hullene med sine egne antakelser, skiller forslagene seg i omfang heller enn i kvalitet, og det billigste er ofte det som antok minst. Beskrivelsen bør derfor være presis om problemet og beskjeden om løsningen. Beskriv hva som må være på plass når prosjektet er ferdig, og la partnerne forklare hvordan de ville kommet dit. Svarene deres på den åpne delen er det mest nyttige du kommer til å lese. ## Start med forretningsproblemet og hvordan du skal vurdere suksess Åpne med grunnen til at prosjektet finnes: hva som ikke fungerer i dag, hvem det rammer, og hva det koster deg å la det være som det er. Å fortelle at driftsteamet ditt taster inn hver bestilling fra e-post i ERP-systemet på nytt, sier en partner langt mer enn å be om en portal for ordrehåndtering. Si deretter hvordan du skal vurdere suksess. Velg noen få resultater du kan observere, for eksempel spart tid per bestilling, feil som ikke lenger når kundene, eller en dato da et gammelt system kan slås av. Disse kriteriene blir senere godkjenningskriteriene for milepælene, så skriv dem slik at noen kan kontrollere dem. ## Beskriv brukere, systemer og data før funksjoner Integrasjons- og dataarbeid er lett å undervurdere når en partner ikke kan se det. Før du lister opp funksjoner, bør du beskrive hvem som skal bruke programvaren, hvilke systemer den må fungere sammen med, og hvilke data den håndterer. Hull i denne delen kommer tilbake senere som endringsforespørsler. - Brukere: hvem de er, omtrent hvor mange, og hvor og på hvilke enheter de jobber. - Eksisterende systemer: hva de er, hvem som eier dem, og om de har et dokumentert API eller bare en database og fileksport. - Data: hva som er personopplysninger, fortrolig eller regulert, hvor det ligger i dag, og hvor mye som må migreres. - Drift: hvem som skal drifte programvaren etter lansering, og hvilke regler for hosting eller sky bedriften din allerede har. - Rammer: språk, krav til universell utforming, sikkerhetsstandarder og eventuelle frister som ikke kan flyttes, med begrunnelsen. ## Del en budsjettramme og fristen som virkelig betyr noe Mange kjøpere holder budsjettet tilbake for å se hva partnerne foreslår. Resultatet er forslag til ulike prosjekter: én partner designer for minimum, en annen for alt du nevnte. En ramme, selv en vid en, lar hver partner foreslå det beste prosjektet som passer innenfor den, og si rett ut hvis det ikke går. Gjør det samme med tid. Si hvilken dato som er fast og hvorfor, for eksempel en kontrakt som utløper eller en regulatorisk frist, og hvilke datoer som bare er ønsker. En partner kan bare planlegge rundt en fast dato hvis den vet hvilken det er. ## Merk hva som er fastsatt, og la resten stå åpent Merk hvert krav som fastsatt, ønsket eller åpent. Fastsatt betyr at et forslag ikke er gyldig uten det, for eksempel hosting i EU eller innlogging via identitetsleverandøren du allerede har. Ønsket betyr at du har en grunn, men kan vurdere et alternativ. Åpent betyr at du vil ha partnerens anbefaling. La teknologien stå åpen med mindre du har en reell grunn til å låse den, for eksempel et internt team som skal vedlikeholde koden, eller en plattform bedriften din har standardisert på. Når du låser et valg, bør du si hvorfor, slik at partnerne ikke bruker forslaget sitt på å argumentere mot det. Be til slutt alle partnerne svare i den samme strukturen: hvordan de forstår problemet, tilnærmingen, faser og milepæler, forutsetninger, risikoer, teamet og den kommersielle modellen. En felles struktur er det som gjør forslagene sammenlignbare i praksis. ## Feil som gjør forslagene umulige å sammenligne Mange ubrukelige forslag er svar på en beskrivelse som la opp til dem. Fjern disse mønstrene før du sender din. - En funksjonsliste uten problembeskrivelse, slik at hver partner må gjette prioriteringene dine. - En lang spesifikasjon som låser løsningen før noen har undersøkt problemet. - Ingen omtale av eksisterende systemer eller datamigrering, som da kommer tilbake som endringsforespørsler. - Ekstra detaljer gitt til enkelte partnere i samtaler, slik at forslagene deres svarer på ulike spørsmål. - Ord som «enkel», «standard» eller «som en kjent app», som betyr noe forskjellig for hver leser. - Ingen frist for spørsmål, eller svar som bare deles med partneren som spurte. ## Inviter til spørsmål, og les dem som en del av vurderingen Gi partnerne en fast periode til å stille spørsmål, svar skriftlig, og send hvert svar til alle. Spørsmålene sier noe i seg selv: en partner som spør om dataene, brukerne og godkjenningskriteriene dine, tenker allerede på leveransen. Hvis problemet fortsatt er for usikkert til å beskrives godt, si det, og be om en kort, betalt forstudie i stedet for et fullstendig forslag. Et fast pristilbud bygget på gjetninger skjuler de ukjente i risikomarginen sin; en forstudie erstatter gjetningene med fakta. Hvis du vil at utviklere skal lese prosjektbeskrivelsen din, eller svare på den, kan du sende den via skjemaet «Start et prosjekt». ## Det viktigste - Beskriv problemet, brukerne og hvordan suksess ser ut, og la løsningen stå åpen. - Integrasjons- og dataarbeid er lett å undervurdere, så list opp alle systemer og datasett som er involvert. - Del en budsjettramme, og si hvilken frist som er fast, og hvorfor. - Merk hvert krav som fastsatt, ønsket eller åpent, og be om forslag i én felles struktur. - Svar skriftlig på spørsmål, og del hvert svar med alle partnerne. ## Spørsmål og svar ### Hvor lang bør en prosjektbeskrivelse for programvare være? Lang nok til å dekke problemet, brukerne, systemene, dataene, rammene, budsjettrammen og tidsplanen, noe som for de fleste prosjekter får plass på noen få sider. Hvis den blir mye lengre, beskriver den sannsynligvis løsningen heller enn problemet. ### Bør jeg dele budsjettet mitt med utviklingspartnere? Ja, som en ramme. Uten en ramme foreslår partnerne prosjekter av svært ulik størrelse, og du kan ikke sammenligne dem. En ramme lar hver partner vise hva den ville gjort innenfor den, og si ærlig fra hvis den ikke er nok. ### Bør jeg be om fastpris som svar på en prosjektbeskrivelse? Bare hvis beskrivelsen omtaler arbeidet detaljert nok til at det kan estimeres. Hvis viktige spørsmål fortsatt er åpne, be om en forstudie til fastpris eller et estimat som et intervall med oppgitte forutsetninger, og fastsett prisen på utviklingen når de ukjente er avklart. ## Start med behovet ditt - [Nettsideutvikling](https://sdk.enterprises/no/website-development) ## Relaterte tjenester - [Skreddersydd programvare](https://sdk.enterprises/no/services/product-engineering) - [Teknisk revisjon og rådgivning](https://sdk.enterprises/no/services/consulting) ## Videre lesning - [Hva en betalt forstudie for programvare bør levere](https://sdk.enterprises/no/insights/what-a-paid-discovery-phase-should-deliver) - [Fastpris eller medgått tid: slik velger du kontraktsmodell](https://sdk.enterprises/no/insights/fixed-price-or-time-and-materials)