The current version at the financial institution is a Windows based GUI (graphical application based). The proposed version was totally web based. After a business review that included a field study and cognitive analysis, I discovered that both the current and the new software didn’t meet the business needs. In fact the current version required lot of manual entries and was highly error prone while the new version would not address those issues and would, in addition, require three times more user action.

I soon made my client aware of this. The project manager, who is from the information technology department, reacted by saying the project scope is to make the transition, respect deadlines and budget. Meaning he does not want to change the plan. Information technology department even contested my findings and required me to demonstrate the facts again. After revisiting my findings they realized that the situation was even worst than they expected it. In the end, the financial institution followed my recommendations because the facts were rock solid and we found a solution that would integrate existing technology already in use at the financial institution.

Sounds familiar? Many IT (Information technology) projects are planned and scoped before analysis or field study is done. In many instances, the justification is a technology replacement or and upgrade. Over the last twenty years I devoted my consulting practice on project turnaround and I encountered hundreds of similar situations.
Last year I attended a three day PMI (Project Management Institute) training camp. What amazed me the most was the widespread acceptance by the PMI community of the irony of planning and estimation for software projects.
Here is the problem:

To estimate a project, you must first know the amount of work required to complete the project. To build two (2) kms of road will require twice as much work than building one (1) km.
In a software project, the amount of work is defined by what (the functions) you will build. You will have a good idea of the functions you will build after the functional specification phase. Since the functional specification is usually done after the planning and estimation, you get the information you need to estimate the project after the project is started. It is a bit like if you have to plan and budget the medical treatment before the diagnostic is done.

I can assure you that in physics, my previous career, you would get fired or put aside fairly fast if you come up with something like this.

What is more, estimation at the planning stage is guesswork. In PMI methodology, they mention arcane techniques such a point of function method or historical data or some other combinations but again, this is, in my view, a sophisticated cover up for guesswork. Yes, there are calculation methods but the input assumptions are based on human judgment (guess). Those judgments vary from one person to another. Often, the estimator does not have any ideas about the business and operations. For example, in the Government of Quebec, software architects estimate after meeting user’s representatives that previously met business analysts who never met end-users.

Typically, once estimations are done, budget, scope and timetables are established. The board approves the budget, people are hired and project execution begins. If you discover in the course of the project that real business needs differ from what you planned, the story above is repeated. The project manager will tell you it is out of scope. Or he might say your new findings could be filed as change at the end of the project. Remember, he is hired to execute the plan even if proven wrong. Isn’t he?

There are solutions:

1. Do you ask yourself if the application you are using (email, office application etc) is in Java, PHP, C Sharp, etc? Most of us will answer “I don’t care”. In fact, 100% of the user experience (UX) is provided by the user interface (UI). So why not start the project by the end. Why not design and test the user interface before the project is established and a budget is set. Then you will know what to build.
2. Look at other industries, such as automotive or aerospace. They all start by verifying their biggest risks first. When Airbus or Boeing want to develop a new airplane, they build a large-scale model, display it at Bourget salon and take orders even if the plane does not exist. If there is not enough order, they will cancel the project. Car manufacturers, design clay models, present those models in a show room to verify if the client will buy it. Then they will plan production. So both automotive and aerospace start by the end.
3. Remove red tape and bureaucracy. Allow direct communication between developers and users
4. Invest in continuous business analysis processes where field study (ethnographic study) is part of the culture. To my knowledge, the best approach to do business analysis is the cognitive approach.
5. Budget business analysis and diagnosis throughout the operation on a continuous basis.
6. When executing verify risk by simulation, experimentation or calculation.
7. Allow information to circulate though project by keeping project size small

This graph shows the evolution of George W. Bush’s approval rating over time. His approval rating rose to 68% in March 2003, at the beginning of the Iraq war, and declined steadily after that. It is now at 26%. Not only did the war not proceed the way he had told people but there is a growing number of Americans questioning the idea of going to Iraq in the first place.

