QSM/Vol4

Practicing to Becoming a Change Artist

  1. Goint to Work: 일하러 갈 때 평소와 다른 길로 가보기. 변화에 수반하는 혼돈 등의 감정을 스스로 느껴보기.
  2. Making One Small Change: 스스로 단 하나의 요소만 바꿔보기. 하나만 바꾼다는 것은 힘들다는 것 느껴보기.
  3. Changing Nothing: 아무 것도 하지 않고, 왜 변화의 필요를 느끼는지 발견해보기.
  4. Changing a Relationship: 누군가와의 관계를 변화시켜보기. 일치성과 충돌에 대해 배운 것을 직접 경험해보기.
  5. Being the Catalyst: 다른 사람의 변화 프로젝트를 facilitate해보기.
  6. Being Fully Present: 적극적 경청해보기.
  7. Being Fully Absent: 문제를 떠나있어보기. 일주일 동안 휴가를 가보고, 돌아왔을 때 어떤 것이 변해있는지 관찰해보기.
  8. Applying the Principle of Addition: 반복하면 강화된다. 어떤 사람에게 어떤 affirmation을 정해서, 매일 매일 줘보기.
  9. Organizing the Grand Tour: 다른 change artist를 사무실에 초대해서, 사무실의 사람들이 그 사람에게 '다른 팀에서 탐낼만한, 우리가 잘 하고 있는 것'을 설명하도록 하기.
  10. Learning from History: 당신이 비생산적이라고 생각하는 그 실천법의 역사를 발견해보기.
  11. Putting Theory into Practice: QSM의 아무 쳅터나 리뷰를 해보고, 구체적으로 실천해보기.
  12. Developing Yourself:

QSM: Volume 4.1: Becoming a Change Artist

Part I. Modeling How Change Really Happens

Chapter 1. Some Familiar Change Models

Summary

  1. Attempts to change software organizations commonly fail because of inadequate models of change dynamics.
  2. The Diffusion Model is the simplest of all the change models and is based on the belief that change just happens by diffusing into the organization like dye diffuses into solution.
  3. A slightly more sophisticated view of the Diffusion Model recognizes that the diffusion of a change does have structure. If we control the variables in this structure, we can manage diffusion to a limited extent.
  4. The strength of the Diffusion Model is its attention to change as a process. The weakness is the abdication of control over that process to forces of nature.
  5. The Hole-in-the-Floor, or Engineering, Model attempts to correct the weakness of the Diffusion Model by adding control of the change process. This control involves three steps:
    1. Working upstairs, the engineers develop the perfect system.
    2. The change plan consists of drilling a hole in the floor.
    3. The system is dropped through the hole and the workers use it happily ever after—instant diffusion.
  6. The Hole-in-the-Floor Model is based on a number of false assumptions about the nature of people, but often fits the data on change if viewed from a sufficiently high level. Those few times when we must change the side of the road, we need to try to make change approximate the Hole-in-the-Floor Model as closely as possible.
  7. The strength of the Hole-in-the-Floor Model is the emphasis on planning. What's weak in the model is that the planning leaves out so many essential factors, most notably the human factor.
  8. The Newtonian Model (or Motivational Model) introduces the concept of external motivation to change, and says
    • The bigger the system you want to change, the harder you must push.
    • The faster the change you want, the harder you must push.
    • To change in a certain direction, you must push in that direction.
  9. The Newtonian Model does recognize that people have a choice in what they do, and that their choice can be influenced by pushing them as part of the change process. It fails to recognize that people are not nearly as simple as the Newtonian Model implies, so that pushing often produces a boomerang effect.
  10. One useful refinement of the simple Newtonian Model is what social psychologists call force field analysis, a method that is based on listing all forces for change on one side of a diagram and against change on the other, then looking for ways of shifting the balance.
  11. The strength of the Newtonian Model is the explicit introduction of the human element in the form of motivation. Its weakness is the totally inadequate model of humanity that's used: that people can be pushed around like billiard balls.
  12. The Learning Curve Model recognizes that people aren't billiard balls, and that people are usually unable to respond to change attempts like a billiard ball with instant efficiency. Moreover, it takes time to learn to respond as well as the planners would hope.
  13. The Learning Curve Model suggests the possibility of influencing the course of the change by personnel selection and training and is quite useful for large- scale planning. However, it fails as as a practical tool for managing cultural change person-by-person in a real organization.
  14. The strength of the Learning Curve Model is its incorporation of the adaptive human element in change. The weakness is the averaging out of details of individual human beings.

Chapter 2. The Satir Change Model

Summary

  1. To manage change effectively, you must understand emotional reactions. Virginia Satir's model of how change takes place applies to individuals as well as to systems of individuals, and definitely incorporates the emotional factor.
  2. The Satir Change Model says that change takes place in four major stages, called:
    1. Late Status Quo, or Old Status Quo
    2. Chaos
    3. Integration and Practice
    4. New Status Quo
    5. The model also describes a higher level of change, or meta-change, which involves changing the way we change.
  3. The Late Status Quo is the logical outcome of a series of attempts to get all the outputs of the system under control. Everything is familiar and in balance, but various parts of the system have an unequal role in maintaining that balance.
  4. The Late Status Quo stage is a state of ill health that always precedes the so-called crisis. The Satir Change Model recognizes that the crisis is not a sudden event, but merely the sudden realization that things have been unhealthy for a long time—not a crisis, but the end of an illusion.
  5. In the Late Status Quo, people may be experiencing anxiety, generalized nervousness, and gastrointestinal problems. Constipation is a perfect metaphor for the over-control that characterizes the Late Status Quo, where there is no sense of creativity, of innovation. The most important sign that the system is in Late Status Quo is denial: the inability or unwillingness to recognize all the other symptoms, or to attach enough significance to them to do anything.
  6. Systems stay in Late Status Quo until something happens that the people in the systems can no longer deny—a condition Satir calls the foreign element. The system usually tries—and often succeeds—to expel the foreign element and return to the Late Status Quo because familiarity is always more powerful than comfort.
  7. When a foreign element arrives, people become protective and defensive. Still, the foreign element may be the only thing that arouses any kind of new activity, but most of that is simply trying to expel the foreign element.
  8. Eventually, some foreign element cannot be denied or deferred or deflected, and the system goes into Chaos, where old predictions no longer work. The Old Status Quo system has been disrupted.
  9. People try random behavior and desperately seek sweeping, magical solutions, to restore the Old Status Quo. It may not be easy for people in Chaos to acknowledge it's happening to them. They feel crazy, afraid, and vulnerable; and they become extremely defensive and alienated.
  10. When in Chaos, people encounter people they've never seen before, and functions they never knew existed. Some startling new ideas may emerge, but if they work at all, they only work for a short time.
  11. Eventually, one of these new ideas seems a real possibility. This is the transforming idea—the "AHA!" that starts the Integration and Practice phase. Chaotic feelings disappear, and at moments of apparent clarity, everything looks like it will be solved. However, the moments of clarity are often replaced by old feelings of doubt, as feelings swing back and forth.
  12. During Integration and Practice, people feel good, but feel unable to control the good feeling. They are easily disappointed when things don't work out perfectly the first time, and need much support, though they may not seek it explicitly.
  13. A major component of the good feeling is the "Aha" rush that often comes with the transforming idea. The memory of this rush is so strong, though, that the practice needed to integrate the transforming idea is often forgotten.
  14. Successful practice eventually leads to a New Status Quo stage. Unfamiliar things become familiar, and a new set of expectations and predictions evolves. People are calm, balanced, and have a sense of accomplishment. But, unless they take charge of the change process, the newness of the New Status Quo wears off, and we drift into another Old Status Quo Stage.

Chapter 3. Responses to Change

