Creating a culture open to change

Resistance to change is part of the human condition. Some say it’s human nature. Others reject this description, noting that we regularly accept change when we perceive it as being in our own best interest. Either way, extreme resistance to change in a corporate setting usually reflects weaknesses in the corporate culture.

Torben Rick, a leading blogger on leadership topics, defines eight common beliefs that lead people to resist change:

There isn’t any real need for the change

The change is going to make it harder for them to meet their needs

The risks seem to outweigh the benefits

They don’t think they have the ability to make the change

The change process is being handled improperly

The change is inconsistent with their values

They don’t trust those responsible for the change

They believe the change will fail

Jeanenne LaMarsh, an expert in change management, believes that resistance comes from three sources, beginning with comfort with the current state, based on a feeling of power it grants. There is also fear of the future state, either because it hasn’t been well explained so its impact on the individual is unclear, or because it is perceived as not being good for the individual’s needs. Finally, there is often fear of the transition period not going well because leaders aren’t trusted, even though the future state is desired.

Overall, resistance to change, based on fear and mistrust, reflects failures in how the organization manages the people side of change. Successful change depends upon building a culture of trust and transparency that goes beyond the limited scope of the change project. Only then will people be willing to consider the value the change will bring.

Agreeing on the project scope across stakeholders can be a challenging process, but never less critical to the success of the project. All business, functional, and technical requirements need to be understood, but ultimately have to be prioritized into must-haves and nice-to-haves.
Jaokim Lundberg, Practice Manager - GRC, EMEA, RSA Archer

Too often, change decisions—made through a top-down formal process by leaders or managers who aren’t themselves directly impacted by the changes—are undermined by resistance spread throughout the informal culture of the organization when employees feel that something uncomfortable is being imposed on them. It is essential to instead make them part of the process by establishing a culture of trust and transparency.

Implementing new GRC technology presents an opportunity to develop the positive culture that will support a successful change process and serve the organization and its achievement of objectives overall. In the recent DDI 2018 Global Leadership Forecast, a report entitled Adjusted for Disruption: Top Drivers of Organizational Success through Complexity and Change notes that it is essential to integrate many diverse perspectives in change efforts. The report states that “Leaders in more-agile organizations are twice as likely as their low-agility counterparts to collaborate and rely on diverse perspectives to create new solutions and opportunities, and to use multiple perspectives to gauge success.”

Ten Building Blocks for Creating a Culture Open to Change

Take steps to ensure that everyone affected understands and accepts reasons for the change
Involve representatives of those most affected in decisions about the change process
Identify specifically how each job will be affected, both good and bad
Clarify the benefits of the change for each affected group or individual
Understand that not everyone will feel the same as those who made the change decision
Recognize and use the ‘informal’ organization
Share details about the roadmap and schedule
Acknowledge the risks and limitations of the change
Continuously monitor attitudes about the change
Define a method for making quick adjustments that respond to needs as they arise
Source: OCEG




,

The report goes on to suggest creating cross-functional, shared goals across the organization to encourage interdepartmental cooperation and collaboration and to help identify and remove information silos that can impede change efforts. Such cross-functional consideration is an essential aspect of effective GRC, and building it into the change process will enhance the outcome of the project and successful use of the new technology for years to come.

A GRC Roundtable: Managing a GRC Software Change

Switzer: What are the biggest challenges in changing GRC software?

Skouse: The challenges are quite different than those associated with starting new. If clients are already using another GRC tool, then they probably realize some of the foundational things required for a GRC program which new clients often don’t.

For example, there must be a solid governance program, not just for the initial implementation/conversion project but for the lifetime of the GRC program. This also includes executive support, not just financially, but to ensure platform decisions are made with the best interests of the company in mind, and not just particular stakeholder groups. GRC implementations without good governance tend to go poorly, require expensive rework, and often lead to silos of Solution areas, which don’t work well together and never give an enterprise GRC picture.

Next, an administrative support structure is essential. New clients often don’t realize this is something they will need because GRC platforms can’t be implemented and then left to run on their own. There will be a continuing stream of change requests and enhancements.

You will need consistent reporting structures and taxonomies. For example, if one group uses a 3-point risk scale and another group uses a 5-point risk scale, they won’t be able to combine risks for an enterprise view.

Consolidated processes are also important. For example, compliance is typically already in place in many areas, but if accomplished in different ways or with different workflows this is something which will have to be rationalized into a single way of doing compliance.

