Lets take a look at developing Road Maps for SharePoint. Now, before you start yawning and thinking ‘Like I need to know about Road Maps?’ – Well, let me tell you that whenever you deliver solutions in SharePoint you should at the very least be thinking of how not only what the capabilities required to build those solutions, but also consider support, user consumption, and administration of SharePoint solutions in an ever changing organization technology landscape (whew). That means building Road Maps.
If you design SharePoint solutions, you will at least be thinking, ‘I want the solution provided to my SharePoint users to last as long as SharePoint does’. If that’s not your thinking on delivering SharePoint solutions, one might say ‘Why are you delivering solutions for into SharePoint in the first place’?
The challenge is what process do you adopt to even start thinking of Road Maps for SharePoint? When talking about this to other SharePoint solution architects they generally have their own ideas, but it is a massive topic to consider. This short article therefore is to look at what layers need aid Road Map development in SharePoint. There will be following further articles looking at each of those layers, describing detail behind each, along with key actions that are required.
The Challenge
A SharePoint roadmap takes the relevant customer goals, prioritises them into short, mid and long terms and defines a plan that provisions those services. You do this to ensure that the solutions being provisioned within SharePoint, whether they be default, third party, internally developed, integrated meet the customer needs and at the same time helps planning future SharePoint developments. This is not to be confused with simple SharePoint implementation; developing a road map for SharePoint requires a thought process which encapsulates the fundamental goals of the customer in utilising the relevant technologies in order to fulfil the key SharePoint premise: “To create and manage content in a website”.
Through engagements and interactions with customers over the last couple of years, I have recognized a need to document the capabilities required to aid the development of a Road map for SharePoint. For example, one client had a hard time appreciating the need for site design and user experience. They were quite content using automated tools to drive site development without challenging those requirements or even managing the process. Through explaining the importance of delivering solutions through a modular approach it has helped the customer not only understand but engage with the development of processes manage site design and user experience in SharePoint for their user-base.
My challenge though has always been mapping SharePoint requirements to not simply refer to a technology release, but into a Road Map which ensures the future-proofing of that SharePoint solution. So, that means not simply looking at SharePoint in a gold fish bowl. It is taking into consideration all other services and processes that the client has through their use of the technology available to them, and making sure that whatever solution is provided follows a defined method of delivery.
I found that it is important to recognize that not all capabilities of the solution being delivered are driven by the actual service owner, or the provider of the components being provided in the solution. For example, if an app that allows automation of a process is deployed in a SharePoint site, which does not necessarily mean that the exact same app can be used in another site meeting all the requirements of that new site. No two sites are identical – the reasons for their existence are never identical, even the support matrix for each site is never identical.
What Capabilities are needed
So, let’s firstly take a look at the three perspectives that aids the development of a Road Map for SharePoint.
- Implementation. This relates to the development and the deployment of the SharePoint solution and from only the providers perspective. This area is the one virtually all organizations appreciate by default and requires the least of clarification. For example, when procuring a third party application which provides SharePoint capabilities, there is an assumption that the implementation process is documented, and can be adhered to (assuming that the SharePoint organization does its home work and identifies these things up front beforehand!). Likewise, developing a solution in-house that relies on several SharePoint components, third party apps and data-sources internal to the organization needs to follow an implementation process that can be repeated. Again, this is something that the customer assumes will take place, and it is highly unlikely that the provider would not define a method of implementation.
- Consumption. This relates to the consumers of the services provided by the SharePoint solution, thus making the solution easier to implement and successfully adopted. Of the three capabilities, this is the area that I have found is somewhat neglected by customers. In other words, customers are simply not leveraging the services provisioned through the SharePoint solution, or, there has not been enough work to identify the value that the service will provide to the customer. Check out the Value Management in SharePoint article for further information.
- Administration. Any solution in SharePoint needs to follow an operational management procedure to ensure stability, and adheres to several governance rules that are both organizational and platform related. This will include proactive monitoring, support, automation rules, reports of usage, etc. The fact that user analytics is seen as an important measure and driver to adoption, and the fact that SharePoint provides usage information (and a number of third party products also provide this and more), means that this perspective is now recognized and appreciated. That said, more needs to be understood about its value and impact.
These capabilities are needed within all SharePoint solutions. It is important to realize that an organization can choose to focus on one or two of the capabilities listed above, but the overall maturity of the SharePoint solution, and hence, the overall value of the SharePoint services, depend on all three. Neglecting any of the three will have consequences – some more readily apparent than others.
To put this into context, appreciate that all services that are in the Road Map need to be extensible, supportable, repeatable and usable. Administration, Support and Implementation are all factors to consider for each service as stated. As an explanation:
- Extensible means that the SharePoint solution is capable of aggregating services and extending its use beyond its own borders. From a simply perspective, take a basic SharePoint site. Then, by adding components to meet the user requirement the SharePoint site grows. However, extensibility is not just growing a site. It’s managing the growth in such a way that the service grows using mostly enterprise technology.
- Supportable means that the SharePoint solution can effectively be managed even when services are increased against relevant SLAs.
- Repeatable means that SharePoint solutions can be implemented by reusing standard and defined processes. It also means that those solutions can consume and reuse relevant services efficiently and consistently. Examples of this includes using third party apps to deliver SharePoint productivity and ensuring they are set in such a way to provide the likewise functionality in other SharePoint solutions.
- Usable means that SharePoint solutions can if necessary use standard mechanisms to connect to enterprise technology. This is very important in order to keep pace with changes in SharePoint and connected technologies.
The four topics above, Extensive, Supportable, Repeatable and Usable are vital aspects in SharePoint service delivery. I use them as a mantra when designing, developing, and implementing SharePoint solutions. They will each have an article devoted to them where I hope to go into more detail on what each means and how you can apply them to your SharePoint solution delivery processes.
Conclusion
As pointed out in the start of this article, the topics discussed in this article will be expanded in future articles (particularly Extensible, Supportable, Repeatable and Usable). The capabilities whose thinking needs to be planted into your SharePoint Road Map are:
- Implementation. Ensuring that the design and development of all SharePoint solutions is optimised.
- Consumption. Ensuring that the services can be used by others which includes all aspects of continual service provision, like support, adoption, training, roll-outs of enhancement services, etc.
- Administration. Ensuring that the SharePoint services being provided are stable and governed. That means proactive monitoring, ownership, configuration management.
This (short) article has been an attempt at describing the key facets that help build a SharePoint Road Map. While it is important to know where you are (hence the reason for starting to build a Road Map in the first place), getting an exact bearing is less important than identifying the capabilities needed to address, so you can continue the advancing the value of SharePoint in your organization. As long as you are willing to ask yourself some hard questions in an objective manner across all the relevant SharePoint services, including third party, integrated and internally developed, you should be able to get a good understanding for your current challenges. If you apply the strategy and objectives of SharePoint, you will be able to identify which capabilities you will need to address in the short, mid and long term.