Summary

  1. According to the Satir Change Model, the change process contains many choice points—points at which the individual or organization can respond in one of several ways:
    • The foreign element can be rejected, or not rejected.
    • The foreign element can be accommodated into the old model of reality.
    • The old model can be transformed to receive the foreign element.
    • The transformation can be integrated or not integrated into the model.
    • The transformed model can be mastered or not mastered through practice.
    • In addition, there is the choice of how much time should pass before the explicit introduction of a new foreign element.
  2. When management announces a change, many employees will perceive the announcement as a foreign element and attempt to reject it. The first step in dealing with these rejections is to realize that opposition to a foreign element is perfectly natural, and not a personal attack. Then listen to the sense of each argument and, more importantly, to the emotional "music" behind it. Responding to the emotions will generally be more successful than trying to counter the arguments.
  3. Other people may resort to accommodating the foreign element into their old model, and truly believe they are doing the change. A good strategy here is to be tactful yet explicit in what truly needs to be done to accomplish the change.
  4. A good strategy when introducing change is to emphasize how the changed state resembles what is already being done. Instead, some people introducing change emphasize how everything is entirely new and different. To be successful at change, you need to show people that they really have a vast amount of knowledge so that the change is only a small, logical increment to their knowledge base.
  5. The introduction of a change often fails at the point where the new way must be integrated into practice. In training, real examples give the most effective practice, especially if the environment makes it safe to make mistakes and to go at whatever speed is needed to integrate the new material. And practice doesn't end when classes end; the introduction of new ideas to the actual job needs lots of safety and support from experienced people.
  6. Once the change has been integrated into a few working examples, a return to Chaos becomes far less likely—but still possible if conditions are bad enough. Lots of petty adjustments are required to make any real change work in practice, and lots of time must be allowed for scaling-up from small examples.

  7. Perhaps the most common cause of failing to change is the question of timing—the interference from other changes. Changes do not come in isolation, and McLyman's Zone Theory is an excellent guide to timing the introduction of new foreign elements, based on zones.

  8. The Red Zone is the interval of time before a previous foreign element is transformed, accommodated, or rejected. When a new foreign element arrives while the system is in the Red Zone, Chaos from both foreign elements increases. Moreover, the chance of ever finding a transformation for either foreign element decreases, and the likelihood of rejection or accommodation increases.
  9. The Yellow Zone is the time during which a previous transformation is still being integrated. When a new foreign element arrives while the system is in the Yellow Zone, chances of successful change are reduced, but not as seriously as with Red Zone foreign elements. With successive Yellow Zone foreign elements, however, the system builds an energy debt. Successful change becomes progressively less likely, and productivity drags.
  10. The Green Zone is the time between late Integration and early New Status Quo. When a foreign element arrives in the Green Zone, the system's chances of successful change are maximized. Not only is there no energy debt, but each successful Green Zone change increases the chances for the next.
  11. The Gray Zone is all the time after system has been in Late Status Quo for a while. When a foreign element arrives in the Gray Zone, people have lost some of their meta-change skills, for old learnings about change have lost their usefulness. Without these meta-change skills, change is once again slow and difficult, and the chance of successful change is lowered.
  12. Managers who are in a hurry and press the organization with too many changes too quickly will merely slow down the very changes they are trying to accelerate. Similarly, if managers adopt the strategy of "hit them with a lot of changes, and some will stick," they'll find that in the end, none of them will stick.
  13. Not all parts of the system are in the same zone at the same time. This is true at every level of the organization, right down to the individual. Although change must be managed at a high level, we must never ignore the impact on individuals.
  14. Change tends to disrupt information flow needed to manage change. The most reliable information is the emotional signals from the people experiencing the change. Use these signals to determine the appropriate zone strategy, or what kind of information you need to supply.
  15. During an aging Status Quo, old feedback mechanisms are eroding slowly. Information is not getting through. Behavior is less predictable, and to make it more predictable, people often ignore what information does get through. Interventions here should be in the direction of getting people to recognize what is, rather than what it is supposed to be.
  16. For major changes, the system may go through the change model many times. Not only do systems and individuals learn during the change cycle, but after several complete change cycles, they "learn to learn"—and they also learn about the importance of learning in a change process. Experienced change artists feel such high self-worth and unlimited coping ability that they are able to deal in a truly helpful way with those to whom the prospect of change is a threat.

Part II. Change Artistry in the Anticipating Organization

Chapter 4. Change Artistry

Summary

  1. Whenever we look into organizations that have accomplished cultural changes, we find a large number of people who we call change artists. Moreover, we find these change artists at all levels of an organization, and in all units, because for cultural change to occur, it must occur at all levels and all units. When these change artists are present, they deal with the individual emotional responses to change, and thus increase the chances for success of any change plan.
  2. In the Anticipating organization, to some degree everybody has become a change artist, Thus, the devotion to developing change artistry is one of the distinguishing marks of this cultural pattern, and the primary tool for change is neither things nor procedures, but people.
  3. Change artistry consists of knowing how to facilitate change, knowing what to change, when to change it, where in the organization the change should be introduced, and who should take what roles in carrying it out. Even more, it consists of the ability to take congruent action when under great stress, and surrounded by people under stress.
  4. There is no single way to be a change artist, and different ones are needed for different jobs. The important thing is to have a change artist in the right place at the right time to facilitate each little piece of the grand plan.
  5. Each stage of change is different, and each stage requires different types of intervention. Fully matured change artists are able to operate well in all phases: Old Status Quo, Chaos, Integration and Practice, and New Status Quo. Some change artists, however, are primarily effective at only one stage, simply because it happens to match their skills and personalities.
  6. The NT Visionary likes working with ideas and is most interested in designing, rather than implementing, change. The NF Catalyst enjoys working with people to help them grow, and is best at keeping people working together through the rough spots of the change process. The SJ Organizer, who likes order and system, is best at carrying the transformation into actual practice, long after the visionaries have gotten bored. The SP Troubleshooter likes getting the job done and is least likely to deny the foreign element, because it offers an opportunity to swing into action.
  7. The temperaments are merely tendencies: what we may do instinctively when we act without thinking. More fully developed change artists recognize their tendencies, honor them for their strengths, note their weaknesses, and set them aside if they are inappropriate for the current situation.
  8. Without careful management, long-term change is invariably sacrificed to short-term expedience. Such expedience takes place all the time, everywhere in the organization, essentially out of the view of the high-level management. That's why change artists have to be in every nook and cranny of an organization.
  9. The act of patching violates standard process, and so encourages further process violations over time. Though the patch maintains stability in one area, it is a foreign element in several others. Change artists in Anticipating organizations evolve a process to resolve this conflict, such as a QUEST team consisting of a hacker responsible for solving the immediate problem, a guardian responsible for seeing that no harm comes to the product, and a healer responsible for amending the process to prevent further occurrences, or to be prepared to handle them better.
  10. Perhaps the toughest skill for a change artist to learn is the skill of knowing what people and what situations to leave alone. Change artists need to learn how to recognize whether a person or department is willing to help themselves rise, and to connect what the individuals want with what the organization or the change artist wants.
  11. Among the important principles of change artistry are
    • Always find the energy for change and go with it.
    • Don't get hooked into negative energy.
    • Talk in their terms and find out what the issues really are.
    • Once you're prepared, go to the source.
    • It's perfectly all right to do nothing for a time.

Chapter 5. Keeping Most Things the Same

Summary

  1. A change artist's first and foremost responsibility is to use that longer-term, wider-scope knowledge to keep most things the same even in the face of innumerable failures. Until you know how to maintain an organization, you will not know how to change one.
  2. All organizations, regardless of their culture, need mechanisms to maintain themselves. You can discover what is being maintained by examining the mechanisms that maintain them. Cannon's principle shows you how to investigate just what these elaborate mechanisms are maintaining—which may not be what the organizations say they are maintaining.
  3. Some Variable cultures are devoted to survival of a system of management power, perquisites, and prestige. Such a culture is not a good candidate for a well-planned, well-managed change project.
  4. Observing how an organization measures is a good way to apply Cannon's principle. For example, the use of lagging indicators is a good way to recognize failure-oriented organizations, ones that assume they will fail. Instead of working to prevent failure, they are working to maintain the failure level low enough so they won't attract attention. They're also working to establish evidence they can use to point blame at someone else.
  5. Another way to understand what a culture values, and what it is trying to maintain, is to examine what it measures. Two of the most common cultures are characterized by the measurement of consumption and the measurement of production. Accounting managers typically measure by consumption. Technology managers typically measure by production.
  6. Neither the accounting mentality nor the technology mentality are adequate to the job of software engineering in an Anticipating culture—first, because neither consumption or production alone is a sufficient measure and, second, because both together are inadequate to explain the organization's ability to survive in the future.
  7. These systems of maintaining cultures of failure and/or management power are examples of what Argyris calls espoused theory versus theory-in-use. To achieve an Anticipating (Pattern 4) culture, you need to lay bare these hidden purposes.
  8. It's not sufficient to set up a process and then expect it to go on forever. Without constant tending, any process will deteriorate, and deterioration of the process invariably leads to deterioration of the product.
  9. Design deterioration is the result of a set of design decisions that didn't age well. Each such short-sighted design decision adds a little to the design debt carried by the existing software inventory. Although no single design deterioration seems sufficiently large or exciting to fuss about, after a couple of decades of such decisions—and little effort to correct them—many an IS organization finds itself in Late Status Quo.
  10. Maintenance deterioration comes from patching programs in a way that does not entirely preserve their designs. A first-class design endures years of hastily considered patches and finally turns to trash.
  11. Design maintenance debt is the sum of design debt and maintenance debt. Design maintenance debt—not the "size" of the modification in function points or lines of code—is the major determining factor in the cost of making a modification to an existing system. This debt is often a major cost and complication factor in changing a software engineering culture.
  12. In many software engineering organizations, change artistry debt stands squarely in the way of eradicating the hidden debts in mountains of code. Some organizations have actively attacked their change artistry with covert communications, promotion by buddy system, rumors used to tarnish reputations, punishment of risk-takers, and acceptance of special favors from vendors.
  13. The MOI Model says that in order to change, we need motivation, organization, and information. For change, motivation may come from many sources, but any motivation to change is killed by a fear of taking risks. Organization consists of a variety of forms, such as good strategic planning, a reliable infrastructure (such as e-mail, meeting facilities, and phone system), sensible budgets, and a consistent culture.
  14. Information for change is needed at two levels. The first kind—the various change artist skills—are of little use without the second—reliable data on the organization's current product and process.
  15. The various components of change artistry are intertwined with management behavior, so that certain behaviors over time create an enormous deficit in an organization's change skills. To overcome this debt, an organization needs management attention. Managers need simple rules to govern their behavior if they are to conserve what's good in the present organization while promoting change to an Anticipating organization.
  16. Some of the more effective management rules for conserving what's good during change are these:
    • Don't blame. Give and receive information.
    • Don't placate. Take no job that you don't believe in.
    • Cut out the superreasonable slogans and exhortations.
    • No tricks. Means are ends.
    • Trust, and merit trust.
    • Never stop training yourself in change skills.
    • Never stop seeking improvements right around you.
    • Remember that you were born little, just like everybody else. Just because you have a title, you haven't ceased to be a human being.
    • Be an example of what you want others to be.

Chapter 6. Practicing to Become a Change Artist

