The SharePoint Maturity Model (SMM)

MOSS has been the most successful server product Microsoft ever released. Sales are growing much faster than Microsoft ever expected and apparently the UK is outstripping worldwide growth (for more see this). Unfortunately this quick growth is also highlighting one of the major problems that everyone seems to be struggling with - deployment. I'm a SharePoint consultant and I've been working with MOSS since Beta 2. I've worked across several companies in the UK and I have also debated this issue with other colleagues and we are all in agreement: deployment is the biggest pain on any SharePoint project. It's one of the areas that will give you more problems and cost you more money. What is curious is that all companies adopting SharePoint seem to go through the same evolution path. Finding a way to measure where my customers are on this path gives me a good idea on the challenges that I will be facing when moving their projects forward. The kind of measure that I'm talking about it's called a Maturity Model so I called it the SharePoint Maturity Model (SMM).

Like the Capability Maturity Model (CMM) I divided the SMM is divided into 5 levels (except for level 4, I have used the same names has the CMM because they are a good match):

1. Level 1 – Ad hoc (Chaos): Companies in level one normally do all development directly in the production system. There is no development or system test environment because no one knows how to move the site to a different server. These companies are normally just starting using MOSS and they do not have experienced MOSS resources.
   
2. Level 2 – Repeatable (Backup/Restore): Level 2 companies have found that SharePoint content and configuration can be moved across environments using backup and restore. As such they have a repeatable deployment process. Unfortunately these companies soon realise that using backup and restore will cause a series of problems that are not immediately noticeable (like the publishing pages still pointing to page layouts on the old environment or exceptions being raised when trying to edit publishing page settings). I was once called to a customer that was having a series of problems with their live environment; it was running too slow with frequent crashes, also they could not understand why the problem seemed to become worse when they turned off their development server (which was on the same network as live). It turned out to be the typical backup\restore syndrome that had to be fixed by copying the content of the publishing pages to new pages created in the live environment (we gave them a small C# script to do that).
   
3. Level 3 – Defined: Companies normally get to level 3 after learning with their mistakes and spending a lot of time and effort going through levels 1 and 2. In level 3 companies have learned that there is a better way to deploy their applications by using CAML in Features, Solution Packages and Site Definitions. Unfortunately there are quite a few configuration artefacts (like security, search, etc) that cannot be deployed via CAML. To overcome this problem companies develop a mixed automated\manual deployment process where some artefacts are deployed via CAML scripts and others by following a long list of manual steps (see Deployment Pete Syndrome below).
   
4. Level 4 – Automated: At this level companies have managed to fully automate their deployment process by using a mixture of CAML and .Net code. This normally comes at great cost because not only developers will need to learn CAML but they will also need to learn the SharePoint API so that they can automate the deployment of configuration artefacts not covered by CAML.
   
5. Level 5 - Optimised: This is the SharePoint deployment Nirvana. At this level companies not only have their deployment process fully optimised and automated but they have also started to manage those processes has shared Intellectual Property (IP) across projects. At the end of every project there is an IP harvesting process that brings any new deployment code into a central location so that it can be reused and shared by future projects. The time required by these companies to setup a new SharePoint project is minimal and quality of their deployment scripts is high because it's based on tested code used several times before.
   

The Deployment Pete Syndrome (DPS):

One of the constant complaints that I seem to find when meeting new customers is about the exceeding amount of time that it takes to move their SharePoint application between environments. Especially when they have been promised -normally by a sales person more interested in hitting their sales target than in providing a fit for purpose solution- that most of their requirements could be accomplished with out-of-the-box (OOB) functionality provided by SharePoint (I'll leave my OOB ramblings for another post). During my first meeting with these customers I'm normally introduced to their deployment expert which, for the purpose of this post, I will call Pete in honour of a great ex-colleague of mine that used to spend a lot of is time deploying SharePoint applications. In further talks with Pete I normally discover that he is given a huge list (sometimes several dozens of pages long) of manual steps that he needs to follow in order to move each SharePoint application between environments. I call this the "Deployment Pete Syndrome" (in lack of a better name) and unfortunately it seems to be a constant of most companies that I go to (especially those in levels 2 and 3 of the SMM).

In my opinion one of the ways to help companies adopting SharePoint and ease the pain of reaching the SMM level 5 (if they wish to do so) is to offer them a mixture of advice and knowledge transfer together with a series of packaged tools that have been designed and developed based on the experience past projects. This is one of the main objectives of a new UK based company called Collaboris (we are still finishing the web site so please bear with us) that I've started together with my colleague Mark Jones.