How to flop a Jisc project

I am at day two of #dataspring and I have done a lot of talking to people about their projects. I notice a few common mistakes which I recognise from my 4 consecutive years of Jisc projects. These are not a definitive list and they wont all apply to all projects. They are mistakes I recognise from either having made them myself or having seen other projects afflicted with them. Jisc’s remit is to get tools and technology into the hands of people and there are a few ways your project might fail to do that. This is the hit parade of my top 8 mistakes not to make. They are roughly in most important first order.

Not having a web presence which will provide long term value

This is the summary of quite a few other points. If I can’t find out anything about a project a year after it happened then the project may as well not have run at all. It is all too common for projects to find themselves in this situation. Job one should be setting yourself up with a web presence and keeping a blog of your progress. As you do presentations upload them to the blog. If you do a requirements gathering exercise put the requirements documentation on the blog. When you have software to share make sure its linked from the blog. Basically if its not on the blog it didnt happen, but don’t worry putting it on the blog is easy. If you think your project isnt big enough to warrent it’s own blog why not guest post on another projects blog?

Having no users

This is another umbrella which covers some of my other points. Without users your project isn’t a solution. The aim is solve a problem for people, without the people there is no problem. Ideally you will have users as the first deliverable. Hopefully you knew what the users problem was early enough in the bid process. Engage the users, gather their requirements, listen to their woes, solve their problems! Don’t just write a project for a jolly, that is not a good use of tax-payer money.

Thinking Jisc care about what you said in the bid

What you bid to do matters a bit… If you said you were going to build the Taj Mahal but you end up building an out house then that might look like a fail. However if you had a lot of discussions with the users and it turned out they didn’t need the Taj Mahal they just needed somewhere to flush their news paper then please don’t build a Taj Mahal just because you said you would. Jisc cares far more about the thing you build being useful to people than they do about what you said you were going to do. The thing you build should address the problem you have. If your understanding of the problem changes the solution probably will too. Chris suggests the issue maybe caused by people are used to research funding where you document a failure rather than change the criteria.

Not having the staff in post

In the old days of Jisc there was were a lot of big long projects where Universities hired someone specifically to do the project. Even as Jisc projects got shorter it was not uncommon to get an extra hand in to do the project. This gives you a number of problems. Talent is not kept in the public sector because when the project ends the staff leave. This also one of the big causes of projects lateness because either you really struggled to hire someone or the person you hired at short notice wasn’t very good. My advice is if you don’t have time to in your organisation to do the work then consider teaming up with an organisation who does or simply accepting this is not the bid for you.

Thinking it is a research project

Jisc projects are about technology, tools and infrastructure and that this is an IT concern. The research element is “will we be able to get users to use it”. The Jisc funding style attracts early career researchers who use Jisc as a leg up into the world of research. This isn’t a big problem as long as you solve the problem you aim to solve. Research papers are nowhere near as valuable to Jisc as good project website and a well documented version controlled code-base that people can reuse. If you get research done on the side that’s fine but remember to do what you bid for.

Your early deliverables have no long term value

This is becoming more of an issue now Jisc are funding projects in stages, but even when they are funding the whole project upfront. If you aren’t in the mind set of delivering long term value by the 3 month mark there is a very good chance you never will be. I always think “If this project ended tomorrow would it have been worth starting”. If the answer is “No.” look at how to change that. Get some value on the web as soon as you can, your project will be better for it.

Thinking it’s all about the software

Jisc is software, tools and infrastructure oriented and so some people get carried away. Jisc is about IT not computer science and IT is about using technology to aid a person doing a job. The greatest piece of software in the world is nothing without users. Users are great for finding emergent properties of the software, providing ideas and finding bugs. Get some users, and work really hard to keep them engaged. Also make sure you are promoting your projects in the right places. Some projects dont have software outputs but they should still have users. Recommendations that no one has ever followed are a bum deal too. (See also Having no users)

Writing other unfinished projects into the bid

This is not the most import point but worth considering. If in your project bid you have software or services which are not released yet then assume they wont be. They may well not be within the life of your project. I know a few projects where the whole project was built on the outputs of other Jisc projects. A lot of the outputs turned out to be poor or were not finished before the project started. This made the project massively behind schedule and a lot of time was spent cleaning up other peoples mess.