Part Four - Why it's Critical to Distinguish Knowledge from Capability
In Part Three of this series, we looked at the extra value that businesses can create when they consider learning and development from the perspective of the team, rather than just the individual. However, all L&D ultimately comes down to individuals, and this is where things often go wrong. So, in Part Four of this series, we’ll look at how a lot of money can be wasted by confusing knowledge with capability, leading to a focus on the wrong type of learning and development.
Training Isn’t Enough to Improve Performance
We once worked with a client who separated the roles of maintenance planner and maintenance scheduler. This is not uncommon, and it can work perfectly well when functioning correctly. However, this client was struggling with poor schedule completion, which was resulting in a growing backlog of defects, and ultimately breakdowns.
The reason for the poor schedule compliance was that assets weren’t being released by production when needed. Digging further, it wasn’t that production were behind their plan and trying to catch up, it was that production wasn’t aware that maintenance had been scheduled until the day.
As we investigated, it became clear that the cause was the maintenance scheduler. The problem wasn’t that they hadn’t been trained. Apart from his background as a tradesman and familiarity with the plant, they had gone through a three-day planning and scheduling course to learn the client’s work management processes and tools. They had a clear job description, a clear process to follow, and a RACI that outlined their responsibilities.
They had gone through further training on how to use the site’s Computerised Maintenance Management System (CMMS). They had also undertaken a two-day course on Microsoft Project. There was nothing they didn’t know about the role.
As it turned out, the problem was that the scheduler didn’t talk to anybody! The planners gave him the tasks for each work group, and they turned them into a schedule. However, they didn’t talk to the production crews to understand when a suitable window was to release the assets for maintenance, and they didn’t provide them with a copy of the weekly schedule.
So, the tradies would turn up in the morning, ready to start work, only to find that production weren’t aware what was happening. Therefore, the tasks often went into the backlog, resulting in numerous failures.
Understanding the Difference Between Knowledge and Capability
The reason these situations arise is that knowledge is only one aspect of capability. In the previous article, we explained the importance of drawing links between the organisation’s objectives, the effectiveness of its processes, and the capability of the individuals. This link isn’t just academic; the success of a business is down to what its people do, not what they know.
Capability is simply defined as the ability to do something. However, capability has multiple dimensions, including:
Knowledge – What we know and understand
Skill – What we can do
Attitude – Internal values and beliefs
Behaviour – What we do and say (as observed by others)
Resources – Tools and processes that help us perform a task.
In the example of the maintenance scheduler, the problem wasn’t knowledge, it was skill and behaviour. An essential skill for a maintenance scheduler is the ability to communicate and broker agreement. The scheduler needs to be the hub through which all information flows. They need to confirm the times at which assets need to be released, and to make sure that production have prepared the assets, and maintenance are ready to start as soon as the asset is available.
Don’t Forget About Resources
As leaders, we must be careful not to attribute blame to individuals without considering if we’re contributing to the situation. Sometimes, an individual’s performance isn’t down to the knowledge, skill, or any other personal attribute. If we don’t equip our team with the tools, processes, and information they need to perform their tasks, they we can’t expect them to achieve the outcomes we’re looking for.
In the case of the scheduler, it wasn’t solely down to their communication. We also uncovered that even though they’d been trained in Microsoft Project to produce the schedules, the plug-in to integrate the CMMS and Project had failed, so they were spending a lot of their time manually producing the schedule. Not only that, but the quality of the master data wasn’t great, so they was continually having to adjust the time and resourcing for jobs (which also had to be done manually because of the failure of the CMMS plug-in).
So, although their communication was a problem, it turned out they was spending far too much of their time and attention on manual tasks that should have been automated. Their attitude also suffered – it’s understandable to be grumpy when you’re taking two days to perform a task that should take less than an hour.
Capability isn’t something you either have or you don’t. Even if we can’t always quantify it, we can still observe and measure capability in a way that separates the highly capable from the not-so-highly capable.
At Bluefield, we’ve found an effective way to rate our capability is in terms of the complexity of the situation in which we can apply it. We can express this using a scale; at the lower level is an individual who understands the basics and can handle simple situations, while at the higher level, we have externally-recognised specialists who we call upon for the most complex projects.
Even if you don’t use a similar scale, you probably recognise the concept. It applies to tradespeople, engineers, or any other role. Even if it’s subconscious, you probably allocate tasks to your team on this basis. If you’re a maintenance supervisor or superintendent, you almost certainly have one or two tradies who you can call upon if there’s a job that needs complex troubleshooting, while others might be more suited to performing regular services.
Using Learning Needs Analysis to Save Money on Unnecessary Training
As a leader, you can link your team members’ development to the tasks you need them to perform. You can do this formally as a learning needs analysis, or on an ad-hoc basis when a team member asks you for training.
For each task, ask five simple questions:
What do they need to know to perform the task?
What do they need to be able to do to perform the task?
How well (to what level of expertise) do they need to be able to perform the task?
What behaviours must be demonstrated when performing the task?
Do they have all the resources they need to perform the task?
These questions can save you money because unless you’re talking about the first question out of this list, then training is unlikely to be the solution. This is good news, because training is generally the most expensive form of learning, and the least effective at building capability.
Here’s an example. It’s not uncommon for a reliability engineer to want to undertake condition monitoring training. However, do they need to attain advanced certification in vibration analysis, which can take up to 20 training days to complete, if you’re not performing your own condition monitoring program?
On many sites, contractors are used to analyse, and in some cases collect, the samples and readings. Reliability engineers are generally responsible for reviewing the reports and alarms, then ensuring notifications are raised to manage any defects. Do they need expert-level knowledge to perform this task? In our experience, the most common problem with condition monitoring programs isn’t the knowledge of the engineers, it’s the process of responding to alarms. Fixing this problem could be much cheaper and more effective than training your reliability team.
In the final part of this series, we’ll look at the different forms of learning, and how you can use these other forms to build capability in your team without relying on expensive and ineffective training courses.
Click here to learn about our Effective Maintenance Supervision program, delivered through the Bluefield Academy.