Collaborative Systems: Easy To Miss The Mark
Map out use cases defining who you want collaborating and what results you want them to achieve. Skip this step in the beginning, and you'll regret it in the end.
One of the things that organizations really need to consider when evaluating collaborative solutions is their use cases. Not only that, but also understanding the outcomes of those use cases and how they can map to a desired feature requirement. Use cases really help put things into perspective for companies who are seeking to understand the "why" before they figure out the "how."
That's what a use case is: the distilled essence of a role within your organization, how it will interact with some system, and the expected or desired result. Developing use cases makes your plans, requirements, and specifications less abstract because it forces you to come up with specific examples.
This is why we created a framework (inspired by Gil Yehuda) to address this. It breaks down as follows:
-- Identify the overall business problem you are looking to solve (typically there are several).
-- Narrow down the problem into specific use cases; each problem has several use cases.
-- Describe the situation that needs to be present for that use case to be applicable.
-- Clarify the desired action.
-- State the desired result.
Here's a simple example of how that would map out.
Jacob Morgan's The Collaboration Organization is a comprehensive strategy guide on how to use emerging collaboration strategies and technologies to solve business problems in the enterprise. It has been endorsed by the former CIO of the USA, CMO of SAP, CMO of Dell, CEO of TELUS, CEO of Unisys, and dozens of other business leaders from around the world.
More by Jacob Morgan
Lack of communication among employees causes them to work in silos.
Use case #1
Employee wishes to share a document with co-workers so that they can edit, share, or make changes to it.
Employee has either a complete or partially complete document that she would like to get feedback on and solicit additional ideas for.
Expected action of the platform
An employee uploads a document to the platform and has the ability to tag it for easy retrieval and search. The platform recommends additional relevant tags that the employee can either accept or reject. Other employees are able to open the document from the same platform and make any desired edits or comments. Changes are tracked and versions are saved. Relevant employees are notified of any changes and anyone can search for that document with keywords or tags.
Document can be developed in a collaborative way, which reduces duplication of content and reliance on email. The document is now easily accessible and searchable.
[ Know your goals: What Collaboration Can And Can't Fix. ]
This approach is quite comprehensive, but it usually yields positive results because it really helps the organization think through and understand their uses cases and what is required while also providing potential vendors a very solid look at what is being asked of them in context. Are their simpler and less comprehensive ways to approach this? Absolutely, and in fact you will discover many new use cases over time that you may not have thought of originally.
A quicker approach might be to focus on just three areas: business problem, use cases, and then the expected action. You can easily compile this in an excel spreadsheet. This may oftentimes be good enough, but one of the common things that help vendors understand if their solution can meet your needs is getting a glimpse into the situation in which something would need to happen--it provides context.
We have taken both approaches with clients in the past. For the primary use cases or business problems we might take the more comprehensive approach while taking the less comprehensive approach for secondary use cases. I'm sure there are plenty of other ways you can think of to map your use cases to platform feature requirements. The important thing here isn't that you follow this particular framework, it's that you actually sit down and go figure out these use cases and requirements, I don't care how you do it, but you must do it.
I have been in several client and prospect meetings where someone says, "I wish I would have been more thorough in our approach, now the platform we deployed can't meet some of our major needs."
Hopefully this will help you map your use cases to collaboration platform requirements. If you have other approaches I'd love to hear them.
Social media make the customer more powerful than ever. Here's how to listen and react. Also in the new, all-digital The Customer Really Comes First issue of The BrainYard: The right tools can help smooth over the rough edges in your social business architecture. (Free registration required.)