Nudge the network

Nudge the network

If you do have a spare 30 minutes I would recommend reading the Behavioural Insights Team Update report.

Click to access BIT_Update-Report-Final-2013-2015.pdf

As more enterprise tools such as O365 / Yammer and Jive the old traditional methods of IT adoption fail (if they ever succeeded) and that’s where the digital transformation agenda takes over. IMO any deployment of collaboration tools need to look at behvaioural insights, nudging the network and behavioural economics to ensure success adoption.

Stick to the recipe for Enterprise Social Software success

Stick to the recipe for Enterprise Social Software success

When I look at reasons given by organisations for the failure of their Enterprise Social Software project to deliver any success or value (whether this is adoption or return on investment or engagement) I still hear the same issues around poor adoption, cultural issues specific to the organisation, change management, alignment to business needs etc. You could date stamp this as ‘2010’ and the issues haven’t changed.

It still amazes me that in 2015 organisations are struggling to get value from social software despite a reliable ‘recipe’ now being known.

All consultancies both large and small have a framework which is pitched to potential clients that will deliver various degrees of success – but success nevertheless.

Every software vendor has similar material that it will tell clients prior to any adoption programme how to get success (actually an interesting exercise would be to look at how the vendors have changed their ‘tune’ from 2008 onwards by looking at how their client adoption material has changed from ‘just plug it in’ to more strategic thinking).

I would also suggest that the vast majority of organisations that deploy Enterprise Social Software have an understanding or at least an awareness of what needs to be done – and I speak from a perspective or having sat on both sides of the table (industry and consultancy) and I would estimate that 90% plus of people I have dealt understand this.

But despite all this material a large majority of organisations appear to ignore the recipe.

I’m trying to find a simple analogy to compare this with so let’s try cooking.

If I were a chef (the ‘sponsor’ of the deployment) and I wanted to make a paella (deploying the tool) and I have a known recipe on how to make paella (the vendors material, consultants material, freely available material online etc.); then why do I think my paella will turn out fine if I refuse to use some key ingredients like the correct rice, saffron, paprika, wine etc. (change management, governance, use cases etc.)?

Some may be down to cost; some may be lack of knowledge – but wouldn’t you look at the recipe before you start!; some may be down to stubbornness (you deployed other tools before and your way has always worked) but I believe in many cases it’s down to the simple fact that most sponsors are purely concerned with plugging it and making sure it works from a technical perspective – and not appraised on the engagement or value it brings. No different to a chef not being appraised on how good the paella is but the fact they have served up a plate of rice that is dressed up as paella but has none of the taste.

Unless the success criteria is driven by engagement and value – which often happens a number of months into the adoption phase then organisations will continue to cite the same issues with their Enterprise Social Software.

The vendors realised their business model needs to change – not so much about selling licences every 5 years but seeing their software being adopted, adapted to working ways and providing value.

Few areas of an organisation focus on how engaged their workforce is with the ‘service’ provided but this will change. It will eventually filter down to project teams that are built to deploy social software.

In my ideal future world deployments will focus on behavioural change rather than just technology change in order for social software to be a success.

A project team for future deployments will have a very different line-up. The focus won’t be around IT Project Managers or business analysts but instead recruit business psychologists, community developers and social network analysts to ensure social software success.

Avoid the usual suspects

Transformation programmes are changing dramatically in the digital age.

The main theme of traditional deployments of tools was that change programmes were slow (cascaded from the top, filtering slowly down), soloed (by geographies, levels and departments) and exclusive (owned by leaders and nominated change agents).

In the digital era change is now fast-paced (focused on habit-forming to kick-start new behaviours), focused around behaviours not technology and inclusive (allows everyone’s input to be seen and for social learning to happen).

One of the key changes is the advocacy network that can be built. Forget reaching out to management and asking for the ‘usual suspects’ – the same folk that get volunteered for most change programmes. Use digital and networking technologies to create a broad number of advocates.

It doesn’t matter about the time commitment. Ask then to do what they can when they can. In the digital age getting volume at the ground level is important. Avoid traditional messages on the intranet and focus on getting role models, word of mouth and great use cases. This will spread the transformation far quicker than going through traditional and failing channels.

What goes where?

Employees are faced with a range of tools to communicate, collaboration, share and network. Simply deploying new tools just confuses an already overworked organisation.

To expect many to understand what tool should be used in which context is foolish. One of the most important documents you can produce in the early days of a collaboration tool deployment is guidance to participants about what goes where.

This could be dressed up as a content strategy document, outlining where implicit and explicit knowledge / content should be stored or a straightforward guide on which tool to use when. Just map out some business scenarios and give people ‘guidance’ on which tool can be used to accomplish the task most efficiently.

Get this document into the environment early and it will save you lots of time answering questions from confused new adopters of the collaboration platform.

It’s more than just the coaching

At my current client we are running a series of ‘beginners guide’ coaching sessions for those that are new to business networking platforms.

We run through the basic concept of using a networking site, the importance of your profiles, how to use the network to get value by following people and groups, etc.

