Copyright Irwin/McGraw-Hill 1998 1 Interpersonal Skills and Communications Prepared by Kevin C....

Prepared by Kevin C. Dittman for

Systems Analysis & Design Methods 4ed

by J. L. Whitten & L. D. BentleyCopyright Irwin/McGraw-Hill 19981

Interpersonal Skills and Communications

Introduction

The chapter will address the following questions: How do you perform the six guidelines for doing effective

listening? What are the four speaking styles and what are the situations

where you would use each? What are examples of both benefit terms and loss terms, and what

are the responses that they would elicit from the audience? What are body language and proxemics and why does a systems

analyst care about them?





Introduction

The chapter will address the following questions: What are the procedures to be able to prepare for, conduct, and

follow up on meetings, formal presentations and project walkthroughs?

What are the proper methods in writing business and technical reports?





Communicating With People

Introduction The systems analyst must have good if not impeccable

communications skills. The systems analyst’s best chance for success, to rise up the

corporate ladder is to possess outstanding communication skills.






Introduction Don Walton, a consultant on communications, quotes the CEO

and chairman of The Prudential Insurance Company of America in his book, Are You Communicating?

Starting my Prudential career as an agent, I understood quickly that although people may listen, they don’t always here. I had to make sure, therefore that my presentations were clear, concise, and to the point. In addition, I taught myself to listen and understand others, another crucial point in making sales.Clear communication is an important component of any career foundation. I have seen bright, ambitious people fail simply because they were unable to understand the importance of this. The person who has the ability to make his or her point simply and effectively, while clearly understanding what is being said by others, will have the best chance of success in a society and business environment as complex and multi-dimensional as ours.






Introduction One of the earliest recorded stories of communication problems -

The Tower of Babel.Once upon a time all the world spoke a single language and used the same words. As men journeyed in the east, they came upon a plain in the land of Shinar and settled there. They said to one another, ``Come, let us make bricks and bake them hard''; they used bricks for stone and bitumen for mortar. ``Come,'' they said, ``let us build ourselves a city and a tower with its top in the heavens, and make a name for ourselves; or we shall ever be dispersed all over the earth.'' Then the Lord came down to see the city and tower which mortal men had built, and he said, ``Here they are, one people with a single language, and now they have started to do this; henceforward nothing they have a mind to do will be beyond their reach. Come, let us go down there and confuse their speech, so that they will not understand what they say to one another.'' So the Lord dispersed them from there all over the earth, and they left off building the city. That is why it is called Babel, because the Lord there made a babble of the language of all the world; from that place the Lord scattered men all over the face of the earth.






Four Audiences for Interpersonal Communication during Systems Projects

For years English and communications scholars have told us that the secret of effective oral and written communications is to know the audience. Who is the audience during a systems development project? There are at least four distinct groups:

• System designers, other analysts and information systems specialists.

• System builders, the programmers and technical specialists who will actually construct the system.

• System users, the people whose day-to-day jobs will be affected, directly or indirectly, by the new system.

• System owners, who in addition to possibly being system users, sponsor the project and approve systems expenditures.






Listening The skill of listening may be the most important. For a systems analyst to be successful in working with customers

or users trying to solve their system problems, they must be able to listen to their problems understand what they are asking them to do.

As Thomas Gildersleeve states in his book, Successful Data Processing System Analysis, you must make a distinction between hearing and listening. “To hear is to recognize that someone is speaking, To listen is

to understand what the speaker wants to communicate.”






Guidelines in Effective Listening1 Approach the Session with a Positive Attitude:

No matter what your feelings are for the person you are working with, or the project as whole, approaching it with a negative attitude is fighting a losing battle.

2 Set the Other Person at Ease: Its no secret that one of the best ways to open a person up to

talking is presenting a nice, cheerful attitude. A good approach is to start by talking about the person’s

interest or hobbies. Showing an interest in their personal life sometimes can serve as an ice breaker and put them more at an ease.






Guidelines in Effective Listening3 Let Them Know You Are Listening:

Make it a habit to always maintain eye contact when listening and use a response such as a head nod or a “uh-huh” to indicate that you acknowledge what the other person is saying.

Always maintain good posture and even sit on the edge of your seat and lean forward.

4 Ask Questions: To make sure you clearly understand what the person is saying

or to clarify a point, ask a question to help you understand. This will show that you are listening and will also give the

