Introduction to Project DocumentationPlease do acknowledge the reading of this document by leaving a comment at the end of it (in the comments section), your feedback on this process is greatly appreciated. All JISC projects are required to complete documentation. While we all know the labour involved in documentation, it is important to take the time to fill out the documentation in full. Documentation is there to help spread best practice amongst our community and to help you to effectively plan the work you want to achieve. For the Rapid Innovation Programme we have attempted to scope all documentation so you can directly see the benefits that documentation has for yourself and for the community as a whole. In short, the 'Rapid Innovation' projects are of a different project species, and so we've changed the way documentation works so that it is lightweight and web-worthy. Overall we hope it gets you writing documentation for one another as a community, rather than just to the JISC Executive. Project/Programme tagsIn the original call all projects were asked to give their proposed projects a name that could be used as a tag. This ProjectTag will be used to track all your work. So it is very important to use this tag on all of your tweets, comments, posts and documents in this environment. Additionally there is a Programmetag #vreri which you should use for all your correspondence regarding this programme and its projects. the tag #jiscri can also be used as this refers to all Rapid Innovation projects withing JISC. At the start of this programme we assigned each project their tag which you used in your proposals. This is the tag used in your original bid document and first wiki page. Please contact me as soon as possible in case this is incorrect or you would like to change. Below is a list of documentation you will need to complete so as to fullfil your remit to the VRERI programme. VRERI Project DocumentationThere are three sets of documents you are required to complete during the course of your VRERI project: - Project Planning: Core Project Resources Form, Project Plan and Projected Budget.
- Progress Posts: A minimum of seven required Progress Posts throughout the duration of your project including a Final Progress Post.
- Final Project Sign-Off: Final Spend Budget, Overall VRERI Programme Survey and official Sign-off of Completed Project.
Instructions and templates for these three sets of documentation are detailed below. 1. Project Planning- Core Project Resources Form <- please fill out within first fortnight of the project.
- This form is gathering the key URIs in your project so that JISC can support you as effectively as possible in monitoring your project.
- All of the information of the form is gathered in the CoreSpreadsheet.
- For example by having all the project blog feeds we can aggregate them into a central feed so we can more effectively pass on news and developments as they occur to other JISC projects.
- This form is essential and needs to be filled out as soon as you have your staff, website/blog/wiki, code repository and project post feeds in place.
- Project Plan Template HTML <- please complete within the first month of your project.
- The Project Plan should clearly state the obligation you have to JISC in how you plan to achieve your project outputs. We understand that these plans are likely to change, nevertheless it should be an accurate estimation for how you intend to achieve success.
- The Project Plan should be a re-formatted version of your Project Proposal so that it is comprehensible to people outside of the JISC community. This document will be made available via the JISC web site i.e. the audience for the Project Plan should be broadened (beyond the original Project Proposal) to include anyone from any other worldwide Academic domain who might find it via a Web search. Please keep in mind JISC has a very large readership from the UK, EU, USA, Australia and India which often makes this document the most highly rated by search engines when searching for your project topic.
Please remember all documents you create as part of your project are subject to FOI so best to maintain best practice with regards to transparency and openness throughout your project 2. Progress Posts- So as to make your life easier we are suggesting a series of blog posts be written for the project as it progresses (this is in place of the project final report so should save you time!)
- The posts are intended to disseminate the knowledge of the project in the now, rather than waiting until the end of the project to share your experiences.
- In short, we would like you to write a blog post on the following themes during the course of your project, though you are welcome to find variance in the theme as you see fit. We are not prescriptive here and really want you to write something that people in the community will want to read, i.e. don't write them for JISC alone.
- Please make sure to use the correct tags for each post (including your own project tag) so that our robots can come along and aggregate all posts on various topics into our analytics tools (manyEyes, Google Data, etc). We are hoping this open data approach helps increase the synchronous-ability in which we communicate with one another.
- The posts can be as short or as long as you like so long as you keep your fellow projects and Higher Education community audience in mind.
- You must cover all the topic themes (and use all the tags) below: be that in ten separate posts or in three or four longer posts (though our preference is for early and often where possible).
The following topics make up the required Progress Posts (you can do these posts in the order you see as most pragmatic to your project). MAKE SURE TO USE REQUIRED TAGS! | Progress Post Topic | Description / Example | Required Tags | | (I) "Project Evaluation" aka iterative reflection | Undertake a basic iterative evaluation and analysis process (e.g.SWOT analysis) of your project. Please also refer to use statistics and analysis of take up. The key is to truly knowing thyself or at least your project. Please give extra attention to any sustainability issues related to this project. | required tags = SWOT, projectEvaluation, rapidInnovation, progressPosts, VRERI, JISC, <your own unique project tag>, etc. | | (II) "User participation" aka user cases | What is the core user case(s) you think of when developing the app; Please find and post #1 testimonial/quote of a real end user, #2 testimonial/quote of someone in the management of your institution. How has this story changed as you have engaged with the end user e.g. "we often talk about Sam the part time working student we met while at...". Bonus points for actually talking about real end-users you are working with (note: you are not the end user!) | required tags = userCase, endUser, rapidInnovation, progressPosts, VRERI, JISC, <your own unique project tag>, etc. | | (III) "Day-to-day work" aka tools, tips and trick that make you productive | What software tools or productivity methods do you use and how do you use them? How do they make you more productive and why do you see value in using them? Any and all tools, methodologies or diagrams showing off the way your project is run from an individual or team perspective are welcome. | required tags = methodology, implementation, productivity, progressPosts, rapidInnovation, VRERI, JISC, <your own unique project tag>, etc. | | (IV) "Technical standards" aka stuff you reuse | What technologies, frameworks, standards or anything else that makes your life easier (or harder) in your work. For example: what programming language (or framework, IDE, pattern, etc) do you use and why do you love it, e.g. "why I love Object Relational Mapping in Python and Django" or "why I think SWORD is great but could do this...", please remember to provide links for standards and acronyms, etc. | required tags = techStandards, technicalDevelopment, progressPosts, rapidInnovation, VRERI, JISC, <your own unique project tag>, etc. | | (V) "Value Add" aka what shifted your thinking in a new direction | What was the most important thing you discovered that brought value to your project, e.g. what was the deciding factor that made you make a specific decision on a what technology, process or human process you were going to use? | required tags = valueAdd, disruptiveInnovation, progressPosts, rapidInnovation, VRERI, JISC, <your own unique project tag>, etc. | | (VI) "Small WIN(s") & "FAIL(s)" aka advice others could benefit from | (To note: you could use twitter for these posts instead of your project blog if you prefer, make sure your twitter account is listed on the core resources form). Announce small wins for the project, e.g. when you finish a coding sprint or when a user has a 'wow your software is cool' moment. The more of these short "win" posts the better! Also don't forget to post the FAIL(s) as well: telling people where things went wrong so they don't repeat mistakes is priceless for a thriving community. | required tags = "WIN" or "FAIL" and progressPosts, rapidInnovation, VRERI, JISC, <your own unique project tag>, etc. |
Final Progress Post aka final prototype product advertisement (DEADLINE: PROJECT END DATE) - In this post you are required to address each one of the below elements, this post along with your final prototype will be evaluated for its readiness to launch to the end user. If selected, we'll be using this post as the final "advertisement" that will go in an 'Argos-like catalogue' of JISC Software Prototypes (a vision of the future to come!). We hope to put this publication on the desk of as many senior managers in UK HE/FE as possible as well as other potential investors (e.g. NGOs and VCs) in the New Year so please write this Final post with that audience in mind.
- Template for Final Progress Post (please copy and paste the below into the html of your final post and fill out accordingly. Delete comments inside of html ignore tags, e.g. "<!-- lorum ipsum doler -->"):
- Title of Primary Project Output: <--! Please use the following title format for this post: "ProjectTag: One line description of prototyped output"-->
- Screenshots or diagram of prototype: <!-- Please provide a series of screenshots or diagram that will quickly explain the point and process of your prototype to the end user. Annotation on screenshots welcome. -->
- Description of Prototype: <--! Please write this description for the end user so they can easily understand what the prototype is about and how to use it, please be brief and to the point (think Argos Catalogue like description). -->
- End User of Prototype: <--! What end user do you think will want to use this prototype, please provide a expressive example that would engage this end user on why they want to use your prototype-->
- Link to working prototype: <!-- This http link should point directly to a working prototype in which the end user can interact, if a working prototype is not available then please provide a screencast or series of screenshots demonstrating end user functionality, this screencast should not exceed 5 minutes. Please note: working prototypes are preferred even if just 'rough and ready', please do not send powerpoints or other non web-based documents, they will not be accepted. This prototype must be maintained for one year after the date of the official project sign-off. -->
- Link to end user documentation: <!-- Please provide an http link for a page that explains the use of the prototype to the end user, e.g. an "about" page that explains the project and why it is producing the prototype. For example, what end user problem does it solve, what question does the prototype answer, what itch for the community does it scratch? -->
- Link to code repository or API: <!-- This http link should be to the primary page listing all code libraries for the prototype. This page must be maintained for one year after the official date of the project sign-off. -->
- Link to technical documentation: <!-- Please provide an http link for a page listing all technical documentation which explains the code listed in the code repository above. -->
- Date prototype was launched: <!-- Please provide a date for when the last version of the prototype was made available to end users -->
- Project Team Names, Emails and Organisations: <!-- For example: "David F. Flanders, d.flanders@jisc.ac.uk - Joint Information Systems Committee; etc." -->
- Project Website: <!-- HTTP link to any additional wiki, blog or site that has applicable documentation -->
- PIMS entry: <!-- Please provide a link to your projects entry in PIMS, for example: https://pims.jisc.ac.uk/projects/view/1333 (ignore authentication pop-up) -->
- Table of Content for Project Posts <!-- A final thematic table of contents should be provided here of all the project posts written along with links to each post. Please make this table of contents generic to any readership that might find your project on the Web. -->
- Required Tags for this Final Progress Post = progressPosts, rapidInnovation, VRERI, JISC, finalProgressPost, output, prototype, product, demonstrator, <your own unique project tag>, etc.
An aggregated feed of all VRERI Progress Posts is available at http://pipes.yahoo.com/jisc/rapidinnovationprojectnews 3. Final Project Sign-OffDEADLINE: 31 OCTOBER 2010 (BUDGETS MUST BE APPROVED BY PROGRAMME MANAGERS SO PLEASE SUBMIT WITH TIME TO SPARE) - Final Budget Template (everyone must fill this out and have it approved by their programme manager)
- Budget spreadsheet template listed here.
- Please note that the final budget will be made open under FOI regulations so do not put any personal data in the budget, e.g. instead of listing names of people please list their generic 'central spine' role in the project: "project manager", "project developer", "consultant developer", etc.
- Final Sign-off Survey Form (Your project is not officially closed until this form is completed in full. The link to this form will be passed to you by your Programme Manager once you have had your final budget approved by them).
- To complete the project you will need to fill out the 'final sign off survey' form. This is the closing of your project and the feedback JISC requires to improve on rapid innovation the next time around.
- This form should be filled out as a team so as to reflect upon the experiences of the projects. JISC would ask for your honest and forthright opinion in what lessons were learned and how we could improve things for future projects based on your experience.
Documentation FeedbackPlease provide any feedback for this documentation procedure in the below comments section. Requires a gmail or hotmail account to login.
|
Hello all!
I hope you are finding your way around the wiki OK.
Throughout the programme I will be sending comments with news and advice from JISC in the comments section.
I wanted to point you to this project the best example in making sure to communicate via the comments section on their wiki pages (which of course then get emailed to the ProgM):
http://code.google.com/p/jiscri/wiki/DIASER
This makes life much easier... and if the programme manager of JISCRI had to do it all over again, he would require projects to communicate everything via the comments section on their pages :)
What do you think?
Best, Frederique
Please note that I have added in a para about project tags. Just let me know if you have any queries about the use of these.
Cheers, F.
I have made an update to match the deadline to the projects' end dates. Please contact me if you have any queries.
Thanks,
Christopher