Anyone who has tried to undertake a major (and even minor) change in an organization has most likely experience some roadblocks. In my experience getting upper management and other key stakeholders to understand why the change is necessary. How many of you can identify with these responses from key management/stakeholders regarding change:
1. Why change? Isn't working just fine?
2. We have always done it this way so why change?
3. We don't have the budget/equipment/people/(insert their excuse here) for this change.
4. I don't like this change.
5. We are not ready for this change.
Any of these sound familiar? So what can you do to make change happen?
One technique is to understand and use the concepts of pain points and trigger events.
Pain Points and Trigger Events
Nothing brings the point home (no pun intended) about change than pain points. When management or stakeholders to not embrace the necessary change, it most likely because they don't understand the pain associated with the way things are taking place now. As far as they are concerned everything is fine. And until we can show them (and convince them) that the pain is real they probably won't change their point of view. Think of it this way: many people wait until the day before (or the actual deadline date) to submit their tax returns. Why? Probably because the don't really feel the pain of doing their taxes until it is absolutely necessary. It is only after they feel the pain that they will do what is necessary to get it done.
So how can we use this to promote change? We need to not only understand the pain (which we already do) but how to get management and stakeholders to also "embrace" this pain.
The COBIT(® 5 framework from ISACA addresses the key points of pain points as a mechanism to drive change and continuous improvement. While ISACA's focus is on why to use COBIT in an organization as a mechanism to improve their IT governance, we can use the same pain point and trigger point principles to help better convince stakeholders that a change is needed.
Lets look at some typical pain points experienced by an organization:
- Failed IT initiatives
- Rising IT costs
- Perception of low business value for IT investments
- Significant incidents related IT risks
- Service delivery problems
- Failure to meet regulatory or contractual requirements
- Unsatisfactory audit findings
- Hidden or rouge IT spending (shadow IT groups)
- Resource waste
These are just a few pain points to consider. Are there any other pain points in your organization?
Now lets talk about trigger events? Triggers are events that happen and can require the organization to need a change. Example trigger points include:
- Merger, acquisition or divestiture
- Shift in the market, economy or competitive position
- Change in business operating model
- New regulatory or compliance requirements
- Major change in technology
- A new CEO, CIO, COO or CFO
Recognize any of these trigger events?
As an IT transformation consultant I've used pain points and trigger events to better understand "why" a change is required. The difficulty sometimes is not only to identify the points and events but to convince the stakeholders that they are indeed problem areas they need address. I've found it works best if I work with the help the stakeholders identify what these issues are themselves. A sense of urgency can be created within the enterprise that is necessary to kick off the change effort. This provides a platform for introducing further changes and can assist in gaining widespread senior management commitment and support for more pervasive changes.
It is critical to obtain commitment and buy-in of the board and executive management from the beginning. To do this, the need for organizational change and its objectives and benefits need to be clearly expressed in business terms. The correct
level of urgency needs to be instilled, and the board and executive management should be aware of the value that a well implemented change initiative can bring to the enterprise as well as the risk of not taking action. Once the direction has been set at the top, an overall view of change initiative at all levels should be taken. The wider
scale and scope of change need to be understood first in hard business terms, but also from a human and behavioral perspective. All of the stakeholders involved in or affected by the change need to be identified and their position relative
to the change established. Use pain points and trigger points to secure stakeholders commitments.
This article is published as part of the IDG Contributor Network. Want to Join?