technology chunking decomposing technology change into manageable chunks

on this page discussion elsewhere veryard projects contact us

Technology Change Management demands the ability to divide technology change into manageable chunks - and then to coordinate multiple technological change programmes. Sometimes the chunks are given - as presented by the vendors or champions. Thus Object Technology or Component-Based Development or Joined-Up Government are presented as coherent chunks of technology, suitable for defining the scope of a technology change programme. But even when there seems to be considerable consensus about these chunks, an adopting organization needs to review whether the scoping makes sense to its particular circumstances and requirements. And often there is no consensus at all - merely confusion.

Discussion veryard projects > technology change management > technology chunking > discussion

Priscilla Fowler

We have amassed quite a bit of informal evidence that dealing with too big or too loose a unit of technology risks the success of technology introduction (adoption, uptake, etc.) in organizations.

I cannot recall any literature other than Leonard-Barton's work on "scope" and "span" of technology impact from some years ago that addresses this issue.

Here's an example or two:

When organizations adopt the Software-CMM, if what they mean is that they are committing to do an assessment and some follow up work, including establishing an infrastructure for improvement, they have some chance of success. There is a well defined set of materials and products, and a community of consultants, who can help an organization succeed.

If, however, they are past the point of assessment, or choose not to do one, and begin to focus on adopting technology and process related to the contents of the Software CMM (i.e., the key process areas, such as SQA, Requirements Mgt., etc.), they run into somewhat more difficulty. They may be unfamiliar with the technology related to a KPA. For example, in recent work we've done on Requirements Management, many of those attempting to comply with the Software CMM in that area have never heard of the larger field of Requirements Engineering.

But at least these folks have the natural "chunking" by KPA to guide them.

In contrast, areas such as object-oriented design, GUI design, and COTS-based design, are sufficiently amorphous so that a change agent, charged with making these happen in his or her organization, has quite a bit of work just to determine what part of these areas to address, and how tools which may be available interact with the process of scoping down the technology. Who needs to learn what? How does the tool selection process interact with understanding the strategic objectives of this technology acquisition and infusion? How long will our sponsors wait before there are some results? How "big" an adoption effort, and how successful, must we accomplish in order to leverage more sponsorship for a wider effort?

Then there's chunking of the organization into units. I suspect there is more literature here. Leonard-Barton's work (and work of others, possibly Fichman) addresses the notion of (relatively) simple technologies such as email, which go broadly, but shallowly, into an organization. Versus a technology which is more "difficult", such as regression testing techniques, where adoption is narrow and deep, for specialists.

But we still have the chunking of the technology itself as an issue.

If you've seen any work on this, please publish the citations to the list.

Stanley M. Przybylinski

Nord and Tucker, in Implementing Radical and Routine Innovations, get to some of this.

The problem with a bundle is that adopters may be more or less ready to adopt pieces of the bundle.  And, since success most often depends on taking the whole thing, one or more pieces can hold you back.  In my experience you really just have to analyze and plan for each piece separately and then integrate the interventions in a way that makes the most sense.  For example, for the CMM you may have to do some (educational) remediation to get an organization up to speed on some tool or technique necessary for them to achieve a particular goal.  We tried to use this approach in a recent R&D program in Michigan with respect to the Internet.  A federal program (the Technology Reinvestment Project) was funding the development of a curriculum for community colleges around the use of the Internet (CoNDUIT, Cooperative Network for Dual Use Information Technology, for those of you who may be interested).  I tried to use the idea of the Internet as a bundle of innovations, with different parts of the bundle necessary depending on exactly what the Internet deployment goal was within your firm.  For example, if you are only going as far as email on one secretary's desk, the training requirements are much different than if you are building an internal network and getting large numbers of people using browsers.

The idea was to develop a range of deployment "breadths" (how much of your organization using the technology) and "depths" (how much will the technology affect the way these people do their work) and then have tailored curriculums to support the different options.

In my current work we are dealing with a similar issue in trying to deploy the results of Advanced Technology Program (ATP) projects (an R&D funding program of the National Institute of Standards and Technology) into small and medium sized manufacturing enterprises (SMEs).  ATPs are by definition high-risk and high reward and are usually heavy on the
science and engineering.  In contrast SMEs are often lucky if they HAVE an engineer.  How do you span that gap?  What we are considering is developing a curriculum for these SMEs that could be created and deployed in parallel with the technology development.  Once the results are ready for deployment, you might have more SMEs that can at least understand the new technology.  That's the theory, anyway.  ;-{)

Actually something like the CMM is uniquely suited for these type of approaches, since the skills, techniques, and the measurement of their successful use are more or less built into the process.  It is much harder when you have to define the bundles from scratch.  This analysis is very context dependent, i.e., an piece of the bundle unknown to one person or part of the organization may be very familiar to another.  I think the work of Tushman and Anderson on radical and routine
innovation, in particular "competence-enhancing" and "-destroying" innovation could help in the analysis.  (Tushman and Anderson.  (1986) "Technological Discontinuities and Organizational Environments", ASQ, 31: 439-465 and related papers.)

I hope this was a positive contribution to the discussion.

Stanley M. Przybylinski, Principal Member Technical Staff
Industrial Technology Institute, 2901 Hubbard Road, Ann Arbor MI 48105
Voice: 734-769-4517  FAX: 734-213-3405  Internet: smp@iti.org
WWW: http://www.anteater.ann-arbor.mi.us/smp

top home page contact us
in asssociation with	This page last updated on October 6th, 2001 Copyright © 2001 Veryard Projects Ltd http://www.veryard.com/tcm/chunking.htm