From failing to define technical uncertainty to skipping the commercialisation plan, the mistakes evaluation boards see most often.
The Ufuktek scientific advisory board evaluates an average of 14 project applications every month. Although some applications are valuable as ideas, they are turned down or ask for further information because of file quality. Here are the seven mistakes we see most often, and their solutions.
1. Technical uncertainty not defined
The distinguishing feature of R&D is that the result is not known in advance. Saying 'we will develop a new application' in the file is not enough; it must explain which technical problem has not been solved and how it will be solved by experiment.
2. Novelty claim without evidence
The phrase 'a world first' does not convince an evaluation board without a literature and competitor survey. At least three rival solutions should be presented in a comparison table.
3. Vague work packages
The output, duration, owner and success criterion of each work package should be written down, and dependencies between packages shown.
4. Budget inconsistent with the work plan
Staff numbers, equipment and service purchase items should match the work packages. The share of R&D staff pay in the budget should be reasonable.
5. Team competences not described
Who takes which role in the project, and that person's relevant experience, should be shown in short CVs. For missing expertise, an academic adviser or outsourcing plan should also be written.
6. Incomplete commercialisation plan
If target market size, first customer profile, pricing approach and sales channel are unclear, the project is judged 'scientifically interesting but commercially uncertain'.
7. Risks ignored
Technical, market and team risks and mitigation plans should be written clearly. A file that does not describe risks looks inexperienced.
Before applying, you can show your file to our specialists through our free application consulting.
What does a good file look like?
Strong files are short, clear and evidence-based. On the first page the problem the project solves, the inadequacy of existing solutions and the proposed approach are summarised in three paragraphs; the file then moves on to technical details, work packages and the commercialisation plan. Figures and tables support the text, and bullet points are preferred to long paragraphs. Having someone unrelated to the project read your file before sending it is the best way to test clarity.
Evaluation scoring
Our board scores projects out of 100: innovation 30, technical feasibility 25, team 20 and commercialisation 25 points. Projects scoring 70 or above are accepted; projects between 55 and 69 are given extra time for missing information.
Conclusion
A strong project file shows not only a good idea but how that idea will be tested, with whom it will be carried out and how it will turn into commercial value. Avoiding the seven mistakes above markedly raises your chance of success in both technopark applications and grant programmes.