Adoption is the problem

Spent a good portion of my commute on the metro last night and again this morning thinking about  information technology and productivity.    With all the “labor-saving” and productivity tools you’d think as an industry we’d be fairly smart with incorporating such into our standard work efforts.   However, over the past twenty years I’ve been tracking improvement efforts I’ve come to the obvious conclusion there is a big difference between deployment and adoption. 

The first is a series of tasks, the later is a behavioral change.  Often the best ideas and solutions fail.  Not because these were technically wrong, poorly tested, or were not deployed correctly.  These ideas failed because they didn’t take into account the human element into the system.  (By system I don’t only mean physical/informational technology). 

When I worked on developing and deploying a new process for one of my employers, they had a long history of failure in re-engineering this specific area.  The original teams–three previous– all spent time on building the most technically complex and automated system.  Then sent out an edict from corporate demanding compliance.   Groups, divisions and people complied to the letter of the law.  As confused as people were the system was operated, data entered, and not one thing changed on how people managed the business.  

The initiative became just one more set of reports and busy-work for people to do in addition to getting the real job accomplished.  In effect management had increased reporting and visibility but lower productivity.   Over the course of time the effort was seen as a failure as was quietly put to bed by yet other re-engineering efforts.  

I was likely to have repeated the same mistakes — and do on occasion too — if it wasn’t for being asked by Corporate Management how I would do things different and how long would it take.   I broke the problem into two pieces; 1) solution building & deployment 2) Adoption planning, execution and management.  The first took less than a year for version 1.0.  The second took four years in all in which three versions were developed, deployed and adopted.        

Management asked why so long?  My response was “Design and deployment are easy, Adoption is hard”.  With a knowing nod I was given the project.    The details of design are not really important to the point of this article.  What is on keen importance was figuring out how to move from deployment to adoption.

The tools I used though rather unorthodox, in this context, were concepts like CMMI, Six Sigma, and ISO-9000.  This became my adoption management system.  Along with developing a deployment team across the corporation and an educational curriculum the basic tools to address adoption were put into place resulting in a success where another failure had been predicted.  Later on my employer asked me to “box it up” so it could be sold to their customers also.  However, the consulting teams that attempted to sell and execute did not grasp the difference between deployment and adoption, so had poor results on engagements, which provides proof the the premise.


About briankseitz
I live in PacNW in a small town and work for Microsoft as a Enterprise strategy and architecture SME. I enjoy solving big complex problems, cooking and eating, woodworking and reading. I typically read between 4-8 business and technology books a month.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: