BACKGROUND/TOOLS AND SKILLS CATEGORIES · 2000-08-30 · one’s knowledge effectively and readily...

648

BACKGROUND/TOOLS AND SKILLS CATEGORIES

1.5.2. PERFORMANCE AND TOOL PERFORMANCE

649

650


1.5.3. TOOL LIST WITH MODULE REFERENCES

651

652


1.5.4. SIMPLICITY AND SKILL —PAUL GAUGUIN

653

654

655

1. BACKGROUND

1.5. TOOLS AND SKILLS

CATEGORIES

1.5.5. SKILLS

656

BACKGROUND/TOOLS AND SKILLS CATEGORIES/SKILLS

1.5.5.1. SORTING OUT SKILLS TO BUILD AND USE MANAGEMENT TOOLS.

the tool and the guide for the skill (in itself amanagement tool), and the fit of the tool to thesituation. For a management tool, we oftenneed an associated operations tool to live up tothe management tool’s potential. I use theword mechanism for the combination of a toolwith its associated guide, the necessary userand operator skills; the fit of the tool to theapplication; and, if appropriate, the associatedoperations tool.

A mechanism by itself doesn’t guarantee thedesired result. We have to consider the sys-tems approach and rules for integrating themechanism into the system we’re working on.In short, using a tool well includes not only thescience behind the tool and its use; using a toolwell includes art. If we didn’t need art, wecould consider the illustrative model in Figure1.1.29.1. to be a map, develop a spreadsheet orprocedure for walking through the illustrativemodel, put the whole thing into a computer,and let the computer automatically manage thedomain of responsibility.

We have to fold in art through the skills. As Idiscuss skills, we’ll work on folding in the artof management. Conversely, we can’t man-age well using art alone. We need to under-stand the science behind management and thetools we need to manage with. I assume that ifwe learn, practice, and develop skill for usinga management tool, we’ll develop technique.

I’ve discussed a few of the skills we need inmanagement systems engineering in earliermodules. Recall skills like system, holistic,and generalist thinking (skill in the systemsapproach); personality typing; design; delim-iting a domain of responsibility; analysis and

Webster defines skill as “the ability to useone’s knowledge effectively and readily inexecution or performance.” (Webster’s NinthNew Collegiate Dictionary) I won’t distin-guish carefully among the concepts of knowl-edge, skill, and ability at this time. Clearly,from the definition, knowledge, skill, and abil-ity work together to help us reach a goal. Theremust be intellectual skills for performing men-tal and conceptual tasks and operational skillsfor performing physical tasks. In the intellec-tual category, I’ll include concepts I’ve dis-cussed like holistic thinking and being a gen-eralist. In the operational category, I’ll includetasks like diagramming organization chartsand designing a calendar.

Some skills must be subordinate to others,such as the skill of constructing a Gantt chartbeing part of the skill of project management.Project management may be more than a skill;it may be a discipline. But, for now, I’ll treatproject management like a skill. Also, there’sprobably human-relations skills for perform-ing emotional tasks. How about putting peopleat ease or promoting a sense of confidence inothers as examples of human relations skills?

I’m interested in management tools. Manymanagement tools are implemented using anassociated operations tool. For example, weimplement the data-to-information chain as aconceptual management tool usually with anassociated computer, file cabinet, notebook,or other operations tool acting as a container.

A management tool or operations tool haspotential. We exercise the potential (like con-verting potential energy into kinetic energy)through the guide for the tool, our skill in using

We need a range of skills to manage our domain of responsibility and to build themanagement tools we need and use the tools well.

657

synthesis; and writing, reading, speaking, andlistening (skill in communicating). In the nextmodule, I’ll develop six categories for skills.We can use the categories to sort out the manyskills we can think of into generic groups tohelp us use and understand the skills and watchout for skills we can’t think of. When consid-ering management tools, we can think ofhundreds of specific tools, like time manage-ment tools. We’re better off understandingcategories of tools and using the specific toolsas examples of the categories. The sameapproach helps us with the many specific skills

we can think of.

After developing skills categories, I’ll concen-trate on systems analysis skills for buildingmanagement tools. Later, I’ll discuss skills forusing management tools, especially in regardto the rules that help gain skill in using themanagement tools synergistically together.Figure 1.5.5.1. lists a number of the skills I’lldiscuss in this book. I’ve neither distinguishedimportance nor signified emphasis in the bookamong the skills.

Figure 1.5.5.1. I’ll discuss skills for building and using management tools in upcoming modules.

EXAMPLE SKILLS ILLUSTRATE THE BREADTH OF ABILITYMANAGEMENT SYSTEMS ENGINEERS NEED.

Information portrayal (Output design)

Distinguishing data and information

Imaging

Input design

Storing data

Measuring performance

Control for quality

Dealing with change

Leadership

Project management

Crisis management

Iteration and recursion

Hierarchical decomposition

Using charts and graphs

Using models

Balancing analysis and synthesis

Problem solving

Facilitation

Building consensus

Building effective teams

Supporting empowerment

Systems approach

System perspective

Holistic perspective

Generalist perspective

Systems integration

Capturing the work process and charting

Understanding life cycles

Framework for the engineering process

System development life cycle

Project management life cycle

Information gathering

Analytical thinking

Analyzing information flow

Evaluating systems

Consensus and group dynamics

Communication

Information sharing

Modeling systems

Diagnosing problems and solutions

Relationship building

Typing personality

Diagnosing interpersonal cycles

Resolving conflict

Coaching

658


1.5.5.2. MANAGEMENT SYSTEMS ENGINEERING SKILLS CATEGORIES—SHOWING INTERRELATIONSHIPS .

You need a synergistic set of skills to help you play various roles for management, forleadership, and for management systems engineering.

We know we need to develop skills to besuccessful in managing our domain of respon-sibility. During a work day, the number ofdifferent skills we use is huge. Some of theskills are simple motor skills, like penman-ship. (I mean the fundamental motor skill ofmaking letters on a page.) Others are complexintellectual skills, like writing for thinking(writing things down) and writing for commu-nication (writing things up). Editing is anothercomplex skill we tend to overlook but is ex-tremely important in our work. Typing is askill all of us will need more and more as wedeal with computers. I’m now composing at akeyboard. I can think faster than I can type.The better I am at typing, the less I forget as Ithink through this module. Spelling and punc-tuation are skills we can get help with fromnew office automation tools. My word pro-cessing package has a speller.

As we consider one important skill in applyingboth the engineering and the management pro-cesses—communication—we realize we’redealing with hundreds of associated skills. Ijust listed a number of simple and complexskills for writing. What about skills for read-ing, speaking, listening, interpreting body lan-guage, and so on?

To help get a grip on the many skills we canapply to improve our work, I’ll develop a set ofcategories, like I did for management tools. Ishow these categories in Figure 1.5.5.2. Foreach category, I’ve included representativeskills. I’ve included six categories, one forskills that cross-cut the other five categories.As we can see from the description of skills I

just made, many of the skills work together.Typing helps me write things down. Spellingand punctuation help me write things up in thatif people are distracted as they read throughmy spelling errors, they won’t receive what Isend very well. I won’t communicate well.Since communication is but one of the impor-tant skills for engineering and management,we can see that we need a huge number ofskills to work together synergistically to be agood management systems engineer.

In Figure 1.5.5.2., I took the first three catego-ries of skills from Mintzberg’s categories forthings managers do. Mintzberg says “Theclassical view says that the manager orga-nizes, coordinates, plans, and controls; thefacts suggest otherwise.” To Mintzberg, thefacts suggest that “....formal authority givesrise to the three interpersonal roles, which inturn give rise to the three informational roles;these two sets of roles enable the manager toplay the four decisional roles.” (HenryMintzberg, The Manager’s Job: Folklore andFact, Harvard Business Review, 53:4, 1975,pp. 45-61.) I described these roles in Module1.3.1. You need skills to perform these roles.I’ve shown three categories of skills to includeinterpersonal, informational, and decisionalskills.

Since the idea of a process is so fundamental towhat we do as management systems engi-neers, I believe we have to develop skillsattuned to the understanding, construction,and operation of a process. The managementsystem, or organization, includes a number ofprocesses, including the work process and the

659

management process. I therefore include acategory for organizational, or process, skills.Some skills are very conceptual and require away of thinking or a way of looking at theworld. I call those attitudinal skills. Ulti-mately, attitudinal skills may include the atti-tudes for human relations skills we act outthrough our interpersonal skills.

Just as you need to know what tool fits whatsituation in management, you need to knowwhat skills apply to the situation. The classi-fication in Figure 1.5.5.2. gives you a structureto think about and sort out the skills you need.If your skills are strong in one category andweak in another, you run the risk of not havinga balanced approach to your work. For ex-ample, if you’re strong at interpersonal skills,but weak at decisional skills, your people willwant to work with you but will be frustratedbecause you have trouble closing the loop inthe management process.

I believe you can learn all skills mentioned inthis book. Simon speaks directly to learningmanagement skills. He says, “...the importantskills of [a manager] are decision-making skills.It is generally believed that good decisionmakers, like good athletes, are born, not made.The belief is about as true in the one case as itis in the other...A good [manager] is born whena [person] with some natural endowment (in-telligence and some capacity for interactingwith his fellow men) by dint of proactive,learning, and experience develops his endow-ment into a mature skill. The skills involved inintelligence, design, and choosing activitiesare as learnable and trainable as the skillsinvolved in driving, recovering, and putting agolf ball.” (Herbert A. Simon, The New Sci-ence of Management Decision, p. 4.)

