JISC

Each project must submit a core set of documents to indicate how the project work will be planned and implemented, to report on progress, and to report the final results.

JISC Website project page

As soon as the project has started a JISC Website template should be completed and returned to the programme manager. This information will be used to update the project webpage on the JISC website (which will already have been created at the point of funding).

The JISC website pages describe each JISC Innovation programme with links to pages on each project within the programme. Together the programme and project pages give an overview of what the programme will achieve. These web pages are created in a consistent way using the JISC Content Management System (CMS). 

Once the project plan has been completed and agreed it will also be published on the project web page. Once created, the project manager should inform the programme manager of any changes that should be made, e.g. URL of the project website, names of key project staff.

Project Plan

Each project must have a formal, written project plan to define aims and objectives and explain how they will be achieved, what will be delivered, how the project will be managed, and how success will be measured. It will be supported by detailed plans for work packages, evaluation, quality, dissemination, and sustainability. A project plan template is provided, and the information in project planning gives guidance for preparing the plan.

The level of detail required in the project plan will depend on the project scope and duration. For short studies and consultancies, the ITT may be quite specific about the work to be done, and only minor modifications may be needed to develop the project proposal into a project plan. For short projects (e.g. 6 months) resulting in deliverables like case studies, the programme manager may recommend a ‘light’ project plan covering all the topics listed in the template briefly, or perhaps only some of the topics. The programme manager will advise on the level of detail.

The project plan should be submitted within 1 month of the official project start unless an alternative schedule is set by the programme manager. Any problems with submission timing should be discussed with the programme manager as alternatives may be agreed where appropriate.

The project plan must be sent to the programme manager and is subject to approval by the JISC Executive. After approval, the project plan should be used to guide the project work and updated to meet changing circumstances or before starting a new phase. Once the project plan is approved, any major changes must be agreed with the JISC Executive, e.g. changes to deliverables or the project schedule.

The project plan is supported by 2 sub-templates covering: Work Packages [Work Packages Template] Budget [Budget Template]

The Work Plan and Budget are mandatory and should be submitted as part of the overall Project Plan.

Acceptance criteria for project plans include: Completeness: It covers all the topics listed in the template. It’s not acceptable for a project to omit one or more topics because they are covered by a work package later in the project. Detail: It covers the topics in sufficient detail. Smart objectives: Objectives are specific, measurable, achievable, realistic, and timed. Work packages: The detailed work plan inspires confidence that the project will achieve its aims and objectives. Outputs: Deliverables are listed and their due dates are clearly indicated in the workpackages. Quality: The project has planned how they will achieve and measure the quality of outputs expected by the programme. Consistency: There’s coherence between the sections e.g. the work packages reflect the plans for quality/evaluation, dissemination, and exit/sustainability.

Consortium agreement

If the project involves more than one partner, the partners must sign a consortium agreement and send a copy to the programme manager. The purpose of the agreement is to ensure that the collaboration is successful and delivers what is promised in the letter of grant signed by the lead institution. It should document the roles and responsibilities of the project partners, how the project work will be conducted, and what will happen in the unlikely event that things go wrong. The consortium agreement must be signed at the start of the project and submitted at the same time as the project plan

The length and complexity of a consortium agreement will vary with the project. Further guidance on consortium agreements please read the JISC Consortium Agreement guidelines

As a minimum, the consortium must address: Purpose: Purpose of the consortium Membership: Membership of the consortium Letter of grant: Confirmation that all project partners will adhere to the JISC letter of grant signed by the lead institution Responsibilities: Broad responsibilities of each partner Joining: Circumstances in which a new institution may join the consortium and their status (e.g. associate partner instead of full partner) Leaving: Circumstances in which a partner may leave the consortium, the consequences for that partner (financial or otherwise), and for the other partners Financial arrangements: How project funding will be apportioned among the project partners IPR: Who will own the IPR of outputs created by the project, e.g. the partner who creates it owns it, or all will own jointly Exploitation: How intellectual property may be exploited after the project ends, with due reference to the letter of grant Project assets: When the project ends, who will own assets like hardware and software bought with project funds Disputes: Process for resolving any disputes among the project partners.