이 장의 목표는 변화 아티스트가 구체적으로 무엇을 하며, 그렇게 되기 위해 어떻게 훈련받는지에 대한 아이디어를 주는 것이다. 만약 이런 도전과제들을 당신이 직접 한다면 누가 말리겠는가?

6.1 일하러 가기

당신의 첫번째 도전과제는 당신이 담당하고 있는 프로젝트의 아주 조그만 특성을 바꾸는 것이다. 이 과제의 목적은 SatirChangeModel을 경험하게 하고 그 과정에서 나오는 감정을 경험하는 것이다.

The Challenge

당신의 도전 과제는, 내일 일하러 갈 때 (평소와) 다른 길로 가는 것이다.

Experiences

이 과제의 첫 경험은 이 과제를 처음 읽었을 때 당신의 머리와 마음에 스쳐 지나간 그것이다. 내가 함께 작업했던 사람들의 몇몇 전형적인 반응은 이렇다:

이번에는 이 과제를 완료한 사람들이 나에게 했던 코멘트 몇 개를 살펴보자:

박정수의 경험

무엇을 실천해볼까 하다가, 병원에 들렀다 나오는 길에 지하철 역까지 걸어서 갔다. 그 때문에 평소와는 다른 입구로 들어가게 되었고, '아, 여기에 이런 곳도 있었구나' 하면서 신기하다는 생각을 했다. 평소에 지하철 머리 부분에서 타야 최단거리라는걸 알고 있었기 때문에 '오늘은 OO 입구로 들어왔으니까 이쪽에 서야 맞겠군' 하고 계산을 하고 지하철을 탔다. 지하철을 내리고 표를 끊는데, 평소에 보던 역삼역의 모습과 너무 달라서 당황했다. '잘못 내렸나?'라는 걱정스런 마음이 덜컥 들었다. '에이, 설마. 방송 잘 듣고 내렸는데. 지하철 꼬리쪽으로 타서 그런가보다'라고 생각이 들었지만, 빨리 직접 가서 익숙한 출구의 모습을 눈으로 확인하고 싶었다. 긴 복도를 지나서 눈에 익은 출구 모습을 보자 그제서야 안심이 되었다. 그러면서, 변화에 직면하는 사람들이 이런 마음일까 하는 생각이 들면서 변화시키려는 마음의 조급함을 완화시킬 수 있었다.

초기의 작은 변화가 연쇄반응을 일으켜서 큰 변화가 될 수 있다: '이것도 하면 안돼?'라고 제안할 수 있지만, 받는 입장에서는 그것 하나가 달라지면 그 다음에 뭐가 나올지 모르고, 그 다음은 더 모르고, 완전히 길을 잃을까봐 두려워할 수 있을 것 같다.

6.2 Making One Small Change

Your next challenge is to undertake a change project of your own, but this time to seek support in making this change. The purpose is to launch your career as a change artist by experiencing in the "real world" some of the theoretical learnings, but in as small and safe a way as possible.

The Challenge

Choose one small thing about yourself you want to change. Novice change artists tend to be too eager for their own good. If you want to eat a whole elephant, start with a single bite. If you finish one change, you are free to do another, and another -- so don't worry that it's too small.

Find an interested change artist (or associate, or some willing person), meet with him or her, and explain the change you want to make. Contact with that person for the kind of support you think you need to accomplish your change. Check with your supporter periodically to update him or her on your progress.

Experiences

Since readers of a book can't easily exchange observations about experiences, let's examine a fre instructive experiences of other change artists accepting this challenge to make on small change.

QSM: Volume 4.2: CHANGE: Planned & Unplanned

Part I. Planning for the Future Organization

Chapter 1. Meta-Planning: Part I. Information

Summary

  1. Change artists practice their skills on three levels, involving three different times scales and three different sets of skills. Change artistry "in-the-small" deals with people and problems face-to-face and day-to-day—this level is what we call tactics.
  2. Tactics are not all reactions to unexpected events. Change artistry "in-the-middle" is what we call tactical planning: looking ahead to be ready to handle such events.
  3. Change artistry "in-the-large" is what we call strategic planning: setting the climate in which tactical planning takes place. The strategic plan addresses two broad questions for a time interval that is typically three to five years in length:
    • What products/services will we supply?
    • What processes/resources/culture will we need in order to supply them?
  4. The strategic planning process has to be able to estimate the feasibility of some of the visions by asking: Can we build these products with the processes/resources/culture we now have? If the answer is yes, then the process vision is one of maintaining and perfecting the present process. If the answer is no, then the planners must decide whether to reduce their ambitions or to raise their process vision.
  5. When done well, the entire process of strategic planning for change can be regarded as having three major components:
    • information gathering, including observing and ignoring
    • problem solving, including systems thinking, negotiating, and translating into action-generating principles
    • mechanics, including knowing when, where, and how the planning is done, as well as who is involved, and understanding the difference between tactics and strategy
  6. The information for making strategic decisions needs to come from both inside and outside the organization. Three types of problems plague the quality of the information used in strategic planning:
    • omission of some essential source
    • dependence upon an unreliable source
    • wallowing in excessive detail, while ignoring relevant details
  7. The information for sensible change planning is simply not available until all three types of problems are cleared up. Until they are, you need to restrict the output of the plan to meta-plans: plans that need to be carried out concerning the planning process before you can do effective planning on the rest of the organization. Most of these meta-plans will concern the quality and quantity of information.
  8. There are a number of typical problems of missing information:
    • failing to consider customers' wishes in the planning process
    • failing to consider potential customers
    • inability to demonstrate any relationship between the software engineering strategy and the firm's overall business strategy.
    • failing to use information of any kind from within the organization
    • failing to use outside sources of information
    • lack of knowledge of organizational development possibilities
    • sham planning that costs a lot and disrupts the organization
  9. There are a number of typical problems of using information from unreliable sources:
    • using internal reports that are irrelevant or are not reliable indicators of what's happening in the organization
    • measuring processes so unstable that measurements have no meaning, except to show the instability
    • creating strategies based on opinion, not data
  10. Even when the available information is reliable, planning sessions fall into trouble by working at the wrong level of detail:
    • spending too much time on irrelevant details
    • using data from different sources that are not of comparable detail
    • working everything to death, while treating important issues superficially
    • being swept along by the latest software engineering fad, ignoring the root problems at home

Chapter 2. Meta-Planning: Part II. Systems Thinking

Summary

  1. Problem solving presents a variety of difficulties at the level of action planning. For example,
    • Planning sessions degenerate into arguments over whose problem solving approach to use.
    • Planning sessions may move smoothly through data sharing and setting priorities, but bog down when it comes time to decide on actions.
  2. The planning group needs to agree on an approach, which need not be complex, but must be common to all the planners. One simple four-step approach is as follows:
    1. Define a problem in terms of a difference between what is perceived and what is desired, and when.
    2. Develop a diagram of effects relating the perceived/desired variables to other variables.
    3. Examine the diagram of effects to discover the dynamic holding the perceived situation in place. If you can't discover that dynamic, then find out what is preventing you from discovering it.
    4. If you understand the dynamic, identify choice points where you can break the stability control of the perceived values. These define your strategic actions. If you don't understand the dynamic, identify actions that will obtain the information to allow you to discover the dynamic.
  3. Development seems always correlated in nature with growth. This is in contrast to organizational changes (or change attempts) which are supposed to take place just by writing them down in a strategic plan. Here are some characteristic planning problems in a developing organization:
    • As quality improves, the business improves, then grows. But growth produces bigness, which then destroys its quality.
    • Complexity restricts development. As explicit mechanisms to control quality are added, the organization seems to be harder to organize further.
    • Size restricts freedom. People feel that because of overplanning, they are losing their opportunity to be creative.
    • Planning projections don't seem to work as well as they used to because tools don't scale up as the system size grows, and growth is always nonlinear.
    • Big isn't the same as small. As the organization grows, its relationship with the outside is strained as it tries to maintain its internal viability.
  4. Strategic planners need to think in terms of risk and reward trade-offs. One of the most common trade-off decisions in strategic planning is between added value and probability of success. By taking a chance on a new technology, you may get a great increase in value or a great decrease in costs. But new technologies are risky and, if you fail, your payoff may be nothing at all.
  5. Different organizations make different choices of trade-offs, and those choices influence their culture:
    • A start-up software company has much to lose if its leaders don't do something spectacular, and fast. They may need to take a high risk in order to get a high enough reward to stay in existence.
    • The high-level managers of a large established software provider have much to lose if they make high risk plans. They don't stick their necks out, but once the big risk is gone, they're ready to move in a swift, sure-footed way.
    • Each culture encourages some risks and discourages others. In a risk-averse culture, following the dictates of the strategic plan may seem a greater risk to people than violating them.
    • The analysis of risks gives managers a chance to steer more effectively, but such improvement is possible only in a culture where risks can be discussed freely and openly. In some organizations, however, risk is not considered a proper subject of discussion.
  6. Incongruent coping behaviors must be dealt with before anyone makes any further attempts to plan. The strategic team should refrain from making any decision based on risk factors that cannot be discussed. The team should create a strategic action item calling for creating a culture in which risk can be discussed freely and openly—that is, a culture where Satir's Five Freedoms are practiced:
    • The freedom to see and hear what is here, instead of what should be, was, or will be.
    • The freedom to say what one feels and thinks instead of what one should.
    • The freedom to feel what one feels, instead of what one ought.
    • The freedom to ask for what one wants, instead of always waiting for permission.
    • The freedom to take risks in one's own behalf, instead of choosing to be only "secure" and not rocking the boat.
  7. Unstable systems are harder to think about—that is, to plan for. Upper management has the responsibility for assuring that there are stable systems at all levels.
  8. To achieve stability that you can manage intellectually, you need to build an organization in trustable units. Each unit has a job, and each unit can be managed through input and output only, as a black box. This approach greatly reduces the need for communication among units, as well as between bottom and top. It also reduces the complexity of planning.
  9. Lack of trust produces a number of characteristic problems for planners:
    • Lower-level people don't trust management, and will adopt a "you go first" attitude toward implement actions of the strategic plan.
    • Management keeps swooping down to correct actions at lower levels, which demotivates people from attempting anything.
  10. Sometimes, even in what seems to be a hospitable climate for change, great ideas just don't seem to get off the ground. There are four possibilities:
    • The new approach seems sure to work, but can't seem to achieve a critical mass of participants.
    • When introducing a new process or technology, we often get a chicken-egg syndrome. Nobody will use it until it's tested by someone else.
    • Letting others try ideas for you has its limits. Prescriptions for one culture sound meaningless or backward for another cultural pattern.
    • Excessive planning energy is devoted to overcoming the objections of a few people with loud, strident voices.

Chapter 3. Tactical Change Planning

Summary

  1. The change artistry of the organization allows the strategic plan to be translated into tactical plans, and then facilitates putting those plans into action. Tactical change planning is an essential part of change artist training.
  2. Three major difficulties contribute to otherwise good plans falling into the trash:
    • The planners create tactical plans instead of strategic plans, giving too much how and not enough what or why.
    • The planners create strategic plans that couldn't possibly be translated into action, or are so ambiguous that they could justify almost any action.
    • Software organizations often have difficulty with strategic and tactical planning when the project is not primarily software. Change project planning is not a software project.
  3. Planned change is taking a system from point A (a perceived state) to point B (a desired state). Points A and B are supplied by a strategic plan, explicit or implicit. Such a change can be accomplished by working on
    • the perceptions of A
    • the desires for B
    • the realities of A or B
  4. Tactical planning is considering possible actions and their outcomes in advance, and arranging them in a way that maximizes your chance of success, using intervention models. The assumption that perceptions and desires remain fixed throughout the entire process is not very useful when planning organizational change, because most organizational change projects involve interventions on all three levels: perceptions, desires, realities.
  5. To be successful in organizational change planning, you need to use a planning method that is "open-ended rather than goal-oriented, and has to make itself up expediently and empirically as it goes along."
  6. Open-ended change planning is described by the following steps:
    1. Use the most current information about goals and capabilities to create a plausible plan to an appropriate level of detail.
    2. Start to execute the plan, gathering information on
      • where you actually go, as opposed to where you planned to go
      • how the organization actually acts, as opposed to how you thought it would act
      • the emotional reactions of people affected by the plan, including yourself
    3. In the light of the information from (2), check whether you want to stop. If not, set new goals and repeat (1).
  7. According to Satir's description of meta-change, change becomes easier over time when the people involved remain congruent, maintaining a balance among the Self, Other, and Context. Thus, during each planning cycle you must monitor all three from start to finish.
  8. Just because planning is open-ended doesn't mean it won't involve goals. Indeed, open-ended planners need to know more about goals, since they will have to test and revise goals on every planning cycle.
  9. Risk assessment is the first step in managing risks. Stability is, in effect, the inverse of risk, because a stable plan is one that can cope with risk. Planners must create a list of risks (threats to stability), discover how risks are interrelated, and uncover hidden risks.
  10. Risk assessment is not risk management, but only the first step. The second step is risk abatement planning, planning to get a predictable result in spite of an unpredictable environment. The PLASTIC Model, the MOI Model, and models of human emotionality can be used to plan steps that will place risks under project control, to the extent possible.
  11. Open-ended planning requires that the plan will have to be revised on a more or less continuing basis, using feedback from each group of people affected by the plan. Any real plan must contain a plan for revising the plan. This plan for revising the plan is comprised of one or more negative feedback loops that stabilize the change process itself.

Chapter 4. Planning Like a Software Engineer

Summary

  1. Anticipating (Pattern 4) and Congruent (Pattern 5) organizations are truly engineering organizations, because people in them consistently think in engineering terms.
  2. Engineering can be done in many ways; there is no gospel, no holy book in which you can look for all the answers.
  3. Engineering is what you do when you can't get everything you want, because it's the art of getting as much as you can under the circumstances. Engineering does mean you make conscious decisions about what you're getting for what you're giving up, and why.
  4. A trade-off curve represents the boundary between the possible and the impossible with today's best engineering practice.
  5. Good software engineering management is the ability to stay on or near the trade-off curve of best possible practice at a point that represents the most desirable trade-off between the variables.
  6. Sketching a family of trade-off curves among critical variables gives engineering managers a basis for discussing the potential trade-offs, as among quality, economy, and schedule.
  7. Most technologies are formed from a mixture of other technologies, and they are linked by management decisions about when to use which.
  8. The fundamental graph of engineering management action shows many of the important decisions facing an engineering manager.
  9. Software engineering management is concerned with choices about technology in a broad sense of that term, and those choices are made at many levels. If control is not in place at one level, it becomes more difficult to control at another.
  10. For a software engineering organization to be well managed, all of the levels have to be well managed. But, in addition, they have to be coordinated with one another. Therefore, software engineering managers have to decide on what level to place various control responsibilities.
  11. We know that decisions at higher levels act to control decisions at lower levels, but decisions at low levels can also control decisions at higher levels. We need to be aware of why we put which control decision on which level.

Part II. What Changes Have to Happen

Chapter 5. Components of Stable Software Engineering

Summary

  1. Although software engineering is in many ways the same as any other kind of engineering, it also has unique properties arising from the nature of software.
  2. According to Boehm, software costs are affected by the size and complexity of the system, by people factors, by the tools that are used, and especially by poor management.
  3. Software projects fail most often when control information is missing, distorted, irrelevant, or just plain wrong, or when managers are unable to function congruently when taking actions as controllers.
  4. Control information failures take several common forms, such as
    • not knowing what product is wanted
    • not understanding the nature of the processes of software development
    • having no visible evidence on how the process is proceeding
    • lacking sufficient stability to make meaningful measurements
    • lacking or losing design integrity
  5. Over time, software engineers are evolving solutions to information failures, such as
    • requirements processes to identify what product is wanted
    • process models to explain the nature of software maintenance and development
    • processes that provide visible evidence on how the project is proceeding
    • systems to provide stability by controlling changes
    • tools and techniques to maintain design integrity
  6. In the end, though, it is the character and personality failures—the incongruence—of management that are the biggest cause of software failures, and these must be worked on through ongoing personal development.

Chapter 6. Process Principles

Summary

  1. There are a number of principles that any effective process model must follow. These principles act as guides when you're exploring the strengths and weaknesses of different models. They also act as guides for managers who are trying to implement one or more process models.
  2. The Millionaire Test says,
    • If you can't show that your process is better than random, don't use it.
    • The Millionaire Test puts the burden of proof on any people who propose a new process, encouraging them to develop a measurable process.
  3. Many processes are in operation today that are demonstrably worse than random. The point of the Millionaire Test is not to advocate random processes, but to awaken an organization to the idiocy of some of its processes.
  4. Feedback works on continuity. The pieces in the model cannot be too large (or response will be slow), and they must be stable (or the response will not be predictable). The Stability Principle summarizes these two requirements: Every part of a process must be a controlled system.
  5. The Stability Principle shows that testing is not a stage, but part of a control process embedded in every stage. What is often called system test is not a test at all, but another part of system construction, perhaps better named "system integration."
  6. From what we know about controlling a project, and from what we know about the natural imperfections of human beings, the concept of private ownership of work products cannot be part of any process model. Instead, every process model must conform to the Visibility Principle: Everything in the project must be visible at all times.
  7. Since nothing is real unless it's passed review, and since invisible things cannot be reviewed, a corollary of the Visibility Principle is the Reality Principle:

Nothing is real until it has passed independent review.

  1. Process diagrams are meaningless and dangerous if they don't describe the measurements that will tell you if the work of each box has actually been accomplished. The Measurability Principle says,
    • Anything you don't measure will be out of your control.
    • The Measurability Principle also says "Good management takes measurement," but that doesn't mean if you measure lots of things, you must be in control.
  2. The Zeroth Law of Software Engineering says,
    • If you don't have to meet requirements, management is no problem.
    • This law is important enough to deserve its own chapter.
  3. The Product Principle says,
    • Products may be programs, but programs are not products.
    • Violation of this principle leads to essential parts of information systems being omitted from process design, or even omitted from the product.

Chapter 7. Culture and Process

