1.1.19. PERSPECTIVE AND B —B ERNARDO BELLOTTO file232 BACKGROUND/INTRODUCTION/THE STRUCTURE OF THE...

228

BACKGROUND/INTRODUCTION

1.1.19. PERSPECTIVE AND BALANCE —BERNARDO BELLOTTO

231

1. BACKGROUND

1.1. INTRODUCTION

1.1.20. THE STRUCTURE OF

THE ENGINEERING

PROCESS

232

BACKGROUND/INTRODUCTION/THE STRUCTURE OF THE ENGINEERING PROCESS

1.1.20.1. OVERVIEW OF THE SYSTEM LIFE CYCLE

The engineering process is framework andphilosophy underpinned by fundamentals ofteamwork, communication, and application.The systems approach and the scientific methodare the heart of the philosophy of the engineer-ing process. In engineering we apply theengineering process to an application system.The framework of the process fits within thefive categories of functions of Module 1.1.11.7.as shown in Figure 1.1.11.7. The completeframework includes the functions and stepsfor using the tools and guides. This well-known framework reflects the scientific methodand has been shown in any number of forms.

A system life cycle is a means of organizingthe thousands of individual, interrelated tasksto be completed in the building and imple-menting of any management tool. Also, thelife cycle provides a means for control—tomake sure tool development remains withincost and time constraints, that the tool is ofhigh quality, and most important, that theresulting tool meet the user’s needs.

Figures 1.1.20.1.1.a. and 1.1.20.1.1.b. show adetailed diagram of the framework of the engi-neering process, known as the system lifecycle. To be consistent with the literature, Imight call the system life cycle the systemdevelopment life cycle. I choose system lifecycle to emphasize the need to include the non-development functions. However, you couldargue that, generally speaking, developmentas a broad term includes even disposal. Thesefigures provide a process-oriented view of theengineering process. The diagram is longenough to require two figures to hold the entirecycle of functions. The system life cycle and

the engineering process are cyclic and recur-sive, centering on the design function(s), whichin itself is a process as we saw in Figure1.1.11.6.

The categories of functions from the frame-work shown in Figure 1.1.11.7. are carriedover into Figures 1.1.20.1.1.a. and 1.1.20.1.1.b.through the dotted lines. The 22 engineering-process functions are shown as rounded rect-angles. These functions are generic, appli-cable to any engineering activity. The resultsof conducting the engineering process func-tions for building and using a managementtool are shown in the figure on the arrowsleaving each function.

To show the engineering process frameworkcomprehensively, I’ve shown more formalresults typical of a large effort and a complexmanagement tool. For smaller efforts andsimpler tools, some results could be informalcommunications. I’ve also shown severalplayers in the user role. These players could bethe same person for a simple situation. Themanager plays the decision-making role.

Figures 1.1.20.1.2.a. and 1.1.20.1.2.b. providethe legend for the players shown as rectanglesin the management process structure and forthe destinations (shown in the diagram asnumbers in circles) of the results of conductingsome of the functions. The numbers in circlesshow connections. Some of the connectionsare user and builder input. Some results offunctions flow directly to other functions anddon’t need connections. The results are iden-tified as information documents. Many of thefunctions in the engineering process will yield

The system life cycle represents the framework of the engineering process, includ-ing the 22 functions and their results.

233

hardware, software, and other more-equip-ment-oriented results. However, the informa-tion documents overlay whatever type of re-sult comes from the functions and thereforemake consistent surrogates for results of all thefunctions.

I’ll dedicate a significant portion of this bookto the 22 engineering process functions as Iwill the five building-tool functions and thenine using-tool functions of the managementprocess. I’ll orient my discussions of all func-tions toward management tools in the contextof the other two components in the manage-ment system. I’m looking at the ManagementSystem Model from the perspective I calledinformation-oriented performance in Module

1.1.18.7.

Figure 1.1.20.1.3. shows a control-orientedview of the framework for the engineeringprocess. The control-oriented view focuses onthe manager shown as the left-hand rectangleat the top of the process-oriented view diagramin Figures 1.1.20.1.1.a. and 1.1.20.1.1.b. I’veshown each of the functions in the flow of theengineering process framework; and I’ve iden-tified each information input to the manager inFigures 1.1.20.1.1.a. and 1.1.20.1.1.b. as thesame circled numbers from those figures. Thediamonds represent decisions. The flow of thefigure doesn’t include the negative side of thedecisions. I only want to show the informationand decision linkages.

234

Figure 1.1.20.1.1.a. In a process-oriented view of the system life cycle applied to building andusing a management tool, we emphasize the information outputs from the functions. (Part 1)

9

Concept of Operations

Conceptual Design

Hardware Study

Physical Configuration

12

11

Structured Analysis

Structured Specifications • DFD • Data Dictionary • Portrayal Formats • Physical/Logical Descriptions • Strategic Plan for Storing and Collecting Data

Investigation

410

Detailed ProjectManagement Charts,

Including Budget

Feasibility Document(Focus on tool requirements and on constraints in light of scope

and work process.)7

Survey

Project Scope(e.g., scoping agreement -

emphasize page 1)

AN

ALY

SIS

USER

Workflow Charts

and Indicators

Tool Requirements (Expectations)

3

54

Updated ScopingAgeement (emphasize

page 2)

6

BuilderWorker

Request Work Process Steps and Indicators

Existing Management Tool

Description

Technological Constraints

9

1

2

DE

SIG

N

Tool Mission and Vision

Policy/Institutional Constraints

2

1

FO

LLO

W T

HR

OU

GH

Documentation

Project Plan, Status and

Progress Reports

8

Manager

8 10 13 15 1776

3

24

28

34 Operator

13 21 24 27828

3

6

7

Information Requirements

Management Tool Operating Requirements

Project Management

10 173 27 3031

32

2

11

32

33

29

26 29

3, 4, 5, 10, 13, 14, 15, 17, 18, 19, 20, 21, 24, 25, 26, 27, 28, 29, 30, 31,

32, 33, 34

235

Figure 1.1.20.1.1.b. In a process-oriented view of the system life cycle applied to building andusing a management tool, we emphasize the information outputs from the functions. (Part 2)

Retired Tool

Justification

Modified Tool Characteristics

Re-enter Cycle at Appropriate Step

FO

LLO

W-U

P

Corrective Action

Tool Performance

History Operating Characteristics and

Problem List

Installation Record

Training Certification

User's Manual

Converted Support Systems

(e.g., database and interface specifications)

Differences in Tool

Operation

Demonstrated Performance

Features

Acceptance Certification

Obsolescence and

ReplacementUpgrade

Maintenance

Installation

Training

Conversion(From Old Tool)

Testing

Integrated Tool Performance

Characteristics

32

31

Operation

30

28

27

22

22

Procedure Description

Training Documents

2524

23

16

2

IMP

LEM

EN

TAT

ION

DE

SIG

N

FO

LLO

W T

HR

OU

GH

Test Plan

19

Final Design Specifications

18

Acceptance and Evaluation Bases

15

16Detailed

Cost/Benefit Analysis

Success Factors and Evaluation

Criteria

4

GeneralDesign

PrototypeResults

Preliminary Design

Specifications

Development and Installation

Plan

13

Detailed(Structured)

Design

14

Physical Configuration

Structured Specifications

Concept of Operations



Clean-up, Restoration, and

Remediation

Statement of Impactand Status of ToolEnvironment and

Purpose33

34 END OF TOOL LIFE

20 21

23

17

Construction(Implementation)

12

Evaluation

26

29

2712

PerformanceVerification

236

LEGEND

Manager: The person who needs the information from the management tool to make decisions(who manages)

Operator: The people who convert data to information using the management tool (They operatethe tool and bridge data and information.)

Worker: The people who produce the product or service that generates the indicators to bemeasured to yield data for input to the management tool (These people are a key partof what is managed.)

User: All those who depend on the management tool to convert data to information in agiven domain of responsibility—the manager, the operator, and the worker, collec-tively

Builder: The people who design, develop, and install the management tool (responsible forwhat is used to manage)

Note: Sometimes, the worker and the operator are the same person. Sometimes, the operator andthe manager are the same person. Sometimes, the operator and the builder are the same person.The builder must suit the operator and the manager. If the tool isn’t workable for the operator, thetool will fail. If the tool doesn’t generate the right information for the manager, the tool will fail.

1. Operator and Worker together determine existing management tool description

2. Existing management tool description from Worker and from Operator to Hardware Study,to Conceptual Design, and to Conversion

3. Project scope from Survey to Manager, to Operator, to Documentation, and to ProjectManagement

4. Tool requirements from Survey to Structured Analysis, to Acceptance and Evaluation Bases,and to Documentation

5. Workflow charts and indicators from Survey to Documentation

6. Updated scoping agreement from Investigation to Manager

7. Feasibility document from Investigation to Manager and to Operator

8. Status and Progress Reports from Project Management to Manager and to Operator

9. All documents in Documentation from Documentation to Builder

10. Detailed project management charts, including budget from Structured Analysis to ProjectManagement, to Documentation, and to Manager

11. Concept of Operations from Conceptual Design to Hardware Study

12. Physical Configuration from Hardware Study to Construction and to Evaluation

Figure 1.1.20.1.2.a. A legend for information outputs helps us easily follow the connections inthe process-oriented view of the system life cycle. (Part 1)

237

13. Development and installation plan from General Design to Documentation, to Manager, andto Operator

14 Prototype results from General Design to Documentation

15. Success factors and evaluation criteria from Acceptance and Evaluation Bases toDocumentation and to Manager

16. Success factors and evaluation criteria from Acceptance and Evaluation Bases to Testing

17. Detailed cost/benefit analysis from Detailed Design to Project Management, toDocumentation, and to Manager

18. Final design specifications from Detailed Design to Documentation

19. Test plan from Detailed Design to Documentation

20. Training documents from Procedure Description to Documentation

21. User’s manual from Procedure Description to Documentation and to Operator

22. Differences in tool operation from Conversion to Training

