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.
ITLever™ 