Summary

  1. This chapter considers three questions all managers must understand if they would change their organization:
    • What determines the way ordinary people behave in an organization?
    • How do those behaviors affect the organization's formal processes?
    • How are ordinary people affected by those processes?
  2. The Culture/Process Principle illustrates the trade-off between culture and process:
    • Whatever you can safely assume in the culture, you don't have to specify in your process description.
  3. The Culture/Process Principle warns us that the same process description will mean different actions in different cultures. Therefore, before plunging in to a grand farrago of process building, we need to understand the culture for which we are building those processes.
  4. The level of quality culture is forced by either customer demands or problem demands. This doesn't mean that in the short run, culture is determined by these two parameters. In the long run, however, organizations that don't develop an appropriate cultural pattern will be forced to change or die.
  5. The consistency of an organization's cultural pattern is striking, and requires no sophisticated measurements to detect. In a culture stemming from the FDA requirement that all work connected with the use and testing of drugs be done under strict process controls, software will be done under strict process controls. If you don't follow them, you go to jail.
  6. In the culture producing space flight software, there is a consistent understanding of everyone in the organization that human lives are riding on the flawlessness of their software. This vision—"Bring 'em back alive—leading with consistent strength over fifty years, has placed this organization in a very advanced software cultural pattern.
  7. In a software organization waiting to be bought or go public, the principal objective is not to produce life-critical systems, but to create an attractive company for the auction block. A short time horizon is often an important part of such a culture, and long-range (or even medium-range) planning is not acceptable, though it may be acceptable to put up a sham of planning to make the firm more attractive to potential buyers.
  8. Not all the themes communicated by management can be considered intentional. A common theme in software organizations these days is the inability to make decisions and stick to them. This theme is communicated not by what management does, but mostly by what it doesn't do: make decisions and follow through on them. The cultural message in such an environment is not to stick with important decisions, so you'll never be caught in a "mistake."
  9. The number of customers influences an organization's approach to design/debugging. With millions of customers, PC software companies simply don't consider shipping rare bugs a life-and-death problem. Instead, they concentrate their energies on creating a culture of quickly fixing bugs.
  10. Because of their positions in the regulatory process, each level of management tends to have a different conception of the word "process," and these differences tend to interfere with process improvement efforts.
    • Top management is responsible for the future of the business, which will not be prosperous unless present and future customers are satisfied. Thus they are concerned with what could be—the process vision.
    • Middle management is concerned with what should be—the process model that translates the vision into specific action steps.
    • Supervisory management is concerned with what is—the only thing that can truly be called the process as opposed to the process vision or process model. Models and visions are process descriptions, which may or may not be followed in the actual process. Supervisory managers translate the models into actions, actions that may or may not reflect the original process vision descending from on high.
  11. The quality of leadership is part of the culture, perhaps the part that is most dangerous to the Old Status Quo. If leadership improves, then the culture must improve.

Chapter 8. Improving Process

Summary

  1. Many software organizations have difficulty in improving their process because they mistake the process models and process visions for actual processes. Because these models concentrate on direct work, they omit most of the areas in which process improvement is possible: the management activities.
  2. There are three distinct types of process improvement, corresponding to the three meanings of process. Cultural changes have much greater potential impact than process changes because one cultural change can affect hundreds of process changes. In order for substantial improvement to take place, the managers' levels must be open to investigation and change.
  3. One classic process improvement strategy consists of four steps:
    1. Document the actual process.
    2. Discover the root cause of the problem.
    3. Modify the process to reduce variation.
    4. Test the process improvements.
    5. If this model is applied at all levels, substantial improvement is possible.
  4. When you examine the real process, you will discover a number of places where things being done were not part of the process model—called the chicken wire factor.
  5. Improvement teams often try to address a symptom without really knowing the root cause behind it. Only after understanding the root cause will the teams be able to choose among solution ideas and modify their process model to include previously implicit steps.
  6. Such process model improvements may not be possible without cultural changes to support them. Such changes will not be possible without explicit modeling of the actions of upper management.
  7. Monitoring the effects of the improved process is always necessary because real organizational changes never follow simple logical plans, so that the actual process always deviates from the process model in unexpected ways.
  8. Monitoring and interviewing may be essential to uncovering the invisible factors that are behind the deviations. These factors are often human factors not ordinarily discussable in the culture. Once these factors have been uncovered and handled, it's often necessary to institute cultural changes to prevent repetition of the same pattern in the future.
  9. Process improvement must involve all levels of the organization. You don't know, when you embark on an improvement process, what you will have to change: the process, the process models, or the culture. In general, you can assume that all three will need some adjustment.
  10. When you study many process improvement situations, you begin to see a pattern of principles:
    • Individual issues often underlie the toughest improvement situations.
    • The way short-term solutions are handled will set cultural precedents.
    • Unless the culture changes, the same kinds of personal issues will keep recurring.
    • Cultural changes will involve upper management; otherwise process improvements will keep being undone by the same culture that created the process issues in the first place.
    • You can change the logical process first, but consider this a test to see if the problem is entirely logical.
    • To address emotional problems, you'll need to get under the surface to the layers of information protected by the cultural rules governing what's not okay to talk about.
    • Be careful changes are not made in a blaming way.
    • A policy of not blaming does not mean a policy of placating.
  11. A common way to avoid learning process principles is to say, "Yes, that's very nice, but our company is different." True, the details always differ, but the principles are the same and the results are similar.
  12. Another common way to avoid process improvement is to say, "Yes, but it costs too much." The answer to this excuse is that properly done process improvement does cost a lot, but it also pays a great deal more. If it doesn't pay big dividends, then it's not been properly done.
  13. Don't be tempted to hide the true cost of process improvement from upper management. Better to start with a realistic idea of the commitment in time and resources than to be undermined later when executives are surprised. Be sure to offer a detailed picture of benefits, which will surely justify the true improvement costs.

Chapter 9. Requirements Principles and Process

Summary

  1. Software engineering is in the business of building, running, and maintaining things for some customer or customers. Requirements are only part of the process of connecting with your customers and responding to them, but they are an important part.
  2. Until recently, the computing industry seems to have avoided the subject of requirements. In the light of all this literature, it's easy to understand why so many software engineering managers have made the mistake of believing that they should have unchanging requirements before starting any project—the Assumption of Fixed Requirements.
  3. Translating requirements into code is an essential part of software engineering, and it is the part that has received the most research attention over the past four decades. But because of that attention, it is no longer the most difficult part of the process, nor is it the process that will yield the most benefit to process improvement efforts.
  4. The Zeroth Law of Software Quality concerns requirements, and appears in various forms:
    • The Zeroth Law of Quality: If you don't care about quality, you can meet any other requirement.
    • The Zeroth Law of Software: If the software doesn't have to work, you can meet any other requirement.
    • The Zeroth Law of Software Engineering Management: If you don't have to meet requirements, management is no problem.
    • The less closely you have to meet requirements and the more your requirements approximate the Assumption of Fixed Requirements, the easier it will be for you to manage.
  5. Changing to another cultural pattern requires a transformation so that people let go of previously successful models, such as the Assumption of Fixed Requirements. For an organization to improve its cultural pattern, requirements process models need to be revised.
    • People in Oblivious cultures tend to be oblivious to process models of any kind, let alone requirements.
    • The linear process models of Variable cultures represent a step up in thinking, even though linear process models have no feedback at all.
    • Routine organizations may acknowledge the non-linearity of the requirements process, but try to keep exceptions to the linear process as linear as possible. The principal job of Change Control is to filter out as many requirements changes as possible—to keep the process linear.
  6. The Pattern 2 requirements model works reasonably well when
    • projects are small, so development takes place over a small time span
    • the underlying business process is very stable
    • customer expectations from information systems are low, and decisions are left in the hands of developers
  7. Much of the time software work involves a constant dialogue between the product's customers and the software developers.
    • In Pattern 0, the requirements process runs inside the head of the person who's doing development.
    • In Pattern 1, the requirements process generally runs back and forth between one customer and one team or individual developer.
    • In Pattern 2, the requirements process runs alongside development, although the developers do their darndest to keep change from happening.
  8. The key process idea in moving to a Steering culture and beyond is that there are really two processes: one to develop a requirements product and one to develop a software product. In this view, the software development process and the requirements development process are mutually controlling twin processes, each exercising feedback control over the other.
  9. In mutually controlling processes, the purpose of each requirements stage is to narrow the discrepancy between what is wanted and what is documented, not to eliminate all discrepancy.
  10. Prototyping, of course, is an explicit way of making the requirements development process and the system development process mutually controlling, but effective prototyping is by no means trivial. If you adopt prototyping in order to avoid facing process issues, you are in for a series of nasty surprises.
  11. Requirements ideas often emerge from the system development process and flowing upward into the requirements process. A good requirements process authorizes the participation of developers, focuses their efforts and makes them visible, yet keeps them under some sort of control so they can make the very real contributions only they can make.
  12. A Steering or Anticipating requirements process is a controlled feedback process in its own right. Such a process model is more in keeping with the vision that says getting the requirements right is the most important part of product development.

Chapter 10. Changing the Requirements Process

