Wat een goed softwarevoorstel moet bevatten: onze tien puntenWat een goed softwarevoorstel moet bevatten: onze tien punten

01Het probleem, de scope, en wat erbuiten valt

Een voorstel opent met het probleem, geformuleerd in de eigen woorden van de klant. Parafraseren wij het in de onze, dan wordt elk misverstand meteen zichtbaar — wat goed is, want het komt aan het licht vóór het contract.

Daarna komt de scope, als een lijst met items — elk item een op te leveren resultaat, geen intentie. Het derde punt wordt het vaakst overgeslagen: wat buiten scope valt. 'Geen mobiele app in deze release', 'contentinvoer is voor de klant', 'licenties voor externe integraties niet inbegrepen'. Die lijst opstellen voelt ongemakkelijk, en precies daarom is hij waardevol.

02Vraag naar het werk achter dezelfde titel

"Wij willen een CRM" is een minder goed startpunt dan "we missen bij het opvolgen van offertes welke klant wanneer moet worden teruggebeld". Zodra het probleem duidelijk is, worden ook de benodigde schermen en meldingen concreet; u hoeft dan geen budget te reserveren voor modules die niet gebruikt gaan worden.

"Er is rapportage" is op zichzelf niet voldoende. Welke gegevens worden getoond, over welke periode en voor welke gebruiker? Is export nodig? Wordt er een koppeling gevraagd met uw boekhoud-, magazijn-, betaal- of verkoopsysteem, dan hoort niet alleen de naam van de integratie in de offerte, maar ook de richting van de gegevensstroom, de technische toegangsvoorwaarden en wat er gebeurt bij een fout.

03Planning, mijlpalen en verantwoordelijkheden van de klant

Wij drukken de planning uit in mijlpalen in plaats van weeknummers: goedkeuring ontwerp, interne oplevering, acceptatietests, livegang. Elke mijlpaal heeft een op te leveren resultaat en een aangewezen goedkeurder. Data hangen af van de mijlpalen, niet andersom.

Het vijfde punt is de verantwoordelijkheden van de klant, de bron van de meeste vertragingen: merkbestanden, domeintoegang, inloggegevens voor de boekhoudkoppeling, contentteksten, realistische testdata. Dit met data in het voorstel opnemen, is niet bedoeld om schuld toe te wijzen; het stelt beide partijen in staat te plannen.

04Vraag bij gefaseerde levering naar de eerste werkende versie

Vraag welk werk u al kunt uitvoeren met de eerste werkende versie. Een servicebedrijf kan bijvoorbeeld eerst werkorders aanmaken, monteurs toewijzen en de status volgen; uitgebreide analyses komen in een latere fase aan bod. Dit is een illustratief voorbeeld; de juiste volgorde hangt af van de prioriteiten van uw organisatie. Hoe u de eerste versie klein en afgerond houdt, hebben we beschreven in ons artikel over hoe een MVP een softwareidee sneller lanceert.

Ook hoe wijzigingen worden beheerd, hoort in de offerte. Het is normaal dat er tijdens de ontwikkeling nieuwe ideeën ontstaan; maar elk nieuw verzoek onopgemerkt aan de bestaande planning toevoegen, is niet betrouwbaar. De impact van een wijziging op kosten, doorlooptijd en andere functies moet zichtbaar worden gemaakt.

05Voorwaarden voor data, rechten en broncode

Medewerkers, beheerders en klanten mogen niet dezelfde informatie te zien krijgen. De overdracht en back-up van gegevens, de levering van de broncode en licenties van derden moeten expliciet worden besproken. Het is belangrijk vooraf te weten welke bestanden en toegangen bij afronding van het project worden overgedragen; hoe wij dit invullen, hebben we uitgewerkt in ons artikel over wat hoort in het opleverpakket van sleutelklare software.

06Prijs, betaalschema, garantie en overdracht

De prijs gaat samen met een betaalschema dat gekoppeld is aan mijlpalen, niet aan de kalender. Valuta, btw-behandeling en de datum waarop de wisselkoers wordt vastgelegd, worden expliciet vermeld — voor EU-klanten scheelt die ene regel de helft van de vervolgcorrespondentie.

De laatste drie punten: de garantieperiode en wat deze dekt, de inhoud van het overdrachtspakket, en de vervaldatum van het voorstel. Die vervaldatum is geen drukmiddel — hij zorgt ervoor dat wij eerlijk kunnen antwoorden wanneer iemand drie maanden later vraagt of het voorstel nog geldig is.

Foutherstel, de ontwikkeling van nieuwe functies en onderhoud zijn verschillende werkzaamheden. Vraag in plaats van een brede zin als "support inbegrepen" naar de precieze scope en de manier van communiceren. Bij een sleutelklare oplevering installeren en testen wij de overeengekomen software op een server die aan de technische eisen voldoet, en leveren we deze werkend op. Vanaf de oplevering bieden we 12 maanden garantie op het herstellen van fouten; nieuwe functies worden apart beoordeeld. Standaardondersteuning loopt tijdens kantooruren; een apart 24-uurs ondersteuningspakket en een apart jaarlijks onderhoudscontract kunnen daarnaast worden overwogen. Onze maatwerksoftware-ontwikkeling bieden we met deze scope aan.

07Let op deze zeven punten bij het vergelijken van offertes

• Is het probleem beschreven vóór de lijst met te kopen modules?
• Zijn de gebruikersscenario's binnen de scope gedefinieerd met gegevens, periode en rechten?
• Zijn de integraties beschreven met richting, toegang en foutafhandeling?
• Staat vast welk werk in de eerste werkende versie wordt afgerond en wat het acceptatiecriterium is?
• Zijn gegevensoverdracht, rechten, broncodelevering en licenties expliciet vastgelegd?
• Is aangegeven hoe wijzigingsverzoeken de kosten en doorlooptijd beïnvloeden?
• Zijn garantie, ondersteuning en onderhoud afzonderlijk gedefinieerd?