En god projektbeskrivelse for software beskriver problemet, brugerne, de involverede systemer, og hvordan succes ser ud, og lader løsningen stå åben, så partnerne kan foreslå den. Send den samme beskrivelse til alle partnere med en budgetramme og en klar liste over, hvad der ligger fast, så bliver de tilbud, du får tilbage, præcise nok til at blive sammenlignet.
En projektbeskrivelse findes for at gøre svarene sammenlignelige
En projektbeskrivelse har én opgave: at lade flere partnere forstå dit problem godt nok til at foreslå en måde at løse det på, med et estimat, du kan stole på. Hvis hver partner udfylder hullerne med sine egne antagelser, adskiller tilbuddene sig i omfang frem for i kvalitet, og det billigste er ofte det, der antog mindst.
Beskrivelsen skal derfor være præcis om problemet og beskeden om løsningen. Beskriv, hvad der skal være opfyldt, når projektet er færdigt, og lad partnerne forklare, hvordan de vil nå dertil. Deres svar på den åbne del er det mest nyttige, du kommer til at læse.
Start med forretningsproblemet, og hvordan du vil bedømme succes
Indled med grunden til, at projektet findes: hvad der ikke virker i dag, hvem det rammer, og hvad det koster dig at lade det være, som det er. At skrive, at dit driftsteam taster hver ordre fra e-mail ind i ERP-systemet igen, fortæller en partner langt mere end at bede om en portal til ordrestyring.
Sig derefter, hvordan du vil bedømme succes. Vælg nogle få resultater, du kan observere, for eksempel sparet tid pr. ordre, fejl, der ikke længere når kunderne, eller en dato, hvor et gammelt system kan slukkes. Disse kriterier bliver senere til acceptkriterierne for milepælene, så formulér dem, så nogen kan tjekke dem.
Beskriv brugere, systemer og data før funktioner
Integrations- og dataarbejde er let at undervurdere, når en partner ikke kan se det. Før du oplister funktioner, så beskriv, hvem der skal bruge softwaren, hvilke systemer den skal arbejde sammen med, og hvilke data den håndterer. Huller i denne del kommer senere tilbage som ændringsønsker.
- Brugere: hvem de er, cirka hvor mange, og hvor og på hvilke enheder de arbejder.
- Eksisterende systemer: hvad de er, hvem der ejer dem, og om de har et dokumenteret API eller kun en database og fileksport.
- Data: hvad der er personligt, fortroligt eller reguleret, hvor det ligger i dag, og hvor meget der skal migreres.
- Drift: hvem der skal drive softwaren efter lanceringen, og hvilke regler for hosting eller cloud din virksomhed allerede har.
- Rammer: sprog, krav til tilgængelighed, sikkerhedsstandarder og enhver deadline, der ikke kan flyttes, med grunden til den.
Del en budgetramme og den deadline, der virkelig betyder noget
Mange købere holder budgettet tilbage for at se, hvad partnerne foreslår. Resultatet er tilbud på forskellige projekter: én partner designer til minimum, en anden til alt, hvad du nævnte. En ramme, selv en bred, lader hver partner foreslå det bedste projekt, der passer inden for den, og sige ligeud, hvis den ikke rækker.
Gør det samme med tiden. Sig, hvilken dato der ligger fast og hvorfor, for eksempel en kontrakt, der udløber, eller en lovpligtig frist, og hvilke datoer der kun er ønsker. En partner kan kun planlægge efter en fast dato, hvis den ved, hvilken det er.
Markér, hvad der ligger fast, og lad resten stå åbent
Markér hvert krav som fast, foretrukket eller åbent. Fast betyder, at et tilbud ikke er gyldigt uden det, for eksempel hosting i EU eller login via din eksisterende identitetsudbyder. Foretrukket betyder, at du har en grund, men vil overveje et alternativ. Åbent betyder, at du vil have partnerens anbefaling.
Lad teknologien stå åben, medmindre du har en reel grund til at låse den fast, for eksempel et internt team, der skal vedligeholde koden, eller en platform, din virksomhed har standardiseret på. Når du låser et valg fast, så sig hvorfor, så partnerne ikke bruger deres tilbud på at argumentere imod det.
Bed til sidst alle partnere om at svare i samme struktur: deres forståelse af problemet, tilgangen, faser og milepæle, antagelser, risici, teamet og den kommercielle model. En fælles struktur er det, der i praksis gør tilbuddene sammenlignelige.
Fejl, der gør tilbud umulige at sammenligne
Mange ubrugelige tilbud er svar på en beskrivelse, der inviterede til dem. Fjern disse mønstre, før du sender din.
- En liste over funktioner uden en problemformulering, så hver partner gætter på dine prioriteter.
- En lang specifikation, der låser løsningen fast, før nogen har undersøgt problemet.
- Ingen omtale af eksisterende systemer eller datamigrering, som så kommer tilbage som ændringsønsker.
- Ekstra oplysninger givet til nogle partnere i opkald, så deres tilbud besvarer forskellige spørgsmål.
- Ord som »enkel«, »standard« eller »som en kendt app«, der betyder noget forskelligt for hver læser.
- Ingen frist for spørgsmål, eller svar, der kun deles med den partner, der spurgte.
Inviter til spørgsmål, og læs dem som en del af evalueringen
Giv partnerne en fast periode til at stille spørgsmål, svar skriftligt, og send hvert svar til dem alle. Spørgsmålene siger noget i sig selv: en partner, der spørger til dine data, dine brugere og dine acceptkriterier, tænker allerede på leverancen.
Hvis problemet stadig er for usikkert til at blive beskrevet godt, så sig det, og bed om en kort, betalt afklaringsfase i stedet for et fuldt tilbud. Et fast tilbud bygget på gæt gemmer det ukendte i sin risikomargin; en afklaringsfase erstatter gættene med fakta. Hvis du vil have udviklere til at læse din projektbeskrivelse eller svare på den, kan du sende den via vores formular til at starte et projekt.
Det vigtigste
- Beskriv problemet, brugerne, og hvordan succes ser ud, og lad løsningen stå åben.
- Integrations- og dataarbejde er let at undervurdere, så list alle involverede systemer og datasæt.
- Del en budgetramme, og sig, hvilken deadline der ligger fast og hvorfor.
- Markér hvert krav som fast, foretrukket eller åbent, og bed om tilbud i én fælles struktur.
- Besvar spørgsmål skriftligt, og del hvert svar med alle partnere.
FAQ
Hvor lang skal en projektbeskrivelse for software være?
Lang nok til at dække problemet, brugerne, systemerne, dataene, rammerne, budgetrammen og tidsplanen, hvilket for de fleste projekter kan være på nogle få sider. Hvis den bliver meget længere, beskriver den sandsynligvis løsningen frem for problemet.
Skal jeg dele mit budget med softwarepartnere?
Ja, som en ramme. Uden den foreslår partnerne projekter af meget forskellig størrelse, og du kan ikke sammenligne dem. En ramme lader hver partner vise, hvad den ville gøre inden for den, og sige ærligt, hvis den ikke er nok.
Skal jeg bede om en fast pris som svar på en projektbeskrivelse?
Kun hvis beskrivelsen beskriver arbejdet detaljeret nok til, at det kan estimeres. Hvis vigtige spørgsmål stadig er åbne, så bed om en afklaringsfase til fast pris eller et estimat i et interval med angivne antagelser, og fastsæt prisen på udviklingen, når det ukendte er afklaret.