Some methodologies sound flawless yet die in the first implementation meeting.
They do not die because of a lack of ideas. They die because of a lack of practical structure. They lack what makes a document become real work: decisions, sequence, responsibilities, risks, and tests.
In institutions and in cooperation and project-based organisations, a methodology is not a “nice chapter”. It is the mechanism that aligns teams that do not share an office, context, or always have the same priorities. And, if it is well written, it is also your best insurance: it allows you to evaluate fairly, correct with data and be accountable without drama.
In this article, I would like to share, based on my experience, what a methodology should include so that someone else can execute it autonomously.
The most common failure I have seen is this: they describe values and approaches with big words but do not break them down into smaller decisions.
“Participatory approach.” “Inclusive perspective.” “Multi-stakeholder work.” All of that may be true… and, at the same time, useless if it is not specified.
When a methodology remains abstract, it usually causes three very specific problems:
First, each actor interprets it differently. What one person sees as “participation” is seen by another as “consultation” and by yet another as “information”. And when the time comes to act, it becomes clear that they were not talking about the same thing.
Second, evaluation becomes fragile. If there are no criteria, no expected evidence, and no logic of “if we do X, we expect Y,” evaluation becomes opinion. And opinions, in sensitive environments, are debated.
Thirdly, implementation becomes voluntaristic. It depends on the drive of a few people, on the time available, and on “let’s see if we can do it”. This is exhausting and unfair: it penalises those who try to do their job well.
The good news is that this can be corrected with a very clear backbone.
If you want your methodology to be understood, evaluated and implemented, you need an order that does not require reading between the lines.
I tend to think of a methodology as seven blocks that answer seven questions, not as rigid sections, but as a thread that avoids gaps.
Here, it is best to be direct. A useful objective is not “to improve communication”, but something you can observe what changes, in whom, and in what time frame.
Two keys that save problems later:
When this is missing, the project produces a lot… and it is difficult to explain what for.
In institutional methodologies, “audiences” are not the same as “audiences”. It is an operational map of actors.
The question is: who must change something (a practice, a decision, a behaviour) for the objective to happen?
If you leave it generic (“citizens”, “organisations”, “stakeholders”), you lose precision and evaluation. If you make it specific (“municipal technical teams”, “applicant organisations”, “participants with access barriers”), the rest of the text writes itself.
The approach is not a statement of values. It is a rule of prioritisation.
For example: “safety and accessibility first,” “territorial equity first,” “verifiable evidence first,” “participant protection first.”
Why is this important? Because there are always tensions in implementation: deadlines, resources, agendas, languages, and permits. And when there is tension, the team needs a shared decision-making criterion to avoid fighting.
This is where many methodologies become vague. They say, “we will hold workshops” or “consultations will be held,” but they do not establish a minimum sequence.
There is no need to turn the methodology into an exhaustive schedule, but it is necessary to make it clear:
If someone cannot draw the process on paper after reading your description, something is missing.
This block reduces friction the most.
Not through control, but through clarity. In projects between organisations, “who does what” is not guessed. It is written down.
An implementable methodology names those responsible without fear: coordination, execution, validation, and the resolution of blockages. If you don’t do this, it will be resolved on a day-to-day basis… and day-to-day is often uneven.
Risks are not a section “to be fulfilled”. They are a sign of maturity.
Here, it is important to be practical: two or three real risks, not fifteen generic ones.
Typical (and useful) examples in institutional settings: low participation due to access barriers, representation bias, consultation fatigue, impossible expectations, blockages due to validations, changes in the political context, and linguistic limitations.
The important thing is not to list risks. It is to write down what you will do: mitigation plan, early warning, and who manages it.
A methodology without evidence is a promise without memory.
There is no need to obsess over metrics. But you do need to define what evidence will remain: minutes, recorded decisions, published criteria, traceability of changes, participant evaluation, and simple indicators.
This protects the institution and those who participate, making clear what will be done with people’s time and contributions.
International guidelines, such as those of the Organisation for Economic Co-operation and Development (OECD), emphasise two things that fit perfectly here: using contributions as promised and communicating to participants the status of their contributions and the outcome, to “close the cycle” of participation.
That closure is evidence. And it is trust.
This is usually where the difference between a methodology that “looks good” and one that works is most noticeable.
Because ‘inclusion’ and ‘participation’ are not adjectives. They are decisions.
If you say “it will be inclusive,” a sensible person will ask: “inclusive how?” For whom? With what resources? What will you do when inclusion clashes with deadlines?
Here are some examples of how to translate these concepts into decisions, to illustrate the kind of specificity we are looking for.
If the process includes people with barriers (language, time, connectivity, disability, family care), then you need to decide:
This is not “more work”. It is well-planned work. If you do not decide this, inclusion remains nothing more than a phrase.
Here, the key question is: which parts of the process are informative, which are consultative, and which are deliberative?
There is no need to get technical, but there is a need to be honest. There are processes where the institution listens and decides. Others where there is co-design. Others where citizen recommendations are sought.
Participation fails when influence is promised, but no explanation is given for what happened to the input. That is why the OECD stresses the importance of explaining why certain contributions are not used and communicating the result to those who participated.
The methodology must state this from the outset: what will be done with the contributions, who will review them, what criteria will be applied, and how the outcome will be reported.
Instead of “inclusive approach”, write “there will be interpretation when…”, “places will be reserved for…”, “a summary of contributions will be published in X days…”.
That is understandable. That can be evaluated. That can be implemented.
Before finalising a methodology, there is a simple test: could someone else implement it without you as their permanent translator?
To check this, review these questions. If the answer is “more or less”, that’s the point you need to reinforce.
First: Is the objective written in such a way that an outsider can understand it at a glance? Furthermore, is there a clear idea of how it will be measured or what evidence will remain?
Second: are the audiences defined as real actors (with a role and relationship to the problem), or as vague categories?
Third: Do the activities have a minimum sequence and an associated visible result? If there are workshops, what comes out of them? If there is consultation, what is done with the feedback?
Fourth: Are the roles clear? Is it known who coordinates, who executes, who validates, and how obstacles are resolved? In institutional environments, this clarity reduces tensions more than any manual ever could.
Fifth: Are the risks real, and do they have a response? “Risk of low participation” is useless to me if you don’t say what you will do when it happens.
Sixth: Is there a monitoring mechanism? I’m not talking about a cumbersome system. I’m talking about a rhythm: when it is reviewed, what is recorded, and how it is adjusted.
Seventh: if you have written “participation” or “inclusion”, have you translated those words into concrete decisions (formats, criteria, support, deadlines, feedback)?
If this checklist leaves you with doubts, it is not a failure. It is useful information: it points out where the methodology needs grounding.
A quality methodology does not impress. It allows you to work without unnecessary friction and leaves a clear trail for fair evaluation.
If you feel like it, please tell me on LinkedIn which part of writing methodologies you find most difficult: translating values into decisions, defining roles, grounding evidence, or writing about risks without sounding defensive. I look forward to hearing from you.
Institutions keep designing messages for public feeds while their audiences make decisions in WhatsApp groups no institutional algorithm can reach. The problem is not technical. It is a question about how trust works when public visibility disappears and what remains are relationships.
When a deepfake involving your organisation surfaces, the first instinct is to treat it as a technical emergency. But what determines the real damage is not the fake content itself — it is what your organisation does, or fails to do, in the hours that follow. That is a communication decision.
Is your team already using AI without clear rules in place? This practical guide shows how to build an AI editorial policy for communication: what to allow, who reviews it, and how to disclose its use without putting trust at risk.