What project architecture looks like before the acronym, the work packages and the reassuringly confident arrows.
By the time a European project appears in public, most of the argument that created it has already been tidied away. The name is settled, the acronym has survived, the consortium looks intentional, the work packages have numbers and the budget has acquired the reassuring authority of a spreadsheet. Looking at the finished version, it is easy to imagine that the project simply emerged this way.
It did not.
Before a proposal becomes respectable, there is another version of it. There are competing interpretations of the problem, policy documents pointing in slightly different directions, calls that almost fit and calls that become considerably less attractive once somebody reads page 47. There are excellent partners who may not belong in this particular consortium, fashionable technologies searching for a legitimate reason to exist, outputs quietly pretending to be outcomes and impact claims with no visible mechanism connecting them to the activities underneath. There are also diagrams. The diagrams are important. Occasionally their arrows express causality. Occasionally their arrows express hope.
That stage is rarely shown publicly, yet it is where much of the difficult work happens. It is the point at which an interesting idea either begins acquiring an operating logic or remains an interesting idea wearing European funding vocabulary. At REDefine, this is the part of the process we tend to think of as project architecture, and it is also the part of funding work we find most intellectually interesting.
This week, for The Inner Circle of Civic Imagination, we want to open that stage. We are not going to present three finished proposals, because we do not have three finished proposals. That is precisely the point. We have three concepts currently in development, each facing a very different architectural problem. Before we reveal what those projects are, however, it is worth looking at what project architecture actually means, because it begins much earlier than most application forms would have us believe.
Before there are work packages, there are harder questions
Project architecture is not the same thing as proposal writing. Writing matters enormously, of course. A badly written proposal can obscure a strong idea, while a beautifully written proposal can occasionally persuade its authors that an incoherent idea has become coherent simply because the transitions are now excellent. Architecture comes earlier. It asks what must be true for the project to work before anybody starts worrying about whether the objective should begin with “strengthen”, “enhance” or the ever-reliable “foster”.
The first question is deceptively simple: what exactly is supposed to change? “Raise awareness” is not yet an answer. Neither is “increase capacity”, “strengthen cooperation” or that venerable European favourite, “foster synergies”. Those phrases may eventually describe part of a project, but they do not yet tell us what will actually be different. Will an institution make a better decision? Will a professional respond differently? Will a young person understand a democratic process that was previously opaque? Will organisations begin sharing information they currently keep in separate systems? Will a methodology become part of ordinary practice rather than disappearing when the funded activity ends? Until the change becomes reasonably specific, the project has nowhere reliable to go.
The second question is who actually has the capacity or authority to produce that change? European projects routinely contain several kinds of actors who are treated as if they were interchangeable: people who experience the problem, people participating in activities, organisations implementing the project, institutions with formal authority, professionals expected to change their practice and organisations that will eventually have to maintain whatever the project creates. These groups can overlap, but they are not the same. A young person may be the participant but not the decision-maker. A municipality may be essential to implementation but have no authority over national regulation. A civil-society organisation may facilitate a beautiful process while having precisely zero legal competence over the policy outcome being discussed. If a project does not distinguish these roles, it can end up promising change through actors who do not possess the power to produce it.
Then comes the question that tends to make otherwise attractive concepts uncomfortable: why should the activities we are proposing plausibly cause the change we are claiming? Training does not automatically create institutional change. Dialogue does not automatically produce cooperation. A platform does not automatically produce use. A recommendation does not automatically influence policy. A pilot does not become sustainable merely because the word “sustainability” appears somewhere in WP5. Something has to happen between the activity and the outcome, and that “something” is where project logic lives.
This leads to perhaps our favourite architecture question: what depends on what? If one work package maps a problem, who actually needs that map and what will they do differently because it exists? If another produces training, what evidence shaped the curriculum? If a later work package pilots a method, which assumptions are being tested and where did those assumptions come from? If the project eventually produces policy recommendations, what results give those recommendations legitimacy? A work package should not exist simply because “research, training, piloting, dissemination” is a familiar sequence. The architecture should make it difficult to remove one part without changing the logic of another.
European proposals have a longstanding temptation to reward every good idea with its own work package. This is how projects occasionally become small federal states.
Another architecture question concerns what happens after the interesting bit. What happens after the training, the workshop, the recommendation, the pilot, the conference or the international mobility? Who responds? Who maintains the result? Who owns the next step? What does continuation mean in operational rather than poetic terms? Many weak project designs are not particularly weak at the beginning. They become weak at the exact moment when the funded activity hands responsibility back to the world.
And finally there is a question we probably ask more often than people expect: what should we remove? Good funding work is partly generative. It helps organisations imagine methods, partnerships, activities and opportunities that did not previously exist. Good architecture, however, is also subtractive. A fashionable technology may not belong. An impressive partner may not be necessary. A separate work package may be disguising something that should actually be transversal. An output may have no credible user. An attractive idea may solve the wrong problem. Sometimes the most useful contribution to a proposal is simply saying, “No. Not this. Not here.”
With that in mind, let us look at three live problems. Not yet the projects themselves. Just the problems.
Design problem one: when everyone shares the problem but nobody shares the operating system
Imagine several professional and institutional communities dealing with different dimensions of the same risk. They may be concerned with the same territories, infrastructure, populations and sometimes even the same event, yet they do not necessarily work through the same evidence, time horizons, mandates, terminology or decision processes. One community may think in decades while another must make a decision by Thursday afternoon. One may work from projections; another from operational records. One may be responsible for long-term planning; another becomes responsible when something catches fire.
It is extremely easy to create an interdisciplinary project around this kind of problem. Put representatives of the different disciplines in one consortium, give each an area of responsibility, schedule some joint meetings and add the word “integrated” at respectful intervals. On paper, everybody is connected. In practice, an interdisciplinary consortium can still become several excellent organisations doing excellent work beside one another.
The real architectural question is therefore not how to place expertise in the same project. It is how to create dependence between the expertise. What must one professional community provide before another can act? Where does evidence need translation? Where does responsibility need to become explicit? What happens when scientific knowledge reaches an institution with no clear mandate to use it? How does learning from an operational event travel back into long-term planning rather than becoming a report about something unfortunate that happened last summer?
This is a problem of integration, but not integration in the polite sense of “everybody talks to everybody”. It is integration in the much more demanding sense that one part of the system has to become useful to another.
Design problem two: when voice enters the system and disappears
Now imagine a completely different type of project. People are invited to participate. They identify concerns, discuss them, collect evidence and perhaps formulate recommendations. The process looks democratic, and in many respects it is. Then the recommendation leaves the room.
Where does it go? Who actually has responsibility for the issue? Is the decision local, national or European? Does a legitimate participation mechanism exist? Was the proposal considered? Was it rejected? Was it redirected somewhere else? Did an institution agree with part of it? Did anything change? More fundamentally, did anybody tell the participants what happened?
We spend considerable energy creating opportunities for people to speak. We spend less energy making the journey of that speech visible afterwards. The architectural problem here is therefore not simply how to generate more voice. It is how to design the route between voice and consequence.
Consequence does not mean victory. Democracy would become alarmingly straightforward if every consultation ended with a message saying, “Congratulations, your recommendation has been dispatched and will arrive within three to five working days.” A democratic consequence may be agreement, partial adoption, referral to another authority or a reasoned rejection. Sometimes the process reveals that responsibility is fragmented or that no existing mechanism fits the issue very well. But if participation is to become intelligible rather than ceremonial, people need some way of understanding what happened after their contribution entered the system.
That requires architecture too.
Design problem three: when creating value risks extracting it
The third problem begins with something apparently optimistic. Imagine people holding knowledge, skills, practices and networks that are genuinely valuable but poorly recognised by conventional systems of education, employment or entrepreneurship. Some of those capabilities may be deeply connected to family, community, identity or tradition. Now imagine building a project designed to make those assets more visible and more economically useful.
At first, the logic seems obvious. Recognise the skills, strengthen them, build confidence, support entrepreneurship and create opportunities. Then the uncomfortable questions arrive. Who owns the knowledge? Who has the right to commercialise it? When does inspiration become appropriation? How should people be credited? Who benefits financially? What happens when something collectively held becomes individually branded? What requires consent? Can a project designed to create opportunity accidentally reproduce the extraction it claims to challenge?
Suddenly, the architecture question is no longer simply, “How do we create value?” It becomes, “How do we create opportunity without destroying, appropriating or decontextualising the value we began with?” That one change in the question affects governance, training, mentoring, prototyping, impact measurement and the order in which activities should happen. It also changes who must have a voice in deciding what is appropriate in the first place.
Three ideas, three very different architectures
Placed beside one another, these three problems expose something standard proposal templates can hide. The first is fundamentally a problem of integration. The second is a problem of navigation. The third is a problem of transformation without extraction. All three projects may eventually contain familiar ingredients—research, training, participation, digital tools, pilots, dissemination, policy work and events—but those ingredients cannot tell us what the project is.
The architecture has to come first.
If we begin instead with a comfortable sequence of mapping, training, local activities, dissemination and final conference, then squeeze the problem into that structure, we may still produce a perfectly respectable application. We simply may not produce a particularly good project.
This brings us to the moment where the public version normally begins. Once the architecture stabilises, the internal argument starts disappearing. Alternatives vanish. Rejected ideas are removed. Unresolved questions are edited into confidence. The consortium starts looking inevitable, the budget starts looking orderly and the work packages acquire numbers. Eventually, the proposal behaves as though it always knew what it was.
We could stop here and turn these three design problems into hypothetical case studies. But they are not hypothetical. They belong to three proposals currently on REDefine’s working desk. Below the line, we are opening that desk: revealing the projects themselves, looking at the architectures forming around them, showing some of the tempting versions we are deliberately not building and examining what those decisions are doing to methodology, work packages, budgets, impact logic and consortium structure.
If this is the part of European projects you find interesting, there are two ways to go deeper.
Come inside the working room
The version you have just read is the public part of this essay. In The Inner Circle of Civic Imagination, we go considerably further.
We open three real European project concepts currently being developed at REDefine and show the architecture while it is still unfinished: the choices we rejected, the dependencies between work packages, the places where a consortium can look impressive but still fail structurally, the difference between what a project can deliver and what it can merely influence, how budgets expose the real theory of change, how uncertainty can be designed rather than hidden, and the questions we are still trying to resolve ourselves.
Paid subscribers also get the REDefine Project Architecture Stress Test and the full worked examples behind the three design problems introduced above.
Join The Inner Circle of Civic Imagination for our deeper project-design work, tools and behind-the-scenes thinking.
Or bring us into your own project
If you are reading this because your organisation has an EU project idea of its own, we also do this work professionally.
REDefine works with NGOs, universities, municipalities, research teams, training providers, social enterprises, SMEs and international consortia to turn promising ideas into coherent European projects. We can enter at the beginning, when you are still deciding whether a call genuinely fits, or later, when a proposal already exists but the intervention logic, work packages, partner roles, indicators or impact story are not holding together.
Our EU funding and proposal-development work includes call-fit and concept development, intervention logic, work-package and partner-role architecture, full proposal leadership, evaluator-style red-team review, resubmission strategy, impact and sustainability design, and proposal rescue for drafts that have become fragmented or internally inconsistent.
We cannot guarantee funding. No one can. However, we help build applications that are coherent enough to deserve serious consideration — and projects that still make sense after the application has been submitted.
