Change Management and IT

In IT, change management often means making the client go through bureaucratic hoops to slow down the change requests from the users. In my reckoning, a lot of times the change request system only worsened the situation: it led to the software developers feeling more powerful and the customer feeling more alienated from the development process, since the product ended up being the way the developer wanted it. This problem always bugged me. I tried to think of a different way to do change management, but the literature on this was all based on technical solutions (ie, creating procedures and forms to manage user expectations).

Years later, I would encounter the same phrase -- change management -- in MBA school. But the way it was tackled in business school used a different approach to it. The first principle they taught us about change management was: "You can't manage change."

That's because change is dependent upon the people involved in (affected by) the software development process and you can't manage (control) people the way we manage furniture, or printers, or office supplies for example. (And for that matter, can we even really manage how employees use office supplies and printers?) People are the X Factor of management. That's why business school distinguishes between managing and leading.

Managing is about seeing what we have, preserving status quo, and optimizing what we have. Leading is about seeing far ahead, seeing more than what we have, and guiding people towards that vision.

In their book Leadership on the Line, Ronald Heifetz and Martin Linsky argue that the usual management problems require technical solutions to solve, but change requires adaptive solutions. Technical solutions are those we do by the book or were taught to us in school or from the company manuals. Adaptive solutions are more challenging because they require us to understand the environment and experiment (ie, "to adapt").

Leading people through change is an adaptive skill. It is about knowing the people well and how to influence them towards a certain goal. It's not about position or authority. It's about selling a vision of change to the people affected by the change. It's about empathizing with those who stand to lose a lot from the change you are introducing. It's recognizing that they have emotional attachments to tightly held values and traditions about how they did things the old way and how that mattered to them.

Sounds crazy, right?

But think about it. All software development involves leading users through change, often difficult change ("What if I become redundant if this new computer system gets popular?"). But what is an IT expert's usual response to resistance to change? "Give them the right training and a user manual, and they'll stop resisting."

Training won't always work, because some users may be attached to one way of doing things ("My dad was an accountant for 50 years and he taught me how to do this in columnar pads."). And change always requires a learning curve that forces people to jump out of their comfort zones ("This is just more work for me.")

I've seen and heard all kinds of excuses and expressions of resistance. But most of them stem from the few patterns that I mentioned above (more of these signs of resistance in future posts). If you ask me the key to change management and resistance, my quick answer is "Plan and Persist." (And more about these, in future posts, too).

How about you? What signs of resistance have you seen and how did you work around them?

IT Management Lessons

I started working in the field of IT in 1987, teaching computers while studying at the University of the Philippines. Then, I became a desktop publication designer and eventually a web developer and software programmer. Now I run a consulting business that provides IT strategy advise and software development.

I have picked up many lessons along the way: on things that work and things that don't in software development, in running a business, and in developing an IT strategy and plan. My goal for writing this blog is to help others avoid the mistakes I made, and to start the dialogue on how to change the IT landscape. I want us to look at the way we do things and ask ourselves how we could make them better.

Much has changed in the field of IT and its customers. In the early days, IT resembled more of a religion. Practitioners -- analysts, programmers, and system administrators --  were the only ones who knew the truth. Mere mortals (aka the users) had to grovel and please the gods in order to get assistance. And if users were not worthy enough, they deserved wrath and punishment.

Here's one hint about the old world order in IT. When the internet began to boom in the mid-1990s, system administrators traded anecdotes about stupid customers, like the ones who forgot to turn the power switch on, or the ones who didn't have a modem but still tried to dialup. I am guilty of trading those stories too, since I personally encountered them.

Today, in a very competitive market, customers have become more demanding. They have more power. Because there is more competition, customers could switch to the competition more easily. In the Philippines, Manila developers compete not only with Indian developers, for example, but also with developers in the provinces.

Non-IT businesses have realized that in this arena, what will set them apart is to offer better customer service and better products. IT businesses, however, are only belatedly and begrudgingly acknowledging this new competitive environment. The result is that we still run in an environment and create products that are:

• Not user-centric.
• Averse to communicating and building a relationship with customers.
• Inflexible to change.
• Promise too much but unable to meet actual requirements.
• Often delayed and costly.

We want to keep the illusion that IT experts can never wrong or can never fail. This causes a lot of stress. But the more damaging result is a shared sentiment among our customers that IT practitioners are not reliable and are overpaid arrogant bastards.

For a period of time, I thought that only I felt the same way about my field. And then I read about the interview of ArsDigita founder Philip Greenspun (Founders at Work), who also complained about the arrogance and lack of customer-focus among software developers. Greenspun asserted that real engineers (ie, civil and electrical) talked to their clients and involved them to create solutions that solved the real problems of the customers. That's a far cry from what's happening to the IT industry today.

Creating change in the IT industry will take a lot of work and a lot of re-examination of ourselves, our attitudes, and our behavior. I believe we can do it, partly because I've worked with and met many IT people whose mindset and behavior prove that there is hope.