Likewise, Flesch contrasts a special talentwith an acquired skill. When talking abouthow hard people find imagining an audiencewhen sitting down to write, Flesch says, “But

it isn’t a special talent you’re born with—it’san acquired skill. You can learn it—just asthousands and thousands of ordinary tongue-tied people have learned to stand up before anaudience and talk to them for five or tenminutes without making a complete mess ofit.” (Rudolf Flesch, On Business Communica-tions, Barnes and Noble Books, 1974, p. 4.) Ihave yet to figure out something we truly havea special talent we’re born with. However, I donotice some people tend to acquire some skillsfaster than other people. I think this acquisi-tion is easier for people with a predispositionfor certain abilities. Perhaps if you are tall andhave a strong voice, you’ll acquire a publicspeaking skill easier. However, I believe youcan work to strengthen your voice—but notgrow taller, yet.

You can’t be perfect at everything you do. Butyou need to know your strengths and weak-nesses and work for balance in applying skillsto the workplace. You have two options forcovering your weaknesses. One option is tolearn new skills and improve old ones. Youcan, in fact, make a weakness a strength bylearning new skills. I believe you can improveyour skills at anything, including holistic think-ing, leadership, and communication. Theseskills take time and effort to improve, but theresult is worth the effort. An interesting asideis that for skills like these, you can improve inmany different ways. You can improve lead-ership skills by independent study of leader-ship and of recognized leaders, by taking acourse, or by gaining experience through vol-unteer efforts in the community.

Your second option is to recognize and thencover your weakness by working with some-one skilled in areas you aren’t. I’ve found Ihave to balance my options at covering weak-nesses. I’ve decided to learn how to writebetter and I’ve decided not to learn how to dealwith bureaucrats better. I study and practicewriting skills. I hire people into my organiza-

660

tion who are good at dealing with the bureau-cracy.

The bottom line is that you should continuallyassess your skills. You need to determine yourskill levels as accurately as possible. Then you

can figure out where you want to improve.Every day you’re not improving one or moreof your skills is a day you slip behind in beingan effective engineer or manager. Do youknow which skills you’re improving today?Are they the skills you need for balance?

CATEGORIES HELP SCRUTINIZE OUR SKILLSTO DETERMINE HOW TO IMPROVE.

Figure 1.5.5.2. For effective management, you need a closed set of skills, working togethersynergistically to support your decision making process.

InterpersonalLeadership, consensus/NGT, communication, MBTI

InformationalInformation gathering (monitor), information dissemination/information sharing, datadictionary, information portrayal, distinguishing data and information, images, modelingthe system, input design, file design, storing data

DecisionalEvaluating systems (cost/benefit), measuring performance, control for quality, crisismanagement

Organizational/ProcessUnderstanding life cycles, information flow (DFD), records management, process defini-tion and scope, integrator role, project management

AttitudinalHolistic thinking, generalist thinking, analytic thinking, dealing with change, integrating

General skills—cross-cut the othersIteration and recursion; hierarchical decomposition; use of charts, graphs, and diagrams;use of models; balancing analysis and synthesis; creative skills; problem solving

661

662


1.5.5.3. SKILLS FOR UNDERSTANDING AND BUILDING A MANAGEMENT

TOOL

You need specific skills to carry you through the system life cycle for building amanagement tool.

I’ll overlay skills for building managementtools on the system life cycle discussed inModule 1.1.20.1. I call these skills analysisskills because we’re analyzing what we’redoing. I call the skills system analysis skillsbecause that’s what management informationsystem (MIS) developers call them and whatthey’re analyzing is a system. I’m as inter-ested in describing system analysis skills as Iam in describing the details of the functions ofthe management-tool-building process. Thedata-to-information chain is very analyzable.The functions of the MIS and the steps for itsdevelopment are relatively easy to describeand to evaluate. I believe the skills we need forMIS development are also the skills we needfor developing any management tool. There-fore, I’ll have MIS development in mind as Icontinue through this module.

We must look at the life cycle of the project,product, or process we’re building. Assumewe’re building an MIS. We must considerMIS development starting with recognizingthe need and continuing through to the MIS’sobsolescence, retirement, and disposal. Wemust think about the resources, like cost andpeople, the MIS will require. We also mustthink about the contribution (positive and nega-tive) the MIS will make for its entire life. Mostof our consideration for the MIS life cycle willfocus on the system life cycle. My discussionof the system life cycle constitutes somethingperhaps larger than a skill—at least a group ofskills. However, I’ll consider understandingthe life cycle to be a skill. You can apply thislife cycle analysis skill to more than just MISdevelopment. You can apply it to any service

or product you’re responsible for.

We’ll start with understanding the life cyclefor system development. How do other sys-tem analysis skills relate to the framework forthe engineering process shown in Figure1.1.11.7. Start with the five categories offunctions: analysis, design, implementation,follow-up, and follow-through. Realize theskills can’t be neatly directed to only one of thecategories shown in Figure 1.1.11.7. I identifyfifteen of the most important skills and overlaythem where they best fit in the five MIS devel-opment categories of functions. You can ex-pect to use the skills I’ve shown in relation tofunctions of one category when you’re doingfunctions of the other categories. Here are thefifteen skills I discuss as system analysis skills:

1. Communicating to get information aboutand to give information to stakeholders ofthe management tool and recognizing theimportance of documentation for trace-ability, maintainability, and accountabil-ity;

2. Interacting in groups for participation,consensus, and ownership;

3. Understanding the engineering processframework, or the system life cycle, fordeveloping the management tool;

4. Understanding the work process (what ismanaged) to be reflected in the manage-ment tool;

5. Understanding the decision maker (who

663

ment tool, or output design;

13. Controlling for quality, including reli-ability design;

14. Evaluating the system, including cost/benefit analysis; and

15. Managing a project.

In the next modules, I’ll review the role ofpeople who practice system analysis skills andthe general skills they use for sequencing andintegrating the system analysis skills I’ve listedhere. I’ll re-emphasize the systems approachas a cross-cutting skill for building manage-ment tools. Then, I’ll focus on the first andmost important of all the skills—communica-tion. I’ll expand upon sending information bydiscussing the writing skill in some detail andshowing parallels with speaking. Then I’lldiscuss listening as the crucial skill for com-munication. After straightforward communi-cation, I’ll address the second skill of interact-ing in groups. After the first two skills, thefollowing skills become more tangible.

manages) who’ll be using the informationproduced by the management tool;

6. Gathering information or collecting dataabout the work process or the decisionmaker;

7. Analyzing the information flow overlay-ing the work process and modeling theoperation, or manipulating and analyzingdata about the layout of the work process;

8. Modeling the management system;

9. Getting data into the management tool,(or what is used to manage), or inputdesign;

10. Storing, verifying, and updating datawithin the management tool, or logicaldata analysis;

11. Organizing and accessing data within themanagement tool, or file design;

12. Portraying information from the manage-

664

665

1. BACKGROUND


CATEGORIES

1.5.5. SKILLS

1.5.5.4. SYSTEM ANALYSIS

666

BACKGROUND/TOOLS AND SKILLS CATEGORIES/SKILLS/SYSTEM ANALYSIS

1.5.5.4.1. ROLE OF SYSTEM ANALYSIS

Why am I discussing the role of a systemanalyst in the middle of outlining skills weneed to build and use management tools? Weplay roles to meet responsibilities. We useskills to carry out our roles. Roles are vehiclesyour skills ride on as you journey towardaccomplishing your responsibilities. (See Fig-ure 1.5.5.4.1.)

The who manages component in the MSMuses decision making, problem solving, andother skills as they play leadership, adminis-trative, liaison, and other roles. I discuss thesystem analyst role in regard to building man-agement tools; but the role and the associatedskills are applicable to making good decisions.

The who manages and the information spe-cialist coordinate efforts at the informationportrayal/information perception interface andthe measurement/data interface. In participat-ing in this coordination, the information spe-cialist needs to play the role of system analy-sis. And, so does the manager. The role ofsystem analysis is traditionally discussed inreference to developing computer systems. Iexpand the role to building any managementtool and to managing any domain of responsi-bility.

The system analyst is a problem solver. Theidea of a system analyst and the role of systemanalysis comes from developing computersystems. Computer system analysts focus onbuilding computer systems more so than usingcomputer systems. Therefore, the role of sys-tem analysis is more an analysis role than an

holistic or a synthesis role. In computer sys-tems, we leave the integration or synthesis tothe user. To build any management tool,you’ll need to apply system analysis skills.

Often discussed in books on developing com-puter systems, skills for system analysis worktogether to solve the problem of getting theright information to the right people in theright place at the right time. These systemanalysis skills apply to developing any man-agement tool. We can extrapolate the use ofthese skills even further. If you’re going toanalyze any system, you need system analysisskills. As management systems engineers, wemust have skills both in analysis and in synthe-sis. I’ll discuss the role of system analysishere. I’ll discuss the problem solving processin Module 1.5.5.6.

In their handbook of systems analysis, Miser andQuade rightfully describe the nature of systemanalysis as being quite complicated. They firstlist a number of difficulties in carrying out therole of system analysis. Their list includes: 1)inadequate knowledge and data, 2) the involve-ment of many different disciplines, 3) uncleargoals and shifting objectives, 4) pluralistic re-sponsibilities, 5) resistance to change in socialsystems, and 6) complexity. (Hugh J. Miser andEdwards S. Quade, Handbook of Systems Analy-sis: Overview of Uses, Procedures, Applica-tions, and Practice, Elsevier Science PublishingCo, New York, 1985, pp. 14 - 15.) The systemanalyst then must be a quick learn, have vision,be an integrator, be adaptable to change, and beskilled at human interaction.

