1
Assessing the Need
In a world that is becoming increasingly mechanized, we as data processing professionals have not placed significant emphasis on improving how we perform our own jobs. Although we have spent decades automating the manual processes of virtually every other profession, we have only recently turned our attention to what I term “mechanization of the mechanizers.”
Mechanization of the Mechanizers
Recently considerable attention has been given to productivity in our profession. There are several compelling reasons for this belated attention. The most significant reason is directly related to the maturity of data processing as an industry, as well as the increasing maturity of the individuals who comprise it. We are no longer bright-eyed young kids right out of college, brimming with energy and enthusiasm. On the contrary, we have all been through development of countless systems and if we don’t know the perfect way to engineer software, we surely know what we would like to avoid. We have had a lifetime quota of bringing up systems both behind schedule and over budget that do not begin to satisfy their users.
In fact, we are beginning to question the cost of our successes. Remember the last “successful” system you developed; the one that was on time, within budget, and appreciated by the users. You will probably also recall that this was the time when you did not see your family or friends for days on end, your project leader developed an ulcer, and your technical guru resigned! We are beginning to ask ourselves not only “How many times can we go through this?” but also “Is it worth any reward?” Therefore, it is not particularly astonishing that many of us are now actively seeking relief by searching for better ways to develop systems.
Considering the increasing share of the corporate budget that is dedicated to data processing, it is also not surprising that there is increasing pressure to rectify any inefficiencies in system development and maintenance. In many companies, small as well as large, top executives have begun to take an active interest in the problem. The result of all this heightened awareness is an ever-growing industry that is comprised of a wide variety and assortment of tools and techniques that purport to improve productivity.
Difficulty of a Technology Transfer
However, even though it would seem that the time is right to mechanize the jobs associated with developing software, this “mechanization of the mechanizers” does not appear to be a totally smooth evolution. The average person in any area of data processing is not only usually overworked and behind schedule, but now also faces a steady barrage of new technology, theories, methodologies, and tools. Moreover, due to economic considerations, it is not uncommon for top management to adopt one of the increasingly popular computer-aided software engineering (CASE) tools as a solution to everyone’s collective problems.
Some of these innovations are helpful and some are not but usually no one has given any thought to whether or not the products are appropriate for a particular organization or company. The difficulties of implementing a new technology have very little to do with the quality of the product itself; rather, they are related to the intangible but real obstacles associated with overcoming resistance. This resistance implies that the rate of technology transfer is directly related to the ability of the agents of change to gain acceptance from their users. Thus data processing managers and their employees are quickly discovering that in order to improve productivity, they must invest in more than a tool or technique. In those groups that manage to achieve substantial improvement, a fundamental change in attitude occurs that borders on a cultural revolution.
The Mission
Several years ago, I set out on a crusade. Management declared me a missionary and commanded me to go forth and convert everyone in our organization. The religion I was preaching involved embracing the concept of productivity in the form of an automated software tool called Excelerator. As far as I can decipher their motives, my management selected me because I was a true believer; in other words, I was the first convert.
Given the hype associated with CASE at the time, I was positive that everyone in the data processing industry had productivity as a high priority. I believed that the beleaguered managers as well as their staffs would welcome major changes in their daily work life. Needless to say, I was in for a real surprise. Although most managers and their employees consider productivity an objective, it is almost never a priority. A priority is putting in a production fix by 6:00 A.M. the following day or meeting a deadline for the next release. Changing how you perform the activities that comprise your job so that the quality of your systems and your daily life is improved was viewed as a luxury or even a nuisance.
At that stage of my data processing career, I already had considerable savvy, having progressed through the years from a development staff member to the management ranks. I quickly assimilated the message that was being communicated and retreated to rethink my position. Many thoughts came to mind, not the least of which was that I still believed (with all the fervor of a convert) in achieving our original objective: implementing a CASE tool to improve productivity. The year that followed made an indelible impression on me and on my management. We succeeded in our implementation—not as rapidly and dramatically as we had envisioned, but perhaps with more thoroughness and acceptance than anyone had anticipated.
The Life Cycle of Implementing Change
Afterward as I reflected upon the approach we took and the techniques we employed, it occurred to me that this was far from the first time I had traveled this particular road. Moreover, the more I analyzed and compared previous change efforts to the current one, I realized not only that we had become increasingly adept at implementing change, but also that we tended to follow the same steps and techniques for every effort. Given the sequence of events and my analysis of them, I arrived at the only possible conclusion: Just as there is a life cycle for developing software, so too there is a life cycle for implementing change (see Figure 1–1).
Moreover, it is my firm conviction that the basic structure, activities, and approach will be the same for implementing any change. Although there may be differences at the detail level, no matter what product you have chosen as your vehicle for improvement, the phases of effecting change will be as follows:
Assessing the need
Selecting the candidate products
Evaluating the products
Presenting the product
Gathering information
Planning the implementation
Implementing change
Finishing the implementation
It is the objective of Agents of Change to describe each phase in great detail and to provide examples (failures as well as successes) based on the experiences (real, composite, and apocryphal) of myself and my fellow change agents. Since the process was not revolutionary or dramatic, it can provide assistance to any manager (at any level in the organizational hierarchy), project leader, or systems analyst. Thus, it is now possible for many data processing professionals to become change agents and to successfully implement new techniques and tools in their own environments.
Figure 1–1 The Phases of Implementing Change are Always Exactly the Same and Therefore are Independent of a Particular Technology That is Being Introduced.
Is the Time Right?
The very first step, before you even begin to search for productivity tools or techniques, is to determine whether or not the time is right for your environment. This seems like a vague and insurmountable task; however, there are signs for which you can search. Here is a test that you can take on behalf of your department that will help you make the determination. Answer the questions with your initial reaction; this will reveal the propensity to accept change at this particular time.
1. Is your organization newly formed?
2. Are the functions your organization performs new to your corporation?
3. Is your organization growing at a reasonably rapid rate?
4. Is your organization responsible for the development of new systems?
5. Is there a general attitude of optimism, and is morale high?
6. Are your analysts and programmers utilizing tools or methods that improve productivity?
7. Does your management support the concept of productivity in any way?
8. Is the staff experiencing motivation problems?
9. Is your organization responsible for mature systems that are primarily in a maintenance mode?
10. Does your organization have a backlog of user requests without enough resources to implement most of them?
Your answers and what they indicate may surprise you and you may even seriously question whether you can adequately represent your organization. However, the intent of this self-test is to assess attitudes, and your responses should accurately reflect the attitude of any organization of which you are a longstanding member. For example, you may have wondered whether productivity in this context could include an on-line debug facility or whether it must be something as complex as the newest system test tool on the market. That train of thought is not even relevant, because having a precise definition firmly in mind is unimportant. What is essential is that as a whole your organization believes it is already implementing productivity improvement measures.
Now let’s turn to the actual items of the self-test. If you answered most of the first five questions “yes,” then you probably should delay introducing productivity improvement measures. This suggestion may not be what you anticipated. In fact, many people do attempt to interject productivity improvements at the outset of a new project or when a new organization is forming. Our experience indicates that this may be far from the optimal time. Remember the first few development projects on which you were a team member? It is unlikely that you were interested in the myriad of planning meetings that took place between the project manager and the users. Nor was it probable that you had much patience with the time and resource negotiations that slowly evolved into Gantt and Pert charts. You wanted to design, to code, and to build a system! In fact, during the last project for which you were responsible that involved leading edge technology, you may have experienced some similar (and almost forgotten) stirrings of impatience. You found yourself silently questioning the slowness with which your management, users, vendors, etc. were moving; you (jaded as you were) wanted to have an opportunity to play with the new toy.
A new organization is imbued with vitality; a team embarking on the development of a new system is usually bristling with enthusiasm. Therefore, in these types of environments, it is unlikely that you will be able to get anyone to stop what they are doing long enough to even spell the word productivity. Your suggestions will probably be received better if you approach people after they have missed a few critical deadlines and are beginning to feel discouraged. At that point most people are actively searching for relief, which you can supply.
On the other hand, if you answered “yes” to most of the last five questions on the self-test, the time is indeed right! Your group has been through the wars and are most definitely battle weary. The members are past the first flush of optimism and all-consuming interest in what they are doing from a technological perspective. They are unbearably familiar with their systems’ shortcomings and are definitely fed up with resolving production problems by phone at 3:00 A.M. In some cases, they may be searching for ways to improve how they implement new releases; these are the groups that are already utilizing productivity tools or techniques. These are the people who will be in an excellent position to appreciate the benefits of the productivity improvement you will recommend.
Look Within Yourself
Obviously, arriving at this determination is not an exact science and even the act of utilizing the ten questions may be somewhat less than straightforward. Therefore, a diagram (Figure 1–2) has been provided to help you summarize your answers as well as analyze their significance. You may also notice that there is a third possibility; namely, the case where you answered “yes” to most questions or “no” to most questions.
If this is your situation, then it will be somewhat more difficult to assess the prevailing climate of your organization. In this case you must look deep within yourself and trust your instincts. We can, however, offer some additional questions that might assist you with this self-assessment. Ask yourself: If your recommendations are accepted and the results are unfavorable, would this dramatically and adversely affect your position in the organization? Then you must also evaluate not only how much you really believe in the cause you have selected, but also exactly what you are willing to risk.
Figure 1–2 A Schematic for Analyzing the Ten Questions.
The key things to consider are the possible adverse effects on your career, your own level of commitment, and the extent of the potential improvement. You are the only one who can assess these factors. Do bear in mind, however, the seriousness of what you are about to undertake. It is not at all in the same category as typical advice to the boss, such as sending the new programmer to a course halfway across the country. You will be recommending something that if it is approved, will result in a considerable expenditure of funds; and more important, if it is successful, will have far-reaching effects on many people. You must fully understand and appreciate the tremendous implications of the fact that you are about to change irrevocably how people perform their jobs.
In order to succeed, you must begin with firm convictions, based on a realistic appraisal of the situation. Specifically, you must also assess yourself as part of the whole process, because as an agent of change, you will definitely be a critical success factor. How comfortable do you really feel with the new tool, technique, etc.? Do you truly believe it is really going to make a dramatic difference (in terms of quality and time) in how systems are developed in your organization? Is this a good time (in terms of career) for you to be taking such a risk? If you have the impression that your prospects of promotion in the near future are bleak, advocating this type of change may be perfect. Although your efforts may not result in any specific reward, at least you will not forfeit something positive that is imminent. However, you should never be unduly influenced by political considerations. If the tool or technique is fundamentally a good product that will substantially improve development and you fervently believe those two facts, then by all means you should recommend it. But never forget that you are a missionary on a crusade, and that one prerequisite for successful implementation of change is a zealot.
Select a Target Area for Improvement
You surely do not want to proceed with a major change effort if you can foresee only minimal improvement. There is absolutely no advantage to implementing change for its own sake. Therefore, before you proceed, you must be confident that the tools or techniques will substantially improve the situation at this time. The first step to determining this fact is to size up the entire development process in which your organization is involved. Select an area or phase (e.g., system definition) in which you can clearly see problems. The following list offers some common problems, and you should use it as a checklist. However, do not limit yourself to these items; add your own to the list so it will be more applicable to your organization.
1. Repeated inability to meet target dates for this phase
2. Low morale among group members during this phase
3. Redundant activities and/or documents produced
4. Constant false starts—the let’s go back to the drawing board syndrome (once is not an indication)
5. Inability to get started at all
6. Specific sets of activities or tasks repeatedly performed
7. Tasks performed inadvertently by more than one group member
8. Critical tasks not performed
9. In general, a lack of communication and control
Utilizing the problems you have identified, you will then select the phase or area targeted for improvement. Following that activity, spend a modest amount of time in reflection. Try to imagine the ideal situation—activities being performed in an atmosphere of cooperation, energetically but without hysteria, by competent team members who meet all deadlines with all deliverables. Now that you have the two pictures (current and ideal) firmly in mind, compare them as honestly as possible. It should be clear to you that the current and ideal scenarios are qualitatively and thus substantially different. If not, then it is not clear that the gain will be worth the effort.
Quantify the Projected Benefits
This “imaging” is a bit like a trip to the ether zone, so we will offer a more concrete method that we have used in determining whether to proceed or delay. This approach involves quantifying the projected benefits as a step in the assessment process. This does not have to be a formal business case, but just a simple analysis of the situation that you will be improving in terms of dollars and cents. Bear in mind that there are many ways to perform cost/benefit analysis, some of which are quite complicated; and the method we will describe is an unsophisticated one.
Utilizing the two scenarios you have just mentally developed, apply the following technique. Take the target phase as it exists in both the current and idealized versions, and attach dollar figures to both scenarios. This is accomplished by compiling a list of necessary activities and determining the number of people and average amount of time required to complete these activities. Then you can calculate the cost by multiplying these figures by loaded salaries (usually you can obtain these figures from personnel). For example:
For a system test, your project usually takes two months and assigns six people.
Three of these people are senior members of your programming staff (MPS) with a loaded salary of $60,000 per year; the other three are junior members of your programming staff with a loaded salary of $40,000 per year.
Therefore, if your system test lasted for a year, you would spend:
Junior MPS |
Total |
|||
3 × $60,000 |
+ |
3 × $40,000 |
= |
$300,000 |
Since your system test period usually takes two months, you usually spend:
1/6 of $300,000 = $50,000 per release
If you have two releases per year on the average
2 × $50,000 = $100,000 per year on system test.
In the ideal situation, you predict that the three junior MPS, armed with a productivity measure, could do the job in the same amount of time. Therefore, if your system test lasted for a year, it would cost:
3 × $40,000 = $120,000 per year
or
1/6 of $120,000 = $20,000 per release
Again, if you usually have two releases per year:
2 × $20,000 = $40,000 per year on system test
Thus, your projected savings would be:
$100,000 – $40,000 = $60,000 per year
You should also consider other expenses such as the computer costs (purchase, lease, or timeshare) for the duration of the system test. If this is a substantial expense for your group, this calculation will improve your projected savings. Moreover, if you already have a particular tool or methodology in mind, you must include the cost of the tool itself. If it is very expensive (some tools may cost $500,000 or more), and your projections indicate approximate savings of $25,000 per year, it would take years to recoup the initial expenditure. In this case you would probably not want to proceed with your recommendation. However, although you need to be careful, you should not be too cautious. If the tool would be used many times a year by several groups, then a very large initial expenditure may still be worthwhile.
After you have followed the steps outlined in the preceding paragraphs, you must analyze the results very carefully (Figure 1–3 offers a pictorial summary). Even though these estimates are usually never seen by anyone other than you, it is important to be very conservative. In general, you will be pleasantly surprised; there is no advantage in setting yourself up for a disappointment. Keep in mind that the main reason you are projecting these figures is to enable you to address whether or not the improvement would be substantial. All this quantification will bring some objectivity to an otherwise extremely subjective issue. Your management will feel much more comfortable if you feel confident in your advocacy of the new tool or technique.
Figure 1–3 A Pictorial Summary of the Quantification Process.
However, if your analysis leads to the conclusion that you should stop based on the economics, so be it. But don’t despair—situations change, people change, and the time will be right eventually, probably after a few more releases of the system or after the new organization matures. In any case, you should save your figures, because you may want to recalculate the quantifications as the environment evolves. At any time (now or in the future), if your estimates indicate a promising area for productivity improvement, you will proceed and you can use these figures as a basis for your business case.
When to Show Your Hand
By now you have assessed your organization as well as yourself, and you have determined that the time is right. You are also confident that the benefits will be substantial, and you are indeed committed. But there is still one question to ask yourself before this phase is complete: You must consider not only the advisability of sharing your plans at this time, but also the extent to which they should be shared and with whom. It may not be obvious, but you actually will have quite a bit of latitude in terms of when your crusade becomes public knowledge. Although this may seem trivial, there are a number of reasons that this flexibility cannot be disregarded.
Once, in the early days of distributed processing, we conceived of an application that would support all our system documentation from definition to user guides. We envisioned that our “paperless environment” would operate on a two-tier architecture and developed a comprehensive prototype. The need existed, the time was right, and we were crusaders; however, we made the fatal error of communicating our mission to the free world. Our technical support group claimed ownership, since the technology was leading edge; the project group across the hall unequivocally stated that the functionality was redundant due to the scope of their effort; the corporate groups informed us that what we produced was not SOE (standard operating environment). In fact, our own management questioned our priorities; if we had so much free time, why didn’t we shorten the release schedule?
The lesson we painfully learned was that a change effort should be as securely launched as possible, before there is too much attention drawn to it. To be sure, the time will come (and quite soon) when publicity will be the objective; raising the awareness of your users will be the goal of an entire phase (see Chapter 5). Also at some point you will require resources and funding for implementation just as you would for any project, and therefore you will have to seek and obtain the commitment of your management (see Chapter 4). Moreover, we are not suggesting massive paranoia; in your environment, an open policy on day 1 may be just right for your effort.
Another option you might consider is sharing your plans with a trusted individual, such as an employee, a peer or your boss. Obviously an employee or peer can be a great asset in terms of making progress while the change effort is still a part-time operation. Your boss can be invaluable in many ways. For example, he can begin subtly laying the groundwork for selling the productivity improvement to upper management. He will also be able to assist you by arranging time for you to keep the change process moving forward during these early days.
It is a fact that during these early phases of implementing change, the process can be compared to a small and fragile child. You must both protect and nurture your effort until its future is secure. Indeed, during the later stage of the life cycle (as we will discuss in Chapter 12), you will experience difficulties in the opposite direction, such as a need to control the process and prevent it from moving forward too quickly. However, in the beginning the main ingredients for progress and success will be your assessment and judgment of the situation, a nurturing and protective attitude, and most important your own commitment and even fervor.
Summary
• Since data processing as a profession (as well as the individuals who practice it) has matured, we have begun to invest time and effort in improving productivity.
• Although the introduction of new technology is difficult, just as surely as there is a software development life cycle, so there exists a life cycle for implementing change.
• As an agent of change, the first activity in which you must engage is assessing your organization to ensure that the time is right to introduce a productivity improvement.
• Since you will be a critical success factor, it is imperative that you are committed and that you fully appreciate the tremendous significance of what is being undertaken.
• To be absolutely certain that the change you are implementing will substantially improve the lives of potential users, you must quantify the projected benefits.