Tag Archives: programming support

Understand supply and demand to manage client expectations

One of the keys to success as an IT manager is being able to manage your client’s expectations. There are many other keys to success, but this one is critical.

To manage your client’s expectations, you must know some things about the concept of “supply and demand” and how it applies within an IT support organization.

Demand is the technology support needed by your clients to address their business needs and issues.

Supply is your IT organization’s capability and capacity to deliver IT support.

In most situations, there will be more demand than supply, , , your clients need or want more from IT than the IT organization can deliver. This is normal and exists for most IT organizations. That’s OK, but to succeed, you are going to have to balance the two somehow.

Let’s take a team of five programmers and use them as an example to discuss these issues.

Here, you see we have one great team of five programmers. Let’s assume they all work on the same software application to make our example easier.

The Demand Side
Our demand for programming work is defined by a couple of things:

  1. Day to day support required of the programmers
  2. Backlog of programming enhancement requests

Your Help Desk should give you some sense for the “disruptive nature” of day to day support issues that hinder a programmer’s coding productivity. If you don’t have anything, do a 2-week time study and have each of your programmer’s chart where they spend their time for every hour of the day.

You might be surprised, , , and this simple exercise will tell you a lot about what’s being pulled out of your team’s capacity to handle daily support issues.

Maybe you think your team is totally isolated and immune from day to day support. Don’t be fooled, , , do the time exercise and discover the reality of your situation.

The second part of Demand is detailed in your Programming Backlog. You should have a database of some type (maybe it’s just an EXCEL spreadsheet) that lists every programming request and an estimate of how many hours it will take to program the project.

If you aren’t managing your backlog like this, then you don’t know what your demand for programming is, , , and if you don’t know, you can’t manage client expectations.

The Supply Side
On average, a programmer can produce about 100 – 120 hours of productive code per month. There are 160 hours in a normal month of work (4 weeks at 40 hours each), and when you pull out time for meetings, training, sick, vacation and holidays, , , what is left is the actual productive coding time you get from a programmer.

Some months will be less than this average of 100 – 120 hours of productive coding time, some months will be better, , , but over 12 months time you should see this average work out.

If you are delivering less than 100-120 hours per programmer per month on average for 6 or more months, you have a productivity issue that needs attention.

OK, if we have 5 programmers that means our supply of productive coding (or capacity) is somewhere between 500 – 600 hours per month as a team.

Let’s assume the demand for coding new reports, enhancements, and new features for this application is considerably more than our capacity. How do we increase our output, , , our supply?

There are several ways to increase the output of a programming team:

  1. Improve the existing team’s productivity
  2. Have the team work more hours
  3. Pay programmers incentive pay to do certain projects on their own time (on weekends and holidays or in the evenings after work)
  4. Hire new programmers
  5. Contract programmers from the outside

I’ve used all of these and every option will work to improve your programming team’s output. One caution though is that “requiring the team to work more hours” will work to an extent, but long term use of this approach can create morale problems and put your programmers at risk of leaving your company.

You essentially have three options to address a programming backlog that exceeds your capacity, , , reduce the amount of backlog, , , take longer to do the work, , , or increase capacity to attack the backlog.

The bottom line though is that you aren’t going to get twice the capacity with the five programmers you have on board now. If need is truly higher than your capacity to deliver, you have to manage your client’s expectations. There are several ways:

  1. Reduce the demand
  2. Increase your capacity to deliver
  3. Take longer

Usually the answer lies within all three of these. However, Item #3 (Take longer) really isn’t doing anything different. You attack the problem when you do something about reducing the demand and/or increasing capacity.

The next thing you need to have a good grasp on is, How much of your capacity goes to day to day support?”

It might be 80% of your total programming capacity to troubleshoot issues, fix things, or provide day to day support for the users. If it is 80%, that doesn’t leave much to develop real enhancements.

You need to have a realistic estimate of what day to day support requires from your team, , , without it, you are doomed.

To manage client expectations, you have to know what your capacity to deliver is and of that capacity, , , how much of it is required for day to day support.

Without this understanding, it is virtually impossible to manage your client’s expectations.

Be conservative
The next thing is that when you are making commitments to your clients, you must be conservative. Remember the “Golden IT Rule”, , ,

Always position your team to over deliver. No one gets upset if you exceed their expectations.

One method I use is that I always start managing a new programming staff with an expectation that we can deliver 100 hours of code per programmer per month, , , the bottom of the 100-120 hours a month range you typically see.

Now, when you do this, you need to know that I consider these programmers to be truly isolated from day to day support issues, , , their full time is focused on software development.

I know that if we are operating properly, each of these programmers will actually deliver on average more than 100 hours per month. When I give my client a forecast that we can deliver up to 500 hours a month for the team (5 programmers * 100 hours), I’m positioning the team to over deliver.

Four key things will help you manage your client’s expectations:

  1. Understand the demand for your resources
  2. Know your capability and capacity to deliver
  3. Realize how much is used for day to day support
  4. Be conservative in your commitments

Do these things with your programming staff and other parts of your IT support organization and you will be able to manage your client’s expectations much better.

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.