Most platform vendors will claim that little training or coaching is needed as their respective tools are intuitive. But not everyone is on a social network in their personal life and I find some coaching is needed to ensure ‘no one gets left behind’. It’s a common approach, particular from IT departments that run these projects.

But the challenge does not end there. Just because someone now knows how to do something doesn’t automatically mean they will begin using it.

We mustn’t confuse ways of imparting knowledge with ways of changing behaviour. To encourage a behaviour we need to generate the best conditions for it to arise and then reinforce it. Merely knowing what you should do is often insufficient to reliably bring the behaviour about and merely knowing doesn’t offer much in the way of reinforcement.

So to support the behavioural change we are also coaching how colleagues can
develop highly engaged communities through some hints and tips around building habit formation as a step to changing behaviour online – some steps you can take to ensure your colleagues begin to regularly participate on the business networking platform.

Coaching participants on how something works is fine but the value comes from coaching on how to develop habits to utilise the capabilities of the network on a regular basis.

Don’t mandate but encourage

Don’t mandate but encourage

The key to getting sense from any networking and collaboration platform is to embed good behaviours of users rather than force templates or processes through technology.

As people gain more experience they will see the benefit of how they need to relate groups or content and begin to adopt good behaviours rather than mandate too much at the beginning which I believes restrict the desire to engage.

I firmly believe that if you alter that level of ‘control’ to an extent where you mandate to much, much of that implicit knowledge is lost due to people’s lack of engagement. I’m sure everyone has seen systems that deal with every workflow, scenario and linkage, with lovely metadata and taxonomies but they remain graveyards. I would also stress that we are not discussing a ‘heavy duty’ document management system here but a networking and collaboration platform where we are looking for people to share their knowledge.

One of the most interesting studies on knowledge sharing was conducted by Constant, Kiesler and Sproull.* One of their findings was that employees differentiated two kinds of knowledge sharing. One type was sharing products, for example, equipment manuals, or reports they had written. The second type of knowledge was what employees had learned from their own experience, for example, how to get around a certain bottle-neck in the system, or how to deal with a particularly tricky bug in a program. This second type of knowledge they regard as part of their identity – part of who they were as professionals.

They were willing to share both kinds of knowledge, but the motivation for sharing each differed greatly. The documents and programs they shared because they considered them the property of the company. But the second kind, their experiential knowledge, they shared because they gained some personal benefit from doing so. The personal benefit, however, was not money or the promise of a promotion. According to the study, “Experts will want to contribute to coworkers who need them, who will hear them, who will respect them and who may even thank them.”

As this study shows, the primary driver for sharing experiential knowledge is the respect and recognition of peers. It is hard to overestimate the psychic value peer recognition. How does this relate to controls and mandates? The less freedom a user has over the ‘platform’ (whether this was a technology or a physical environment) the less they would share their own experiential knowledge.

Organisations that have created great engagement and value from collaboration technologies have done so because they have reduced many of the controls that you would find in their more structured channels such as intranets and document management systems.

It may not always be neat and tidy but it generates this ‘experiential’ / implicit knowledge that organisations have tried to tap into since KM programmes first started. If we initially focus on getting the engagement, input and desire for folk to share then the quicker it is to make sense of the noise that social collaboration platforms can bring.

No organisation should fail as a social business

707

It still does amaze me that Deloitte (see below) and Gartner (80% of social business efforts will not achieve the intended benefits”) still have the ammunition to produce these reports.

http://www.deloitte.com/view/en_AU/au/services/financial-advisory/deloitte-access-economics/collaborative-economy/index.htm

Social Business tools have been around long enough for a successful best practice approach to be evolved. The focus should be away from traditional IT implementations onto good strategy, governance (or stewardship) and transformation that will lead to most organisations that want to become social businesses achieving success.

The strategy needs to ensure the capabilities, deployment and utilisation of both technology and people align with the overall goals of the business.

The governance / stewardship needs to ensure the technology deployed is sustainable and the quality content filtered through the technology can surface above the redundant noise that will occur in many organisation and can be utilised to assist in achieving the overall goals of the business.

The transformation needs to ensure people and their communities /  networks have an understanding of how, what and when to share and collaborate to help meet the goals of the business.

But I guess most organisations are treating the tools similar to their approaches to knowledge management initiatives of the past. Build it and they will come. They focus on the technology (plugging it in) rather than the transformation needed to change people’s behaviours to adapt and cultivate new skills that are enabled by the technology.

I fear in 5 years the Gartner’s and Deloitte’s of this world will still be producing the same old reports.

Go where the energy is to build an advocacy network

Image

 

One of the key themes (or attitudes as I would like to call it) of the business change project team, involved in putting one of the world’s largest airlines into the Cloud (O365), was to look at changing the normal business model and, in essence, changing the way we worked. 

An excellent example of this was the way we recruited the advocates (called Mercury Heroes) for the programme who would spread the message, coach their colleagues and be general role models in changing the way people worked through using collaborative tools.