The role of the system analyst is to use systems understanding and problem solving skillsto build management tools to meet the needs of the decision maker in his or her domainof responsibility.

667

ment tool, or the decision maker. The systemanalyst must have imagination, flexibility, andadaptability to develop the management toolto meet the needs of an unique domain ofresponsibility, regardless of the resource avail-able to him or her. For building managementtools, the system analyst must be able to iden-tify the needs of the user and to have theknowledge and experience to overcome barri-ers and create pathways to meet those needs.

To begin developing a management tool, thesystem analyst must be able to delimit, learn,and diagnose the domain of responsibility andunderstand the user of the management tool.Our previous discussions on delimiting do-mains of responsibility, the information por-trayal to information perception interface ofthe MSM, and the frameworks for diagnosinga domain of responsibility provide a startingpoint for developing the management tool.Now, we must figure out more about the workprocess and the aim of the domain of respon-sibility for which we’re developing the tool.

In the next module, I'll describe the role of thesystem analyst through an example. I'll use theexample of a small country inn because I'veowned and operated a country inn and amfamiliar with the management needs.

Figure 1.5.5.4.1. Roles are vehicles your skills ride on as you journey toward accomplishing yourresponsibilities.

SKILLS ROLES RESPONSIBILITIES

Miser and Quade approach system analysisgenerically, not only as a computer develop-ment role. They argue that a system analystapproaches a problem in terms of these ele-ments: 1) Setting the framework for systemsanalysis (defining objectives and generatingand ranking alternatives for reaching objec-tives by involving iteration and feedback); 2)Formulating the problem (stating the objec-tives and constraints); 3) Generating and se-lecting alternatives; 4) Forecasting future statesfor the system; 5) Identifying the consequences,or outcomes, including the use of models; 6)Comparing and ranking alternatives, usingcriteria and including value and utility; and 7)Documenting the analysis and results. (pp.119 - 145.) The value to you in seeing theirapproach is to compare their approach to theengineering method I’ll describe in the nextmodule and to the steps of problem solving I’lldescribe in Module 1.5.5.6. You’ll notice thatthe process and skills of system analysis areessentially the process and skills of solvingsystem problems.

The system analyst must combine both techni-cal skill for developing the components andthe relationships of the components into aworking management tool and interpersonalskill for working with the user of the manage-

668

BACKGROUND/TOOLS AND SKILLS CATEGORIES/SKILLS/SYSTEM ANALYSIS

1.5.5.4.2. AN EXAMPLE SYSTEM ANALYSIS EFFORT

I’ll describe the need for system analysis tobuild a detailed understanding of the workprocess and the aim of the organization throughan example. The example I choose is one of afamily-owned country inn. As I describe tasksof system analysis, note that these consider-ations don’t contain any definition of com-puter processing.

First, as a system analyst, you must delimit,learn, and diagnose the domain of responsibil-ity. You must find out how the innkeeper andthe owner of the inn are getting informationnow and learn what’s working well. Makesure what you do preserves the characteristicsof the successful parts of the existing systemfor getting information. In this role, you’refiguring out the situation in the domain. I sayyou’re looking at Where We Are. You mustknow Where We Are (WWA) and Where WeWant To Be (WWWTB) before you can beginto know How To Get There (HTGT).

Many system analysts focus on what’s wrongwith the existing system for converting data toinformation. A good system analyst focuseson what’s right with the existing system. Tounderstand what’s right, the system analystshould walk through the work process and theinformation overlay to the work process. Inthe country inn, experience the work processfrom the point of view of the traveler. Experi-ence the work process from the point of viewof a worker. Experience the work processfrom the point of view of the innkeeper. Learnthe reservation process. Learn the other partsof the work process.

How are data gathered and recorded? If datagathered last week must be retrieved to changea reservation, how well can the innkeeper findand use the data? What’s happening is that thesystem analyst is experiencing the physicalreality of the innkeeping system. Then, thesystem analyst must translate the physical re-ality into a logical model of the inn and itsprocess. The model should emphasize thehandling of data and the conversion of thosedata into information that will be perceived bythe decision maker for making decisions andtaking action.

As part of WWA, you must understand theneeds and forces that both the innkeeper andthe owner have for the management tool beingdeveloped. They won’t express these needsand forces in terms of tool characteristics.Rather, they’ll have needs in terms of occu-pancy rate, cash flow, and absenteeism ofworkers.

As part of WWWTB, you must understand theexpectations and vision of the innkeeper andowner. Can you translate those expectationsinto functions a management tool can serve?Determine what the expectations of the inn-keeper and of the owner of the inn (differentpeople) are for what the management toolswill provide in the way of information tosupport decision making.

One of the bigger skills a system analyst musthave is to translate physical issues of the work-place into logical counterparts for manage-ment tool design. In the country inn, where

By considering how a system analyst can help the business of a small country inn, we cansee the use of the steps Where We Are, Where We Want To Be, and How To Get There—a form of the engineering method.

669

will the management tool be housed? Is thetool easily accessible? Can those who need touse the tool understand what the tool can do?Then, can they use the tool? Can you build themanagement tool for a cost a small country inncan afford? When you add in a computer tohouse the data to information conversion pro-cess, the cost can become prohibitive. Do youknow inexpensive ways to house the tool, suchas a rolodex, notebook, or marker board? Inaddition to being able to function in terms ofdata, information, and mechanisms for con-verting data to information, the system analystmust understand business issues and how totranslate those issues into tool characteristics.The system analyst must be able to judgequickly to what extent the mechanization ofthe needed data to information conversionneeds to be.

After the system analyst knows what’s rightwith the existing system and what’s needed inthe future system, then the system analyst canlook for ways to improve the system. Nowwe’re looking at HTGT. The system analystwill find opportunities for improvement at twolevels: physical and logical. Consider an ex-ample of translating a physical issue into alogical one for a computer-based managementtool as described by Powers, Adams, and Mills.“...suppose a hotel does a considerable part ofits business with tours. Under the existingreservation system, tours are booked as a unit.When reservations are reported to the localhotel, however, cards are broken out in thenames of individual guests. The fact that theseguests are tied to a single tour is lost, creatinga gap in information that might be useful tomanagement. For example, suppose a hotel insouthern Florida learns that a snowstorm hascaused cancellation of all flights from Pitts-burgh. Suppose further that the hotel had 20guests in a single tour scheduled to arrive fromPittsburgh. If the card had already been bro-ken out by guest name, it would be difficult tolocate the unavoidable cancellations. How-

ever, a computer system could quickly searchfor and report the names of all guests whowould not be arriving. The added dimensionof information made available to managementrepresents a system improvement achieved ata logical level. Timely information aboutbusiness problems makes it possible to under-stand, anticipate, and react to situations thatwould not come to light under present meth-ods. The ability to get information into acomputer immediately represents a substan-tial improvement at the physical level. Roomsstatus is more current, by hours, than waspossible under the manual system.” (Powers,Adams, and Mills, Computer Information Sys-tems Development: Analysis and Design,South-Western Publishing Co., 1984, p. 36.)My recent experience with a hotel and itscomputer-based management tool runs in theopposite direction. The desk clerk enters in-formation from the registration card into thecomputer when the rush slows down. In themeantime, those people trying to call me onthe phone are told I’m not at that hotel. Thesystem analyst can never lose the translationbetween the physical and the logical.

Opportunities for improvement in manage-ment tools come from closing gaps. When welook at WWA, we want to close performancegaps. Are we doing what we know we shouldbe doing? If not, we have a performance gap.When we look at WWWTB, we want to closeexpectation gaps. Are we doing what we wantto do to improve. If not, we have an expecta-tion gap.

When we introduce a new management toolinto the country inn, we’ll affect their workprocess at a physical level. The innkeeper willadjust how he or she takes reservations toreflect the abilities of the management tool.When we introduce the new tool, we’ll affectthe information flow at a logical level. Themanagement tool can link information noteasily done before.

670

Before any management tool can be designedand implemented by a system analyst, theinnkeeper and the owner must be able to seewhat the resulting effect will be on their busi-ness. If they don’t see a worthwhile return ontheir investment in time, money, and frustra-tion of changing their work rituals to fit thenew management tool, they’ll not agree todeveloping the tool. We can always findhardware (tool container) and software (datato information conversion procedure) that ex-ceed the ability of the innkeeper and the owner.Can we find the operations, the work proce-dure, and the information portrayal to come

close to the ability of the innkeeper and theowner? If we can, we’ll probably succeed assystem analysts.

As we consider the role of computers in man-agement tools, consider two needed consider-ations. One is to figure out how soon and howwell the computer (the associated operationstool) fits into the solution of the country innneeds. Computers certainly don’t fit into fig-uring out the problem. The other consider-ation is to figure out the solution not based oncomputers—then fit computers into the solu-tion, if appropriate.

671

672


1.5.5.5. GENERAL SKILLS OF SYSTEM ANALYSIS

In Figure 1.5.5.2., I identified a category ofgeneral skills for cross-cutting the other cat-egories of skills. These general skills areextremely important for supporting the role ofsystem analysis. Those who discuss buildingmanagement tools and especially those whodiscuss building computer-based managementinformation systems (MIS) promote the pro-cess of system analysis. Some people preferthe structured system analysis process of Ed-ward Yourdon. (I’ll show you some ofYourdon’s ideas later.)