other person the opportunity to expand on the answer.






Guidelines in Effective Listening5 Don’t Assume Anything:

One of the worst things to do is to get in a hurry and be impatient with the speaker.

• For example:

– You assume you know what the other person is going to say so you cut in and finish the sentence for them, possibly, missing entirely what the person was going to say, plus irritating the them in the process.

– You interrupt or stop the speaker because you may have already heard that information before or you believe it is not applicable to what you are doing, thus risking missing a valuable piece of information.






Guidelines in Effective Listening5 Don’t Assume Anything:

Art Linkletter learned this lesson on his popular television show, “Kid Say The Darndest Things” when he asked a child a philosophical question:“On my show I once had a child tell me he wanted to be an airline pilot. I asked him what he’d do if all the engines stopped out over the Pacific Ocean. He said ‘First I would tell everyone to fasten their seatbelts, and then I’d find my parachute and jump out.’ While the audience rocked with laughter, I kept my attention on the young man to see if he was being a smart alec. The tears that sprang into his eyes alerted me to his chagrin more than anything he could have said, so I asked him why he’d do such a thing. His answer revealed the sound logic of a child: ‘I’m going for gas…I’m coming back!”






Guidelines in Effective Listening6 Take Notes:

The process of taking notes serves two purposes. • By jotting down brief notes while the other person is speaking,

gives them the impression that what they have to say is important enough that you want to write it down.

• It helps you remember the major points of the meeting when you reference your notes at a later time.






Speaking Systems analysts need to be able to speak effectively in their work to

be successful. To be effective speaker is to deliver a clear and concise message

which is received and understood for its intended purpose, minimizing the risk of creating misunderstandings with your words. An Effective Speaking approach:

• Before speaking, organize thoughts to think about what the purpose for speaking is, what is the main point, who is the intended audience and what are the desired results.

• During speaking obtain feedback via oral response or body language to see if the message is being received and the desired results are being obtained.

– If not, you have the opportunity to alternate your approach and try again.






Speaking Keep in mind that different situations may call for different speaking

styles, just as different business writings call for different writing styles. There are four identified speaking styles:

• Expressive style. Spontaneous, conversational, and uninhibited. We use this style when we are expressing our feelings, joking around, complaining, being intimate or socializing.

• Directive style. Authoritative and judgmental. We use this style to give orders, give instruction, exert leadership, pass judgment, or state our opinions.

• Problem-solving style. Rational, objective, unbiased, and bland. This is the style most used in business dealings.

• Meta style. Used to discuss the communications process itself. Meta language enables us to talk about our interactions.






Use of Words: Turn-ons and Turnoffs Choosing the right words is important, especially to the systems

analyst who must effectively communicate with a diverse group of system users, owners, and builders.

There are two identified categories of terms that influence managers: benefit terms and loss terms. Benefit terms are words or phrases that evoke positive

responses from the audience. Benefit terms can be used very effectively to sell proposed changes. Managers will usually accept ideas that produce benefit terms.

• Examples are: increase productivity, increase sales, and reduce cost.






Use of Words: Turn-ons and Turnoffs There are two identified categories of terms that influence

managers: benefit terms and loss terms. Loss terms are words or phrases that evoke negative responses

from the audience. Loss terms can also be used very effectively to sell proposed changes. Managers will usually accept ideas that eliminate loss terms.

• Examples are: higher costs, excessive waste, and higher taxes. Avoid turn-off words or phrases such as jargon.

These can kill projects by changing the attitudes and opinions of management.

Avoid red-flag terms that attack people's performance or threaten their job.






Electronic Mail One of the newer forms of interpersonal communication of particular

importance to the systems analyst is electronic mail (E-mail). Electronic mail gives us the ability to create, edit, send, and

receive information electronically, usually using some type of computer network.

• The advantages are as follows:

– A person can send messages to and receive messages from someone almost instantaneously practically anywhere in the world (provided both people are linked together by some type of computer network). These messages can be read, stored, printed, edited, or deleted.

– Once the mail system software and computer network are in place, the actual cost of sending a message is very small.






Electronic Mail• The disadvantages are as follows:

– The sheer volume of electronic mail an individual receives may be overwhelming.

– Because it is so quick and easy to create a response to an electronic mail message and because mail users sometimes forget that they are communicating with another person via a machine, not with the machine directly, electronic mail messages are sometimes blunt, tactless, or inflammatory.

