Reduce Your Requirements

One of my favorite Microsoft executive exchanges with customers happened between Jeff Teper, CVP of SharePoint and Microsoft Teams, and a customer as Jeff was existing the stage after having just given his keynote address at the SharePoint Conference in Anaheim, California back in 2011. I was sitting up near the front, and could clearly hear the questions being thrown at Jeff, and overheard one attendee share the details and the breadth and scale of investments that his company had made in SharePoint, and was frustrated that Microsoft would now advise them to re-architect again and move everything into the cloud. Jeff stopped to listen to him, and when the attendee wrapped up his case and asked what Microsoft tells customers in that situation, gave him a short and succinct answer: “Reduce your requirements.”

I absolutely love this response. Too many organization over-think their future plans, whether moving to the cloud, upgrading platforms, or in personalizing their collaboration environment to meet the demands of their unique company culture.

Bring it down a notch, people. Standardize as much as you can. Leverage the out-of-the-box capabilities wherever possible. And when you build — do it in a way that is salable and supportable.

There are huge benefits to building out your enterprise collaboration capabilities around platforms and tools such as SharePoint, Microsoft Teams, and the Power Platform, including streamlined identity and authentication, backwards compatibility and strong cross-workload integration, core document and information management capabilities, and a massive partner ecosystem of solutions and expertise. However, with all of these features and capabilities, and a rich history of experience, some organizations still choose to “break” the functionality and build an environment that may meet their short-term customization requirements, but sets them up for pain and frustration when it comes to maintenance and support.

I’ve had many discussions on this topic with customers around the world. And every one of them has a story about how their needs are unique.

While I’ll recognize that no two companies are exactly the same, the solutions you are trying to build and the business outcomes you’re striving for ARE similar or the same as your nearest competitors, and many other companies out there. When presenting on SharePoint migration planning, I often connect this story to the common pitfalls of failing to properly understand current-state (how your end users are using the platform today) and future-state designs. Not properly understanding the current system (functional and operational gaps, business processes and workflows) will undoubtedly lead to over-building on your new environment.

When looking at how your employees use the platform, you will likely come to the conclusion that many customizations painstakingly created to automate and simplify tasks in SharePoint to increase end user productivity may have become, in fact, outdated or unnecessary due to advances in the platform itself.

If you’ve followed my blog for any amount of time, you’ve probably heard me say that every SharePoint migration begins as an extensive business analyst activity. What I mean by this is that prior to any system implementation or redesign, you need to first seek to understand the environment goals and purpose:

• What works in the current design?
• What doesn’t work?
• What are the organizational “must have” requirements and priorities?
• What are the “nice to have” features?
• What is the goal of the project?
• What are the key use cases that drive how the environment is used?

Based on the answers to these questions, the analyst will then begin to model out the “to be” or future-state of the environment. How can you design your new environment if you don’t have a clear picture of what people do, and how they do it, within your current environment? Failure to understand the present leads to mistakes in the future.

Every customer is different, and your migration plans may be unique. Whether moving your production system to the cloud in one fell swoop, building a long-term strategy to slowly move your legacy workflows and other customizations, or to design some sort of hybrid solution in which you’ll maintain both new and old — constantly review your transformation scope and stay focused on delivering what is essential to drive your business. In other words, know your priorities at every phase of your planning.

Don’t over-build your new environment. Understand what you have to work with, have a vision for what it should look like, and work with your end users to build out the solutions that they will actually use.