I’ve discussed the importance of balancingsynthesis with analysis and of balancing holis-tic thinking with analytic thinking. I accept theneed for balance, but will focus on generalskills for system analysis here. You can imag-ine that a structured system analysis would bethe height of analytical thinking.

I’ve also discussed the parts of the Manage-ment System Model (MSM) the manager (tooluser) and the information specialist (toolbuilder) know best and the interfaces at whichtheir expertise overlaps. I’ll emphasize theview of the information specialist, or systemanalyst, here. (We have to be careful to recog-nize that information specialists aren’t theonly people who analyze systems. However,as a job title, system analyst often designatesthe analyzing of information systems.) Don‘tforget that the general skills are valuable formuch more than system analysis. However, ifwe’re going to focus on building managementtools, system analysis for building an MIS is agood place to focus. The MIS tends to be themore structured of the management tools andmakes a tangible example for considering thegeneral skills.

Information specialists, or system analysts,should consider all management tools andhow they together convert data into informa-tion to support the decision maker. However,I’ll emphasize the analysis of the data-to-information chain here because that type oftool is both structured and representative. TheMIS is exercised as a tool more frequently thana plan, for example, even though the data fromthe plan (what you intend to do) and from theMIS (what you did do) should be comparedfrequently (to see how well you did what youintended to do).

The skills of system analysis go beyond build-ing management tools. Analysis of a systemgoes hand in hand with synthesis of a system.There’s no sense in doing synthesis if there’sno analysis. For example, can you use amanagement tool if you don’t build one? As Idescribed in Module 1.5.5.2., one of the cat-egories of skills we need in management sys-tem engineering is the general skills that cross-cut the other categories. These general skillsinclude iteration and recursion; hierarchicaldecomposition; use of charts, graphs, and dia-grams; use of models; balancing analysis andsynthesis; creative skills; and problem solv-ing.

The system analyst provides a service functionto support a user. A system analyst is aprofessional. Service professionals serve cli-ents. Clients depend on those services. Thesystem analyst role is an important one.

As we apply these general skills to help pro-vide the decision maker with the informationhe or she needs, we can thoughtfully ask: Whythe decision maker doesn’t use these skills to

You need certain general skills to do the system analysis to build a management tool.

673

We can repeat all of the steps or only the lastfew. We can skip ahead to future steps of theprocess. We saw this recursion when welooked at conducting management systemanalysis and management system synthesistogether.

Later I’ll describe a partitioning process youcan use to determine the subdomains in yourdomain of responsibility. You’ll repeat thepartitioning activity again and again until youcan distinguish the fundamental informationflows within your domain. You took the firststep in this iteration when you scoped a do-main of responsibility in Module 1.1.18.8.Clearly the idea of partitioning is hierarchicaldecomposition and is analytic, not holistic.

Hierarchical DecompositionIn hierarchical decomposition, we decomposethe whole into its component parts and thosecomponents into their component parts. Weare dividing, or partitioning, each system orprocess into its subsystems or subprocessesrepeatedly until we reach what we believe aremanageable pieces. We’ll use hierarchicaldecomposition when we look at informationflows inside the domain of responsibility. Ifwe partition the context diagram, or the man-agement system, into its subdomains or sub-systems, we can look at the information flowsbetween these subdomains. Then, we canpartition the subdomain further and furtheruntil we have no need to decompose any more.At that point, we believe we have all theinformation flows in the organization and canthen identify the data set that makes up all theinformation used in the organization. Weabandon the decomposition when we clearlyunderstand the fundamental parts of the sys-tem.

Use of Graphs, Charts, and DiagramsWe’ll use diagrams to help us iterate throughhierarchical decomposition to find the funda-mental information flows. Graphs and charts

provide his or her own information? Whydoesn’t the decision maker use their knowl-edge of their own decision making style andtheir operation to develop the best tools tomeet their needs? The answer is that themanagement tool builder has several advan-tages over the decision maker. First, the toolbuilder deals with many different domains ofresponsibility. If the tool builder is a general-ist, he or she can transfer many lessons learnedfrom one domain to another. The tool builderis better able to understand the frameworks fordiagnosing the domain based on using theframeworks for a large number of domains.Second, the decision maker often can’t see theforest for the trees. He or she is so involvedwith the details of the domain and the deci-sions, he or she lacks the objectivity of seeingthe total system and seeing that system from afresh perspective. Third, the tool builder hasdeveloped experience in effectively and effi-ciently developing management tools. How-ever, the tool builder, and anyone practicingsystem analysis, needs a set of general skills toapply to any situation.

Iteration and RecursionIn analysis, we decompose the whole into itscomponent parts. We’ll learn a number ofskills and techniques for looking at the detailsof a system. We can repeatedly apply thetechniques to look deeper and deeper into thesystem. We repeat the techniques iterativelyor recursively. When we use iteration, werecycle through a closed-loop process. In thecase of skills, we reapply the skill in the sameway over and over to the increasingly detailedunderstanding of the system. For example, wecan look at information flows across the bound-aries of a domain of responsibility like we didin developing context diagrams. We can reap-ply the technique of developing informationflows by treating the partitions of the domainas individual context diagrams. When we userecursion, we go back or forward in a closed-loop process by skipping steps in the process.

674

engineering process. You should see somesimilarity between the DFD in Figure 1.5.5.5.and Figures 1.1.20.1.1.a. and 1.1.20.1.1.b. Fig-ure 1.5.5.5. shows three sided boxes for datastores. Data stores are where you store data forlater access, like a computer data base or a filecabinet. (Figure 1.1.20.1.3. is much like awork flow diagram in that the figure includesboth decisions and actions.)

Use of ModelsWe’ve seen how we use models for showingthe organization and for showing performancecriteria in the illustrative model. We’ve dis-cussed the types of models. Here, we’re inter-ested in modelling as a general skill and the useof models to help build management tools. Wecan use equations or diagrams as a model. Anorganization diagram models how people in-teract in an organization. A data flow diagrammodels how information moves in an organi-zation. A work flow diagram models how theactivities of the operation fit together. We usemodels as graphic, written, or visual represen-tations of the system we’re analyzing.

Balancing Analysis and SynthesisI discussed the meaning and importance ofanalysis and synthesis in a general definitionmodule. The issue here is that we can’t do oneeffectively without the other. Just as we com-bined management system analysis and man-agement system synthesis, we get more out ofdoing one of these skills when we’re able to dothe other.

Consider an analogy from Powers, Adams,and Mills. “When an architect develops ahome for a client, a process takes place thatbegins with a description of the life-style to besupported and special features desired. Fromthis description, the architect visualizes a wayto meet the client’s needs. Before breakingground to construct a building, however, somemodeling must take place. This is done withblueprints, detailed drawings, and, in cases,

help us see the entire system. Since to touch asystem anywhere is to touch the system every-where, we need to see the entire system todecide where to touch it. We need to diagram,or chart, the work flow to see where we wantto measure. We need to diagram the entireorganization to see the individual informationflows to determine the set of data from whichwe make all the information. We need to graphthe total effect of an impact on a system to seethe effect of an individual force, as in theexample of a force field analysis or a cause andeffect diagram.

Graphs and charts are very effective as com-munication tools. System analysts use graphs,charts, and diagrams to describe the organiza-tion for the user to confirm. I’ve shown arelatively simple data flow diagram, describ-ing the processing involved in a student regis-tration system, in Figure 1.5.5.5. We can useFigure 1.5.5.5. to communicate with peopleresponsible for registration or for studentswho register to make sure we’ve capturedwhat really goes on in the system.

Charting is an important tool for both themanager and the information specialist. Themanager does a work flow chart to understandand improve his or her operation, or workflow. I’ll discuss work flow charts in detailwhen I talk about using management tools.The system analyst does a data flow diagram(DFD) to understand and improve the data andinformation provided to the manager. I be-lieve a DFD is really an information flowdiagram, in that the DFD captures the informa-tion flows in the organization. Another tool,the data dictionary, identifies what data arecarried along with the information flows.

Recall the diagram for the framework of theengineering process in Figures 1.1.20.1.1.a.,and 1.1.20.1.1.b. Those figures are much likea data flow diagram, in that the arrows symbol-ize information flows between functions of the

675

actual miniature models of the buildings. Inthe same way, data flow diagrams and thesupporting data dictionary model a systemconceived in the mind of a systems analyst fora user. Models, then, are tools for communi-cation and understanding.” (Powers, Adams,and Mills, Computer Information SystemsDevelopment: Analysis and Design, South-Western Publishing Co., 1984, pp. 53-54.)

Creative SkillsThe system analyst must strive for ultimateunderstanding of the workings, needs, andissues in the existing system (WWA) and forcreative, visionary thinking for the workingsin the future system (WWWTB). Using cre-ative skills, the system analyst can figure outthe best way to transform the existing systeminto the future system. This transformation ispartly content and structure of managementtools and partly communication with and sup-port of the people who will be affected by thetransformation and will be threatened by thechange.

One of the biggest problems facing a systemanalyst is sorting out what’s right with a sys-tem and what needs to be changed. Thisproblem requires the builder to put aside his orher desire to be creative and make sure he orshe doesn’t propose change for change sake.Once the system analyst knows a change isclearly needed, then he or she can use creativeskills to make the change without undoingwhat’s working well. He or she must knowwhen the change is necessary and have theimagination to develop the process and con-tent of the change without being inhibited bywhat’s now in place. The system analyst facesan interesting paradox: Respect the value inwhat exists and improve the system.

