Gathering requirements (the hard way)

dearsantaI’ve written about communication a few times; it’s an important part of my job, I enjoy it, and I’m always learning about it. Recently I’ve been involved in a project which included a requirements gathering phase, consulting hundreds of users across two Schools of the University, and what I learned there forced me to completely re-think my approach to this process, and to communication with users in general.

The Project Management approach

As this is a hugely important project to CSCS, we’ve adopted a formal Prince2 project management approach, including a project brief and initiation document, stakeholder analysis and a communication strategy.  We’ve been careful to communicate with all stakeholder departments in the two Schools, via both administrative and academic contacts. The Project Steering Group has representatives from both Schools are who actively involved in running the project.

The project had been running for several months when we held two open forum sessions to allow anyone to ask questions about the project (which could result in a change to the IT services they receive) and almost no-one turned up.  Those open forums were a lead up to a week of technical workshops to confirm requirements and start to explore design, and again, turn out to some of those was surprisingly low considering the number of departments in scope.  What was going on?

Too long; didn’t read

It’s very simple, one of three things happened to the emails we were sending;

  1. It was read by the recipient, and distributed to some extent, but not read by the majority of staff,
  2. It was read by the recipient, but not distributed, or
  3. It wasn’t read by the recipient at all

We were communicating in a way which might work in corporations where the language of project management is familiar, but in the University it is not so familiar.

We had also relied on internal organisational structures and communication systems within each department, and had forgotten that in the University of Cambridge, traditional ‘top down’ messaging just doesn’t work.

Over and over again, when we reached out directly to Researchers and Research Group Leads we found that they didn’t know anything about the project, though many were happy to get involved once they did.

So what did we do about it?

Lessons Learned

We changed a few things;

  1. Rather than relying on centralised communication in a complex and federated University we’re contacting all key users direct.  Those who aren’t interested can opt out of the communication, and we will work with the rest.
  2. We’re keeping communication short and sweet.  Everyone is busy, everyone has a short attention span for IT issues, it’s not the most important of their working life, so we need to keep our messages brief, and to the point.
  3. We’re trying to build a website which doesn’t present project information, but a simulation of the output of the project (the JSCS website), which will give users something far more tangible to react to.

A different way

So, short and succinct communication, a less formal and more tangible concept to get to grips with, what does that mean for requirements gathering?  An iterative approach.  Thus far we’ve gathered requirements at a service level, effectively focusing on outcomes.  We’ve identified one or two new services we didn’t know were needed, and we’ve found more depth of need for services we knew were required.

What we’re focusing on now is Service Design, technical details, capacity, performance etc., but the requirements gathering phase is not over, it continues.  Having determined the outcomes in broad terms, we’re now looking at exactly how that outcome or service will be delivered, how people will access it, from where, how they’ll get support for it and so on.

This is where we’re expecting much more engagement than before, because now this really looks like something real, which people can productively engage with not at some abstract strategic level, but at the operational level, discussing details users understand and care about

Ultimately, that’s the message I take away from this experience.  If people don’t understand what you’re talking about, and don’t care about it, you might as well not be saying anything at all.

Leave a Reply

Your email address will not be published. Required fields are marked *