Part 1 - What is the SharePoint Platform
Part 2 - What capabilities to start with
Part 3 - How to start with the SharePoint Platform
Part 4 - Levels of leveraging the SharePoint Platform
Part 5 - Why use SharePoint as a Development Platform
Part 6 - Lessons learnt from Leveraging the SharePoint Platform

This the third post of a six part series on Leveraging the SharePoint Platform. In the last post I explained some of the great things that can be implemented. In this post I will introduce the Governance, the People and the Approach that needs to surround SharePoint.

I hope from reading the first two parts you are under no illusions on the scale of the SharePoint Platform. With this post I hope to point to some great resources out there both from Microsoft and the awesome SharePoint Community.

The Governance

Microsoft defines Governance as “the set of policies, roles, responsibilities, and processes that you establish in an enterprise to guide, direct, and control how the organization uses technologies to accomplish business goals.”.

You’ll notice from a lot of the references I use in the post are all 2008, the reason I point this out is because the latest version of SharePoint has been out since November 2006 and it has taken this long for Microoft to raise their game and provide assistance in this area. SharePoint could quite easily become the next SAP behemoth platform that people talk about and never witness being rolled out nto Production (apologies for any SAP lovers out there - I’m sure you say the same thing about SharePoint).

There seem to be a collection of sites dotted among the Microsoft network regarding SharePoint Governance:

• Code Plex
• SharePoint GearUp
• TechNet
• Office.Microsoft.Net
• and more from the entire Internet at diigo.com/user/jthake/

Microsoft have published a great SharePoint Governance Checklist Guide that offers a lot of information around the Platform. They also have provided a template Governance Plan that can be used at the initiation of the project.

There’s plenty of information in the links I’ve listed above and rather than me regurgitate it all here I’ll let you read these at your leisure.

The People

This is an area that is covered by the Plans and Checklists that Microsoft provide, but I don’t believe they are realistic. The problem I have had with most engagements I have been involved with or witnessed around me is that SharePoint is treated in isolation to the rest of the Technologies around it. To emphasise this point further, most environments I have been in even have a separate SQL Server instance just for SharePoint Databases rather than leveraging existing server infrastructure due to the uneasy nature of DBAs not knowing what SharePoint does because Microsoft state that you shouldn’t touch the Database Schema in ANY way.

With this isolation also becomes resource islands and the common pattern is that the person/role who installs SharePoint, also becomes the person who supports it and keeps it operational. Now in a perfect World, and in Microsoft Plans and Checklists, this would be divided up into separate resources and transitions would occur at various phases to make up a ‘Tactical Team’.

As I highlighted in my first part in this series, SharePoint spans multiple Tiers, so immediately, you can see there’s a lot of specialists skills required that span multiple Microsoft Technologies which alone have their own sophisticated exams and certifications. Various bloggers out there have tried to define this:

• Sharee English
• Becky Isserman
• Eric Harlan

(Please add more in the comments of this post)

All of these approaches are valid and some take it from the Roles and Responsibilities approach and others take it from the Technical Background. Sharee’s approach in my mind gives the breakdown I have seen naturally evolve in various SharePoint roll outs I’ve witnessed.

The biggest problem I’ve seen with the isolation and break down of personnel is that SharePoint always takes the blame, because although it is in isolation, there are some shared resources because it shares resources such as the underlying network, Exchange, ISA, Backup and Active Directory. Also, it just isn’t a full time role for each isolated tier such as SQL, ForeFront, SMTP and Windows Server.

What do I mean by “taking the blame”…so a User submits a support call to say the Company Intranet is running slowly  (typically they even know it’s SharePoint and say it’s SharePoint running slowly), this immediately points the blame at SharePoint. Looking at the tiers in the diagram you can see that potentially it might be the underlying architecture that is the issue. This will involve various experts getting involved and working as a team to resolve the issue. So many times I’ve had experts in particular areas going “everything is fine” to later find out that their area was the reason, because other experts have invested hours of time proving to the nth degree it isn’t their technology.

This ‘Tactical Team’ would also include Developers who as Microsoft put it:

“Technically talented people both willing and able to customize, personalize, and use SharePoint in a manner that fulfils the business opportunities as identified by the strategy team. This team is a loosely-knit community of developers with varying degrees of proficiency in software development. Members can range from highly skilled programmers to technically savvy end users in charge of personalizing departmental team sites. Skilled developers will handle large change requests, new features, and program management while ensuring adherence to standards.”

