Use Cases: The enemy of collaboration?

Today’s modern workplace offers a plethora of collaboration tools, as we shift away from face-to-face interactions and increasingly towards digital connections. But making these work has always been complicated by:

  • Too many tools to choose from
  • Choosing between social or document-based collaboration
  • Having overlapping collaboration functionality within suites such as Office 365   
  • Low collaboration maturity in organisations to begin with

When deploying collaboration tools or determining the best way to use existing ones, we often draw upon standard IT project management practice and develop use cases for them. A well-worn route for connecting tools to users, for giving those tools a business goal, a purpose.

And that’s great, we always need a clear goal. And here is where we encounter the problem with use cases and collaboration: forced to try and reconcile two very different types of goal.

1. Tool biased goals

Use cases are biased towards the tool. They represent transactional needs and are viewed from the perspective of the tool and not of the user. We can refer to these as functional use cases, based on the function of the tool. But isn’t this just putting the cart before the horse?

We are unwittingly pre-determining how people should use the tools based on what the tools say they can do, and of course tools speak in a very different, very functional language. For example:

  • To share files with anyone in the organisation
  • To work on files at any location

bot-not-userMakes sense, but if we are after collaboration, this simply isn’t good enough. We have to ask ‘why’ to these questions. Why do we need to share documents? Why do we need to work on them at any location?

What are our ‘users’ doing? In fact, they are not users, they are people. They might not even need documents at all. The problem is we look at everything as an incremental solution. We used Excel to capture project data, so therefore we should continue to use Excel, only now we should do it in the cloud! That way we can work on the one file, anywhere! Is this a better way of managing a document? Possibly. Is it a force for collaboration? No.

It doesn’t ask any of the deeper, more fundamental questions we need to ask. Why are we capturing data? Who do we need to share it with? What happens at the end? For a moment, let’s forget we ever had an Excel file, forget how we’ve historically worked, and start again. If we actually mapped out people’s interactions based on answers to those questions, we’d have an entirely different use case.

Collaboration as a goal

Another approach would see us having collaboration as a goal in its own right. However noble this is, it still won’t help. Collaboration is never an end goal in itself, it’s a means of achieving an end. Basing a use case purely around what we think collaboration is (or would like it to be) will still drive us towards incremental changes, such as:

  • To have multiple authorship at one time on a file
  • To target content to selected groups
  • To be able to comment on anything at any time just because we can

Again, we have to look a little deeper and understand why we are collaborating. What are we collaborating for? What is the end result for the customer? More important than trying to roll out the broadest, smartest tools that allow us to collaborate better is trying to understand how as people we collaborate. What will motivate us, what will stop us. Where is the link to business outcomes?

What about user stories?

User stories at least acknowledge the perspective of the end-user. However, we still constrain our thinking by the capabilities of the tool and what we expect of it rather than what the problem is that we are actually trying to solve. For example: “As a remote site worker I need to be able to access data logged by the previous shift to identify my tasks”. All sounds reasonable, but all we do is find ways to connect the user with the previous shift’s data. We’re not looking into the actual process of collaboration: who are these people, why do they need to access their data and what does this data tell them? It may be that we’re actually trying to facilitate a conversation between two shifts, but instead only capture data because that’s what we’ve always done.

Use cases and user stories both still drive us to look at previous habits, building on functional capability rather than looking for real opportunities to collaborate based on deeper, fundamental business needs.

It’s about the people

Collaboration is never going to be built on a set of use cases and user stories which too often allow the tools to be the driver of the outcomes. It’s a people thing. It’s what we do when we need to work together to solve a problem or create new solutions and fresh thinking. Understanding what our people are doing, and who they need to collaborate with to improve our work is where we should start. I have absolutely nothing against collaboration tools, in fact they are capable of awesome things when properly used. But we need to challenge our assumptions on why we are using them, on why we are using documents as our vehicle and not conversations, on why we are collaborating in the first place.

A great way to start is to imagine you don’t have any IT tools – to forget about how we’ve historically done things. All we have instead are some people, a place of work, some roles and some customers. Then apply the same projects. What can we do to exceed our clients’ expectations? What can we do to do things better than last time? How would we work? Who do we need to work with? Answering these questions will give us the real use cases we need for our collaboration tools.

Flattening hierarchies, creating more visibility to our work are what collaboration tools are capable of. The question is, how can we leverage this in our own unique situations, what will it achieve and what do we need to do to engage our people in this? If we jump to this more openly communicative world, we need to understand what it means to the way we work, and crucially how we feel.

What if our use cases addressed emotions rather than functions? “I feel confident to highlight a failure on our enterprise social tool”. Now we can actually start to address some of the issues that hold us up truly collaborating.