How to lead?
First: be right
No matter how good you are at executing and communicating, and how much charisma and resolution you have, if you are wrong, you will fail. Churchill was resolved but he was right. In the hiking story above, the leader was sure of himself but wrong. He overestimated how lost we were.
To be right, you need facts.
In real life, we do not know with certainty the actual situation. In the context of uncertainty (most real life situations), the more certain you are the more likely you will be wrong. Facts are even more important in uncertain situations. Why? What you know and what don’t know are facts. ”I am lost in the forest” is a fact. If the leader in the hiking story would have admitted the true level of uncertainty about how lost we were, he could have proposed a series of tests. For example, he could have propose a short walk in a different direction to gather more facts about the current location. A negative result would then have been seen as new information on where not to go instead.
Second: Communicate facts (reason for change)
It is very difficult to convince people to change something if they are not convinced about what the problems are and their urgency, see John Kotter. Two economists might disagree even if they use the same economic model. By separating fact from opinion, we might understand the input or assumption and understand why those economists disagree. Whenever you make a decision where people must follow your lead, facts are the essence of getting people agreeing on the current situation and the course of action.
In business transformation (change Management), facts are more than data “Not everything that counts can be counted, and not everything that can be counted counts.” (Sign hanging in Albert Einstein’s office at Princeton), facts are like an observable situation that can be described and shared.

Once facts are gathered and separated from opinion, they can be shared during working sessions. Those sessions permit the group to agree on problems. Consequently, it will be much easier to get the group to agree on a course of action once they have agreed on the problems. During those working sessions, the focus is first on the current situation, not the course of action. Ensure everybody that they are respected and never discard people expressing bad news (don’t shoot the messenger). Often they might be your best source of facts. To ensure the free flow of information, remove red tape, formal presentation and favor a more informal organization with a high degree of respect, see ‘‘The Death to Bureaucracy” from Jack Welch.
Third: gather more facts
Often, you need to collect more facts. Creativity and imagination are required to gather facts. For example, in the above story, a series of short walks in different directions is an approach to gather more facts on the current location. Gathering facts is boiled down to: observation, experiment, calculation and simulation. Fact gathering is not a consensus driven process. You are collecting evidence. Never rely on opinion. Humans are biased and opinions rarely correlate with facts.
In business transformation initiative, the best sources of fact are field studies. The field is rich and wild; people develop very sophisticated tactics in real work environment. Knowledge lies in the field, not in meeting rooms. The worst source of facts is the traditional hierarchy : line manager, director and executive. Facts gathered through this path will surely be altered, trimmed down or hidden.
Fourth: prevent bias
Facts may be distorted. When relying on human sources, multiple independent sources are required. Be careful with surveys or focus groups, they do not gather facts but opinions. They provide the tip of an iceberg. Avoid group meetings. Groups are only good to solve problems, to brainstorm or share information.
Objectivity does not exist; you have to cope with that.
No matter how good the information is, if you are biased, or already convinced of the answer, you are in danger. A bias could, for example, lead one to accept or deny the truth of a claim, discard evidence or look for evidence that confirms a preconceived idea (confirmation bias). In the hiking story, the guy seemed so sure of himself that we trusted him even if the direction he gave did not ring a bell to us.
To reduce bias, observe yourself to see if you feel emotional. You need to detach yourself. It is well known that a lawyer should never defend himself or a medical doctor should never diagnose himself. Ask different persons in a one on one session to interpret facts. Don’t give them your thoughts. Observe the difference in their interpretation. Try to think as fresh as you can. Gather all facts prior to a decision. In order to avoid bias, good investigators will collect evidence and then conclude. After all this work, let the decision emerge naturally. If you still do not feel not comfortable, your instinct will tells you there is something wrong, listen to it. It means there are still uncertainties that you have to work with, or simply wait.
The four steps described here relate to making the right decision and communicating that decision (vision) to a group of people. Once you have the right direction and a group of people agreeing with you on the course of action, executing change is a piece of cake.
Leading people in the right direction requires hard work, time, experience and wisdom. You can get there faster by practicing the right thing. For more on the subject, I suggest reading John Kotter on this subject and “Engineering psychology” by Christopher Wickens.

The levels at which impacts of change are major are not understood while the levels at which impacts are minor are easily understood.

Why?

Most managers believe people resist change because humans have a natural desire to keep the status quo. They believe that resistance to change is a defense mechanism caused by frustration and anxiety. With this diagnostic, executives belief that good change leadership comes with a strong message from the top, effective communication plan, mandatory training and sometimes, removing undesirable parties that are labeled as strong change resistant.
In fact, Individuals aren’t really resisting the change, but rather resist the loss of status, loss of pay, or fear they will not be able to achieve the same level of performance. While causes of losses of pay or statuses are visible, causes impacting performance involve factors at the unconscious level that are difficult to communicate.
We observe that in many business transformation initiatives those fears were justified. New processes would not permit anymore efficient tactics evolved over years of trial and errors.
How can we distinguish between fear and facts?
First, let’s look at the nature of change in human work, the impact of business transformation initiatives and to finish, what to do about it.

