Have you ever wondered who invented the phrase “not invented here”? I have. To me, it is art in fifteen letters. A mere three words encapsulate a train of thought that for thousands of years has prevented good ideas from sprouting roots in fertile grounds. If there was ever a candidate for the Nobel Prize for Succinctness in Human Thought, this one would certainly make the short list.
The concept is simple – human beings have egos, and one of the behaviors driven by ego is the negative reaction to the possibility that someone else might know of a better way to do something in an area which falls under your sphere of responsibility. Some people will tell you they are immune to such emotions, but in reality all they are doing is repressing them. However, repressed emotions do not disappear – eventually they must be released in one way or another. Unfortunately, that usually takes place well past the point when those emotions should have been recognized and addressed.
The consequences of failing to identify and address these emotional roadblocks during a process improvement initiative can range from skepticism (which in and of itself is not unhealthy if its motivation is aligned with the goals of the initiative) to full-scale war, complete with hand-grenade management skirmishes (where teams or departments purposefully sabotage others’ work to derail the initiative), or worse.
Because process improvement through the use of ITIL® best practices is fundamentally an exercise in transformation of culture, all of our work as ITIL advocates and consultants is threatened by the “Not invented here” syndrome. No one likes to be told that their ideas are not working. For someone with a strong ego, hearing that management believes someone else outside the organization has better ideas to fix things can be akin to piling insult on top of injury. A strategy to address this “show-stopper” risk must be part of our toolbox, and it is of vital importance to ensure that our clients clearly understand that we as consultants cannot successfully overcome this challenge without the strong participation of management at all levels of the organization.
The point in time where you must identify the extent of the syndrome is during the initial maturity assessment, as part of the analysis performed to identify all the potential risks that could endanger the success of the process improvement initiative. It will not take long to identify the symptoms as you interview the IT staff and management. Make sure you keep good notes of your findings, because you will need them.
That is the easy part. The hard work comes during the visioning and implementation phases of the process improvement initiative. In my experience, there are two fundamental ways to address this.
First, it is important to understand that as a consultant, your job is not to do the work and create a relationship of dependency – that is what a contractor does. Your job as a consultant is to pass on knowledge, empower the organization to improve and guide them along the path to success. Do not make the mistake of allowing your own ego to interfere with your work, or the manner in which you engage with the staff. Remember that managing is about telling people what to do, but leading is about inspiring people to achieve common goal as a team.
Second, remember that one of the best ways to gain buy-in and commitment in a situation like this is to create pride of ownership. This is not your initiative – it is theirs. When it is all over, you will move on to the next assignment, but they will stay. You must ensure that they feel that any success will be theirs to celebrate, with the accompanying rewards. The implication must also be that any failure will also be theirs to suffer, but emphasis on the positive is more effective than fear of the negative.
If there is a choice as to who will take credit for positive results, the decision should always lean towards the staff, not the consultant. On the other hand, when things go wrong, playing the blame game will not help. Instead, analyze the issue, find the root cause, correct it and move on. Always separate the people from the process. Guide the staff towards the solution to the issue and let them take credit for that as well. Of course, this also requires you to disassociate your ego from the work, but remember that if the IT staff is successful, you will be successful, and senior management will recognize that.
As always, the point of my blogs is to get readers to think, rather than provide ready-made answers, because I will be the first to admit I do not always have them. Feedback on my blog entries is always welcome!
(ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.)