You’ve found the tender. You’ve read the Terms of Reference three times. You’ve assembled your team. You have the expertise. And then you submit a proposal that gets scored in the bottom third.
It happens more often than anyone admits. Not because the technical team wasn’t qualified – but because the proposal itself failed to communicate that qualification clearly enough to evaluators who are reading 30 submissions in a week.
After reviewing hundreds of development proposals (and writing more than a few), here are the seven mistakes that consistently sink otherwise strong bids.
1. Answering the wrong question
This is the most common and most costly mistake. The Terms of Reference ask for a specific approach to a specific problem. The proposal describes the firm’s general capabilities and methodology.
Evaluators score responsiveness to the TOR. They’re checking: did this team understand what we’re asking for? Does their approach address our specific context, constraints, and objectives?
The fix: Before writing a single word of methodology, map every requirement in the TOR to a specific section of your proposal. If the TOR mentions « gender-sensitive approach, » your proposal needs a visible, substantive gender section – not a paragraph at the end saying « gender will be mainstreamed. »
2. Generic methodology
« We will employ a participatory mixed-methods approach combining quantitative and qualitative data collection. » This sentence appears in approximately 90% of development proposals. It says nothing.
Evaluators want to see that you understand the specific methodological challenges of this assignment. If you’re evaluating a pastoral resilience program in northern Mauritania, they want to know how you’ll reach mobile populations, how you’ll deal with seasonal access constraints, and what specific data collection tools you’ll use for illiterate respondents.
The fix: Write your methodology as if you’re explaining to a skeptical colleague exactly how you’d execute the work. Include specific tools, sampling strategies, and contingency plans for likely challenges. Name the challenges before the evaluator does.
3. CVs that don’t match the TOR
The TOR says « Team Leader with 10 years of experience in climate adaptation in the Sahel. » Your proposed Team Leader has 15 years in environmental consulting globally, with two projects in West Africa.
On paper, they’re experienced. But the evaluator is scoring against specific criteria. « Climate adaptation in the Sahel » is the requirement. « Environmental consulting globally » doesn’t hit it.
The fix: Tailor every CV to the specific TOR. Highlight the experiences that directly match what’s being asked for. Move irrelevant (but impressive) experience to the bottom or remove it entirely. The evaluator isn’t reading your full career – they’re scanning for keyword matches with their scoring grid.
4. Ignoring the evaluation criteria
Most TORs include a scoring matrix. Technical approach: 40 points. Team qualifications: 30 points. Relevant experience: 20 points. Work plan: 10 points.
Too many proposals allocate space evenly across all sections. If team qualifications are worth 30% of the score, they should get roughly 30% of your attention and page count.
The fix: Structure your proposal to mirror the evaluation criteria. Allocate space proportionally to points. If the work plan is only worth 10%, a detailed two-page work plan is sufficient. But if the methodology is worth 40%, that section needs to be thorough, specific, and compelling.
5. No evidence of local knowledge
International firms lose points here constantly. The proposal reads like it could apply to any country in Africa. There’s no mention of specific local institutions, ongoing programs, policy frameworks, or implementation challenges unique to the project area.
Evaluators – especially national evaluators – notice immediately when a proposal lacks local grounding.
The fix: Research the specific context. Reference the relevant national strategy or policy framework. Mention specific institutions you’ll collaborate with (and why). Show that you’ve done your homework on the local landscape. This is where a platform like ICOpedia can make a real difference – having quick access to existing project data and country-specific development intelligence gives you the contextual depth that generic proposals lack.
6. Poor writing quality
This sounds obvious, but it’s pervasive. Proposals written by committee often read that way – inconsistent tone, varying levels of detail, repetition across sections, and formatting that looks like three different Word templates merged into one.
Evaluators reading 30 proposals notice quality. A well-written, clearly structured proposal creates a halo effect: it signals competence, attention to detail, and professionalism.
The fix: One person should do the final edit of the entire document. Check for consistency in formatting, terminology, and voice. Use clear headings. Keep paragraphs short. Cut jargon that doesn’t add meaning. And proofread – typos in a proposal signal carelessness.
7. Submitting late or incomplete
This should never happen, but it does – more often than firms want to acknowledge. Missing annexes. Wrong file format. Exceeding the page limit. Submitting after the deadline by even one minute.
Most procurement systems are unforgiving. A late submission is automatically disqualified. A missing annex can drop your score below the technical threshold.
The fix: Create a submission checklist from the TOR’s requirements on day one. Assign someone (not the lead author) to verify completeness 48 hours before the deadline. Build in buffer time for upload issues – procurement portals crash more often than they should.
The meta-lesson
All seven mistakes share a common root: insufficient preparation time. Teams that start writing the week before submission inevitably cut corners on research, context analysis, and quality control.
The fix isn’t working harder in the last week. It’s knowing about the tender earlier, having faster access to background information, and building a library of reusable components that can be adapted to each opportunity.
This is why tender visibility and development intelligence matter so much. The best proposal isn’t written by the smartest team – it’s written by the team that had the most time to prepare.
