Over the years I’ve been privileged enough to work on different learning challenges and solutions across a lot of sectors. This list hopefully pulls out some of the bitter lessons I’ve learnt and shows up my mistakes so you don’t have to make them too.
Write a Vision
A vision is a version of the future that you are aspiring to. You should focus on what success will look like for your users, what they can do and how they feel. A vision shouldn’t include money or profits or return on investment but rather be the end state of success.
So don’t say “we’ll save £1m in 2 years”. Say rather “we’ll see users adopting the new standards and metrics improving”. The vision becomes your intent, your big hairy audacious goal, your lens through which you see the world. Once you have your vision you can ask yourself the key question: Will what we’re doing help us realise our vision?
Iterate your vision with your stakeholders
Once you’ve written it you need to share it. And this is the hard part. Your vision is yours, but for it to become powerful you need to let others see it and create their own version of the future. You need to work with them to create a shared vision, something everyone can sign up to. I’ve seen great projects fail because a single senior stakeholder didn’t understand the vision and thought it was going in a different direction. By the time anyone realised, the project was derailed.
You need to make sure you’re not precious about your vision, otherwise you’ll get hurt. Oh, and do this often. Check that they’re still onboard. This will save you a lot of time and pain by heading off objections, misunderstandings and the like.
Get your project sponsor on board
This person is the most important stakeholder. They need to sign up to your vision, trust your judgement and support you at a senior level. It is going to get rough, you need a backer. If you can’t get them wholeheartedly on board, do something else because this is not going to work.
Write a user experience
This is a tool you can use to help sell your ideas and solution. It’s simply a step by step walk through of what the user will do using your solution. It should include what they’re learning, how they’re feeling and the benefits they’re receiving. It doesn’t need to go into details or specifics. It’s just taking the vision and making it a little more concrete. You could see it as an extremely early written prototype that allows you to test the waters for the overall experience.
Like your vision, it will need to be shared, pulled apart and put back together again. But be prepared to defend it. You don’t want to be an order taker.
Win permission in increments
If something is too new, too different or just too weird then your stakeholders, SMEs and users won’t get it. The chances are that you’re not Steve Jobs able to create a new market. So you need to move everyone forward gently. Similarly, if you are the unknown quantity, you need to be prepared to slowly win people over by going in small steps, gaining their confidence. (Points 7 and 9 can help here).
We’ve all heard of show, don’t tell. I can’t stress enough how important this is because ‘the business’ doesn’t get learning. They get interfaces and flows though. So show them things they can relate to, and do it with pictures.
Speak their language
This can be tricky because it depends who ‘they’ are. What this means really is that you need to forget that you’re an L&D person when speaking to ‘the business’. You need to forget about it when talking to SMEs, or specialists, or clients, users. You must learn their language and talk their talk. You have to get up (or down or across) to their level if you hope that your solution is going to work. The real point here is that very few people are excited by L&D language and it often feels stuffy and too academic for outsiders. You need to stop this happening and speak in their terms.
Write your goals and outcomes
The old saying is that if you don’t have a target then you can’t hit it. Of course this is true and just because you have a vision doesn’t mean you don’t need goals and outcomes. Your outcomes can come at many levels but at this stage they should be an articulation of a particular part of the vision. Here you can be specific and fairly bold. You can aim to hit a certain business metric, or reach a certain number of users.
Remember to iterate these as well in the light of the development of your solution. For example, having an outcome of reducing Mean Time to Recovery by %25 is great, but as you get into the project you might realise that you can never influence that metric by that much. So change your target and make sure you tell everyone.
Establish your expertise
Or better yet – get someone else to do it for you. This sounds egotistical and needs to be done with complete honesty from yourself. Your goal here is to ensure that you’re left to do your job without unnecessary interference. I’m not suggesting that you ride over other people or that you assume that you’re right (see 14). But you need to be trusted and your capability shouldn’t be in doubt. Sometimes this means blinding them with science (caution – do this sparingly – see point 7) and sometimes it means over-ruling a decision because of your experience. Don’t be afraid to respectfully disagree with stakeholders when the time comes.
Set expectations early
It is very important for stakeholders to realise that everything isn’t going to be rosey in the garden and that they will have push back from users, SMEs and other interested parties. If your learning solution is any good then people will struggle before reaching the mark. Some people will not like the design or quibble over wording. You need to be honest and transparent up front and make sure you have a plan to deal with these challenges as they come in.
If you don’t, you’ll have a nervous stakeholder on your back second guessing you.
Who are your audience? The name of a team doesn’t cut it here. You want to know ages, educational and experience levels, gender mix, attitudes, work preferences, behavioural norms etc. Do the research and find the answers. Once you have that, give the different types of users a name, find a picture for them, give them a personality with a backstory. They become your test users.
You will then be able to ask yourself: Would this work for Frank the market analyst from Croyden who’s under pressure because of workload?
Don’t hire generalists
You should look for specific skills, people who are great at particular things. A group of specialists united under a shared vision is a very powerful team.
Plan to use natural assessment
Resist the call for a test or quiz at the end. You all know that it just tests short term knowledge. Instead, build in assessments that seek evidence of knowledge and application. If you need to train users on some software don’t ask them questions about it, get them to use it in a simulation.
Don’t assume you’re the smartest guy in the room
The final one is probably the most important. You are good at your job, but everyone around you is too and they’ll have ideas, thoughts and inspiration about the solution too. Make sure the environment you’re setting allows them to express that and make the solution as good as it can be. That doesn’t mean you can be a push over, but seek to grow ideas, use their experience and listen to it. Sure – you can discard it if you want, but remembering that you were once in their position with a killer idea will certainly help you.
Feel free to share your additions in the comments.