James Governor's Monkchips

Adoption versus Deployment: Nailed by Mike Gotta. Read This Post.

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

More great work from Billybob at Burton. Great piece arguing that we need to get better at ensuring people actually use the technology we deploy. No its not IT’s fault if people don’t understand how to use the platform- did you OK a major training budget? I thought not.

My sense is that organizations need to prioritize technology literacy and adoption issues over the next couple of years and closely involve IT organizations in such efforts. 2007 and 2008 will see a wave of new applications and infrastructure platforms coming out from major vendors and the emergence of more socially-oriented tools (e.g., blogs, wikis, RSS, tagging, and social networking). These new platforms do indeed offer powerful new metaphors for people to work differently than previous generations of technology.

But the tipping point, in terms of delivering value back to the enterprise, is shifting from deployment (simply making the technology available) to adoption (making sure that users change behaviors). This is more than simply training on the tools, it’s about making sure that users are aware of the capabilities of these tools (i.e., literacy) and are willing to work differently (take risk, explore new ways of thinking, new ways of doing and new ways of interacting).

Mike has nailed something important here. He is focusing on collaboration tooling (his beat) but the argument will stand up just as well for Microsoft Office 12, which is a different beast from its predecessors. It will require training to take advantage of its simplification…

If you’re an enterprise its time to start thinking about how to get people to use technology more effectively. If you’re a service provider its time to invest in training capabilities. If you’re a software vendor its time to think about packaged training, not just packaged software.

7 comments

  1. James, the opportunities that come from focusing on paths to adoption are way wider than just the enterprise. Right now I’m working on a project to create a design pattern for paths to IT adoption in the developing world. Specifically we want to map how people in villages or urban communities will use IT so that we can drive adoption of a new open-source information programme that helps people quickly fix water and sanitation problems.

    Right now I see a lot of pictures on NGO websites with bemused looking people gathered around computers.

  2. am I being too simplistic to suggest that we take some of that training budget and put it into good user centred design of applications in the first place so that they are easier for people to learn. You probably won’t need that bit of training budget we borrowed if you do 🙂

  3. There are two key lines from your extract:

    “These new platforms do indeed offer powerful new metaphors for people to work differently”

    and

    “making sure that users change behaviors”

    The emergence of the new Web2.0 type tools could have as big an implication on the ways organisations operate as office productivity tools such as MS Office ancestors did when they first appeared: good bye typing pools and memos – hello word processing and email.

    To what degree users actually change behaviours will depend on the ability of the tools to react and devleop in ways sympathetic to the needs of non-technical users. Too much Web2.0 stuff is still in the realm of techies – it has yet to cross the rubicon into the general user population in any major way. This does not mean dumbing down but rather a change of perspective (think of what Excel can do – it is far from dumb but it is built to be used by accountants and financial planners.) All of which means that the next year or so promises to be very interesting. And packaged training isn’t the blocker – the right training is: not functional training but use cases and inspiration.

    Ronan

  4. I think you’re observation about the adoption of technology speaks to the heart of what’s wrong with software development today (and ever since it was invented, probably). Namely – software developers (and all the other folks in that loop) see their job as delivering *software*. For me, the job SHOULD be about delivering business value (aka a WHOLE PRODUCT perspective).

    So it’s not just training that needs to be part of the package – in fact a whole bunch of things need to be in there to ensure that all the stakeholders (and not just the users) get real value from the product/service/whatever.

  5. Great feedback folks. Thanks.

    Mark – that sounds very interesting. I bet Lisa would be interested in this kind of affordance… 😉

    Lisa- people already have really bad habits and expectations… which is one reason i pointed to Office 12- have you seen it, and the new ribbon? its actually a far smarter, simpler, better designed way of dealing with building documents… but its not… “what people are used to”. its more user-centric design but its going to freak those users out. on the broader topic of social software use- as Mike points out we’re talking about behaviours… teaching people to fish rather than giving them fish. its not just a question of better designed apps, although it would be great if there were more of them. flow, and mastery, are about the *interaction* between user and application. affordance can achieve a lot but it can’t achieve everything.

    Ronan- so you agree then?

    Bob – it feels a bit like you’re falling into the “blame IT” trap there. most organisations do ask IT to deliver software – they don’t trust developers to engage with the business and interpret needs. which is where, for example, as you know only too well, agile and related methods comes in. Training is one element of good business governance- its underserved in all areas, not just IT/

  6. Hi James,
    Thanks for your response. I surely didn’t mean to imply that IT was to blame. I hope I understand the dynamics of the typical scenario you paint. And yes, many business people ask for software when they might be better off asking for a solution. But then I guess it’s unlikely they’d go to a *software* house for a *business* solution. And many businesses think they can save money by rolling their own solution around a software core (and generally don’t seem too good at that – with outcomes your posting mentioned, in terms of key elements like training getting omitted from the “whole product”).

    Nevertheless I stand by my original point, in that I believe it behooves software suppliers to point out these issues/risks to customers (allowing for the fact that they might get ignored or overruled), and EVEN AFTER THAT during the course of the project manage the risks on behalf of the customer (or push for the customer to manage them) – risks including the omission of key elements – like training – from the whole solution, when delivered.

    BTW Agile (e.g. iterative delivery of working software *into production*) can generally help here by highlighting these omissions very early in the game – when there’s still lots of time for the client to accommodate them into the project/programme plan for the whole product/solution.

    Of course, we live in an imperfect world… 😉

  7. […] Users tend to adopt software that they buy as opposed to the software the IT buys for them, which gets deployed… you figure out which side you would rather be on, I did. James Governor’s Monkchips » Adoption versus Deployment: Nailed by Mike Gotta. Read This Post.: More great work from Billybob at Burton. Great piece arguing that we need to get better at ensuring people actually use the technology we deploy. No its not IT’s fault if people don’t understand how to use the platform- did you OK a major training budget? I thought not. Posted in Uncategorized || […]

Leave a Reply

Your email address will not be published. Required fields are marked *