– Personal privacy is another concern.

– Electronic mail deprives its users of some of the richness of other forms of communication, such as tone of voice, facial expression, body language, etc.






Body Language and Proxemics Body language is all of the information being communicated by

an individual other than their spoken words. Body language is a form of nonverbal communications that we all use and are usually unaware of. Why should the analyst be concerned with body language?

• Research studies have determined a startling fact — of a person's total feelings, only 7 percent are communicated verbally (in words), 38 percent are communicated by the tone of voice used, and 55 percent of those feelings are communicated by facial and body expressions.

– If you only listen to someone's words, you are missing most of what they have to say!






Body Language and Proxemics We will focus on just three aspects of body language: facial

disclosure, eye contact, and posture. Facial disclosure means you can sometimes understand how a

person feels by watching the expressions on their faces. • Many common emotions have easily recognizable facial

expressions associated with them.

• However, you need to be aware that the face is one of the most controlled parts of the body.

• Some people who are aware that their expressions often reveal what they are thinking are very good at disguising their faces.






Body Language and Proxemics Eye contact is the least controlled part of the face.

• A continual lack of eye contact may indicate uncertainty.

• A normal glance is usually from three to five seconds in length; however, direct eye contact time should increase with distance.

• As an analyst, you need to be careful not to use excessive eye contact with a threatened user so that you won't further intimidate them.

• Direct eye contact can cause strong feelings, either positive or negative, in other people.

• If eyes are ``the window to the soul,'' be sure to search for any information they may provide.






Body Language and Proxemics Posture is the least controlled aspect of the body, even less than

the face or voice. • Body posture holds a wealth of information for the astute analyst.

• Members of a group who are in agreement tend to display the same posture.

• A good analyst will watch the audience for changes in posture that could indicate anxiety, disagreement, or boredom.

• An analyst should normally maintain an “open” body position signaling approachability, acceptance, and receptiveness.

• In special circumstances, the analyst may choose to use a confrontation angle of head on or at a 90 angle to another person in order to establish control and dominance.






Body Language and Proxemics Individuals also communicate via proxemics.

Proxemics is the relationship between people and the space around them. Proxemics is a factor in communications that can be controlled by the knowledgeable analyst.

People still tend to be very territorial about their space. A good analyst is aware of four spatial zones:

Intimate zone -- closer than 1.5 feet. Personal zone -- from 1.5 feet to 4 feet. Social zone -- from 4 feet to 12 feet. Public zone -- beyond 12 feet.






Body Language and Proxemics Certain types of communications take place only in some of these

spatial zones. For example, an analyst conducts most interviews with system

users in the personal zone. • But the analyst may need to move back to the social zone if the

user displays any signs (body language) of being uncomfortable. Sometimes increasing eye contact can make up for a long

distance that can't be changed. Many people use the fringes of the social zone as a ``respect''

distance.





Meetings

Introduction During the course of a systems development project, many

meetings are usually held. A meeting is an attempt to accomplish an objective as a result

of discussion under leadership. Some possible meeting objectives are listed in the margin.

The ability to coordinate or participate in a meeting is critical to the success of any project.





Meetings

Preparing for a Meeting Meetings are also very expensive because they require several

people to dedicate time that could be better spent on other productive work. The more individuals involved in a meeting, the more the

meeting costs. But because meetings are an essential form of communication, we

must strive to offset the meeting costs by maximizing benefits (in terms of project progress) realized during the meeting.





Meetings

Preparing for a Meeting Step 1: Determine the Need for and Purpose of the Meeting:

Every meeting should have a well-defined purpose that can be communicated to its participants.

• Meetings without a well-defined purpose are rarely productive. The purpose of every meeting should be attainable within 60 to

90 minutes, because longer meetings tend to become unproductive.

• When necessary, longer meetings are possible if they are divided into well-defined submeetings that are separated by breaks that allow people to catch up on their normal responsibilities.





Meetings

Preparing for a Meeting Step 2: Schedule the Meeting and Arrange for Facilities:

After deciding the purpose of the meeting, determine who should attend.

• The proper participants should be chosen to ensure that the purpose of the meeting can be attained.

• Some research indicates that the most creative problem solving and decision making is done in small, odd-numbered groups.





Meetings


The date and time for the meeting will be subject to the availability of the meeting room and the prior commitments of the various participants.