23. Demonstrated performance features from Testing to Procedure Description

24. Demonstrated performance features from Testing to Documentation, to Manager, and toOperator

25. Acceptance certification from Testing to Documentation

26. Training certification from Training to Documentation and to Operator

27. Installation record from Installation to Documentation, to Operator, to ProjectManagement, and to Evaluation

28. Operating characteristics and problem list from Operation to Documentation, to Manager, andto Operator

29. Performance verification from Evaluation to Documentation, to Operator, and to Builder

30. Tool performance history from Operation to Documentation and to Project Management

31. Corrective action from Maintenance to Documentation, to Operator, and to ProjectManagement

32. Modified tool characteristics from Upgrade to Documentation, to Operator, and to ProjectManagement

33. Retired tool justification from Obsolescence and Replacement to Documentation and toOperator

34. Statement of impact and status of tool environment and purpose from Obsolescence andReplacement to Documentation and to Manager

Figure 1.1.20.1.2.b. A legend for information outputs helps us easily follow the connections inthe process-oriented view of the system life cycle. (Part 2)

238

Figure 1.1.20.1.3. In a control-oriented view of the system life cycle, we emphasize the decisionsthe manager makes in building and using a management tool.

Agreewith

feasibility?

Acceptupdated scoping

agreement?

Acceptscoping

agreement?

Approvedevelopment andinstallation plan

?

Survey

Investigation

Installation

Operation

Acceptdetailed project management

charts including budget

?

StructuredAnalysis

HardwareStudy

ConceptualDesign

General Design

Acceptance andEvaluation Bases

DetailedDesign

ProcedureDescription Construction

Conversion Testing

Satisfiedwith

demonstratedperformance

features?

Training

Maintenance

Upgrade

Re-entercycle at

appropriatestep

6 7

10

13

Yes

Yes

15 17

YesYes

YesYes

Yes

Yes

Yes

24

3

Acceptcost/benefit

analysis?

Agreewith success

factors?

To Documentation

DocumentationDocumentation

Project Management

Project Management

Project status and

progress OK?

Re-entercycle at

appropriatestep

8

Re-entercycle at

appropriatestep

Project status and

progress OK?

8

End ofTool Life

Obsolescenceand

Replacement

Clean-up, Restoration, and

Remediation

Recognizeneed for

improvement?

Needfor another

means?

Yes

28

34

Evaluation

Evaluation

240


1.1.20.2. APPLYING THE SYSTEM LIFE CYCLE FUNCTIONSWITHIN THE

ENGINEERING PROCESS

Typically, engineers learn those laws of naturethat apply to a particular type of machine; e.g.,mechanical machines, electrical machines,chemical machines, machines for mining,machines for aerospace, and so on. I use theword machine in a general sense. A machinecan be a chemical processing plant, an evapo-rator, or a wrench.

For management systems engineering, ourmachines look less like machines yet they actaccording to the laws of nature like their moretangible counterparts. The machines of man-agement systems engineering are organiza-tions, management tools in a closed set, anindividual management tool like a manage-ment information system or an organizationchart, the work process, a stage in the workprocess, and many more. We can even analyzethe who manages component of the Manage-ment System Model like a controller in anelectrical or mechanical servomechanism.

Each of these machines are systems and sub-systems, depending on our unit of interest, orin management system terms, domain of re-sponsibility. We apply the functions of thesystem life cycle to any of these machines, orsystems. We apply the functions to the pro-cessing plant, the evaporator, the wrench, theorganization, the management informationsystem, the work process, and more—even themanager. In the engineering process, when weapply the functions, we must use the systemsapproach by understanding the system, thelaws of nature behind that system, and the aimof the system.

The structure of the system life cycle is thebody, or skeleton and muscles, of the process;applicable laws of nature are the brain; theapplication is the heart; and the systems ap-proach is the soul. They work together to givethe engineering process intelligent life. How’sthat for practicing the generalist perspectiveand transferring concepts from one disciplineto another?

The structure of the engineering process, thesystem life cycle, is the easiest part of theengineering process to lay out, pull apart, andstudy in detail. We can and will study thefunctions of the engineering process and thetools and skills you need to do the engineeringprocess functions well.

Shortly, I’ll describe the management processwith its structure and philosophy. We can andwill study the functions of the managementprocess and the tools and skills you need to dothe management process functions well.

We can’t combine the engineering process andthe management process functions into a grandstructure like we can’t combine the engineer-ing process and the chemical process func-tions into a grand structure to diagram in afigure. However, we do blend the processestogether with their structures and philosophieslike we blend yellow and blue to get green.The result of blending the engineering andmanagement processes together gives differ-ent shades of the blend depending on ourobjective.

The system life cycle integrates with the laws of nature, the application, and the systemsapproach to bring the engineering process to life.

242


1.1.20.3. ORIGINS OF THE SYSTEM LIFE CYCLE FUNCTIONS

When I came to Virginia Tech in the summerof 1974, I discovered the almost-deliberateignoring of the nuclear-fuel life cycle by thenuclear engineering community. The wordsfuel cycle meant how to shuffle fuel in anuclear reactor during periodic refuelings. Ihad never been taught in school or industry,and the discipline had been put on the backburner, the cradle-to-grave fuel cycle startingfrom the raw uranium ore in the ground to theultimate disposal of nuclear waste and theremediation and restoration of the environ-ment affected by converting the fuel into waste.Joel Nachlas (of the Industrial EngineeringDepartment) and I (of the Nuclear Engineer-ing Program) found we could combine under-standings of nuclear and industrial engineer-ing in better management of the nuclear fuelcycle. We team-taught a course on the subject.By May 1977, we had a research contract tostudy management of the nuclear fuel cycle.That research contract evolved over the yearsinto what was to become in 1981 the Manage-ment Systems Laboratories.

I wasn’t taught about life cycles in civil engi-neering or in nuclear engineering. I was nevertaught the framework for the engineering pro-cess. Engineers must learn and practice thelife cycle whether they’re building (analysis,design, implementation, etc.) automobiles,bridges, computers, nuclear reactors, or orga-nizations. When we talk about green engi-neering today, we’re invoking the system de-velopment life cycle. Green engineering re-quires a cyclic, recursive, reversible process.Green engineering requires the rudiments ofmanagement systems engineering.

I first recognized the system life cycle for whatit was in the spring and summer of 1984 whenI worked on the two-day workshop on officeautomation for information systems designersand manager-users in the United States De-partment of Energy Senior Executive Service.I had to speak to managing the life cycle forinformation systems. Hardware and softwaretypically had very short (and ever shortening)life spans. Organizations were looking atreplacing or upgrading their hardware andsoftware on an 18-month cycle. Now, there’sa life cycle we can get our arms around—quitedifferent from a 50-year life cycle for a bridgeor a nuclear facility. We couldn’t practiceNIMPL (Not In My Professional Lifetime—taken from NIMBY and NIMTO, popularlyknown as Not In My Back Yard and Not In MyTerm of Office) on computer projects.

I discovered a book by Edward Yourdon calledManaging the System Life Cycle (YourdonPress, 1982). He says, “Recently, however,the approach taken to systems developmenthas begun to change. More and more large andsmall organizations are adopting a single, uni-form project life cycle—otherwise known as aproject plan or systems development method-ology, or simply, ‘the way we do things.’Usually contained in a notebook as ponderousas the standards manual that sits (unread) onevery programmer’s desk, the documentedproject life cycle provides a common way foreveryone in the EDP [Electronic Data Pro-cessing] organization to go about the businessof developing a computer system. ..... Threeobvious objectives may be discerned from thecomments above: One purpose of the project

The system life cycle functions come primarily from the project management lifecycle and, more specifically, the computer information system life cycle, thus aimingthe functions toward the building of management tools.

243

life cycle is to define the activities that must becarried out in an EDP project. A second is tointroduce consistency among the many EDPprojects in an organization. A third objectiveis to provide checkpoints for managementcontrol and checkpoints for go/no-go deci-sions.” (p. 36.)

Yourdon describes weaknesses in what hecalls the classical project life cycle and offershis version of a structured life cycle.

He says, “The use of bottom-up implementa-tion is, in my opinion, one of the major weak-nesses in the classical project life cycle. [The]project manager is expected to carry out all ofhis module testing first, then subsystem test-ing, and finally system testing. I’m not quitesure where this approach originally came from,but I wouldn’t be surprised if it was borrowedfrom assembly-line industries. The bottom-upimplementation approach is a good one forassembling automobiles on an assembly line—but only after the prototype model has beenthoroughly debugged! Unfortunately, most ofus in the computer field are still producingone-of-a-kind systems, for which the bottom-up approach has a number of serious difficul-ties ..... The second major weakness with theclassical project life cycle is its insistence thatthe phases proceed sequentially from one tothe next. There is a natural, human tendency towant this to be so: We want to be able to saythat we have finished the analysis phase andthat we’ll never have to worry about that phaseagain. Indeed, many organizations formalizethis notion with a ritual known as ‘freezing thespecification’ or ‘freezing the design docu-ment.’” (pp. 39-40.)

I’ve reproduced Yourdon’s figure for the struc-tured project life cycle as Figure 1.1.20.3.1.You can see the heavy branching among hisactivities implying recursive, reversible se-quencing. The cyclic nature of the process isimplied in its title—life cycle.

Perhaps computer systems people were theright ones to introduce me to the system devel-opment life cycle because they seem to elevatethe idea of a system, and for some of thosepeople (like Weinberg), the idea of generalsystems thinking to a prominent level.

Yourdon’s comments clue us into the idea thatlife cycles are things project managers knowabout. Harold Kerzner addresses life cycles inhis book Project Management: A SystemsApproach to Planning, Scheduling, and Con-trolling (Van Nostrand Reinhold, 1984). “Ev-ery program, project, or product has certainphases of development. A clear understandingof these phases permits managers and execu-tives to better control total corporate resourcesin the achievement of desired goals. Thephases of development are known as life-cyclephases. However, the breakdown and termi-nology of these phases differ, depending uponwhether we are discussing products or projects.

