Sunday, March 10, 2013

How to manage and control IT support department?

Question:
Is it possible to manage IT maintenance operations like a project, with typical project management mechanisms including scope, time, and cost planning? In our project we experience difficulties in such a management of our IT infrastructure support department. We don't know how to define their scope, how to control it, and how to make sure that the work is done. They are not developing any software but organizing our server space. Sometimes (and very often) their mistakes severely affect the entire project. I'm interested to find some formal or semi-formal instruments of this IT department management and coordination with the rest of the business.

Answer:
There is a danger in trying to use PM methodology to manage an operational process. PM methodology - waterfall, agile, Prince2, whatever - is designed to deal with temporary endeavors.

I suggest you build the processes you need to make thinks happen in the support department.

If you are unfamiliar with process development, you can find all kinds of resources on line. The basic steps are;

    make a list of everything your department needs to do
    organize it into process groups
    document the steps for each process
    start improving the processes

------------------------------------------------------------------------------------------

The main problem with maintenance and support teams is that it's usually really hard to plan their work in reasonable way in any longer time span.

If we define maintenance team as one which reacts either to problems within project (bugs, issues, inquiries) or to requests submitted by others (client, other teams) it's more like dealing with constant priority changes. If there's critical bug submitted we likely deal with it in the first place before moving to regular stuff. If there are other (major or minor) bugs which have solution deadline they also go up through priority list as the deadline approaches.

However even though it's hard to plan team work in any detailed way as the plan is going to change a number of times, you still can organize process in a way which just takes such situation as given. A very good method to try here is Kanban as it doesn't force the team to plan work up front but allows to react to priority changes in a neat way. See http://blog.brodzinski.com/2010/11/beauty-of-kanban.html as example of how Kanban in terms of reacting for frequent priority changes.

Kanban also does a very good job in terms of visualizing what the team is doing now, what they're going to do next, any problems they might have, individual responsibilities for tasks etc. In given situation not only may it help you to track their work but also help them to see what they're really have on the plate.

Also with Kanban it doesn't really matter what kind of tasks the team deals with as it wasn't designed with a purpose of applying it to software development only, so it can be perfectly used for the team dealing with infrastructure.
-------------------------------------------------------------------------------------------

This may be considered as a project itself " IT Operations Alignment".

In order to manage the service delivered by the IT Support Team you will need liaise with the Team Lead to understand the following:

    Current Process Logic for IT Operations (planning, approval requirements, etc...)
    Current Service Level of Agreement (SLA) to deliver solutions
    Resource Availability (remote teams, on-site testers, etc...)

Once you have gathered all relevant information regarding their processes try to match these with your own ones and identify any gaps or areas of improvement.

    Document Agreed Business Process and Operations/Projects - defining the scope of your business/project and where their support must imply.
    Agree a Service Level of Agreement - for an estimated timing of resolution according to the severity of the issue/requirement.
    Define and classify the defects or incidents according to the timing agreed on the SLA; e.g. Critical issues to be resolved in less than 24h, Critical incidents can be unavailability of the system or servers down. Moderate issues to be resolved within 72h, and so forth...

Finally, I would also recommend building a robust defect reporting mechanism which interfaces with IT. A good example could be eTracker, Jira, or SharePoint. By using these tools you can raise items according to the agreed scope and track the progress, flag concerns, escalate unresolved issues to senior management, and so on.

On a separate note, I would also consider that depending on the complexity of the teams and/or the business the maintenance of this relationship between IT Support and Operations may need to be managed by a separate role.


------------------------------------------------------------------------------------------



When I have had support responsibilities I found it was a very successful week if I got the planned work done on two days. A lot of support time may be taken up responding to problem reports. Even if the problem is out of your control you still need to determine that it isn't in your control. You may then need to manage the response to the problem.

There are projects (usually on the small side) within the work that the support group will be handling. Setting up a process to make those happen could be worthwhile.

The one area ITIL is reported to be best suited to is managing support groups. I would consider implementing that area of ITIL.

No comments:

Post a Comment