Salesforce Lean Governance Framework

In the old world of mainframes, IT projects had a complicated governance structure. It made sense at the time because of all of that pesky infrastructure. Building data centers, installing mainframes, writing copious code, and more. These are all expensive and time-consuming tasks. The memory of this old way of doing things is what causes many people today to equate governance with bureaucracy and red tape. At Salesforce, we use a lightweight governance structure to develop, implement, and manage new technology—we call it lean governance. It’s lean because it helps customers deliver successful IT projects—fast, but under control.

What does this lightweight and agile framework look like? It includes five key processes. 

• Vision and strategy
• Business backlog
• Software development lifecycle
• Data strategy, architecture, and management
• Communication strategy

Vision and Strategy 

Every project needs a “north star”—a foundational mission statement to guide all participants on a common path. Within the Salesforce lean governance framework this is the vision and strategy. The vision specifies what you want to do, and the strategy defines how you’re going to do it. 

A great starting point is the project business case. It is paramount to also define your strategy to achieve your goal. For example, your vision might be to increase profitability. This could be achieved by two different strategies: cutting costs or increasing sales. In our Ursa Major Solar example from Unit 1, it might look something like this.

“Boost profitability by radically increasing sales for turnkey solar systems.”

As we discussed earlier, the Sales team owns the vision but this should be an iterative and public process that involves all stakeholders. If the project spans multiple business units, then all these business units need to be involved too. 

It is also important to define a few (no more than five) measurable criteria to evaluate success. Monitoring this data allows the project team to alter course if the solution is not delivering the expected value. Here are a few criteria that our Ursa Major Solar team might create to support their vision.

• Reduce the average lead-to-cash duration on a turnkey solar system from 26 days to 6 days.
• Reduce the average time to generate a turnkey solar system price quote from 3 days to 1 day.
• Reduce the percentage of turnkey solar system quotes that require Sales Operations assistance from 100% to 25%.

Finally, it's important to understand that a vision and strategy are not etched in stone, they should be regularly reviewed and updated. This ensures the solution can always deliver business value even in a rapidly changing landscape. One final point to emphasize: the vision and strategy are expressed in business terms. There should not be any mention of technology or systems. 

Business Backlog 

The business backlog is a complete list of all the business requirements. We all know that everything can’t be delivered at the same time. The implementation team only has a certain amount of capacity. This means the backlog needs to be prioritized. 

Knowledge of the features and functionality of the Salesforce Platform is essential for people making the prioritization decisions. Teams should always be thinking of ways to maximize usage of the platform’s declarative (that is, point-and-click) features and minimize the need for custom code. Custom code is the most expensive kind of solution to implement and maintain, and that cost should be an important factor when setting priorities for the backlog. Lean governance emphasizes efficient and fast delivery. We have observed many customers rush into custom code too many times when a viable declarative alternative was available.

Always use the vision and strategy as your guide when working through the business backlog. And remember: This process is owned by the business units affected by the project with support from the technology team. Under no circumstances this is carried out by a third-party implementation team—they simply don’t know your business as well as you do.

Just like the vision and strategy statement, the business backlog should be dynamic and flexible. Build in feedback mechanisms from your users, take their suggestions seriously and highlight enhancements that come from your users. For inspiration, check out the Salesforce Idea Exchange, where we publicly solicit feedback from our Trailblazer community. Many of our greatest features and enhancements come from our customers and partners.                                                                                     

Software Development Lifecycle

Another key process in a lean governance framework is defining your software development lifecycle. Establishing guidelines for the release cadence, migration of new functionality between environments, and quality assurance testing, and having consistency and guidelines for these things maximizes productivity and minimizes system instability. We refer to this set of principles as technical governance. Your technology organization needs to educate themselves on this subject and develop methodologies that work for your company. See the resources section at the bottom of this unit to learn more and get started on this.

Data Strategy, Architecture, and Management

Data has become one of a company’s most vital and precious assets. Multiple systems generate tremendous amounts of information, and there’s real insights to uncover when integrating all this data. That’s why having a data strategy as part of your lean governance framework is so important. You need to formalize an integration strategy to ensure important data architecture decisions are considered holistically and with system integration in mind. To get started with a data strategy that works for your lean governance framework, see the resources section below.

