Do your projects rely on IT staff who have support responsibilities? Are project deadlines being impacted due to the amount of support work being done?

Do your support staff also have project responsibilities? Are they letting support calls fall into black holes because the project work is more interesting?

Ideally, you would never suffer these problems. You would have some IT staff dedicated solely to projects and others dedicated solely to support. While this arrangement may be possible in larger IT departments, where roles can be clearly delineated and where multiple people understand each component of the infrastructure, for the rest of us this arrangement is an unobtainable luxury.

So, how can the rest of us make it work when individual staff have both support and project responsibilities?

Well, first of all let’s talk about two ways that it never works.

The first is to ignore the problem and let staff do whatever they like. Depending on their skills and on the preferences of themselves and their manager, either project deadlines or support service levels (formal or perceived) will suffer as staff concentrate on the type of work they enjoy most.

The second is to ask individual staff to focus on meeting project deadlines and but spend their ‘spare’ time on support. But what happens when a project is already behind schedule, a tight project deadline is looming, and a major incident occurs? What is the staff member supposed to do? We all know that ‘spare time’ is an absolute rarity on any project – if a project is on track or ahead of schedule, then ‘spare time’ should be used to keep the project that way. And if a project is not on track, there will never be such a thing as ‘spare time’ and support calls will continue to fall into black holes.

So what can you do? You have two options, one better than the other, and I’ll describe them both for you now. At the end of this article I’ve included a decision tree to help you decide which option is best for you.

Option 1 – Split time by Fixed Days per Week

Your first option is to split someone’s time between support and projects by formally agreeing the days each week that will be spent on each activity.

For example, Rob will spend Monday to Wednesday on Projects and Thursday to Friday on Support. 

This is a very simple solution, allowing a project manager to simply schedule Rob on the project as though he is a part-time resource. It is very clear to the individual staff member when they should be working on projects versus when they should be doing support work.

Note that this approach is better than Rob spending time each day on both Projects and Support (e.g. 4 hours on Projects, 3 hours on Support) because Rob gets to be more productive by being ‘in the zone’ for a few days rather than continually swinging between one type of activity and another.

However, there is a major drawback to this approach – if Rob is the only one with expertise on a particular system or type of infrastructure, then either there will be no-one to respond to a high priority incident if that system or component fails during Rob’s project days, or Rob does drop everything to help restore service but the project loses him and the schedule is compromised.

There are therefore three situations where this option will work:

1. Where the individual staff member is not the only one who has expertise in any one system or type of infrastructure (and therefore one person can provide support on the days that the other does project work).
2. Where the individual staff member is assigned to project tasks that are not on the critical path of the project, so that delays to those tasks will not adversely impact the project schedule.
3. Where the Project Manager is willing and able to add sufficient contingency to all the tasks assigned to the individual staff member, so that support interruptions are planned for rather than being a nasty surprise.

So, is there a better way? Yes, read on…

Option 2–Split time based on Support Targets

In my opinion, this second option is the best way to solve your problem. It is used by thousands of organisations who have staff doing both support and project work concurrently but who don’t experience the pain that others do with this.

First you are required to have four things in place:

1. A reliable and consistent mechanism for prioritising incidents.
2. Response and resolution targets defined for each incident priority, e.g. A 4 hour response time and a 5 day resolution time for Priority 3 incidents.
3. Objectives in place that express how you are going to perform against these targets for each incident priority, e.g. For Priority 3 incidents, we will respond to 90% of them within 4 hours, and we will resolve 75% of them within 5 days.
4. Measurement of how you are actually performing against those objectives.

If you are thinking these look a lot like Service Levels, you’d be right. If you choose to agree these targets and objectives with your customer, then we would call these Service Levels. However, to solve your project vs. support resourcing problem, you do not need to publish these as formal Service Levels – they can be strictly for internal use.

Regardless of whether or not you have problems with staff who have both project and support responsibilities, these four things are absolutely fundamental to understanding whether or not you are over or under resourced to meet your support obligations – if you have no targets, no objectives and no measurement of how you are performing against those objectives, how could you possibly claim you need more support staff? How could your boss possibly claim you have too many support staff?

So, once these things are in place and you are measuring your performance against these objectives you will be able to determine what resources you need to meet these targets and objectives. You will know whether you are meeting your objectives, exceeding them, or failing them. You will be able to have meaningful debates over support staffing levels and objectively agree whether you need more staff or less challenging objectives.

With these things in place, you will be able to determine the percentage of Jim’s time that is needed for him to meet your support objectives.

Let’s say that, between 40% and 50% of Jim’s time is needed for him to be able to meet the support targets (“Jim, you need to respond to Priority 3’s within 4 hours, and resolve  them within 5 days”).  The Project Manager will be advised to schedule Jim onto the project for 50% of his time, allowing Jim to spend up to 50% of his time on support. Jim will monitor his support queue and ensure that he is responding to and resolving the incidents in his queue according to the response and resolution targets for each priority of incident. When Jim is ‘on top of his queue (e.g. Jim only has a single Priority 4 incident in his queue and he’s got a week to respond to it and 3 months to fix it), then Jim focuses on the project.

The beauty of this approach is that it requires you to have basic disciplines in place that every support team should have in place in the first place. And, once these are in place, you are able to make informed decisions about support objectives and resourcing levels.

When you have these support targets, objectives and measures in place, your project should be able to rely on IT staff who have support responsibilities because (1) your project staff have clear support targets to perform to and (2) Because you have made an informed decision about how much of their time they need to meet those support targets, and therefore how much time they have available for project work.

When you have these support targets, objectives and measures in place, support calls should never fall into black holes due to support staff having project responsibilities because those staff have clear support targets to perform to.

No more excuses about poor support because of project obligations. No more excuses about missing project deadlines due to support obligations. No more questions day by day about what their priority is.