• Morning meetings are generally better than afternoon meetings because the participants are fresh and not yet caught up in the workday's problems.

• It is best to avoid scheduling meetings in the late afternoon (when people are anxious to go home), before lunch, before holidays, or on the same day as other meetings involving the same participants.





Meetings


The meeting location is very important. • Seating arrangement is particularly important.

– If leader-to-group interaction is required, the group should face the leader but not necessarily other members of the group.

– If group-to-group interaction is needed, the team members, including the leader, should all face one another.

• Make sure that any necessary visual aids (flip charts, overhead projectors, chalk, and so forth) are also available in the room.





Meetings

Preparing for a Meeting Step 3: Prepare an Agenda:

A written agenda for the meeting should be distributed well in advance of the meeting.

The agenda confirms the date, time, location, and duration of the meeting.

It states the meeting's purpose and offers a tentative timetable for discussion and questions.

If participants should bring specific materials with them or review specific documents prior to the meeting, specify this in the agenda.

The agenda may include any supplements — for example, reports, documentation, or memoranda — that the participants will need to refer to or study before or during the meeting.





Meetings

Conducting a Meeting Try to start on time, but do not start the meeting until everyone is

present. If an important participant is more than 15 minutes late, then

consider canceling the meeting. Discourage interruptions and delays, such as phone calls. Have enough copies of handouts for all participants. Review the agenda so that the discussion items become group

property. Cover each item on the agenda according to the timetable

developed when the meeting was scheduled. The group leader should ensure that no one person or subgroup

dominates or is left out of the discussion.





Meetings

Conducting a Meeting Decisions should be made by consensus opinion or majority vote.

One rule is always in order: Stay on the agenda and end on time!

If you do not finish discussing all items on the agenda, schedule another meeting.

Sometimes, the purpose of a meeting is to generate possible ideas to solve a problem. One approach is called brainstorming. Brainstorming is a technique for generating ideas during

group meetings. Participants are encouraged to generate as many ideas as possible in a short period of time without any analysis until all the ideas have been exhausted.





Meetings

Conducting a Meeting Brainstorming is a formal technique that requires discipline.

These guidelines should be followed to ensure effective brainstorming:

• Isolate the appropriate people in a place that will be free from distractions and interruptions.

• Make sure that everyone understands the purpose of the meeting (to generate ideas to solve the problem) and focus on the problem(s).

• Appoint one person to record ideas. This person should use a flip chart, chalkboard, or overhead projector that can be viewed by the entire group.





Meetings

Conducting a Meeting These guidelines should be followed to ensure effective

brainstorming:• Remind everyone of the brainstorming rules:

– Be spontaneous. Call out ideas as fast as they occur.

– Absolutely no criticism, analysis, or evaluation of any kind is permitted while the ideas are being generated. Any idea may be useful, if only to spark another idea.

– Emphasize quantity of ideas, not necessarily quality.





Meetings

Conducting a Meeting These guidelines should be followed to ensure effective

brainstorming:• Within a specified time period, team members call out their ideas

as quickly as they can think of them.

• After the group has run out of ideas and all ideas have been recorded, then and only then should the ideas be analyzed and evaluated.

• Refine, combine, and improve the ideas that were generated earlier.





Meetings

Following Up on a a Meeting As soon as possible after the meeting is over, the minutes of the

meeting should be published. The minutes are a brief, written summary of what happened

during the meeting -- items discussed, decisions made, and items for future consideration.

The minutes are usually prepared by the recording secretary, a team member designated by the group leader.





Formal Presentations

Introduction In order to communicate information to the many different people

involved in a systems development project, a systems analyst is frequently required to make a formal presentation. Formal presentations are special meetings used to sell new

ideas and gain approval for new systems. They may also be used for any of the purposes in the margin. In many cases, a formal presentation may set up or supplement a more detailed written report.

Effective and successful presentations require three critical ingredients: preparation, preparation, and preparation.






Introduction Formal Presentation Advantages:

Immediate feedback and spontaneous responses. • The audience can respond to the presenter, who can use emphasis,

timed pauses, and body language to convey messages not possible with the written word.

Formal Presentation Disadvantages: The material presented is easily forgotten because the words

are spoken and the visual aids are transient. • That's why presentations are often followed by a written report,

either summarized or detailed.






Preparing for the Formal Presentation As mentioned earlier, it is particularly important to know your