Summary

  1. For many software organizations, an inadequate requirements process is the principal impediment to higher quality. To move such an organization to a controlled requirements process, managers need to plan and execute four major steps:
    1. Measure the true cost and value of requirements.
    2. Gain control of the requirements inputs.
    3. Gain control of the requirements outputs.
    4. Gain control of the requirements process itself.
  2. An improved requirements process pays for itself in a number of ways:
    • faults caught early or not created at all
    • redundant work eliminated
    • better reception by customers
    • faster, more manageable development
    • improved maintenance
  3. Requirements come from many places, some of which are official, but many of which simply leak into the process. To gain control, management must create a process to
    • identify and plug all leaks
    • replace leaks with explicit negotiation
  4. When half of requirements come from unofficial sources, you cannot possibly control software development. To gain control of this requirements chaos, you must
    • recognize that requirements come from many sources
    • survey the sources of all leaks and close them tight so they must come through a single channel
    • accept these multiple interests as legitimate, but not necessarily guaranteed to have their way with the requirements
    • create an explicit negotiation process that will consider anybody's requirements ideas
  5. Requirements conflicts happen, and if not resolved any other way, they are resolved by the customer. Such customer resolution is not the best way to resolve requirements conflicts, but is needed to back up the system when negotiations fail.
  6. To prevent leakage and convert it into an explicit requirements capture process, there must be a single path for a requirements idea to be converted to a requirement. Anyone with a requirements idea—managers, engineers, customers, or anyone else—must understand that there is no other path by which this idea has a chance of becoming a requirement.
  7. Proponents of requirements ideas must clearly understand that they are simply requirements ideas, not requirements, until they pass through this process. Once requirements are gathered, they are considered rough requirements until they have passed through a smoothing process of analysis and clarification. If they pass this step, they are considered to be in reviewable condition, and are called requirements candidates. Only this review process can promote candidates into requirements that are placed in the database. Rejected ideas are turned back to their originators, who may then modify and resubmit them.
  8. The requirements database is used for building the system, and is also needed when new rough requirements are considered. That is because requirements must not only be clear and correct in themselves, but must be consistent with existing requirements.
  9. It isn't easy changing from the old back-door way to this new process of explicit negotiation. You can be sure that more than one person will challenge the system and try to return to the Old Status Quo situation.
  10. A requirements document is much like a software product. Like software, it is an information product, so
    • it must be made visible.
    • it must be made stable.
    • it must be made controllable.
  11. A requirements document carries only a small part of the requirements communication load. In practice, most of the load is carried by
    • individuals who understand the requirements and help other people understand
    • teams that work effectively, so that they can communicate with one another about requirements
  12. To have the kind of understanding that keeps requirements simple, people must learn from participation in the requirements process. Participation alone won't be sufficient unless information is coordinated, open, available, and of known quality.
  13. If you have a full-time requirements manager with a staff of trained, committed people using appropriate tools and high quality information, you make the requirements task into a real project.
  14. The requirements process will also be better controlled if supported with appropriate tools, such as
    • configuration control of all the relevant databases
    • an active requirements database that allows all interested parties to examine any part of the current requirements at any time
    • network access to the database, especially if it is seamless with other network use
    • electronic mail and voice mail to support person to person communication
    • special facilities for requirements meetings
  15. Management is ultimately responsible for defining what problems the organization is to solve internally, and for its customers. These managers must have the authority to establish and control the processes that make it possible for them to control this definition.

QSM: Volume 4.3: Change Done Well

Chapter 1. Starting Projects Correctly

Summary

  1. Most unsuccessful projects were under pressure from the moment they started, actually even before the moment that their process models said they started. And, indeed, the primary reason for the pressure was that there were no explicit models of what happens before a project officially starts.
  2. Preceding every project is a series of high-level negotiations that lead to the decisions that constrain the project. If these negotiations are not both informed and congruent, the project is finished before it starts.
  3. When a project is in the fuzzy early stages, before official initiation, the first question is, of course, what benefits the organization expects from the successful completion of the project. But infinite potential benefits will have zero value if the project isn't completed.
  4. When project benefits are large, it's difficult to make a congruent decision about risk. There are a number of relatively formal systems of risk analysis that can aid in making this decision, and any software engineering manager should be steeped in at least one.
  5. Rough consideration of Boehm's ten factors generally improves the chances for project success by at least a factor of two:
    1. Personnel shortfalls
    2. Unrealistic schedules and budgets
    3. Developing the wrong software functions
    4. Developing the wrong user interface
    5. Gold plating
    6. Continuing stream of requirements changes
    7. Shortfalls in externally furnished components
    8. Shortfalls in externally performed tasks
    9. Real-time performance shortfalls
    10. Straining computer science capabilities
  6. The biggest risk of all is that the management team isn't up to the job of performing a congruent risk analysis, let alone leading the project. The planning process, not the plan, is what transforms ridiculous fantasies into real projects.
  7. For a project to succeed, these early negotiations must produce a congruent agreement, one that balances the Self, Other, and Context. The single most important measure of any development project is, Did we fulfill our agreement? If you negotiate well, you'll be able to use this measure. If not, your project will probably fail.
  8. One essential for making projects comparable is to be sure they start on the same basis, which implies that all negotiations must be done explicitly, done well, and the agreements recorded, including
    • Desired results (not methods) identify what is to be done, and when.
    • Guidelines specify the parameters (principles, policies, etc.) within which results are to be accomplished.
    • Resources identify the human, financial, technical, or organizational support available to help accomplish the results.
    • Accountability sets up the standards of performance and the time of evaluation.
    • Consequences specify—good and bad, natural and logical—what does and will happen as a result of the evaluation.
  9. A culture of fear creates covert collusion to violate good requirements processes. As such, the problem cannot be solved without top management change.
  10. Guidelines specify the principles and policies within which results are to be accomplished. Guidelines are a way to establish triggers while you are relatively sane, so they will keep you from doing foolish things when the project is driving you insane. Here are a few examples of guidelines:
    • Brooks's Law: Adding X per cent to the staff will not generally speed the schedule by X per cent.
    • The Square Law of Computation: Adding X per cent to the schedule will not accommodate X per cent increase in functionality.
    • Jones's Law: Those parts of the product that don't go through the entire development process will cause 90% of your problems.
  11. All resources are not created equal. Human, financial, technical, or organizational resources each have their own algebra, so you cannot assume that each party to the beginning of a project knows what the resource commitments mean.
  12. The most common accountability fallacy in software projects is to mistake effort for results. Lacking any better measure, you have a single standard of performance—the time put into the job, not the product produced.
  13. Another important part of accountability is the time at which evaluations take place. Reporting deadlines and delays often ensure that all reports will be works of fiction.
  14. When negotiations at the start of a project are made in an atmosphere of fear and intimidation, the project personnel will agree to everything while simultaneously looking for ways to escape. The same dynamic reappears every time management swoops down to take a look at progress.
  15. Management reviews are also popular in blaming cultures as a way of punishing any project that fails to provide management with a series of glowing reports. A three-day circus parade of project progress violates the basic principles of cybernetic management: Act early, act small, using more-or-less continuous feedback.
  16. In most of these large reviews, there is no possibility that the project could be canceled, no matter how bad the material, because of how much has been invested already. Moreover, there is essentially no chance that any major change could be made. The chunk of work is too big.
  17. There are many other ways to get information for managing projects than by conducting traditional management reviews. The Hudson's Bay Start (or shake-down cruise) is one of the most effective types of small, relevant, timely review.

Chapter 2. Sustaining Projects Correctly

Summary

  1. The plan you make at the beginning of a project says, "If we can do these things, I will get the result I now want." It doesn't say, "No other way will get it," or "I won't change my mind about what I want."
  2. To become an Anticipating manager, you also need to anticipate that nobody can anticipate everything. Therefore, you need to examine some of the common process models from a more practical point of view, to determine under which conditions each is applicable.
  3. The Waterfall Model underlies all other development process models. The essence of all Waterfall Models is that one thing happens after another, that water doesn't run uphill. When one stage is finished, it's finished, and there's no going back.
  4. The output of each stage of the waterfall defines what the next stage has to do, each being a further translation of the original desires. If there's been nothing lost or added in translation, the final output is what was desired. The Waterfall Model is the simplest class of processes, and to use anything else is to add complication. Therefore, you should always use the Waterfall Model, when it applies.
  5. The Cascade Model is a collection of waterfalls, one after the other, or at times one beside another. Cascading is effective because of the Square Law of Computation. Decomposing one large problem into two smaller problems may be half the difficulty and also less risky. However, there is always an integration cost to cascading.
  6. Parallel cascades can be used for speed or to reduce risk by setting up two or more waterfalls to build the same project. The best (or quickest) result can be chosen as the product, and/or the multiple products can be used as reference tests for each other.
  7. The popular Spiral Model is a type of cascade, but drawn in a spiral to show cumulative cost (by distance from the center) and progress on each cycle (by angular displacement). Perhaps the strongest feature of the Spiral Model is the way it emphasizes that development (or maintenance, for that matter) is a series of cycles, each consisting of the same kinds of processes. The Spiral Model, however, is actually more of a process vision, and may mislead the people who are actually carrying out the process.
  8. Iterative enhancement is software development based on an existing piece of software as a base. There are a number of variations of iterative enhancement, as when
    • the requirements have changed only incrementally, little enough that much of the original system can be preserved
    • the functional requirements are preserved but the design may change
    • the design is preserved, but the code may change
  9. Iterative enhancement is a form of reuse. Reusable code is a great idea. Like all great ideas, it must be managed.
  10. Another way to look at reuse in software development is to consider what is actually the most common method today of obtaining software: the off-the-shelf method. This is the method we use when we buy a software application. Someone else did the development, so we simply need to apply it to our needs.
  11. People frequently bypass all the early stages of software development and use their existing software in some new way. Some software is designed to encourage this kind of reuse, but some is not. Users don't seem to care, because they reuse the software with which they're most familiar.
  12. Prototyping is many things under a single term:
    • a process to get requirements
    • a process to get something working quickly, perhaps to
    • relieve pressure from customers or management
    • get a feel for a system
    • simulate system performance early in the development cycle
    • a way to start writing code early, perhaps to smooth the workload, or perhaps just to do something developers like better than requirements work
    • a disciplined process of incremental development
    • a way to prove a concept or measure something
    • a synonym for hacking
  13. The essence of prototyping is "build-a-little, learn-a-little, build-some-more." We call this hacking when the amount built at each stage is very small. When the increments are intermediate in size, we may call the approach "rapid" prototyping, though calling it that doesn't make it rapid.
  14. Top-down development (as opposed to top-down design) is one way of prototyping. First you build a skeleton embodying the general structure of the application. As development progresses, you fill in the details by replacing the stubs with code that more and more closely resembles the desired finished product. Unlike top-down design, you don't have to know the detailed requirements when you start the process.
  15. To be successful, prototyping requires more management discipline than other forms of development, not less as many people believe.
  16. Regardless of the combination of methods used, they are merely templates to guide you in making a project plan. The plan will elaborate the template in more detail, ideally decomposing everything to a connected network of standard task units. After you follow it for a while, something happens that you didn't anticipate. Now you have more information than you had at the beginning, so you replan, perhaps even switching development models.
  17. Slack allows you to keep replanning to a minimum. Slack can take the form of resources, time, and quality (requirements). Much of the manager's job in the middle of a project is trading one kind of slack for another, to deal with contingencies. Slack is the principal method for coping with project risks. Anticipating project managers forge all three types of slack in their plans—the amount depends on the amount of uncertainty about the future.
  18. Operating a project with less slack than appears prudent increases the chance of total project failure. Weigh the cost of slack and the risk of failure against the value of completing the project as planned.

