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:
- Day to day support required of the programmers
- 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:
- Improve the existing team’s productivity
- Have the team work more hours
- Pay programmers incentive pay to do certain projects on their own time (on weekends and holidays or in the evenings after work)
- Hire new programmers
- 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:
- Reduce the demand
- Increase your capacity to deliver
- 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?”
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.
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:
- Understand the demand for your resources
- Know your capability and capacity to deliver
- Realize how much is used for day to day support
- 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.