When you implement a change management process in your company for the first time, it’s a change of culture, , , and changing culture is very, very difficult.
In my last post, I showed you two change management processes, , , well, at least one of them was a real process. The other is what our clients would like us to do, , , give us the request verbally and the hope we march off to our little IT world and create the result for them.
I call this an “ad hoc” process, and many IT organizations operate in this mode. It’s very prevalent in small and medium size companies and not so unusual in big companies as well.
When you introduce a process change, it can be a real culture change because, “That’s just not how we have been doing things here.” You might also hear things like, “That won’t work for us.” or “We have been doing it our way for years and it seems to have worked pretty well to this point.”
What “seems” to work well may in fact not be working well at all if you were to conduct an honest and objective assessment with your clients. Many times the IT organization believes they are doing a good job when they are not.
Let’s take another look at the programming support change management process we discussed in the last post:
There are four parts where the client must spend time and effort that might be new for them. If they haven’t been participating in these steps already, there will be some level of kicking and screaming as you pull your client into the process.
That’s right, , , there will be resistance!
The four components are steps 1, 2, 4b and 5. Each of these steps require your client’s involvement and guess what, , , your client does not want to be involved. Your client just wants you to “do your job” and what that means to them is that you do all the work without them having to be involved.
In a very small company, the client being minimally involved might work; but in a company of any size with lots going on, this method simply doesn’t work well for you. More importantly, it does not work well for your client! Remember, the main reason we want to introduce a change management process is to help us do a much better job in supporting our client.
Let’s analyze why your clients don’t want to be involved:
- Clients view the work as an IT responsibility, not theirs.
- Clients don’t understand technology nor want to.
- Clients don’t want to do the extra work.
- They resist change imposed by IT.
Let’s take a closer look at this last one, “They resist change imposed by IT.” Clients have a natural resistance to anything that comes from their IT support organization. Many times, they view you as not being part of the core competency of the company whereas they certainly view their own department as being a critical part of that core competency.
Clients see IT as always forcing change upon them and often do not understand the change, , , they see IT as a group that constantly does things that makes their job more difficult.
Another key reason for all of this is that many of your clients are high detail people, just like you and your people probably are. High detail people resist change.
4 steps that require client involvement
1. Define the change request,
It is difficult, if not impossible, for you to deliver what the client wants unless you know exactly what the client needs. This means you need specific definition of the request and that means someone must document the specific programming changes needed to address the client’s issue. A good Business Analyst can help the client do this, but a BA should not work on this alone.
2. The client must review and approve requests
IT should not take requests from everyone in the company. Department managers or designated leaders in their department should review and approve requests to be submitted to IT. This insures the right hand knows what the left hand is doing and will minimize duplication of requests. It also gives the department an opportunity t verify the request is worthwhile.
3. Clients should prioritize the work to be done
Get ready for major kicking and screaming. I’ve never seen many clients want to be involved in this part because it takes time and they think IT should take care of it.
The problem is that the client is in a much better position to determine which requests are most important for their department, , , not IT.
Certainly, IT must sit at the table of a committee assigned responsibility to determine programming priorities and even be able to influence some of the decisions that help the programming staff improve productivity. But the key piece of this is that our programming priorities should be driven by the business and not by the IT organization.
If you allow the IT organization to be solely responsible for determining programming priorities, it will be easier, , , however, you can never win when this is the case. The client will constantly believe you should be able to get more accomplished for them and will be frustrated with IT programming support.
4. We need a user quality assurance (QA) function
To be the most effective, we need a knowledge expert involved in the QA process from our client, not just an IT testing effort of new software changes. Be prepared for mor kicking and screaming, , , your client wants no part in this but it is also a critical component to help your team be the most productive you can be for your client, , , the real winner is the client.
Positive outcome
The results can be significant. Your team will get more work done for the client and the client will be in much better control of their own destiny. It’s something they want, but they probably won’t be able to see how all of this gets them there. What they will tend to see is that this is just a bunch of extra work with no guarantee things will get any better.
I have never had a client organization sign up for a new change management process without some level of concern or pushing back. Expect resistance. The good news is that over time your client will embrace the process and see it simply as a way of how we get things done.
In some of my travels, I’ve seen this type of process working well in a company and when I asked the clients about it, they always tell me, “It was hard at first, but now we wouldn’t think of trying to work without it.”
A structured change management process is well worth the effort. Don’t be discouraged by early resistance, , , expect it and persevere through it because the benefits are well worth the effort to get there.
ITLever™ 