Work Towards Change Enablement, Not Management, to Align With Business Objectives

Many IT organizations take a conservative approach to change, focusing more on the control aspect and less on enabling the business. This approach makes IT less responsive to the business and is often an impediment rather than an enabler.

Businesses are driven by market demands. If a new business capability is required, speed to market is of the essence or a competitor might increase barriers to entry or compete. By balancing the controls with agility based on the risk propensity of the organization, you can provide better service to the organization.

Not everybody is an approver

Let’s look at how the time to market for new products challenged a large insurance company.

In the change process, a manager expected all the stakeholders to approve the IT change ticket one week before it arrived at the change advisory board (CAB). Only then would the manager look at the change was completed and approve it.

Additionally, change required approvals from a wide range of groups ranging from the network, virtual infrastructure, database and security teams. Many of these approvals were rubber stamps that informed a stakeholder about the requested change. These would often keep the change in limbo, and it would be up to the requester to follow up and get these approvals. New product features took too long; business users were getting frustrated with IT in general.

This long-winded approval process isn't prevalent in traditional organizations; it's used at some bleeding-edge digital technology businesses.

Technology and business approvals

All change involves some level of risk. As soon as you introduce a function to an existing stable environment, we risk breaking something that worked before. While testing would help find errors, successful testing can never guarantee the absence of errors. Organizations may also factor in the risk of not introducing the change to the business. Organizations need to enable efficient change management while managing potential risk with appropriate mitigation plans.

Managing risk involves two main checks:

1. Is the change technically feasible?
2. Is the business willing to accept the risk of the change?

The first approval validates that what is being asked for can be done. It checks that the request aligns with the best practices for the technology as identified by the organization or team. It also checks that the steps indicated in the implementation plan and backout plan are correct. A subject matter expert should do this approval within the technology domain. The support group manager, a designate, or a peer can be used to approve.

The client’s change manager helped determine who would be appropriate to provide technical approval in their organization. It was also agreed that the peer review would meet the needs to validate the technical feasibility of the change.

The second approval is validates that the affected business understands and is willing to accept the risk associated with the change. Since every change to the status quo involves some risk, the business must understand the value of the change weighed against the risk it introduces. Often, the business might believe that there would be a greater risk of not doing the change. The business users can be a single person, a department, a location, a division or the entire organization. The service provider or business relationship manager, should accept the risk for the business users they represent.

The client’s change manager indicated that they had business relationship managers for each of the services IT provided. They had their pulse on business needs and risk propensity. In effect, they could speak for the business and thus approve changes on their behalf.

Higher risk, higher approval authority

Not all changes are created equally. Some changes impact a critical business service. Some changes have been executed many times and are considered standard. Some involve downtime when the business can’t use the service. Some have no path back to the original state.

It's critical to have an objective risk calculation methodology so that the level of risk to the organization is identified.

For business approvals, the approval authority required varies with the level of risk. The higher the risk, the higher the level of the approving authority within the organization. If the risk level was low, the business relationship manager might suffice for the acceptance of the risk. However, if the risk level was medium, the approver might need to be a director-level person. And if the risk level was high, the approval might be a director-level person under the advice of a CAB.

It's also important to note that the change manager shouldn't be the person doing the actual approval, even if they chair the CAB.

Start today

Business desires highly responsive IT. Organizations need their IT service providers to be agile to the needs of the business. Having new capabilities, or updates to existing capabilities delivered to the business at high velocity is critical for IT’s alignment and integration into the business.

Complex processes that involve long approval lists, or long lead times often have the opposite effect. Only by streamlining approval to be based on the level of risk and engaging the right people will IT departments be able to achieve this.

• Identify what role needs to assume technical risk – and that person is your technical approver
• Identify what role needs to assume the business risk – and that person is your business approver
• Identify which changes need to get advice from the CAB and submit only those to that group

Think you might be ready to get started? Let’s talk.