Back to school…why classroom-based learning is crucial for realising value of enterprise software

When visiting clients, I often ask end-users and application administrators how they were trained on the enterprise software they spend most of their day working with. If they were around when the solution was first implemented, they will typically have received basic product training as part of the implementation project, usually some time ago. However, a year or two after the implementation, those people will often have moved on and in most cases, the response is that they were shown what to do by their peers when they joined the company or team. These same users will often gripe about their frustrations with the software, about how it’s difficult to do simple tasks; how things often run slowly, or that they don’t know how to resolve common errors. When asked why they do some things the way they do, the answer is usually “it’s always been done like that”, or “that’s how I was told to do it”. Team leaders are generally aware of these frustrations but have long since accepted that “that’s just the way it is” and deal instead with other issues they feel they can affect. Senior managers or project sponsors, although not always close to the ‘day-to-day’ challenges of the software users, may be disappointed that they don’t seem to have achieved the software vendors ‘promise’ of scalable automation, consistency and performance improvement that led them to invest in the solution in the first place. That may sound like a bleak perspective, but many will find aspects of it familiar.I’ve also long since come to terms with the fact the finger of blame is usually pointed at the software vendor for over-selling, the systems integrator for under-delivering, or both. Occasionally there is some truth to that accusation, but more often, a contributing factor is that the client simply doesn’t understand the full capabilities of the solution they have or how best to deploy them (sometimes they do but find themselves continuing their ‘old ways’ just in a different technology and surprise, surprise, aren’t seeing any value, but that’s a discussion for another day!). Understanding and deploying the full depth and breadth of capabilities is particularly important with enterprise software, which are significant financial investments that are expected to deliver a return. Buying a technology that’s fit-for-purpose is obviously key and having it deployed effectively by experts is also important, but as previously discussed in ‘Application Support as an Enabler’, empowering the business and IT organisations to get the most out of the software, requires continued investment in best-practice consulting, effective application support and on-going learning to up-skill and engage the user community.

Which, in a round-about way, brings me back to the headline of this post. We know that different people learn in different ways and content should be relevant to the user’s role and responsibilities. There are also different learning formats that lend themselves better to some content or purpose than others. Although there are many variations, the formats I’ve come across in the context of enabling a user community, typically of 5-15 users, in enterprise-level marketing technology, can be categorised as follows:

  • Reference material – self-learning through product manuals, knowledgebases/wikis, Q&A /community forums. The acronym RTFM (‘read the f’ing manual’) sums this approach up. Although some people find this really works for them, most find this tedious and ineffective.
  • Peer coaching – as mentioned, this is commonplace in my experience, at least in the context of end-users of marketing technology. Usually desk-side coaching from an ‘experienced’ user received as part of the on-boarding of a new staff member. The ‘experienced’ user however is often only able to talk from their personal experience which may be limited to the single use of that software within that one organisation. Peer coaching can also propagate mis-understandings, poor process and bad habits. The ‘coaches’ are often blissfully unaware that they themselves are doing things inefficiently.
  • E-learning – online training has become the default learning format in recent years, particularly for software.  Usually browser-based, self-paced presentations, with interactive content such as videos, quizzes and testing. This format lends itself well to supporting a distributed user base and can often be dipped-in and out of around ‘the day job’. The challenge here is often motivation to work through the content alone and what to do if you get stuck.
  • 1:1 SME coaching – having one-to-one coaching and custom guidance from an experienced specialist in the solution is hard to beat in terms of effectiveness. However, experts can be expensive, and this approach isn’t practically scalable for many or distributed users.
  • Classroom-based – literally the ‘old school’ approach, with students in a room, face-to-face with their instructor for a focused period of time, delivered as a public or private course, often on a client’s site. Fortunately, presentation-based training, where an instructor reads though slides of bullet points and screen shots for hours on end are largely a thing of the past – whiteboards, flipcharts, demos, workshops and discussion are far more engaging. Almost regardless of the content, the key thing that determines whether classroom-based training works is whether the instructor is knowledgeable, experienced and engaging – a key benefit to this approach is the ability to be able to ask questions and discuss your use case or experience directly with a ‘subject matter expert’.

However, no one approach is best every time, not even for different learning requirements within the same team or for the same software solution. As a rough guide for considering the best approach, I first think of the need along two dimensions.

  1. Firstly, where the software capability itself (or at least the scope of capability that the user needs to learn) is, on a range between simple and complex. Simple software/functionality might have a more linear user process or be wizard driven, while more functionally rich enterprise software, for example, might have more capabilities and multiple ways of achieving the same goal depending on specific requirements.
  2. Secondly, the level to which the user needs to get to, on a scale between instruction and understanding. Instruction might involve following specific, well defined and consistent steps or ‘how to’ type guidance, while understanding requires a fundamental comprehension of concepts, capabilities and how things work. Instruction may be enough but what happens when the requirement, data or process changes? To handle change effectively, you must have understanding.

In general, knowledge on simpler capabilities or those that require mere direction, can be transferred effectively via reference material, peer coaching or e-learning. As the capability becomes more complex or requires a more complete understanding, there is a greater reliance on the expertise and face-to-face discussion that comes with classroom-based training or 1:1 SME coaching – you really do need a discussion with an SME when it comes to understanding why you would use functionality/approach A as opposed to functionality/approach B for your particular scenario. The graphic below is an attempt to represent these dimensions and where the different learning formats are most effective.

Again, this isn’t a hard-and-fast rule, and there will I’m sure be exceptions.

Learning requirements also change over time. During an implementation project, a project team would benefit from classroom-based product training in order to design and deploy a configured solution that meets the specified requirements. As part of go-live, end-users will require training, not only on what the product can do and which buttons to press, but how they are going to use it to support their specific requirements, data and process. Coaching and workshops may be required to learn how a specific campaign requirement can be delivered. Once foundational knowledge is in place and the solution is in production, users can enhance their skills through micro-courses on the use of advanced functionality to meet changing and increasingly complex requirements.

Videos, podcasts, mobile apps and online courses all have a place in supporting focused or functionality-specific learning. Product documentation, knowledgebases and wikis provide reference for consistent instructions and standard process. Community forums, chatbots and AI all facilitate Q&A. The point is that classroom-based learning remains an important part of a broader commitment to enabling a business or technical user community. Some skills can certainly be self-taught or learned via online courses or bite-sized tutorials, but before a business can consider itself to be truly enabled on enterprise software, there must be an understanding of what their solution is capable of and how to best deploy that capability to meet ever changing requirements.

Finally, there’s no getting away from the fact that to ‘do’ learning properly, particularly as part of the wider enablement of a business or IT team, requires significant investment in staff professional development…but to appropriate a meme that does the rounds regularly on LinkedIn…

What if we enable them and they leave?

What if we don’t and they stay?

By Ben North