Comments on: Adoption versus Deployment: Nailed by Mike Gotta. Read This Post. http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/ An industry analyst blog looking at software ecosystems and convergence Fri, 03 Feb 2012 10:35:40 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Venture Chronicles http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/comment-page-1/#comment-9580 Venture Chronicles Wed, 10 Jan 2007 23:49:37 +0000 http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/#comment-9580 [...] 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 || [...] [...] 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 || [...]

]]> By: Bob Marshall http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/comment-page-1/#comment-9495 Bob Marshall Wed, 10 Jan 2007 11:34:36 +0000 http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/#comment-9495 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... ;-) 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… ;-)

]]> By: jgovernor http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/comment-page-1/#comment-9485 jgovernor Wed, 10 Jan 2007 11:20:59 +0000 http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/#comment-9485 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/ 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/

]]> By: Bob Marshall http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/comment-page-1/#comment-9472 Bob Marshall Wed, 10 Jan 2007 10:11:33 +0000 http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/#comment-9472 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. 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.

]]> By: Ronan Bradley http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/comment-page-1/#comment-9300 Ronan Bradley Tue, 09 Jan 2007 23:48:43 +0000 http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/#comment-9300 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 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

]]> By: leisa.reichelt http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/comment-page-1/#comment-9228 leisa.reichelt Tue, 09 Jan 2007 19:35:09 +0000 http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/#comment-9228 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 :) 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 :)

]]> By: Mark Charmer http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/comment-page-1/#comment-9172 Mark Charmer Tue, 09 Jan 2007 18:00:00 +0000 http://www.redmonk.com/jgovernor/2007/01/09/adoption-versus-deployment-nailed-by-mike-gotta-read-this-post/#comment-9172 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. 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.

]]>