Skip to main content

Fundamental of Change Management

The most powerful tool of any agile or lean methodology is continuous improvement. And continues improvement happens only by observing, evaluating, learning and experimenting in a safe to fail environment. Although every change is not improvement, but every improvement is a change. Therefore, changing is the only thing that doesn’t change in an environment that embraces a culture of continues improvement.
Because change is inevitable, Therefore it is crucial for everyone to be aware of the fundamentals and essentials of proven change management processes. At this short article we will review these fundamentals.
Change and The Goal Of the System
Every change initiative must have a reason. The reason must justify the change, the justification is only valid when it is related to the goal of the system or the organisation or the team.
As there are always limited resources (e.g. time, money, manpower), therefore it is wise to focus only on things that are obstacles between you and your goals. If you spend time on things that have minimum impact or no impact on reaching the goal, then you simply wasted the limited resources you had.
So, we always must know why we want to change something. This is the first step, before going forward. And only then we start identifying the areas that we want to change. When you identify areas that you want to change, only then you need to focus on alternative solutions and choose the solutions that serve you best. When you selected the right solution, only then you must think about how to implement the change. In other words:
  1. Why Change?
  2. What To Change?
  3. What To Change To?
  4. How To Cause The Change?
4 Dimensions of Change
While you are trying to identify what to change and what to change to, you must also pay attention to the four dimensions of each change. Every change can be perceived from four different angles. We know that every change has Pros and Cons, but what else?
Well, it turns out that every change has two categories of pros and cons. If you decide to make the change then you can identify Pros and Cons related to such a change, But NOT changing has also Pros and Cons. So, not changing has advantages and disadvantage.
Therefore, a change can be implemented only if:
  • the pros of changing is greater than its cons;
  • AND if cons of NOT Changing is greater than pros of NOT Changing;
  • AND if pros of change is greater than pros of not changing.
In fact, These are necessary conditions for a change to be successful.
Undesirable Effects (UDEs)
As proven by physics, every action has an reaction, every effect has a cause. In the process of change management when we are looking for areas to change, then we must be careful to not focus on the effect or symptom of a deeper problem. Every negative problem that we see on the surface are the symptoms of the deeper problem. We call these negative symptoms “Undesirable Effects”. These are the negative effects of a cause several layer deeper. In order to decide what to change, we must find the root cause and apply the change to that root cause, so we get the desirable effects that we want.
Span of Control and Sphere of Influence
In the process of change management, we must identify the areas that are out of our control. There are the areas that we can not do anything about and therefore we better to not waste time on changing them, we only need to know that they exist.
On the other hand, there are areas that are in our absolute control. These are the areas that we can implement the “right” change immediately and hopefully get result. We must identify these areas, and therefore make sure selected improvement initiatives are implemented immediately.
Also, there are areas that we can influence. Again, we must know what are these areas and how can we influence them. We may need extra budget in order to cause change and we do not have control over the budget, but we can prepare proposal for the budget holder and help him/her to see the importance of the change.
Scientific Method and Experiment
Every change or improvement initiative is based on a series of hypothesis and their outcome are not alway certain. Therefore, we must look at every change initiative or proposal as a scientist. It means, we must continually test and measure change proposals until they are proved to be the right change. If they proved to not be the right change, then we will need to act and make necessary changes again and create new experiments.
There is a set of simple questions to answer when we decide to make a change in order to apply a scientific method:
  1. What assumptions we had when drafting such a change proposal?
  2. How can we know if this change is successful?
  3. How can we test and measure the change?
  4. What can we measure?
  5. How do we know if the change is not successful?
Post a Comment

Popular posts from this blog

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe.

At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better. The reasons are simple:

It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next!

At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and their fellows can resol…

Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to KanbanFrom High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important. 
Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate. 
Context: A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while, they deploy their …

Collocation is not the silver bullet for success and agility

To collocate or not to collocate? Most companies that are new to agile have been "consulted" by a "Scrum" Agile Coach, who suggested that they must break their organisation and have cross-functional teams to sit together in one location. Is that the recipe for success?.. Is it really?

Even though collocation has its benefits, it is not the necessary condition for a successful delivery team. Collocation as a dogmatic view may hurt you more than you think, and will not necessarily help you to deliver more successful products.

I am neither for nor against collocation, but I have experienced and worked with both approaches. And each sometimes worked very well and sometimes failed. All the variations of teams geolocation (collocated, fully-dispersed, partially-dispersed, or distributed) can work. It all depends on how the collaboration model is setup, what is the context and conditions, and how much the team and organisation are aware of each other, and are aligned.