The normal approach would have been to reach out to leadership with a request for nominees. If we were lucky we would get the ‘normal suspects’ who would be involved in every other programme and dutifully attend induction and go through the standard actions. This was not a model for us to follow!

Instead we began to practice what we preached and started to use the power of Yammer. With an agreed set of principles and objectives (but no core job description) we by-passed the traditional middle management (general road blockers with this sort of activity) and reached out to active users on Yammer (going where the energy was) to become advocates. These people were already changing the way they worked by using Yammer and we deliberately avoided the traditional ‘floor walkers’ that IT departments would generally use for the role. It didn’t matter if you were of a management grade or role within a department – we wanted people that had a desire for change rather than a knowledge or technology.

I should add we tactically deployed Yammer as the first of O365 as:

1 – it was simpler but
2 – it was one of the ‘game changers’ that would teach us so much about behaviours in a short space of time, enable us to deal with lots of leadership concern early and, if we got it right, provide us with ready made advocate and communications channels for the remaining roll-out. 

The strategy was to go for numbers. Not dissuade people with a rigid job description or time commitment but giving them a set of principles and objectives and asking them to ‘do what they can, when they can’. The assumption was to have such a large volume of advocates that it didn’t matter if we have gaps in coverage or people away during certain activities – we had the numbers to cover. 

We provided a core toolkit and built a coaching programme for them and there were some prescriptive elements around Outlook coaching, but in essence we began using the power of social networking to spread the message and the coaching. Heroes were asked to deal with any permission issues from their management. 

Microsoft challenged us to get 350 advocates for the beginning of the roll-out programme. Within 6 weeks we had over 900.

Some of the initial success stories include:

Over 400 Mercury Heroes attended physical and online Yammer coaching sessions in November with the challenge to recruit colleagues and join a group or discussion in Yammer. From the 8 weeks leading up to Christmas over 1000 new people were joining Yammer each week (with engagement levels at over 50%). 

Volunteers for use cases, testing, focus groups for SharePoint, OneDrive etc were recruited within minutes rather than days or weeks in normal programmes. 

There was some resistance to the ‘social approach’ we took and in some areas we needed to be more prescriptive (interestingly many of these were IT related departments) but the approach got us 90% plus of the advocates we needed. 

As the whole campaign was based on behavioural change and new ways of working (not the tools or IT deployment) the intention is not to stand the Mercury Heroes down once the roll-out is complete but to use them as a legacy for collaboration (and others projects) within the airline.

Giving people a voice

707 

 

Just saw this from Ragan and it shows how enterprise social networking tools can be used to engage all areas of the business and gain valuable insights.

http://www.ragan.com/Main/Articles/How_Yammer_connected_Air_Canadas_employees_47932.aspx

For too long we have focused on so called ‘knowledge workers’ as the major users and contributors of the social networking but, if cultivated correctly it can benefit every level and both management and workers.

There have always been fears about giving people voices in organisations but enterprise social networks have been successfully been deployed in unionised environments with more benefits than detractions.

From my own experiences one factor I believe that helps in this deployment are meetings and processes around ‘contingency planning’, from incidents at airports and in the sky, media breaches and industrial relations. We mapped out processes for each scenario that we highlighted to leadership as appropriate. These eased a number of fears. 

Also it was vital to show that this environment benefited everybody, giving workers a voice and also providing insights for leadership. One of the ways of achieving this was the development of advocates in crucial areas of the business, whether they be union activities that could spread the benefits of a tool that gives people and voice and begins to make the whole organisation more transparent and democratic, or leaders within departments that saw how much value they could get by receiving immediate insights into products, processes etc. 

This is not achieved through guidelines and corporate missives by but meeting and talking to people (lots of them) and spreading the word. Its people and not technology we engage with so it’s very ‘old school’ in terms of building this network – not just face-to-face but individual conversations via Yammer, email, face-to-face etc. 

One of the signals that I believe this was successful was an occurrence when a new member made a post about ‘how much money had the company wasted on this Facebook gimmick’. Before any of the core team could respond a large number of users from all levels of the business came on to defend the platform and giving real life examples of how Yammer helped them as individuals, as teams and as an organisations. 

I think once you get people thinking the platform is their voice and not a corporate tool then you can sit back and pat yourself on the back (only for a few minutes though).

Why collaboration fails

714

Just a quick brain muse here about why collaboration initiatives fail in organisations. Here’s my take on it:

Organisation Context

  • No collaboration strategy (not technology but business)
    No integration with People agenda
    Seen as an IT deployment. Technical solution before business requirements gathered
    No governance – ‘no one in charge’
    No linkage with other systems (intranet)
    Little ROI identified for the business
    Not replacing existing tools
    No business change framework (approached from a psychological / attitudinal perspective rather than technological)

People Context

  • No guidance on how and what to share in a business context
    No training / coaching (for users and management)
    Fear
    No attention paid to behaviour or culture
    No clarity on ‘what goes where’
    No change management framework
    Left to organic growth
    No communities or networks developed
    No advocacy programme

Please chip in if you feel I’ve left anything out and we can start to build a comprehensive list.