Chapter 3. Terminating Projects Properly

Summary

  1. In well-managed projects, termination comes more or less as planned, with the delivery of the desired product or modification. Perhaps the greatest challenge and test of a good manager is the ability to terminate projects that should be terminated, when they should be terminated.
  2. Testing is productive, but not production. In an Anticipating organization, testing is merely part of every standard task unit in which something is built, and putting testing in a separate box may mislead people into thinking that testing is done once, at the end of the entire process.
  3. Process testing asks, "Where are we in the process?" Product testing asks, "What state is the product in?" The requirements or prerequisites part at the front of a standard task unit is a process test, and so is the review at the end. In the task itself, there may or may not be product testing, but one of the things the review will examine is whatever testing has been done. Using this and other information, the review will determine whether the task of producing the product is finished.
  4. Most process tests take the form of asking, "Should we terminate?" or "Should we replan the task?" Product tests are different, asking, "What are the faults in this product?" Any evidence that a project is not working earnestly and effectively to expose faults is evidence for a process test that says:
    • IF faults are being hidden
    • THEN replan project.
  5. Most software work takes place at the level of the fix, the patch, or the update in some sub-phase called testing—that is, doing construction that was not called construction. Vast resources are consumed by developers who continue to build long after the building phase is finished.
  6. Adding a line back from one stage to another does not give a true picture of the testing/quick-fix/hacking process. Since the number of iterations is unknown, this kind of shorthand easily creates a Downfall Model. Such unbounded process loops are one of the primary sources of overruns of project estimates because hacking starts as soon as the lid of discipline is removed under the guise of testing.
  7. You can estimate the number of development cycles based on an estimate of the number of faults left that need fixing after the first iteration and after each subsequent iteration. These estimates of remaining faults tend to be characteristic of each organization's culture, and are among the first measures you should obtain if you wish to stabilize your development processes. By comparing the number of faults removed to the estimate, you get an early indication that you may have more iterations (or fewer) than you'd planned.
  8. Never use loops in a process description. Never use loops in a plan. If you want your plans and process descriptions to be true to life, use your measurements to unroll the loops.
  9. Managers without access to appropriate models and measurements tend to do exactly the wrong thing when a project is going sour. Formal measurements may not help you to recognize when your project is starting to fail, because the formal measurement system may be the first thing to start failing. You need to watch and listen for signs outside that system, and STOP the project when they arise.
  10. The earliest indicator that a project may need terminating is when you're asked to certify that a plan as achievable, when it's not. In answer to a request or demand to certify that the plan is achievable, you can say, "Perhaps it is achievable, but I don't know how to achieve it."
  11. "Test complete" is often scheduled according to when some senior manager has been promised a demonstration, not when the quality has reached a certain level. Under this kind of pressure, managers are often asked to certify that a product is acceptable, generally when it is not—a sure sign that the project ought to be terminated and rebirthed with a new acceptance criterion
  12. In the middle of a project, perhaps the most reliable indicator that a project may need terminating is a decline in morale—the overall intuitive assessment of the project's chances by the entire staff.
  13. A plan is not a process, but a process model for one particular project. It is not a general process model, but an instantiation of one, since it's unlikely that we will ever have two projects with exactly the same plan, even if they follow the same process model.
  14. Every plan must plan for various kinds of termination. The unanticipated need for another iteration as a signal that your plan has gone sour, that you need a new plan. And, since the plan is the seed of the project, what you really need is a new project.

Chapter 4. Building Faster By Building Smaller

Summary

  1. Futile efforts to change software more quickly often mean that we change our software organizations more slowly. The Satir Change Model suggests a number of principles that show how to respond to pressures to speed up the building process without destroying your plans for long-term improvement of your organization
  2. There are two fundamental tactics you can use to accelerate building process:
    • increase your capacity for building
    • decrease the size of what you're building
    • Increasing capacity—not just numbers, but skill as well—in the long run helps achieve schedules, high performance, low costs, and just about everything else—and so will be the subject of later chapters. Decreasing size, however, is something that managers can control in the short run.
  3. System size enters into many of the fundamental dynamic feedback loops of software engineering. For example, in a bigger system, there are
    • more faults
    • more places to look for faults
    • more possibility of faults interacting, which confuses location efforts
    • This dynamic suggests that the system in which we are looking for faults should be as small as possible.
  4. The most important measure of system size is the mental size of the system—the amount of mental effort required to play the game effectively. This size may correlate roughly with lines of code, but there are many ways in which programs L and B with the same number of lines may be very different in this meaning of size.
  5. In addition, mental size is also relative to whose mentality is involved. Smarter, better trained people working with superior tools will see a smaller system.
  6. Systems grow in functionality when the software developers placate the customers or their surrogates, the marketers.
  7. Reducing scope does not necessarily mean giving customers less. If you have an Anticipating process for gathering, analyzing, and ranking requirements, you'll know what customers want and what's most important to them.
  8. Once you've actually been working with the system, you have data on which functions have shown the most faults. If you choose the worst ones to get rid of, you can have an effect that's out of proportion to size. An order-of-magnitude reduction in location time can easily result from a small reduction in function.
  9. An Anticipating organization will have foreseen the possibility of late reduction in scope and maintained a good, open relationship with its customer. With such a relationship, it's much more likely that this offer will not be a surprise, and not be confrontational.
  10. You can avoid de-releasing trouble if you build top down with the most important functions being built and integrated first, because then 90% complete would probably give 99.9% of value. As a variant, you can produce some of the new pieces in prototype form, then offer them to the customer.
  11. No software product was ever delivered fault-free, so one way to eliminate the worst part is to ask your customers to put faults in priority order:
    • F. I cannot use the system with this fault.
    • D. I can use the system for a certain time with this fault, at a cost of X.
    • C. I can use the system indefinitely with this fault, at a cost of Y.
    • B. I can use the system indefinitely with this fault, at no cost.
    • A. What fault?
    • A++. What a great feature!
  12. Cutting down system size is a powerful intervention, and the earlier you can do it, the more powerful it is:
    • Fewer resources are wasted on things that don't have to be done.
    • There's more time and less pressure to get people trained to new tasks
    • Project managers will be able to set reasonable expectations
    • It's easier on the people in your organization. Overload is like cancer, and feeds on itself.
  13. Some of the dynamic size effects are relative to the schedule. Therefore, some of the effects of size reduction can be gained by slipping the schedule. Before you negotiate a schedule slippage, however, study the dynamics of your system. Attempts to deliver a system on an impossibly short schedule will only lengthen the actual time you need to deliver.
  14. Ultimately, what helps you most in managing system size is courage and realism.
  15. Some late requirements changes are necessary in any organization, but you must never forget that they are increasing the size of the system. The dynamics of system size are nonlinear, so you need to be very generous in estimating the effect of late arriving requirements, and make your side of the business case, too.
  16. Tell your customer in advance that in the event changes are requested, a specified process will be used to evaluate the request and that it will take X amount of time. Late surprises produce angry customers, diminish trust, and may turn the entire relationship adversarial rather than cooperative.
  17. Remember the Helpful Model: Most of the time, in spite of appearances, everybody is trying to be helpful. Generally, your customers simply don't understand software quality dynamics—that's your profession, not theirs.

Chapter 5. Protecting Information Assets

