A little case study for you…
Several years ago we decided we needed a document and records management system. After a lot of careful evaluation, we bought one. It looked as though it would do everything we wanted it to - not just store corporate documents but properly mange them as well, keep excellent version control, allow collaboration to produce compound documents, produce workflows which could be used to simplify and digitise many of our processes.
Today, 3 years later, we're still not live with it in any real sense of the word, apart from some pilots. Why? Lots of reasons. It took us a lot longer to get a working system than we thought it would - about 18 months - it was more complex to install than we expected. Since then we've spent a lot of time getting to grips with how it works, training people to develop and configure it, and working on our pilots. I think it's fair to say that we probably underestimated the resource that would be needed both in our department and those working with us. Certainly no fault of anyone working on it.
Today we had a meeting to look at a way forward. It was a very good discussion and I’m writing about it because it raised so many issues – issues I think we may need to face in other projects. We faced a number of options. The main one - is it a white elephant? We bought it several years ago, times have changed, technology has moved on. We have other systems which can store documents and allow collaboration. Web 2.0 is here. So, should we scrap it and look at alternatives? That’s one of the things we talked about - how we could replicate the functionality using other ways of doing things – existing systems, workarounds, and other bits of software we might get. Some of the stuff we can do in different ways, some we can’t.
How high a priority is it? How closely does it align with University objectives? Well, interestingly, some of it aligns very closely. We’re committed to simplifying and streamlining processes and the workflow can help with this - it can’t solve it. Only business process analysis and re-engineering can do that, but the actual process of designing the workflow system can build that in.
Should we go with basic functionality (lets say 80%), or go for all the bells and whistles as well? The bells and whistles would be nice, but will take longer development time, and I think more staff training for the system.
It’s fair to say we had a full and frank exchange of views, especially as we have staff who are committed to the product, who have spent 2 years working with it, who can see the benefits it will bring if it’s implemented to its full extent. Talking about scrapping it or limiting its implementation was difficult for them. But, it’s fair to say they stood their ground well! :-)
We will take it forward, but in carefully prioritised and focussed areas, where we don’t have other ways of doing the things it does, and not necessarily with all the bells and whistles. Sounds obvious doesn’t it? But, what can be difficult, especially for people closely involved with projects, is taking a step back, seeing the bigger picture and considering alterative ways forward. Thinking the unthinkable is something we are going to have to do more often in the current climate.