Practical Solutions for your Software Development Challenges


Vol. 6, No.1 February 1999




Steamrolling the organization with process, or is there a better way?

by Neil Potter and Mary Sakry




 

Proving that the true skeptics are indeed truly skeptical achieves nothing, except that you’ve dented your pick and probably permanently diminished your credibility (and failed to appreciate the vital importance of building a fragile momentum).” [Peters, 85]

The adoption of any practice can be represented by the bell curve in figure 1 [adapted from Rogers, 1983]. Five distinct groups can be seen during the adoption of a new practice.

Group 1: At the leading edge you have a few who may be perceived as early champions or fanatics. These are the people who will try anything new, or ones that have a desperate need for your solution.

Group 2: After the fanatics there are people who would like to try the new practice but are not quite ready. The timing might be poor or further evidence might be needed. Beyond group two the challenges are greater.

Group 3: This group is typically the largest. This group needs considerable evidence from the first two groups before attempting the idea. Change is not seen as a priority, either because the current practices are comfortable, or there is no perceived problem to solve.

Group 4: This group consists of heavy skeptics who resist every change. There might be considerable mistrust regarding the motive for the change, or resentment built up from previous changes that have failed.

Group 5: This group contains the laggards, the people who would kill, or would like to be killed, before changing. Group five also contains people “retired on the job”. A laggard sees a paycheck arrive in the mail whether the change occurs or not.

Using the adoption curve.
There are two primary uses of the adoption curve when deploying a change:

1. To increase the speed of deployment, by determining who to work with, and in which order.

2. To reduce the risk of failure by building and deploying the solution in increments. The early adopters can provide specific requirements for, and feedback on, early versions of the solution.

Who to work with, and in which order.
Always target the early adopters first. The early adopters are the people with willingness and need to try the new idea. If you pick people in the beginning who do not have a willingness or need, this is about all you will prove. For example, one company decided to do a process assessment of two sister organizations. One sister loved it; the other hated it and learned little. In hindsight, the second sister should have been ignored. There was never a willingness or perceived need.

The people in group one will typically be more willing to help you improve any inadequacies in the idea or solution you are advocating. The solution you provide to the other groups will then be better tested and more robust. To increase the receptiveness of the next group, success stories from the previous one should be well publicized.

Building the solution in increments.
If your solution is complex, you might want to consider breaking it up into components. The audience you have in mind for the complete solution will probably not need every component immediately. For example, if you are developing a planning process, you might have components for estimation, risk management, negotiation, tracking, metrics, reviews and approvals. Identify the components that the early adopters need and develop these first. Use the feedback from the early adopters to design and refine the next increment.

Each component of your solution might have a different group of early adopters. For example: Some of the managers will be the early adopters for the negotiation piece. Some of the developers will be the early adopters for the estimation piece. The adoption curve provides information to help one set priorities.

In one company, a group was developing a process for subcontract management. After studying the adoption curve, it was realized that there were different audiences for each part of the process. The subcontractor selection piece had a different audience than the subcontractor tracking piece. The subcontract management process was broken into components and each component was developed and refined using a different set of early adopters. Some components, such as the subcontract auditing, were not needed by anyone until much later.

Who to avoid.
Some people believe that to implement change it is better to attack the most difficult groups first (the laggards and heavy skeptics) because they will need the most time to be convinced. There is also a common opinion that if you can “crack” these groups, the remainder will follow.

It is usually a mistake to start with the most difficult people. Ideas new to the organization take time to become credible. Successes from groups one and two will have a better chance of convincing a skeptic than all the preaching and memos in the world. If you were to work with the most difficult group first, you would not only encounter resistance, you would increase the likelihood of failure stories spreading across the organization. Bad news travels fast.

As for the laggards, ignore them. If you have individuals or teams that think your solution is the dumbest thing ever invented, ignore them (other than understanding their resistance). If you have a good solution, you should be able to find early adopters. By the time you deploy the solution to groups one, two and three, some of the laggards will have changed positions or left the company. If they are still in the organization, either the evidence so far will have converted them, or they will comply, albeit superficially, under the edict. You may need to leave the conversion of laggards to management. An alternative career path for laggards might be necessary.

I don’t have time for adoption curves!
You may feel that using the adoption curve is too slow for your organization, which has set a goal to have 120 practices adopted in the next six months in order to achieve the next process standard or maturity level. It is important to note that many organizations that rush adoption usually do not actually adopt the practices long-term. Someone might think that the practices are being used “because the deadline says so”. If you ask the developers and managers, you will find that some of the practices are being used, some superficially, but many not at all. One cannot master and internalize a new technique in a day, but one can pretend!

Not using the adoption curve can slow down the deployment of new ideas. The more resistance you encounter, the longer deployment will take. It is much quicker to work with people who do not resist.

Increasing the number of knowledgeable staff providing the expertise (often called process champions or a Software Engineering Process Group) can accelerate adoption. Some organizations use training companies so that more people learn the skills in parallel. Even so, the adoption and practice of the new skill takes time. A proportion of the audience will always believe that the new idea is a total waste of time.

Where to go from here.
In summary, we suggest you study your organization and use the adoption curve to facilitate your process improvement program. Start with the early adopters and don’t worry about the laggards for now.

Bibliography
[Rogers, 83] Rogers, Everett M., Diffusion of Innovation, Free Press, New York, NY, 1983.
[Peters, 85] Peters, Tom; Austin, Nancy, A Passion for Excellence, p357, Warner Books, 1985.

Top of newsletter