Communications Strategies

Have you ever been involved with a technology project that was unsuccessful? Sadly, many of us have. Mismanaged technology initiatives cost organizations dearly. Our Success Cloud teams are called on frequently to help address challenges like this regularly. More often than not, the root cause of some of our customers’ biggest issues are related to mismanaged implementations. And the underlying root cause of the unsuccessful implementation is nearly always poor communication—changing requirements, “scope creep,” cost overruns, mutinous end users.

Communications strategy is about ensuring everyone affected by a new project is informed and has a voice in the process. 

While there is no one-size-fits-all recipe for developing an effective communication strategy, here are some best practices that you should try to incorporate into your governance model.

• Involve leadership. People naturally pay closer attention to communications from executives. For major initiatives and changes in particular, executives should lead the messaging.
• Mix it up. It’s important to take advantage of the various communication tools and forums that your company uses. Don’t exclusively rely on emails or Chatter. If there are major releases or new features to share with your users, try to get the word out in multiple ways.
• Be mindful of noise. While we stress over communication is generally good, especially in the beginning of a new implementation, be aware of going overboard. Crying wolf and bombarding your community with a constant stream of information will quickly misfire. Ensure your messages contain real value to the intended audience. For example, end users are probably not interested in full details of your steering committee minutes.
• What’s in it for me? As mentioned above, ensure your communications are valuable. One way to ensure this is to always think about it from the perspective of the recipient. Why should I care about this message? What’s the value to me? People are naturally resistant to the changes that Salesforce projects introduce. Be extremely mindful of this, and always think about providing real business value to your audience.

Operating Model and Core Committees

With those five core processes defined, we can now move into the actual structure of the Salesforce lean governance framework. The first thing to figure out is your operating model. The three basic options are:

• Centralized: A single governance framework with a one set of processes and normally focused on a single solution, single business unit, or global processes. Generally the best option for smaller, single-org companies.
• Decentralized: Federated governance framework with independent governance frameworks and the possibility of different sets of processes for different business units. The decentralized model is used for organizations that have multiple Salesforce environments with highly autonomous business units or geographies.
• Hybrid: Common governance framework with each business unit having its own autonomy. This approach is effective for larger companies that want to standardize their best practices and processes under a common framework, yet allow some amount of autonomy for their different divisions or geographies.

There’s not one right answer for which structure is best for your company. If you’re only using a single production Salesforce org, then the centralized option is most likely the best option. If, on the other hand, you’ve got multiple Salesforce environments and different geographies or business units that operate in different ways, then one of the other approaches might be a better fit. Some additional factors that can influence this decision include:

• Your development methodology: Does your company follow an Agile development methodology, or the classic waterfall paradigm? Do different divisions use different methodologies? These two approaches don’t mesh well together in a single framework.
• Use of third-party partners: Are system integrators being used for some or all of your projects? Again, this has a big influence on your processes.
• Company politics: Corporate structure and politics are also a factor. If your company generally operates in a federated way, then a centralized governance framework presents an extra challenge.

Once you establish your operating model, it’s time to form the core committees that will execute your lean governance framework. They are:

• Executive Steering Committee: This group owns the overall vision and strategy, sets the priorities and oversees the overall project budget. It also acts as the final escalation point for disagreements that the project teams are unable to resolve. Membership should include key executive leaders across the impacted business units, IT, and the project management team. The committee should meet at least quarterly or more often, depending on the release cadence. Here’s a typical agenda for the steering committee.
• Update on actions from the last meeting.
• Review of the project(s) overall health and KPIs.
• Review and update the vision and strategy if required.
• Review of the overall project(s) budgets.
• Review of project risk register.
• Discuss any other competent business.
• Project Management Committee: This group manages the day-to-day details of all major projects. This team should meet once per week with representatives from all key stakeholders in attendance. Suggested agenda:
• Update on actions from the last meeting.
• Review of the project(s) overall health and KPIs.
• Project resources and team skill requirements.
• Review of project risk register.
• Discuss any other competent business.

There are a few other optional committees that might make sense for your company. See the resources at the end for additional details on these committees.

It's important that all of these committee meetings are documented and published to all stakeholders. Remember, communication and consensus are critical success factors.