Deploying Office 365 is easy. It offers thousands of powerful features.Finding out where to use this features in business context is not so easy.Here is how you find those scenarios.
Estimated reading time 8 min.
If you are looking for a quick list of usage scenarios, this is NOT the article.
Contents
What is a usage scenario
Every feature originates from a “use case” – also known as user need, a problem people are facing, some manual effort, some inefficiency, some enhancement requested by users. These use cases end up as features in a software product.
Just knowing the features is not enough. We have to find out where to use them – this is called the “usage scenario”. The usage scenario may be the original use case or another relevant need.
What to do with usage scenarios
Once you know the usage scenario – you can apply the feature to it and improve efficiency.
Unfortunately, the use case behind each button, option or ribbon item is never documented publicly. Therefore, customers and partners have to do this in reverse.
Guidelines
These are guidelines with few examples. The objective is to provide the right thought process and then leave you to discover the scenarios yourself.
- I suggest that the evaluation and adoption team should consist of cross-functional business users along with IT and Learning and Development team. They should backtrack from every feature and discover the use case – ideally in the local business language.
- Once this map is ready, you can identify the most pervasive use cases and then create the adoption campaign around it.
- Some use cases are universal. Some are specific to roles while some others are specific to departments. Universal cases take priority. Others are released as users gain from the generic benefits and have the desire to learn and apply more.
- Often the new functionality is overlapping at use case level. Most of the adoption effort is focused around showing off what’s new and great. Which is fine. But the overlap must be resolved while doing so. Otherwise, people look at the new thing, get confused and continue to work the old way.
- Use cases which dramatically transform routine, mundane and problem ridden activities are most important. New behavior takes time to sink in. But if there is lot of known suffering and inefficiency in existing process and if the new process is dramatically better, adoption is faster.
- Simple data capture using a list instead of sending Excel attachments is a simple but extremely useful scenario.
- Creating a shared OneNote notebook for time-bound, key initiatives is another simple way to get everyone on board. The benefits are so compelling that the resistance to change is replaced with excitement about the new miracle.
- While delivering use case based solutions, it is important to utilize out-of-the-box feature set initially. Anything which requires development, integration with LOB systems, involvement of graphic designers, etc. is bound to go into an endless loop.
- Proving use case specific training material is important. Generic training does not help.
- Finally, remember that all these tools are designed to empower users. Therefore, IT must be willing to relinquish control and let the users handle their work.
- Here is an example of overlapping functionality. In this case, the use caseis explained and the recommended approachis communicated. Final discretionshould be left to users. If you want to share a document (or any othershareable item) –
- if you don’t care about what happens to it later – send as attachment to mail
- if you are going to ask for any inputs, review, etc. – publish to OneDrive and share
- if the document is going to be implicitly shared with your team – publish to team site
- if you want immediate clarification – use a Lync meeting with sharing
- if you don’t know whom to share it with – use Yammer
Refer to this article for more details.
Confusion: Which method of communication to use when?
***
