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.
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.
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.
On the good ole trek through TechNet, I noticed that Microsoft have published a set of Governance Guides for SharePoint 2013 – yaaaaaay! Taking a look through the pack, I noticed some great nuggets of information, which backs up the Governance topic I’ve pushed in this site (written to be version agnostic) and which appears in my Microsoft books (Microsoft SharePoint 2013: Planning for Adoption and Governance).
- What is governance in SharePoint 2013 – this looks at the areas of SharePoint service management, the site types, the role of the team that should look after SharePoint (like sponsors, managers, trainers etc), training and best practices for building plans (http://technet.microsoft.com/en-us/library/cc263356.aspx).
- IT Governance covers the team, the policies and the users. A word of caution would clarity concerning a statement in that section.” A SharePoint service as an IT service”. Actually, I would see the term “SharePoint service” to mean different things to different groups of people. An example I found just the other day is where a team of users wanted their SharePoint services to be available in a scheduled group of days and wanted an SLA to match up to it. This meant that IT would see that SharePoint service as a collection based on business rules, IT resources, with its own set of stakeholders, users, support matrix etc. Whilst the Microsoft definition of SharePoint service is not far from this, there is definitely a service element to the users as well as IT – however, to see the statement at least is a great step forward (http://technet.microsoft.com/en-us/library/cc262883.aspx).
- Information Management and Governance in SharePoint 2013 – this page describes information architecture from a laymans perspective, presents a set of questions that may be asked when developing a site or solution, and then links those to relevant TechNet pages. Great resource this and I would certainly bookmark this page (http://technet.microsoft.com/en-us/library/cc262900.aspx)
- Application management and Governance in SharePoint 2013 – this page describes customization, lifecycle management, branding and presents a discussion as to whether a solution or app should be taken (http://technet.microsoft.com/en-us/library/dn531035.aspx).
In conclusion, and I am putting my neck out on this one is this… be mindful of that word “Governance”. That word “Governance”, when mentioned to people puts them on a ‘back footer’ – they immediately think ‘Oh dear, there’s going to be a whole bunch of enforcement now, so isn’t that going to stop me doing what I want’? And, that is not the ethos applied to SharePoint which is ‘the ability for the user to create and manage their own site’ – which is the kind of feeling you want users to have, because that makes them want to use SharePoint, right?. Note also that I used the word manage in my definition. To manage something means that you provide a service to someone other than yourself. And to manage something means having to understand exactly how that service ticks, how you should provide it, how the user learns and evolves with their sites from the solution within that service. So please ensure that when you talk to your userbase about Governance, that it has absolutely NOTHING to do with forming a new form of Government, and that its all about sustaining productivity.
Bottom line? The Microsoft Governance Guide pages are great to bring management knowledge, particularly for those new to the land of trying to manage SharePoint 2013. Of course, one does not instantly meld all the topics and best practices listed to the organization using SharePoint, they are to be used as a guide. So critically, when reading these articles, remember that in order to apply them to your sponsor to be mindful of the culture and the learnability of the customer, and remember that at the end of this, SharePoint needs supported. So don’t start overusing the word ‘Governance’ until it is clear to your customer how it will be provided to the service, the actual resources needed (especially who is going to continually manage and support the process). Doing those things then defines the expected productivity gain from using solutions in SharePoint.
I put together an article concerning SharePoint Training and Resources for IMIS (Institute of Management Information Systems), this is now available on line
User Adoption of SharePoint is based on meeting the goals and requirements of the business sponsor. To do that, there is an importance in ensuring that the correct features are applied to the relevant solutions to meet their goals. Platform Governance is key; since there would need to be knowledge of the relevant features and an understanding therefore in how they would be implemented, supported, maintained in an evolving SharePoint landscape. This is particularly important in deciding on the migration path of SharePoint 2010 to 2013, since quite a few features have been enhanced.
Microsoft Word Research – Providing SharePoint Search features to SharePoint 2010 and SharePoint 2013
I’ve published to TechNET UK an article concerning the use of some great Microsoft Word functionality called Research. This provides individuals with the ability to customize options to suit their research needs. This feature can be used to expose SharePoint search, meaning that individuals can locate information they have access to on SharePoint within Microsoft Office Word, without having to go to the SharePoint site.
To read the summarised blog go here.
A full article is here
Am in the land of setting up quite a few 2013 environments to demo and test. Some using VMware, HyperV, Cloudshare to name a few. Ran into a ‘gotcha’ starring SQL which I thought I would share. In this scenario I’m setting up a Dev / POC environment which is a single server SharePoint 2013 environment and not set as a Domain Controller. SQL is also deployed to that box. Using the UI it’s not possible to create a new farm due to the fact I’m using a local account as farm admin, therefore, had to use the wonderful New-SPConfigurationDatabase Powershell command to create the SharePoint config database).
Yaaaay, SharePoint 2013 is now available on preview – there’s a whole pile of blogs coming your way concerning Office integration and SharePoint 2013 from me. Also, watch out for my new book which I will announce shortly – for now, get the download and start trying it out!
Installation Details here:
Am pretty humbled here having been accepted into the Microsoft Most Valuable Professional Student Mentoring programme (ok its a long title). However, its all about giving back your expertise, knowledge and experience into those who will in future help shape SharePoint and associated products. To recap, the MVP Student Mentor Program pairs MVPs with students in the Microsoft Student Partner (MSP) Program to share their knowledge and experience as influential technical leaders in the community. The MSP Program is a worldwide educational program that sponsors students majoring in disciplines related to technology who then share their knowledge with the academic community. The MVP Student Mentor Program helps MVPs share their passion, expertise, and real-world experience with students who share their passion and are just starting out in the technology community.
Also when I’m paired up I’ll be adding more articles related to SharePoint experiences with students so watch this space!
More information here:
If you are an Information Worker in SharePoint, and you would like proove your skills by marking on your Cirriculum Vitae as a Microsoft Office Specialist in SharePoint, then the best way is by doing the Microsoft Office Specialist suite of exams provided by Microsoft and run by Certiport. This is also true if you teach Microsoft Office at school, college or university, and would like your students to be made aware of this offering.