project management.docx communiction

39
Project Management Growing Significance in Today’s Business World More Competitive: Time, Resource, and Cost Management Requirements are More Demanding Projects: User Documentation, Presentations, Training Course Material, Sales Proposals, Marketing Data Sheets Project management is a subject of growing significance in today’s business world. As projects become increasingly complex, as managing time and resources becomes more unwieldy, and as competition increases, organizations are searching for more effective ways to manage the projects they undertake. A project is a task which must be completed within budget and by a specific time; which is usually, but not always, carried out at once. Examples include preparing a presentation for a major meeting, installing a computer system (including training documentation), or introducing a new product (including sales proposals and marketing data sheets). Technical Communications: Process

Upload: berhanu-tadesse

Post on 20-Jan-2015

199 views

Category:

Business


0 download

DESCRIPTION

Presentations for college trainers in particular place of Entoto TVET on project management.

TRANSCRIPT

Page 1: Project management.docx communiction

Project Management

• Growing Significance in Today’s Business World

• More Competitive: Time, Resource, and Cost Management

Requirements are More Demanding

• Projects: User Documentation, Presentations, Training Course

Material, Sales Proposals, Marketing Data Sheets

Project management is a subject of growing significance in today’s business world. As

projects become increasingly complex, as managing time and resources becomes more

unwieldy, and as competition increases, organizations are searching for more effective

ways to manage the projects they undertake. A project is a task which must be completed

within budget and by a specific time; which is usually, but not always, carried out at

once. Examples include preparing a presentation for a major meeting, installing a

computer system (including training documentation), or introducing a new product

(including sales proposals and marketing data sheets).

Technical Communications: Process

Duties and Skills of the Project Leader

• Plans and Coordinates Project Activities

• Project Completed On Time and Within Budget

• Work Well with Peers and Motivate Writing Team

• Excellent Oral and Written Communication Skills

• Manage Time, People, Resources, and Multiple Responsibilities

Effectively

Page 2: Project management.docx communiction

• Interview and Evaluate New Writing Candidates and Make

Recommendations to Management

• A documentation project leader (or manager) plans and coordinates the activities

of a documentation project. A project leader can be the sole writer on a project or

the lead writer on a larger, multi-writer project; ensuring that the project passes

quality checks, and is completed on time and within the budget set for it. To be

successful as a project leader, you must work well with your peers and motivate

the members of the writing team, have excellent oral and written communications

skills, manage time, people, resources, and multiple responsibilities effectively,

interview and evaluate new writing candidates, and make recommendations to

management.

Administrative Tasks for the Project Leader

• Anticipates Problems Affecting Project Group

• Schedules Writing and Production Resources

• Delegates Project Writing Tasks

• Forecasts Special Needs/Ensures They are Met

• Informs Management and Peers of Project Status

• The following are some administrative tasks performed by the project leader: 1)

anticipates problems affecting the project group, 2) schedules the writing and

production resources for the project, 3) delegates the project writing tasks, 4)

forecasts the special needs of the project and ensures that those needs are met, 5)

informs management and peers of the project status regularly,

Administrative Tasks for the Project Leader

• Creates Documentation Plans and Monthly Status Reports

Page 3: Project management.docx communiction

• Provides Management with Performance Evaluation Information for

Each Member of the Project Team

• Ensures that All Documentation Project Tasks are Completed

• Keeps Records of Project Activities

• 6) creates documentation plans and monthly status reports for all new projects, 7)

provides management with performance evaluation information for each member

of the documentation project team, 8) ensures that all documentation project tasks

are completed, and 9) keeps records of project activities.

Writing-Related Tasks for the Project Leader

• Provides Support, Mentorship, and Training

• Provides Technical Direction for the Writing Team

• Ensures that Documentation Standards Are Met

• Reviews Documentation for Readability, Accuracy, Consistency,

and Style

• Identifies Future Documentation Requirements

• Suggests and Implements Process Improvements

• The following are some writing-related tasks performed by the project leader: 1)

Provides support, mentorship, and training for the writing team members, 2)

