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:
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.
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?
In part 1 of this series of articles looking at Marketing Automation, we looked at a high-...
There are a lot of definitions around for Marketing Automation. Vendors will often talk of it being ...