By Edan Puritt
What’s in the past is behind us
In many ways I have historically treated Change Management as analogous to the use of artillery. Salvo after salvo was needed to soften up the enemy, our users. Once the resistance was reduced, we could send in the project troops. This approach worked. Without that bombardment, it rarely worked. In meetings, I would talk about ‘tilting the project field in our favour’, or ‘changing the current so we could swim downstream instead of upstream’. In each case, the net effect and premise were the same. I was going to be doing something to my users, and I needed to prepare them. They had to be softened up to accept the change I was about to inflict. Concurrently, I was multi-tasking, which is my way of justifying the fact that I am easily distracted. (Look, a squirrel!) At one point in a conversation with a friend about why I enjoy my work so much, I described my access to learning the business processes of all the different clients as essential to the success of these projects. It wasn’t so much that a light went on at that moment, but rather a slight buzz sounded. Something in my well-ordered project planning process was amiss.download movie The Space Between Us
Information Asset Management – project planning
Initially the buzz wasn’t loud enough to distract me. I continued helping assorted clients in various industries make the most effective and efficient use of their information assets, while I continued learning all the time. I was understanding how and why those information assets were needed, created, maintained, shared, and disposed of. As I thought back on the projects I have enjoyed most, they almost always were projects that required great levels of detailed understanding of the client’s use of information. Eventually the buzz grew loud enough that I had to stop and re-examine my understanding. I realized it wasn’t just understanding the client’s use of information, there was another step. I was most effective when I understood and made decisions based on my clients’ business needs. And then the light went on. When my projects had Change Management, I was engaging the business, and when they didn’t, I wasn’t.
The light goes on
The success of a project was not predicated upon my bombardment, but on my exposure. The projects were more successful when I was listening to the business needs. Listening meant I was configuring software and processes, as well as governance as required. It had nothing to do with my preparation of the organization to accept something I wanted to impose. It had everything to do with my openness. I had been in the right places, but for the wrong reasons. Exposure to the business was so valuable, that even the small amount I had allowed myself to be exposed to, had made a difference. And what happens now when I actually plan to engage and absorb? When I don’t parachute a governance structure into place because I don’t see one, but rather ask how the culture of that organization ALREADY governs itself? When they are actively invited to share, they are receptive to learning too. I can then assist them in applying their models to the new tools and technical environment. Likewise, I ask and learn how they have evolved to their current effective business processes. Understanding the how and why of their operations, I can then marry that knowledge of existing systems to an environment that allows increased efficiency. My starting point now is discovering who in an organization is already sharing information (often without their knowledge), and then I help those individuals become more effective.
Finding an antidote to institutional infection
IM/IT technical solutions are almost by definition sterile. They are a combination of code and functions, awaiting design and configuration. And that is, in essence, why many IM projects fail. We professionals are so intent on inserting the technology into the life and body of the organization that we fail to recognize that the technology is inert and the organization is organic. In the end, much like any organism, the body treats the technology like an infection. Anyone of us who has tried to introduce IM solutions into an organization understands what it’s like to be treated as an infection. The technologies that are introduced with the least amount of accommodation to the organization, meet the most resistance, and vice versa. The people who provide the value functions that are the business intuitively understand when there is an infection that must be resisted. And how do we IM/IT professionals respond? Usually with coercion. We seek steering committees and champions who have the authority to coerce the business users into, at best, acceptance of our sterile solutions and, at worst, into acquiescence. It goes without saying, the more foreign the change, the more coercion is required.
Collaboration and business-based decision-making must lead the way
However, silence is not agreement. Coercion is not a long term strategy for success. Collaboration is essential to effective knowledge transfer. If I, as an IM/IT specialist, am in charge of designing the technology, it will fail. If the business is in charge, it has a chance to succeed. The business must tell us what they need to do. From there, I must configure solutions to meet those needs. How often have we heard of failed IT projects that used technology to try and re-engineer a business process?
More lights go on… related to Agile methodology
I even misunderstood why building large projects piece by piece was more successful than structuring projects to deliver with a big bang: Agile vs Waterfall methodology. By using an Agile approach, I thought I was reducing risk and delivering value tied to expenditure. In reality, piece by piece, I was able to engage each business unit. In that very process, they were influencing my thinking and behaviour. I was still using all the understood IM rules related to information architecture, and information life cycle management, but I was providing consistency and leveraging information assets between business processes, not just IT components. The early small wins were not just a way of introducing enterprise level change, they were exactly what they purported to be, ‘wins’ for each business unit. In leveraging the effort, resources, and expenditure of each business unit (information asset management), it was easier for each successive business unit to win. Cumulative wins meant the enterprise level project would succeed. Again, it wasn’t just that the IT components integrated seamlessly. Rather, each business unit, in the end, would be able to do its job more effectively and efficiently by leveraging the information assets of other business units. Units and individuals were sharing knowledge, even if they didn’t know they were. Think of an author: an author shares knowledge by writing a book in absolute ignorance of who will read it.
Why Information Asset Management through Change Management is FUN!
Working in detail, in each business unit, allowed me to learn how they work, how they share, and what they need to accomplish. There is absolutely a direct relationship between Change Management and the success of an enterprise project. Similarly, there is absolutely a benefit to implementing a system-wide IM project following an Agile approach. The key, however, is to always involve the business. Indeed, it is critical that listening to the business be my first step of engagement. From there, I can enable a project’s success. When I start by listening to the business, I can understand the culture and organization. I will see opportunities to enable efficiencies and greater sharing. I will strive to include early adopters and inherently well-functioning units in the early stages to get those early wins. I will make Change Management be based on the business needs, not just the client’s use of information. That’s what makes this work so rewarding. That’s what makes this work so much fun.