Skriv en projektbeskrivning som ger jämförbara offerter

En projektbeskrivning finns till för att göra svaren jämförbara

En projektbeskrivning har en uppgift: att låta flera partner förstå ditt problem tillräckligt väl för att föreslå ett sätt att lösa det, med en uppskattning som du kan lita på. Om varje partner fyller luckorna med egna antaganden skiljer sig förslagen i omfattning snarare än i kvalitet, och det billigaste är ofta det som antog minst.

Beskrivningen ska därför vara exakt om problemet och återhållsam om lösningen. Beskriv vad som ska gälla när projektet är klart, och låt partnerna förklara hur de skulle ta sig dit. Deras svar på den öppna delen är det mest användbara du kommer att läsa.

Börja med affärsproblemet och hur du ska bedöma framgång

Inled med skälet till att projektet finns: vad som inte fungerar i dag, vem det påverkar och vad det kostar dig att låta det vara som det är. Att säga att ditt driftteam skriver in varje order från mejl i affärssystemet för hand säger en partner mycket mer än att be om en portal för orderhantering.

Säg sedan hur du ska bedöma framgång. Välj några resultat som går att observera, till exempel sparad tid per order, fel som inte längre når kunderna eller ett datum då ett gammalt system kan stängas av. Kriterierna blir senare kriterier för godkännande av delmålen, så skriv dem så att någon kan kontrollera dem.

Beskriv användare, system och data före funktionerna

Integrations- och dataarbete är lätt att underskatta när en partner inte kan se det. Innan du listar funktioner: beskriv vem som ska använda mjukvaran, vilka system den måste fungera med och vilka data den hanterar. Luckor i den här delen kommer tillbaka senare som ändringsbegäranden.

• Användare: vilka de är, ungefär hur många och var och på vilka enheter de arbetar.
• Befintliga system: vilka de är, vem som äger dem och om de har ett dokumenterat API eller bara en databas och filexporter.
• Data: vad som är personuppgifter, konfidentiellt eller reglerat, var det finns i dag och hur mycket som måste migreras.
• Drift: vem som ska driva mjukvaran efter lanseringen, och vilka regler för hosting eller moln som ditt företag redan har.
• Begränsningar: språk, behov av tillgänglighet, säkerhetsstandarder och varje tidsfrist som inte kan flyttas, med skälet till den.

Dela en budgetram och den tidsfrist som verkligen spelar roll

Många köpare håller inne med budgeten för att se vad partnerna föreslår. Resultatet blir förslag på olika projekt: en partner utformar för minimum, en annan för allt du nämnde. En ram, även en bred, låter varje partner föreslå det bästa projekt som ryms inom den och säga rakt ut om den inte räcker.

Gör likadant med tiden. Säg vilket datum som är fast och varför, till exempel ett avtal som löper ut eller en regulatorisk tidsfrist, och vilka datum som bara är önskemål. En partner kan bara planera kring ett fast datum om den vet vilket det är.

Markera vad som är fast och lämna resten öppet

Märk varje krav som fast, önskat eller öppet. Fast betyder att ett förslag inte är giltigt utan det, till exempel hosting inom EU eller inloggning via din befintliga identitetsleverantör. Önskat betyder att du har ett skäl men kan tänka dig ett alternativ. Öppet betyder att du vill ha partnerns rekommendation.

Lämna tekniken öppen om du inte har ett verkligt skäl att låsa den, till exempel ett internt team som ska underhålla koden eller en plattform som ditt företag har standardiserat på. När du låser ett val: säg varför, så att partnerna inte lägger sina förslag på att argumentera emot det.

Be slutligen varje partner att svara i samma struktur: hur de förstår problemet, angreppssätt, faser och delmål, antaganden, risker, team och affärsmodell. En gemensam struktur är det som gör förslagen jämförbara i praktiken.

Misstag som gör förslagen omöjliga att jämföra

Många oanvändbara förslag är svar på en projektbeskrivning som bjöd in till dem. Ta bort de här mönstren innan du skickar din.

• En funktionslista utan problembeskrivning, så att varje partner gissar sig till dina prioriteringar.
• En lång specifikation som låser lösningen innan någon har undersökt problemet.
• Inget om befintliga system eller datamigrering, som sedan kommer tillbaka som ändringsbegäranden.
• Extra detaljer som ges till vissa partner i samtal, så att deras förslag svarar på andra frågor.
• Ord som ”enkel”, ”standard” eller ”som en välkänd app”, som betyder något olika för varje läsare.
• Ingen sista dag för frågor, eller svar som bara delas med den partner som frågade.

Bjud in till frågor och läs dem som en del av utvärderingen

Ge partnerna en bestämd period för frågor, svara skriftligt och skicka varje svar till alla. Frågorna säger något i sig: en partner som frågar om dina data, dina användare och dina kriterier för godkännande tänker redan på leveransen.

Om problemet fortfarande är för osäkert för att beskrivas väl: säg det och be om en kort, betald förstudie i stället för ett fullständigt förslag. En fast offert som bygger på gissningar döljer de okända faktorerna i sin riskmarginal; en förstudie ersätter gissningarna med fakta. Om du vill att utvecklare läser din projektbeskrivning, eller svarar på den, kan du skicka den via vårt formulär ”Starta ett projekt”.

Vanliga frågor