The mistakes that ruin the software part of a funding application

The vague offer is the champion of rejections: with no modules, no deliverables and no values per component, the evaluator can check neither the reasonableness of the price nor the link to the project's objectives. A close relative: the budget that does not speak the guide's language — home-made headings instead of the official cost categories, approximate classifications, totals that do not reconcile between annexes.

Then come unjustifiable prices, in both directions. Inflated values attract justification requests and cuts; artificially low ones sometimes pass evaluation but guarantee an unbuildable project — nobody delivers a working ERP at template prices, and that gets discovered during implementation, when it is most expensive.

The unrealistic deadline is a delayed-action mine: at submission nobody challenges it, but the financing contract turns it into an obligation. When it becomes obvious that delivery on time is impossible, every remaining option is bad — forced acceptances, addenda signed under pressure, or losing eligible costs.

The same category holds decorative promises in the specifications: features added for effect that nobody ever estimated seriously. At handover the committee compares the application against the file, and every unhonoured promise blocks the acceptance report. Our rule is simple: nothing goes into the file unless we already know who builds it, how, and in how long.

Before submitting, put the software component through a four-question test: is it clear exactly what is being bought? does every sum sit under the correct category from the guide? can any price be argued? would the deadline be accepted by a developer who actually has to meet it? If any answer is “not sure”, the file has a problem that is solvable today and expensive tomorrow.

The verdict such a review produces is technical, not funding advice — but most clarification requests raised at evaluation come from exactly that technical area.