Een goed projectvoorstel is het verschil tussen een opdracht die je krijgt en een die aan je neus voorbijgaat. Toch zien veel IT-voorstellen er hetzelfde uit: een lijst met taken, een prijs en een planning. Dat is niet genoeg.
Wat een projectvoorstel eigenlijk moet doen
Een voorstel is geen offerte. Dat klinkt misschien als een detail, maar het is een fundamenteel verschil. Een offerte zegt wat iets kost. Een voorstel legt uit waarom jij de juiste persoon bent voor dit specifieke probleem.
In de IT-sector gaat het vaak mis omdat de schrijver te snel naar de technische oplossing springt. Je beschrijft de stack, de tooling, de methodiek. Maar de opdrachtgever zit niet te wachten op een opsomming van technologieën. Die wil weten: begrijp jij wat er bij ons speelt?
Begin daarom altijd met een probleemomschrijving in eigen woorden. Niet kopiëren wat de opdrachtgever zelf heeft opgeschreven, maar laten zien dat je het hebt doorgrond. Dat kleine verschil maakt een groot verschil in hoe je voorstel binnenkomt.
De structuur die werkt
Er is geen universele template die altijd klopt, maar er zijn wel onderdelen die bijna nooit ontbreken in een sterk voorstel. De volgorde maakt daarbij meer uit dan je denkt.
Een logische opbouw ziet er zo uit: begin met de context en het probleem, dan de aanpak, dan de planning, dan de prijs. Niet andersom. Veel mensen zetten de prijs vooraan omdat ze denken dat de opdrachtgever dat toch als eerste zoekt. Misschien. Maar als je de prijs toont voordat je de waarde hebt uitgelegd, beoordeel je jezelf op kosten in plaats van op kwaliteit.
De aanpak is het hart van je voorstel. Wees concreet over wat je gaat doen en waarom je het zo aanpakt. Vage termen als “agile werken” of “iteratief ontwikkelen” zeggen weinig als ze niet worden uitgelegd in de context van het project. Koppel elke keuze aan het probleem dat je eerder hebt beschreven.
Toon en taalgebruik
Je schrijft een voorstel, geen scriptie. Dat betekent: korte zinnen, actieve werkwoorden, geen passieve constructies die de verantwoordelijkheid wegstoppen. “Er zal worden gewerkt aan…” is slechter dan “Ik werk aan…”.
Directheid wordt in de IT-wereld vaak gewaardeerd, maar dat is geen excuus voor kil of afstandelijk taalgebruik. Je mag gewoon schrijven zoals je praat, als je maar zeker weet dat de boodschap helder is. Lees je voorstel hardop voor. Struikel je ergens? Dan struikelt de lezer ook.
Pas op voor jargon dat je zelf vanzelfsprekend vindt maar dat voor de opdrachtgever ondoorzichtig is. Woorden als “deployment pipeline”, “containerisatie” of “microservices” mogen erin als de opdrachtgever ze kent. Ken je de achtergrond van je lezer niet precies, dan leg je ze kort uit of je vermijdt ze. Onduidelijkheid schept twijfel, en twijfel verlies je.
Wat je kunt opnemen in je voorstel
Naast de standaardonderdelen zijn er elementen die een voorstel sterker maken zonder dat het langer hoeft te worden. Denk aan:
- Een korte probleemanalyse in twee of drie zinnen, in jouw woorden
- Een schets van de aanpak per fase, met voor elke fase een concreet resultaat
- Een overzicht van wat je van de opdrachtgever nodig hebt, zodat hij weet dat jij weet dat samenwerking twee kanten op gaat
- Een risicoanalyse met één of twee scenario’s die realistisch zijn, niet een lijst van twintig onwaarschijnlijke gevallen
- Referenties of een korte beschrijving van vergelijkbaar werk, zonder een volledig portfolio te dumpen
- Een duidelijke volgende stap: wat verwacht je van de opdrachtgever na het lezen?
Dat laatste punt wordt het vaakst vergeten. Een voorstel zonder call to action laat de opdrachtgever in het ongewisse over wat er nu moet gebeuren. Zet er gewoon in: “Als dit voorstel aansluit bij wat je zoekt, plan dan een gesprek in via…” of “Ik neem volgende week contact op om vragen te bespreken.” Simpel, maar effectief.
Prijs en waarde in balans
Prijzen zetten is een vak apart, maar er zijn een paar principes die bijna altijd opgaan. Laat de prijs niet zweven zonder context. Een bedrag van 8.000 euro voelt anders als je hebt uitgelegd wat er allemaal in zit dan als je het gewoon onderaan de pagina plaatst.
Werk met vaste prijzen waar dat kan, en wees eerlijk over wat er buiten de scope valt. Opdrachtgevers haten verrassingen achteraf meer dan een hogere prijs vooraf. Een helder prijsplaatje met een goede toelichting wekt vertrouwen. Een vage indicatie met veel voorbehouden wekt argwaan.
Als je met uurtarieven werkt, geef dan een schatting van het aantal uren per fase. Niet tot op de minuut nauwkeurig, maar genoeg om de opdrachtgever een beeld te geven. “Fase 1: ontwerp en analyse, circa 12 uur” is bruikbaarder dan “ontwerp: nader te bepalen”.
Vergeet ook niet: de prijs in je voorstel is niet alleen een getal. Het is ook een signaal over hoe jij jezelf positioneert. Een te lage prijs kan net zo veel twijfel wekken als een te hoge. Als jij weet wat je waard bent, laat dat dan ook zien in hoe je over je prijs schrijft.
Soms helpt het om te kijken hoe andere vakgebieden omgaan met het specificeren van werk en materialen. In sectoren als de maakindustrie, waar precisie letterlijk het product is, zijn gedetailleerde specificaties en heldere categorisering van kosten heel gewoon. Als je op zoek bent naar inspiratie voor hoe dat eruitziet, kun je bekijk het aanbod van een gespecialiseerde partij als richtlijn gebruiken voor hoe werk concreet wordt omschreven per categorie.
Veelgestelde vragen over IT-projectvoorstellen
Hoe lang moet een projectvoorstel zijn?
Er is geen vaste lengte, maar twee tot vijf pagina’s is voor de meeste IT-projecten een realistisch bereik. Korter kan als het project eenvoudig is en je de opdrachtgever al goed kent. Langer is soms nodig bij complexe trajecten met meerdere fases of stakeholders. Wat je wilt vermijden: opvulling. Een voorstel van tien pagina’s waarvan zes pagina’s standaardtekst zijn, werkt averechts. Elke zin moet iets toevoegen.
Wanneer stuur je een voorstel, en wanneer eerst een gesprek?
Een voorstel stuur je nadat je voldoende informatie hebt om het goed te schrijven. Dat klinkt vanzelfsprekend, maar in de praktijk gaan veel mensen te snel aan de slag. Als je de opdracht niet goed begrijpt, schrijf je een voorstel dat niet aansluit. Een kort verkennend gesprek van dertig minuten kan je uren schrijfwerk besparen en de kwaliteit van je voorstel sterk verbeteren. Vraag door op het probleem, de context, de verwachtingen en het budget. Dan schrijf je gerichter.
Hoe ga je om met een opdrachtgever die alleen op prijs selecteert?
Dat is een reële situatie, en eerlijk gezegd ook een die je iets vertelt over de samenwerking die zou volgen. Als een opdrachtgever uitsluitend op prijs selecteert, is er weinig ruimte om te laten zien wat je waard bent. Toch kun je in je voorstel proberen de waarde zo concreet mogelijk te maken: wat levert het op, wat kost het als het misgaat, wat onderscheidt jouw aanpak? Soms verschuift de focus dan alsnog. En soms niet. In dat geval is het de vraag of dit de juiste opdracht voor je is.