This did make me laugh and also made me feel very self important. I’m going to cut and paste this into my Profile for future reference! In all seriousness, I don’t believe that having ‘Developers’ is breaking this role up enough. As mentioned in my personal blog there is more than one way to skin a cat in SharePoint. Most of the approaches set SharePoint Developers apart from each other, these are (and not limited to):

• Web User Interface Developers - everything is done within the User Interface using OOTB Web Parts, JavaScript and done directly into production environment.
• Site Template Developers - slightly more advanced than above, involving packaging up Site Templates that can be reused.
• SharePoint Designer Developers - everything is done from with SharePoint Designer and migrated using Content Deployment API or similar tools.
• Visual Studio Developers - everything is a Solution with Features and Powershell automated build scripts

There’s been quite a bit of discussion on the best approach to actually ’skinning the cat’ and Chris O’Brien has put some great points forward on the table.

I also believe that with these customisations there is some relevance to what was discussed in the last two posts around the SharePoint Capabilities. Most of the SharePoint MVPs have a specialist area within the Platform and may understand the other areas principles but never implemented them. With this in mind I think it is wise to understand the risks of putting a fresh SharePoint Developer onto their first Business Data Catalogue or Enterprise Search project. The current SharePoint certifications really don’t go deep enough into each capability and I’d like to see more specialisation in each of these with a core WSS Development exam.

Project Managers and Development Team Leaders should be aware of the strengths of their SharePoint Developers and try and identify the gaps in their team based on the requirements of the Organisation. This is further confused by the lack of resources in general in the SharePoint market and the push from recruitment firms and misleading CVs with unexperienced Developers. Joel Oleson makes some valid points about this issue which also has a HUGE discussion thread. Microsoft are also trying to combat this problem by encouraging existing ASP.NET developers to get onboard, this site is a great resource for people ramping up on SharePoint.

Basically, if you have one thing to take away from this section, please be aware of the multitudes of Developers out there and what type is going to suit your sized rollout whether bringing them in-house or outsourcing.

The Approach

Joel Oleson is one of the greatest SharePoint Community Members out there in my opinion and has some great posts around this whole area. Way back in October 2007 he announced the MOSS Deployment Plan sample.  Before you open it, bear in mind that this has the kitchen sink of tasks in there, but also keep your eyes open as this project plan has a total of 6452 hours split between 10 different resources. Again this break down doesn’t seem to align with the other Microsoft Plans and Checklists which isn’t going to make this very easy to use without some work.

Again, with all the references I’ve linked to, I just want to highlight two main core approaches to rolling out SharePoint into the Organisation. You have the traditional Waterfall model and the Agile model. The  Agile model attracts a more iterative approach, which works well with SharePoint due to the features you get out of the box and the speed in which you can get things up and running compared to a more traditional project where you are building everything from the ground up (I will discuss this more in the next part in this series).

As with any Requirements Gathering exercise, Business Users think they KNOW what they want from a system, but often need pushing to be able to explain EXACTLY what they WANT and also sometimes need to be RECOMMENDED what they NEED. Erik Swenson does a great job of highlighting some possible decisions that need to be made simply on the User Interface, before you even start getting into functionality requirements of a particular sub system.  My fellow Perth blogger Paul Culmsee also offers some advice with a great sense of humour and bitterness on this.

By following an iterative process, where you deliver in small chunks what a Business User asks for produces more responsive and early feedback. This allows the system to evolve as the Business User sees the interface working for them with their data. These prototypes can then be taken away to give them stability and shelf life to go into production.

This iterative approach does not lend itself well to the Waterfall method where there is a more formalised process up front of: gather requirements; documenting these into a Functional Design Document; then handing this to someone to produce a Detailed Design of how it will be implemented by the SharePoint Platform.
Traditionally Business Users don’t actually get to see or interact with anything until well after the Detailed Design is complete and the Implementation is in full swing. From here, it is likely that requirements change and scope creep occurs and then Functional and Detailed Design documents are immediately out of date.
A lot of SharePoint projects are very poorly documented due to the ease of which it is implemented and changed and this is something to highlight early on to the entire team…that Documentation is required! It is important to treat Releases as strict as you would a ASP.NET project for various reasons:

• Developers can look in source control and see what’s in Test/Production at any given time;
• A sense of achieving a goal if you have specific release dates;
• Formalised testing done as part of release process;
• If things are packaged and automated properly, SharePoint Admins can be handed the package to run in Test and then once approved run in Production…rather than Developers getting involved;
• Producing an As Built Document of the release, so that if a new team comes in to support it, they don’t have to go digging through code, environments and e-mails to work out what it is doing;
• All of which encourages a formal transition to support for the release.