During the past few years, there has been atleast partial agreement about the life-cyclephases of a product. They include:

• Research and development• Market introduction• Growth• Maturity• Deterioration• Death

Today, there is no agreement among indus-tries, or even companies within the same in-dustry, about the life-cycle phases of a project.This is understandable because of the complexnature and diversity of projects.” (p. 71.)

I’ll address the difference in programs, projects,and products later in a framework I call pur-suits, which includes perplexities, problems,programs, projects, and processes. I’ll arguethat the system life cycle fits in whole or in partto each of these pursuits. Kerzner reaffirms at

244

least the last three pursuits and the life cycle.

To me, the life-cycle phases, or steps, or func-tions are consistent from project to project orfrom projects to processes to programs whenyou step back far enough to see the functionsgenerically. Then the functions fit the industryor pursuit as they are specified to address theunique characteristics of their application.

I’ve reproduced Kerzner’s table of project lifecycle phase definitions for different industriesas Figure 1.1.20.3.2. To me, each industrygroup exhibits the same life cycle flow for theproject, except each group reflects the termi-nology or emphasis of that industry.

The theoretical definitions of the life-cyclephases of a system development are applied toprojects by Cleland and King in their ProjectManagement Handbook. They say, “Newproducts, services, or roles for the organiza-tion have their genesis in ideas evolving withinthe organization. Typically, such ‘systems’ideas go through a distinct life cycle, i.e., anatural and pervasive order of thought andaction. In each phase of this cycle, differentlevels and varieties of specific thought andaction are required within the organization toassess the efficacy of the system. The ‘phases’of this cycle serve to illustrate the systemsdevelopment life-cycle concept and impor-tance.” (pp. 210-211.)

Cleland and King list and describe the life-cycle phases as the conceptual, definition,production or acquisition, operational, anddivestment phases. They continue, “Takentogether [the details of the phases] provide adetailed outline of the overall systems devel-opment life cycle. Of course, the terminology[used] is not applicable to every system whichmight be under development, since the termi-nology generally applied to the developmentof consumer product systems is often differentfrom that applied to weapons systems. Both,

in turn, are different from that used in thedevelopment of a financial system for a busi-ness firm. However, whatever the terminol-ogy used, the concepts are applicable to allsuch systems. ..... Life cycle management re-fers to the management of systems, productsor projects throughout their life cycle. In thecontext of the sales life cycle, life cycle man-agement is usually called ‘product manage-ment.’ In the development life cycle, it isusually called ‘project management.’ In allcases, life cycle management is needed be-cause the life cycle reflects very different man-agement requirements at its various stages.”(p. 214.)

Starting in 1986, I used the book ComputerInformation Systems Development: Analysisand Design by Powers, Adams, and Mills(South-Western Publishing Co, 1984) in myundergraduate class on information systems.The authors emphasize the life cycle and say,“A systems development life cycle provides amethodology, or an organized process, thatcan be followed in developing any CIS [Com-puter Information System]. Emphasis is onorganization. In developing a CIS, thousandsof separate, individual tasks must be com-pleted. Some of these must be performed in acertain given order. Many people are in-volved. Their efforts must be coordinated. Byorganizing all of these efforts, the systemsdevelopment life cycle fulfills its main pur-pose: It provides a basis for control.

Any systems development effort will be toolarge to proceed without control. The controlsneeded are in the areas of:

• Functions• Budgets• Schedules• Quality

To make sure that a system is being developedwith the proper and necessary functions, within

245

budget, on schedule, and up to quality expec-tations, a number of checkpoints are needed.These checkpoints are important for assuringthat work is reviewed and decisions are madeon a timely, organized basis. In other words,checkpoints hold the key to control in systemsdevelopment.” (pp. 40-41.)

The functions of Powers, Adams, and Millsare functions of the system, while my func-tions are functions of the system life cycle.

The idea of checkpoints in the system lifecycle stimulated the idea of the control-ori-ented life cycle diagram in Figure 1.1.20.1.3.and the decision points shown in that diagram.

Finally, recall the discussion of Blanchard andFabrycky’s life cycle functions in Module1.1.11.7. Those functions included systemplanning, system research, system design, pro-duction and/or construction, system evalua-tion, and system use and logistic support.

Figure 1.1.20.3.1. The structured project life cycle reflects some computer system terminology butcan be applied generally to all systems. (taken from Yourdon)

5.ACCEPTANCE

TESTGENER-ATION

9.INSTAL-LATION

2.ANALYSIS

8.DATABASE

CONVERSION

7.PROCEDURE

DESCRIP.

3.DESIGN

1.SURVEY

MANAGE-MENT

4.IMPLEMEN-

TATION

6.QUALITY

ASSURANCE

USERS OPER-ATIONS

SYSTEMREQUIRE-

MENTS USERPOLICY

OPERATIONALRESTRIC-

TIONS

EXISTINGDATABASE

USER MANUAL

CONVERTEDDATABASE

DESIGN SPECIFICATION

INSTALLED SYSTEM

ACCEPTEDSYSTEM

INTEGRATED SYSTEM

QUALITYASSURANCETESTSET

STRUCTUREDSPECIFICATION

COST/BENEFITREPORT

CONSTRAINTS

PROJECTCHARTER

TENTATIVECOST/BENEFITREPORT

CON-STRAINTS

246

Figure 1.1.20.3.2. The project life cycle phase definitions for several industries show a consistentflow among the phases and reflect the functions of the system development life cycle in Module1.1.20.1. (taken from Kerzner)

ENGINEERING MANUFACTURING COMPUTER PROGRAMMING CONSTRUCTION

• Startup• Definition• Main• Termination

• Formation• Buildup• Production• Phase-out• Final audit

• Conceptual• Planning• Definition and design• Implementation• Conversion

• Planning, datagathering andprocedures

• Studies and basicengineering

• Major review• Detail engineering• Detail engineering/

constructionoverlap

• Construction• Testing and

commissioning

248


1.1.20.4. ORGANIZATIONAL LIFE CYCLES

We’ve looked at the system life cycle, which isdiscussed most in terms of information tech-nology or project management. But, we knowproducts have life cycles too. (Consider buggywhips.) If we consider the Studebaker car (orthe Packard or many others), we realize com-panies have life cycles. Some corporate lifecycles are short (80% of new companies lastless than two years—either due toundercapitalization or to lack of commitmenton the part of the founder.) and other life cyclesare long. Within corporations, groups (do-mains of responsibility) are forever being re-organized or terminated, having life cycles oftheir own.

The problem with some of the life cycles I’vejust described is that they’re once-through.The corporation is born, grows, ages, and dies.Sometimes the corporation doesn’t do muchgrowing and aging, just birthing and dying.Where’s the iteration that makes life cycles sopowerful? That’s the point. Successful corpo-rations, or organizations, do iterate throughthe life cycle. When they reach their prime,they find ways for rebirth and continue throughanother cycle. (This stage is where you wantto do business process re-engineering, notwhen the organization is in its death-throes.)Since we don’t know exactly when we’vereached our prime and when exactly to con-fuse the success with renewal and rebirth, weoften undershoot or overshoot a bit.

How many organizations last in their originalform (not merged or otherwise significantlychanged) more than a decade—at least thosenot mandated (as in some government organi-zations). We each can identify a government

organization that has outlived its usefulnessand would be dead in an open marketplace.Not many organizations last long, and we needto know what happens to shorten their lifecycle and what to do the lengthen the life cyclein healthy ways (not by mandate).

Adizes has made his career out of understand-ing and intervening in organizational life cycles.When he discusses the life cycles of organiza-tions, he looks at the life cycles of building anairplane (a project) and a marriage in parallelwith the life cycle of the organization. He talksof growth and aging in the corporation just aswe would in describing the life cycle of aperson. One of his most interesting parallelsbetween people and organizations is his dis-cussion of the idea that size and time aren’tcauses of growth and aging. He says, “Grow-ing means the ability to deal with bigger, morecomplex problems. The function of leader-ship, then, is to manage the organization insuch a way that it is able to move to the next,more demanding stage of the Lifecycle. ....You can tell the ‘size’ of a person by the ‘size’of the problems that preoccupy him. Smallpeople spend their lives worrying about smallproblems: what the neighbor did or did not do,who wears what makeup or drives what car.Big people worry about big problems, thosewhich are more complex to analyze and diffi-cult to resolve. They seek insight about theirown lives—about the nature of the environ-ment, the quality of life, the political system,the education of their children, and the nextgeneration. A person must grow out of smallproblems to free up the energy to deal withbigger problems. That is the process of grow-ing and maturing. The same applies to organi-

Organizations go through life cycles too, and we can use our understanding of theorganizational life cycle to determine the right intervention to use during aparticular stage of the organization’s growth and aging stages.

249

jagged lines in Figure 1.1.20.4. are for painful,intense, transition stages. Notice how on thegrowth side a painful transition is needed to getto the good times. If the organization survivesthe adolescence stage, it gets to the prime stage,the optimum point on the life cycle where theorganization is able to balance flexibility andcontrollability.

The stable stage is the first of the aging stagesof the life cycle. The organization is strong butis starting to lose its flexibility. When at thisstage, we have the greatest chance for a suc-cessful renewal and rejuvenation. The organi-zation is strong and can support the neededinward scrutiny for renewal. If the organiza-tion can’t or won’t change and renew itself, thestages of aristocracy, early bureaucracy, bu-reaucracy, and finally death follow. As theorganization moves into the later stages ofaging, an interesting dilemma occurs. First, theorganization faces clearer and more significantthreats. To be motivated to go through thegreat pain and effort of change in culture, youneed to face a threat to your survival or youneed very strong leadership, preferably both.Second, the organization isn’t as strong as itonce was and has trouble devoting the re-sources to the inward effort of changing cul-ture.