To illustrate the level of creative thinkingrequired in deciding the types of changesneeded, consider the situation in many govern-ment oversight agencies. A government over-sight agency is one that’s close to the legisla-

tive body they serve. The government over-sight agency is usually called the headquartersfor the many local government implementa-tion agencies located where the work is beingdone.

I’ll use a state department of transportation asan example of a government oversight agency.The government oversight agency is the statedepartment of transportation (headquarters)which is located in the state capitol where thelegislative body is. The local governmentimplementation agency is the county highwaydepartment that maintains the roads and clearsthe snow during winter storms. I’ve found thatmany government oversight agencies designtheir organization structure as a managementtool to reflect the work that’s being donelocally. That is, headquarters has divisions foreach of the functions implemented at the locallevel; in the case of the state department oftransportation, a division for maintenance, adivision for bridges, a division for snow re-moval, a division for construction projects,and so on. However, nobody at the state levelever maintains anything, constructs anything,or removes any snow. What the governmentoversight agency does do is broker informa-tion. They interpret the desires of the statelegislature regarding transportation and makeadjustments to the resources allocated to thelocal agencies to support their interpretation.They interpret the needs and problems of thelocal highway departments and make adjust-ments to their proposals and issue statements(usually in the form of budgets) to the legisla-ture to reflect those needs and problems. Thegovernment oversight agency brokers infor-mation in two directions. But, they are orga-nized as bridge builders and highway con-struction people, not as information brokers.

Here’s where the creativity comes in. Howdoes the system analyst ensure that he or sheputs aside his or her view of what’s needed toferret out what’s working well in the govern-ment oversight agency’s organization struc-

676

Problem SolvingI described problem solving as a general con-cept in Module 1.1.14.1. and highlighted prob-lem solving as a fundamental of the engineer-ing process in Module 1.1.11.6.4. I’ll describeproblem solving as a general skill in Module1.5.5.6.

The system analysis process supports the needsof the system analyst for creativity and forproblem solving. The use of models beginswith diagramming the physical existing andfuture system. The system analyst uses thephysical model to gather information fromthose who know the system and communicatethe future to those who will be affected by thechange in the system. The system analyst mustbe able to translate the physical model into alogical model needed by those who will buildthe management tool based on the logicalrelationship between data and information,not on the physical operation in the workplace.As the transformation takes place, the physicaland logical models continue to play importantroles for the system analyst.

ture that moves information up and down thestate hierarchy? How do you get the agency’sdecision makers to see the advantages of chang-ing their tried and true organization structureso they can be more effective in their work?Once the decision makers agree to a neworganization, how fast and in what way do youtransform the organization from its existingstructure to its new structure? As the organi-zation goes through the throes of change, howdo you encourage, support, and resolve realconcerns over the problems caused by thechange? To work out the answers to thesequestions, the system analyst needs incredibleunderstanding of the work process, the man-agement process, and the people being af-fected. The system analyst must be visionaryin seeing and holding onto the vision of whatshould be and how that future state will work.The system analyst must be creative in notonly suggesting how to make the change but inworking with the people and resources duringthe change to support the fear that accompa-nies any change in job description and ininteragency relationships.

677

Figure 1.5.5.5. The data flow diagram for a simplified student registration system illustrates howsystem analysts model information flows. (taken from Powers, Adams, and Mills, p. 54)

CLASSSCHEDULE

REGISTRATIONLIST

TUITIONBILLINGSYSTEM

CATALOGSTUDENT

TRANSCRIPT

VERIFYPREREQUISITE

MET

ASSIGNCLASSSEAT

VERIFYSEATS

AVAILABLESTUDENT

COMPLETED-COURSES

COURSE-PREREQ

ACCEPTED-CLASS-REQUEST

SS#

#-AVAIL-SEATS

OPEN-CLASS-REQUEST

CLASS-REQUEST

#-AVAIL-SEATS

SCHEDULED-CLASS

678

BACKGROUND/TOOLS AND SKILL CATEGORIES/TOOLS

1.5.5.6. SKILLS FOR PROBLEM SOLVING

Problem solving involves making a number ofconnected decisions, often in a group setting,all aimed at a specific objective. Recall thatthe decision making process includes the stepsof investigation (get the facts), design (de-velop alternatives), and choice (pick an alter-native). The problem solving process involv-ing skills, as well as tools, will follow a similarpath to the one for decision making. I’veshown ten steps for problem solving in Figure1.5.5.6.

The first step has to be to figure out what theproblem is. This step requires an open mind,a quick learn, and an understanding or experi-ence with other problems and their character-istics. From here on out in the process, be surenot to lose sight of what you decided theproblem was. If you made a mistake, redefinethe problem. All diagnosing skills are impor-tant here.

The second step is to determine the goals(qualitative) and objectives (quantitative) forwhat a solution means for that problem. Makesure everyone preparing and implementingthe solution understands the same goals andobjectives. Holistic skills are important here.

The third step is to study the problem. Wheredid the problem come from? What’s its rootcause? What are the characteristics of theproblem relative to the goals and objectivesyou determined? What assumptions do youhave to make to consider the problem? Ana-lyze the problem. Can the problem be dividedinto subproblems such that solving all thesubproblems solves the problem and achievesyour goals and objectives? This question

involves the general skill of hierarchical de-composition. What are the consequences ofnot solving all the subproblems or partiallysolving some or all of them? Recall that thedo-nothing alternative is an alternative. There-fore, you must know the consequences (bothgood and bad) of solving the problem as wellas not solving it. Analysis skills are importanthere.

The first three steps parallel Simon’s intelli-gence phase of decision making. In the case ofproblem solving, we’re cycling through anynumber of decisions and the early phases of thedecision making process for a number of deci-sions.

The fourth step is to develop alternatives forsolving the problem. For each alternative,consider a strategy for how you’ll implementthe solution. Many of your alternatives will bepart of the solution as opposed to the completesolution. By that I mean one alternative forsolving the problem may have a clear begin-ning but then have a number of alternatives forwhat to do next. The idea of strategy carrieswith it the ideas of priorities and contingen-cies. Which is the highest priority goal? Whichalternative has the most or best fall-back posi-tion. This step is almost as important as thefirst step for identifying the right problem tosolve. If you overlook a good alternative, youonly have sub-par alternatives to choose from.All creative skills are most important here.

The fifth step is to evaluate the alternatives.Develop a consistent set of criteria to measurethe alternatives against. Apply your under-standing of priorities and contingencies to the

As a fundamental for the engineering process, problem solving is a skill that involvesa large number of interpersonal, informational, decisional, process, and attitudinalskills. The steps for problem solving show where the skills fit together.

679

alternatives. Identify the resources you’ll needfor each alternative. Consider the method andits difficulty for applying the resources to theproblem. Consider the risks and threats to theorganization and its people for each alterna-tive. Procedural and appraisal skills are im-portant here.

The fourth and fifth steps parallel Simon’sdesign phase of decision making. You need todesign not one but many good alternatives tochoose from. You need enough of a plan forimplementation for each alternative that youhaven’t overlooked a risk or a barrier that willset you back when it rears up after you’vechosen a particular alternative.

The sixth step is to choose one of the alterna-tives. By considering the advantages anddisadvantages of each alternative in terms ofthe method, priorities, contingencies, and con-sequences of implementing the alternative,you must select the alternative to carry for-ward as the solution to the problem. Groupchoice requires an understanding of informa-tion sharing and consensus gathering. I dis-cuss those concepts shortly. Decisional skillsare important here.

The sixth step parallels Simon’s choice phaseof decision making. Now you must continueon from your choice and make sure the choiceis implemented. In essence, you’re followingthe choice phase with an action phase.

The seventh step is to formalize the action planfor implementing the solution. Through theaction plan, you assign responsibilities, dedi-cate resources, and lay out the method andcontingencies for implementation. Part ofyour action plan must include points to test thechoice and the progress of the implementation.

You must ensure all those affected by themethod for solution have bought in to the need(There is a real problem.) and the solution (Themethod will work.). Interpersonal and infor-mational skills are important for this step andthe next few steps.

The eighth step is to implement the solution.We learned from the Management SystemModel that every decision requires an atten-dant action. Now is the time to act. And youmust monitor the progress of the solution.Evaluate the solution to determine if you chosethe right alternative.

The ninth step is to follow up on the solution.You want to formalize the solution, especiallyif the problem is recurring. If possible, youwant to go to the root cause of the problem andmake sure the problem doesn’t come up again.If not, you want to ensure you identify the nextoccurrence of the problem early and applywhat you learned from solving the problembefore. You don’t want to go to all the troubleto figure out how to solve a problem and nothave your solution formalized and at the readyto solve the problem again.

The tenth step is to iterate on the solution forcontinuous improvement. Your skills for it-eration and recursion help you know when toapply what you learned in earlier steps toimprove the steps next time through. Theresemblance to the Plan-Do-Study-Act (PDSA)Cycle occurs because both the PDSA Cycleand problem solving stem from the scientificmethod.

Clearly, problem solving is an opportunity tointegrate your skills. As an integrator, prob-lem solving cross-cuts all the categories ofskills.

680

THE TEN STEPS FOR PROBLEM SOLVINGCROSS-CUT THE SKILLS CATEGORIES.

• Identify the problem

• Determine goals and objectives

• Study the problem

• Develop solution alternatives

• Evaluate the alternatives

• Choose an alternative

• Formalize an action plan

• Implement the solution

• Follow-up on the solution

• Iterate for continuous improvement

