Loading...
Loading...
EU-funded project site
Publish the project information and public deliverables named in your grant documents. Give partner editors a clear handover and keep control after funding ends.
Three routes
The smallest build that satisfies your programme guide is the right one. I'll tell you which route I think it is after I read your grant agreement and your content.
Your university or research centre already runs a site. The web team will host the project pages, but has no time to build them. I build the pages, the deliverables library and the visibility block. This is the smallest build of the three.
Scoped in writing after the inventory.
The approved project needs its own address. I build the public site and hand over the domain, code, content and accounts.
Scoped in writing after the inventory.
Your research office repeats this work. The first project establishes an approved structure; later projects receive their own inventory and scope.
Scoped in writing after the inventory.
Who does the work
Scope
The process
After the inventory, I send the pages, partner responsibilities, approval points and expected effort in writing.
I list the pages, partners, work packages, deliverables and required links. You mark each document public or confidential, and you name the partner who decides.
Output: A content map, a document list, a written scope your finance and procurement offices can read, and my route recommendation.
I set up the page blocks, the deliverables library, the visibility block and the partner editor accounts. I load the approved text, logos and public documents. I then check accessibility, links, document access and the visibility block against your grant documents.
Output: A complete staging site and an acceptance checklist against the agreed content map.
I publish after your named approver releases the site. I hand over the accounts and the code, train the partner editors, and write the plan for the years after closure.
Output: A live site, an editor guide and a written plan for the years after closure.
Safeguards
A project site carries a deliverable date, a public document library and an owner long after the money stops. Here is what holds each one down.
Questions
Often the proposal creates the duty, not the regulation. If your Annex 1 promises a website, your programme will expect one. Your grant agreement and your programme guide set the wording and the dates, so read those first.
I confirm no delivery date before the inventory. The written scope names the dependencies, approval points and date supplied by your project officer.
Your finance office decides that, not me. I give a written scope that names the work, the outputs and the effort. Your project officer confirms how it is booked.
Each named partner gets editor access and a written guide. Routine updates using existing fields do not need me.
Routine changes use the existing fields. A new page type, workflow or integration receives a separate written scope.
You do. You keep the domain, the code and the accounts. The site needs no server subscription, so the cost after closure stays small. Your programme guide sets how long it must stay up.
By launch you hold the domain, the code, the content and every account. The site runs without me. The handover pack names the hosting and the cost to keep it up. It also names what a new supplier needs on day one.
Your accessibility officer names the applicable standard and owns the statement. The written scope names my tests; an independent audit is separate.
The wording comes from your own grant agreement, not from a template. Programmes word it differently. Send me the text and I put it in the visibility block.
Your project officer confirms where each public deliverable must live. The site lists it or links to the approved repository.
Send the signed grant section or Annex 1, the website deliverable date and the partner list. I return the route and risks in writing.
Send me your deliverable date