To skill or not to skill…

Tuesday, February 28, 2006

You can trace every disaster back to a lack of skills – so training is a risk avoidance strategy, argues Colin Steed, CEO, Institute of IT Training.

The Titanic sank because they steered it the wrong way; Buncefield Depot went up because of a lack of care; even people who suffered in the recent earthquakes can trace their problem back to building skills. It's a sobering thought – every disaster that ever occurred can be traced back to skills issues. And the fact that no-one lost their life in Hurricane Rita can be traced back to the fact that there was not a lack of skills.

So what's the relevance of this to you? Just think, next time there's a problem, look at the underlying skills issues and you'll see. Now don't get paranoid; it's easy to imagine all sorts of risks and provide everyone with a host of skills 'just in case' – there's no point in that. But there is a point in identifying the five or six biggest risks, and developing a skills plan to ensure that these risks are minimised.

From the point of view of IT skills, the risks are fairly common – but first of all, let's identify what we mean by the term 'IT skills'.

IT skills
There are three key areas to consider. The first is your users – all those people who are outside the IT department but need IT skills to be able to do their job effectively. That leaves the people inside the IT department, and there are essentially two types of such individuals. There are those that are involved in developing IT solutions and those that are involved in supporting their deployment.

There are others, of course: managers, specialists, strategists, change specialists and possibly trainers as well. They will all come into the picture somewhere or other. But my core argument still holds – you need to think about users, developers and infrastructure support as the key areas.

User skills
So what are the key risks? The general reaction is that, if people don't know how to use their IT systems, the only downside is that they won't be as productive as they could be. But that really isn't the issue.

Take a typical scenario: the enterprise wants to become more client-centric in its approach and has just implemented a new CRM (Client Relationship Management) system. The functionality within most of the packages is extensive and therefore the enterprise decided to implement the package and change their processes to map to the package.

The real danger from a lack of skills in the new processes is not that transactions will be implemented slower, it's that they'll be entered inaccurately. The user's requirements may be wrongly specified, the dates may be wrong, the contact details may be incorrect – in short, the risk is scarily high. Both the risk factors – the probability of occurrence and the impact of an error – are high and therefore the issue needs to come onto management's radar.

IT department
Now let's turn to your IT department – we typically refer to these people as IT professionals (they earn their crust as a result of their IT skills; they are very different from end-users who earn their crust as a result of non-IT skills, but they need IT skills to make their other skills effective).

One of the issues that is being tackled at the moment by the British Computer Society (in conjunction with the Cabinet Office) is the definition of 'IT professionalism' and the fact that it goes way beyond just skills – but that's another matter.

Your IT department will comprise developers and infrastructure support staff. And, if your IT department is like about 80% of the IT departments in the UK, there will be fewer support staff than development staff, but you'll actually be spending more on support training than developer training.

Infrastructure
These people are essentially the ones that install, troubleshoot, optimise and make the infrastructure more robust. There are really three critical risks here: the first is that the infrastructure goes down at a critical point; the second is that it takes too long to fix; and the third is that dreaded nightmare – security.

'Break-fix' skills used to be very scarce, but as software has increased in functionality and the suppliers focused on that critical area of 'cost of ownership', this has been reduced as an exposure. Nevertheless, it is still a risk. If you don't have access to email, the internet/intranet, or mission-critical applications for a period of time, there is a cost (probably substantial) associated with the problem.

But the bigger risk now is security; this is certainly an area to look into, as being hit by hackers is both a high probability and will have a high impact.

Your IT manager or network manager will probably respond saying 'Don't worry, boss, we're as tight as Fort Knox. We've just installed this new firewall and have this intrusion detection system so no-one can get in.' Right? Wrong.

It's all very well investing in security hardware but it's another thing to invest in the skills to use it effectively. Most organisations now employ their own hackers (there's a program called Ethical Hacking, which always struck me as a contradiction in terms) and they encourage what they call 'pen testing' to be able to penetrate the infrastructure. That, and computer forensics, are the critical skills to ensure you have within your organisation; don't just rely on installing hardware – the hackers know how to get through that just as a criminal knows how to get into your car.

Development
Your IT professionals who are your developers are almost certainly the least trained part of your organisation. There is a 'don't worry, they'll learn it on the job' attitude to the development of developer skills. And they do learn it on the job – good practice, as well as bad practice.

How often have you come across the scenario that development on this new application is not quite complete: 'We're 93% complete boss, and it'll be ready soon.' The project may only have taken 10 weeks – so '93%' implies that it'll just be another three to four days, but it'll most likely be three to four weeks.

This is all the result of a lack of skills; at the start of the project, when euphoria abounds, 'We don't have the right skills' is not seen as a problem area. When the project is late, and there's no sign of a committed completion date, the cry goes up 'It's too late to train them now!' The strategy to avoid this is, in hindsight, blindingly obvious.

Vision
But the most critical IT skill of all, and it's difficult to train this one, is that of vision – understanding the way in which the enterprise should use technology for commercial or public benefit.

Coaching and mentoring are the best ways to develop this skill.

Cross-training
The final area to consider is that this neat and tidy scenario I've painted of IT professionals in the IT department is actually a rarity these days; it is far more likely that you'll transfer people from line of business units into IT for short periods of time to ensure that the IT group has access to the business skills they need to implement successful applications.

That means that there is a real issue of deciding what the business users need to know about IT. The temptation is to treat them as new entrants into IT; but that has the effect of both boring them and encouraging them to request an early transfer back to their 'day job'. This one needs very careful planning.

So, it's easy to avoid disasters – just get training. But don't get paranoid about risk assessment and the dangers; that simply results in too much internal navel gazing.