Great software, but what about the people? - Part 1

The discussion on the pros and cons of using software is quite naturally and understandably focused on the software itself. Is it functionally rich? Is it easy to implement? Does it provide the right outputs? Can it support international or regional BC standards ? Will it help me to implement and maintain a robust BCM structure in my organisation? These are all too familiar questions and all software providers will be eager to respond ‘yes’ and then endeavour to demonstrate how this will be achieved in a practical way.

This response is not altogether surprising for the following reasons:

• In any mature market, all leading providers will claim to have the same high level of pedigree in solutions delivered.
• For technology solutions, often the sheer weight of technical functionality and innovation (real or perceived) can be seen as key differentiators i.e. more and/or different = better.

If you look at the functional comparison charts for BCM software providers published from time to time, there is one clear conclusion. Most of the major tools probably share 95% of the same functionality. So, why are some more successful than others and why, at the other end of the spectrum, do some organisations actually give up when trying to implement software solutions?

The answer is not found in technology; it is people. People who use the technology; people who access the technology as part of their day-to-day role or on an infrequent basis.

Now, the ‘people’ factor works in three important ways as far as software is concerned:

1. Has the software been developed with end users in mind? (workflows, clarity of format, accessibility etc)
2. Can the software be used in a very practical way by different users of all abilities?
3. Does the software encourage users to adopt good BCM practice and actively engage in the subject/process?

The unfortunate aspect in our own industry is that often these three particular boxes have not all been ticked by software providers. The end result is that attempts to embed software in organisations have sometimes been less than successful. If you ask a BC practitioner why this has happened you may receive one or more of the following responses:

1. Lack of motivation – end users have not ‘bought in’ to the importance of the process and have thus not actively adopted BC
2. Wilful ignorance – end users believe that if it is ignored it will go away …. eventually!
3. Confusion – the sheer variety and volume of acronyms and unfamiliar terminology, together with new technology caused corporate confusion
4. Poor project management/implementation – ‘yet another project from Head Office’
5. Badly designed system interface – technology that is patently not fit for purpose or does not deliver on the supplier’s promises.

Items 1-4 are clearly ‘people’ driven and I would suggest that 5 is too, as it is the failure to focus on users that leads to poorly designed tools.

People-centric processes

This term is often quoted but not so often followed. ‘People centric’ means that you start with people and build your structures around how they will be managed by individuals. This isn’t about losing sight of processes, structure and work-flow – it is about recognising that it is individuals who create activities and make decisions. There are some very simple steps that can be taken to mitigate the risk of losing sight of the people aspect:

• When building a process, imagine that you are on the receiving end, actually doing this in a live environment. Take it off the page and into reality.
• Think about what the user knows/doesn’t know and how they will approach the task. And remember, they are not you.
• When building a screen or a page, draw the attention, highlight things that need to be done, have consistent navigation, keep the screen simple, clear and informative. Use a level-based approach – primary level has core info, secondary level if I need to know more, tertiary level if I really want to dig deep into the information. This way users of all abilities and with different requirements can have their needs met.
• Communicate. Tell your audience/users why you are doing something. Explain the rationale. If I understand, I accept. If I am just asked to follow a process with no clear idea of outcomes, I am reluctant.

What this means for BCM Software and the Future?

I will explore implications in Part 2, to follow.