Avoiding Growing Pains Through Good Governance

I’ve recently returned from Dreamforce 2013, where I had the opportunity to spend time with our fantastic Cloud for Good team, see some great sessions, meet some of our amazing customers and co-present two separate sessions. One of those sessions was entitled ‘Growing Pains: Scaling Your Salesforce Implementation’ and I worked with fellow MVP’s Mary Pustejovsky and Brian Kwong to discuss some of the issues and considerations that customers of any sort should take into account when expanding their use of Salesforce (you can see the session slides and here the audio on YouTube here). The session will eventually be posted on YouTube, but in the meantime, I thought it might be useful to expand on one of the topics covered in more detail: Establishing Good Governance

If you Google/Bing/Yahoo the term Governance, you will be presented with a variety of definitions, but fundamentally they boil down to ‘a method or system of government or management’. In non-profit (and even general corporate) terms governance is most often referred to in terms of the relationship between the Board of Directors and the organization and the rules that establish how organizations will function.

When working with Salesforce.com (or any system for that matter), following the principles of good governance can make life easier for administrators and users alike by providing a clear and consistent framework to manage change over time and defining processes to resolve conflicting requirements. In our experience, governance is often an evolutionary process, consisting of three stages: Monarchy, Democracy and Republic

Stage 1: Monarchy

For many organizations, non-profits in particular, the use of the system often starts off in a very limited fashion, supporting a single business function such as Development, customer service or delivery of a service, and in those early, halcyon days, governance is relatively easy; there is little conflict or competition for resources to support the system and decisions about changes can be made with little concern for the impact on other teams. Management can focus on increasing user adoption, driving efficiency and delivering on whatever value proposition has been identified for using Salesforce.com. We characterize this stage as Monarchy, because the governance requirements of this stage are relatively light, typically with a single owner who can make decisions (this may be someone from either the business unit or IT, depending on the organization).

All may be good for a while, but then things begin to change. Other teams, seeing what can be done with Salesforce may begin to say ‘how can we get in on this?’ Executive leadership may say ‘why do we have to have a different system for managing volunteers and managing donors – we want a 360 degree view of our constituents – let’s merge them!’

One of the great advantages to using Salesforce.com for non-profits is that the economic barriers to entry are relatively low and the ease of integrating other functions is much greater than many other systems, so those requests to bring them on board can be accomodated fairly easily. This is where things start to get tricky from a governance perspective, or as Admiral Ackbar said ‘It’s a trap!’.

Stage 2: Democracy

Different business functions, even within the same organization often have different naming conventions for the same things, different business processes (e.g. different cultivation stages for volunteers and donors), different rating systems, etc. Once you bring those functions together into your system, you need to begin reconciling those differences. Additionally, every time someone requests a new field to be added to an object, you have to begin assessing the impact on the whole organization. What often happens in this stage is the development of an informal governance committee, as super-users or champions from different user groups begin to meet to try and resolve issues as they arise.

We characterize stage 2 as Democracy, because governance at this point tends to be more reactive and serve a coordinating function rather than one of control, with each representative having approximately equal weight in the decision-making process. Adherence to processes may be inconsistent or sporadic, and change-management processes may not be fully realized, leading to conflict between affected user groups. Depending on the rapidity of change or the addition of new groups to the system, this stage can continue for quite some time.

As the scale of Salesforce implementation increases, the complexity of coordination increases at a faster rate, and the need for more formalized processes becomes critical to ensure the smooth functioning of what has become a primary technology platform for the organization.

Stage 3: Republic

In the Republic stage, ad-hoc coordination between super-users is replaced by a more formal business-council structure – A Governance Council (or Committee) which has both strategic and operational oversight of the organization’s use of Salesforce. The council should be chaired by a member of the senior leadership team, with representation from the technology team, business functions using the system and other representatives with related interests. The purpose of the Governance Council is to define the strategic roadmap for future implementations and serve as the arbiter for resource allocation towards specific projects.

The role of the Governance Council is to define policies and procedures that help codify the organizations approach to administrative rights, access privileges, license acquisition, change promotion procedures, and all the myriad settings involved in maintaining a healthy Salesforce.com instance and ensuring that the organization is realizing the maximum value from its investment in Salesforce.com. By establishing these standard policies, they ensure that there is equal treatment for users across the organization, or as Dr. Sheldon Cooper would say:

In addition to playing a compliance role, members of the Council can also serve as champions and advocates for the system, encouraging adoption and helping with change-management as the organization continues to scale its use.

While we’ve outlined an evolutionary process from Stage 1 to Stage 3 in the model above, evolution is a messy and conflict-filled process, filled with blind-alleys and false-starts. Wouldn’t it be great if you could jump directly to stage 3 and skip the messy middle of Stage 2? The good news is that you can! Whether you’re thinking about implementing Salesforce, or you’re already using it and thinking about expanding, here are a few things you can do to start building a governance structure that works:

Strictly limit the number of System Administrator profiles – the more Admins you have, the more changes that can be made and the harder it is to control them.
Require that changes be made in a sandbox before being made in production. Ideally, provide each admin who makes changes with their own sandbox and use one to integrate all changes before promotion to production.
Publish policies and promote their review and discussion. Get buy-in from your admins and on-board new admins to the process from the outset.
Leverage page-layouts, profiles, permission-sets and record-types to provide different views of the same data for different users.
Carefully evaluate requests for new fields to ensure that they are properly visible and that you’re not going to create very sparse data sets (fields that are filled in only for a handful of records).
Plan, plan, plan! Think carefully about the sequencing of functions that you’re going to bring onto the platform. Identify like functions that could be consolidated as part of the migration process and align their business processes as part of your project, not afterwards.