CIO Thoughts

Over time, most managers will create specific ways by which they prefer to manage teams. Most of us do this by trial and error, hopefully a bit of training or by discussing approaches with others – some of us were even lucky enough to have a mentor. What I thought I would share today is the framework I use for managing a wide variety of teams, which all have both project and day to day activities to take care of, all while meeting SLA’s. This balancing act is often one which managers in IT find quite difficult to manage. Sure, the ITIL framework provides some approaches, and incident management is very helpful for day to day activities, but how do you do it on the ground – and when you have multiple teams, what are some of the ways of controlling all this activity without losing track of where things are?

Generally I break activities down into a couple of different areas – projects and incidents. Projects as a rule of thumb, are any activities which require 3 or more resources or will take more than 3 man-days of work. Everything else fits into the ‘incident’ category. Naturally you need to have a little bit of flexibility on this, but as a general rule-of-thumb, this works quite well. Projects are then split into two types – Major and Minor. Minor projects are relatively short duration, low impact (although often high visibility) and are run by the manager creating a ‘Simplified project Initiation Document’ (SPID). These SPID’s require some essential information such as; Project Sponsor, Project Objective, Success Criteria, Key Milestones, Resources required, Costs and an approval process.

Projects larger than this get managed through a Project management Methodology, based on prince 2 and standard project management practices (I generally find the paperwork and admin generated in a full Prince 2 project excessive, and so prefer a ‘skinny version’).

Day to day activities are managed through ITIL Incident Management (and Problem management). The key to balancing between immediate tasks generated by Incidents and longer term project requirements is twofold; 1) Get managers to break projects down into manageable day to day tasks and 2) Prioritise, prioritise, prioritise based on business impact. All projects be they small or large and all incidents and problems get prioritised as they come in, before any work is done on them – that way the managers of the teams can make a judgement on a) whether there is enough resource and time to do them and b) where to allocate resource.

The final piece of this management process is regular reviews – as an Exec I am not terribly interested in the detail of every project unless it is going off the rails (then, like most I can suddenly get very interested!). So I ask each of my managers to provide a weekly highlight report which is broken down into this week (what just happened) and next week (what is planned to happen) on a project by project basis. Each project section is further broken down into several sections – a Risk and Issues summary with RAG status, and the tasks for the project along with comments and timelines for each. Note that no action ever goes without a timeframe….!

Finally, at the bottom of the report a summary of the number of incidents and amount of resource being used by those incidents is given, along with any other business. This gives me a way of making sure my team are organising their thoughts, planning at least a week ahead (I’ll cover longer term projects in a sec) and managing risks and issues on a regular basis. It also gives me a quick sense of project progress and resource utilisation. I ask for these on a Friday by lunch (giving me some time to review Friday afternoon/evening) and I have a Management Meeting on the following Monday. This line management meeting is used to focus on any specific issues, and provide some cross-team focus on problems. It is also an opportunity to bring attention to new information from either the Exec or the staff from the previous week.

Longer term projects I generally have a weekly review with the project manager or the line manager, covering the detail, risks, issues, resources, timelines, deliverables, etc. We also maintain a timeline of all the projects for the year, and a framework for when they are scheduled to begin and finish, which is reviewed monthly. This overall timeline is structured from the IT strategy document, which is written and aligned with the companies board level expectations.

In this way, I am able to make sure that what we are doing on the ground aligns with the board and exec strategies and that I have control over day to day activities without micro-managing people.

The teams I have done this with generally find this a good balance, and the feedback has been that they find it useful themselves. When this type of framework is put in place initially, it can be seen as onerous, but within 3-4 weeks most managers are spending no more than 30-60 mins doing the report and it has become a part of their own planning routine. The point I make is that it is a darn sight less intrusive than me asking questions everyday and sticking my nose in where they are perfectly capable of handling things.

As time goes by, you can of course gradually back off on the amount of reporting so that the do it every 2 weeks, but it really depends on the number of projects, time sensitivity and tolerances you have on them. As I do transformation work primarily, tolerances are small and timelines very tight, so this works well as a balance for me.

Naturally there is a lot more to managing teams than just the elements I have described here – but this will hopefully give you a feel for one way of managing some of the core activities for one or many teams. It doesn’t cover any of the performance, HR, training or other parts of management, nor is it intended to – it is just a nice simple way of managing workloads really…

|