Figure 1.5.5.6. The ten problem solving steps reflect the scientific method leading to a resem-blance with the PDSA Cycle.

681

682


1.5.5.7. THE SKILL OF UNDERSTANDING THE SYSTEM LIFE CYCLE .

Understanding the system life cycle puts the other skills of the management systemengineer into context.

The system life cycle is the framework for theengineering process, the process by which weimprove organizations and build, select, orchange management tools. As such the func-tions of the life cycle discussed in Module1.1.20.1. tell us where each of the skills high-lighted in Module 1.5.5.2. fit into the engineer-ing process. Even though the skills describedcan be effectively used in the managementprocess, I’ve highlighted them here to indicatetheir importance in carrying out the engineer-ing process. I’m not surprised by the effective-ness of these skills in both the management andthe engineering processes because both pro-cesses have the same root: the scientific method.

The understanding and use of the system lifecycle, either for the engineering process or forthe organization life, is a skill in and of itself.I might call the role needed for exercising thisskill that of a system synthesist. Of course, Ibelieve the management system engineer mustbe able to play both roles and to find the rightbalance between the roles. The skills may bethe same or similar for playing both analyst andsynthesist roles, but each role dictates how theskills will be used. Even the ability to makesuch a balance indicates an associated skill.

Developing a management tool isn’t a simple

process. We recognized that problem whenwe saw the complexity in the system life cyclein Figure 1.1.20.1. To develop a managementtool, the management system engineer must beable to 1) identify the information require-ments of the decision maker (Recall manage-ment system analysis.), 2) design the manage-ment tool to convert the needed data into theinformation to meet the requirements, 3) buildthe management tool to carry out the design, 4)make sure the designing and building of themanagement are conducive to the dismantlingand replacement of the tool when the toolbecomes obsolete, and 5) prepare the neededdocumentation, training, and project manage-ment to support the design, building, and useof the tool. Recall that these five activities arethe analysis, design, implementation, follow-up, and follow-through groups of functions ofthe framework of the engineering process.

The way in which the framework of the engi-neering process is applied differs from situa-tion to situation. The skills required to carryout the framework are broadly transferable.The skills for identifying needs and solvingproblems transcend any methodology or anydiscipline. These skills are needed for ad-dressing any problem and building any solu-tion.

683

684


1.5.5.8. AN INFORMATION SYSTEM NEEDS THE SYSTEMS APPROACH.

Everyone has some form of information sys-tem. Some information systems are primitive,but they are indeed information systems. Theinformation system may be misunderstood orpoorly suited to the organization. Such fail-ings put managers and their system at crosspurposes.

The way you manage can result from the state-of-the-art in establishing an information sys-tem. For example, in the Roman Empire, ittook weeks or months to transfer informationto and from the outposts. Therefore, the terri-tories were given a great deal of autonomy toset policy and make decisions. With betterinformation systems, authority can be focusedbetter.

The existence of an information system doesnot imply the existence of the systems ap-proach. You are familiar with your informa-tion system and it has worked to some degree.It reflects history and the real world. Assuggested in Figure 1.5.5.6., don’t abandon orabuse your existing information system. Thereare reasons why you have the informationsystem you do—they probably are good rea-sons. You must know these reasons beforeturning to a new information system. Yourexisting information system is the first itera-tion in the process to develop your new infor-mation system.

Know Your Domain and Your Role WithinIt.Microcomputer or no microcomputer, main-frame or no mainframe, you should analyzewhat it is you manage. The reason you must dothat for computers is that they only do auto-matically what we tell them to do—we have to

tell them things to do that will be helpful to usand work toward our mission. Otherwise theywill do something, and a random selection willresult in much harm.

I remember a day when I needed to assemblea number of notebooks for a prototype work-shop on office automation. The 500 pageswere to be divided by tabs; but, because of thelast minute rush, the decision had been madenot to number the pages. I knew very wellwhere each page belonged; but, to get ready toleave for the workshop, I wanted my ownworkers, who are intelligent, logical, and knowmy idiosyncrasies, to assemble the books forme. If I led the process and the workersthrough the assembly we could assemble thebooks, otherwise for that one afternoon the jobcouldn’t be done.

The bottom line is that even though I knewvery well what I was doing and could do itmyself, I could not in that short time tell myworkers well enough how to do the job bythemselves. (Later we numbered the pagesand had the time for the workers to learn howto assemble the books.) Most importantly, if Ididn't know the process well enough to tell mypeople how to do the job, surely I didn’t knowthe process well enough to tell the computerhow to do it.

For this reason, most of us have experiencewith automation specialists who repeatedlyfail us. If we don’t know what we manage wellenough, surely the automation specialistdoesn’t. To deal with computer systems analy-sis you must balance a thorough understand-ing of your information needs and the avail-ability and characteristics of automation.

Systems analysts can do more good than harm, if they and you practice the systemsapproach.

685

Systems Analysts Will Help, If You KnowYour Stuff.Computer and information or automation or-ganizations are service organizations. I learneda rule from being such a service organization.That is, “Never mess with the guy’s opera-tion.” Do not ask him to change “what ismanaged” or “who manages” to make it easierto develop tools for him. Otherwise, you'llthrow the management system out of balanceor cause it to fail to meet its’ objectives. Youmust insist that the service organization leaveyour operation alone. I have seen automation

drive companies to bankruptcy—these werenot hardware or software problems; they al-ways were a fit problem.

Both you and the information specialist shouldrecognize each other’s responsibilities. Theinformation specialist provides a service orsupport function to you. Without knowledgeof your information needs, the informationspecialist can do nothing more than tell you thewonderful things automation is capable of ac-complishing.

Figure 1.5.5.8. “Good-by, Junior. We’re tired of you.”

686


1.5.6. SKILL LIST WITH MODULE REFERENCES

687

688


1.5.7. EXERCISE ON SKILLS

If you know which of your skills are transferable and what they’re transferrable to,you can determine your perceived value by a person who needs someone with skill tocontribute to their organization.

ExplanationYou’ve been developing skills since you wereborn. Some skills you learned at home and inthe community and others you learned at schooland in the workplace. Many of your skillsseem personal but are applicable to your workresponsibilities. Learning to cross stitch wellteaches you paying attention to detail. Skill atputting together large jigsaw puzzles impliesyou are good at seeing a long, tedious effortthrough to its end. Skill derived in high schoolgeometry indicates you can develop a logicalsolution to a problem.

You can transfer some of your skills to a largenumber of different situations. The skill ofcross stitching is limited to situations whereyou want to do decorative needle work. Theskill of paying attention to detail is broadlyapplicable to figuring out and solving a host ofdifferent problems and to doing a completeand thorough job in any line of work. Whatyou learned from your life’s experiences andhow you understand the range of applicability

of what you learned affect your skills and theirtransferability.

ExerciseMake a list of skills you believe you’ve devel-oped. After each skill, briefly identify (with aphrase, if possible) a situation where you’vedisplayed that skill. You want a situation thatwould convince a stranger that you indeedhave that skill. Don’t be limited by my lists ofskills in earlier modules.

Group the skills into three groups: high, me-dium, and low transferability. As you think oftransferability, think of using your skills indifferent work situations. Make sure you haveat least a few skills in each group.

Which of your skills do you think are mostvaluable to a prospective employer? How doyou show those skills to a prospective em-ployer? Where did you get the skills mostvaluable to a prospective employer?

689

690

691

1. BACKGROUND


CATEGORIES

1.5.8. THE

COMMUNICATION

SKILL

692

BACKGROUND/TOOLS AND SKILLs CATEGORIES/THE COMMUNICATION SKILL

1.5.8.1. THE MESSAGE ISN’ T IN THE WORDS—FRANCOIS BOUCHER

693

694

BACKGROUND/TOOLS AND SKILLS CATEGORIES/THE COMMUNICATION SKILL

1.5.8.2. COMMUNICATION SKILLS FOR SYSTEM ANALYSTS

Communication is probably one of the two most important skills you can develop foryour professional advancement. The other important skill is information gathering.

Often total strangers will need to coordinateand integrate their efforts to produce a respon-sive management tool to support a manager inhis or her domain of responsibility. For ex-ample, a project for developing a managementtool requires the participation of people withmany different interests and backgrounds andfrom different disciplines. To coordinate thesediverse people, this project needs effectivecommunication programs directed to the spe-cific information requirements of all the peopleinvolved. Some of these people are users,computer professionals, and top-level manag-ers. The project leader must create a commu-nication structure for delivering the informa-tion people need to do their jobs. A goodsystem analyst should be at the center of thiscommunication network. A system analystmust be able to speak the language of most, ifnot all, of the people working on or interestedin the tool.

Who’s Your Audience?A primary responsibility of the system analystin any project is to identify the audiences oftheir communications and the needs of thoseaudiences. Rudolf Flesch says you shouldimagine yourself talking about this subject tothis person at lunch. In other words, thinkabout your audience before you begin writing.The needs of the audience must determine thecontext and purpose of the message. A simpleapproach to effective communication in anysystems development project implies you mustknow your audience, understand their inter-ests or motivation, and their information needs.Three formal communication activities ofmanagement tool development projects in-clude: problem solving work sessions, techni-

cal reviews, and reports (written and oral pre-sentations). These activities represent situa-tions in building management tools whereyou’ll need to exercise your communicationskills.

