Change is Inevitable, Be Good at It

In many organizations change management is an underdeveloped capability. Organizations with weak change management processes suffer from unnecessary churn in their development engine, increased frustration of team members, poor feature mix, and negative outcomes for time, cost, and scope of development.

So, what is change management and what makes a good change management process? At its core, change management is a process for evaluating proposed updates (change requests or CRs) to a plan of record. A good change management process has several characteristics:

1. Well Defined: a change management process must be well defined and documented in a single source of truth repository. Everyone should understand their role, required inputs, outputs, and escalation paths. Timelines should be transparent.

2. Consistent: Every change to the plan of record must go through the same process—no exceptions. Skipping steps may feel expedient but usually creates bigger problems later.

3. Efficient: Change requests have a shelf life. Teams need to analyze, cost, and respond quickly so leadership can act while opportunities are still relevant.

4. Reliable: People must trust the process. Routine, repeatable, and efficient evaluation of change requests builds confidence in the results.

5. Quantifiable: Change management is about evaluating cost and benefit.

   • Cost: measured in time, money, or scope.

   • Benefit: measured in dollars, licenses, or goodwill (the hardest to quantify).

   Requesters should quantify benefits; delivery teams should quantify costs; managers should prioritize based on the best benefit-to-cost ratio.

6. Transparent: Requests and their status should be transparent to all stakeholders, including any documentation generated in evaluating the change request.

7. Documented: A paper trail is critical for accountability and closing expectation gaps. Each request and decision should be recorded and accessible so all parties understand what was agreed to.

Like any process, change management takes practice. When first implemented, it might spark pushback from teams. For example:

• Sales teams may resist quantifying benefits. For example, a salesperson may claim a feature will sell 10,000 more licenses. A solid process forces the question: which customers? what percentage of the base? is there a commitment to buy?

• Engineering teams may resist T-shirt sizing, preferring detailed estimates. But thoughtful T-shirt sizing can be nearly as accurate and far more efficient.

As people and teams practice the process, however, they will experience and understand the benefits.

Another common challenge: missing inputs. If data is incomplete, the process should stop until required inputs are gathered. At every stage, the status of the CR must remain clear to all interested parties. 

Ultimately, once costs are assessed, management decides on the priority of the requested change versus other aspects of the existing plan of record. This allows management to understand both what they would be getting, but just as importantly, what they may be delaying or dropping. In many cases, after evaluating the cost of a CR, management will decide on no change to the plan of record, and that's OK.

Tips and Techniques

• Define a change management process—write it down and make it easily accessible to everyone.

• Apply the process consistently to all changes.

• Quantify both costs and benefits.

• Evaluate all inputs and outputs of your change management process. The goal is to get to a realistic cost / benefit analysis quickly.

• Keep requests visible, documented, and version-controlled, even when working with external partners.

• Once a change request has been costed, ensure all relevant Deciders[1] are involved in approving, postponing, or rejecting the change request.

• Practice makes perfect. The more closely you adhere to your change management process, the easier it will become to evaluate each change request.

  
  

[1] "Decider" is simply shorthand for a person with whom making a decision ultimately lies. For example, an executive with budget would be the decider for a purchasing decision.