Let’s celebrate Halloween by talking about some of the most common mistakes that can turn our projects into “monsters.”
European projects: are the “monsters” among us?
It is difficult to turn an idea into a successful and feasible project. That’s why we share tools and tips in the section of the Guide devoted to the design business, and have recently published a series of video guidance pills (you can find them in the Guide and on Youtube).
Sometimes, the problems come from outside: complex calls with many requirements, little time, tight deadlines. Other times, or additionally, the problems lie in the design: superficial context analysis, too general formulation of objectives, inadequate time or financial planning.
Ineffective planning can create real “monsters,” and that is what we want to talk to you about in these Halloween days. In addition to bringing examples, we will propose some keywords and tips for avoiding “monstrosities” and developing a project with a good chance of getting funding, and achieving the set goals.
This is the second article we are publishing for our series on design errors (the first, on organizational capacity, can be found here). We will continue it in the coming months.
The zombie: the design idea resurfaced from the past and out of date
Key word: topicality.
Let’s start with a common mistake: who hasn’t happened, while writing a project, to pull ideas from the past out of the drawer? Activities that seemed “dead and buried” and instead are resurrected and submitted for a new call?
Taking cues from past projects has its upsides: it saves time in planning and writing the project. If done strategically, it allows you to adapt ideas that worked to new contexts, or to improve those that did not work. It is normal and useful to have ideas in the drawer, or to “freeze” them while waiting for the time to be ripe or for there to be a suitable call for proposals.
But beware of the zombie effect: the needs we want to address with our project may have changed from the past and the activities may no longer be appropriate; or simply, the idea may not be suitable for the new context. In this chapter you can find some hints on how to conduct a context analysis, such as stakeholder mapping and needs analysis, while avoiding the “zombie effect.”
If the project that we had submitted with those ideas and activities had not received funding, let us ask ourselves why this happened. Let us reread the evaluations we had received from the funding agency, and reflect on the validity of that idea and activity in the here and now. Beware then of the copy-and-paste effect and the risk of uncritically repeating mistakes that prevented our previous project from getting funded, or from working well.
Let’s remember that although it is not necessary to invent the wheel every time, planning is also an opportunity to stimulate creative solutions: “fishing” too much from the past could have a limiting effect on our organization’s ability to innovate.
Our advice? There is no need to “exhume” but to “regenerate”: starting from the context, analyze the project by discarding the outdated parts and keeping the elements that are still relevant to today’s needs and integrating the new elements. In this way, the legacy of a past project will be enhanced and given new life.
The replicant: the project proposal submitted indiscriminately on multiple calls for proposals
Key word: authenticity.
In an approach somewhat akin to the zombie effect, it sometimes happens that the same project ideas are used indiscriminately on multiple calls for proposals, with the intention of maximizing (at least theoretically) one’s chances of obtaining funding.
This mode makes it possible to optimize the design effort, but each European call for proposals is a world of its own: copying a project (or a part of it) without the necessary adaptations carries the risk of a lack of adherence to the specific requirements, themes and approaches of the call, drastically reducing the chances of getting a good evaluation and seeing one’s project funded.
In some cases, calls for proposals include a clause in the regulations that disqualifies projects found to be already submitted or funded by other programs. Cross-checking is a common practice, and there is a risk that one’s project will be disqualified.
But risks also exist if our project is funded on more than one call: if it is the same project, there may be a risk of incurring “double funding” (which we have also discussed here), that is, reporting the same costs on more than one funding source. This is a practice that can lead to revocation of funding, sanctions or, in the most serious cases, legal action.
All of this can lead to reputational damage to the organization’s reputation with funding agencies, a much more serious damage than not seeing a single project funded.I
OUR ADVICE. Adapt, don’t copy: use the original proposal as a starting point, but adapt the design so that it is in line with the objectives, evaluation criteria, and specific language of each call.
Frankenstein: the assemblage of inconsistent ideas or components of previous projects
Key word: consistency.
Another typical design monstrosity is the “Frankenstein effect,” which occurs when we create a project by joining parts of other projects more or less indiscriminately, sacrificing internal and external coherence. In this case the benefits are far outweighed by the risks because, while it is true that we can save time and include activities that we have already tried, the validity of the project can be severely compromised by the lack of consistency. This, in addition to greatly reducing the possibility of funding, also leads to serious problems during implementation, which can result in project failure.
The various components (activities, methods, objectives, outcomes) are developed within projects with a consistent purpose, aim, and design: mixing them without care carries a strong risk that they will not integrate coherently and may even conflict with each other. Maybe we save time in the design phase, but by reducing the coherence of the project we greatly undermine its value. And even in the event that the project is funded, we risk wasting energy in the implementation phase, trying to force the fit of incompatible elements with each other.
Inconsistency can also occur at the level of objectives, which may not be clear: the project is a system in which each element contributes, on different levels, to a common vision and rationale, which are needed to communicate the project to the outside world effectively.
Our advice? Do not proceed “from the parts to the whole,” but “from the whole to the parts”: clearly define the larger vision and goals of the project. Filter out parts from other projects, asking yourself if that part is consistent with the internal (goals and activities) and external (results and vision) vision of the project. You can help with tools such as the Logical Framework to check the causal chain between its components.
The blob fish: the project difficult to replicate and adapt to other contexts
Key word: adaptability.
Let us imagine that we have developed a project perfectly “tailored” for a call for proposals. Our project has a much better chance of being funded and effective than other project proposals that may lack specificity.
But if the focus of the project is too narrow, it can be very difficult to replicate the experience and adapt it to other contexts, or to unforeseen events. Our project is in danger of coming to the sad end of the blobfish: an animal that lives in the deep sea. In its natural environment it is at ease and looks perfectly respectable, but when brought to the surface it changes completely due to decreased water pressure, taking on a flaccid, gelatinous appearance.
Each project, even if unique, must have a certain degree of adaptability, sustainability and replicability: both for the organization, which wants to grow its business with the projects; and for the funding body, which wants to use its resources effectively, focusing on projects that can “live on” beyond the funding period, and eventually adapt to respond to new challenges. Beware also of the risk of “premature aging”: a project that is too specific risks being less able to adapt to changes in context over time.
Our advice? Use a modular approach: develop a project in which the basic elements, particularly the activities, are designed as self-contained modules, with elements that can be standardized and exported to other contexts, focusing not only on content but also on the use of replicable methods.
The mummy: the rigid design structure with little room to maneuver
Key word: flexibility.
A project is a set of processes and activities dependent on three interconnected variables (the so-called triple constraint): scope of action, cost, and available time. Changing one of these variables makes it necessary to adjust the others accordingly. For example, increasing the number of recipients, which affects the scope, may lead to a lengthening of project time and/or require an increase in resources. Therefore, even at the design stage, it is essential to maintain flexibility.
Some degree of accuracy is certainly helpful: accurate and precise cost estimates in the budget help to better manage the project and increase the likelihood that costs during implementation will be on track. Many risks can be avoided through a crystal-clear division of roles, and straightforward execution of activities keeps the focus on goals and results.
But if our project is inelastic, it will also be more difficult to adapt to changes in context, new challenges or new opportunities that arise. Too much control can make the design less dynamic, limiting the ability to adapt and learn. It is normal for some of the solutions envisioned in the design phase not to be effective in the implementation phase: if the approach is only focused on the faithful execution of activities, there is a risk of continuing to pursue something that does not work, hindering the achievement of goals and results, or the emergence of better solutions. The longer a critical issue is maintained, the more costs and difficulties in finding a solution increase. Chasing formal perfection, that is, wanting to implement a project exactly as planned, can lead to not meeting the needs for which the project was designed. This is why monitoring and evaluation activities exist: to break out of rigidity and adopt the changes necessary to ensure the substantial success of the project.
Our advice? Imagine the project not as a cage but as an armature: it must be rigid enough not to disperse but flexible enough to withstand shocks. Develop the activities not as an unbroken chain, but so that they are organized in distinct and autonomous phases, with their own budget and defined time frames, so that a negative event in one activity has the least possible repercussions on the others. Allow for margin in defining time and costs and, if possible, include in the budget an amount to be used for contingencies.
Hand: the design idea that coincides with a single activity or component
Key word: complexity.
It may happen that an organization turns to European calls for proposals to fund a specific activity, for example, to carry out a festival or workshop. But if we don’t want a project that looks like “Hand” from the Addams Family, we will have to resist the temptation to focus exclusively on our immediate needs, and develop a broader project proposal.
A project with only one activity or component may have advantages in terms of management and clarity. But this simplification is almost always accompanied by a limited ability to generate long-term impact, which is instead the main goal of funding agencies. Adaptability, which we discussed above, is greatly at risk in a project that coincides with a single activity.
In an overly elementary, or “one-size-fits-all” project, there are limited learning opportunities and (paradoxically) one may expose oneself more to certain risks. Indeed, although less complexity carries fewer risks, in such a framework it may take only one risk (e.g., event cancellation) to generate a fatal impact on the project.
European calls for proposals reward projects that have a strategic vision and are able to propose solutions to complex problems, an aspect that rarely goes with projects consisting of a single component or even a single activity.
The term “complexity” comes from the Latin verb “to embrace, to squeeze together”: in design, it means to be able to compose a project consisting of multiple functional elements that come together for a common goal. And let us remember that a “complex” design does not mean a “complicated” design.
Our advice? Consider the individual activity as the tip of an iceberg: the core activity can remain the most visible element of the project, but it must be supported by other activities with a broader vision that enhances its impact. For example, propose not only the event, but also the strategy that makes the event necessary to address the identified needs by including, as appropriate, research, analysis, replicability activities. Also consider integrating the event into a project to be built with other partner organizations(here and in the video pill you will find some ideas for creating effective partnerships and here an in-depth discussion of partnership agreements).
From monster to winning project
We have been navigating through the design nightmares, trying to give you insights into some of the approaches that can limit your chances of creating projects that can get funding and, more importantly, create lasting value. A winning and impactful project is always:
- Current, that is, oriented to present needs and challenges
- Authentic, designed on the basis of identified needs and reflection on the call
- Coherent, with internal elements (goals, activities) contributing to a common vision
- Adaptable, so that it can be implemented with a modular approach in other contexts
- Flexible, elastic enough to withstand shocks and incorporate necessary changes
- Complex, that is, designed as a system with a strategic vision and long-term impact
This is not an easy challenge, but by meeting these criteria we can avoid the ” monstereffect.”
What about you, have you ever been confronted with one of these “monsters” in your design experience? Which one is the most difficult to defeat?