Compare Adizes’ life cycle to the stages of thesystem life cycle. After all, the organization isa system. We do analysis during the courtshipand infant stages. We do design during theinfant and go-go stages. We do implementa-tion during the go-go, adolescence, and primestages. After those stages, we’re into follow-up. We do follow-through throughout thestages. Just as a project can be terminated(early death) in early stages of the system lifecycle, an organization can die during the earlystages of the organizational life cycle. Thoseprojects that don’t get beyond the early stagesof the system life cycle and those companiesthat don’t get beyond the early stages of the

zations. .... Aging means there is a decreasingability to deal with problems. .... The purposeof management is to provide for balancedgrowth or rejuvenation and to bring the orga-nization to Prime [one of his stages of the lifecycle] and keep it there.” (pp. 3 - 4.)

In Module 1.1.20.1., I’ve implied that a cycleis a circle, which is correct. However, a cyclecan also look like a sine wave. That’s the formAdizes chooses in his book, CorporateLifecycles: How and Why Corporations Growand Die and What to Do about It. (PrenticeHall, 1988). Figure 1.1.20.4. is from Adizes’book. (p. 84.) This figure and Adizes’ analysisof the stages is another good diagnostic tool forunderstanding your domain of responsibility.Like the pursuits framework or the endeavorsframework, we can use Adizes’ life cyclediagram to understand what interventions, likemanagement tools, need to be used to be suc-cessful.

Consider Figure 1.1.20.4. The courtship stageoccurs before birth and is the first stage of theorganizational lifecycle. The organization ex-ists only as an idea in the courtship stage. Inthe courtship stage, we find the process ofbuilding commitment to the idea, which isaccompanied by excitement, enthusiasm, andemotion resulting in “‘heat,’ as if energy iscoalescing to one point to be released.” (p. 12.)Between courtship and infancy is birth. Birthoccurs when the commitment is successfullytested and risk is overridden. If the test ofcommitment fails, the idea was only an affairand the lifecycle is over. In infancy, manage-ment is often by crisis and when the infant dies,the causes are usually undercapitalization andfailure of the founder’s commitment. Thethird stage, the go-go stage, is euphoric. Theorganization can do no wrong, and the founderis always in charge and usually right.

In going to the adolescence stage, the organi-zation is reborn apart from its founder. The

250

organizational life cycle fail. Those that workthe increasingly complex and interesting prob-lems of the progressive stages of the life cycle

succeed. Those that do reappraisal and re-newal to iterate through the stages of the lifecycle find prolonged and progressive success.

Figure 1.1.20.4. The organization grows and ages through early stages of high flexibility and latestages of high controllability. At the prime stage the flexibility and controllability are balanced.(taken from Adizes, p. 84)

Stable

Prime

Adolescence

Go-Go

Infant

Courtship Affair

Infant Mortality

Founder or Family Trap

Unfulfilled Entrepreneur

PrematureAging

Divorce

Aristocracy

EarlyBureaucracy

Bureaucracy

Death

Growing Aging

252


1.1.20.5. A WORLD OF LIFE CYCLES

255

1. BACKGROUND

1.1. INTRODUCTION

1.1.21. BUILDING AND USING

MANAGEMENT TOOLS

256

BACKGROUND/INTRODUCTION/BUILDING AND USING MANAGEMENT TOOLS

1.1.21.1. ANALOGIES —RENE MAGRITTE

258


1.1.21.2. ANALYSIS AND SYNTHESIS ORIENTATIONS TO MANAGEMENT

TOOLS

What do you use to manage? Informationfrom a sophisticated computer system or a filecabinet and a rolodex? Information from anautomated manufacturing process line or aword processor? Corporate policy or operat-ing procedures? Optimization models or rulesof thumb? Expansive and fashionable ap-pointments and offices for people or a simpleoffice layout? You need to get the most fromthese management tools or you seem to getfurther behind in meeting the objectives ofyour responsibility. You had hoped your toolswould work better, didn’t you?

Our jobs are faster moving, more complex,always changing, requiring more and moreknowledgeable decisions. In such a dynamicenvironment we have to make sense of whatwe do and have our tools work for us and notagainst us. In this day of modern computingtools, we can empathize with the sad situationin Figure 1.1.16.9.—the data-rich, informa-tion-poor (DRIP) situation wherein the com-puter produces so much and helps so little.

The 1912 publication of Taylor’s The Prin-ciples of Scientific Management introduced anew approach to decision-making based onstructure. He was known for ideas founded onquantitative measurement, such as time andmotion studies and standardized industrialtools and procedures. Moreover, Taylorwanted managers to know not just that apractice does or does not work, but why andhow the practice works.

What does structure mean to us in our work?A science. A frame of reference. A handle to

hold onto to keep all our tools in order and tochoose the right one at the right time and haveit work because that tool, the operator (us), andthe operation to which we apply the tool allmatch and work well together.

Through a series of simple and integratedqualitative models, I structure what you man-age, your objectives for developing your man-agement tools (through automation, for ex-ample), procedures for developing your tools,and evaluation methods to gauge your successwith your tools. As a group, the modelsprovide an integrated method from beginningto end—from analyzing your situation to re-solving your needs.

Most of our tools don’t work well. I claim that70% of all management information systemsfail and the little argument I get with the claimis that the number may be low. When our toolsfail, we fail. The failure is largely due to aconfusion of ends and means—a confusionbetween what is managed and what is used tomanage—and due to a lack of understandingthe significance of the preferences of whomanages (our preferences)—a tendency to bendour needs to fit the tools rather than vice versa.

Focus on management tools and start with theManagement System Model (MSM). What dowe want the tools for? Ultimately to help indecision making—in management. So, thestarting point for building a tool is to knowwhat type of decision the tool will supportwithin the context of the domain of responsi-bility. Is the domain of responsibility a man-agement systems engineering course with

We use an analysis orientation for building management tools and a synthesis orienta-tion for using management tools all within the systems approach.

259

Harold the who manages and the decision howto grade midterms? Is the decision whichclassroom to use? Is the domain of responsi-bility Management Systems Laboratories? Theanswers to these kinds of questions aboutdomain and decision making starts the tool-building process. For goodness sake, don’tstart that process by saying, “Here’s a niftyhardware or software package; we ought to beable to work this in somewhere.”

By starting and focusing on the end use of thetool, we’re embarking on an analysis effortwithin the context of the systems approach.I’ll start with a function for scoping the domainand another function for identifying decisionsand related actions and use the MSM to directme through an analysis process for the build-ing-management-tool part of the managementprocess—a process I call management systemanalysis (discussed in Module 1.1.21.3.).Clearly, the functions of the building-manage-ment-tool part of the management processstructure and the functions of the engineeringprocess structure shown in Figures 1.1.20.1.1.a.and 1.1.20.1.1.b. work hand-in-hand. But theyaren’t the same. The engineering functions areanalysis, design, and implementation oriented.The management functions are decision, in-formation, and data oriented. Both start withscoping the situation.

When using management tools we start wherethe action is—in the work process by makingmeasurements to get data for the managementtools to convert into information. I’ll start withfunctions for setting expectations and survey-ing the work process and use the MSM todirect me through a synthesis process for theusing-management-tool part of the manage-ment process—a process I call managementsystem synthesis (discussed in Module1.1.21.5.). The measurements and data are the

most rudimentary components of the manage-ment system, and we synthesize them intoinformation for decision making.

The MSM directs and gives a sense to thecompleteness of the sets of functions and theirsequence. I use the MSM in a symbolic way soI can tie together the building-management-tool part of the management process structureand the using-management-tool part of themanagement process structure and the engi-neering process structure. The MSM has greatpower in directing the three sets of functions,but the MSM isn’t detailed enough and itreflects its closed-system nature. So I use theMSM as a rallying point or an icon whensorting out management system analysis andmanagement system synthesis functions.

We use management system analysis to get aproper analysis of the problem; and we usemanagement system synthesis to get a propersynthesis of the solution. However, the targetfor both management system analysis and man-agement system synthesis is data. When webuild a management tool, we want to find outthe necessary data and only the necessary datato provide information for decision making.When we use the management tool, we mustcollect the right data or the tool will fail.

The bottom line for management system analy-sis and management system synthesis and forthe engineering process is building and usingthe right tool for the right application. Figure1.1.21.2. illustrates a much-too-common situ-ation. The wrench in the figure may be a visualexample of tool failure. However, we try to dothe same sorts of things with managementtools. The job of the management systemsengineer is to make sure the manager has theright tool for the right job.

260

Figure 1.1.21.2. “This seems like an awfully hard way to do a simple thing.”

262


1.1.21.3. THE FIVE FUNCTIONS OF MANAGEMENT SYSTEM ANALYSIS

Management Systems Laboratories (MSL) ofVirginia Tech evolved management systemanalysis through the years 1982 to 1984 duringtheir work with government and industry re-search sponsors. MSL designed the analysisto help managers determine which manage-ment tools work best for them. The analysis isunique because of the role the human managerplays in the heavily structured approach. Theanalysis is based on the Management SystemModel (MSM).

People who study productivity and perfor-mance call the combination of decision andaction in the MSM an intervention. (See thedecision-to-action interface of the MSM inFigure 1.1.18.1.3.) An intervention includesboth a decision based on information about theproductivity or performance indicators andthe resulting action the manager takes to affectwhat he or she manages. Productivity andperformance people design interventions toimprove productivity and performance. Be-cause the analysis is oriented toward helpingthe manager, productivity and performancepeople have found MSL’s management sys-tem analysis equally valuable in finding theright interventions as MSL does in finding theright management tools. (Recall information-oriented performance and operational perfor-mance as two of the three perspectives for theMSM in Module 1.1.18.7.)

The manager can find the right managementtools either by selecting one already availableor building a new tool to suit the needs of thedomain of responsibility. This make-or-buydecision is crucial and evolves from manage-ment system analysis. The manager, of course,

is the user of the management tools and isresponsible for the interventions for produc-tivity improvement.

In its simplest form, management system analy-sis includes five steps:

1. Delimit the domain of responsibility andunderstand the operation, or work process,to ensure you know the problem beforestarting on a solution.