audience. The systems analyst is frequently thought of as the dreaded

agent of change in an organization. As Machiavelli wrote in his classic book The Prince,

There is nothing more difficult to carry out, nor more dangerous to handle, than to initiate a new order of things. For the reformer has enemies in all who profit by the old order, and only lukewarm defenders in all those who would profit from the new order, this lukewarmness arising partly from fear of their adversaries — and partly from the incredulity of mankind, who do not believe in anything new until they have had actual experience of it.

People tend to be opposed to change.






Preparing for the Formal Presentation A successful analyst must be an effective salesman.

To effectively present and sell change, you must be confident in your ideas and have the facts to back them up.

Step 1: Define your expectations of the presentation — for instance, that you are seeking approval to continue the project, that you are trying to confirm facts, and so forth. A presentation is a summary of your ideas and proposals that is

directed toward your expectations. Step 2: Organize your presentation around the allotted time

(usually 30 to 60 minutes).






Preparing for the Formal Presentation Step 3: Prepare visual aids such as predrawn flip charts, overhead

slides, Microsoft Powerpoint slides and the like — to support your position. Just like a written paragraph, each visual aid should convey a

single idea. To hold your audience's attention, consider distributing

photocopies of the visual aids at the start of the presentation. • This way, the audience doesn't have to take as many notes

Step 4: Practice the presentation in front of the most critical audience you can assemble. Have somebody raise criticisms and objections. Practice your responses to these issues.





I. Introduction (one-sixth of total time available)A. Problem statementB. Work completed to date

II. Part of the presentation (two-thirds of total time available)A. Summary of existing problems and limitationsB. Summary description of the proposed systemC. Feasibility AnalysisD. Proposed schedule to complete project

III. Questions and concerns from the audience (time here is not to be included in the time allotted forpresentation and conclusion; it is determined by those asking the questions and voicing theirconcerns)

IV. Conclusion (one-sixth of total time available)A. Summary of proposalB. Call to action (request for whatever authority you require to continue systems

development)






Conducting the Formal Presentation The following are guidelines that may improve the actual

presentation: Dress professionally. The way you dress influences people. Avoid using the word “I” when making the presentation. Use

“you”' and “we” to assign ownership of the proposed system to management.

Maintain eye contact with the group and keep an air of confidence. If you don't show management that you believe in your proposal, why should they believe in it?

Be aware of your own mannerisms. Some of the most common mannerisms include using too many hand gestures, pacing, and repeatedly saying ``you know'' or ``okay.''






Conducting the Formal Presentation Ways to Keep the Audience Listening:

Stop talking. The silence can be deafening. Ask a question, and let someone in the audience answer it. Try a little humor. Everybody likes to laugh. Tell a joke on

yourself. Use some props. Use some type of visual aid to make your

point clearer. Change your voice level. By making your voice louder or

softer, you force the audience to listen more closely or make it easier for them to hear.

Do something totally unexpected. Drop a book, toss your notes, jingle your keys.






Conducting the Formal Presentation Answering Questions:

Sometimes answering questions after a presentation may be difficult and frustrating.

We suggest the following guidelines when answering questions:

• Always answer questions seriously, even if you feel that it is a silly question.

• Answer both the individual who asked the question and the entire audience.

• Summarize your answers.

• Limit the amount of time you spend answering any one question.

• Be honest.






Following Up the Formal Presentation It is extremely important to follow up a formal presentation

because the spoken work and impressive visual aids used in a presentation do not usually leave a lasting impression. For this reason, most presentations are followed by written

reports of some kind that provide the audience with a more permanent copy of the information that was communicated.





Project Walkthroughs

Introduction A special type of meeting conducted by the analyst is called a

project walkthrough. The project walkthrough is a peer group review of systems

development documentation. Walkthroughs may be used to verify almost any type of detailed documentation such as ERDs, DFDs and program listings.

Peer group review tend to identify errors that go unnoticed by the analyst who prepared the documentation.






Who Should Participate in the Walkthrough? A walkthrough group should consist of seven or fewer participants. All members of the walkthrough must be treated as equals. The analyst who prepared the documentation to be reviewed should

present that documentation to the group during the walkthrough. Another analyst or key system user should be appointed as

walkthrough coordinator. The coordinator schedules the walkthrough and ensures that

each participant gets the documentation well before the meeting date.

