As the adoption of our MOSS 2007 platform continues to gain traction we have begun delivering some of the more important pieces of our governance plan.  Due to our limited resources we have identified the areas that we feel are the most important and are delivering those as they are developed. 

First, a primer on our environment in order to provide some context on the why.  I work for a global manufacturing company with a decentralized operational structure.  We currently have about 8000 users and are at approximately 600,000 hits per month across the portal.  Many of our facilities are coming on board to our MOSS implementation which is managed centrally in the Toronto area by a relatively (by the standards of other organizations) small team of people.    When I say small – I mean 3 in IT.   As our facilities come on board there are increasing requests to automate business processes by creating and hosting workflows in SharePoint.  We felt it was necessary to quickly develop and publish some policies around this type of activity that takes into account three main factors:  reinforcing the concept of user ownership over SharePoint functionality, the resource levels at the central office, and the current processes around deployment that are already in place.

Obviously many pieces of successful governance are inter-related which is why in conjunction with these specific policies we have published governance about the roles & responsibilities of the various types of users interacting with SharePoint: site collection administrators, site administrators, content creators etc.  Support processes need to be documented as well in order for the site administrators/content creators to understand their role and the escalation path.

Below is an overview of the workflow-related policies and the rationale behind them.

Policies

• Out of the Box SharePoint workflows will be the first option examined when implementing workflows
  • This is straightforward and doesn’t require much explanation.  OOTB should always be the first option when looking at new functionality whether its SharePoint or any other technology solution
• We do not currently support the out of the box translation workflows
  • Our implementation is currently English only so there is no business need to be using these workflows
• We will not provide support for user developed SharePoint Designer workflows
  • This does not mean that we will not allow SPD workflows to be created and deployed.  It means that should a user choose to use SPD designer to create a workflow they own it we will not be able to support them with their troubleshooting requirements.  We simply do not have the resources to spend time with individual users or teams analyzing why their workflow is not doing what they expected it to do.
• SharePoint Designer training must be taken prior to creating workflows with this tool.
  • We will however recommend training providers that can provide the required training or will assist individuals or teams with the fundamentals of SPD workflows.  We are also developing training material that will be provided through the MS Productivity Hub which will allow them to access material on demand.
• The creator of the workflow owns it and is responsible for any documentation/knowledge transfer.
  • This was touched on in Point 4 but it can’t be stressed enough.  As with any business solution the functional business owners are responsible for knowing, using and training on the functionality and business processes they own.  We are making a much more concerted effort as part of the governance process to define and communicate the responsibilities of the business owner/site administrator. 
  • Communicating the necessity of cross training to the owner as a risk mitigation strategy is essential in helping them understand their responsibility.
• Errors with workflows will be investigated by the owner of the workflow by reviewing the workflow history.  If, after investigating, the error appears to be platform related an email will be sent to the helpdesk with detailed information about the error.
  • The intention here is to again ensure that IT and more specifically the Help Desk is not the first option when an issue with a workflow is discovered.
  • Training the users on the fundamentals of workflows, tasks, workflow history etc. will empower them to attempt to troubleshoot the issue and resolve it more quickly.
• We will not support the developer training or deployment related to custom developed workflows in Visual Studio.  
  • VS workflows need to be deployed by someone with access to Central Administration
  • We have a rigid deployment process of one deployment to QA and Production per month.  We have 1 person responsible for doing this (along with many other tasks including non-SP related).   This means that a custom developed workflow change could potentially be facing a lag of 1 month prior to being deployed
  • The issue for us here is not the mechanics of deploying the workflows, but the inevitability of the software developers at our divisions creating more complex workflows over time with increased needs for changes, errors and “emergency” deployments putting our current deployment processes and policies at risk.
• SharePoint workflows will not be used to automate business critical processes.
  • This policy is derivative of the previous points and realities of our environment.  As is common with most SharePoint deployments there is a tendency for people to think of SharePoint as the solution for everything.  We are attempting to place reasonable constraints on the use of the environment while working proactively with our users to identify alternatives by helping them clearly define their requirement and choosing the right solution.

This policies will evolve over time, as they should.  We have already referred numerous people to these policies and their supporting documentation.  As our organizational maturity with this platform improves our governance model will evolve in parallel.