Problem Solving Work SessionsLet’s begin with problem solving work ses-sions as an example of a setting a systemanalyst would find where he or she would needto practice communication skills. Systemanalysis is problem solving. The overall prob-lem being solved is made up of hundreds ofsmaller subproblems. Members of the projectteam will address one or more of these sub-problems each day. According to Powers,Adams, and Mills, the best problem solvingmodel involves objectivity when looking at aproblem. They define five simple and directsteps to objectivity in problem solving. (Pow-ers, Adams, and Mills, Computer InformationSystems Development: Analysis and Design,South-Western Publishing Co., 1984, p. 218.)

Step 1: State the problem clearly, separatinglarge problems into individual smallerones.

Step 2: Analyze the problem for its probablecause.

Step 3: Identify alternatives for eliminating thecause.

Step 4: Consider the consequences of thesealternatives.

Step 5: Choose the best alternative.

695

review their roles and skills in following theprocedures laid out in the plan and using theresources available in the room that makes upthe emergency operating center.

People who do a walk-through simply identifythe strengths and weaknesses in the intermedi-ate products in the development of a manage-ment tool. Some example development prod-ucts are data flow diagrams, program structurecharts, collections of input or output docu-ments, and test plans. These walk-throughpeople aren’t expected to act on what theyfind; they just find strengths and weaknesses.

A walk-through is just what it sounds like.People who’ll use or develop the managementtool and others who want the tool to work walkthrough the tool, its features, and its use. Theypretend they’re exercising the tool. They putthe tool through its paces.

Walk-through is a term coined in the MISbusiness for testing and improving computer-based information systems. In planning (pri-marily emergency planning), this activity iscalled a table-top exercise. Those people withresponsibilities defined in the plan sit aroundthe table and pretend they’re carrying out theirresponsibilities. As they play out their roles,they find problems in the plan. They fix theproblems. Then, when the plan is needed “todo its thing,” the glitches are out of it.

In developing a computer-based managementtool, usually three to five people will be in-volved in reviewing any particular intermedi-ate product. The author, or developer, of theproduct provides most of the information dur-ing the walk-through. For large projects, oneor more experienced system analysts will beappointed as administrator of walk-throughs.The administrator resolves any conflicts ordisputes and has authority to cut off any unpro-ductive discussion. Each walk-through ad-ministrator should also appoint a secretary

Compare these problem solving steps with thesteps in Module 1.5.5.6. Any problem solvingprocess emulates the scientific method. Effec-tive problem solving is done using groups ofpeople, some of whom know the problem andsome of whom have expertise in solution alter-natives. The key to bringing the right solutiontogether with the right problem is our commu-nication skills.

Technical ReviewsThe second category of communication ac-tivities is technical reviews. You can partici-pate in formal or informal technical reviews.Engineers tend to think of anything technicalas having to be based on physical science.However, technical review is the review of thecontent of a system or its associated processes(WWA or WWWTB) or projects (HTGT) asopposed to the review of the management orprogress of changes in the process or project.Therefore, you can conduct a technical reviewof any process, including those based on lifescience or social science as well as physicalscience.

A formal review includes the preparation of,transfer of, and interpretation of technical docu-ments and reports and oral briefings and brief-ing charts. An informal review includes walk-throughs, table tops, and observations of theprocess or project. The communication issuesin formal technical reviews are similar to thoseissues in reports, which I’ll discuss shortly.

To illustrate the communication issues in in-formal reviews, I’ll discuss what happens in awalk-through. In emergency management,we formalize a walk through a bit and conducta table top exercise. In a table top, the partici-pants in a potential emergency response gatherand review and test an emergency plan or aemergency operating center, both of which aremanagement tools. They review and test themanagement tools by using the tools in anhypothetical emergency situation. They also

696

(pp. 225-226) list five steps to be used inorganizing a message. The five steps are:

Step 1: Identify audience needs and setpriorities.

Step 2: Collect all relevant information.

Step 3: Start the presentation (message) withthe most important item, then supportthis initial statement.

Step 4: Analyze and critique the content of themessage.

Step 5: Use only enough time or words todeliver a message that meets theinformation needs of the audience.

This approach works equally well with writtenreports and oral presentations. I’ll discuss theskills needed for both written reports and oralpresentations shortly. Now, I’ll highlight thecommunication activities management tool de-velopers participate in.

Examples of written reports include manage-ment summaries, progress reports, proceduresmanuals, training manuals, and many others.We use graphic information portrayal, such asdata flow diagrams and structure charts, inwritten reports. Management summaries areused as a basis for decision making and there-fore should include recommendations for so-lutions and for actions. The managementsummary should be limited to a one-page totwo-page typewritten presentation. Often themanagement summary is written in “bullet”form. We’ll practice doing management sum-maries when we discuss the management pro-cess function, organizing and presenting in-formation.

Procedures manuals should do for people whatprograms do for computers. The guiding prin-ciple in developing a manual should be that

who has a thorough understanding of the prod-uct being examined. In table tops, we includepeople who observe the exercise and critiquenot only the management tool but those peopleparticipating in the table top.

A walk-through should be conducted in abusinesslike way with all parties participatingequally. Each member of the review teamshould receive an advance copy of the productthey’re reviewing. Additional walk-throughsmay be scheduled if they find rework require-ments during an earlier walk-through.

There are two end-product documents to awalk-through. One is a walk-through report,which is a brief, factual document identifyingthe product, author, date, names of partici-pants, and outcomes. Another end-productdocument of a walk-through is the manage-ment report. This report summarizes the walk-through report but doesn’t give a detailed listof errors found during the walk-through. If theparticipants accept the product, in full or inpart, they sign the management report. Theparticipants who sign this document shareresponsibility for the quality of the product.

Walk-throughs have some problems no matterhow expertly and professionally they’re con-ducted. One potential problem is when theproduct to be reviewed is too large, whichresults in a session taking too long. Anotherproblem occurs if participants aren’t givenenough time to review the document and pre-pare themselves. Often in walk-throughs, werush to give the participants review documentsat the last minute and the participants don’thave time to prepare properly for the walk-through.

Reports (Written and Oral Presentations)The third category of communication activi-ties is reporting (written reports or oral presen-tations). Reports deliver messages to identi-fied audiences. Powers, Adams, and Mills

697

tools to prepare the content of the projectmanagement review.

We give status reviews to keep user manage-ment current on the progress of the project.They are information sessions, not sales meet-ings.

Acceptance reviews consist of formal docu-ments prepared in advance and provided to thedecision makers. The purpose of an accep-tance review is to get approval for recommen-dations made.

Most guidelines for preparing written reportsapply equally to oral presentations. However,several special considerations also apply tooral presentations. An oral presentation shouldbe supported by visual aids that focus theattention of the participants on the topics beingdiscussed. Members of the audience should beencouraged to ask questions and participateactively in the discussion.

people are in the system because they’re ableto apply judgment. Procedures manuals shouldemphasize the importance of the results andcontain items to help build human understand-ing and interest.

Training manuals should be designed as easy-to-use references. No trainer can teach every-thing needed for smooth, continuous opera-tion of a computer information system or anyother management tool. This kind of skill andexperience can only be built on the job. Effec-tive training programs teach operators to learn.

Another type of report is an oral presentation,which may fall into at least three categories:project management reviews, status reviews,and acceptance reviews. Project managementreviews include reports of progress during thecurrent week, completion of tasks, time re-maining for tasks in process, reviews of par-ticular problems encountered, or tasks about tobegin. I’ll outline a set of ten simple tools forproject management shortly. You’ll use these

698

699

1. BACKGROUND


CATEGORIES

1.5.8. THE COMMUNICATION

SKILL

1.5.8.3. WRITTEN

COMMUNICATION I

700


1.5.8.3.1. AUDIENCE PLUS PURPOSE EQUALS DESIGN.

How do we design an information portrayal sowe can effectively work the information por-trayal to information perception interface inthe Management System Model? Lou Middle-man has the most valuable answer to thatquestion in his simple equation: Audience pluspurpose equals design. Whether you’re plan-ning what to say or what to write, alwaysconsider: Audience plus purpose equals de-sign. You design the oral or written portrayalby considering in similar measure both thepurpose of your communication and the audi-ence to whom you’re aiming the information.

When discussing the skill of communication,I choose first to look at written communica-tion, because the written form is more tan-gible, is easier to look at again, and is useful fordiscussing both written communication andcommunication in general. The two best piecesto read to learn how to communicate in writingeffectively are Lou Middleman’s In Short(Louis I. Middleman, In Short: A ConciseGuide to Good Writing, St. Martin’s Press,Inc, New York, 1981) and Rudolf Flesch’s OnBusiness Communications (Rudolf Flesch, Onbusiness Communications: How to Say WhatYou Mean in Plain English, Barnes and NobleBooks, New York, 1972).

Both books speak to the way to write effec-tively and what to consider in writing so you’llhold your audience’s attention. Neither spendsmuch time on grammer, punctuation, or sen-tence structure. What we want in writing is toeffectively transfer the information we want toget from us to some audience. Lou Middlemanputs it well when he indicates that the issue inspelling or grammer is that if we do it wrong,

we distract the reader. The reader can usuallyfigure out what word we mean or what thegrammer should be. But, why ask the reader todo that much work? The reader won’t. If thereader has too much (really not much at all)trouble in finding out what he or she mightwant from what we’ve written, the reader willabandon what we’ve written.

When we set aside the issues of punctuationand spelling and so on, what’s left? How do wecommunicate so the audience will stick withour communication long enough to get ourmessage? How do we communicate so theaudience will get the message we intend?Middleman and Flesch get into the specifics ofissues like writing like you speak, spilling thebeans, getting to the point, writing for thinkingversus writing for communicating, using shortsentences, and more. Middleman tends to bemore intuitive and Flesch tends to be moresensing. Probably, your personality type willdictate which you like best.

