CIO Thoughts

Over my career to date I have built a number of teams, and restructured many more (not necessarily redundancies, rather changes in direction or scope as required).  In doing this I have come to the realisation that there are essentially 3 broad types of people – the do’ers, the planners and the planning do’ers. Now clearly the ones you generally want are the Planning Do’ers; the ones that work out what needs to be done and then get on and do it against a plan (obviously there is a bit of a continuum here). What I have found interesting is the ways in which to get planners doing and do’ers planning. 

What I have generally found is that it is easier to get do’ers to plan than it is to get planners to do.  Something in the paralysis by analysis, and a fear of making a mistake seems to hold planners back from getting on and getting things done.  Additionally, when you speak to a planner, there is an intrinsic need to ‘get everything just right’ before taking action.  Now those who are do’ers will say there is no point in planning, because as we all know, ‘the best laid plans of mice and men…’ and they will have experienced that taking action builds momentum, and momentum and excitement build new ideas and approaches (if they are flexible enough) and that things ‘will change anyway’ as they discover new ways to tackle things.  Both sides have their merits, and both are of course correct, just not all the time.  Like all things in life, balance is key.  Action without planning devolves into meaningless effort and wastes resources. Planning without doing is just as meaningless and unhelpful.

All in all though I really do prefer do’ers (perhaps it’s because I am so delivery oriented myself). You can pull a do’er back, restrict access to resources and generally put in controls before you let them go.  Then make sure they report back regularly against those controls.  Now, they will really take an intense dislike to you initially, but once you have one or two smaller projects, or phases of projects done successfully they will come around.

A planner on the other hand needs lots of encouragement, both carrot and stick, to get them to take the first step.  They also need to be forced to take a step when they will not feel they are sufficiently prepared.  Essentially their judgement on when enough planning has been done is impaired.  They need to be told directly that they have done a terrific job, and that the first task, and then the next, and then the next must be taken.  Unfortunately there is a need to sit on top of these perfectionists through each and every task, because at the first sign of something going slightly differently to their well laid out plans, they will panic, revert to type and resort to further planning! Eventually they will come around – they just need a series of successes, and to get the feeling of momentum and energy that builds up in a project as it gets going.  They also need to fail a few times, and recover from that failure (there really isn’t any failure – only feedback).  When they fail though, it is important as a manager to encourage them to keep going, think outside the box, focus on solutions and get things moving. Reflect, adapt and then implement – not stop (unless of course it is a truly major stuff-up in which case why weren’t you noticing what they were doing??).

Often when I interview people, I ask a series of questions which are designed to elicit where on the continuum of do’ers to planners they are. Can they do both, do they understand an 80/20 approach, can they build momentum and energy in a project.  All of these are important if you want a team who deliver and keep delivering, but do it with direction, purpose, reflection and adaption.

Share this post :

|

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…

|