provides technical direction for the writing team, 3) ensures that documentation

standards are met, 4) reviews documentation for readability, accuracy,

consistency, and style, 5) identifies future documentation requirements, and 6)

suggests and implements process improvements.

Client-Relation Tasks for the Project Leader

Page 4: Project management.docx communiction

• Explores Opportunities with Potential Customers

• Analyzes Customer Documentation Needs

• Negotiates Project Costs and Schedules

• Coordinates People, Budgets, and Schedules

• Primary Contact for All Documentation Issues

• Communicates All Relevant Project Information to the Members

of the Project Writing Team

• The following are some client-relation tasks performed by the project leader: 1)

Explores opportunities with potential customers, 2) analyzes customer

documentation needs, 3) negotiates project costs and schedules, 4) coordinates

people, budgets, and schedules, 5) acts as the primary contact for all

documentation issues, and 6) communicates all relevant project information to the

members of the project writing team.

Suggestions for Project Leaders

• Set Expectations and Manage Them

• Clearly Explain Your Expectations; Don’t Leave Anything Out

• Make It Clear: Developers Expected to Spend Time with Writers;

Documentation Part of Product

• Keep Channels of Communication Open

• Ask for the Product’s History, if Relevant to Learning More

About Product Features

• The following are some suggestions for project leaders: 1) Set expectations and

take the initiative to manage them, 2) give a clear explanation of your

Page 5: Project management.docx communiction

expectations; remember, what you do not say is just as important as what you do

say, so don’t leave anything out, 3) make it clear that developers are expected to

spend time with writers, and that documentation is an essential part of the product,

4) keep your channels of communication open to everyone, 5) if necessary, ask for

a history of the product, which may make you more aware of product features…

Suggestions for Project Leaders

• Remain Professional at All Times

• Detailed Planning = Professional Atmosphere

• Positive and Professional Attitude Lends to Credibility

• Ensure that Presentations are Professional: Examine Room,

Check Audio/Visual Equipment, Use Visual Aids at Every Opportunity

• 6) remain professional at all times, 7) produce detailed plans; it creates a

professional atmosphere, 8) have a positive and professional attitude; it lends to

credibility, 9) when making group presentations, the environment can be a help or

a hindrance to you. Be certain that your presentation is well received by taking the

following precautions: If possible, examine the presentation room beforehand,

ensure that the audio/visual equipment you need is available and operational, and

use visual aids when you can…

Suggestions for Project Leaders

• Establish a Respectful Relationship from the Start: Ask Client

About Their Preferred Way of Working, e.g., Email? In-Person? Regular

Meetings?

• Explain Your Role at Start of Project

• Attend Client Team Meetings (Denotes Control/Gains Respect)

Page 6: Project management.docx communiction

• Get to Know the Client: Meet with Each Developer Individually

at Start of Project

• 10) establish a respectful relationship: ask the client and members of the client’s

team how they would like to work (e.g., communicating by email, meeting in-

person, meeting regularly, etc.), 11) explain your role at the very start of the

project, 12) attend client team meetings; this shows that you as the writer are in

control, and gains the respect of the team, 13) get to know the client: try to meet

with each developer individually at the start of the project.

Suggestions for Project Leaders

• Look Around Client’s Office for Common Points of Interest;

Have Lunch or Coffee with Client

• Establishing a Rapport with Client Makes it Easier to Extract

Relevant Information for the Documentation

• Try to Have a Meeting for the First Draft Review with All

Reviewers: Saves the Time Spent Chasing Down Reviewers with Opposing

Viewpoints

• 14) look around your client’s office to see any indications of common points of

interest, or make a point to have lunch or coffee with your client 15) establishing a

rapport may make the client or developer more apt to talk to you throughout the

project, making it easier to extract relevant information for your document, and

16) when attempting to obtain review comments, try to have a review meeting for

at least the first draft. Go through the manual page-by-page, if necessary.

Everything should be settled during this meeting, so you won’t have to chase

down reviewers with opposing viewpoints later on. If there are significant changes

in subsequent drafts, similar review meetings should be conducted.

Typical Project Problems and Solutions

Page 7: Project management.docx communiction

• Problem: Getting Inaccurate End-User Information from the Developer

• Solution: Involve the End User at the Beginning of the Project

• The following presents common problems and solutions during most

documentation projects.

• ? Problem: Getting inaccurate end-user information from the developer.

• ? Solution: Involve the end user at the beginning of the project.

• Typical Project Problems and Solutions

• Problem: Gaining Permission to Obtain Input from a Potential User; Some

Project Managers Do Not Seem to Trust the Writer’s Capabilities in Dealing with

the End User

• Solution: Build Up Trust with the Project Manager; Explain How You Are

Going to Interview the End User; Anticipate Any Questions or Objections and

Prepare Your Responses

• Problem: Gaining permission to obtain input from a potential user. Sometimes the

project team coordinator (project leader or supervisor) does not seem to trust the

writer in dealing with the end user.

• Solution: Build up trust from the beginning of the project. Meet with the project

coordinator and explain how you are going to interview the end user. Anticipate

any questions or objections and have your responses prepared.

• Typical Project Problems and Solutions

• Problem: Getting the Most Out of the Interview with the End User

Page 8: Project management.docx communiction

• Solution: Watch the End User in Action; Some Users Are Too Busy or Not

Effective at Answering Questions; Observe and Ask Pertinent Questions to Gain

Information

• Problem: Getting the most out of the interview with the end user.

• Solution: Watch the end user in action. Some people are too busy or are not very

effective at answering questions. If you simply watch and ask pertinent questions

during the process, you can gain the information that you need more effectively.

Typical Project Problems and Solutions

• Problem: Not Getting Review Comments from a Key Reviewer and You

Feel Uncomfortable ‘Haunting’ the Reviewer

• Solution: Speak with Their Supervisor and Yours; Ensure that You

Documented and Communicated the Deadline for Draft Review Comments.

Arrange Review Meetings; Some Reviewers Have Trouble Documenting

Comments, but in a Meeting

They Can Express Their Comments Verbally

• Problem: Not getting review comments from a key reviewer and you feel

uncomfortable ‘haunting’ the reviewer.

• Solution: Speak with their supervisor; speak with your supervisor. Ensure that you

document the times you asked for comments and the turnaround time for

comments. When sending out drafts, state explicitly in your cover letter that if a

reviewer does not give you comments by a certain date, you will assume he or she

has approved the draft as is. Set up review meetings for documents. Some

reviewers may have trouble documenting their comments, but in a meeting they

can express their comments verbally.

• Typical Project Problems and Solutions

Page 9: Project management.docx communiction

• Problem: Client Dictates the Style and Content of the Manual, Creates

Document Templates, Does Not Believe in Documentation Plans, and Does Not

Include the Writer in Documentation Meetings

• Solution: Meet with the Client and your Supervisor; Explain (with

Discretion) that Writers Are Consultants Who Manage the Writing Effort Instead

of Passively Taking Advice and Direction from the Client; Maintain Writing,

Editing, Planning, and Scheduling Standards

• Problem: The client attempts to dictate the style and content of the manuals, set

writing deadlines, create templates for the documentation, and doesn’t believe in

documentation plans. The client has documentation meetings and does not include

the writer.

• Solution: Hold several meetings with the client and the writing supervisor. With

discretion, explain that the writers are consultants who manage the writing effort,

instead of passively taking advice and direction from the client. Adhere to high-

quality writing and frequent editing cycles. Explain that you may not be able to

continue the project without a documentation plan, and maintain reasonable

schedules. In most cases, a documentation plan should be drawn up when

producing a new document (or set of documents), or when developing a radically

new version of an existing product.

• Typical Project Problems and Solutions

• Problem: Availability of Developers

• Solution: Prepare a List of Questions and Meet with the Developer to Go

Over Them; Acknowledge that You Realize the Developer Is Busy; Prepare

Weekly Status Reports and Distribute Reports to Peers, Managers, and Clients;

Ask Developer to Delegate a Reliable Information Source; or Ask Developer’s

