Designing an Agile Org Governance Model (A106)

Empower, not restrict

Governance is often associated with lots of rules and policies. Invasive governance models require every change to be approved by a specific person or committee. The more change requests there are, the more of a bottleneck this becomes. And people in the committee are often not the best people to ask anyway – as they do not know how all different parts of the system are being used and by whom. 

Click to open Learning Objectives

LO1-1 Evaluate when stakeholders are required for metadata

LO1-2 Design stakeholder governance models

The governance model needs to find the right balance between controls over data definitions and agility to improve end user experiences to help them execute their jobs better and faster.  The best way to do that, especially for organisations that are just embarking on the governance journey, is to implement simple checkpoints when making decisions about certain types of metadata.

The more complicated the governance model, the more costly and time-consuming the process for making changes to the system and the business. If every type of change has to go through some rounds of approvals, then you are hurting and reducing your time to value. The longer and more restrictive the decision-making process, the more likely the governance rules will be abandoned over time.

Delegate responsibilities

One of the best practices for implementing an agile metadata governance model is to rely on a responsibility assignment matrix. Rather than assigning fixed roles or responsibilities for all changes to the Org, which ultimately leads to bottlenecks and delays, a more sophisticated approach is to assign responsibilities down at the specific metadata level. This ensures the right subject matter experts are consulted directly, which shortens the communication cycle.

Within the Elements platform, we rely on OACI matrix for metadata which stands for:

  • Owner: Person who is ultimately accountable for the metadata and data stored within. This could be a business stakeholder who owns a particular object or an administrator who is responsible for curating a given part of the Org.
  • Authorizer: Person who needs to authorize any changes to the metadata before they happen.
  • Consulted: Person who can offer expertise for changing a particular part of the Org.
  • Informed: Person who needs to know when the change to a component is being done and when it is to be released. This could be a training officer or a team lead who need time to prepare their employees for the change. 

Click to open illustrative example

Company Zenalpha works in a highly regulated industry. On top of that, they have integrated many external systems to the key objects. In such an environment, it would be easy to assume that any changes to the Opportunity object need to be approved by a committee or a specific person. But consider the following matrix:

Opportunity object stakeholders:

  • Object:
    • Owner: Jack : the admin responsible for any changes to this object.
    • Authorizer: Rob : the head of sales who needs to know about any fields being added or deleted as this is the primary object for his team.
  • Fields:
    • Amount:
      • Owner: Jack : the admin responsible for any changes to this field.
      • Authorizer: Kate: the head of finance needs to approve any changes to the opportunity amount as this is required by regulation and impacts forecasting.
      • Authorizer: Richard: as the head of sales, he needs to approve any changes to the amount field.
    • Base Commission Value:
      • Owner: Jack : the admin responsible for any changes to this field.
      • Authorizer: Kate: the head of finance needs to approve any changes to this field as this affects commissions paid to the sales team.
      • Consulted: Richard: as the head of sales, needs to have a say in how these commissions get calculated.
    • CampaignId:
      • Owner: Jack : the admin responsible for any changes to this field.
      • Authorizer: Lyanne: the head of marketing needs to approve any changes that affect visibility of campaign success.
    • Contract ID:
      • Owner: Jack : the admin responsible for any changes to this field.
      • Consulted: Adrian: the architect who built an external integration to the finance system
      • Informed: Solomon: the sales ops person who needs to know which contracts to send when.
    • Discount amount:
      • Owner: Jack : the admin responsible for any changes to this field.
      • Authorizer: Richard: as the head of sales, needs to approve what are the rules on available discounting by different team members.
    • Fiscal Period:
      • Owner: Jack : the admin responsible for any changes to this field.
      • Authorizer: Kate: the head of finance needs to approve any changes to the opportunity amount as this is required by regulation and impacts forecasting.
    • Licence Allocation Date:
      • Owner: Jack : the admin responsible for any changes to this field.
      • Authorizer: Kate: the head of finance needs to approve any changes to the opportunity amount as this is required by regulation and impacts forecasting.
      • Informed: Solomon: the sales ops person who needs to know when to allocate licenses to the customers.
    • Product ID:
      • Owner: Rory : the admin responsible for any changes to this field.
      • Consulted: Ksawery: the head of product that needs to clarify the types of products we sell.
      • Informed: Solomon: the sales ops person who needs to know when to allocate licenses to the customers.
    • Lost reason:
      • Owner: Rory : the admin responsible for any changes to this field.
      • Consulted: Ksawery: the head of product that wants to know why deals fail and what shortcomings in the product are deal breakers for prospects.
      • Consulted: Jim: the head of customer success team who wants to be aware of the reasons why some deals never go through.

This example demonstrates that the Opportunity object in Salesforce, which can be reasonably seen as being a ‘sales’ object, is utilized by almost every other business unit in the business. It would be extremely restrictive to consult everybody on any change to this object. Equally, not consulting finance, product, customer success or sales ops teams could result in huge operational risks to the business.

By specifying the right stakeholders on key metadata, it is extremely effective and agile to get the right information at the right time.

And that is the foundation of your knowledge and understanding needed to design an Org Governance Model.

What’s next

Next, you will take a short, theory and practical quiz. Select it from the menu below.

This quiz will help you to recognise the skills and knowledge you have gained, and identify any areas you still need to explore and learn.

Remember, you can revisit these pages, or ask us for help if you get stuck. Once you pass the quiz, click “Next Module” to move on to Module 3.

Back to