The coordinator also makes sure that the walkthrough is properly conducted and mediates disputes and problems that may arise during the walkthrough.






Who Should Participate in the Walkthrough? The coordinator has the authority to ask participants to stop a

disagreement and move on. The coordinator designates a walkthrough recorder to take

notes during the walkthrough. The remaining participants include system users, analysts, or

specialists who evaluate the documentation. Walkthroughs should never last more than 90 minutes.






Conducting a Walkthrough All participants must agree to follow the same set of rules and

procedures. The basic purpose of the walkthrough is error detection, not error

correction. The analyst who is presenting the documentation should seek only

whatever clarification is needed to correct the errors. The analysts should never argue with the reviewers' comments.

A defensive attitude inhibits constructive criticism. Reviewers should be encouraged to offer at least one positive and

one negative comment in order to guarantee that the walkthrough is not superficial.






Conducting a Walkthrough After the walkthrough, the coordinator should ask the reviewers

for a recommendation. There are three possible alternatives: Accept the documentation in its present form. Accept the documentation with the revisions noted. Request another walkthrough because a large number of errors

were found or because criticisms created controversy.






Following Up on the Walkthrough The walkthrough should be promptly followed by a written report

from the coordinator. The report contains a management summary that states what

was reviewed, when the walkthrough occurred, who attended, and the final recommendation.





Written Reports

Introduction The business and technical report is the primary method used by

analysts to communicate information about a systems development project. The purpose of the report is to either inform or persuade,

possibly both.





Written Reports

Business and Technical Reports Systems Planning Reports:

While studying the business mission, the analyst will usually prepare a planning project charter for review, correction, and approval by the appropriate managers and staff.

During the definition phase, the analyst must prepare and present the information architecture and plan.

• This architecture and plan must be approved by both information systems manager and staff and system owners and users.

The evaluation phase, results in several important reports, including the business area plan, planned database and/or network development projects, and planned application development projects.





Written Reports

Business and Technical Reports Systems Analysis Reports:

After the survey phase, the analyst normally prepares a preliminary feasibility assessment and a statement of project scope, both of which are presented to a steering committee who make a decision concerning the continuation or cancellation of the project.

During the study phase, the analyst prepares and presents a business problem statement and new system objectives to verify with system users their understanding of the current system and analyses of problems, limitations, and constraints in that system.





Written Reports

Business and Technical Reports Systems Analysis Reports:

The definition phase, results in a business requirements statement.

• This specification document is often large and complex and is rarely written up as a single report to system users and owners.

• It is best reviewed in walkthroughs (in small pieces) with users and maintained as a reference for analysts and programmers.





Written Reports

Business and Technical Reports Systems Design Reports:

The next formal report, the systems proposal, is generated after the selection phase has been completed.

• This report combines an outline of the system user requirements from the definition phase with the detailed feasibility analysis of alternative solutions that fulfill those requirements.

• The report concludes with a recommended or proposed solution.

• This report is normally preceded or followed by a presentation to those managers and executives who will decide on the proposal.





Written Reports

Business and Technical Reports Systems Design Reports:

The design phase results in detailed design specifications that are often organized into a technical design report.

• This report is quite detailed and is primarily intended for information systems professionals.

• It tends to be quite a large report because it contains numerous forms, charts, and technical specifications.

The acquisition phase can generate several reports.• The most important report — the request for proposals — is used to

communicate requirements to prospective vendors who may respond with specific proposals.

• Especially when the selection decision involves significant expenditures, the analyst may have to write a report that defends the recommended proposal to management.





Written Reports

Business and Technical Reports Systems Implementation Reports

In a sense, the most important report is written during the construction and delivery phases.

• The user's manual and reference guide.

– This document explains how to use the computer system (such as what keys to push, how to react to certain messages, and where to get help).

• In addition to computer manuals, the analyst may rewrite the standard operating procedures for the system.

– A standard operating procedure explains both the noncomputer and computer tasks and policies for the new system.





Written Reports

Length of a Written Report The written report is the most abused method used by analysts to

communicate with system users. The following are guidelines to restrict report size:

To executive-level managers — one or two pages. To middle-level managers — three to five pages. To supervisory-level managers — less than ten pages. To clerk-level personnel — less than fifty pages.

It is possible to organize a larger report to include subreports for managers who are at different levels. These subreports are usually included as early sections in the

