Behold my prezi on the subject:

People don’t know what they want. And what they think they want might not be what’s best for them. Ask a child what he wants and he might want sweets – that’s not necessarily best for him, but it’s what he thinks he wants. On the other hand, ask an adult what’s their ideal job – something much more complex  - and most will confess to having no idea.

There’s that Henry Ford quote which you’ve probably heard before (which may or may not actually be something he said, there is some debate) that sums it up perfectly:

If I had asked people what they wanted, they would have said faster horses.

Because whether you’re asking a simple or complicated question, the best you’ll ever end up with is what people think they want. They’ll start with what they know – think back to what they already have or what they’ve had before and base it on that. Give them another option, one that’s quite different to anything they’ve heard of, and they’ll probably say they don’t want it. Not great if you’re trying to innovate. Or offer something which sounds enticing, and they’ll say they want it even if it does nothing to solve their actual problems.

And there’s the key – solving problems. If you want to know what features to deploy, how to structure your sites, what topics to cover in training etc, don’t ask people what they want. Find out what they want to achieve. What tasks are they doing that they need to do better or quicker or more efficiently? What problem do they have that they’re hoping SharePoint is going to solve for them? What specific elements do they need to learn from a training course?

Finding out the answers to these questions is not always easy. But don’t just fall back on asking people what they want, because you’ll end up producing something that doesn’t meet their needs.

The temptation with technology training is to demonstrate all the things that the technology is capable of doing, or all the things that you know how to do with it. But it’s not a forum to demonstrate your extensive knowledge on the subject. You may have spent weeks or months (or even years) honing that knowledge. There’s no way you can (or should want to) offload all that knowledge during a two hour training session, no matter how good a trainer you are.

If instead, you approach it from the viewpoint of showing people only what they need to know in order to get their work done, then you’re onto a winner.

Less irrelevant crap for people to wade through and less wasted time for everyone involved. Simple.

I must admit (proudly) to not often coming up against words I don’t know the meaning of, and it embarrassed me slightly. After all, this is my field – technology engagement, employee engagement – if there’s a new management fad going round, I generally want to be on it. At least so I can say it’s a management fad and dismiss it with a (slightly camp, albeit) wave of my hand.

There was a cocooned safety in not knowing what it meant, but also a danger. I’m a consultant. What if someone asked me about it? Would I look stupid? Out of the loop? Not up with the latest trends? Would I have to find a longer, more complicated, word to distract them?

And so it was with trepidation that I clicked this link on Twitter this morning, posted by Guardian Tech (@guardiantech) - From Angry Birds to Draw Something: how gamification can work for you.

I read the whole article and I must admit to feeling a little disappointed with what I learned. Gamification, it turns out, is not a nasty illness but the rather more joyful idea of ‘adding a game layer to everyday activities’. Things like rewards, goals, competitions and progression to different levels. In an organisation going through change, gamification would mean designing ways of rewarding and incentivising people for changing their behaviour.

In other words, just what human beings and organisations have always done. As the article says, this kind of behaviour is ‘hardwired’ into us. To my mind then, that means it’s nothing new – apart from the fact someone’s stuck a fancy name on it, thus splitting the world into those who know what gamification means and those who don’t, but all acting the same regardless.

After reading this I googled it (I know, I could have done that ages ago) and checked out the Wikipedia result where the basic premise seems to be that you can take anything boring and make it seem like a game, and it won’t be so boring anymore. Like filling in a tax return, shopping, or engaging with technology. There are also various critics of it who say (and I’m paraphrasing from the Wikipedia contributor who paraphrased it before me) that it simplifies real-life interactions which may lead to disillusionment when they turn out to be actually more complex.

So what I’ve learned is that gamification is doing something that we, as humans, do naturally (i.e. creating games out of real life) and using that same technique to create games out of real life… at work.

Well, that was a morning of pointless research I won’t get back.

And if it’s really hard, we can be forgiven for not getting it right… right?

Well, here’s an idea which might help a bit. Stop assuming that everything is always going to be so difficult. Change your mindset. Tell yourself that it’s not change you’re trying to manage – it’s progress. Or improvement. Or anything which has a positive, rather than a negative, connotation. Tell yourself that you’re making people’s work lives better, easier or more productive.

It’s sometimes easy to forget that the reason for change is improvement, and to get hung up on the change itself. But look at why you’re doing what you’re doing, rather than what you’re doing, and leading that change process becomes easier.

So stop hiding behind excuses. Not everyone hates change. But people are looking for a good reason to change.

A blue postbox looks great, but would you use it?

If your intranet looks fantastic, then you’ve succeeded right? But succeeded in what? The thing is, making a fantastic looking intranet was probably not what you were asked to do, was it?

You were probably asked to deliver a fantastic functioning intranet. An intranet which is the place that staff go to collaborate, or to find out about the latest news in the organisation. And whilst it might look great, if it’s not achieving these aims, then it’s not a success.

