Tag Archives: change management process

Part 2 – Changing culture is like pulling teeth

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.

Implement a programming support change management process

Hello from Canada!!

In yesterday’s IT Manager Institute class, we had a very good discussion about the challenges of implementing a change management process. Introducing such a process is a culture change in many cases and trying to change culture can be very, very difficult.

It was such a good discussion, I thought I would write a Blog post about it. In fact, there will be two posts. This first post focuses on creating and implementing a programming change management process. My next post will discuss the difficulties in doing this.

Clients who submit programming change requests for new reports and new functionality want IT to just do your job”.

What this means is that they want to tell you what they want and they expect you to provide it for them. They don’t want to document anything or to get involved in the process, , , they would like to simply tell you verbally what they want and get it the next day.

Unfortunately, this doesn’t work very well, especially as your company grows and there is more demand for programming support.

You need to implement a structured change management process that assists your programming support team in their ability to support their clients.

Understand this, , , when you implement a change management process in a company that has been able to request ad hoc programming changes for years, there will be resistance.  In fact, there will probably be some kicking and screaming, , , it’s not going to happen without some resistance. In my next Blog post, I’ll talk about this aspect.

Your client wants a very simple process.

Simple and no involvement. They simply want to give you a call or tell you in the hallway that they want a report that does such and such, , , and expect you to know what they want, , , and they want it immediately.

It’s hard to be successful when you have to be a mind reader.

Here is a better change management process  that helps your Programming Support team be more effective in supporting their clients.

Let’s break it down into the 5 components identified in the graphic

1. Client fills out a request form.
This can be an online ticket request or a paper document. The key is that the client needs to tell us exactly what they want. Your Business Analysts can be very helpful in assisting your client with this step, , , especially when you first introduce your change management process.

2. A client manager or supervisor reviews and approves the request.
You don’t want to be accepting programming requests from all users in the company. When a manager or supervisor approves a request, it helps reduce duplication and allows the client to filter our requests that won’t be of real value to their organization.

3. The request is sent to the IT Department
In this step, we log the programming request into our programming backlog of all requests and the Programming Support manager or one of his senior people does a quick review to evaluate appropriateness and a quick understanding of the request.

4.  IT estimates and schedules the request
I’ll break this into two parts. First, a senior programmer should estimate how many hours it will take to complete the project. I like to use the same person to do this so we have consistent estimations, , , and I ask the programmer to estimate in terms of an average programmer, , , not our best and not our worst.

Some projects may need a project just to define the work required in order to develop a programming estimate due to the complexity of the request.

The second part of this step is to schedule the request, , , i.e., assign it to a programmer and put into the schedule of work to be done in the coming month. In most cases, you have a lot more work than you can complete in a month, , , so requests must be reviewed and prioritized.

It is much better for the priorities to be developed by representatives of the departments who are submitting the programming requests. If IT is required to be the one who prioritizes these requests, you can never win.

For one thing, IT is not in the best position to determine what is truly the most important of these programming requests, , , your client is. Let me emphasize this point, , , you will not be as effective in supporting your client if you allow your IT organization to determine the priorities of when programming requests are worked on.

I like to put a Programming Steering Committee together made up primarily of representatives of each of the departments who are submitting programming requests. A senior IT person, preferably a manager, should also have a seat at the table and be able to influence their decisions. There will be times when two or three requests should be combined because the coding effort required can be reduced when requests are solved in the same area of the software code.

This part of the process will be very difficult to implement because your clients don’t want to be involved, but it will be well worth the effort once they finally embrace the process and begin to work together to determine the priorities of programming work.

5. Once scheduled, IT programs the changes, tests the software and implements the changes.
Programmers are assigned specific requests based upon their priority and once the programming is completed we test the software both within IT and by the user. Your quality is going to be much better when you test new code within the IT organization and also by a knowledge expert from your client department who submitted the request.

Once we complete the process, the changes are put into production and the client receives the requested changes.

A process like this is a bit more structured and requires more involvement than your client will want, , , but I can assure you the benefits are well worth the effort to implement a change management process like this. Ultimately, the biggest winner will be your client because it will help your team become more productive and predictable.

Be sure to read my next post where I discuss the challenges in implementing a change management process.