One of Middleman’s issues is knowing theaudience of what you write. Later, I’ll talkabout matching the reader’s and writer’s pur-pose. Now, let’s think about how important orurgent what you write will be to the audience.Stephen Covey urges us to focus on what’sboth urgent and important rather than justwhat’s urgent. He also argues that the impor-tant should come before the urgent. Considerimportance and urgency when you decide towrite. In business writing, we often writememos. Do you expect the reader to readeverything you write? Of course, you do.Otherwise, you wouldn’t write it. Do you readevery word of what people write to you? Of

When you communicate you must match the purpose of the information senderto the purpose of the information receiver.

701

course, you don’t. You don’t have time. Theage of information has gotten out of hand. Wecan’t read everything every writer has laboredso hard to put in front of us. So, we choose.

When I look at my in-box material I stand overthe trash can. Most of what I get I never open.I use the return address on the envelope or thesubject heading on the memo to decide whetherto trash the document. Sometimes I lose timebecause I throw away something I should haveread at least the first sentence of. Then, I haveto use some of the time I saved by throwingmost of my in-box away. What do you want

me to do with what you write? Consider howimportant or urgent I’ll feel your document isbased on at most the first sentence. Figure1.5.8.3.1. is a scale for the importance andurgency of memoranda. What I consider 1through 7 on the scale, I never get to. You wantme to consider what you write a 10. In Figure1.5.8.3.1., Middleman indicates that a 10 onthe scale requires a reason (because) for read-ing a memorandum immediately. You mustknow the because before you write the docu-ment to have any chance for me to have abecause to compel me to read what you wrote.

MIDDLEMAN’S IMPORTANCE/URGENCYSCALE FOR MEMORANDA

No rush; readonly if infinitelycurious orparanoid; File Read on

the johnif you’re bored.

Read duringinsomnia.

Read firstthing thisa.m. or tomorrowa.m.

Stopwhateveryou’re doing!Read and respond atonce.

Read immediatelybecause_______.

(An I/U number should follow each name on thedistribution list; the number may differ for differentrecipients.)

Note: A “9” or “10” must be accompanied by a “because.”

1 2 3 4 5 6 7 8 9 10

Figure 1.5.8.3.1. What is the reason (because) for me to read your document immediately?

• In a memo, you have at most two sentences to grab your reader.

• No reader should have to ask, “Why is so-and-so telling me this?” It’s dis-courteous to waste someone’s time. Actually, it’s murder, stealing life, be-cause all we have is time.

702


1.5.8.3.2. SCOPING YOUR AUDIENCE

5. Consider the following issues first for theprimary reader and then for the secondaryreader.

a. What is his or her communication level(education, understanding of terms, expe-rience, knowledge of the topic or field,etc.)?

b. What is his or her position relative to actingon what you propose or discuss in yourdocument (position, relationship to you,responsibility, etc.)?

c. What is his or her attitude toward the sub-ject (interest, history, motivation, concern,issues, etc.) before reading your document?

d. Why would he or she want to read yourdocument (need, importance, urgency,etc.)?

e. What do you want him or her to do after heor she reads your document (action, re-sponse, etc.)?

f. What do you need to say to get him or herto do that?

g. What attitude do you want him or her tohave toward the subject after reading yourdocument?

h. What attitude do you want him or her tohave toward you after reading your docu-ment?

i. What do you need to say to get him or herto feel that way?

How do you figure out your audience whenyou write a memorandum? The first hardquestion is: Who’s the audience? Often, youdon’t know exactly who’s going to read whatyou write. Often, more than one person willread your writing, and the people are quitedifferent one from the other. When you writea love letter, it’s easier. You’re writing to oneperson that you’ve spent some time trying tofigure out what’s important to him or her, whyhe or she should hear what you have to say,what he or she wants to hear, and how he or shewants to hear it.

It’s almost impossible to write a documentthat’s equally effective for two or more people.I don’t suggest using the same letter for two ormore lovers. Tailor each letter to each lover.Likewise, don’t send the same memo to two ormore bosses. Consider the following issueswhen you scope out the reader of your memo-randum. I’ll include issues for a primaryreader and a secondary reader. If you’re writ-ing to a bunch of people, I suggest you pick outone person to focus on and try to make thatperson the one who is most important to you inthe bunch. Then try to group all the rest as thesecondary reader.

1. When did you determine that you need towrite the document?

2. When does the document have to be delivered?

3. What is the subject of the document?

4. If you need a title, what title reflects whatyou want the reader to conclude fromreading the document?

If you expect your audience to read what you write, you must know your audience wellbefore you write.

703

6. Why (motivation, purpose, outcome, etc.)are you writing your document?

7. What do you want to accomplish in yourcareer or financial position as a result ofwriting your document?

8. What resources (library, people, documents,etc.) do you need to prepare yourd o c u -ment?

9. What information (facts, data, informa-tion) do you need to prepare your docu-ment?

10.What visuals (graphs, photographs, draw-ings, etc.) do you need to include in yourdocument?

11.What constraints do you have on the docu-ment (style, length, etc.)?

12.What form (letterhead, binding, color, etc.)do you want to put the document in?

13.How many copies will you need to make ofthe document and where will they go?

I suggest that before you write a document youcarefully answer these questions. Based onthe answers, you can write down what you’rethinking. Middleman says that we use writingto help us think through what we want tocommunicate. When we write to think, we’rewriting things down. He says that we usewriting to help us transfer information. Whenwe write to communicate, we’re writing thingsup.

What we write down is good for thinking andlousy for communication. When we think, wemake wrong turns, say the same thing in differ-ent ways, put extraneous information in toremind us of something else, and so manyother cumbersome and messy techniques. Thisextra structure, or scaffolding, gets in the waywhen we try to communicate. Before writingthings up, we have to identify and tear awaythe scaffolding so we can see the creation weworked so hard to build. Now, we want tocommunicate what we’ve exposed by remov-ing the extraneous stuff and crisply stating theimportant stuff.

704


1.5.8.3.3. GUIDES FOR WRITING

Guides for writing are legion. Here are a fewfrom Lou Middleman.

1. Writing is an highly idiosyncratic, non-linear, recursive process of inventing andrehearsing, drafting, revising, and rewrit-ing. Writing begins anywhere between“Oh, Oh!” and “Aha!” and ends when thewritten product is abandoned. Writingbegins before the first word and ends be-fore the last.

2. Write first to find your thoughts, then toplease yourself, finally to shape the mes-sage to the reader’s needs.

3. All effective writing is persuasive: it mustpersuade a reader to go on.

4. Audience plus purpose equals design.

5. Trust your sense of simplicity, clarity, andconciseness. It is easier to muddy a clearstatement than to rescue clarity fromgobbledygook or drivel. When appropri-ate, inform your audience, up front, thatfor the sake of clarity you have deliber-ately departed from its formal expecta-tions of style and word choice (specify), sohe or she won’t respond to your writing asan accident, a mistake from which youmust be saved.

You abandon any communication. When Ispeak, I can see people shift their attention.

Then I know I have to do something to getthem back. You abandon any written docu-ment. Your eyes may look at the words, butyour mind has gone somewhere else. Totransfer information, I need your mind, notyour eyes. When you write, do so knowingthat your audience will mentally and thenphysically abandon what you write. The ques-tion is : How long can you keep his or herattention?

Crispness is a guiding rule for the managementprocess. Crispness means simplicity, clarity,and conciseness and also means strength. I’lldiscuss crispness at length when I discuss theguiding rules for the management process.

One way to be unclear is to write in the passivevoice. I suggest you write in the active voice.When you want to be obtuse or unclear (and,unfortunately, you’ll want to do that some-time), you can go back and change the word-ing. If you write clearly, you can be unclear onpurpose. If you write unclearly, you can’t beclear on purpose.

You can write about your writing or speakabout your speaking. You can write thatyou’re using a certain kind of jargon or thatyou’re writing in a very personal style for apurpose.

Lou Middleman likes to list six rules to help uswrite better. I’ve included the six rules inFigure 1.5.8.3.3.

To write effectively, keep it simple, spill the beans, consider your audience, and be active.

705

SIX “RULES THAT ONE CAN RELYON WHEN INSTINCT FAILS”*

• Never use a metaphor, simile, or other figure of speechwhich you are used to seeing in print.

• Never use a long word where a short one will do.

• If it is possible to cut a word out, always cut it out.

• Never use the passive where you can use the active.

• Never use a foreign phrase, a scientific word, or a jargonword if you can think of an everyday English equivalent.

• Break any of these rules sooner than say anything outrightbarbarous.

*from George Orwell’s “Politics and the English Language”

Figure 1.5.8.3.3. These six rules will help you write better.

706


1.5.8.3.4. USAGE OF THE PASSIVE VOICE

Read Kent Porter, "Usage of the Passive Voice,"Technical Communication, First Quarter 1991,Vol. 33, pp. 87-88.

707

708


1.5.8.3.5. TO BE OR NOT

Read DeWitt Scott, "To Be or Not," Journalof Management Consulting, Spring 1992, pp.50-51.

709

710


1.5.8.4. COMMUNICATION IN BITS—GEORGE SEURAT

711

Date post:	10-Jun-2018
Category:	Documents
Upload:	buidung
View:	213 times
Download:	0 times

BACKGROUND/TOOLS AND SKILLS CATEGORIES · 2000-08-30 · one’s knowledge effectively and readily...

Documents