Page 10: Project management.docx communiction

Supervisor to Free Up Some Time for the Developer to Provide the Required

Information

• Problem: Availability of developers.

• Solution: Prepare a list of questions and meet the developer to go over them.

However, many developers may want to meet with you immediately; be prepared

for that too. Catch the developer walking by and say: “I know you’re very busy,

but I need a few minutes of your time to…do XYZ.” Prepare weekly status

reports. Distribute these reports to everyone who depends on the documentation,

including peers, clients, and managers. As a result, some peers, clients, and/or

managers may put the necessary pressure on the developers to help obtain what

you need. Ask the developer to delegate another (reliable) information source. Or

elevate the issue by asking the developer’s supervisor to free up some time for the

developer to give you what you need (for instance, reviewing documentation and

answering questions).

Managing Your Client’s Expectations

• Some Clients Expect You as the Writer to Write the

Documentation from Thin Air

• Educate Them About the Possible Sources of Information:

Interviews, Legacy Documentation, Functional Specifications, and

Other Sources

• Although some managers and engineers expect you to write the documentation

from thin air, it’s your job to educate them about the possible sources of

information, such as interviews, legacy documentation, functional specifications,

and other sources.

Expectations for Each Project Participant

Page 11: Project management.docx communiction

• Goals

• Problems

• Expectations

• Pressures (Time, Other Projects or Requirements)

• Options (Documentation Style, Tools, Design, Review Process, and

Others)

• Restrictions (Time, Decisions, Budget)

• Likes and Dislikes

• The following is a list of expectations and considerations which you can introduce

to your client at the beginning of the writing project. Each project participant

should take the time to define each category to the best of his or her knowledge:

Goals, problems, expectations, pressures (e.g., time, other projects or

requirements), options (e.g., documentation style, tools, design, the review

process, and others), restrictions (e.g., time, decisions, or budget), and likes and

dislikes.

Expectations for Each Project Participant

• Style of Work (Casual, Formal, Email, Team Meetings, One-On-

One Meetings, etc.)

• Special Needs (e.g., ? Section 508)

• Levels of Documentation Confidentiality

• Audience Profile and Task Analysis

• Language Translation Requirements (if Any)

Page 12: Project management.docx communiction

• Other expectations include style of work (e.g., casual, formal, email, face-to-face,

formal/informal meetings, meetings with the entire team, one-on-one meetings,

etc.), special needs (e.g., Section 508 for the reading or hearing impaired), levels

of documentation confidentiality, audience profile and task analysis (Who are

they? And how and in what context will they use the documentation?), and

language translation requirements (if any—What languages? And who will do the

translations?).

Sources of Information

• Information Sources Provide the Initial ‘Ball of Wax’

• Use Meetings/Draft Reviews to Continually ‘Play Catch’ with

Reviewers, Continually Growing and Refining This ‘Ball’ of

Information

• Start Out with a Rough Outline, Topic Headings and

Sentences, Then Paragraphs, Tables and Illustrations

• Information sources provide the initial ‘ball of wax’ of information. The project

consists of your throwing this ball of wax back and forth with your review team,

using meetings and draft reviews, and continually growing and refining this ball,

until the final product is ‘rolled’ out. It’s your job to find every which way to keep

the ball rolling. You’ll probably start out with a rough outline, then a topic

sentence for each heading, then paragraphs, then tables, then illustrations.

Potential Sources of Information

• Developers and Supervisors

• Functional and Design Specifications

• Marketing Specifications and Business Plan

Page 13: Project management.docx communiction

• Legacy Documentation and Development Plan

• Project Documents (Project Initiation Document, Project

Office Document, Business Vision, Use Cases, Analysis and Design, Test

and Phase Review Documents, and Others)

• The following list describes potential sources of information: developers and

supervisors, functional and design specifications, marketing specifications and the

business plan, legacy documentation, the development plan, project documents

(e.g., a Program Initiation document, a Project Office document, a Business Vision

document, Use Cases, an Analysis and Design document, a Test document, a

Phase Review document, and others).