report and summarize the report, focusing on the bottom line: What's wrong? What do you suggest? What do you want?





Written Reports

Organizing the Written Report Every report consists of both primary and secondary elements.

Primary elements present the actual information that the report is intended to convey. Examples include the introduction and the conclusion.

Secondary elements package the report so the reader can easily identify the report and its primary elements. Secondary elements also add a professional polish to the report.





Written Reports

Organizing the Written Report Primary Elements:

Primary elements can be organized in one of two formats: factual and administrative.

• The factual format is very traditional and best suited to readers who are interested in facts and details as well as conclusions.

– We would use this format to specify detailed requirements and design specifications to system users.

– This format is not appropriate for most managers and executives.





Written Reports


Primary elements can be organized in one of two formats: factual and administrative. (continued)

• The administrative format is a modern, result-oriented format preferred by many managers and executives.

– This format is designed for readers who are interested in results, not facts.

– This format presents conclusions or recommendations first.

– Readers can read the report straight through, until the point at which the level of detail exceeds their interest.





Written Reports


Both formats include some common elements. • The introduction should include four components: purpose of the report,

statement of the problem, scope of the project, and a narrative explanation of the contents of the report.

• The methods and procedures section should briefly explain how the information contained in the report was developed — for example, how the study was performed or how the new system will be designed.

• The bulk of the report will be in the facts section.

– This section should be named to describe the type of factual data to be presented (e.g., “Existing Systems Description,” “Analysis of Alternative Solutions,” or “Design Specifications”).

• The conclusion should briefly summarize the report, verifying the problem statement, findings, and recommendations.





Factual Format Administrative FormatI. Introduction I. Introduction

II. Methods and procedures II. Conclusions and recommendationsIII. Facts and details III. Summary and discussion of facts

and detailsIV. Discussion and analysis of facts and

detailsIV. Methods and procedures

V. Recommendations V. Final conclusionVI. Conclusion VI. Appendices with facts and details





Written Reports

Organizing the Written Report Secondary Elements:

No report should be distributed without a letter of transmittal to the recipient.

• This letter should be clearly visible, not inside the cover of the report.

• A letter of transmittal states what type of action is needed on the report.

• It can also call attention to any features of the project or report that deserve special attention.

• In addition, it is an appropriate place to acknowledge the help you’ve received from various people.





Written Reports

Organizing the Written Report Secondary Elements:

The abstract or executive summary is a one- or two-page summary of the entire report.

• It helps the reader decide if the report contains information they need to know.

• It can also serve as the highest level summary report.

• Virtually every manager reads these summaries.

• Most managers will read on, possibly skipping the detailed facts and appendices.





Letter of transmittal

Title page

Table of contents

List of figures, illustrations, and tables

Abstract or executive summary

(The primary elements -- the body of the report, in either the factual or administrativeformat -- are presented in this portion of the report.)

Appendices





Written Reports

Writing the Business or Technical Report Writing can greatly influence career paths in any profession.

The following are some writing guidelines:• Paragraphs should convey a single idea.

– They should flow nicely, one to the next.

– Poor paragraph structure can almost always be traced to outlining deficiencies.

• Sentences should not be too complex.

– The average sentence length should not exceed 20 words.

– Studies suggest that sentences longer than 20 words are difficult to read and understand.





Written Reports

Writing the Business or Technical Report Writing can greatly influence career paths in any profession.

The following are some writing guidelines: (continued)• Write in the active voice.

– The passive voice becomes wordy and boring when used consistently.

• Eliminate jargon, big words, and deadwood.

– For example, replace “DBMS” with “database management system,” substitute “so” for “accordingly,” try “useful” instead of “advantageous,” and use “clearly” instead of “it is clear that.”





Initial preparation * Define objectives, scope and strategy * Clarify material * Define readership and method (length and standards)

Outline * Headings * Illustration Titles

Draft textDraft

illustrations

Rewrite/ edit

Final type

Proofread

Reproduce/ blind

Distribute

Check





Summary

Introduction Communicating With People Meetings Formal Presentations Project Walkthroughs Written Reports

Copyright Irwin/McGraw-Hill 1998 1 Interpersonal Skills and Communications Prepared by Kevin C....

Documents

Transcript of Copyright Irwin/McGraw-Hill 1998 1 Interpersonal Skills and Communications Prepared by Kevin C....