When transitioning off of other tools, there is always a big question and a lot of work around what data sets and content will be transferred from the old system to the new. Can the legacy data be kept in the old system for audit purposes and the new system be the system of record from a certain date going forward? If content must be moved, what amount of work or formatting must be done in order to bring it into the new tool? You have to think about and answer these questions.

Lundberg: There could be several different reasons behind deciding to replace a GRC tool, which will affect the approach and introduce different types of challenges. It could, for instance, be the result of two companies merging, a commercial disagreement with the current vendor, or lack of functionality needed to meet business requirements.

Regardless of the reason, there are a few practical things to consider. It may not be possible to entirely replicate functionality, which can cause frustration with business users. Historical data needs to be considered, and simple things like migrating attachments or access control assignments on records can be complex or require manual hands-on. Integrations with third-party systems have to be re-engineered, and compatibility issues need to be considered. Both GRC systems may have to live side by side for some time, which needs to be planned for. Licensing, maintenance, or support deadlines can result in time constraints on the project. Third parties may not be helpful in ensuring a smooth transition. These are just a few examples, but most of these risks can be mitigated by robust project management practices and diligence in the scoping of the project.

ROUNDTABLE PARTICIPANTS





Moderator: Carole Switzer, Co-Founder & President, OCEG
Jaokim Lundberg, Practice Manager - GRC, EMEA, RSA Archer
Brian Skouse, Advisory Consultant, RSA Archer Professional Services

Switzer: What steps do you need to take to begin?

Lundberg: It is very tempting to start deploying a tool right away, but you should first clearly define your projects goals, scope, and priorities. A project definition exercise can take a few weeks, but is well worth the investment. Items to discuss include:

Use cases in scope

Roles and responsibilities

Existing tools

Reports and dashboards in use and their audiences

Current and future processes

Touch points with other processes or systems

Migration of historical data

Training requirements and audiences

Infrastructure requirements and constraints

This type of information is usually best gathered in a series of workshops and interviews with key functional stakeholders, system owners, and power users. Demos and prototypes can be helpful at this stage to ensure everyone is on board and to receive early feedback. The outcome is being in a good position to create a high-level project plan that outlines the scope, objectives, key stakeholders, milestones, and so on.

You also need to think about who will own, host, and administer your solution after the project. Those people needs to be involved and consulted at an early stage. Important things like how future changes will be funded and approved or how the solution should be hosted and operated should be understood.

Skouse: In addition to other software in use, you should determine what other methodologies or tools are used. Who is using spreadsheets, e-mail, and document managment tools? Are they using manual forms or worksheets? What, if any, are their GRC processes today that need to be captured within the tool?

Next you need to determine what will be replaced or supplanted. Along with this, are there budget and/or license restrictions that need to be taken into account? For example, if another tool is sunsetting, and it’s not done by a certain time, will a large cost be incurred? If key stakeholders give their acceptance, it’s much more difficult for them to complain later. The best programs take the work people are already doing and make it easier. If you design something that makes things more difficult, then adoption is typically not good.

Switzer: How do you set a schedule and determine what items to include?

Skouse: High-level roadmaps are a good place to start. Identify foundational priorities to be done first, such as reporting hierarchies, taxonomies, process harmonization, and issue management processes. After prerequisites are in place, look for business priorities that are “quick wins.” High gain for low effort. Processes that are close to out-of-box functionality are good candidates here. In a perfect world … another way to consider order is as follows: First, establish the foundational priorities. Next, define the regulatory needs and what defines compliance with those regulations. Then define and manage risk informed by how well you are addressing regulatory compliance, and then look for quick wins in areas such as third-party management, business continuity, audit, and other operations. IT-specific GRC projects would likely prioritize other areas as well, such as security operations and vulnerability management.

Lundberg: Agreeing on the project scope across stakeholders can be a challenging process, but never less critical to the success of the project. All business, functional, and technical requirements need to be understood, but ultimately have to be prioritized into must-haves and nice-to-haves.

A number of things could influence your decision, such as business priorities and cycles, regulatory requirements, constraints on use of existing systems, dependencies on other projects, and so on. Your executive sponsor and/or steering committee should ultimately provide guidance on the scoping.

Organizations that adopt an incremental or phased approach are, however, much more likely to be successful than those who try to boil the ocean. Have a vision and define a roadmap, but focus on the basics and worry about perfection later. Everyone wants an aggressive timeline, but be realistic. And, while it’s tempting to pressure the vendor, most of them will confess to spending most of the project time waiting for the client anyway. Expect to deploy a single businss process in 2-3 months and to spend 50 percent of that time with business requirements and design activities.