Progress reports

You are normally required to provide two progress reports per year, detailing activity during the previous period. Programme managers will advise on the frequency and timing of reporting as short projects (e.g. 6 months) usually require a more frequent reporting schedule. The programme manager may also tailor the progress template to suit the nature of the project and to elicit particular reporting information.

This reporting framework provides the JISC Executive with a consistent and coherent set of data from all projects about activities and progress, the process of implementation, reflections on what has been learned, and revised understandings and expectations about the project. Given the high level of interest in JISC Innovation projects, regular and timely reports are important so that knowledge and results can be shared with the wider community. Progress reporting is also useful for project self-evaluation and reflection among the partners about what is being learned.

The progress report template covers the same topics as the project plan, so you can report progress against your plans and note any changes you envisage. What is reported will depend on the stage in the project lifecycle. Early on, you will report on start-up activities, later on interim results, and towards the end outcomes and results. At all stages, you must report expenditure against budget (using the budget template). You should also report what you are learning, and lessons you would like to pass on to the programme and other projects.

Typically reports are due at the end of January and July, but the programme manager will inform you if the schedule is different. Reporting dates will also be posted on the programme website.

Acceptance criteria for progress reports include: Completeness: It covers all the topics in the template and reports progress against plans Detail: It covers the topics in sufficient detail Accuracy: It accurately reflects the extent and status of the project work and doesn’t gloss over problems and issues On track: Is clearly indicates if the project is on target and on schedule, or what is being done to address issues Inclusive: It takes account of all partners and their work Access to project work: The project website reflects the progress indicated in the report (e.g. project deliverables, examples, and reports are included on or referenced by the website).

Final report

The final report documents what the project has done and achieved. For most projects, it will be a report of publishable quality for the community covering topics like a summary of the work undertaken, objectives, methodology, achievements, findings, outputs and results, outcomes, conclusions, and implications for future work. The final report gives a detailed and considered account of the project’s achievements that will be of interest to stakeholders and peers in the development community. A final report template has been developed as a general guide to the topics that should be covered in final reports. The programme manager will customise it for the programme and indicate what topics to cover.

The nature and scope of the final report will depend on the work undertaken and the intended audience. In the case of consultancies and supporting studies, the ITT will indicate the purpose of the report, target audience (e.g. JISC Executive, other group within JISC, a wider audience), and specific topics to cover. For some projects, the project deliverable(s) will be sufficient to document the project’s findings and achievements, for example where the deliverable is a case study. In these cases, you only need to submit the deliverable(s) along with a summary of the work you have undertaken, this will be used to update the project page on the JISC website. A full final report may not be required, the programme manager will advise.

A draft final report should be submitted at least one month before the end of the project. In the case of long projects (e.g. 3 years), the programme manager may require the draft two months before the end of the project. This will give the programme manager and any advisory board time to read the report, digest it, and send comments or requests for revision back to the project. You should re-submit the final revised version of the final report before the formal project end date. The final report document will be uploaded onto the JISC project webpage to provide further information for interested parties on the achievements of the project.

Acceptance criteria for final reports include: Completeness: It covers all the topics in the template Structure: It’s clearly structured and well organised Style: It’s well written and free of typographical errors Accuracy: It provides a true picture of the work performed Objectivity: It’s objective, separating any opinions from fact, and containing nothing libellous Terminology: Terminology is appropriate for the intended audience Authority: Any conclusions or recommendations are substantiated by the work performed Attribution: The work of others is acknowledged

Project Closure Survey 

The project closure survey is a short, electronic survey style report for the JISC Executive that acts as a ‘sign-off’ on the project work. It’s for internal use within JISC and the results will not be published more widely.

