QSM: Volume 4.2: CHANGE: Planned & Unplanned

Part I. 미래 조직을 위해 계획하기 (Planning for the Future Organization)

Chapter 1. 메타-계획하기: Part I. 정보 (Meta-Planning: Part I. Information)

Summary

1. 변화 예술가들은 세 가지 다른 시간 척도와 세 가지 다른 기술을 포함하는 세 가지 레벨에서 그들의 기술을 연습한다. "소규모의" 변화 예술성은 사람과 문제를 직접 대면하고 일상적으로 다룬다 - 우리가 전술(tatics)이라고 부르는 수준이다. 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. "큰 규모에서의" 변화 예술성은 우리가 전략적 플래닝이라고 부르는 것이다: 전술적(tactical) 계획이 이루어지는 풍토를 설정하는 것이다. 전략적 플래닝은 일반적으로 3년에서 5년의 기간에 걸친 두 가지 광범위한 질문을 다룬다: 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), 계획 수립 시기, 장소, 방법, 그리고 누가 관여하는지 알기, 전술과 전략의 차이를 이해하기 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. 메타-계획하기: Part II. 시스템 사고 (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. 복잡할 필요는 없지만 모든 계획자가 공통적으로 접근해야 하는 접근방법에 대해 계획단이 합의할 필요가 있다. 하나의 간단한 4단계 접근법은 다음과 같다: 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. 계획된 변화는 A지점(인식 상태)에서 B지점(원하는 상태)으로 시스템을 가져가는 것이다. 포인트 A와 B는 명시적이든 암시적이든 전략 계획에 의해 제공된다. 이러한 변화는 다음 작업을 통해 달성될 수 있다: 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

   • A의 인식 the perceptions of A

   • B에 대한 욕망 the desires for B

   • A 또는 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

   2. (2)의 정보에 비추어 정지 여부를 확인한다. 그렇지 않을 경우 새로운 목표를 설정하고 (1)을 반복한다. In the light of the information from (2), check whether you want to stop. If not, set new goals and repeat (1).

7. 메타 변화에 대한 Satir의 설명에 따르면, 관련자들이 일치된 상태를 유지하는 시간이 흐를수록 변화는 더 쉬워져 self, other, context 사이의 균형을 유지하게 된다. 따라서 각 계획 수립 주기 동안 처음부터 끝까지 세 가지를 모두 모니터링해야 한다. 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. 리스크 평가는 리스크 관리가 아니라 첫 단계일 뿐이다. 두 번째 단계는 예측 불가능한 환경에도 불구하고 예측 가능한 결과를 얻기 위한 계획인 위험 완화 계획이다. 플라스틱 모델, MOI 모델 및 인간 감정성 모델을 사용하여 가능한 한 프로젝트 관리 하에 위험을 배치할 단계를 계획할 수 있다. 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. 예상하는(패턴4), 그리고 일치적인(패턴5) 조직은 진정한 엔지니어링 조직으로, 그 안에 있는 사람들이 엔지니어링 용어로 일관되게 생각하기 때문이다. 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. Boehm에 따르면, 소프트웨어 비용은 시스템의 크기와 복잡성, 사람 요인, 사용하는 도구, 특히 관리 부실에 의해 영향을 받는다. 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.

8. 프로세스 다이어그램은 각 상자의 작업이 실제로 이루어졌는지를 알려주는 측정을 기술하지 않으면 무의미하고 위험하다. 측정가능성 원칙은 다음과 같이 말한다, 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.

9. 소프트웨어 엔지니어링의 0순위 법칙에 따르면, 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.

10. 제품 원칙은, 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.