This article takes a service delivery examination concerning workflow provisions around SharePoint, Office365, Windows Azure to help you understand the implications there are for organisations needing to improve business process automation, collaboration and productivity through workflow adoption.
Support service development for SharePoint is crucial to ensure sustained SharePoint Governance and User Adoption. I had the situation where in building a SharePoint support service that a customer needed the provision of support to be handled differently for a newly delivered SharePoint solution, and also needed that to be documented and agreed by the SharePoint sponsor. The reason for this is that they needed the support service to be measured against the supply of support to that solution, which was critical to the department and the organization.
Bold statement time. The Internet is a collection of machines – and there is more data generated by machines than humans. IOT (Internet Of Things) is connected devices providing data which will simplify, enhance, and enrich our lives. Already connected devices are beginning to revolutionise our lives; but to understand the nature, challenges and opportunities we need to understand how we can take informed decisions concerning this technology and trends.
Things like how the data our devices upload and download is shared, used, managed, controlled with clear data integrity. What should be our focus, what and who can help us understand this technology. IOT has implications for those working within the SharePoint sphere. As SharePoint workers, we will need to roadmap and further refine data provided (from internally or externally provided systems harvesting sensor data) to define an IOT strategy.
We will need to learn how to promote use of devices used within organisations, so they become smarter devices thus turning our companies, and ourselves, into smarter people. The article I have written for TechNet, aims to describe, simplistically, the nature of IOT, some of the key opportunities realised by Microsoft and others, the challenges we may face in control, management, security, privacy. The article suggests some take-aways in what we may need to address to support the infrastructure and manage the data.
Sometime ago, I also wrote about the skill-sets coming into the fold of data analysis (the Data Scientist). We are already seeing the emergence of the CDO (Chief Data Officer) whose skillset will become more and more entrenched in helping people make decisions on data coming from sensor feeds and the management of IOT in organisations.
Even my kids know about IOT and sensor technology. My eldest daughter, an ardent follower of fashion, running her own shop, mentioned to me that she was really into reading up and working on opportunities concerning nano-technology in clothes, as she thought it definitely the future. I thought that nano-technology in clothes was a myth; that it simply didn’t exist (showing my age I suspect) – but I was astonished to find on IET an article talking about just that, even to the point where engineers were busy creating clothes and being designers! Imagine, nano-technology in clothes; that would be able to determine the colour and provide better waterproofing in clothes – wow…. Surely then, we can’t be far away from having our clothes change colour based on the time of year, or maybe even inform how many washing cycles clothes can take before needing repair / replacement? So that means sensor technology in clothes must be a reality…
Anyway, I just had to do more digging. I am sure there are implications from a systems analysis, and service delivery perspective, particularly for data management. I found myself absolutely fascinated by the impact of IOT. From discussing with other techies in this field and more, I was able to put together an article which I’ve had posted to TechNet. Please go read the article here.
I was absolutely delighted to have been part of an exceptional line up at the European SharePoint Conference 2014 this year. The conference took place in Barcelona, Spain from the 5th to the 8th of May 2014 and was Europe’s largest SharePoint event, bringing great sessions and the latest innovations from Vegas. The conference programme included over 110 sessions, keynotes, and tutorials, including topics covering the latest news from SPC14 including what’s new with SharePoint 2013 SP1 – Office Graph/Oslo – new Office 365 REST APIs – Access Apps – Cloud Business Apps.
I conducted a session on “Ten Steps to Creating a SharePoint Support Model” aimed at Business Decisions Markers and End Users – description follows:
“There is nothing like a smoothly running SharePoint support environment but is that possible? In creating a great support SharePoint environment helps foster great user adoption and great SharePoint champions. This presentation attempts to show a strategic approach where the questions to be answered on how to build a true support model for SharePoint be based on “What has to happen, why and where?”, and attempts to describe a basic support model of ten key steps; from knowing what resources make up your SharePoint environment to keeping in contact with customers.”
I had awesome fun conducting the session, and have been inundated with requests for the slide deck – you can download if from here – if you need any other formats please contact me.
Ten Steps To Creating a SharePoint Support Model Slide Deck
Additionally, a resource associated with this session, the 2013 Helpdesk Template, is available for download here:
SharePoint 2013 Helpdesk Template
Enjoy!
Any SharePoint solution has to be usable, by the users and by the support team who addresses those challenges posed by the users, and by those who delivered the solution to ensure that enhancements and modifications can be applied. The solution must be usable, irrespective of what that solution is. For example, there would be no point in building a SharePoint platform unless you followed some design standards (or even had them applied), like service account naming, DNS naming, taxonomy, search topology and more. There would be no point in building a document library which has several global workflow templates assigned unless there was a consistency in development standards, which was defined and applied.
If the solution is usable, the provision of the solution repeatable, it can be supported and scaled with minimal effort, then the solution is deemed successful in terms of its provision.
To understand whether your SharePoint solution is usable, consider these service delivery concerns:
Design Standards
Designing a SharePoint solution is akin to carrying out systems analysis which results in a blueprint of the solution, which is then communicated to the client. Once communicated, the client can agree to the design. The communication can come from a workshop or series of workshops, for example.
The solution is deemed designed when the design layout is acceptable to the client, acceptable based on the resources provided, and acceptable in terms of being provided by those responsible for delivering the solution. Unfortunately, however, there are many instances where design standards are simply not adhered to.
I have witnessed examples of where the design of a SharePoint solution has been completely bypassed. One of the reasons is that there is an assumption that the user will be able to use the solution, without needing to ask what the user actually needs, without needing to document how / why / which / what. Yes, this sounds crazy, but I have witnessed clients faces of amazement when they are told that a new SharePoint site (being the solution delivered) has been built, and to get on with using it, without any mention of the value gained, the benefits that will be delivered, or even the reasons why the solution was created in the first place.
The reasons why this mistake was made could be one or more of the following:
A laissez faire approach to design standards results in a SharePoint solution which will not be useable.
Following a design standard creates consistency that will help your users, and will save you pain and will save money. Additionally, following a design standard actually makes upgrading the SharePoint solution a lot easier.
Following a design standard needs to be done by those delivering the solution and clearly understood by those who will be receiving the solution. A good resource to get further information on this is from “SharePoint Customization Impacting User Adoption”, Chapter 10, in the book “SharePoint 2013 User Adoption and Governance”. This covers deciding when you should and should not customize SharePoint, choosing the correct resources, development options and more.
Development Standards
Once the design of the solution has been agreed upon, the development of the solution can get underway.
Development does not mean “Yaaaay…. Visual Studio! You’re mine now, let’s jump in, slam some CODE”.
Again, based on the usable concepts described in this section, the solution being developed must be usable when delivered, and must continue to be usable until it reaches end of live (the customer is no longer using the solution). That means the solution needs to be stable, easy to maintain, scale with the changes to the platform which it relates to.
Therefore, a ‘dive in’ and ‘gun-hoe’ approach is not going to make a solution ‘usable’ to ensure the solution lifecycle, without a development process being followed.
A development process begins with understanding the limitations of the resources available to develop, both person and tool inventory. The process also includes ensuring that there is a correct fit between the tools being used and the resources being applied.
Amazingly, following a development standard is sometimes not addressed by the over-zealous developer and/or the over-zealous customer who has not been made aware of what is currently available in SharePoint. Examples of this are where developers have been brought in to provide functionality to SharePoint which could have been achieved using out of the box tools and components. Other examples of ‘epic fails’ concerning solutions being provisioned as ‘usable’ include customers who ignore the features of SharePoint and request third party tools be bolted on ‘because they look nice’ and spending far too much money and resources on ‘look and feel’, instead of functionality of provisioned solutions (and the process). Other examples include developers who are unclear of the aspects of SharePoint that should and should not be targeted for customization; this being due to those developers not aware of the resources available.
So, to correct this issue, the first standard needs to identify what resources are available which then defines the tools that will be used to develop the solution.
And, even if the above has been done there are plenty of things to consider to ensure that a standard is being applied when actually considering or doing development in SharePoint, irrespective of whether the development is based on using built in features, custom coding using the API, web service development, Javascript, jQuery etc. Thank goodness that Richard Harbridge has provided a great resource that identifies development standards here which I strongly suggest you read and digest: http://www.rharbridge.com/?page_id=259
Final point in this section, if you are new to development standards from a higher level and wish to know more about how management is applied to these standards check out the following:
Commonality
In order to build a usable environment the need to create a design based on the same methods used before is important. There is little benefit in choosing a different method to build a solution, if the solution will be planted into the same environment.
An example of this is having a garden where you need to plant two trees upon request from your partner who gave you the trees. You locate a spot, then dig a hole, put the tree in the hole, fill in the hole and water the tree. That’s it. No rocket science needed. Ok, so there will be a need to water the tree after, choose the right spade, etc. However, the process is a common one in terms of planting anything in the garden, whether it is a tree, a flower, or a scrub.
Now imagine if you will, having to plant the second tree, but instead of digging the hole, you simply throw the tree onto the spot, then water the tree. By not using the common method, a number of things will occur:
Let address this from a SharePoint perspective. Imagine that you have developed a collaborative site in an organization for a department of ten people. The site has a graphic on the right, the quick launch bar on the left, a calendar in the centre, and an announcements list at the top. Assume that a new site needs to be provided for another department in the same organization. Some of the users of the new site already access the current site. Do you:
Going back to the analogy of the tree, the site will either (a) not be used (b) the users will get frustrated because it does not look and feel the same from site to site (c) the site will have a lot of features but not meet the actual requirements (i.e. that it is simply a SharePoint site).
So, by providing a common approach in all aspects of SharePoint solution delivery is a key aspect of ensuring the solution is usable, from the design, to the build to the deployment of the solution. This is not just from a UX design perspective, but also from even the requirements gathering of the solution in the first place.
Consistency
The consistency in the approach used to provision a SharePoint solution is another important aspect in ensuring that the SharePoint solution is usable.
For example, take a SharePoint site which has a piece of Javascript in place embedded in a Content Editor Webpart. The person who put that Javascript has since left the company. There is no documentation concerning how the Javascript operates. Another person decides to modify the Javascript, finds they lack the knowledge and instead downloads another piece of JQuery. Meanwhile, unknown to them, that same Content Editor Webpart with the original Javascript is in use elsewhere. Then, later, someone downloads a SharePoint app which supersedes the need for the content editor Webpart.
Let’s take another example. Your client wishes to have another SharePoint farm in addition to the current in place. The original documentation concerning the design, build and deployment of the current SharePoint farm is used as a basis to provision the new SharePoint farm.
Now, take a look between the two examples above. Clearly, the second shows more consistency and at least an approach. Why is this? Is it because there was documentation? No. It is because there is an approach already in place which IS documented. The good thing about that is that the solution provisioned in the second example is usable straight away, simply because the approach will to a large degree take into consideration all the other aspects of service delivery; is the solution supportable, can the provision be repeated, is it usable, can it be scaled.
Tools
A distinct aspect of a solution being usable are the tools used within the construction process. However, we will need to be clear on what we mean by tools when talking about a SharePoint solution. That is because SharePoint includes tools which can be combined to create a solution.
In particular, take SharePoint 2013 with the terminology ‘App’ being applied to repositories (commonly known as document libraries and lists). So App is short for application, meaning that the document library is in fact a configurable aspect that can make up the solution. On the other hand, a tool could be the use of a programming tool like say Microsoft Visual Studio, or even a third party tool deployed into SharePoint, like a workflow tool, or a form building tool, or even a digital signing tool (ad infinitum). Irrespective of the tool used to create the solution, care needs to be taken that the right tool is selected, and that training, support and adoption is factored into the choice of those tools. This is because there is a danger that in order to produce the solution that meets all the business requirements that a complex web of products needs to be employed which in itself requires a host of tools to help configure the solution.
Delivery actions
To recap, all solutions created for the purpose of being used in SharePoint must be usable, repeatable, supportable and extensible. In this section, I’ll give you the implementation, consumption and administration tasks that will need to be carried out to ensure that the service solution being delivered is ‘usable’. Usable Implementation deals with ensuring that the way the solution is going to provisioned follows a known standard which can be managed, and that the deployment for any solution can be repeated.
Implementation
Consumption
People are required to ensure that a solution is deemed ‘usable’. If you consider that when you have provided a something in SharePoint designed to improve the productivity of the users involved, that you have already addressed an element of what is considered for the solution to be ‘usable’. So, you will need to know what audiences are involved, since at the very least they influence the usability of the solution provided.
Administration
This article is part of Delivering SharePoint Solutions – Areas of Importance.
A challenge that SharePoint organisations have who are actively involved in the creation, then management, of SharePoint solutions, is then applying a process of delivering those solutions, and then using the same defined process. And note, we are not talking complex or simple SharePoint solutions, these solutions could be as simple as configuring a SharePoint site with repositories to provide a records management experience, or to provide a method of filling in on-line forms, or a business automation solution utilising workflow templates, or even taking on a third party app in a SharePoint 2013 online site, etc.
More often than not, those who do not apply any process involving any kind of systems analysis and design, then through to administration of SharePoint solutions usually end in disaster because:
Some customers when quizzed speak of their alternatives to delivering a solution, and some are nothing short of astonishing – here are some examples – prepare to laugh:
Ok, laugh over… Let us quickly see why alternatives have been addressed which simply do not work. The main reason appears to be that organisations find it difficult to build let alone understand a delivery framework surrounding SharePoint solutions. This may be due to having one person to provide the entire solution start to finish with no proper support, or a lack of skills concerning how to provision a solution (because their background is programming), or even that the current process does not map to SharePoint.
If you happen to work in an organisation where there has been SharePoint solution success; for example, you have been on or lead a team responsible for delivering a SharePoint comprising of a number of tools and services, you will be in no doubt that the following areas would have been addressed:
Conversely, you may have been in a situation where there was deployed a SharePoint solution which had failed because it had not addressed the above.
Am going to try to help out then. I am going to describe four areas which relate to the practical work required around delivering SharePoint solutions – every SharePoint solution being conceived must:
If any one of the above areas is not fulfilled then the adoption of that solution will fail.
For each of the four areas I will describe some actions that you should consider. The topics will be written in a way that is SharePoint version agnostic and generic and can be applied to your organization.
At the end of each section will be a Deliver Actions section which will show three areas of concern related to the topic:
Please note though, describing these areas is not easy. I have even have difficulty amongst other solution architects in explaining the concepts, because of statements of SharePoint service delivery which is all over this article, and the fact that the areas covered in this article may touch all parts in an organization, which therefore increases complexity. So, to those new to SharePoint Service Delivery, as well as reading the guides, I suggest that you:
The areas being described are separate articles as follows – please read them (when they are available) and they will be listed and categorised on the site (when they are available):
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:
| Tool | Provider | Purpose |
| Cardiolog | Intlock | Web Analytics |
| Cosign | ARX | Digital Signatures |
| ControlPoint | Metalogix (was Axceler) | Administration (governance) |
| Nintex Workflow | Nintex | Workflow Process automation |
| PDFShareForms | PDF Share Forms LLC | PDF Forms Design |
| Quick Apps for SharePoint | Quest | Rapid application development |
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.
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:
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:
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!
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
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:
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.
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.
SharePoint Service Level Agreement Guide
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!
Microsoft have provided a great video clip explaining what SharePoint is. I think it is a really good advert for SharePoint, but at the same time, helps you demonstrate the collaboration features that enables SharePoint to solve information and collaborative challenges.
No, security is not all about a Dalek yelling ‘Exterminate’ if you don’t follow rules concerning access to information 🙂 Access to information can be controlled at many different levels within Sharepoint. The question of where best to implement control of user access is answered only with an understanding of available options and requirements. As part of training those who need to manage security on the sites, even if they themselves do not set the security permissions, it is a very important that you communicate a policy concerning when and where to apply site security.
One of the most difficult areas of delivering a SharePoint solution is identifying not just who should be targetted for User Adoption, but, going forward, how to sustain that User Adoption through communication. Reasons include rapid changes in the business culture, direction, and changes in technology concerning the methods used to communicate (e.g. business process changes from manual to email notification to automation, etc.). Moreover, if you have developed a customer list for Service Delivery purposes (e.g. support, user adoption, training, governance, etc.) then you will need to keep tabs on customer culture, communication technology and apply communication tactics and strategies.
Take control of user adoption and governance processes in your next SharePoint 2013 deployment—whether it’s a specific site or complete farm solution. In this book, you’ll learn proven techniques and methods that will help you better manage the entire project lifecycle concerning SharePoint implementation from a practical standpoint.
Discover how to:
Go here to get the book and find out more information.
I have created a basic SharePoint 2013 helpdesk template which you can try out, modify and apply as a helper to their SharePoint support desks. The reason for supplying this is to (a) give an understanding of the ability of SharePoint to provide basic helpdesk functionality using built in features and (b) to introduce you to the concept of centralising a helpdesk in a ‘one stop shop site’ concept. Please note, I am not providing this as a suggestion that you drop any helpdesk product you are using – this is not supposed to in anyway detract you from using that!!
SharePoint Service Delivery concerns itself with capability, and the methods used to ensure that the clients SharePoint vision and goals align with the users, and includes focusing how those responsible for managing the platform (the technical teams) fit and provide that service through guiding principles. These, if followed will ensure that your SharePoint environment can be managed in a structured and measured way.
I’m speaking at the European SharePoint Conference 2013 and I’m delighted to be a part of this fantastic gathering of the SharePoint Community, Feb 4-7 2013, in Copenhagen, Denmark. I will also be conducted a session on “Ten Steps to Creating a SharePoint Support Model” aimed at Business Decision Makers and End Users.
Ten Steps to Creating a SharePoint Support Model
There is nothing like a smoothly running SharePoint support environment – but is that possible? In creating a great support SharePoint environment helps foster great user adoption and great SharePoint champions. This presentation attempts to show a strategic approach where the questions to be answered on how to build a true support model for SharePoint be based on ‘What has to happen, why and where’?, and attempts to describe a basic support model of ten key steps; from knowing what resources make up your SharePoint environment to keeping in contact with customers
I am speaking alongside renowned experts on SharePoint as well as sharing the stage with some of Microsoft’s product team from Redmond covering Search, Apps, Social, Cloud, Project, Migration & Upgrade, Governance and much more.
With over 110 SharePoint sessions, keynotes, hands on labs, SharePoint Shootouts, ask the experts, community lounge, tutorials, Europe’s largest SharePoint focused expo, SharePints, parties, meetings, networking events, competitions and more…. this is a MUST attend event for all SharePoint enthusiasts! Check out the full Conference Programme to see all sessions and topics that are being covered by myself and many others.
Prices start as low as €995! There is also special group discounts for bookings of 3 or more people. Book Now and I’ll see you in Copenhagen this February.
Not a hardware, software, or people resource solution. It is an organizational strategy and methodology for documenting and implementing business rules and controls related to your client’s data. It brings cross-functional teams together to identify data issues impacting the company or organization.
M365 Security and Compliance |
 |
 |
 |
 |
 |
 |
 |
 |
 |
