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. 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.
Business problem
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
Situation
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 which 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.
Desired result
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
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 which 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 which helps 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.
Comments