2. Determine the interventions (decision-ac-tion pair) needed to improve the operationor carry out the work process and themanager’s role in making the needed deci-sions.

3. Figure out what information best supportsthe decisions and which management-toolfeatures you need to get that information.

4. Deduce what data make up the neededinformation and what measurement meansare required to collect the data.

5. Determine the indicators highlighting theoperation’s working and outputs that themeasurements measure and the relation-ships among the identified indicators.

Figure 1.1.21.3. uses the MSM for directionand as a rallying point for the five managementsystem analysis functions. In the figure, Iinclude the MSM more as an icon than as theframework for management system analysis.You can see that the five functions of manage-ment system analysis fit comfortably aroundthe MSM. The MSM tells us we have a closed

The Management System Model points us to five functions for building managementtools, together making up management system analysis—the building-tool part ofthe management process.

263

set of functions for analysis by showing nogaps and overlaps in considering the compo-nents and interfaces of the MSM. Through theMSM, we have confidence that the foundationconcepts leading to the MSM are carried intomanagement system analysis. Just as the com-ponents and interfaces of the MSM are reallyintermingled and have been pulled apart forease of discussion, the management systemanalysis functions must work together withinthe systems approach. The cycle of the func-tions includes sequence but allows the neces-sary cyclic, recursive, reversible nature of themanagement system.

Figure 1.1.21.3. labels the five functions asCCW1, CCW2, and so on. CCW1 stands forthe first counter-clockwise function. Themanagement system synthesis functions go inthe other direction; so the labels distinguishbetween analysis and synthesis and indicatesequence.

The success of management system analysis isin taking the functions in the proper sequence.Notice how the functions of the analysis movecounter-clockwise sequentially around thecomponents and interfaces of the MSM. We

want to get to functions 3 and 4. But if we don’tdo functions 1 and 2 well and define decisionsand actions needed for the domain, our infor-mation efforts won’t work well. We musttightly relate functions 2 and 3. That is, wehave to key information to the decision theinformation serves. Function 5 completes theloop. We can’t measure the effect of interven-tions without function 5. In fact, we have aloop we must iteratively work to design, cause,and measure performance improvement.

After we use management system analysis toanalyze management tool selection or produc-tivity or performance improvement interven-tions, we use the management process to imple-ment what we’ve learned from the analysis.We use the measurements and log data for theindicators. We prepare the data for the man-agement information system and organize andpresent information. Then we review statusand progress toward productivity or perfor-mance goals and appraise the results. In imple-menting what we learn from management sys-tem analysis, I’ve just worked my way backclockwise around the MSM. Now, I’m doingmanagement system synthesis.

264

Figure 1.1.21.3. The five management system analysis functions for building management toolswork counter-clockwise around the Management System Model.

MANAGEMENT SYSTEM ANALYSIS(Functions for Building Management Tools)

DETERMINE DECISIONSAND ACTIONS

DELIMIT YOURDOMAIN

LISTMEASUREMENTS

FOR DATA

OUTLINE DATAFOR INFO

DEFINE INFOFOR DECISIONS

CCW1

CCW2

CCW3

CCW4

CCW5

WHAT

WHAT WITH

WHO

266


1.1.21.4. ORIGINS OF MANAGEMENT SYSTEM ANALYSIS

For most of a decade, Management SystemsLaboratories built management tools knowingyou had to start with the application and workyour way toward data—the nitty-gritty issuein any management tool. During the period1982 to 1984, the sequence of managementsystem analysis surfaced as an informal proce-dure for building tools.

In the spring and summer of 1984, we wereasked to present a two-day workshop on officeautomation for information systems designersand manager-users in the United States De-partment of Energy Senior Executive Service.We knew the needs of these managers weren’thow to use a spreadsheet package or a wordprocessing package. Rather the managersneeded to know what tools they needed andhow to make decisions to ensure they got theright tools. The managers were used to goingto a contractor and asking the contractor tobuild a tool for them. The tools they got wereuseless because they didn’t fit the operation orweren’t comfortable for the users.

In discussing information processing as anintegrating concept in organizational design,Tushman and Nadler say that their model’scentral hypothesis is that “...organizationaleffectiveness is indeed associated with the fitor match between the information processingrequirements facing an organization (and itssubunits) and the information processing ca-pacity of its structure.” They define fit as“Effectiveness is a function of matching infor-mation processing capabilities with informa-tion processing requirements.” (Michael L.Tushman and David A. Nadler, “InformationProcessing as an Integrating Concept in Orga-

nizational Design,” Academy of ManagementReview, July 1978, p. 622.)

In producing large information systems forwholesalers in 1973-1974, I discovered thekey to success was fit. We implemented thesame system in a large number of companies.When the fit of the system to the operation andthe decision makers was good, the systemhelped the company succeed. When the fitwas bad, the system helped the company fail.My experience, then, supports the Tushmanand Nadler hypothesis.

In the Senior Executive Service Workshop, wediscovered two important issues. First, themanagers could use management system analy-sis to start with what they knew best—theiroperation—and work to what they knew nextbest—the decision makers involved—and thenbe able to specify to the contractors exactlywhat they needed. Second, the contractorscould never know the operation of the domainas well as the managers did. Through theMSM and management system analysis, wecould show that without the manager makinga crucial contribution through functions 1, 2and 3 to building the management tool, the toolwas destined to fail. However, the manager’scontribution required only familiarity withmanagement, information, data, and systemsapproach concepts, not technical or specialistexpertise in hardware or software issues of anykind. They felt so relieved! They didn’t haveto become expert in this strange technology tostay up with a changing world. But, they didneed to know more about their domain ofresponsibility and associated decisions thanbefore. They had to understand what they

Through their intimate knowledge of the first several steps of management systemanalysis, managers play an instrumental initiating role in providing input to infor-mation specialists when building management tools.

267

managed well enough to work through the firstfew management system analysis functionsand to tell someone else what they knew. Thisjob was harder than you might expect, but a jobthey needed to do to be successful in theirresponsibilities.

We used Figure 1.1.21.4. to demonstrate thecrucial role the manager plays in buildingmanagement tools and the interface the man-ager has with the information specialist. Themanager contributes the management systemanalysis functions around the upper part of theMSM and the information specialist contrib-utes the functions around the lower part. Themanager’s functions come first. Figure1.1.21.4. shows the interfaces or the overlapbetween the manager and the information spe-cialist. One overlap is at the informationportrayal/information perception interface ofthe MSM. The other overlap is at the mea-surement, data interface. These overlapswere the two places where the manager andthe information specialist needed to under-

stand each other and communicate.

The two overlaps in Figure 1.1.21.4. highlightthe two classical ways of analyzing the needfor management tools. The first way is to startwith what data is available and figure out howto store, retrieve, and manipulate those dataand then how to make information out of them.Most people do management tools this way.That’s why you have so many notebooks, filecabinets, and computer data bases with worth-less stuff in them. The second way is to startwith the decisions the management tools are tosupport and strive for only the informationneeded for the decisions and the data neededfor the information. The first way started at themeasurement, data overlap between managerand information specialist and the secondstarted at the information portrayal, informa-tion perception overlap. Management systemanalysis clearly says that the best way is thesecond. The managers learned that lesson andthey’re glad they did.

Figure 1.1.21.4. The manager and the information specialist overlap contributions toward buildingmanagement tools at two Management System Model interfaces. Management system analysis saysthe interface starting the interaction should be the information portrayal/information perceptioninterface.

WHOMANAGES

WHAT ISMANAGED

WHAT IS USEDTO MANAGE

INFORMATIONPERCEPTION

INFORMATIONPORTRAYAL

MEASUREMENT

DATA

DECISIONS ACTIONS

268


1.1.21.5. THE NINE FUNCTIONS OF MANAGEMENT SYSTEM SYNTHESIS

To use management tools within the management process, we use nine managementsystem synthesis functions, best described in terms of the Management SystemModel.

The nine functions of management systemsynthesis serve two purposes. First, they pro-vide a map for continuous performance im-provement. The map is an embellishment ofDeming’s Plan-Do-Study-Act (PDSA) Cycle,which is an embellishment of Shewhart’sSpecification-Production-Inspection Cycle,which is an embellishment of the scientificmethod. Second, they tell us how to usemanagement tools. Since the five functions ofmanagement system analysis tell us how tobuild management tools, the nine functions ofmanagement system synthesis work togetherwith the five functions to provide a closed setfor directing us how to build the right tool andthen how to use that tool correctly. The build-ing and the using of the tools then aren’tseparated conceptually.

One group of people may build the tool andanother group may use the tool, but the map ofthe management process structure, throughthe 15 functions, ties everything together. Ifwe do the functions correctly, the manager(decision maker) is the consistent playerthrough the building and using directions ofthe management process.

In its simplest form, management system syn-thesis includes three groups of steps:

1. Three steps, or functions, for planningwhat the manager will do with his or heroperation using the management tools(Decide what to do. These functions relateto the Plan part of the PDSA Cycle.)

2. Three steps, or functions, for executing theplan using the management tools (Do what

you decided to do. These functions relateto the Do part of the PDSA Cycle.)

3. Three steps, or functions, for comparingthe plan with the execution to determinestatus and progress (See how well you didwhat you decided to do. These functionsrelate to the Study part of the PDSA Cycle.)

The groups of functions, and therefore thefunctions, are cyclic. So, after seeing how wellyou did what you decided to do, you start allover again by planning what to do to improvebased on what you learned in the precedingcycle. (The closing of the cycle and the impli-cations for recycle relate to the Act part of thePDSA Cycle.) In this way you execute thecycle and improvement spiral shown in Figure1.1.9.1. in the module called Define Manage-ment Systems Engineering.

Figure 1.1.21.5. uses the Management SystemModel (MSM) for direction and as a rallyingpoint for the nine management system synthe-sis functions. In the figure, I include the MSMmore as an icon than as the framework formanagement system synthesis. You can seethat the nine functions of management systemsynthesis fit comfortably around the MSM.The MSM tells us we have a closed set offunctions for synthesis by showing no gapsand overlaps in considering the componentsand interfaces of the MSM. Through theMSM, we have confidence that the foundationconcepts leading to the MSM are carried intomanagement system synthesis. Just as thecomponents and interfaces of the MSM arereally intermingled and have been pulled apartfor ease of discussion, the management system

