Governance is often spoken of almost solely from an IT perspective, and I think that's in large part because it evolved from The Principles of Scientific Management, TQM and ISO 9001 Quality management systems. More often than not, IT governance operates in a model whereby boards and senior business executives defer IT strategy and decisions to the IT leaders but create oversight and controls so that the IT delivery aligns with the interests of the business stakeholders – and ensures that the IT and business strategies and objectives remain complimentary and synergistic where possible, and not separate or possibly in conflict.
It's not easy, but when done correctly, IT delivers the maximum value throughout the business and empowers the business to achieve objectives that would otherwise not be possible.
Drilling down a level, the governance model and its benefits are directly transferable to CRM adoption projects, if you do four things.
Align with Corporate Governance
First, create your project governance as a subset of the organization's corporate governance. The more your project governance resembles the company's corporate governance, the more likely your project will link and directly contribute to the company's most important objectives, and the more likely the project will be both successful and sustainable.
In this context, project governance includes a mission and clear vision linked to the corporate mission and vision, accepts project risk in a way that references the tolerance, constraints or criteria of how the company accepts business risk, and takes a holistic view to understand how the project may benefit other stakeholders beyond the immediate CRM constituents, and thereby better align and integrate the project within the broader organization.
This means identifying and considering the interests of many stakeholder groups, and architecting efforts in a way that project output or deliverables can provide the input or reusable value for other departments, lines of business or beneficiaries. This requires looking at the project holistically, and not piecemeal or in siloes.
Align Business and IT Objectives
The second step is to design the governance method to align business and IT objectives, deliveries and even relationships. But that's easier said than done. Here's the challenge.
Business leaders want easy to procure, easy to use, fast to deploy, purpose-built applications in order to more quickly respond to more empowered customers, fluid market conditions and agile business strategies. But IT leaders desire standardization on fewer technologies and applications in order to use more of what they have, curtail integration, aid security, deliver superior services and reduce IT costs. When the goals are not aligned it creates a gap between the business and IT.
Compounding the problem, most organizations have a single process for selecting, deploying, managing and retiring business applications. They often classify applications by type or three letter acronym (CRM, ERP, HCM, MRP, MES, SCM, etc.), but don't differentiate based on how those applications can be used to achieve user objectives such as productivity, ease of use and rewarding user experiences, or business objectives such as innovation, differentiation and agility.
These are perennial challenges that were often neglected when businesses controlled the balance of power in the vendor-customer relationship. But now more connected, informed, empowered and demanding customers control the balance of power in commerce so this misalignment must be resolved if businesses are expected to respond to more fluid and competitive marketplaces.
To solve these challenges, there are a few governance models designed to accommodate this new reality. One is Gartner’s Pace-Layered Application Strategy, generally just called Pace. This can be used to apply a governance model which aligns the methods business leaders use to create competitive advantage, described in terms of common ideas, different ideas and new ideas, with a technology portfolio segmented into layers of Systems of Record, Systems of Differentiation and Systems of Innovation.
A single application may cross all three layers. For example, a CRM system is generally a System of Record, but a CRM Next Best Offer (NBO) algorithm or a self-service knowledge-base may be Systems of Differentiation while unique methods of social engagement or delivering relevant, personalized and contextual customer experience's may be Systems of Innovation. Additionally, different companies may classify the same application differently, and the same technology may migrate among layers due to maturity or obsolescence. Also, a System of Record is often required in order to support more nimble Systems of Differentiation and Innovation.
This IT portfolio segmentation permits more flexible and united governance objectives. Rather than view the CRM system as a collective whole – to be managed, maintained and replaced in the aggregate – business and IT can mutually designate individual CRM components based on their highest and best value.
Systems of record will include CRM foundational components that perform core processing, safeguard data integrity and ensure compliance, and therefore benefit the company by incurring fewer changes and longer life cycles. On the flip side, CRM components designated as systems of differentiation and innovation may be updated or replaced more frequently in order to support more fluid and flexible business strategies.
So how does this offer a strategic opportunity for a CRM project? You can create or update the governance model by identifying CRM capabilities that best support common, different and new ideas for competitive advantage and choose to manage these capabilities within the constraints or flexibility of systems of record, differentiation and innovation. The result is a more agile CRM application that can segment its capabilities in order to get more life and value from foundational components and permit more investment in those capabilities that can drive more differentiation and competitive advantages for the company.
Focus on WHY Before You Propose WHAT and HOW
The third step is to recognize that when stating and slating objectives, business users generally answer the WHAT question (i.e. what do we want to achieve?), and IT answers the HOW question (i.e. here's how we'll do it), … but governance thinking is much more focused on the WHY question (i.e. why do we want to do this?).
When considering your objectives and initiatives, by applying a governance mindset to focus on the WHY question, in later the WHAT and HOW questions, you can better prioritize the actions which lead to the most strategic and highest payback outcomes.
CRM Governance Operation
The fourth step is to support your governance model with governance resourcing, communications, cadence and tools. Unfortunately, from a governance perspective, this is where most CRM projects begin the governance process, which ignores the prior three steps, and moves into project execution without sufficient strategy and planning. This is a common mistake in many less than successful CRM deployments.
Resourcing will include organizing the user committees, project team and steering committee. It's helpful if these groups are made up of cross-departmental teams. It's also helpful to identify the right roles, then determine the specific responsibilities and commitments needed for those roles to achieve the slated outcomes, and then match those roles to the right people.
This is different than the more common approach of finding resources with availability and designating them to roles. We identified outcomes and then worked backwards to get to the right people. It’s helpful to recognize that the right people are quite often the people with the least availability. That's not a coincidence, and perhaps why my dad used to say if you want something done, give it to a busy man.
Governance also includes cultural norms and expected behaviors from your team members. Another governance standard may be to agree that weekly project team attendance at project team meetings is critically important to sharing information timely and across departments, and should not fall below a minimum attendance threshold over the course of the project.
Governance communications will include weekly project team status reports and monthly steering committee reporting. Agile projects also include agile reporting such as sprint based burn down charts, velocity charts, stage gate reviews and retrospectives. The organizational change management (OCM) will deliver communications to a much broader audience based on a Comms Plan and in a way that tailors the messaging to progressively move the recipients along a continuum from Awareness to Interest to Understanding to Engagement.
The status report content is subject to these groups determination, but should normally include project status overall and status broken down by program area (i.e. such as status for the application, data migration, system integration, staffing, change management, scope, time, cost, quality and outcomes). Issues and risks should be separately reviewed, noting that issues are discrepancies which have occurred and need resolution while risks are events which may occur and need mitigation. Any project deviations that cause impact to project objectives or the project management cornerstones of scope, time, cost or quality should be separately presented and include accompanying remediation plans.
Governance cadence will include as-needed and recurring get-togethers, such as weekly project team meetings, monthly steering committee meetings and agile-based meetings such as daily standups, backlog grooming, release planning, iteration demos and retrospectives. These meetings should use agreed upon agendas, deliver meeting contents to participants in advance of the meetings, be led by knowledgeable facilitators and achieve planned outcomes.
Unproductive meetings represent significant investment and productivity leakage that generally occurs under the radar or is accepted as the status quo. A best practice is to measure meeting outcomes, and change the agenda if not getting the expected outcomes, and avoid having unproductive meetings. Restructuring and cancelling unproductive meetings will accelerate project progress.
Governance software tools are needed to automate planning and execution. It's helpful if a single tool or a few integrated tools are used to track and report project status, project progress, issues and risks, change control, performance metrics and agile constructs (i.e. product backlog, release backlog, sprints and other agile reporting that I mentioned above). Common tools include Jira and Rally for relatively simple projects or Microsoft DevOps and IBM Rational Team Concert for more complex projects.
The governance approach, methodology, model, management techniques and expected outcomes are memorialized in a standalone governance plan and evaluated during weekly project team meetings and monthly steering committee meetings.
The governance plan and its four cornerstones empower the organization to view the project through the front windshield, and not just the rear view mirror, and are essential to steer the CRM project to a planned destination, and not just be along for the ride.