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

.