Summary

  1. In construction projects as in software development, changes can be introduced into translation from design to manufacturing by builders who are trying to improve the product, and problems can arise if those changes aren't subjected to the same rigorous procedure as the initial concept. In the light of experience with software systems, an Anticipating manager will anticipate that unreviewed changes are dangerous and take preventive action.
  2. Information systems are assets, and a major part of your job as manager is to protect your organization's assets. Many of the organization's assets are in the form of information:
    • requirements databases
    • code libraries
    • data dictionaries
    • test libraries
    • designs
    • standards
    • project plans
    • process descriptions
    • process histories
    • measurement libraries
    • manuals and documents of all sorts
  3. Code libraries—particularly object code libraries—are the asset of last resort. A change in the object code library affects the behavior of a system directly, without any further step in which to check for problems. If you want to protect assets, code libraries are the first place to look for improvement.
  4. Control of other assets need not be as strict as code control, because there are checks and balances that follow certification of data dictionaries, designs, standards, and so forth. Nevertheless, lax asset control tends to produce creeping deterioration, and eventually will lead to the collapse of any software engineering organization, no matter how carefully it controls code.
  5. As systems grow larger, uncontrolled naming leads to increased error and time to perform engineering tasks. Many organizations operate without any explicit data dictionary and manage to blunder along, but blundering simply won't do if you want your organization to become Anticipating. The most important benefit of names is their consistency. As a manager, your job is to see that naming doesn't get out of hand.
  6. The value of standards as assets is easy to miss, because their impact is usually through many small savings. Configurations are much easier to manage if you have standards, at the very least because there is much less code to manage.
  7. A sensible approach to information hiding is to develop a culture, supported by configuration management tools, that encourages builders to play the black box game, and act as if they don't know what's inside all the other black boxes. To do this, manage the design interfaces with all the care given to code management, for these are the only places one person's design changes can affect the correctness of another person's designs.
  8. Design quality and configuration management quality are in a mutual feedback relationship: Poor design increases errors in code, which produce lots of code changes that increase the load on the code management system. Poor design also makes the code management task more complex, because it's not always clear where things are, and where they're supposed to be.
  9. A good design acts as a natural index to data stored about a system—such as, code, tests, and maintenance manuals. Often, complaints about the complexity of code management are actually complaints about poor design.
  10. For some reason, programmers don't consider tests to be assets, perhaps because of the unsystematic way in which many organizations conduct their testing. Sometimes, you can improve this situation by having separate testers do the unit testing.
  11. Many developers who are quite careful when composing code go into a hacking frenzy when unit testing, destroying whatever design integrity their original version may have possessed. In the process, they also destroy valuable information about the history of the module.
  12. Error-prone modules are ten to a hundred times more likely than the average module to contain problems. Thus, by noticing the early history of a module, you can predict its future and, if indicated, rebuild it. Because of the universal problem of error-prone modules, a module's history is an essential tool of maintenance.
  13. Unit testing of modules should create a record of trouble that becomes part of a module process history. This history is a most valuable asset, and should contain
    • the complete history of code changes
    • the complete history of unit testing
    • all test cases, plus expected and actual test results
    • issues lists and summary reports from all technical reviews
    • the schedule history (which is often an indication of error-proneness)
  14. To create an Anticipating organization, you must know the past, for there is no other way to anticipate the future. Anything that is developed on a machine can and should be archived, and the archives kept up-to-date and accessible.
  15. Moving to an improved system of protecting any form of information assets can follow a plan similar to that given for changing the requirements process:
    1. Measure the true cost and value of protecting the asset.
    2. Gain control of the changes (inputs) to the asset.
    3. Gain control of the access (outputs) to the asset.
    4. Gain control of the entire process of creating and maintaining the asset.

Chapter 6. Managing Design

Summary

  1. As a manager, you may be able to satisfy your passion for design by using it to design organizations and processes, but not information systems. Because designs are assets, there is one point of view that dictates that managers must always stay involved in reviewing designs—the point of view that design is designed for manageability. When a design is too complex to be managed, the manager must insist on simplification.
  2. When the design debt grows large, management becomes well nigh impossible. The accumulation of design debt can certainly arise from "featuritis," but generally develops from excessive and/or hasty attempts to correct faults.
  3. The common fallacy is that code is the source of most faults, but most failures found in testing don't come from faults created in coding; they're just found immediately after coding.
  4. There are many examples of "coding faults" that didn't originate in coding:
    • code for which there was no requirement
    • code for a wrong design
    • code for a wrong requirement
    • code not written because we forgot the requirement
    • code that's too long because the data structure was clumsy
    • code that's wrong because interface was too complex
    • code that's wrong because two parts of the design had different ideas
  5. Most faults originate in requirements and design, though process errors are also significant in poorly managed organizations. Process errors are caused by the development process, such as duplicates, zaps, and failures to update. Many of them can be addressed by improved process design, which is definitely a management responsibility.
  6. Increased design effort decreases coding effort in developing or maintaining an information system when it results in
    • a better-designed data structure
    • cleaner interfaces
    • fewer switches and flags
    • fewer global variables
    • a more testable system
    • reuse of constructs
    • The direct effect of some of these improvements is a reduction in coding effort
  7. Decreasing direct coding effort is not the only positive effect of good design. Other important reasons for design effort are
    • to decrease the number of large-scale errors
    • to make the time to build is also less variable, making estimating and control easier for the management
    • reducing the total number of faults to be repaired
    • reducing the time and effort spent in testing
    • making code more understandable, and thus more easily maintained
  8. The change to an Anticipating organization is a partly a change in emphasis from coding to design. Only poor designers allow themselves to be rushed by poor managers, and vice versa.
  9. As a manager, you can at least help your organization prevent some of the worst design mistakes, such as
    • Using a technology not because it's appropriate, but because it's there.
    • Being different at any cost; reinventing whenever possible; copying nothing, not even good ideas.
    • Just plain stupidity.
    • Too many cooks.
    • Oops! Where the hell are we going to put this?
    • You need not be a designer to prevent these blunders. You simply need to be the last bulkhead of sanity.
  10. It's important for an organization to perform some scanning for new technology. But even when something new and apparently useful comes up, it should never become a license to bypass the ordinary design process.
  11. Designers who can't seem to use anything that anyone else ever thought of before are always fooling themselves. When you think you're being original, you're usually just being unaware of what went before you. Most programs are not, and need not be, masterpieces of original design.
  12. Whenever possible, watch for and exploit three levels of reuse:
    • sharing design ideas, the most productive type of sharing
    • sharing copies of source code, but modifying it (not maintaining the connection with the original)
    • sharing object code
  13. Bad design destroys understandability, and anything that destroys understandability destroys design. Doing things in a hurry reduces the quality of thinking.
  14. Slack is always needed in complex systems to investigate the unknown future, so allow slack in designs and do not push designs to the limit.
  15. Other things being reasonably equal, favor simple designs over complex designs. Do not, however, mistake the simplistic for the simple.
  16. It's a good idea to keep the architect involved in the building process—to learn, not to stand over the builders and critique their work.
  17. Design is supposed to be forethought; afterthoughts are an indication of failure in the design process. As an Anticipating manager, you can help prevent afterthoughts by a few simple policies.
    • Insist that all designs be written down so they can be reviewed.
    • Apply the Rule of Three.
    • Don't accept designs that are described as "the only way."
    • Apply the Paradox Rule.
    • Don't accept designs from designers who haven't confronted the fundamental trade-offs in the problem and given you a choice of how you would like to make the trades.
    • Insist that you understand what problems the design actually addresses, by applying reverse design.

Chapter 7. Introducing Technology

Summary

  1. The choice and use of technologies is always a balance between present and future. We use tools because they help us reduce costs and increase quality, but before we can use a tool, we must learn to use it. The learning takes us through the Satir Change Model, increasing costs and exposing us to serious mistakes. By improving our management of the process of introducing tools, we can lower the costs and reduce these mistakes.
  2. To change tool use, we need to change the culture, not vice-versa. A good way to start changing tool use is to conduct a tool survey to discover what people are doing with the tools they have. Usually, the survey shows that what is needed is not more tools, but management guidance to get more benefit from the tools we acquired.
  3. People in an organization use the tools they have (or don't use them) in ways that are characteristic of their organization's cultural processes, and particularly its management style, which determines
    • what tools they choose
    • how they obtain them
    • how they socialize tools
    • how they use them
  4. Oblivious organizations make little use of tools. Variable organizations often use tools quite well, but generally on an individual basis. Routine organizations often use tools more broadly than Pattern 1 organizations, but the use of these tools is both shallow and reluctant.
  5. Receptor groups identify and evaluate technological opportunities. They ask, "How can I take technology and apply it to how I do business?" These groups understand technology and their organizations, so they make the match between a general technology and a specific context.
  6. Steering organizations use tools cautiously, but rather well, on the whole, though often without an overall plan or coordination. Anticipating organizations use tools vigorously, but always with a result in mind. They almost always have a specially trained receptor group that proactively searches for generally useful tools, as well as tools to address specific process problems. Because tools are socialized by trained change artists, individuals who need tools, get tools and use them well.
  7. The First Law of Technology Transfer says that long-range good tends to be sacrificed to short-range good. The battle cries of the First Law are all too familiar:
    • We don't have time to do it right… .
    • We can't spare him right now… .
    • We'll assign her one-eighth time to the task… .
    • We'll do it in our spare time… .
  8. The Second Law of Technology Transfer says that short-range feasibility tends to be sacrificed to long-range perfection. The battle cries of the Second Law are also well known:
    • It's not part of the plan… .
    • We'll set up a task force… .
    • It's not the elegant way… .
    • We need to study the implications… .
  9. When you hear the NT Visionaries arguing over the perfect tool to solve your problems, step in and find something useful and specific for them to do. Don't let them evade crises by irrelevant tool building, though when the crisis is over, they can become your best tool designers.
  10. Even the organization in Chaos has all the tools it needs, though most people don't know about them. Work first under the hypothesis that your tool problem is not one of manufacturing, but of distribution.
  11. Use a dual strategy to beat the two Laws of Technology Transfer: Find the long-term solution while using a short-term solution to relieve the pressure.
  12. The Ten Commandments of Technology Transfer form a useful mnemonic guide to avoiding the sins of technology transfer:
    • Thou shalt have a plan to lead thee out of the wilderness.
    • Thou shalt not worship thy plan.
    • Thou shalt ask for no person in vain.
    • Thou shalt not work seven days a week.
    • Thou shalt honor thy users and listen to them.
    • Thou shalt not kill support for change.
    • Thou shalt not adulterate the work.
    • Thou shalt not steal resources from the work.
    • Thou shalt not bear false witness against thy plan.
    • Thou shalt not covet thy neighbor's optimal technology.
  13. The power of the Ten Commandments is magnified if you remember the Helpful Model:
    • No matter how it looks, everyone is trying to be helpful.
    • If you forget this commandment, you will begin to counter so-called resistance, which will engender real resistance—not to the technology, but to your anti-resistance efforts.
  14. Listen for the real information present in all resistance, so that you can use this information to correct your mistakes and enlist everybody's participation in changing your organization.

Epilogue

.