Hi Folks, As promised in last weeks’ article, a quick warn that I will be drawing attention to a number of third party products which I have used with SharePoint in particular articles going forward. Before embarking on what can only be described as a wonderful adventure, I’d like to clarify why I am doing this, given that this site is devoted to SharePoint service delivery. This clarification is important, because, for a long time, I have been “externally SharePoint technology agnostic”, and instead, user focused in terms of the actual process of service delivery (implementation, support, capability etc). That will not end of course!
So why the third party tool mentions Geoff? Well, as a SharePoint solutions architect, I have always maintained that whilst a lot of things can be achieved using SharePoint in-built features and components, that there will be times where a third party tool, used to augment SharePoint, or to meet a specific requirement, carries more value add. There will be instances when it is either bringing in the third party tool, or instead, having to either (a) redesign the wheel (b) attempt to hack around SharePoint (c) bring in developers to code (d) inform the customer in a Star Trek Scottie style ‘It cannae be doon, capn’, or a combination of those.
Indeed, I can think of many instances where a third party product, sanctioned by the SharePoint sponsor, meets key requirements much quicker, smoother and can bring long term enhanced user adoption and therefore a greater ROI.
Note however, that in adopting third party tools is not without its pitfalls, for example, having to ensure that there is a strong relationship with the third party development team. Support must be manageable, that the third party tool must be scalable (or its limitations understood fully), and that the tool sits within the organizational SharePoint strategy. This is the essence of commoditization of course, the ability for SharePoint to evolve and morph into exactly what the customer requires (if the process of doing so is defined and managed). And, given that as a SharePoint community the app model of the cloud (Office 365) brings a lightning bolt of third party components means SharePoint becomes even more commoditized. Already, Microsoft Office is fully tuned into SharePoint – with the news that the Access App is now available in SharePoint online it is now even more important that we, as SharePoint workers are aware of third party tools also. This is particularly since, as these tools gather pace, they will increase their own customer base to the point that new skillsets evolve in the marketplace that become commoditized. For example, a number of third party tool providers produce their own training courses, which become a commodity due to the size of the customer base for that tool.
Anyway, I will for now list the tools (in alphabetical order) which I will give special mentions to as they relate to areas of SharePoint service delivery. There are many others I have absolutely no doubt, but these are the ones which I particularly have experience in and therefore can write about with a little more authority:
A gentle reminder that where the tools are discussed that I will not describe what is good or what is bad about the tool. I am not a sales person for any of the tools. Do not expect me to go into details of installation or configuration either. The key is to identify where I have used the tool, why, and how – including the process of how I went about provisioning the tool from a business perspective……
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.
Providing a sustained and good SharePoint service means providing adequate SharePoint support – and that is not simply for ‘work-days’. As Christmas looms, there needs to be ample preparation done to ensure that those charged with providing SharePoint support over the period, have the necessary tools and processes in place. I penned an article for TechNet which is on the following link:
http://blogs.technet.com/b/uktechnet/archive/2013/12/23/port-pies-and-sharepoint-support.aspx
Happy Reading, and Happy Christmas and a wonderful new Year to all!
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.
As anyone working with SharePoint and trying to get people to use solutions provided will know – you simply cannot guarantee any success concerning the usage of any SharePoint solution, if the relevant support provided is not ‘good’ enough in the eyes of those using the solution.
(more…)
Time for another support article, and I’ll concentrate in this area for the next month or so since it is a key aspect of SharePoint Service Delivery, and crucial to sustaining SharePoint User Adoption. I put an article to the wonderful MS TechNet guys, and am so pleased they published it! The article is a ‘thought’ piece based on the importance of identifying exactly what in a SharePoint environment should be supported, and suggestions of some methods used to set those expectations back to those using the solutions provided (and therefore supported) in that SharePoint environment. To describe this, I’ve used a scenario common to many organisations using SharePoint. Anyway, best you read the article located here, and hope you find it useful!
http://blogs.technet.com/b/uktechnet/archive/2013/10/23/oh-sharepoint-what-gets-supported.aspx
![Office365 Service Status and SharePoint support]()
Am checking up on a friend who is using Office 365 within a team of 20 people, mainly for SharePoint 2013, and who relies on SharePoint support provided externally. My friend stated they want to ramp up the usage, but were concerned about service availability, and wanted to know whether it was possible to get a record of service uptime for Office 365. They were particularly interested in SharePoint Online service uptime.
That got me thinking. Not all customers using Office 365 will understand how to read the service status provided in Office 365. Even if they saw that page, without really understanding the meaning will probably gloss over some of the features within the service status offerings on that page. Also, considering the methods by which Office365 tenants are provisioned (off-the-shelf buy, through a re-seller, directly) it could be likely that literally any computer literate person could be drafted in to support the customer who takes on Office 365 who potentially has never worked in customer support!
So, yes, taking some time to understand the service statuses provided within Office 365 is useful. Particularly if you are responsible for managing SharePoint online through Office 365 (plus its other offerings), or if you are considering a move / hybrid approach and need to inform the client of the service expectation and what is used to measure service status in Office 365.
What is the Office 365 Service dashboard? The service dashboard is located in the Office 365 Admin centre, and then by clicking the View Details and History link at the foot of the current health list in the centre of the screen as shown in Figure 1.
Figure 1: The Office 365 Service Dashboard
When View Details and History is clicked, a screen showing the service health of Office 365 is displayed. These Service are Exchange Online, Identity Service, Lync Online, Office 365 Portal, Office Subscription, Rights Management Service and SharePoint Online and all are shown in expanded format showing the sub-services and their statuses. The service status is indicated by an icon which is displayed for each. Figure 2 shows each service icon, its meaning, the definition associated with that icon.
Figure 2: Office 365 Service Status icons, description and Definitions
Most of the above are self-explanatory, and for each service listed if there is any status reported other than ‘Normal service availability’ there is a link which is provided which when clicked allows the individual to get more information about the service issue.
An interesting one above is ‘False Positive’. For those working in email land you may have heard of this term before. A False Positive is essentially a message which is legitimate but marked as spam, which is then rejected or returned to the sender. So, what that means is that a report is provided that indicates a problem but does not provide clear proof. It is very important that these are noted, because if that’s not done, it will result in False Negative.
Without going into False Negatives (which I will write about in a companion article), let’s take a look at a False Positive example starring on-Premise SharePoint. Assume that a SharePoint 2013 on premise platform has a third party app deployed on it and a monitoring service carrying out remote scans of all apps and services on that platform. Note that it does not matter what the third party app does. The app identifies itself as version “1.6.11”. A remote scan provided on the platform identifies the app to be a vulnerable version (could be due to security, compatibility or other issues). The remote scan does not have further knowledge of the app, however, the scanner has reason to believe that a vulnerability exists and includes this in its reports. However, the SharePoint administrator (a human!) of the target system may know that this app has already been security-fixed to “1.6.11-1”, however, the app still identifies itself as version 1.6.11. Hence, this is a False Positive because the platform is deemed healthy.
I would suggest that False Positives are useful when identified, and should be recorded – so it has good reason to be there listed as a service status. One thing I should point out, however, is that the problem with tools to remote scan is that if they are configured strongly enough to be effective, there’s a significant chance of receiving false positives. If too many false positives are received, the monitoring becomes less proactive to the point were real issues are ignored, because of the volume of false positives and the assumption therefore that a human already ‘understands’ that there is no issue (when there is!).
Going back to getting more information concerning the service status. Figure 3 shows a list of the current health against each service in Office 365, and for any there there are issues links are provided for more information. SharePoint shows as being in extended recovery in the screenshot. You can click the View details link to get more information concerning the issue. In the figure, I have deliberately scored over the date…
Figure 3. Example of the Current health of services section in the Service Overview page
When clicking on the view details against a particular service status (not normal service status), another page is displayed giving further information concerning the issue covering issue, resolution action and date of next update. Figure 4 shows the page displayed when the view details link is clicked (again I have deliberately scored over the date).
Figure 4. The details page regarding the relevant incident when clicking the view details link at the foot of any service which has an issue on the service overview page
So, the service overview page is a good resource for identifying how the products provided in a Office 365 tenant are performing. However, without understanding the lifecycle of a service incident, it will be problematic in identifying whether a service incident is being fixed, has been fixed, is still under investigation and so on. What is the lifecycle concerning a service incident and how is that reflected on the service health dashboard? Here is an outline of that process:
- The incident occurs
- The service health dashboard is updated to ‘investigating’
- The incident status is posted to the service health dashboard
- The incident is resolved
- The closure summary is posted to the service health dashboard
- The post incident review is posted to the service health dashboard
I think this lifecycle is important to describe to your customer, as well as your service desk team (if for example you have an internal support team). When explaining the lifecycle of a service incident to a new customer, do this as part of providing Office 365 in the first place. If this is not done, there will be an assumption from the customer that they have a direct line to Microsoft Support. They will assume that they can quite literally pick up the phone, report a user challenge which they think is resolved using the product, and expect it be resolved immediately and that the resolution meets their exact requirements. Besides which, even understanding the sheer wealth of information provided on the service dashboard will overwhelm the customer, particularly if the customer has not been taken to identify, using the Service Level Agreement, the products listed of the service dashboard which will be of applicable to the them. That’s not to say the support you provide does not monitor the other services, it is just that in terms of priority that there is information going back to the customer that clearly identifies what is supported.
Conclusion.
Understanding the service dashboard is only a part of the picture in providing a successful support service for an Office 365 customer. In order for it to be effective and measurable, the results being displayed on the dashboard needs to be made meaningful and each service status to be relayed to the relevant customer in a way that makes it useful to them. So, to effectively support Office 365 and to manage customer expectation, you should define a Service Level Agreement which maps onto exactly what will be supported, since that is the key that will help you and the customer able to map the service status provided by the Office 365 service, give that meaning and provides a useful resource which can be measured.
I repeat, the principle here is a matter of what is supported. Your job as SharePoint support is to support the information worker, and in that sense, you support the usage of SharePoint. Your job is intertwined with how SharePoint is exploited to the benefit of the business. Your job is user support. However, Microsoft will see things from an entirely different perspective. Their job is product support. Microsoft cannot be expect to support your users, and certainly cannot be expected to precisely understand how your business applies to their products. So, when your query goes to Microsoft Office365 support, that query will be of several to do with the products provided within Office 365 of which SharePoint is one. That support will answer the question from a product perspective point of view. Your job, is to translate that inherently generic information into the specific information your end user needs. That means that the service status messages that are provided within the dashboard are not specific to your users concerning their use of the product, and instead the service status of the entire product provided to all customers. You must therefore take the information provided by the service status messages and relay that to the customer in a way they understand using the Service Level Agreement.
The Service Level Agreement is vital, for in the end, the only support service truly qualified to support your users is your own. The service dashboard is a resource, for that is the best it can be. If you depend 100% on Microsoft Office 365 support, the best you can hope for is an accidental or actual coincidence of purpose. I believe that is a foolish prospect, whereby one would hope or even attempt to engineer that the two widely differing set of goals (those of Microsoft and your end users) coincide somewhere, so that your company can extract some real benefit from ‘supplier’ support. I would not put all my eggs in relying on complete Microsoft support. You will still need to provide real user support and that means building a proper support model which exposes the service status. The alternative (getting the supplier to provide end user support) will simply not happen in the way the customer will expect or fully understand.
References:
SharePoint Service Level Agreement Guide
SharePoint Service Delivery
Book – SharePoint 2013 Adoption and Governance Guide
With every SharePoint solution being delivered, there is comes a change management effort that requires not only organizational, but also behavioural change on the part of the participants. You can set up the finest SharePoint solution on the planet, but if people do not take to the SharePoint solution, nothing will change and the effort will be lost.
“To get a horse to drink water, you make the horse thirsty”
Successful adoption of any SharePoint solution enables users with self determination. Irrespective of user task, or position, self determination needs three factors, which is competence, relatedness and autonomy. These combined produces motivation. And, when you have self determined people, support requirements are properly defined, people understand how the solution makes their tasks more productive, training strategies are easier to develop and sustain. A key person requirement, which is not technical, is the SharePoint Champion; whose objective is to foster self-determination amongs their peers; a person elected to help drive adoption of SharePoint solutions, elected by the business, and for the business.
I wrote a pretty detailed piece on the topic of SharePoint Champion being a vital role, because I think it is so important to provide successful service delivery of SharePoint solutions. To see this, check out on Microsoft TechNet Newsletters article posted here:
http://blogs.technet.com/b/uktechnet/archive/2013/07/29/sharepoint-champions-are-vital-roles.aspx
Hope you find the article useful!
A key aspect of service delivery is the provision of updates to the SharePoint Platform, the key ones being Service Packs. Well, Service Pack 2 for SharePoint Server 2010 is now available. The pack addresses security, stability, and performance and provides better compatibility with Windows 8, Internet Explorer 10, Office 2013, and SharePoint 2013.
(more…)
The SharePoint 2010 Productivity Hub and the User Adoption Kits for SharePoint 2010 and SharePoint 2013 are great tools of centralizing knowledge in the organization, providing materials to enable the communication of SharePoint to information workers and helping organizations address User Adoption principles. (more…)
