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:

1. Design Standards. The process by which the solution is designed impacts on its usability
   
2. Development Standards. The process by which the solution is developed impacts on how extensible it will be and how effective the support
   
3. Commonality. The look and feel, the components used whether they are SharePoint, third Party integrated, or a combination
   
4. Consistency. The expected outcomes impacts on how the users learn about how the solution works
   
5. Tools. Choosing the tools necessary to design and build the solution impacts on the support available
   
6. Cross platform and environment concerns. This is related to all of the above points. For example, what happens if you have more than one SharePoint environment to deliver to? What security constraints are there? Are there dependant systems involved?
   

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:

• Those responsible for delivering the solution did not follow any systems analysis and design – instead, they jumped in and built the solution ad-hoc
  
• Those responsible for receiving the solution were not concerned of the lack of systems analysis, in other words, were happy to just ‘get’ the solution, even if it was built ad-hoc
  
• Design standards are seen as something that takes people a lot to learn, ties them down, and does not offer flexibility
  

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.

• If the requirement can be met using SharePoint built in features then build the solution and integrate into the inventory
  
• If the requirement can be met using an existing solution in the current inventory that the organization has and that existing solution can be applied then requisition that solution from the library, configure then integrate into the inventory
  
• If the requirement can be met using a third party package or application then obtain, configure and add it into the inventory
  
• If the requirement can be met by customization through development then author the solution and add it into the inventory
  

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:

• 15288 ISO/IEC 15288 Systems and Software Engineering; establishes a common framework for describing the lifecycle of systems created by humans. It defines a set of processes and associated terminology.
  
• ISO 12207 ISO/IEC 12207:2008 Software Life Cycle Processes. ISO/IEC 12207:2008 establishes a common framework for software lifecycle processes, with well-defined terminology, that can be referenced by the software industry. It contains processes, activities, and tasks that are to be applied during the acquisition of a software product or service and during the supply, development, operation, maintenance and disposal of software products. Software includes the software portion of firmware.
  

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:

• The tree will die
  
• Your partner will be very angry
  
• A lot of weeds, with probably no tree
  

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:

1. Design the new site so that it has the elements of the current site (calendar, quick launch bar, announcements etc) applied in the first site is applied to the second OR
   
2. Go for a fresh approach, because you wish to boast of some SharePoint wizzy features
   

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

• Examine the most successful implementation of a SharePoint solution, and then identify the standards used to put it in place.
  
• Ensure there is a bank of tools available which are documented in terms of what they should be used for, including examples and an inventory of solutions which have been constructed using the tools
  
• Document policies which describes the software development policy which stipulates the process under which solutions will be system analysed, designed, constructed, released, supported and maintained going forward.
  

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.

• IT Support
  
• Software Developers
  
• SharePoint Architects
  
• SharePoint Support
  

Administration

• Build a SharePoint site for each of the third party products. Use that site to house solutions created using those third party products
  
• Build a repository to hold source code
  
• Identify valid sources of libraries which hold validated tools
  
• Record key resolutions to typical problems concerning the use of the available tools.
  

This article is part of Delivering SharePoint Solutions – Areas of Importance.