Draft Reviewer’s Expectations

• Many Reviewers Are Unsure What Is Expected of Them

• Sometimes Perform Cursory Review Because “It’s the Writer’s

Job” to Publish the Documentation

• Some Reviewers Think They Should Concentrate on Correcting

Grammar and Rewriting Content

• Many reviewers are unsure of what is expected of them. Some shrug off the task

by giving the documents a cursory reading at best, feeling that it is solely the

writer’s job to publish the documentation. Other reviewers think they are expected

to be editors and correct grammar and rewrite content.

Reasons for Draft Reviews

• To Ensure Technical Accuracy: Does the Documentation

Accurately Describe the Way Things Work? the Screens? the

Procedures? Methods? Hardware Descriptions?

Page 14: Project management.docx communiction

• To Ensure Completeness: Are There Any Omissions? Is

Everything Covered that Needs to Be?

• Is the Document Readable? Do Explanations Follow a Logical

Progression? Are They Clear and Understandable? Do They Make Sense?

• To ensure technical accuracy, ask yourself: Does the documentation accurately

describe the way things work? the screens? the procedures? methods? hardware

descriptions? To ensure completeness, ask yourself: Are there any omissions? Is

everything covered that needs to be covered? Also, is the document readable? Do

explanations follow a logical progression? Are they clear and understandable? Do

the explanations make sense?

Reasons for Draft Reviews

• Is Too Much Material Covered?

• Are There Unnecessary Explanations? Figures? Sections? Chapters?

• Are Figures and Tables Helpful, Clear, and Accurate?

• Is There a Need for Additional Text? Figures? Or Other

Content?

• Are All References to Text, Figures, and Tables Accurate and

Appropriate?

• Good writing should have a flow to it, so that your reader doesn’t feel bogged

down or confused. Is too much material covered? Are there unnecessary

explanations? Figures? Sections? Or Chapters? Are the figures and tables helpful,

clear, and accurate? Are there places where additional figures are needed? Are all

references to text, figures, and tables accurate and appropriate?

Draft Review Instructions (Cover Letter)

Page 15: Project management.docx communiction

• Cover Letter Should Accompany Each Draft Review Copy

• ‘Draft Review Copy’ Written on Each Page

• For Online Documentation: Print Out Pages for a Standard

Hard-Copy Review, OR… Centralized Online Feedback Table on

Intranet—Follow Up with a Team Review Session of Electronic

Version via an Overhead Projector

• For a printed (or hard copy) draft, a cover letter should accompany each draft

review copy, explaining the need for a thorough review, and providing a deadline

for returning the draft with comments. The document should have ‘Draft Review

Copy’ written on each page (e.g., on the header, footer, or as a watermark in large,

shaded print). For online documentation, either print out all pages for a hard-copy

review and mark-ups; or better yet, develop an online tabular review sheet on the

intranet for centralized feedback. After all review comments have been resolved

and incorporated, meet with all reviewers to display the online documentation on

an overhead projector for further comments. This is the time to put your online

documentation in motion, while presenting your information architecture,

including the review of all hyperlinks.

Draft Review Phases

• Rough Draft (New or Drastically Changed Product)

• First Draft

• Second Draft (Final Draft)

• Signoff Draft

• During the course of a typical project there will be a number of reviews. Each

review has unique features for writers and reviewers. If the product is new, or

there are radical changes, and the development schedule allows for a rough draft,

Page 16: Project management.docx communiction

you should have four draft reviews: rough, first, second (final) and signoff.

However, if the product has been moderately revised, or there is not enough time

allocated to the project, then use three drafts: first, second, and signoff.

Rough Draft

• Usually Start This Draft with Functional Specifications and

Interviews with Developers

• Artwork, Screens, Menus, and Messages May Not Be Available

• Indicate Incomplete Sections

• Review Layout, Outline, Omissions, Accuracy of Descriptions

and Procedures

• Specific/Complete Review Comments Required: “???,”

“Huh?,” “Wrong,” Are Not Useful

• Usually a rough draft can be written, at least in part, from functional