Why change is difficult in work setting?

Change happens on an individual and organizational basis. Change is everywhere: mergers, new policies, new technology, new management . . .
Employees resist change because they have to learn something new. They fear the unknown future and their ability to perform.
The unknown comes from subtle and nonverbal aspects of human work that are difficult to communicate.
The nature of work
Jens Rasmussen observed that human work is either at: the skill level, rule-based level or knowledge level. Don Norman also came to the same conclusion.
When driving a car, turning the wheels is at the skill level while letting the other car passes at the intersection is at the rule-based level. Deciding to choose a route over another one is the knowledge level.
In addition, we observe that there is a fourth level, usually called “meta-cognition” but I prefer to use “wisdom”, which involves self-awareness about our own limitation. For example, if tired or drunk, hopefully, we might decide not to drive.
Any human activity: tasks, sport, arts or leisure lies within those levels.

The impacts of change

Changing something at the knowledge level is relatively easy. If someone shows you a better route to go somewhere, you only need to understand the advantage and good indications and voila, you can execute the change.
At the rule-based level, it is a bit more difficult but manageable. For example, if the state decides to change the law and permit right turn on red light, an action previously forbidden, at first you need to pay a little bit more attention to apply the new rule. You may even forget to apply it but with little time and patience, turning on the red light will become natural.
The real challenge is at the skill level. Let’s say the car manufacturer decides to invert the position of the break pedal and gas pedal. It will take you months of practice and you might make many errors that might event kill you. Change will be very difficult to accept and you might express a high degree of frustration. You will certainly not use this car if you have the choice.
Those examples show that: efforts to execute a change at the skill level are much higher than at the rule-based or knowledge based level. The level of energy required is dependent of the level of work affected by change: being at the skill, rule-based or knowledge based level.
Convincing a golfer to change his swing is a much more difficult challenge than convincing him to change club number to reach the green. It requires much more energy to acquire the new swing.
The proposed law of change:

“The effort to execute change will be equal to the amount of energy required to execute the same level of performance.”
“The amount of energy required to change is the highest at the lowest level of wok affected”. Skill based being the lowest level while knowledge based being the highest level.

Business Transformation

In business transformation initiatives, people only understand impact of change at the knowledge and rule-based level but not the ones at the skill level. Skill level is mostly non-verbal and unconscious.
For example, during a word processing task, users might select backspace to delete few letters or they might select the mouse to delete a paragraph. The choice is usually unconscious. This is a good example of a natural way humans optimize energy. According to the keystroke model, it takes 1.2 seconds to delete 6 letters with backspace and it takes 2.6 seconds with the mouse.
Now, let’s say a vendor convinces management to adopt a new word processor. While nicer and with more features, it doesn’t permit using backspace anymore. It is likely that this subtle change would be unnoticed even during a demonstration. Only after implementation employees will complain and express their frustration. As good performers, employees will be frustrated because they cannot achieve the same level of performance. They might even express anger.
This is only the tip of the iceberg. In fact, in a real work setting there is a myriad of such optimizations tactics: being a particular noise, a visual clue, a physical arrangement, a specific sequence…

What to do about it

There is a science, Cognitive ergonomics (called Human Factors in USA), which permits the understanding of human work at all levels including the skill level. Cognitive task analysis permits gathering both verbal and subtle non-verbal operations such as eye movement, cognitive processes and unconscious manual movements. Understating work at all levels permits the understanding of the impact of change at all level of work.

Managers can stop managing change with brute force.

First: stop doing endless meetings and politics and go in the field. Wake-up and forget the meeting rooms, the real world is in four dimensions.
Second: do a field study and cognitive task analysis to fully understand the current situation. Field is rich and wild; people develop very sophisticated tactics.
Third: select a solution or design a new system that will permit skill transfer, keep efficient tactics and strategies and remove problems.
Fourth: before any implementation and at the earliest stage possible, design mock-ups, simulate and test them in the most realistic manner as possible. This is even truer with physical devices because there are so many subtle interactions with the environment.

Easier said than done but at least try to change the change management practice if you want to bring change in your organizations.