So by all means don’t completely ignore how it looks, but don’t attach too much importance to it either. If it works well, people will forgive what it looks like. But if it doesn’t work well, then they won’t be looking at it at all…

Of course I can’t know for certain, as I don’t know you or your project. But in my experience, many people involved in tech implementations blame the users when things don’t work out, when they really needn’t look any further than themselves.

I’m not going to launch into a long list of reasons why people don’t adopt new tech systems. Long posts really aren’t my style, plus the variables are endless. But I will say that to get to the bottom of a lack of user engagement or adoption, you have to listen to the users.

And listen means listen – don’t try to offer excuses and don’t be defensive. I’ve been there – I know you’ve put in tons of effort and really care about what you’ve produced. I know you take it personally when people don’t want to use it. But defensiveness won’t help you get to the bottom of why they’re not using it.

Also, accept that it will always be a combination of things. So if you discover something that points to the why, don’t stop listening – there are bound to be more reasons.

I’m not trying to encourage a blame culture here. But establishing what’s gone wrong means that lessons can be learned and the situation can be improved. Nothing can be improved if everyone denies a problem exists, or worse, blames the lack of user adoption on the users themselves.

I’ve seen all sorts of reasons and a million blog posts on this topic, but I’m going to focus on just two:

1. People will probably have heard of SharePoint before. They might have used it in their previous jobs. You have no control over their experiences, but in launching ‘SharePoint’ you’re going to be stuck with their expectations.

And the reality is that a lot of SharePoint implementations that have been done over the past 10 years were done badly. In many organisations, the mention of ‘SharePoint’ will be met with a roll of the eyes and a rant about lost documents.

Don’t make life hard for yourself by bringing years of other people’s mistakes into your project.

2. Internal systems need to be marketed to the organisation in the same way as external products need to be marketed to customers. The people in your organisation are your customers.

So give it a name and a brand – something that fits in with your organisation; something that people will identify with. Hold a competition to suggest a name if you like.

However you go about it, make an effort to call it something. But FFS, just don’t call it SharePoint!

Banging your head against a brick wall?

OK, we’ve all thought it from time to time. It would be so much easier to launch a new tech project if our users weren’t so far behind us. They moan about change, they don’t listen when they’re being trained, they need us to tell them everything 10 times before it sinks in…. Sound familiar? It’s so hard to launch something under these conditions isn’t it?

If you could only get rid of all your users….

…Well then you wouldn’t need to bother with your project at all.

If you get frustrated with people who get frustrated with change, then implementing new technology is perhaps not the best business to be in (perhaps you could consider funeral directing?)

Because people don’t like change.

Especially at work. They might have spent years building up that business process until it works just right. They’ve got their desk just the way they want it. They’ve got everything all lined up and then you steamroller in with your new intranet, or whatever, and you go and change everything.

Of course they’re going to obstruct it. Get used to it. And deal with it pro-actively and positively.

A new tech product in an organisation is about so much more than getting the design right. People need to know how to use it. They need to know why they should use it. They need to know what’s in it for them.

If you take the view that this is their problem and that they need to man up and get used to the changes round here, then you won’t get very far with engaging them. Because it’s not about their attitude. It’s about your attitude. Yours and your team. Because if you have the mindset of always blaming other people when things don’t work out, you’re going to have a hard job working out whether you could have done things better.

Have you provided enough good quality training? Or too much so that people got bored of it? Have you communicated regularly – giving out the right messages to the right people? Have you provided enough support – both remote and on the ground? Did you promise too much and deliver less? Were you trying to force through too much change too quickly?

It could be any of these things. Or a hundred other. The onus is on you to engage your users, not on them to be engaged. The sooner you make peace with that instead of constantly fighting it, the more likely that engagement will follow. And that’s what success looks like.

Be prepared to train around your new technology system.

Somehow, somewhere, it probably interacts with some other system in your organisation and users won’t appreciate you saying things in training sessions like ‘that’s not my area’ or ‘that’s nothing to do with this new system’.

They want a seamless integrated tech solution (although they wouldn’t say it in so many words). In other words, they’re expecting you to be knowledgeable about anything even remotely linked to what you’re training on, so it’s a good idea to have some answers ready. And if the situation warrants it, you could even include a dedicated section in your training programme on the most obvious integrations.

While you’re planning your training programme, look for areas where your system meets another, or makes use of another in some way, and work that in to it. I was once working on a SharePoint implementation at around the same time as the organisation upgraded to Internet Explorer 7. I had some difficult training sessions before I added in a ‘Module 0′ for getting to know your browser. It wasn’t my responsibility to train the organisation in using browsers, as it wasn’t really part of my project, but I couldn’t ignore the fact that people were struggling to open a tab!

So just because it’s not your thing doesn’t mean you should ignore it. If you do, people will go away from your training and remember the stuff you didn’t answer. But if you’re prepared to provide some training or answer questions on anything related to your new tech, they’ll go away and remember how helpful and knowledgeable you are.

Are you up to the challenge?