Changing IT Mindsets From Deployment To Adoption

I’ve always found it interesting why the various tools we’ve previously thoughts as the “right answer” are continually replace by tools we believe to be “the next right answer”. We used to love e-mail back in the nineties – now we know hold it in disregard. We now think micro-blogging and activity streams will solve the e-mail problem. I wonder how long it will take for us to complain about those tools and pontificate eloquently about the next right answer that should replace them.

The point? Almost every widely deployed technology today that has failed to meet expectations over time, at one point was revered as the answer to our problems (productivity suites, content management systems, “groupware”, search, portals, etc.). While this might be the natural cycle of things, we might also have ourselves to blame based on the way we think about technology delivery.

One of the tag lines I’ve used over the years is that Enterprise 2.0 strategists need to think of their projects in terms of adoption not deployment. What I wanted to achieve with the catchphrase was simple – to persuade people to think about their projects differently. We never seem to be happy with enterprise technology – this is especially true when it comes to collaboration tools – and might very well be the situation with tools associated with Enterprise 2.0 in a few years unless we alter our view on what it is that we’re “delivering” and what constitutes “being done”. We should not be so enamored by what we think is our current right answer from a technology perspective that we forget the non-technological things we need to enable so that people (and the organization at large) can realize and sustain the value derived from use of the tools.

Within many organizations, the plan-build-run philosophy still frames our view of IT – once a system is implemented (i.e., deployed), the project is “over” – resources are reallocated, budgets are closed out, systems go into some type of maintenance mode or await the next release cycle of new development. We then wait and watch for the results promised by the project (e.g., ROI). Often those results are based on metrics that examine cause-effect impacts and improved business outcomes. We want benefits to be self-evident quickly. We tend to struggle when project results are subjective, can only be inferred, or correlated to improvements that take more time to emerge than anticipated.

While the situation I describe above is somewhat of an over-simplification, and not applicable to every enterprise, it is a reasonable scenario. My perspective is based on talking to many IT organizations involved in collaboration-related projects since 1996.

When it comes to collaboration, knowledge management, and E2.0 efforts, “culture” is often cited as the reason results fail to meet expectations set when the project is approved. While some projects might acknowledge the need to support post-deployment activities early in the planning stages, strategists and project leaders have consistently told me that they were surprised (and not in a good way) at how they underestimated the effort necessary to gain “adoption” of their solution.

To make up for the shortsightedness, we respond (after the solution has been deployed and after the project has officially ended) with governance programs, user experience enhancements, change management processes, and community outreach efforts. We collectively hope that “better late than never” heroic efforts can rectify the original mistake. In my experience, it’s a toss-up as to whether you can salvage the project in a timely and effective manner at that point.

As long as we equate project delivery with the end of the project – our frustration over time with “the new right answer” is going to follow the same cycle as previous techno-centric approaches. In many ways, what strategists and project leaders were saying is that delivery of the technology (e.g., blog, wiki, social network site, activity stream, micro-blogging) actually represented the beginning of the project from an organizational perspective. Some take-aways I hope you consider:

• Governance programs, user experience design, change management processes, and community outreach efforts must be treated as required components of the project. That means “time, money, and resources” must be forecasted upstream.
• Project completion cannot be viewed as coincident with technology deployment. That means thinking of people-centric initiatives like Enterprise 2.0 as part of an overall transformation program, not a one-off project.
• Metrics (and ROI) for people-centric solutions need to be recast. This remains a work-in-progress for the industry. We are in a state were we can find great stories of people working in new ways and in some cases, with real impacts. However, we're still in search of the right measures and ways to value people's participation.  

As an industry, we're still struggling with measuring E2.0 value. Some might call it a crock - some might say that the solution is to make all of E2.0 process-centric. Each argument has some level of truth. If we cannot define the business or organizational value then we are guilty of arguing for something that is academic, conceptual or a leap-of-faith (ala KM in the 90's). That does not make E2.0 wrong, simply difficult to "prove" (cause-effect). If we fail to include "social" with the context of actual work, then we limit how E2.0 can deliver real improvements. However, we should not hide behind process - or cede the value of participation outside a process context. All it means is that we're early into understanding the organizational dynamics in play when it comes to issues related to identity, social roles, formation of group structures, and social networks.

Note: The reason I am saying “as part of an overall transformation program” is to acknowledge that E2.0 is complimentary to the real business and organizational initiatives an enterprise might have. E2.0 for the sake of E2.0 is not the point – that would be making the same mistake KM initiatives made in the nineties. E2.0 can help with strategic talent and learning initiatives, CRM and BPM efforts, and so on. It is additive, or a means to an end. It should not be positioned as an end onto itself.

 

Comments

[DMOZ Listing]

In IT development is necessary and updation is also must.We always see that new versions or new updation of any software,tool or project comes fastly . Sometimes it raise problem like we created our project in old version of tool and then in new version sometime project can not run.So IT deployment is both Good and Bad also.

[Maria Helm]

Your comments about considering business culture/buy-in/adoption really resonated with me. I had to learn the hard way, after many projects, that this was an important part of the planning process, not a given. Just because a new technology is easier, more secure, and produced better results - that doesn't guarantee that end users will actually USE it. It turns out that humans are driven by emotion, and often use reasoning to support the decisions they've made via emotion. In other words, convincing them that it is a BETTER technology often fails...you have to convince them that they LIKE using it. Sometimes that is by making it look as much like the old process as possible, sometimes that might involve detailed user interaction during the planning process...or any number of other things, depending on the porject, the culture, the users. But the sooner you grasp this, the less heartache you'll go through over projects which failed for - apparently - no reason other than people failed to use them.

[christian briggs]

Hi Mike,

Thanks for such a thoughtful take on this. I particularly appreciate your point that time, money and resources need to be factored into such efforts early. This of course, means that leadership needs to be pretty well-versed in the potential benefits of adoption early as well.

In our research and work with organizations so far, we've found that the simple-looking nature of these tools ("Hey, it's like Facebook for work. Teens use Facebook. How hard could it be?") tends to mask the social/emotional complexity of using them in the enterprise.

As a result, we have found it necessary to address three different aspects of IT adoption when it comes to social software: the purpose (organizational strategy and structures), the tools (finding software that fits), and the most overlooked, but perhaps most important one: the people (the digital fluencies and relationships that the people have).

Importantly, we've found that fluency (comfort and high level of skill) with things like email, etc. does not automatically translate to fluency with things like internal collaboration tools.