This quick article is going to explain the basis of Microsoft Office Systems Service Delivery (centered a little on SharePoint, ahem) and why it is so important to have in your organization. Also, check out my book (on this link) which covers a lot more on this topic.
This article, split into three blogs, goes into detail on describing Managing Value for SharePoint, and the basis of the two key tools to Managing Value. To help you understand the concepts, I will be drawing on real life projects and showing how using the techniques described was able to determine the best solution.
This is the second part of the article concerning the delivery of SharePoint solutions. I will start by recapping on why I have produced these set of free articles, which will combine into an e-Book soon, check out this article. In essence, a successful solution delivery process encapsulates a design, creation, provision and support framework – that’s what makes up a SharePoint solution.
As stated in the first article, I am not designing a new process, rather, giving ideas surrounding theory, and actions for the reader to use.
The first article in the series, first looked into the understanding of creating a Usable SharePoint solution. A usable SharePoint solution takes into consideration the service standards applicable like design, development, commonality, consistency, tools and cross platform standards that can be applied when working with SharePoint. In learning the standards relating to usability, repeatability, supportability and extensibility you will be able to continually provision solutions easily, slicker and also help the client learn how to manage the solution once handed over.
A danger in writing these kind of articles is that the reader may be fooled into assuming that this is a business article, and somehow, not related to anything technical in SharePoint. In fact, service delivery is combination of the two – known as Systems Analysis which has been around as long as software has!
This is the second article in the series, concentrating on the key aspect of providing a sustainable solution – repeatability. In essence, this is the use of common processes, components, and products to build SharePoint solutions; continually – meaning using a repeatable method. Before thinking ‘this isn’t for me’ – wrong. As a SharePoint worker, you will be using a ‘repeatable’ process when even the simplest of SharePoint site solutions. For example, a document template re-use is defined as using a repeatable process. A web service that provides solutions such as say copying files from one place to another can be set to carry out the same process on another source and destination with minor customisation. Even a SharePoint site carrying a common structure can be easily created using a template, such as a Team Site Template. Apps are ‘repeatable’. Other examples could include workflows which are re-purposed, like Approval workflows.
The challenge is that most people, faced with constructing a SharePoint solution using components do not understand the principle of re-use which is a key aspect of a repeatable SharePoint solution delivery process. They may understand that something such as a template can be used again and again of course; however, they do not understand why a process ensuring why and when that a re-use management process can be applied; from the lowest component, to sites, site collections, web applications or farms. Even the provision of an Office365 tenant to a client is defined as a repeatable process. If there is no understanding, even a laissez faire approach, no standard or structure applied. And, as time marches on, as components morph, change and multiply, the potential for chaos ensues, where people simply have no idea what component should be used for what solution – instead, a patchwork of ‘guessing’ takes place!
Time I think to put a spin on helping you understand the principles of a ‘repeatable’ SharePoint solution. Again, this is a really challenging article to write, but an enjoyable one as well (like all my articles!).
First, time to get back to basics. Am going to start this section with a strange analogy – IKEA tables.
I went to IKEA Edinburgh last week looking for tables. My partner wanted some new tables to brighten up the conservatory, the kitchen and the cinema room. Now, browsing around IKEA for tables (well in fact anything in IKEA as I am not a great shopper) can be a bit of an experience, and sometimes, an annoyance. Trying the find the right colour, size took a huge wedge of the day to find what would look right.
So, in the end after hunting for tables in IKEA, we decided on three tables, put them into the horsebox and drove back home with them. Once home, I spent the following day putting the tables together. The first attempt at building a table was a nightmare. Yes, the instructions are easy to follow, but unfortunately I am not that great in following IKEA instructions; I dove in blindly with the screwdriver – then once I started getting things wrong, I went to the manual. It took me over 3 hours to build the table. Finally, I managed to put the first table together. Then, onto the second table. This was easier to put together, simply because I remembered all the wrong things I did about the first, and because I followed the manual :). The third was such a blur of activity – I simply didn’t need the manual, and I placed all the components in the order of building – the time taken to build was a fraction of the time to build the first.
Of course, stating that building tables is not a great and wonderful idea of delivering SharePoint solutions using repeatable exercises. But it is a great analogy because of two key reasons:
That means this two simple reasons can easily be applied to SharePoint to ensure a repeatable process. Surely it is easier to put a SharePoint site solution together if there are common components that can be reused at will? Surely, if there is a documented process that aids the creation of the SharePoint solution which utilises those common components, then that defines a repeatable method of creating those solutions. However, the concepts I have mentioned are unfortunately not carried out, or is a challenge to understand how to put them in place – and this is because the capabilities that describe how a SharePoint solution can be made ‘efficient’, through its delivery process is not at hand. I am going to attempt to address that, by describing the key capabilities that make the SharePoint solution efficient in terms of its development, deployment and maintenance.
The capabilities that you should consider, which in my view help you create a SharePoint solution (requiring the roles of Systems Analysis, Development, Architecture and Administration) and by definition can help build a ‘repeatable’ framework are:
Service Delivery
Service delivery of the relevant solution needs to be efficient. This means being understood and managed by the stakeholders, since they are responsible for managing / devolving the management of the solution going forward.
For Service Delivery to be efficient, the solution delivery mechanism needs to be carried out in a sequenced and logical approach that the customer will understand and be part of. For example, if SharePoint is going to be employed in an organisation, the client needs to understand the part that SharePoint is going to play. This means understanding the information framework, and applying that, including controls for managing and locating that information. The fact that SharePoint is going to be used is irrelevant at that stage, since through the evaluation of the information flow in the organisation, the tools being used, the culture of the organization, amongst other key issues like control, security will influence the platform being employed.
So, a service delivery mechanism which encapsulates vision, decision, design, build, support, sustain, control needs to be defined first. A key outcome of creating a service delivery mechanism provides the stakeholder with the knowledge and comfort that an understood process (which they will manage) is clear and can be adhered to.
This means providing a number of service blocks that can be provided whenever releasing a SharePoint service. Examples of this are:
Efficient Service Deployment
There is confusion on the terminology surrounding the term ‘Service Deployment’. It seems that it is a technological term, and therefore, something related to getting some software from somewhere and installing it. I have witnessed situations where someone says ‘We are going to deploy the software service by following the installation process given in the manual’. In other words, download the product from somewhere and follow the automated installation process by clicking ‘Setup.exe’….
No.
Service Deployment is the process under which the SharePoint solution is deployed from a full implementation perspective and involves all resources necessary for that to take place. That means including people. That is the first simple rule. Keep the users involved.
Example. An app has been sanctioned to be deployed to a SharePoint online team site. The procedure that was followed to get the product sanctioned is a tried and tested method of user requirements, testing, user acceptance.
Efficient Service Deployment is part of a Software Delivery Process. A process by which the deployment of the solution is simply part of its lifecycle. That lifecycle includes the design, build, maintenance, support and any other aspect that defines the solution.
Henceforth, knowing what makes up the SharePoint solution is vital since that naturally produces the information required to ensure that the solution can be deployed. There are a number of documents which should be created:
Capability
Because the people must be capable in using the delivered SharePoint solution. Therefore, the solution must be capable in enabling and enhancing business productivity, knowledge, and solving information and management collaboration challenges.
So, in order to repeat the process of creating successful SharePoint solutions, the capability (structure, roles) of the support service team responsible for designing, crafting and, deploying and most likely supporting the solution must be repeatable from solution to solution.
This means that:
Scalability
Scenario: You are going to deliver a SharePoint platform to a client. You gather their information requirements and process. You provision a ‘Proof of Concept’ SharePoint platform open to key stakeholders to showcase, demo, and gather further requirements. The client wants SharePoint. From there, you provision a UAT (User Acceptance Test) environment which maps to their requirements in terms of infrastructure, availability, scalability, extensibility, support. You then open that up to key stakeholders. Workshops ensue. The client still wants SharePoint, the UAT environment provided appears to meet functional and system requirements. You then provision a Production environment which matches the infrastructure provided at UAT level, and then deploy SharePoint services to the client as prescribed in UAT.
The above is a simplistic approach concerning the delivery of SharePoint to a client, following a design, build, deploy process. A repeatable SharePoint Service Delivery mechanism focusing on implementation.
However, the point being made about the scenario given about is a word which encompasses the delivery – future-proofing. ‘Future-proofing’, means that the solution being provided will not only meet the client requirements at the point of inception, but can also in the future because it can be scaled, and therefore will continue to meet changing requirements.
Scaling a SharePoint platform and any relevant solutions is not a single event exercise. Any alteration, addition or deletion to the solutions provided within the SharePoint platform requires a review to determine the impact on the scalability of SharePoint. For example, take the addition of a third party app to SharePoint, which becomes important, an app which the users cannot do without. The impact to the scalability of SharePoint comes into question if, for example, that app cannot itself scale to the next ‘hotfix’ of SharePoint, let alone the next version of SharePoint!
Actions
A lifecycle of delivering SharePoint solution needs to be based on being repeatable. Reasons for doing this have been stressed in this section, but to summarise:
In the Scalability section above, I gave a simple scenario based on deployment of SharePoint and boiled this into a repeatable solution exercise. That’s not the only scenario that uses Repeatable as a method to service deliver SharePoint solutions. SharePoint provides virtually all the components and tools that allows components to be configured, connected and scaled. SharePoint provides the ability for modules of functionality, developed internally or externally to the organization and contained in Apps. Apps that can be re-deployed, and further enhanced based on changing needs of the client, and can be deployed centrally from a bank of other Apps. For example, a simple document library App may alter need the ability to be connected to a third party tool, or may require further enhancement concerning views and sort, or may be required to lookup information from another repository. When completed, the entire configuration of the document library can be transformed into an ‘App’ which can then be redeployed elsewhere without having to re-develop from scratch. Other Apps include Site Apps, and Third Party Apps.
Third Party Apps throw a different kind of repeatable solution scenario because of the added dimension in providing automation, which then leads to the ‘Supportable’ element of the SharePoint Service Framework. This is simply due to the fact that Third Party Apps cannot be successful unless there is a support group. The sheer number of Apps available from the Office Store for SharePoint compounds scenarios concerning re-use, consumption, implementation and administration.
As per all things when implementing a solution in SharePoint, the answer to solving business and information challenges requires you to continually and critically review the requirements to find nuggets of functionality that has already been created. Analyse thoroughly the various elements of the SharePoint solution, so you can identify common areas that can be defined generically and as repeatable components. Harvest them into deliverable chunks and rework to see if they can be repeated. Remember the DEV to UAT to Production model – this applies to any kind of solution (design, develop, test, make it live).
If this sounds a little convoluted, remember the client perspective. Generally, they will not care what the resolution is made up from, is as long as it works – however, they will care, if the solution is usable, whether the solution once implementation can be repeated to meet a likewise requirement elsewhere without having to pay extra, whether the solution can be supported and whether the solution can be extended as the SharePoint platform scales.
Before going onto the relevant actions concerning what you need to implement, how the customers can consume, and how you can administer a SharePoint solution that can be repeated, check out these articles which all have a bearing on this section.
In conclusion to this article, which I will continually come back to update, you should also consider the three actions that you should consider in building a ‘repeatable’ SharePoint solution framework – Implementation, Consumption and Administration.
· Implementation
· Consumption
· Administration
This article is part of Delivering SharePoint Solutions – Areas of Importance.
Hi there folks!
Sometime ago I created a quick ten step guide and had it published on TechNet – amazed to find so much interest, and great comments! ShareGate contacted me and asked if they could turn it into an info-graphic (which looks great); now available on their site and is displayed below – enjoy!
Getting hands on deployment information concerning SharePoint 2013 can be a challenge. Managed to locate this guide which is created by Microsoft detailing the process! This is available from the Knowledge Base so check that out for more guides as they come in. Also, check out the Ten Steps paper on the planning and implementation to get a complete picture..
I have often been asked; “Hey Geoff, what points do I need to take into consideration whilst creating a SharePoint platform service”?
Configuration Management is the answer – “the combination of technical documentation, product pack information, user rules, continuity planning; – which helps create platform policies, platform change management rules and helps sustain the platform in its lifecycle”.
In ‘creating’ a SharePoint platform service, and I am purposefully ignoring high level ‘so called’ business points, no-one in the right mind would stick a SharePoint install DVD, or mount a SharePoint install image, click Next, Next and Next again, enter some configuration details without recording anything (using the ‘It’s Easy so why do I need to write anything down’ excuse), and then announce to the client “Eureka! I have given you a SharePoint platform – I declare that it has been successfully implemented!” (and real-world I have actually witnessed this).
SharePoint configuration management is the answer. Why? Because decisions concerning the implementation need to be recorded, as it is likely that the implementation configuration of SharePoint will change, or referred to, or added to in its lifecycle. So that means, you need to have a reference to each of these points in at the very least your Detail Level Plan for your SharePoint platform. Those should be then referred to in associated user policy documents as necessary.
So, here’s my take: (Note – most of these are technical checklist items, for the business side, see the user requirements checklist. Additionally, this refers to SharePoint 2007, 2010 and 2013 so examine each point as necessary and apply it to your version of SharePoint).
Governance and Culture Planning Points
Naming Conventions
Extranet and Security Planning Needs
Search and Indexing Planning Issues
Disaster Recovery Planning
Staffing Needs
Personalisation
Document Library Planning Issues
SharePoint Capacity Planning, Reporting and Monitoring
Plan site quota templates
Branding and Consistency
Criteria for creating a web application
Additionally, you should take a look at this:
User Requirements Checklist – this is a further set of areas that you will need to address which when completed gives you a better idea on user requirements. In my book – Managing and Implementing SharePoint 2010 Projects (which applies to SharePoint 2013 as well), I went into much more detail about these including a process to capture the results from each of the decision points (Chapters 4, 10, 11 and 12).
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.
Microsoft has today released the Office 365 for business public roadmap. The Office 365 for business public roadmap provides customers with a way to learn more about upcoming change and updates before the change impacts their service.
Go here to see the Office365 for Business Public Roadmap
The public roadmap will be closely coupled with the larger Office 365 Change Management strategy, including integration with Message Centre and the Office 365 direct to admin communication channel.
This is an extremely important and very useful service delivery mechanism to ensure you know what services will affect Office 365 customers – the roadmap page is split into sections allowing you to see what features are launched, rolling out, in development and cancelled.
Another very important read is the Improving visibility to service updates blog which gives more information concerning the concepts behind the Office 365 for business public roadmap.
The Office 365 for business public roadmap is a web page on Office.com that provides customers with a list of new and updated features being released to the Office 365 service. The website will list recently launched features, features still rolling out, and features that are still in development. The website will launch with a monthly update cadence.
Note that the public roadmap does NOT commit Microsoft to specific timelines for delivering service updates. It follows a set of policies for what should and should not be included based on when an update is expected to being rolling out and previous disclosure of a particular update. The content goes through a quality assurance pass bi-monthly as part of previous NDA roadmap activities.
As both engineering and marketing move to a services operating model, Microsoft are changing the way they approach customer communications. Part of this transformation is going directly to customers and scaling communications to every Office 365 customer from the individual business owner with 1 employee to the largest enterprise or governmental organization with hundreds of thousands of users.
From examining customer data it has been seen that customers expect a “service” to behave like other services in their life, such as cable or mobile phone subscriptions. They expect notification and communication about any changes to their service. PSAT data, focus groups, and OneList items all show the high cost in the old operating model that erodes customers’ trust and confidence in Office 365.
Microsoft will be listening closely to customer, partner, and field feedback for improvements that fit within policy guidelines. Improvements currently being evaluated include localization into tier 1 languages, notification or tracking capabilities for the site change log, and expanding to include out-of-scope Office 365 instances. They will continue to refine the update tracking process and use the Office Release Roadmap as the single source for data related to service updates.
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):
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.
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
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.
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:
Check out this review on the book:
http://www.bcs.org/content/conWebDoc/51817
Go here to get the book and find out more information.
The following downloads are worksheets designed to help plan aspects of a SharePoint 2010 or a SharePoint 2013 implementation, and at the same time ensure that decisions in the design are captured.So, you should use these in conjunction with the development of the following documents:
1: SharePoint User Requirements – these define SharePoint collaborative environments for the users based on their requirements, and provides a fundamental understanding of interconnected tools and applications the organization uses in conjunction with the platform. SharePoint User Requirements also identify where content should be consolidated, reduce and improve data management; reduce duplication and boost productivity as defined by the clients’ vision of SharePoint.
2: SharePoint System Specification (also known as SharePoint Solution Specification) – expands the User Requirements, Planning and Decisions concerning SharePoint as technical requirements. The system specification is a clear, complete and unambiguous set of documentation, describing the SharePoint for the organization in terms of its function, performance, interfaces and design constraints.
The below is divided as follows:
Where it helps – describes the context and areas of SharePoint design gathering these documents can be used. Note that I have also indicated whether the worksheet is for SharePoint 2010 or SharePoint 2013.
| Area | Link | Plan Type | Where it helps |
| Backup and Recovery | http://go.microsoft.com/fwlink/?LinkID=184385 | Planning SS | SharePoint 2010. Help you plan strategies for backup and recovery. |
| Content deployment | http://go.microsoft.com/fwlink/?LinkID=167835 | Content Deployment SS | SharePoint 2010 / 2013. .Plan the export and import servers in the farms in your content deployment topology, and to plan the content deployment paths and jobs. |
| Document management | http://go.microsoft.com/fwlink/?LinkID=165871 | Stakeholders UR | SharePoint 2010 / 2013. .Identify document management planning stakeholders and record document management practices. |
| Document management | http://go.microsoft.com/fwlink/?LinkID=165873 | Usage UR | SharePoint 2010 / 2013. Record information gathered when analyzing document usage. |
| Document management | http://go.microsoft.com/fwlink/?LinkID=165874 | Document Libraries UR | SharePoint 2010 / 2013. Plan libraries based on sites and on document types. |
| Document management | http://go.microsoft.com/fwlink/?LinkID=165883 | Policy UR | SharePoint 2010 / 2013. Plan information management policies for content types. |
| Managed metadata | http://go.microsoft.com/fwlink/?LinkId=163486 | Term Sets UR | SharePoint 2010 / 2013. Determine basic taxonomy, including term, usage, owner, and group. |
| Managed metadata | http://go.microsoft.com/fwlink/?LinkId=163487 | Term Sets UR | SharePoint 2010 / 2013. .Determine taxonomy including detailed identifying characteristics such as measurements. |
| Managed metadata | http://go.microsoft.com/fwlink/?LinkId=164578 | Managed Metadata Service UR / SS | SharePoint 2010 / 2013. .Plan to share metadata information using managed metadata services and connections. |
| Metadata-based routing and storage planning | http://go.microsoft.com/fwlink/?LinkId=189018&clcid=0x409 | Content Organizer Settings SS | SharePoint 2010 / 2013. .Determine and record how the content organizer settings in your site can be an effective part of your metadata-based content routing and storage solution. |
| Metadata-based routing and storage planning | http://go.microsoft.com/fwlink/?LinkId=189019&clcid=0x409 | Content Organizer Rule SS | SharePoint 2010 / 2013. .Plan rules that will be an effective part of your metadata-based routing and storage solution. |
| Prepare for upgrade | http://go.microsoft.com/fwlink/?LinkId=179928 | Upgrade SS | SharePoint 2010.Record information about your environment while you prepare for upgrade. |
| Records management | http://go.microsoft.com/fwlink/?LinkId=185011 | In Place Records UR | SharePoint 2010.Identify record types and content types to be stored in normal document libraries. |
| Sites and site collections, Navigation, Themes | http://go.microsoft.com/fwlink/?LinkID=167837 | Site UR / SS | SharePoint 2010.Plan top level site collections and sites, and record decisions about site themes and navigation. |
| Backup and Recovery | http://go.microsoft.com/fwlink/p/?LinkId=256660 | Planning SS | SharePoint 2013. Help you plan strategies for backup and recovery. |
| Service Deployment | http://go.microsoft.com/fwlink/p/?LinkId=256658 | Planning SS | SharePoint 2013: Plan for an indicate the services that will run on farm servers |
| Prepare for upgrade | http://go.microsoft.com/fwlink/p/LinkId=256659 | Upgrade SS | SharePoint 2010.Record information about your environment while you prepare for upgrade. |
| e-Discovery | http://go.microsoft.com/fwlink/p/LinkID=254840 | Usage: UR | SharePoint 2013: Record the decisions that you make as you plan to implement eDiscovery in your SharePoint environment, including decisions about eDiscovery Centers and permissions |
| http://go.microsoft.com/fwlink/p/?LinkId=267990 | Planning:SS | SharePoint 2013: Plan for incoming email for your SharePoint farm |
I’m going to add some more documents to aid gathering of information relevant to other areas of SharePoint user requirements and system specification. You should also take a look at my user requirements article – that can help you determine the format of those documents and how the above can link.
In Chapter 4 of my forthcoming book SharePoint 2013 User Adoption Planning and Governance, there is a section titled ‘Collaborative Ownership’; it is my take on the creation of simple rules to manage a SharePoint solution (note – an implementation of a SharePoint environment could be defined as a solution)…
O365 Security and Compliance Information Security News |
 |
 |
 |
 |
 |
 |
 |
 |
 |