specifications. Additional information can be obtained from speaking with

developers. Artwork, screens, menus, messages, etc. may not yet be available.

Indicate what sections of the document are incomplete because the information is

not available. As a reviewer (including you as the writer), answer the following

questions: Does the layout seem appropriate? Is the outline complete? Has

anything been left out? Are the descriptions and procedures accurate? Specific and

complete review comments are most helpful. A set of ‘???’ marks, or statements

such as “Huh?” or “Wrong,” are not useful.

First Draft

• ‘Flesh Out’ Headings and All Sections Should Have a Substantial

Amount of Text

Page 17: Project management.docx communiction

• Almost All Artwork, Screens, Menus, and Messages Should

Be Available

• Issues Regarding Layout, Outline, Omissions, Accuracy of

Descriptions and Procedures Should Have Been Addressed

• The first draft should be ‘fleshed out’: all headings and sections should include

some text to work with. Almost all artwork, screens, menus, and messages should

be available. Issues regarding layout, outline, omissions, and the accuracy of

descriptions and procedures should have been addressed.

Second (Final) Draft

• Almost Ready for Production

• Check for Accuracy and Completeness

• If Last-Minute Functional Changes Produce Numerous Changes

in the Draft, Incorporate Changes and Introduce Another Second (Final)

Draft—Notify Everyone that Schedule May Be Impacted

• The second (final) draft document should almost be ready for production. Check

carefully for accuracy and completeness. If there are any last-minute functional

changes, work closely with the developer so that these can be included in the

documentation. If these changes produce numerous changes in the document, do

not proceed to the signoff draft review. Instead, incorporate the changes and

introduce another second or final draft review; at least one covering the revised

sections. Make everyone aware that this may impact the schedule.

Signoff Draft

• Reviewer’s Last Chance

• Check that All Earlier Changes Have Been Made

Page 18: Project management.docx communiction

• Check that Last-Minute Changes Are Correct

• Read the Document Carefully

• Make Final Check for Accuracy and Completeness

• The signoff draft is the reviewer’s last chance to see the documentation before it

goes to print or, if it’s online, uploaded to the server. Here are some things to do

for the signoff draft: Check that earlier changes have been made. If there have

been last-minute changes, ensure that they are correct. Read the document

carefully; and make a final check for accuracy and completeness.

Releasing the Official Documentation

• Document Placed on Company Network

• Notify All Relevant Personnel

• Depending on Their User and Business Roles, Employees Can

Access the Documentation for Reading and/or for Internal/External

Distribution

After the draft review process has been completed successfully, the document is officially

released and placed on the company network. Notify all relevant users and designated

document distributors (e.g., Marketing managers, Product managers, Customer Service

managers, IT managers, and others). Depending on their user and business roles,

employees can access this document from the network for reading and/or for internal and

external distribution.

Documentation Monitoring and Control

• For Print Documentation: Title, Draft/Release Version Number,

Date of Release on Header and/or Footer of Each Page

Page 19: Project management.docx communiction

• Version Numbers: Draft = Non-Zero Right of Decimal Point (e.g.,

v0.1, v1.3, v2.7, etc.)

• Version Numbers: Official Release = Zero Right of Decimal

Point (e.g., v1.0, v2.0, v3.0, etc.)

• Archiving/Shredding to Conform with International Standards

(e.g., ISO 9000)

• For print documentation, indicate the document title, draft or official release

version, and release date in the header and/or footer of each page. Use a document

version numbering system for draft review copies, where the number to the right

of the decimal point is anything but a zero ‘0’, e.g., v0.1, v1.3, v2.7, etc. Officially

released document versions should be indicated by a zero ‘0’ to the right of the

decimal point, e.g., v1.0, v2.0, v3.0, etc. Archive and shredding policies need to be

established to comply with international standards.

Documentation Monitoring and Control

Typical Development Process for a Document:

1. Documentation Plan

2. Draft Review

3. Official Release and Implementation

4. Operation Change Order Form (if Applicable)

5. Documentation Control and Maintenance

