Prompt-Gids
Een projectvoorstel schrijven met Claude
Een voorstel dat wordt goedgekeurd is concreet. Een voorstel dat wordt genegeerd is vaag.
Claude van Anthropic is goed in het omzetten van een ruw projectidee in een gestructureerd voorstel met een probleemstelling, scope, tijdlijn, en precies het soort concreet detail dat een stakeholder daadwerkelijk ja laat zeggen. Wat Claude niet weet, is je budget, de echte capaciteit van je team, of de interne politiek van je organisatie, tenzij je het vertelt, en daarom levert "schrijf me een projectvoorstel voor X" meestal iets op dat generiek genoeg is om bij elk bedrijf te passen. De oplossing is Claude de echte beperkingen te geven: voor wie het voorstel is, wat je daadwerkelijk tot je beschikking hebt, en welke beslissing je van die persoon nodig hebt.
Om Claude een projectvoorstel te laten schrijven, geef je het probleem dat je oplost, voor wie het voorstel is en welke beslissing je daarvan nodig hebt, je echte beperkingen (teamgrootte, ruwe tijdlijn, budgetbereik), en de instructie om het concept te structureren als probleemstelling, voorgestelde aanpak, scope, tijdlijn en succesmetingen. Plak achtergrondmateriaal, eerdere voorstellen of notities die je al hebt, en vraag Claude alles te markeren dat te vaag is om een concreet plan van te maken.
Gepubliceerd
Gratis les · geen account nodigMaak kennis met ClaudeWaarom Claude?6 minStart de gratis lesBelangrijkste punten
- Zeg voor wie het voorstel is en welke beslissing je nodig hebt dat ze nemen. Een voorstel waarmee je eigen team plant, leest anders dan een dat een leidinggevende om budgetgoedkeuring vraagt.
- Geef Claude je echte beperkingen: teamgrootte, ruwe tijdlijn, budgetbereik. Een plan gebouwd op verzonnen beperkingen moet herschreven worden zodra iemand met de echte cijfers het leest.
- Vraag specifiek om succesmetingen, niet alleen een beschrijving van het werk. Een voorstel dat niet zegt hoe je weet dat het werkte, is moeilijker goed te keuren en moeilijker later op te volgen.
- Plak achtergrondmateriaal dat je al hebt: eerdere voorstellen, vergadernotities, een ruwe opzet. Claude organiseert en verscherpt wat je geeft; het kan de context achter je specifieke project niet verzinnen.
- Lees de scope-sectie extra aandachtig voordat je verstuurt. Een scope die vager of breder is dan je werkelijke bedoeling is de meest voorkomende reden waarom een voorstel later problemen veroorzaakt.
Kopiëren en plakken
Prompts die je vandaag kunt gebruiken
Een eerste volledig concept uit een ruw idee
Ik wil [beschrijf je projectidee in een of twee zinnen] voorstellen. Dit is voor [voor wie het voorstel is en welke beslissing je daarvan nodig hebt]. Dit heb ik daadwerkelijk tot mijn beschikking: team van [grootte], tijdlijn van ongeveer [periode], budget rond [bereik, of 'nog niet vastgesteld']. Schrijf een conceptvoorstel met een probleemstelling, voorgestelde aanpak, scope (inclusief wat expliciet buiten scope valt), een ruwe tijdlijn en succesmetingen. Markeer alles wat je moest raden omdat ik je niet genoeg detail gaf.
Eerlijk zijn over wat je nog niet weet, zoals budget, levert een nuttiger concept op dan een getal verzinnen om het gat te vullen.
Een rommelige brainstorm omzetten in een probleemstelling
Dit zijn mijn ruwe, ongeorganiseerde notities over een probleem dat ik wil oplossen: [plak je notities]. Zet dit om in een strakke probleemstelling van twee tot drie zinnen die uitlegt waarom dit ertoe doet en wie erdoor wordt getroffen, zonder nog de oplossing te beschrijven. Ik wil dat het probleem duidelijk is afgebakend voordat ik de oplossing voorstel.
Houd de probleemstelling gescheiden van de oplossing; een voorstel dat meteen naar de oplossing springt verliest vaak de lezer die nog niet overtuigd is dat er een probleem is dat het oplossen waard is.
Scope definiëren, inclusief wat erbuiten valt
Dit is mijn voorgestelde project: [beschrijf het]. Schrijf een scope-sectie die duidelijk stelt wat dit project wel en niet zal omvatten, met minstens drie specifieke zaken die expliciet buiten scope vallen. Ik wil voorkomen dat het voorstel breder wordt opgevat dan ik bedoel.
Een expliciete lijst van wat buiten scope valt, is vaak het deel van een voorstel dat later de meeste verwarring voorkomt.
Een voorstel stresstesten voordat je het verstuurt
Lees dit conceptvoorstel alsof je de stakeholder bent die beslist of het wordt goedgekeurd: [plak je concept]. Welke vragen zou je hebben voordat je dit goedkeurt? Waar lijken de tijdlijn, scope of succesmeting onrealistisch of onduidelijk? Wees specifiek over wat ontbreekt, niet alleen over wat fout is.
Dit werkt het beste net voordat je het voorstel verstuurt, als laatste check in plaats van een vroege conceptstap.
De toon van een voorstel aanpassen voor een ander publiek
Dit is een projectvoorstel dat ik voor mijn eigen team schreef: [plak je concept]. Herschrijf het voor een directiepubliek dat het budget moet goedkeuren: begin met de business case en de kosten, houd technisch detail kort, en verplaats implementatiedetails naar een appendixsectie aan het einde.
Hetzelfde project heeft vaak twee verschillende versies nodig, afhankelijk van wie leest en wat die persoon moet beslissen.
De Structuur
De vijf delen die een voorstelprompt nodig heeft
Deze vijf elementen veranderen een vaag idee in iets waarop een stakeholder daadwerkelijk kan handelen.
Een probleemstelling, vóór de oplossing
Benoem het probleem en waarom het ertoe doet voordat je de oplossing beschrijft. Een lezer die nog niet overtuigd is dat er een probleem is, neemt een voorgestelde oplossing ervoor niet serieus.
Scope, inclusief wat er expliciet buiten valt
Zeg wat het project zal doen en, even belangrijk, wat niet. Een voorstel zonder duidelijke scope groeit in ieders hoofd tot wat zij aannamen dat het betekende.
Echte beperkingen, geen verzonnen
Geef Claude je echte teamgrootte, ruwe tijdlijn en budgetbereik, ook als een deel daarvan nog onzeker is. Een plan gebouwd op verzonnen cijfers moet opnieuw gemaakt worden zodra de echte opduiken.
Succesmetingen, duidelijk gesteld
Zeg hoe je weet dat het project werkte. Een voorstel zonder succesmeting is moeilijker goed te keuren en, als het toch wordt goedgekeurd, moeilijker zes maanden later op te volgen.
Ken Je Lezer
Hetzelfde project heeft een ander voorstel nodig voor een ander publiek
Een voorstel geschreven zodat je eigen team kan plannen en een voorstel geschreven om budgetgoedkeuring van een leidinggevende te krijgen, doen verschillende dingen, ook als ze hetzelfde project beschrijven. De teamversie kan diep op implementatiedetails ingaan omdat de lezer daar al om geeft. De directieversie moet beginnen met de business case en de kosten, omdat dat de echte beslissing is die die lezer moet nemen, en onnodig detail vertraagt alleen de beslissing die je vraagt.
Zeg Claude expliciet wie leest en welke beslissing je van die persoon nodig hebt. "Dit is voor mijn team om het volgende kwartaal te plannen" en "dit moet budgetgoedkeuring krijgen van een VP die de technische details niet kent" sturen Claude naar twee verschillende concepten, zelfs voor hetzelfde project, en het publiek van tevoren benoemen bespaart je het schrijven van een versie om er later achter te komen dat die verkeerd is voor de echte lezer.
Als je echt beide versies nodig hebt, is het vaak sneller om eerst de gedetailleerde teamversie te schrijven en Claude dan te vragen die voor het directiepubliek aan te passen, in plaats van beide vanaf nul te schrijven. De onderliggende feiten veranderen niet; alleen wat benadrukt wordt en wat naar een appendix verhuist.
Veelgemaakte Fouten
Wat een voorstel laat vastlopen in plaats van goedgekeurd te worden
Dit zijn de gaten die een redelijk idee veranderen in een voorstel dat onbeantwoord blijft liggen.
Een scope die breder is dan je werkelijk bedoelt
Als je niet stelt wat buiten scope valt, vullen lezers het gat met hun eigen aannames, die vaak groter zijn dan wat je wilde voorstellen. Zeg expliciet wat dit project niet zal omvatten.
Geen vastgestelde beslissing voor de lezer
Een voorstel dat niet zegt waar je eigenlijk om vraagt, goedkeuring, budget, personeel, groen licht om te starten, laat de lezer onzeker over welke respons je van hem nodig hebt.
Verzonnen cijfers in plaats van echte beperkingen
Een tijdlijn of budget dat Claude raadde omdat je er geen gaf, klinkt zeker terwijl het fictief is, en iemand met de echte cijfers merkt dat het voorstel niet overeenkomt met de werkelijkheid.
Geen manier om later te weten of het werkte
Een voorstel zonder succesmetingen is moeilijk met vertrouwen goed te keuren, en als het toch wordt goedgekeurd, is er geen afgesproken manier om zes maanden later te checken of het project leverde.
Gebruik Wat Je Al Hebt
Plak je achtergrondmateriaal erin in plaats van vanaf nul te beginnen
Als je een eerder voorstel hebt voor iets vergelijkbaars, ruwe vergadernotities over het probleem, of zelfs een half afgewerkte opzet, plak die erin in plaats van het project vanuit je geheugen helemaal opnieuw te beschrijven. Claude kan materiaal dat je al hebt veel betrouwbaarder organiseren en verscherpen dan dat het de specifieke context, geschiedenis en beperkingen van je echte project kan verzinnen uit een beschrijving van één zin.
Dit telt vooral voor de probleemstelling. Als het probleem naar voren kwam in een vergadering, in een klacht van een klant, of in een eerdere mislukte poging tot iets vergelijkbaars, hoort die context in de prompt. Een probleemstelling die alleen is opgebouwd uit je huidige samenvatting van het probleem verliest vaak het specifieke detail dat het probleem echt en het oplossen waard maakte.
Datzelfde geldt voor beperkingen. Als je organisatie al een standaard voorstelsjabloon heeft, een typisch budgetbereik voor dit type project, of een gebruikelijke tijdlijnconventie, geef dat direct aan Claude in plaats van het terug te laten vallen op een generieke structuur. Een voorstel dat al past bij hoe je organisatie dit type document verwacht te zien, wordt serieuzer gelezen dan een dat aanvoelt als een sjabloon van elders.
Het is de moeite waard om een lopende map bij te houden met voorstellen die bij jouw organisatie zijn goedgekeurd, ook informeel, en er een succesvol voorstel naast je eigen concept te plakken wanneer dat kan. Claude kan het patroon herkennen van wat meestal aanslaat, of dat nu een bepaald niveau van formaliteit is, een voorkeur voor korte in plaats van lange alinea's, of de gewoonte om te beginnen met risicobeperking, en datzelfde patroon toepassen op je huidige concept in plaats van terug te vallen op een generieke structuur die niet past bij wat bij jou op het werk echt werkt.
Voordat Je Het Verstuurt
Wat te checken voordat het voorstel bij de lezer komt
Lees de scope-sectie eerst en vraag je af of die precies beschrijft wat je van plan bent te doen, niet meer en niet minder. Dit is de sectie die later het meest waarschijnlijk problemen veroorzaakt als ze vager of breder is dan je werkelijke bedoeling, omdat ze het punt wordt waarnaar iedereen terugverwijst zodra het project loopt.
Controleer elk getal tegen de realiteit: de tijdlijn, de teamgrootte, het budget. Een plan dat zelfverzekerd klinkt maar gebouwd is op een geraden getal is slechter dan een eerlijk "tijdlijn nog niet definitief", omdat het eerste wordt behandeld als een toezegging zodra iemand het leest.
De structuur hier geeft je snel een sterk concept; het oordeel over wat je organisatie en je lezer echt nodig hebben voor dit specifieke voorstel blijft van jou voordat het de deur uitgaat.
Een duidelijk voorstel wordt gelezen. Een vaag voorstel wordt genegeerd.
De structuur is herbruikbaar voor elk voorstel na dit. De gratis lessen van Nightschool AI behandelen echte werkschrijftaken met Claude, inclusief de afwegingen rond scope en publiek.
Veelgestelde vragen
Wat is het belangrijkste om Claude te vertellen voordat het een voorstel opstelt?
Voor wie het voorstel is en welke beslissing je nodig hebt dat ze nemen. Een voorstel waarmee je eigen team plant en een die een leidinggevende om budgetgoedkeuring vraagt, hebben verschillende framing nodig, ook voor hetzelfde project.
Moet ik Claude een budgetcijfer geven als ik er nog geen heb?
Nee. Zeg dat het budget nog niet definitief is in plaats van Claude een cijfer te laten raden. Een verzonnen getal dat zelfverzekerd klinkt wordt behandeld als een toezegging zodra iemand met de echte cijfers het ziet.
Waarom heeft het voorstel een expliciete sectie nodig over wat buiten scope valt?
Zonder die sectie vullen lezers het gat met hun eigen aannames over wat het project omvat, die vaak breder zijn dan je werkelijke bedoeling. Expliciet stellen wat is uitgesloten voorkomt die drift.
Hoe schrijf ik een voorstel dat werkt voor zowel mijn team als een leidinggevende?
Schrijf eerst de gedetailleerde versie voor je team, vraag Claude die daarna aan te passen voor de directielezer: begin met de business case en de kosten, beperk technisch detail, en verplaats implementatiespecifieke zaken naar een appendix.
Kan ik notities van een eerder voorstel of vergadering gebruiken in plaats van vanaf nul te beginnen?
Ja, en dat zou je moeten doen. Plak achtergrondmateriaal dat je al hebt. Claude organiseert en verscherpt echt materiaal veel beter dan het de specifieke context van je project vanuit het niets kan verzinnen.
Waarom heeft het voorstel succesmetingen nodig?
Zonder een gestelde manier om succes te meten is het voorstel moeilijker met vertrouwen goed te keuren, en is er geen afgesproken manier om later te checken of het project echt leverde wat het beloofde.
Hoe moet ik een concept checken voordat ik het naar een stakeholder stuur?
Vraag Claude het te lezen zoals de stakeholder dat zou doen en de vragen op te sommen die ze zouden hebben voordat ze het goedkeuren. Controleer daarna apart elk getal in het concept tegen je echte beperkingen voordat je het verstuurt.
Wat als mijn organisatie al een standaard voorstelsjabloon heeft?
Geef dat direct aan Claude in plaats van het concept terug te laten vallen op een generieke structuur. Een voorstel dat al past bij het verwachte format van je organisatie wordt serieuzer gelezen dan een dat dat niet doet.
Een goedgekeurd voorstel begint met echte beperkingen
De structuur is elke keer herbruikbaar. Het eerlijke cijfers geven in plaats van gissingen is het deel dat het waard is om goed te doen.