269

convert the data from the measurements intoinformation for the manager to compare toexpectation to determine new or better inter-ventions for continuously improving perfor-mance.

The success of management system synthesisis in taking the functions in the proper se-quence. Notice how the functions of the syn-thesis move clockwise sequentially around thecomponents and interfaces of the MSM. Wewant to get to the comparing functions. But ifwe don’t do the planning and executing func-tions well, our comparisons will be worthless.The verifying performance function completesthe loop. We can’t determine how good ourexpectations, work process, and measurementsare until we know what they yield in terms ofthe aim of the management system. In fact, wehave a loop we must work iteratively to design,cause, and measure performance improvement.

Management system analysis and manage-ment system synthesis work together. I’llshow how you can jump from analysis tosynthesis or vice versa. For example, if you’reworking the synthesis loop (using manage-ment tools) and converting data to informa-tion, you may find that you need an improvedmanagement tool to do what you want. Youcan continue the clockwise loop and simulta-neously work counter-clockwise to improvethe tools you need to get the data. Soon, I’lldescribe the inter-workings of managementsystem analysis and management system syn-thesis within the management process.

synthesis functions must work together withinthe systems approach. The cycle of the func-tions includes sequence but allows the neces-sary cyclic, recursive, reversible nature of themanagement system.

Figure 1.1.21.5. labels the nine functions asCW1, CW2, and so on. CW1 stands for thefirst clockwise function. The managementsystem analysis functions go in the other direc-tion, so the labels distinguish between analysisand synthesis and indicate sequence.

In analysis, we separate the whole into its partsso we can better deal with each part. Under thesystems approach we analyze with the wholeand its aim always in mind. In managementsystem analysis for management tools, westart with the whole—an understanding of thedomain for which we intend to improve itsperformance. Then we separate the interven-tion into the decisions needed in the process ofbuilding and applying the intervention, theinformation needed to support the decisions,the data needed to make up the information,and the measurements to collect the neededdata—a process continually moving us intogreater detail and specificity, an analysis.

In synthesis, we combine the parts to make upthe whole so we can make sure everythingworks toward a common aim. In managementsystem synthesis for management tools, westart with the parts—the expectations of thedomain and its parts, the details of the workprocess, and the indicators to be measured tosee the workings of the operation. Then we

270

Figure 1.1.21.5. The nine management system synthesis functions for using management tools workclockwise around the Management System Model.

MANAGEMENT SYSTEM SYNTHESIS(Functions for Using Management Tools)

SETTINGEXPECTATIONS

SURVEYINGYOUR WORK

COLLECTING ANDLOGGING DATA

CONVERTING DATATO INFORMATION

ORGANIZING ANDPRESENTING INFO

REVIEWING STATUSAND PROGRESS

EXERCISINGPERSONAL

EFFECTIVENESS

VERIFYINGPERFORMANCE

DETERMININGINDICATORS AND

REFERENCE POINTS

CW1

CW2

CW3

CW4

CW5

CW6

CW7

CW8

CW9

WHAT

WHAT WITH

WHO

272


1.1.21.6. ORIGINS OF MANAGEMENT SYSTEM SYNTHESIS

During the period 1972 to 1974, PamelaKurstedt and I worked with Management Ho-rizons Data Systems, a company that providedmanagement, data, and information servicesto wholesale warehousing companies. Citicorphad just assumed majority ownership and con-trol of the company. They applied the success-ful Citicorp management techniques of the1970’s and turned a failing company into asuccessful one. We didn’t know it then, but wewere part of management system synthesis.

In 1986, one of the Citibank executives whoparticipated in the informal, evolutionary de-velopment of what was the successful Citicorpmanagement process of the 1970’s askedPamela and me to capture the managementstyle still practiced by some people in Citibankand write an internal training manual. Hisobjective was to recover and promulgate themanagement process, what he called methodsfor management.

The most exciting part of the managementprocess was a series of rules that had becomeingrained in Citibank’s culture during thatsuccessful time period. The less exciting, butmost important, part of the process was anumber of methods (That’s what Citibankcalled them.) that were guided by the rules. Inhindsight, Citibank’s methods included func-tions and methods and other management tools.For example, one method was work flow chart-ing, which in this book is a tool to help do thesurveying your work function. While workflow charting is a superb tool, we can use othergood tools to help do that function.

The management process reflected the ideas

of the quality movement but neglected thehuman flavor of willing workers doing theirbest. However, the parts of the process pro-moted cooperation and continuous perfor-mance improvement.

When the internal training manual was pub-lished in 1988, we had defined eight ofCitibank’s methods. The manual generatedmuch excitement and many thousands of cop-ies were used throughout Citibank’s offices allover the world. Pamela and I helped install themethods for management with the methodsand rules in a number of Citibank’s divisionswhere the process had been forgotten or ne-glected.

Later, we generalized the rules and methodsand helped government agencies and variousindustries learn and practice the process. Dur-ing this time, we rewrote the rules so they hadbroad application and less Citibank jargon.We also discovered the inconsistency amongthe function, tool, and method category of themethods. So, we deciphered the functionsbehind the eight methods.

When we saw the functions, we discovered theconnections to the Management System Model.As a result, we added the ninth function; andone of the difficulties we had in the originaltraining manual was resolved. Immediately,we saw the reflection of Deming’s Plan-Do-Study-Act Cycle in the functions. We care-fully adjusted the present labels for and imple-mentation of the functions and the rules thatguide them so they center on the human as-pects of continuous performance improvement.Studying the management systems synthesis,

Management system synthesis originated in successful management practices forcontinuous performance improvement.

273

or using management tools, part of the man-agement process is essentially studying totalquality management.

I argue that from Taylor’s time until todaywe’ve been evolving total quality manage-ment and continuous performance improve-ment to properly answer the time-honored,fundamental management questions in Mod-ule 1.1.4. Management systems engineers arewell equipped to lead the answers to the ques-tions.

The nine functions were always used to imple-ment management with existing managementtools. Clearly, they were using-management-tool functions. When people used the func-

tions well, they discovered ways to improvetheir management tools. So, we now see theconnection between the building-management-tool and using-management-tool functions.

The origin of management system synthesiswas inductive. Based on observations in orga-nizations trying to use management tools andtrying to install and implement the functionsfor using management tools, we developed theclosed set of nine functions and a set of eightrules (described in Section 3.0 of this book) formanagement system synthesis. Managementsystem synthesis is empirically derived andnot derived from management theory. In evalu-ating management system synthesis, we seethe management theory at work.

274


1.1.21.7. MANAGEMENT SYSTEM MODEL, MANAGEMENT SYSTEM

ANALYSIS, MANAGEMENT SYSTEM SYNTHESIS

If we look at an organization from the perspec-tive of building and using management tools,we can construct an organizational model basedon the five management system analysis func-tions and the nine management system synthe-sis functions as shown in Figure 1.1.21.7. Thefourteen functions work around the Manage-ment System Model (MSM). The MSM actsas an icon or rallying point for the two cyclesof functions. The MSM made its contributionin integrating the foundation concepts andstimulating the creation of the two cycles. TheMSM plays primarily a symbolic role in thepractice of the functions.

The direction of the sequencing of functions inFigure 1.1.21.7. reflects the way the MSM isdrawn in Figure 1.1.18.1.3. The clockwisedirection in the MSM goes from who to whatto what with. You can find the starting pointsfor both management system analysis andmanagement system synthesis in Figure1.1.21.7. To build a tool well, you start byunderstanding your domain and proceedcounter clockwise to the decisions you need tomake by working toward measuring indica-tors to get data to convert into information tosupport the decisions. To use a tool well, youstart by surveying your work and proceedclockwise to the indicators you must set to getthe data you need and work toward making andcommunicating decisions to improve the or-ganization. The starting point is always pro-found knowledge of the workplace by under-standing your domain, or surveying your work.Proceeding either counter clockwise or clock-wise through the functions requires profound

knowledge of the management process and ofwhat Deming calls profound knowledge: thetheories of variation, systems, knowledge, andpsychology.

If you look back at Figures 1.1.21.3. and1.1.21.5., you’ll be able to interpret connec-tions between the clockwise and counter-clock-wise functions. In Figure 1.1.21.7., I’ve shownthese connections as two-headed arrows be-tween the cycles. The arrows in the figurearen’t all there are. The few I show representthe crosswalk between management systemanalysis and management system synthesis.These arrows emphasize the idea that we canbe following one cycle in sequence, move tothe other cycle and proceed in the oppositedirection. The combination of the cycles shownin the figure emphasizes the reversible natureof the management process. Figure 1.1.21.7.shows the complete structure for the manage-ment process. This structure, together with themanagement process rules and the systemsapproach helps us convert interventions intoperformance improvement.

Here’s an example of what I mean by switch-ing directions in the two cycles of functionsby moving from one cycle to the other. Asyou work on using a management toolthrough management system synthesis andare figuring out how to portray informationin CW6, you may realize you need to im-prove the management tool and its data gath-ering ability. Then, you switch from usingthe tool into building a better tool by movingfrom the clockwise direction to the counter

Management system analysis and management system synthesis work theirfunctions around the Management System Model and their functions interplayto help managers convert interventions into improved performance.

275

Figure 1.1.21.7. When we put the management system analysis and the management systemsynthesis functions together around the Management System Model, we see the cyclic, recursive, andreversible nature of the management system.

MANAGEMENT SYSTEM ORGANIZATIONAL MODEL

CCW1Domain

CCW3Information

CCW4Data

CCW5Measurements

CCW2Interventions

CW1Expectations

CW2Survey

CW3Indicators

CW4Logging

CW5Converting

CW6Presenting

CW7Reviews

CW8Personal