It captures impact information and lessons learned as well signing off the work undertaken, e.g. that all deliverables and reports have been submitted and accepted, exit plans have been implemented, and IPR issues have been dealt with. Projects will also be encouraged to identify new areas where JISC should undertake development work. All information and feedback given in the survey is important so that JISC can improve its current Innovation programmes and develop new ones.

The project closure survey will be issued to projects by the programme manager prior to the end of the project and it should be submitted at the formal end of the project. A final updated budget must also be submitted to the programme manager when the project closure survey is completed.

Submission of core documentation

The programme manager may customise the generic templates for the programme. If so they will circulate the customised template to you, typically one month before the report is due. You should ensure you use the correct template. Instructions or explanatory text is in italics.

All core project documents (with the exception of the Project Closure Survey) should be sent to the programme manager electronically as word files (the budget in excel)

Acceptance process

JISC requirement  Project deliverables and core project documents are subject to approval by the JISC Executive

See acceptance criteria for project deliverables. The programme manager will provide further information.

Due dates

Due dates for project deliverables must be clearly indicated in the work packages that form part of the project plan. The schedule and any changes to this schedule must be agreed with the programme manager.

Deliverables and core project documents must be submitted on time. You receive funding to perform the work agreed, and JISC expects you to deliver on schedule.

Extensions

If you foresee any problem submitting the deliverable/report on the due date, you should contact the programme manager in advance and explain the reasons. The programme manager is likely to be quite supportive about any problems you're having and can offer assistance and advice.

The programme manager will decide if an extension will be granted. An extension is likely to be granted in circumstances beyond the project’s control (e.g. suppliers fail to deliver, hardware failure, illness, etc). The programme manager is less likely to be sympathetic if delays are due to poor management. Excuses like staff are on holiday, are off at conferences, or are simply ‘busy’ are not likely to merit an extension.

Where the programme manager agrees to an extension, the extended due date will be agreed with you. If this is more than one month from the original due date, the programme manager will inform the committee secretary.

Acceptance

The programme manager will decide if the report/deliverable meets the acceptance criteria and will be accepted by JISC. The programme manager will notify you in writing (email) about acceptance within one month of the submission date. If the report is accepted, the programme manager confirms this and provides any constructive feedback.

If the report/deliverable is not accepted, they will explain which criteria have not been met, why, and what further work must be done to get the report/deliverable to an acceptable standard. The programme manager and the project discuss the situation as soon as possible (meeting or phone conference), to ensure the project understands why the output was not acceptable, what the project must do to bring it up to an acceptable standard, and any additional support needed from the programme.

The programme manager and project agree a re-submission date. If this is more than one month from the date the report/deliverable was rejected, the programme manager informs the committee secretary. The programme manager keeps in touch with you to provide support or assistance as required to help the project meet the standard required.

You re-submit the report/deliverable and the acceptance process starts again. If the report/deliverable still doesn’t meet acceptance criteria, the programme manager will meet with you to decide how to proceed. Together you will agree a plan to get the project back on-track and the report/deliverable to an acceptable standard. The programme manager will document the meeting and the agreed plan, and send a copy to the committee secretary.

If the project fails to comply with the plan and/or get the report/deliverable to an acceptable standard, the warning process is invoked.

Warning process

If the project fails to comply with the plan and/or get the report/deliverable to an acceptable standard, the warning process is invoked. The committee secretary sends the project a first warning letter. This letter sets a final due date, indicates any other conditions the project must comply with, and notes that failure to comply will result in suspension of payments. The committee secretary arranges a meeting with the project and programme manager to discuss the warning process, agree what action you will take to comply, and what will happen if you don’t.

If you don't comply with conditions in the first warning letter, then payments are suspended. The committee secretary then sends the project a second warning letter indicating that payments have been stopped and the conditions upon which JISC would be prepared to resume payments.

If you don't comply with the conditions in the second warning letter, then the project is deemed to have failed. The committee secretary will send the project a final warning letter indicating that the project has failed, the amount (or percent) of project funding that must be repaid to JISC, and the procedure by which this will be done.