Oooo… Things are gaining ground in the SharePoint 2016 arena. A fantastic set of links to resources, concerning planning, setup, operations, upgrading and lot more is available on the TechNet site.
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!
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.
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):
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!
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.
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.
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.
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.
Excerp: “For those entrenched in trying to get information workers to buy into using SharePoint, SharePoint User Adoption seems to be a black art. In a way, it is because the kind of enticements and methods you use will be relative to the product that is being supplied. In reality, complexity of User Adoption is based on the breadth of the SharePoint solution being implemented.
This article shows the different types of people there are in terms of the User Adoption (which has a lifecycle), and attempts to identify the related high priority areas where you should focus your communication and training programmes. Note. The kind of users involved are ‘generic’; and therefore you should use this as a model for any SharePoint solution – irrespective of version. The key areas of SharePoint I will focus on relate to Information Architecture, Term Store, Search and User Profiles and in SharePoint 2013”.
The article I wrote for MSDN newsletter is located here:
As part of my book, SharePoint 2013 User Adoption Planning and Governance, below is a SharePoint Delivery Detail Plan. This plan encompasses the tasks required to deliver a SharePoint solution from Envision through to User Adoption.
Am working on my forthcoming book concerning the delivery of user adoption and platform governance, and thought that I would share a summarised section which concerns the creation of SharePoint support. a crucial area that relates to how SharePoint services will be managed.
Nb. Am also working on an article which goes into further detail looking at SharePoint support and what are the necessary items to put in place to guarantee success (rather like my Ten Steps for SharePoint implementation article :D). This will be available soon…
Please read on though – hope the summary is useful!
From a planning perspective, what are the very basic areas that one needs to think of when going down the route of creating a SharePoint solution, whether its a site, or farm, or even a workflow solution. I have attempted to answer this by building a presentation key covering planning, adoption, supporting, delivery from a high level.
Located some great guides whose goal is to assist the reader through the process of planning a SharePoint Server 2010 infrastructure by addressing the following:
Step 1: Identify the Requirements
Step 2: Apply the IT Policies
Step 3: Define the High-Level Architecture
Step 4: Design the Web Server Infrastructure
Step 5: Design the Application Server Infrastructure
Step 6: Design the SQL Server® Infrastructure
Step 7: Identify the Optimization Opportunities
These guides are available for download. The first guide takes the architect through an easy-to-follow planning and design process to successfully create a SharePoint Server infrastructure that is appropriately placed, sized, and designed to deliver the desired business benefits, while also considering the performance, capacity, and fault tolerance of the system.
For more information go here: http://technet.microsoft.com/library/gg581794.aspx
This guide provides a clear comparison of SharePoint collaboration technologies across on-premises, standard hosting, and dedicated hosting scenarios. The guide can be used as a framework for evaluating the technical feasibility of Microsoft SharePoint Online and determining which SharePoint delivery model best suits the organization’s needs.
For more information go here: http://technet.microsoft.com/library/ee354215.aspx
Am building a presentation summarising these guides for a future blog coming soon!
There’s plenty of technical articles discussing what tool to use, what commands to use, what products to use and more in the face of migrating one or more SharePoint environments from 2007 to 2010. However, this article describes the process that a SharePoint Architect would need to define with the SharePoint Administrator to ensure there is a plan which covers:
Welcome to the third and final part of my Value Management article concerning how to define and apply a model for solution architecture in SharePoint.
(more…)
People have been requesting me do a shortened article to cover SharePoint Implementation from a higher level; a kind of whats my the key steps required to deliver SharePoint to a client. Please note there’s a whole bunch of webcasts coming soon to go into some more detail on each of the steps, so watch this space. If you need further information go ahead and give me a shout! Happy Reading!
Time for a service delivery article, looking at working with external SharePoint agencies in a SharePoint environment in BAU…
If you are operating and managing SharePoint environments for your clients, you may find that there is a business requirement for enhancements or modifications to something to take place which would alter your controlled SharePoint environment. This business requirement may be one where there is a call for the intended work to be carried out by utilising services from an external ‘SharePoint’ on a sub-contracted basis.
History has a way of repeating itself. Thankfully, when we learn from the mistakes of the past, we are able to address new challenges more quickly and in smarter ways. In the early 1990s, email emerged as a collaboration mechanism, speeding up communications between multiple parties.
