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…

DAD Inception Phase Workshop Agenda

Disciplined Agile Delivery (DAD) realised the reality of the projects and introduced back phases to Agile community. Whoever works in a project based company, especially a project based company where projects are usually less than one year in length and each are for different clients, understands the reality of Agile in such environment. When you start working on a new project for a new client, it is essential to go through a phase that you get to know each other better, to understand the business purpose of the project, to understand the scope of the project, to know what are the high level architecture and what technologies are going to be used and who is the initial team, and if funding is available and also when things must be delivered and to whom.
In answering these questions you may need to meet with different people, run couple of workshops and brainstorming sessions. And this is called Inception Phase. As DAD is more like a goal oriented decision framework and not a prescrip…

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.

Ha…