Understand supply and demand to manage client expectations

One of the keys to success in IT management is being able to manage your client’s expectations.

To manage your client’s expectations, you need to 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.

You have to understand the dynamics of what’s happening in both “Supply” and “Demand” within your IT support organization’s environment to manage client expectations.

In most situations, there will be more demand than supply, your clients need or want more from IT than your 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 and manage your client’s expectation to what you can deliver.

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 new programming enhancement requests – new reports, new functionality, etc.

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 their work day.

You might be surprised! This simple exercise will tell you a lot about what’s being pulled out of your team’s programming 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 in your Programming Backlog for new requests (new reports, new functionality, etc.).

You should have a programming backlog 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 new programming is. 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 normally about 160 hours in a normal month of work (4 weeks at 40 hours per week). 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 more. But over 12 months time you should see a programmer’s average work out to be about 120 hours per month of productive coding, roughly 75 percent of their work time.

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

Note: This measurement may vary depending upon your company situation or part of the world you live in and the productivity culture that exists.

OK, if we have 5 programmers this means our supply of productive coding (or capacity) should average between 500 to 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:

1. Reduce the amount of backlog
2. Take longer to do the work
3. 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 significantly higher than your capacity to deliver, you have to manage your client’s expectations.

There are essentially three 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 and probably may not satisfy your client.

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 percent of your total programming capacity to troubleshoot issues, fix things, or provide day to day support for the users.

If it is 80 percent, that doesn’t leave much to develop new enhancements that are being requested by users.

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 not only need to know what the demand for programming services is, you must also know what your capacity to deliver is. This “capacity to deliver” includes how much programming is required for day to day support plus how much is available to focus on new requests.

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

Be conservative

The next thing is that when you make commitments to your clients, you must be conservative.

Remember the “Golden IT Rule”,

M

Always position your team to over deliver. No one gets upset if you exceed their expectations. Someone always gets concerned when you don’t meet expectations.

One method I use is that I always start managing a new programming staff with an expectation that we can deliver an average of 100 hours of code per programmer per month even though I know we should deliver around 120 hours a month of new code per programmer on average.

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 and producing new code.

I know that if we are operating properly, each of these programmers will actually deliver on average more than 100 hours per month. So, 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.

Let me emphasize this: Position your team to over deliver!

One of the best ways to manage a client’s expectation is to position your team to deliver more than what the client expects. To do this, you must be conservative in what you commit to. My approach with programming is to commit an average of 100 hours per programmer per month to the client and deliver somewhere around 120 hours per programmer.

Summary

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, and this will help your IT organization achieve more success.