Tag Archives: manage client expectations

Understand supply and demand to manage client expectations

Posted on November 27, 2016 | Leave a comment

project success 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:

Day to day support required of the programmers
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.

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:

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
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:

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 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”,

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:

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

This article first appeared in my CIO.com BLOG, Practical Management Tips for IT Leaders.

Save

You can do anything

Posted on March 6, 2015 | Leave a comment

There is a great quote I like. It has meaning in most things and goes like this, , ,

I didn’t know who David Allen was when I first came across this quote years ago, so I looked him up. I still don’t really know him but he appears to have done some things in personal organization and productivity areas, something I’m always interested in. He has written several books including his best seller titled, Getting Things Done. It is worth reading.

I’ve used a similar quote in my IT organizations for as long as I can remember, so this “hit home” when I first saw it. Let me give you a couple of examples.

First, IT organizations usually have more demand for support work than they can deliver. This is a normal occurrence and something that is probably not going to go away, , , sorry about that, but it’s not.

What I explain to my staff and to my business clients is that, “We have to manage the business of IT support.” Having more need than capability and capacity to deliver is normal and occurs in almost every IT support organization in the world.

We will never get everything done as quickly as our client wants it completed.

Given the manpower and money, we can do virtually anything, , , yes, anything if we have the resources and money.

But, , , and this is a BIG BUT, , , our companies can’t afford to write IT a “blank check”. Companies don’t have endless amounts of capital to spend on IT. So, what this says is that we have to prioritize and manage the business of IT support, , , not just assume we can do anything and everything.

There is another analogy I use, and it is a personal one.

My company is a small company, , , essentially it is “me”. My biggest challenge is deciding “what I will do” and “what I won’t do”. My natural desire is to do everything, , , that’s right, to tackle every opportunity that comes along.

The problem is that when you are a small company like mine, time is your single limiting factor. Capital can be as well, , , of course, , , but the biggest bottleneck for a small company is available time to do all that you want to do.

So what this says is that you need to be selective in what you decide to work on. In a small company, you aren’t afforded too many mistakes, , , even little mistakes can have major consequences. This is especially true if you target an “opportunity” and spend lots of time and it turns into a “bust”.

Using up valuable time for something that does not provide a good return on your investment will put you out of business, so you have to weigh the risks associated with every new project. What looks like an opportunity can be misleading at times, , , the same is true in your IT support function.

It is imperative that you manage your client’s expectations and help them realize that, “even if you could do everything, , , the company can’t afford it and the users probably couldn’t absorb that much change so quickly”, , , so even though certain requests are not delivered as quickly as the client would like, there are legitimate reasons why this occurs.

In fact, this little quote applies to most things in life if you think about it, , , you may have to manage your own expectations a little.

Managing client expectations

Posted on March 15, 2011 | Leave a comment

A big key to IT success is the ability to manage your client’s expectations. In my last post, I talked about the “client is always right”. I’ve encountered many situations where the client was not factually correct, , , but their expectation was exactly what it should be given the situation.

Let me give you a perfect example. In one company I joined as their new CIO several client managers told me during my initial assessment that I should fire one of the IT employees in my organization.

Not one, not two, , , but three managers told me this. When you get this many, there is an issue to be sure. My job is to determine what reality is and take appropriate action. In such a case, there will be one of two issues to exist:

The employee is not performing.
The client’s expectations are incorrect.

What I discovered in this case was a bit of both. The employee was not performing to the level needed, , , but it was because there was considerable more demand than staff to provide such support. The employee in question had a good attitude and tried to do the job well but there wasn’t enough capacity to get it all done, , , we needed 3 or 4 more people to do what was necessary in this support situation.

In this case, it was not an employee problem, , , it was a management problem because we weren’t managing the client’s expectations about what to expect from their IT organization. Now, the client was correct about support not being sufficient for them to do their job, but they were incorrect in what the problem really was, , , and especially wrong about what the solution should be.

Once I fixed the staffing deficiency problem, no one felt that I should fire this employee, , , in fact, they thought the employee’s morale had improved immensely. That’s really funny because the employee always had a good attitude, , , just could not possibly get all the work done to support the client. I didn’t do anything but fix the real issue, , , insufficient capacity to support the business.

Learn to be conservative
To manage client expectations, you must be conservative. What I mean is you need to set expectations that position you to over deliver. That means telling clients you will complete a project in 6 weeks when you think you will be able to do it in 4 weeks, , , and telling your client the cost of a project is $120,000 when you think you should be able to complete it for $100k to $110k.

There is what I call a Law of IT principle in that, “IT projects always take longer and cost more to complete than you think they will.”

If you are not conservative when you commit to do things for your client, it’s going to be rough going for you and your team. Teach your employees how to be appropriately conservative when they commit to do things for others.

Another example – programming productivity
There are approximately 160 work hours in a typical month. I know from experience you should get 110 to 120 hours or more a month of productive programming time on average from a programmer over the course of a year. Some months will be much less due to vacation, training, meetings, etc. and some months will be a lot more, , , but over time you should average around 120 hours of code produced a month by every programmer on your team.

When setting your client’s expectations, tell them you can produce 100 hours per month per programmer. If you have 5 programmers working on the same application, that means you position your client for your team to produce on average 500 hours of code each month when you expect to be able to produce 550 to 600 hours a month.

By doing this, you position your team to over achieve.

Another simple rule
No one gets upset if you complete a job faster than you say you will or less expensive than you say it will cost, , , but someone always gets concerned if you are late or over budget.

Learn to be conservative every time you tell someone you plan to do something for them and teach your staff to do the same, , , it is going to help you deliver what you say you will do, when you say it will be completed, , , and within the budget you submit.

This makes you a reliable manager and that’s something everyone wants from you.