CW9Verifying

WHO WHAT

WHAT WITH

clockwise direction.

Here’s another example. As you work onbuilding a management tool and finding outthe information you need in CCW3 for thedecisions you make, you may want to look atcharts of the work flow to determine the pos-sibility of operationalizing the measurementsof data to get that information. Then youswitch from building the tool into using thetool better by moving from the counter clock-wise direction to the clockwise direction.

I’ve emphasized the management-tool (whatis used to manage), or information-oriented,

perspective from Figure 1.1.18.7. in develop-ing and discussing the functions of the man-agement process shown in Figure 1.1.21.7.I’ve emphasized the engineer’s interest in themachines of management. The managementprocess and this figure apply equally well tothe perspectives emphasizing the operation(what is managed) and the manager (whomanages). Since who manages uses the man-agement tools, the functions help the managerdetermine how to build and use the manage-ment tools. Since the management tools areused on what is managed, the functions tell ushow to apply the management tools to thework process.

276


1.1.21.8. BEYOND THE MANAGEMENT SYSTEM MODEL

In management systems engineering, we mustbridge our engineering and management think-ing. Management system analysis and man-agement system synthesis form the structureof the management process and represent man-agement thinking. When we make physicalscience analogies, we put management issuesin physical science terms. Applying the engi-neering process is even more direct when theobject of the application is in physical science,or engineering, terms. We then generate solu-tions to management questions or problems inan engineering context. If our analogies aresolid, we can transfer back the engineeringsolutions to contribute to management solu-tions.

To extend our thinking beyond the Manage-ment System Model (MSM), we want othersimple models, each emphasizing and display-ing management issues different from thosebest addressed using the MSM. A good ex-ample of such an extension and one that illus-trates the value of finding an analogous engi-neering model is the control loop. Recall thatthe MSM is a descriptive model. A majorcontribution of the control loop is that it ispredictive.

To discuss the control loop analogy, I’ll quotefrom Engineering Analogs in Management byKurstedt, Mendes, and Lee (Proceedings ofthe Ninth Annual Conference, American Soci-ety for Engineering Management, October,1988, pp. 197-202.). “Inspired by the MSM’scircular loop (suggesting a feedback controldiagram), I decided to use an analytical frame-work based on automatic control theory. I wastrying to model the interfaces in the MSM by

looking at the relationships between the com-ponents, and this is what control theory does.(Control theory studies the dynamics of agiven ‘plant,’ and decides what is the best wayto make it track some desired behavior. Thedesired behavior corresponds to the engineer-ing criteria. In a management situation, thesecriteria result from a (participative or not)decision-making process.) Control-basedmanagement models are supported by the lit-erature, either explicitly (e.g., Forrester, 1961)or implicitly (e.g., Argyris and Schon, 1978).As a point of interest, the MSM-based controlframework complements classical industrialengineering (Herzog, 1985) and managerialcontrol theories (Amey, 1986).

My objectives are: (1) to get a generalizedmodel from the analysis of common classes ofvariables and types of elementary componentsfound in different physical environments, and(2) to use the meaning of variables and rela-tionships in the general model to understandand specify the meaning of variables and com-ponents in the MSM (See Mendes, Kurstedt,and Lee, An Information Strategy is Funda-mental for Sustained Competitive Advantage,Proceedings of the Ninth Annual Conference,American Society for Engineering Manage-ment, October, 1988 for an application ofthese concepts.) According to the precedingdefinition of Industrial Engineering [See Mod-ule 1.1.14.4.], predicting the behavior of engi-neered systems is a major objective, attainablethrough the formal application of scientificknowledge. Analogies between physical sys-tems reflect general laws. For example, thecontinuity law is the basis of Forrester’s rateequations, useful in modeling the operation

We can use the Management System Model to develop new models, compatible withthe Management System Model, that emphasize management parameters theManagement System Model doesn’t.

277

(the ‘What is managed’ component in theMSM):

(Flow into system) - (Flow out of system) =(Time rate of change inside system).

To model each person’s management system Iuse a control systems perspective. Tosi (1983)defines ‘the control structure [as] the set offactors, and the relationships between them,which elicit predictable performance from in-dividuals and groups in organizations.’ Hesees control as influencing people to minimizeproblems and insure compliance with normsand goals. Without going this far, the moretraditional control systems theory I subscribeto supports the three stage maturity concept ofcontrol: to maintain the values of an outputvariable close to a preset value, and absorbdisturbances.

I use the MSM to understand the ‘inside world’first, and the ‘outside world’ after, i.e., tofigure out how the organization works withinitself before worrying how it interacts bestwith the outside. I deal with shared informa-tion processing (information for both the in-side and outside world) through different in-formation portrayals. Now, to physically modela management system, I represent the MSM asa control loop in the lower part of Figure1.1.21.8. The MSM and the control loop areplaced together to show their analogous com-ponents and relationships. The controller inthe control loop is the ‘who manages’ in theMSM, the plant is ‘what is managed,’ and thesensors are ‘what is used to manage’; theinterfaces are intact. The analog is completebecause the control loop shows the interac-tions with the environment as inputs (set points),disturbances, and outputs. At this time I don’tconsider the interfaces. Those are only re-quired during implementation.

The analogy can be further explored. Whensomething goes wrong and a manager is un-able to control the operation as desired, either

the manager is replaced, the organizationchanges, or both. That corresponds to eitherreplacing the controller or facing an unstablesystem. Another alternative is to change goals,but that corresponds to changing the inputs,the desired system behavior. Similarly, chang-ing a manager’s attitudes is equivalent to tun-ing the controller, and improving the tools islike calibrating the sensors.

The control theory loop is general. I use thecontrol theory representation of the MSM tostudy the response of a management system tochanges in the reference input. The compara-tor [the little circle where the reference inputand results meet] shows the manager’s biasrelative to the incoming information, such thatmanagers in different positions in the organi-zation will respond differently to the samechanges (See also Kurstedt, Berube, andMendes, We Bias Information Differently forManagers at Different Organizational Levels,Proceedings of the Ninth Annual Conference,American Society for Engineering Manage-ment, October, 1988.) In physical systems,sensors also have reference inputs, used forcalibration purposes. Continuing with theanalogy, I say the management tools are alsobiased relative to the incoming data.”

The interfaces of the MSM aren’t emphasizedin the control loop in Figure 1.1.21.8. Theinputs and outputs to the environment are. Ifind that the functions of management systemsynthesis lay on top of the control loop quitewell—better than they do the MSM. We canalso find the ABC Model in the control loopanalogy. The disturbance input represents C,cater to crises. Administer the work process,A, is the action of the controller on the plantbased on the reference input. When we extendA to include administer the management pro-cess, we include the feedback through thesensors. Build the business, B, occurs whenwe set the reference to a new level and adjustthe plant accordingly.

278

Figure 1.1.21.8. The control loop analog helps make the Management System Model predictive andextends the Management System Model to a new form emphasizing the interaction of the system withthe environment and the resulting dynamics of the system. (The control loop analogy wascontributed by Pedro Mendes during our work together on his PhD dissertation. Pedro has the bestunderstanding of anyone I know on how to extend the MSM. In his dissertation, Pedro applied thecontrol loop analogy to an emergency management problem. Later, I’ll use Pedro’s dissertation torender the control loop into terms directly related to management questions.)

I argue that the control loop analogy is a goodway to extend the MSM. Obviously, thecontrol loop stands on its own in modelling theorganization. The MSM served its purpose ingiving us confidence that the analogy works.Now we have two different models, each withits strengths.

I prefer two different models rather than RubeGoldberg type attachments or extensions toeither model. I intuitively know we’ll findmore models, each serving a valuable purposein understanding the complex system we callan organization.

THE CONTROL LOOP ANALOGHELPS MAKE THE MSM PREDICTIVE.

InformationPerception

InformationPortrayal

Measurement

Data

Decisions Actions

Controller

ReferenceInput

Plant

Disturbance Input

Sensors

OutputResults

WHOMANAGES

WHAT ISMANAGED

WHAT IS USEDTO MANAGE

280


1.1.21.9. THE STATICS VIEW VERSUS THE DYNAMICS VIEW

When engineering a mechanical system, wefind value in taking both a statics view and adynamics view. We use each view to learnsomething about the mechanical system. Eachview contributes something different to ourunderstanding, based on what that particularview is best equipped to do. Recall this discus-sion from Module 1.1.16.3.

I’ll transfer the perspectives we’ve learned instatics and dynamics to understanding howorganizations work. Statics looks at balance inorganizations. (Don’t imagine a scale—as inthe scale of justice—when I say balance. Bal-ance here is more like fit and adjustment to amatch or compatible and productive arrange-ment. I discussed the idea of fit in Module1.1.21.4.) Dynamics looks at change in orga-nizations. Since the organization is an opensystem, the forces for change must includeexternal forces. For a dynamics view of theorganization, we have to include external forceson the organization. The resistance to changein an organization is internal. In terms ofstatics and dynamics, resistance to changecaused by an external force is friction. Clearly,we can use mechanics analogies to representorganizations. But, what can we learn from theanalogies?

The Management System Model (MSM) is aclosed system model and is most directly use-ful for balance. The MSM is an internal lookat the organization and includes the operationas a subsystem acted on by interventions andyielding measurements and data for manage-ment tools. Figure 1.1.21.9.a. shows the partof the MSM where the operation is influencedby actions internal to the organization. In

Module 1.1.21.8., I showed another model forthe organization, a control loop analogy, tohelp us look at dynamics of the managementsystem so we can study change. The controlloop model looks at the organization under theinfluence of the environment. Figure1.1.21.9.b. shows the part of the control loopwhere the organization is influenced by thevendors and the customers of the organization.

The control loop model incorporates all theparts of the MSM, but can’t be called anextension or modification of the MSM. Thecontrol loop is its own model. The control loophas been used in electrical engineering, me-chanical engineering, psychology, and otherdisciplines for many years to study the time-dependent performance of a system under ex-ternal forces.

