Organisations these days spend large proportions of their budget on getting the right software in place. Whether it’s finance, document management, CRM or the latest Office software, it’s a large outlay for anyone. Too many rollouts do not provide the cost savings and productivity gains that are expected – one only has to look in the newspapers to read the latest tale of a major IT project that hasn’t delivered, and it’s a problem that does not just affect large organisations. Though SMEs and organisations in the third sector may spend less as an absolute amount, that doesn’t mean that there’s a smaller relative effect.

But why does this happen?

When closing a project, the project team can look back with the benefit of hindsight and can be heard to say “The specification wasn’t detailed enough”, or “the requirements kept changing”, which may be true. There are many reasons why a rollout does not achieve the results expected, and we tend to look at the failings in the project planning, the software itself – or the budget that was allocated. Sometimes though, there’s no obvious reason for the problems.

Perhaps, it’s a simple PICNIC problem. That’s “Problem In Chair, Not in Computer”. The software is actually great, the project was properly planned and executed and the team worked well together. The issues that the organisation is now facing are nothing to do with these factors; they’re to do with the people who have to use the system.

That’s not to say your staff aren’t up to scratch, just that they haven’t been properly trained. Using software on a day to day basis requires users to know what the processes that surround the technology are, as well as how that technology works. Often, the training provided by a software vendor only covers what buttons to press, and not why you should press them. While they have been brilliant at gathering and implementing corporate requirements, have they taken the trouble to find out what the people in your organisation do? I’m not just talking about the project team, I’m talking about the people who will be sitting in front of the system every day – the ones who can make or break a successful project.

Let’s look at an example. You put in a new expense system. It’s full of bells and whistles. It meets your requirements exactly. What training do you give your users? Do you accept the generic training that is offered by your vendor? The training shows in detail how to create a transaction on the system, and tells your staff about those bells and whistles that you paid so much for.

But does it cover everything else that a staff member needs to do to successfully make a claim? Do they scan the receipts and attach them electronically? Do they print off the claim and staple the receipts to it? Where do they send it in either case? How many pay runs do you do each month?

These are the questions that need to be answered in order for your staff to use the system and make the improvements you have invested so heavily in. Ask your training supplier if they provide a bespoke or off-the-shelf solution, and how they gather their requirements. Ask yourself what someone who has never seen the system will need to do to complete the processes that you have identified, and make sure that is covered in the training, as anything else raises significant risks to your project.

Training. It’s all about the PICNIC.