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

The Cascading Impact of Y2K by Jeanine McDermott, Software Project Manager   The goal to provide quality software depends on many factors. One of the recent factors is that the software be Y2K compliant. For software to properly handle the millennium problem, a multitude of issues need to be closely managed. Some of these issues are within our immediate area of influence, and other issues are outside our direct control. The goal to provide quality software depends on many factors. One of the recent factors is that the software be Y2K compliant. For software to properly handle the millennium problem, a multitude of issues need to be closely managed. Some of these issues are within our immediate area of influence, and other issues are outside our direct control. Internally developed and maintained software needs to be addressed regarding Y2K compliance. Basically, the steps are as follows: • Identify the areas that may be affected by the Y2K date problems • Determine the magnitude of how much the problem will affect the software product and its related systems • Select a method for addressing each affected area, i.e., fix it, upgrade it, or throw it away • Implement the solution according to its priority among all the software that needs to be addressed • Resolve the Y2K software issues and then test them with all their interfaces and related systems • Release the Y2K-compliant software to the customers Performing the above steps may resolve internally developed software but doesn’t completely solve the Y2K problem. There are many underlying Y2K factors that also need to be addressed. It is important to realize that a software product is dependent on many external components, (i.e., a supply chain of vendors and software) that we each rely upon for daily business operations. The following items identify how to attack this side of the issue: • Identify all the external software that is used. This includes the operating systems, databases, test and de-bug tools, software configuration management tools, cost estimation tools, etc. • Identify all support systems that may possibly contain software. These include the phone system, desktop computers, elevators, and security systems to name a few. • Contact the critical suppliers and vendors to determine how their Y2K compliance efforts are coming, and whether they have contacted their own chain of suppliers and vendors. We can be impacted if the supplier’s order entry system or 24-hour support line fails because of a Y2K problem. This is a risk that must be addressed, especially when a Y2K problem can directly affect critical operations. • Develop a schedule for introducing the Y2K vendor/supplier software into the corporate environment. A transition path is needed because some systems may depend upon other systems&emdash;particularly when a software interface has changed and the new software is not backward compatible. • Test the new Y2K compliant vendor/supplier software. The Y2K compliant version is not exempt from its own bugs. • Produce a contingency plan just in case something fails later. A work-around may be needed if a situation becomes crucial. Top of newsletter

Y2K sources on the web Review by Mary Sakry There are numerous Y2K sources on the Web. I spent days crawling around the sites. They are easy to find and contain lots of links to yet more sites. Today, I’ll focus on my favorite site which is at www.year2000.com. If you want further resources, there are lists at that site. This site contains a robust list of “Frequently Asked Questions about the Year 2000 Computer Crisis”. It is maintained by Robert J. Sandler and was originated by John Moffitt of Jager & Company, Limited. This is a great resource because it covers such a wide range of topics and gives you additional resources if you need more details. This is not the sort of document that you would read from front to back, but rather something to browse through and find topics that interest you. It flows well by first defining the Year 2000 problem(s), followed by problems related to specific hardware and software, social and historical aspects, calendars and date representations, and finally providing resources and tools for fixing the problem. The first section helps you understand the Y2K issues and gives you a feeling for what is important. Other sections give very specific information, such as detail for each operating system or application. Neil’s favorite is an article that he found at www.mitre.org/research/y2k/docs/DATES.html that gives a nice list of important dates that can be problematic. Overall, I think the web is a great place to go for information, but beware that the links go on and on forever. I spent days wandering around, often finding the same information in different locations. I like the FAQ’s on the year 2000 site the best because it covers the topics I care about most and is well organized. In summary I suggest you look at the following sources: http://www.year2000.com &emdash; very good starting point http://www.mitre.org/research/y2k/docs/DATES.html &emdash; http://www.brite.com &emdash; the list of important dates to check The following article is another good Y2K resource: Watts S. Humphrey, “Year 2000 Readiness Checklists?” Software Engineering Institute, Carnegie Mellon University. CROSS TALK - The Journal of Defense Software Engineering, July 1998. Top of newsletter

© 1999 The Process Group