Even though the MSM directed the develop-ment of management system analysis andmanagement system synthesis, the MSM didn’tcarry into management system analysis andsynthesis its exclusion of the connections ofthe management system to the environment.As a result, management system analysis andmanagement system synthesis apply both tobalance and change.

I’ll illustrate how management system analy-sis and synthesis have the ability to deal withthe organization’s environment. My first il-lustration is for using management tools—management system synthesis . If the survey-ing your work, collecting and logging data,and reviewing status and progress functionsshown in Figure 1.1.21.5. are internal, we dealwith internally stimulated change and resis-

Management system analysis and management system synthesis are equally goodfor looking at balance—the statics view—and for looking at change—the dynamicsview—in an organization.

281

on the operation’s performance. However, wecan build management tools based on deci-sions including external as well as internalinformation, data, measurements, and indica-tors. Therefore, management system analysisis just as valuable for change as for balance.The same is true for management system syn-thesis.

The MSM and statics lead to managementsystem analysis. In building managementtools, we look for balance and strength of theMSM components. These activities relatemore to A activities (administer the work andmanagement processes) in the ABC Modelshown in Figure 1.1.7.

The control loop and dynamics lead to man-agement system synthesis. In using manage-ment tools, we look for change in the MSMcomponents. These activities relate more to Bactivities (build the business) in the ABCModel shown in Figure 1.1.7. Soon, I’ll ex-tend my discussions of the ABC Model andhow to use the model.

In summary, the MSM provides a statics-typeview of the organization. We need the controlloop model for a dynamics-type view. Man-agement system analysis and managementsystem synthesis 1) overlay both the MSM andthe control loop model, providing both staticsand dynamics views; 2) can be confined inter-nally for a view as a closed system, MSM, orstatics; and 3) can be extended externally for aview as an open system, control loop model, ordynamics.

tance to change. (To continue the mechanicsanalogy, we do so in terms of force, weight,and friction.) We’re considering the workprocess as shown in Figure 1.1.21.9.a. Byincluding the vendors on the input side of themanagement system in Figure 1.1.21.9.b. andthe customers on the output side within thethree management system synthesis functionsI just listed, we include external forces forchange.

In working with management tools, we firstunderstand the tools we need by looking at theorganization internally—a statics view—andfocusing on the work process as shown inFigure 1.1.21.9.a., where the tools directlyexperience the data from the operation. Then,we refine our management tools by looking atthe organization externally—a dynamicsview—and adjusting our view of tools to in-clude the environment as shown in Figure1.1.21.9.b., where the tools indirectly reflectmeasurements related to vendors and custom-ers. In the dynamics view, the tools includeboth input effects of the environment andoutput effects on the environment in relation tothe work process as used by the manager andhis or her understanding of data and informa-tion not only coming from the operation butcoming from and going to the environment.

My second illustration of how managementsystem analysis and management system syn-thesis include effects of the environment is forbuilding management tools—managementsystem analysis. We can build managementtools based on decisions for actions on theoperation from the feedback within the MSM

282

Figure 1.1.21.9. The Management System Model focuses on the inner workings of the managementsystem for balance and strength of components, whereas a control loop model focuses on the externaleffects on the management system for change.

Management System Modela.

Operation

Manger’sdecisions

andactions

Measurements

and data formanagement tools

Control Loopb.

OrganizationVendors Customers

Manager'sdecisions

284


1.1.21.10. FORCES, ENERGY, AND FRICTION IN THE WORKPLACE

Recall two of the time-honored, fundamentalmanagement questions from Module 1.1.4.How do I get useful information (the right,high-quality information on time) about mywork to support the decisions I make? How doI improve morale and reduce fear in the work-place? When you’re responsible for the workseveral people do and need to make decisionson reliable, often-detailed data, you must in-teract with people in non-threatening but pen-etrating ways.

In trying to solve a problem, you must get tothe root cause of the problem. One techniqueis a Japanese technique called the five-whystechnique, where you ask why five times to digdeeper and deeper into the problem to find theroot cause. In this technique you depend oninformation from the person you’re askingwhy. They must cooperate or you’ll never getthe information you need. If they feel threat-ened, they won’t cooperate. So, you mustpenetrate to the root cause without being threat-ening. In short, to be successful, you oftenneed a potentially-threatened person’s help.

Penetration requires specifics, not a broadapproach. To penetrate to the specifics, youmust understand the technology of the workprocess and of the management process.

Success in penetrating for information requires1) understanding of the technology and 2) thehelp of a potentially-threatened person. Forsuccess in penetrating into the specifics, youmust enhance driving forces in your penetrat-ing skill and reduce restraining forces by re-ducing barriers and resistance to penetrating.

Consider Lewin’s force field analysis describedin Chapter Three of Weisbord’s ProductiveWorkplaces. I’ve set up a simplified forcefield analysis diagram for the problem of inter-acting in non-threatening but penetrating waysin Figure 1.1.21.10. The diagram is simplifiedsince I’m sure you can add both driving forcesand restraining forces to the diagram. A valu-able group activity in an organization wouldbe to complete the set of forces in the diagram,determine the length of the arrows to representrelative sizes of the forces, and discuss ways toincrease forces in the direction of desiredmovement and ways to reduce forces oppositeto the direction of desired movement. Re-member that you get better results from reduc-ing restraining forces because increasing driv-ing forces begets increased restraining forces.

Our objective is to move the problem from thestatus quo by increasing the drives or reducingthe restraints. My point in all this is that inraising the fundamental management questionand finding the answer we have developed adiagram of forces on or within an organiza-tion. As engineers, we feel comfortable ana-lyzing forces.

Our diagram looks a little like a free-bodydiagram in mechanics for studying statics anddynamics. If the sum of the forces in the xdirection is zero, the system is in equilibriumand the status quo is maintained. If the sum ofthe forces in the x direction is different thanzero, the system is going to move (change) inthe direction of the prevailing forces. But theforces aren’t like the ones we’re used to frommechanics. These forces have to do with

Analogous parameters from the physical sciences, so familiar and useful to engineers,like forces, energy, and friction help us generate relationships for answering funda-mental management questions.

285

thermal energy) and increasing friction doesthis. We know that intentionally producingfriction is a delicate matter because that energyis usually lost or harmful to the system. One ofthe fundamentals of the engineering process isknowing how to gather, convert, and conserveenergy. This fundamental applies to engineer-ing a management process too. (Perhaps wecan find an analogy between friction in pipesand delaying or distorting information flow.)

Through the mechanical analogy, I’ve set upsome relationships by which we can discusscause and effect in using forces to do work andgenerate productive energy recognizing wecan waste it all through energy dissipatedthrough friction. Eric Mills of my 1993 classsuggests that if friction is external resistance tochange, then inertia is internal resistance tochange. I’ve set up relationships for dealingwith at least some of the fundamental manage-ment questions in Module 1.1.4. I discoveredthese relationships by considering mechanicalanalogies. If any of the relationships makessense on the face of it, we can test the relation-ship through observation and measurement.

We can find many analogies from the physicalsciences to develop useful parameters andrelationships, like control, force, work, en-ergy, power, strength, and many others. Whenwe have the analogies and have confidencethat, through the systems approach (generalistperspective), the analogies apply, we can trans-fer the relationships among variables and studythe sensitivity of one variable to changes inanother variable. Today, we seldom are able toplug in numbers and get quantitative results.We can’t quantify fear in pounds or pounds persquare foot. But we can get qualitative results;and qualitative results aren’t only the startingplace, they’re the most potent results.

human characteristics like abilities and moti-vation. Yet they’re forces just the same.

What about continuing the analogy. If weapply a force through a distance, we get work.What is distance in an organization? I’ll argueorganizational distance ranges through peopleor jobs up and down the organizational hierar-chy and across people or jobs at a level in thehierarchy.

The more broadly the force is felt, the morepositive or negative work done by the force,where positive or negative depends on thedirection of the force. Each force does workthat accumulates effort regardless of direction.(You accumulate effort in the sense that if youcarry a brick up and down a hill to return to thepoint of origin, you might do no work but youstill get tired.) We know the work accom-plished is the resultant force acting through thedistance moved and occurs only when some ofthe forces prevail.

If we integrate the force through distance overtime, we get energy. In an organization, wefind many types of energy, including motiva-tion, joy, and frustration.

We know what time is in an organization. Wecan even develop an analogy for weight in theorganization. Let weight be a function of sizeand density. Size we can handle, but what’sdensity? Perhaps influence on others and onthe work process. If we’re moving an organi-zation through or across another medium andthe organization has weight, we’ll get friction.We know organizations get conflict and loss ofenergy through friction. Generally, we want toreduce friction because friction results in adissipation of energy and a loss of work. Some-times we want to convert energy from oneform to another (e.g., mechanical energy to

286

Figure 1.1.21.10. A force field analysis diagram helps give us a handle on answering the question:How can I interact with people in non-threatening but penetrating ways?

PROBLEM: Need to penetrate for information

Drivingforces

Status quoline

Restrainingforces

Knowledge oftechnology

Fear

Something tohide

Comforting stylefor interaction

Direction ofdesired movement

288


1.1.21.11. THE CARE AND FEEDING OF ANALOGIES

Morris indicates that analogies are good start-ing points for new models. (William T. Morris,“On the Art of Modeling,” Management Sci-ence, 13 (12), August 1967, p. B-709.) He saysthat analogies between the problem at handand some previously well-developed logicalstructure help us make intuitive leaps. Analo-

gies are effective when dealing with an emerg-ing science in that they stimulate premises tobe proven or disproven through further study.Engineering analogies help us with manage-ment systems engineering and management,which are emerging sciences.

1.1.19. PERSPECTIVE AND B —B ERNARDO BELLOTTO file232 BACKGROUND/INTRODUCTION/THE STRUCTURE OF THE...

Documents

Transcript of 1.1.19. PERSPECTIVE AND B —B ERNARDO BELLOTTO file232 BACKGROUND/INTRODUCTION/THE STRUCTURE OF THE...