You sat down to write your organisational baseline. What came out sounded like a brochure. And now you are wondering why evaluators are not convinced.
This post is based on Lesson 1.2 — Organisational Baseline — from Module 1, Framing the Needs Analysis, in the EU KA2 Needs Analysis course. In this lesson, we look at why the organisational baseline is one of the most misunderstood documents in any partnership application — and what it actually takes to write one that holds up under scrutiny.
For more information please check Needs Analysis resources. You can also follow the ongoing work being done in this space by visiting AI Agent Node on LinkedIn.
What an Organisational-Baseline Actually Is
The organisational baseline is a factual description of your organisation’s current state. It covers what you can do, what you cannot do, what resources you have, and what you are still missing. It is grounded entirely in what is true today — not what you plan to achieve, and not what you believe you are capable of becoming.
Think of it as a photograph, not a vision board. A photograph captures what is there right now — with all its detail and imperfection. A vision board shows what you want to become. However, they serve entirely different purposes. Confusing one for the other creates serious problems in a project application.
Furthermore, the baseline is not a profile or a biography. It is not the place to list your history, your founding principles, or your proudest achievements. Those things belong elsewhere. The baseline has one function — to establish where you are right now, in relation to the challenge the project is addressing.
The moment you write “we are a leading provider of…” or “our innovative approach has transformed…”, you have crossed from baseline into promotion. That shift is subtle. Yet evaluators notice it immediately. Phrases like “we aim to” or “we intend to” have no place in a baseline either. Those belong in the objectives section. The baseline describes what already exists — not what you hope to build.
Why Your Organisational Baseline Is Failing Right Now
Most organisations have a default mode built on positive communication. Annual reports, website copy, funding profiles — all are designed to present the organisation in the best possible light. That habit is deeply ingrained. Consequently, when people sit down to write a baseline, they reach for the same language without realising it.
The result reads like a press release. It sounds impressive — yet it says very little about where the organisation actually is. It raises more questions than it answers. Moreover, a weak baseline does not just hurt the application. It distorts the internal picture too. Teams begin projects without an accurate understanding of their own starting point. They cannot measure change, cannot identify what genuinely needs to improve, and cannot make a credible case that the project delivered anything real.
Research across European partnership programmes consistently shows that proposals with vague or aspirational baselines score lower on relevance and context criteria. Evaluators frequently cite the absence of concrete, evidence-based organisational data as a reason for marking down application quality. The problem is real, it is measurable — and it is fixable.
Another common failure is blending current reality with future ambition. The excitement of what could be achieved bleeds into the description of what currently exists. That mixing is a credibility risk. If your baseline already sounds like the outcomes you are promising, the project has nothing left to achieve — and evaluators will notice immediately.
Perhaps the most damaging habit is hiding capacity gaps. Organisations worry that naming gaps will make them look incompetent. In fact, the opposite is true. Evaluators expect gaps — that is exactly why the project is needed. When capacity gaps are absent from a baseline, the entire needs argument collapses. Naming them clearly is not an admission of failure — it is the foundation of a credible case.
How to Write an Honest Organisational Baseline
Start with what you can prove. Every claim in your organisational baseline should be traceable to evidence — internal data such as staff numbers, budget figures, or project history, or external sources such as published reports and stakeholder feedback. If you cannot point to it, do not include it.
Use concrete, specific language. Instead of “we work with many young people”, write “we work directly with approximately 240 young people per year across three community sites.” Instead of “we have limited digital capacity”, write “none of our staff currently hold a recognised qualification in digital facilitation, and our existing tools do not support remote collaboration.” Specificity forces honesty. It also makes the gap feel real — and that matters enormously when you are building a case for why the project is needed.
Write the baseline in the present tense and the past tense only. Future tense belongs in objectives — not baselines. That grammatical discipline is simple but powerful. It reminds you, as you write, that the baseline is about what is, not what will be. Go back through your draft and look for any sentence that begins with a future-facing phrase. Remove it or move it to the appropriate section.
Additionally, write for a reader who does not know your organisation at all. They have not read your website. They have never heard of you. From your baseline alone, can they understand who you are, what you have, and what you are still missing? If not, the baseline is not specific enough. That standard of clarity is what transforms a baseline from a formality into a genuine asset.
Once you understand what an organisational baseline actually requires — and what it does not — you can write one that is specific, evidence-driven, and honest. It becomes a foundation that supports everything else. The problem statement becomes more credible. The partnership rationale becomes clearer. The case for the project becomes harder to argue against.
Mistakes That Weaken Your Output
Words like “excellent”, “innovative”, “impactful”, and “leading” are evaluative. They tell the reader what the organisation thinks of itself. However, the baseline is the place for self-description — not self-evaluation. Replace every evaluative adjective with a factual statement. Instead of “we have an innovative approach to youth engagement”, write “we use peer-led workshops and participatory design methods in our youth engagement programmes.” The second version is not only more honest — it is also more useful and more interesting to a reader who needs specific, verifiable information.
In a consortium, each partner has a different baseline. A consortium baseline that sounds identical across all partners is a red flag. It signals that no one has done the diagnostic work needed to understand each organisation individually. Therefore, write a genuinely distinct baseline for each partner. The differences between baselines are not problems to smooth over — they are data. They tell the story of why this particular group of organisations needs to work together.
Furthermore, one of the most valuable habits you can build is writing the baseline before you write the problem statement. The baseline is the foundation of the problem statement — not the other way around. If you write the problem statement first, you will be tempted to reverse-engineer a baseline that supports the argument. Write the baseline first. Then build everything else on top of it. The result will be far more coherent, and far harder to challenge.
If you want to put this into practice alongside others working on the same challenges, there is a community where that work happens — with frameworks, peer review, and expert guidance at every stage. You do not have to figure this out on your own.
Conclusion
As conclusion, building a strong organisational baseline is not complicated — but it requires a discipline that most organisations have to learn deliberately. It means choosing concrete language over promotional language, present reality over future ambition, and evidence over aspiration. It means being willing to name what is missing, not just what exists. When you get it right, it does not just strengthen one section of your application — it strengthens the whole thing. Join our Training Waiting List [Pending — user to complete].
