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:

• The level of support provided is inadequate to the solution can be scaled
  
• The deployment process has not been followed, for example, in an ‘on-premise land’, ‘let’s build the lot on production…’
  
• It’s easier to start building the solution virtually identical to one already in use, than working from the design of another likewise solution, because it is not possible to locate the design for the existing solution.
  
• Solution ABC is nothing like another solution whose focus is virtually identical and has been built from scratch
  

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:

1. Get a third party organisation to put the solution in for us because we do not have the time to follow any delivery process – but we want to control everything and be able to support it ourselves
   
2. Build a delivery process, show that there is such a process in place,  but don’t actually follow the process
   
3. Let’s simply get on with it, build the lot in a ‘fly by night’ fashion, we will deal with all the issues as they arise
   

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:

• Service Testing
  
• Deployment
  
• Versions
  
• Support
  

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:

1. Be Usable
   
2. Be Repeatable
   
3. Be Supportable
   
4. Be Extensible
   

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:

1. Implementation – what actions needs to be done to ensure that the relevant framework section is in place.
   
2. Consumption – what resources will benefit from the relevant section and what resources should be used to help place the framework section.
   
3. Administration – How you will ensure that the service delivery model relevant to the section includes an element of management. This will ensure the sustainability of the relevant section.
   

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:

• Get help. Seek a SharePoint solutions architect to help you meld the service framework to match your organisation resources.
  

• Ensure that to back up the SharePoint framework that you have / using a methodology that allows the framework to connect to, that also allows a logical and structured approach. 

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):

• What makes a ‘Usable’ SharePoint Solution
  
• What makes a ‘Repeatable’ SharePoint Solution Delivery Process
  
• Defining a ‘Supportable’ SharePoint Solution (TBA)
  
• What makes an ‘Extensible’ SharePoint Solution (TBA)