Building a project legacy

(Patrick McSweeney)

I am at #dataspring sandpit 2 listening to what people have done in their projects so far. A project can achieve a lot in over its course but to get real value for tax payers money it needs other people to use it’s outputs. This legacy is where good work can become really valuable. One of the key things I have identified at the centre of a lasting legacy is the project website. Most people will find out about your project outputs from your website so you should make it clear and easy for them to explore.

In the spirit of openness I will review three past projects which I have worked on and talked about how I think their website has influenced or hindered their success. In all these projects I was developing software but some projects will be generating policy or guidance type material. The same still applies here I just don’t have any of my own examples to critique.

The Faroes Project

URL: http://blog.lsl.ecs.soton.ac.uk/Faroes

This was the first JISC project I ever worked on. As a team we were not clear what was expected of us and we were struggling to find out feet. This really shows in our website. The website still exists 7 years later which is one of the few things it has going for it. It has a tiny bit of information on it but that information is not very useful. It says what we did but does not provide any outputs from those activities. We did a big requirements capture workshop which is documented on the blog but the requirements we gathered are not. This was a document that existed and it would have been really easy to attach to the post. The project also produced a running service, languagebox.ac.uk, which is still accessible and working today but completely unlinked on the website. The code for this service is open source but that is not linked either. What we learnt is not really documented here and it easily could be. It featured in reports and power point presentations which for almost no effort could have been attached. It also spawned a few papers which could have been linked to for very limited effort. The low link count on this site means search Faroes project in Google puts this site on the second page. A well linked blog post on another blog gets our top spot.

Legacy: The languagebox.ac.uk site although you would not know that from the website. The website provides no value that I am really aware of, this project which lead to the software has been more or less completely lost

Lessons

Do:
* Have a website hosted somewhere it will last.
* Upload as much information as you can. Even if its not polished it is better to get it on the web than leave it on your laptop to polish up later (that never happens).
* Link all the external materials from your project website so people can find it.

Don’t:
* Make managing your website into a chore. Do not let perfect be the enemy of good. More medium quality information is much better than almost no high quality information.
* Put too much stock in a domain name. As soon as your domain lapses (and it will) your site can disappear off the web.

The OneShare Project

URL: http://oneshare.ecs.soton.ac.uk/

This was a follow up project to Faroes which joined up with the EdShare project. The website itself is quite poor. The site was flat html (no CMS) and so it was difficult to update meaning it was never really updated. It links out to a few different resources and most importantly to the OneShare blog (http://blog.soton.ac.uk/oneshare/). This should have been the project website, it is on wordpress maintained by Southampton’s IT department so the software is kept up to date by someone else. It was easy to add content to and this was a huge boon. We did a lot of other projects off the back of this blog because it was so easy to use, we even made interns each kept a log of their activities on there. There is a lot of value in the blog posts and the pages link out to the vital information. I have had several people contact me by email to ask for help installing the EdShare software so it does get read. The website is a bit of a flop but the blog was a complete success. The website does turn up on the front page of Google but if you get there your might miss the good content which is on the blog.

Legacy: Six repositories containing a substantial set of open educational resources. The blog has a reasonable explanation of our approach and links out to the code we produced. The code has been reused in a number of places by people who were not related to the project.

Lessons

Do:
* Use a tool which allows you and your colleagues to publish information easily (or you might not do it at all)
* Link out to live demonstrators
* Link out to your code
* Show your workings, talk about what you found out and how it informed your development

Don’t:
* Fragment your content any more than you have to (we should have just had a blog)
* Don’t be afraid to run multiple projects from the same blog and just provide aggregations using tags or categories

All About MePrints Project

URL: http://blog.soton.ac.uk/meprints/

This is probably my favourite project website just because of its simplicity. Having learnt our lessons we produced a really good, simple site which had really valuable content. We used University hosted wordpress again but kept all the content there, having realised a blog is just a website where it is easy to add content. There are clear links out to the code, documentation and even the little workshop paper we got out of it. Making the software easy to install was a big win which resulted in high uptake. For a short 6 month project this project really gives bang for the buck. If I had been wiser when I worked on the Faroes project it would have been a similar success.

Legacy: As well as the seven repositories which we installed MePrints on during the project there have been many installations since including some high profile ones (e.g http://eprints.gla.ac.uk/). The way we approached the project is well documented enough that someone might even use it to inform their approach to a project.

Lessons

Do:
* Make any software as easy to install as you can
* Do link to the software documentation
* Write posts with lots of content so someone can repeat your approach

Don’t:
* Think that your project is too small for a website. We wrote 11 blog posts in 6 months and it would have been worth it if we had only done half that

Conclusion

A website really is showcase of the work that you have done. The value of the material you put on it will directly influence how much your outputs are reused. The combination of the quality of your outputs and how well the are communicated on your website will build a picture of your projects legacy. Make sure you do the dos and avoid the don’ts and in 7 years time you might have a project legacy which you can be proud of.