I work on an O365 Productivity and Collaboration team which means change is our “norm”. When you’re part of a team like this you must be adaptable to the changing landscape of O365 and adept at selecting the appropriate solution for various business needs across the organization at any given point in time.
When someone approaches the team with a business problem and asks “how can O365 help?”, it can sometimes be a challenging response. I say this not to mean there aren’t great options available, but rather there are so many options to choose from. How do we go about parsing down the options to the most appropriate ones and then communicating them to the business users so they can pick the one most suitable?
There is a smorgasbord of options available in O365 with new ones being added at a rapid pace. For example, the options for group collaboration within O365 today are: O365 Outlook Group, Yammer Group, Planner Board, standalone SharePoint Team Site, and recently Microsoft Teams. Each offers its own unique style of collaboration for a group with seemingly similar capabilities and nuanced differences.
Therefore, when responding to “how can O365 help?”, you may find that sometimes the solution is obvious and you can provision the required solution immediately, but often it’s not that straightforward. There are usually several ways to accomplish the same thing in O365 so it’s the job of the adoption specialist/solution architect to help identify the strengths and weaknesses of each option so the appropriate solution can be chosen.
I was recently asked to come up with some solution options within O365 for a business problem involving the following components: organization-wide players, ability to assign and track tasks, document collaboration, external party collaboration, retention requirements, and varying levels of security levels within. I can’t go into the specifics of the problem due to NDA (it’s also not material to this post) however I would like to share the approach I took to come up with the options for the customer. Although the business problem may change, I think the approach used is a fairly repeatable process and could be applied to many business problems you’re asked to solve in O365.
GATHER REQUIREMENTS
Nothing new under the sun here. Meet with the customer and talk about the business problem they are trying to solve. If possible, observe them while they’re working thru their current process. Some good things to find out specifically as it relates to O365 are:
- who is the intended audience for the solution?
- how large is the group of people that will come together to collaborate?
- what are the “pain points” of the current solution?
- what are the security requirements for the solution?
- are there external customers/partners involved in the process?
- are there mobile requirements for the solution? (in today’s world the answer will almost always be yes on this)
- are there compliance/regulatory requirements for the solution?
- what is the demographic of the group of people involved in the solution?
- what type of content do you want to keep track of?
ORGANIZATIONAL TEMPERATURE
It’s helpful to know the “temperature” of the organization(s) you’re working with. By this I mean the culture, political nature and work style of the organization. These have a significant influence on the type of solution that is likely to be accepted. Here are some other things to consider as well:
- where is the organization on the O365 adoption spectrum?
- what is the appetite for change within the organization? (Are there competing initiatives in the organization that have already saturated staff with change?)
- what is the appetite for custom code within the organization?
DEMO TIME
The fun part… demo time!! By this time, you should have come up with several options to demo to the customer. Minimal Viable Product is the goal so the customer can get a general idea of the options and (ideally) pick the one they want to proceed with for a POC or final product by the end of the demo discussion.
I like to put some structure around the demo presentation. In my experience, this helps the customer delineate the options in their mind which ultimately aids in better decision-making from them. I create a PowerPoint or Sway to outline these things:
- Identify the “pain points” of the current solution/system.
- Identify the high-level requirements for the new solution.
- Describe the option you are about to demo. (Tip: leverage Microsoft articles/videos/images to explain the O365 service being demoed)
- Demo each option. After each demo, list its Pros and Cons. (Tip: Make sure you’ve seeded some realistic content to allow the customer to see how their content will look in that option – very beneficial)
- Once all options have been demoed, I like to show a 1-page visual summary (example below) of the requirements, each of the options (with/without customization if relevant) and how each option fulfilled that requirement. Having this summary displayed for all demo participants is a great opportunity for an open discussion to compare options and pros/cons of each.
Tips:
- Have your recommendation ready but don’t include it in the above summary. You want the customer to be able to think thru the options without the influence of your recommendation.
- If possible, aim for a decision from the customer on which option is preferred by the end of the meeting.
EXAMPLE
Here are 4 typical options I might present in a demo. Demonstrate options covering a wide swath of O365 services/capabilities addressing the current problem and requirements to varying degrees. For each there could also be a “custom code” alternative you could suggest to fulfill more requirements of that option:
- An “Out of the Box” traditional option: this option taps into what I call the “old school” options in a standard SharePoint site available without the need for custom code – content types, document sets, content organizer, certain levels of workflow, retention policies, etc. With the plethora of options in O365, sometimes the old ones get forgotten however there is still a time and place where these are good options to demo. This demonstrates how important it is to know the features available across SharePoint so you can provide it as a choice. Sometimes it’s exactly the right solution.
- A fully customized option: this option may tap into custom SharePoint sites, custom content types, custom search web parts, custom pages, custom code, custom information management policies, etc. This is typically a very tailored, custom-built solution. Remember, you’re only building a MVP to demo; it does not have to be fully functional. Note: different organizations have different appetites for custom coded solutions like this – you must know what that is before suggesting this as an option. If they have no in-house developers and do not want custom code in their environment, you wouldn’t demo this option.
- An “Out of the Box” collaboration option: this option may demonstrate one of the O365 Group services such as an O365 Outlook Group. This takes a “use what you want” approach – it is built to allow users to make it their own without as much structure and control as you currently get with a standard SharePoint team site. End-users typically love the collaboration flexibility of this option however it is not always the appropriate solution if more rigour and control is required. I find most questions I receive around an O365 Group relate to wanting more restriction and structure. These can sometimes be addressed by user guidelines and clear communication and (in the future) policy applied to the Group based on classification. However, in some cases this will not be sufficient and may be a legitimate reason to move to a more controlled solution like Option 1 or 2 above.
- A look to the future option: this option may demonstrate something that’s on the O365 Roadmap but still suits the business problem trying to be solved (e.g. Microsoft Teams). You won’t always have something to demo in this category, but if you do seize the opportunity. Sometimes there is still value in demoing a product even if it’s in Preview release mode at demo time. Why? It’s all about user education and showing users what’s coming to O365. Perhaps it won’t be chosen for the solution being demoed, but just going thru the exercise of showing it as an option may plant a seed for a future opportunity when it may be chosen.
This is one of the key ways to address the “when to use what” confusion. Education is critical to combating this. If users know the capabilities of the products available to them, they are more likely to “self select” the right option at the right time. THIS is the ultimate adoption goal in O365.
On a recent demo where I used the above 4-option approach, by the end of the meeting the user audience picked one of the options to proceed with. That’s success in my books!
SUMMARY
Although the exact options demoed will certainly change depending on the specific business problem you’re trying to solve, the overall approach is a repeatable process. From my experience, end-users like to see options clearly laid out with pros/cons for each providing a framework for making a decision. In more complex solutions, the selection may then become a Proof-of-concept that further testing can be done on. In simpler solutions they may start using their selected option immediately for real-world use.
What approach do you take in this new O365 world where choice is in abundance? How do you help your end-users decide which one is “right” for them?
Thanks for reading.
-JCK