2. The generalized steps above show a typical development process for a document:

1) Documentation Plan, 2) Draft Review, 3) Official Release and Implementation,

Page 20: Project management.docx communiction

4) Operation Change Order Form (if applicable), and 5) Documentation Control

and Maintenance. Note that in some cases, if document updates associated with a

new release comprise extensive changes, a revised documentation plan should be

drawn up before the draft review stage.

3.

Meetings

• Be Clear About the Purpose of the Meeting

• Prepare and Distribute an Agenda Prior to the Meeting Date

• Guarantee Participant Attendance

• Run Your Meeting Effectively

• Deal with Problem Participants

• Follow Up After the Meeting

• The following focuses on the elements of an effective meeting and the

responsibilities of the person running it: Be clear about the purpose of the meeting.

Prepare and distribute an agenda prior to the meeting date. Guarantee participant

attendance. Run your meeting effectively. Deal with problem participants. And

follow up after the meeting.

Be Clear About the Purpose of the Meeting

• Is It an Informative Exchange or a Presentation

• To Resolve Conflicts

• To Analyze Current Trends and Plan for the Future

• To Improve Existing Work

Page 21: Project management.docx communiction

• To Provide Training and Development

• Invited participants are more likely to attend if the purpose of the meeting is made

clear. Will the meeting be an informative exchange or a presentation? Perhaps the

purpose of the meeting is to collaborate, coordinate, and communicate. The

following is a list of some common reasons to have a meeting: To resolve

conflicts, to analyze current trends and plan for the future, to improve existing

work, and to provide training and development.

Prepare/Distribute Agenda Prior to Meeting

• Clear Identity of the Group That’s Meeting

• Limited Amount of Agenda Items with a Prioritized List

Presented in Logical Order

• A List of People Who Will Contribute to the Meeting and What

They Will Contribute

• A good meeting agenda has the following essential elements: A clear identity of

the group that’s meeting, a limited amount of agenda items with a prioritized list

presented in logical order, and a list of people who will contribute to the meeting

and what they will contribute.

Follow Up After the Meeting

• Distribute Meeting Minutes Promptly

• Encourage the Completion of Action Items

• Placing Unfinished Business on the Agenda for Next Meeting

• It’s important to have a meeting follow-up by doing such things as distributing

minutes of the meeting promptly, encouraging the completion of action items, and

placing unfinished business on the agenda for the next meeting.

Page 22: Project management.docx communiction

Meeting with the End User

• Ensure They Don’t Feel They’re Being Quizzed

• Ask What’s Wrong with the Product

• Ask What Needs to be Known When Using It

• Ask What Knowledge Would Help Simplify the Process

• Ask End User What Other Product Resources They Can Provide

(e.g., People or Information)

• When meeting with the end user, ensure that the end user doesn’t get the

impression you’re quizzing him or her. The following questions can be helpful in

your interview: What’s wrong with the product? What do you need to know to use

it? What knowledge would simplify the process? What other product resources can

you provide (e.g., people or information)?

Assertive Behavior

• Alternative to Powerlessness and Manipulation

• Barriers to Self Expression:

• No Right to Question Developer’s Opinions

• Fearful that Engineer Will Complain to Your Supervisor

• Lack Assertion Skills; e.g., Don’t Know How to Handle a

Pushy Developer

Assertive behavior is an alternative to personal powerlessness and manipulation.

It’s a way to develop self-confidence and respect for others. It will help you do a

Page 23: Project management.docx communiction

much better job, and feel better about yourself at the same time. Here are some

common barriers to self expression: 1) You don’t feel you have the right to be

assertive. For example, you should not question the developer’s opinions. 2) You

are anxious or fearful about being assertive. For example, the engineer will

complain to your supervisor if you do not do exactly as he tells you. And 3) You

lack the skills to be assertive. For example, you know you shouldn’t let the

developer run over you like that, but you don’t know what to do about it.

Assertive Behavior

• Changes in Project Are Certain—Be Prepared

• Material Is Added

• Deadlines Are Shortened

• Need for Negotiation and Understanding