I would recommend treating the installation of SharePoint as a completely separate project to any Solution you wish to deliver to the Organisation. The main reason for this is that it often involves very different resources than those involved with creating the Solutions on top of this Platform.

The Waterfall methodology does work well when it comes to the Infrastructure and Setup of the Environments. Many Integrators out there repeatedly do this for new customers who have purchased SharePoint licenses and have formalised approaches for this. I would strongly agree using an Integrator, rather than doing this internally as a self learning exercise, due to the complexities of the setup. It may look like a simple Wizard you run, but there are plenty of minor details that can cause all sorts of havoc later down the track. As mentioned before about the isolation, this is mainly due to the complexities of the platform which runs a risk of having more applications servers running on the environment leading to too many permutations when it comes to fixing a problem.

Scenario

At this point I’d like to raise a scenario which I’m sure most SharePoint Integrators reading this will nod their head repeatedly at.

So Microsoft have finally managed to persuade you to purchase the MOSS 2007 Standard/Enterprise license and the IT Manager has the media in his hands. The various technical whitepapers have been read and hardware has been purchased for a Database server and a Application server.

The Server Admin is sent off to install Windows Server on the two servers. The database server is then handed off to the DBA to install SQL. The thumbs up occurs and the SharePoint Admin installs MOSS on the Application server. The SharePoint Admin gives the thumbs up and they all get together to ensure that everything is being backed up.

A quick company logo is added to the header of the OOTB Blue SharePoint Theme and team sites are created for company divisions: Public Relations, Human Resources, IT and Finance. Division Managers are given full control of their Division Team Site and all members of the Division governed by Active Directory are given Contribute access.

Over the course of 3 months, various ad-hoc projects occur:

• Custom Web Parts have been added to particular Divisions;
• modifications are made to the look and feel using SharePoint Designer;
• InfoPath forms are suddenly replacing Word Documents for Time Sheets and Annual Leave forms with custom SharePoint Designer workflow;
• Columns have been added to certain Division Document Libraries;
• And the list of Business  Users with Power goes on…

6 months later, Users start complaining:

• Users can’t find documents in the search; and
• inconsistencies in how Document Libraries are set up make it hard for Users to know what to do;
• Users don’t know the most appropriate Document Library to use because the person who set them all up has left the organisation;
• Users want extra functionality out of the Web Parts/InfoPath Forms that have been installed, but the person who installed them has left;
• Also, Patches are released for SharePoint that need to be put on and fears around customisations that have been created being lost occur.

So a SharePoint Development Team is brought in-house or outsourced to follow up on these requirements. Immediately the team require a Development environment and the Project Manager wants a Test Environment for testing the updates and deployments before they go into Production. Issues are raised on the best ways to get Deployments from Development to Test to Production and also how to get Content from Production down to Test down to Development to give some realistic working data to test on (more on this coming on my blog).

18 months later, the CIO starts to raise concerns about how all this is being controlled and wants to start rationalising what people can and can’t do (from the list above) without going through a formalised process. This in my opinion is too little too late.

What I am trying to illustrate here is that if you put SharePoint into an Organisation you have to start Governing it straight away and take Roles and Responsibilities seriously. To the point where it is defined in Job Roles throughout the organisation and part of the Handover process when personnel move or leave the Organisation. The OOTB permissions that are giving to an “Owner” of the Division is far too much and should be giving to Owners at the IT Departments discretion.

In Conclusion

At this point, it is also worth mentioned that there is a programme that Microsoft have put together called the SharePoint Deployment Planning Services program. Basically Microsoft will pay its Partners to deliver a qualifying SharePoint deployment plan to their customers through on-site consulting sessions. The clients must have Software Assurance and the length of the session (one, three, five, ten or fifteen) depends on the agreement. So if you have Software Assurance please speak to your Microsoft representative and make the most of this opportunity.

Microsoft have also released this PDF on Risk and Health Assessment for MOSS Server by Microsoft as part of their Premium Support package. This again is probably to combat those environments that just aren’t set up correctly, for example hitting 100% CPU with 5 users or Maxing out on RAM.

The recent success of the Best Practices Conference in the US last month also pays testament on the awareness being raised within the Community. I have also noticed that plenty of training companies out there are also offering specific SharePoint Planning and Governance courses such as Ted Pattison , Set Focus, Mark Schneider (please add more in comments below).

The next part in the series will talk more in detail about the tools out there and how to leverage them.

Until next time,

Jeremy Thake

http://wss.made4the.net/ | http://www.readify.net/