Key Principles for a Successful Salesforce Implementation Part III: Governance

Salesforce Architects
Salesforce Architects
5 min readSep 2, 2020

--

Articulating the value of guiding principles to your stakeholders, knowing when and how to use them in governance, and managing principles throughout their lifecycle are all critical elements in to really successfully using principles to make your Salesforce implementations healthy, and help keep them healthy.

Read on to find out how to approach these elements.

Explain The Value

Asking your team members to change how they go about making decisions and getting things done can be challenging. This can be the case whether you’re talking about program or project tasks, or more ‘business as usual’ and maintenance tasks. The trick is, as always when changing any process, to make sure you explain the value of making the change in a way that means something to those affected. For example, why not talk about the benefits in empowering your solution architects, developers, and administrators? Giving them clarity in what will or won’t be an acceptable design choice up front means they can make their own decisions more confidently and more quickly.

It’s also important to take time to explain to senior leadership how they’ll benefit from your change in approach. Things you won’t be doing include: adding unnecessary bureaucracy, slowing down your delivery cadence, constraining innovation. Things you will be doing include: empower teams to make good decisions, exercising more consistent controls without removing team-level autonomy, help demonstrate the impact on organizational goals (read Part I of this series to learn how this works).

When and How to Govern?

Transition from unprincipled to principled governance requires tolerance for varying degrees of success, as you change your approach over time. Not everyone will want different controls applied, either immediately or at all. Not everyone will apply them correctly from the start. But it’s not all doom and gloom, far from it! Principles will help set people free, allowing people to get on with the ‘doing’ part of their work more quickly.

Ideally every time someone starts out designing a solution, creating a fix, or making any sort of change in your Salesforce environment, there should be a thought process triggered that checks your principles first. The reality is that doesn’t always happen for a variety of reasons (e.g. time, desire, perceived relevance). Adding a ‘principle checkpoint’ step into existing governance processes is a great way to help this become second nature.

Here are some times when checkpoints are most helpful:

  • Solution Design: After requirements have been aligned to features and solutions.
  • Solution Approval: Before a solution design, or statement of work (SoW) that proposes a solution, is agreed.
  • Architectural Reviews: During regular architecture group meetings and discussions of proposed changes.
  • Change Management: Before a release or change is approved for deployment.

In these cases, where no alignment is found, alternative solutions should be sought before moving forward. Critically, include why a given principle matters and how it has been applied in each case, relating the statements back to the rationale of the principle. This will help focus efforts on finding a solution that is a better fit.

Managing the Principle Lifecycle

Principles should not change often, as they’re such an important factor in how you make decisions. Adapting to changing business priorities and technical advancement, however, will inevitably mean your principles must also adapt. That means there can be no hard and fast rule for how often to review your principles. Instead, consider what might trigger a review of your principles e.g. major change in business plan and/or IT strategy, a new program or project about to start, a new set of skills within your Salesforce team, or new features available in your Salesforce deployment.

Your existing governance groups are an ideal way to make sure the right people are involved in controlling the consistency of the principle set. This should include business and IT stakeholders, with the final say given to your enterprise architecture team. If you don’t have an enterprise architecture team, then this usually falls to the most senior IT person with an architectural or high level design responsibility.

Use your usual change management to manage the lifecycle of a principle. As well as recording who created and last updated the principle, and when those things happened, consider additional details for each principle to manage the lifecycle:

  • Owner: Who is responsible for wording updates, version control, any other queries?
  • Version: Use a versioning scheme to keep things clear for all.
  • Status: E.g. Draft (work in progress), Final (released and in use), Retired (no longer in use).
  • Review Date: When should this principle be reviewed for accuracy and relevance?
  • Retirement Date: When was this principle removed from use?

We personally would not recommend changing the wording in a principle once it has been finalized for use, but instead create a new principle where a wording change is needed. Changing a single word could fundamentally change the intention, so there’s risk in trying to capture and reference those changes over time in a single principle.

Moving Forward

Throughout this 3-part blog series, we’ve talked about the reasons why principles should matter to you and how to get started. We’ve shared categorization ideas and examples, and most recently talked about how to manage the principle lifecycle. Your mission, if you choose to accept it (which we really think you should!), is to start working out how to make this work for you and your organization.

About the Authors

Richard Booth is a Customer Success Architect at Salesforce.org in EMEA. He helps nonprofit and higher education organizations make the best possible use of Salesforce technologies to deliver value and support their mission. Connect with Richard on LinkedIn.

Chris Rolfe is a Customer Success Architect at Salesforce.org in EMEA. As a member of the advisory team he ensures our EMEA customers in higher education and nonprofit areas are successful in their implementation of Salesforce technologies, enabling them to achieve their mission. Connect with Chris on Linkedin.

--

--

Salesforce Architects
Salesforce Architects

We exist to empower, inspire and connect the best folks around: Salesforce Architects.