• It’s certain that the project will change as it proceeds. You may be asked to do

things that are beyond the original scope of the project. For example, you may be

asked to include additional material, or to finish the manual before the agreed-

upon completion date. These changes have to be negotiated. Usually there are

good business and technical reasons for these requests, and in many cases you can,

and should, accommodate for the request with few problems.

Assertive Behavior

• Sometimes Difficult or Impossible to Meet Request

• Assertive Behavior and Negotiation Skills Can Effect a Win-Win

Compromise

• Sometimes, however, it may be very difficult or even impossible for you to

comply with a particular request. When this happens, successful assertive behavior

Page 24: Project management.docx communiction

can lead to a win-win compromise. Negotiation comprises a particular type of

assertive behavior that’s used when you want a win-win outcome; you want both

sides to come out ahead. This can be vital when dealing with business associates.

Dealing with Demands and Criticism

• Record All Meeting Minutes

• Last-Minute Additions with No Schedule Slip

• People Tend to React to Criticism Emotionally

• Emotional Responses Lead to Aggressive Behavior

• It’s Not the Anger, It’s How You Manage It

Writers are frequently exposed to demands and criticism from developers, editors, and

others. For example, the developer expects you to take minutes at meetings because

you’re a writer, or insists on adding new modules at the last minute without schedule

slips, or tells you the final draft is unsatisfactory. People tend to get emotional when

criticized, whether it’s justified or not. This can lead to aggressive behavior and over-

reaction. When you act aggressively, you react to your perception of the feelings behind

the words, rather than to the words themselves. It’s not the anger that you feel that’s

inappropriate, it’s how you manage that anger.

Guidelines to Reacting to Criticism

• Separate the Person from the Problem

• Do Not Over-Generalize—Get Specifics

• Do Not Counter-Attack—Loss of Self Control

• Do Not Offer Excuses or Remain Silent—Speak Up

Page 25: Project management.docx communiction

• Here are some guidelines for reacting to criticism that will keep the discussion

productive: Separate the person from the problem: For example, you are

working with another person to solve a particular problem. You may have

difficulties dealing with this person, but the person himself is not the problem.

Don’t over-generalize: Find out in specific detail what they don’t like, or what

they want changed. The developer may say that the manual is poor when what he

really means is that he wants a paragraph changed on page 33. Don’t

counterattack: This means your anger is out of control, and so is the discussion.

Don’t offer excuses or remain silent: This implies agreement; speak up if you

disagree.

Guidelines to Reacting to Criticism

• Don’t Say You Agree When You Don’t—Express

• Listen—Before Interrupting and Offering Solutions

• Ask for More Information—To Clarify

• Ask for a Solution—Pose Opened-Ended Questions

• Don’t say you agree when you really don’t: Express your opinions and discuss

your differences. Don’t be afraid to disagree. Listen: Don’t needlessly interrupt or

offer a solution immediately. Let the person talk it out. Try to figure out the real

meaning behind the words. Ask for more information: Ask questions that clarify

the problem and be more specific, such as: “What don’t you like about this

chapter?” or “Why do you want to add this module?” And ask for a solution: Ask

questions like, “What do you think we should do about this?”

Responding to Valid Criticism

• Accept It: “You’re Right. I’ll Change It.”

Page 26: Project management.docx communiction

• Delay: “I’ll Need to Discuss This with My Manager First. I’ll Get

Back to You.” (Ensure that You Do)

• Disagree in Part: “I Agree with Your First Two Comments;

However, the Last One Seems Unjustified.”

• Often criticism is deserved. If the criticism is valid, acknowledge it and act on it.

Being assertive does not mean ignoring criticism. Here are some assertive ways to

react to valid criticism: Accept it: “You’re right. I’ll change it.” Delay: “I’ll need

to discuss this with my manager first. I’ll get back to you.” and ensure that you do

get back to them. Disagree in part: “I agree with your fist two comments;

however, the last one seems unjustified.” Remember, assertive behavior is not a

cure-all. But it does support techniques that can help you be more effective,

productive, and happier on the job.