Category: Advertising & PR

How are you at speaking directly and clearly? Some of us like to “sugar coat” the truth so we don’t hurt anyone’s feelings. Others are “too blunt” to the point of harshness. If you fall in one camp or the other, finding a balanced approach might be a better way to go.

1. Pay attention to your communication for a few days, and listen for hedging with understatement, misdirection, or apology. If you hear these behaviors, you might be too soft. If you hear accusations, forceful tone or language, or lots of “you” messages, you might be too tough. To find and maintain that middle ground that is honest, direct, and clear (but short on aggression) consider the following before you speak.
2. Consider your intent. What is the purpose of this communication? Is it small talk with peers? Is it corrective in nature? Is it brainstorming? What do you want to get out of this communication? A disciplined but intimidated direct report? Or better understanding and cooperation within your team? Setting your intention ahead of the conversion is a powerful tool for driving your communication behavior.
3. Master your timing. If your direct report comes in late, or makes a mistake, you might be tempted to address it immediately. But should you? Who else—customers or coworkers—will overhear your criticism? Better wait for a private moment. Also, what about your emotions? If you are frustrated, that will impair your ability to speak in a fair, impartial way. However, if you tend to be “too nice” or postpone uncomfortable conversations, you might want to make a rule for yourself to deal with issues within the same business day.
4. Weigh your words. Words like “always” and “never” beg to be argued with. Critical words like “careless” or “incompetent” will raise defensiveness. Consider searching for wording that is truthful yet neutral. And if you tend to be too nice and indirect, consider—and rehearse if needed—direct words such as, “this report needs to be corrected today.”
5. Be aware of your body language. Watch for incongruent body language. If you are a person who smiles all the time, people may find it hard to take you seriously. Conversely, if your face or body language often looks angry or disapproving, your words may be taken as more negative than you mean them to. Strive for a neutral tone, face and body language.
6. Tune into listening skills. If you want to build communication rather than just bark out orders, it would be helpful to hone and employ your best listening skills. Ask open-ended questions to hear the other person’s point of view. Listen to what they have to say, how they say it, and what they don’t say.
7. Maintain consistency. If you want your communication brand to be “honest and direct,” you will need to continually think before you speak, choose direct words, and tell the truth. Doing these things now and then won’t build your brand, but may just confuse those you deal with, since they don’t know from day to day what to expect from you.

As noted in the previous content (Part One), an Action Plan is extremely detailed. It has to communicate and justify its proposal, strategy, and design. We described the initial outline of an ‘Action Plan’, as having the following material:

• Acknowledgements – Listing the key players up front.
• Table of Contents – Denoting the breakdown and location of the content.
• Executive Summary – Providing a short but concise explanation of the action plan.
• Introduction – Providing the overview and reasons behind the plan.
• Overview – Describing in detail what is needed, who is affected, the definitions needed to be understood, and the approach taken to derive the findings.

After the above sections, we can now structure the document as follows:

Goals

Note the goals and strategy of the ‘Action Plan’

• Beginning – Describe how the plan will be initiated; the ‘why’, and the reasoning behind it. List all stakeholders and target audiences affected and any required agreements. Describe new policies and roles created; including any amendments.
• Building a team – Describe how a team will be formed; include partnerships and task forces.
• Building the infrastructure – Describe how the new organization will function.
• Setting the groundwork – Describe how to achieve the goal; include project schedule, resources, budgets, and any new standards or programs. Include everything that will be affected.
• Preparing the population or audience – Describe how the target audience will be notified and what education is required for understanding functionality and requirements, i.e., through meetings and seminars. Include how to measure the audience reaction and ROI, i.e., through voting or analysis.

Benefits

Note all benefits of the plan.

• State why the plan is needed, i.e., how it fills a void, or how it solves a persistent problem.
• List the benefits. For example, state how the client, organization, or target audience can function more efficiently, gain more momentum, or reap more rewards, such as decreased productivity costs, better communication between employees, more security, or providing advantages of a new product, application, or process.

Cost

Note the budget involved.

• State how the proposal will be accomplished within a budget. List future and current costs involved.
• List all financing and loans, such as where funds will be used, found, and the maximum budgeting involved, as well as grants, third party financing, etc.
• Note the tools that will be used to complete the project on schedule and what might be needed if the project lasts longer. Note down critical milestones.

Reporting

Note the required reports.

• Generate reports on the project status and its budget. Describe possible bottlenecks and problems, such as ‘What if it doesn’t work’, or ‘limitations if not completely accomplished’ and any unexpected issues.
• Provide analysis on ‘should wok be done a step at a time or go full force’ and ‘complete within x number of years, months, etc.’

Hope this has been helpful. As with any documentation, be precise and accurate. If you have previously created an action plan, please add to this content. Thank you.

An Action Plan is very involved and detailed as it has to justify its proposal, strategy, and design. When you have to perform a task that involves a particular population, how do you communicate and create an action plan? The Technical Writer involved has to have meetings to gather information and as always, with any documentation, create an outline or a mapping depicting what items are associated to one another.

An example of an outline that would need to be created, is as follows:

The Acknowledgements

List the key players up front. List the directors, community, partners, consultants, etc., involved in developing the subject matter. Note down their involvement and participation in creating this plan.

The Table of Contents

Create a Table of Contents denoting the breakdown of the content. Include the location of the Executive Summary, Introduction; Overview, Goals, Benefits, Costs, Future Plans, etc. Include the following:

• Figures – list the title and location of diagrams, graphs and charts showing trends, comparison of values, distribution, etc. Be sure to illustrate data points over time periods.
• Tables – list the title and location of tables describing events and/or tables that clarify and compare items, facts, figures, etc.
• Appendix – list any additional reports, references, or addendum to the action plan.

The Executive Summary

Create a short but concise explanation of the action plan. Include its purpose and note reasons why this report was created. Also include the goal as well as the budget needed to complete the project.

The Introduction

Within the introduction, provide:

• Overview of the action plan – an outline giving a rundown of what will be done.
• Reason behind the plan – the why and the goal.

The Overview

Create a summary and explain the plan for the population that will be affected. Describe what exists, what is needed, the strategy, and the future outcome.

• Definitions – Define terms that need to be clarified, such as explaining the situation that caused the problem or any needed technical explanations.
• Current environment – Note what currently exists. Justify the action required. How did this come about? What analysis was done? List all the various types of analysis completed. Next, note what the findings were, and also include any evidence that exists to justify your point.
• Approach – State how the conclusion or plan was derived. Get estimates. Note what was checked, such as how did you know what was needed and what was needed to be investigated? Note also what prerequisites, requirements, conditions, and obligations are needed before any action can take place.
• Future – State what the future holds. What will happen in the future from this new action? What can affect this change – increased traffic, population, decreasing prices?

Next month, the Goals segment of the action plan will be presented. It is not easy to create an ‘Action Plan’. It is very extensive and a lot of work has to go into its creation.

Hope this beginning section has been most helpful. And, as with any documentation, be precise and exact.

If you have previously created an action plan, please add to this content. Thank you.

In continuing the topic of business cases, here are some tips on creating a Business Case.

How do you begin to create your business case? A business case justifies the value of a project by defining the goal and scope of the project. It will describe the usefulness of the project and the consequences if the project is not approved.

As with any document that needs to prove a point, research has to be first done and then the findings studied. As previously stated in the prior article (Part One), a business case generally provides a solution to a problem, so include details from meetings of problems that currently exist. Note down all the core requirements gathered from meetings, hands-on work, or practical experience needed to resolve a problem. From your gathered information, you will now know what content needs to be written.

To Begin

• Use an outline as a starting point and include a Table of Contents or at minimum an outline of the contents up front.
• Break up the outline into logical sections, e.g., Introduction, Research, Problems, Resolution, Recommendation, Strategy and Risks, Costs, Benefits, and Time.
• Create an introduction to the project and be specific. State the reason (justification) behind the business case and the goal(s).
• Describe the research and findings that were done.
• Describe all the problems that currently exist and the solutions that have been derived.
• Create a chart if needed, and point out relevant data by highlighting it.
• Denote only the important ‘must have’ items within the business case to validate a point.
• Include all the data that is needed to prove your case. Numbers are always beneficial to proving a point or making a justification.
• For lengthy documents, break it up into sections and include a Table of Contents or break it up into several documents; one for each department or subgroup, and show the relevance for each department or subgroup.
• Keep it organized and break it up into subject matter if you need to.
• Note the benefits such as ease of use, long term usage, better monitoring, etc. Prove its value.
• Provide a cost analysis (if needed) and make it visually appealing and not complex.
• Show, e.g., customer satisfaction benefits (if needed) – easier to access information. – saves time and energy.
• Describe how to handle marketing and distribution (if needed).
• For readability, apply bullets to outline lengthy text or explanations.
• Double check your grammar and spelling to ensure the validity of the document.
• Remember to communicate well through written material. You have to work as an editor, illustrator, and designer to get your information across.

Once the document is completed, send it to the client and respective project managers for verification and approval. If the document is of considerable length, indicate what sections should be read by which party. As always, write for the intended audience. Make it accurate and precise to prove your point and to get your recommendation approved.

If you have previously written business cases, please add to this content or leave a comment. Thank you.

“Well, I guess that’s about all I have.”

“Well, I guess we are out of time.”

“That’s about it.”

How do you close your meetings and presentations? Hopefully not like these endings, which are common enough, but entirely ineffective. Closing your presentation can be challenging, especially if you have run out of time, taken a number of tough questions or failed to win approval for your ideas. But the close is so important for reinforcing your message that you shouldn’t just leave it to chance.

Take time to plan the next ending of your meeting or presentation, so no matter what happens, you can still end with finesse.

• Be careful not to use the words “in closing” or “in conclusion” until you are really ready to end. Once people hear those words they are mentally ready to move on.
• Don’t thank them for their time, but instead for their participation, feedback or comments. Even if the meeting was contentious, you can honestly thank them for being passionate about the subject matter.
• Remind people what they have learned or accomplished by listening to you. Keep it positive and forward-focused, even if there were areas of disagreement.
• If you want more questions, don’t ask, “are there any more questions?” Instead, ask “what questions do you have?” or “what other questions can I answer?”
• A brisk “thank you” will create closure after a question and answer period that just won’t end. So will an offer to answer any remaining questions offline, or after the meeting. Give your contact information if appropriate.
• Try to end after a positive question or on a positive note. Watch how comedians refuse to end after a joke that bombs; they will always try one more, hoping for an upbeat ending.
• Always end with a reminder of your key message or a call to action. Since people tend to remember what they hear first and last, select and reinforce what you want people to remember by repeating or restating it at the end.

Bottom line: Don’t let your presentation or meeting just wind down; instead plan ahead so you can end on a strong note that leaves a positive, lasting impression.

What is a business case?

A business case is a document that describes the reason why something has to be done. It will describe the usefulness of the project and the consequences if the project is not approved. Because it is a document that defines the project and its purpose, it can almost be compared and structured similarly to a Requirements Document which provides the desired details of a project and what its goals, resources, funding, and technology are. It shows what is needed to accomplish a task. The difference though, is that the business case will justify the value of a project. For example, it will show prove how a new product or application will benefit the intended audience. It details all the reasons for wanting a project to be done.

Why use a business case

We use a business case to show the worth and importance of a project. It will detail how the task will be accomplished. It will include items, i.e., a migration being involved, purchasing new equipment, or hiring consultants. Most importantly, it also specifies time and expenses, and the benefits and risks involved.

Once the document is completed, it is sent to all parties involved as well as to the client and respective project managers for verification and approval (if needed).

Creating your business case

The business case is usually written using a logical format and is written for those authorized to make a decision, so be logical when creating the business case. Structure it by presenting an introduction to the, e.g., product. – Let users know what the product is. Use simple terms to describe it and if there is a prototype, display it. If the document is of considerable length, indicate what sections should be read by which party.

A business case helps to define a possible solution to a problem, so include facts and details, such as the core requirements, i.e., Introduction, Research, Problems, Resolution, Recommendation, Strategy and Risks, Costs, Benefits, and Time. Also:

• Break it up into logical sections that fit your case. Explain the logistics. For example, if it’s for new equipment, denote the equipment required and the reason why that particular equipment is required, e.g., providing more storage, easier use of software and maintenance for database access such as accessibility to files for specific tasks, i.e., system enhancements, documentation, testing, etc.
• Include items such as dates for priorities, milestones, and deadlines.
• For denoting security, list for example, the types of maintenance and issues that will be planned out and taken care of, such as protocols, archives, contingency plans, etc.
• Also, denote resources required–e.g., who will be involved- Developers, DBAs, Testers, Lead Project Manager, Sub-Contractors, etc. This will ensure you have the right amount of personnel to perform the job as well as the right people.

As always, write for the intended audience to prove your case and to get it approved. If you have previously written business cases, please add to this content. Thank you.

How does a technical writer and developer communicate how a product works to a user? How do they communicate functionality, to make their audience’s user experience easier? They plan it out by knowing their audience, knowing what is expected of the product through meetings and through training.

Knowing the audience

Create the product needed by the user.

• What does your user need to know- what do they already know?
• Does the developer know how much information a user knows and more importantly, what is needed by the user in order to develop applications that are suitable for them? For example, do menu options need to be displayed?
• Does the technical writer need to write lengthy documents or just quick sheets?

Knowing what is expected

The answer to many questions is by having all parties share their knowledge through meetings. The technical writer, as mediator, interviews each party, and gets answers to questions, such as:

• What will the product do and why?
• Will the product be suitable for the user?
• Will it be intuitive or data driven?
• Will the technical writer have to write a long procedure?
• Will this be on the web? Web-based applications are easier for users to access and use. Documentation will also be easier as help menus (with hyperlinks) can be created.
• Will this be an end-user product? – If so, then documentation will be lengthier unless the product is easy to use and mostly error free. – Note: To avoid frustrating user errors, multiple options can be listed to avoid this problem.

Knowing what training is needed

The best product or application for a user as a whole should not be complicated.

• If a product or an application is complicated or has a lot of options, then the technical writer can develop business cases with user stories to help with explanations. The writer can also create training sessions with demonstrations and/or create instruction videos that are not too complex. Images are always better than words. Words however should still be written to reinforce what was presented.
• If an application is, for example, a data entry form, the user should be able to go through the mechanics without problems – in other words, it should instinctively lead the user to the next screen or item without any extra work nor thought from the user.

Key words are: ‘what is needed, shared, and not complicated’. To communicate functionality to the user, know what is needed, be aware of what they already know, and know how best to present it. Make sure that communication exists between all parties through meetings. Knowing how much to document will also depend on the results of these meetings. As always, when verbally communicating or writing, stick to the point; be concise and accurate.

If you have any suggestions or comments on how to communicate functionality to make a user’s experience more enjoyable and easier, please leave a comment. Thank you

 

 

 

 

Are you prepared to introduce yourself in a way that builds credibility and trust? If you are uneasy or uncomfortable introducing yourself, or do it poorly, your presentation, meeting or training session can get off to a bad start. Take time to plan and rehearse your openings.

Guidelines:

• State your name clearly, maybe more than once.
• If it is unusual, hard to pronounce or remember, provide a memory device or write it on a flipchart.
• Briefly give your credentials, expertise or experience. You may wish to supply these in a handout so you can move through your introduction faster.
• Mention why you are the person conducting the session. What special skills or experience do you bring? How do you feel about the content?
• Mention the purpose of the training. Often people don’t know or don’t remember why they were asked to attend.
• Stress the WIIFM*. How will participants benefit from participating? Why is this important to them?
• Keep it simple and fairly brief. Once you are into the content you can tell more about your experiences.
• It is OK to use a little humor but don’t force it.
• Make it “all about them” not “all about you.”
• Do something that engages or surprises them (like asking a question, or for a show of hands.)

*What’s in it for me, the listener or learner

More tips:

Make your openings brief and positive. This is not the place to begin rambling, to provide a long description of your background and expertise. They don’t want to hear an apology or a description of your travel woes, unless you are really funny in describing them. Start our crisp and upbeat, getting to the point pretty fast.

Talk about listeners and their concerns more than about yourself. If you speak about them and show them you have something to offer, they will be more impressed than they will just hearing your credentials. If someone else is introducing you, they can mention your credentials and accomplishments, then you won’t have to. It is smart to bring a short bio for whoever is introducing you to use.

Encourage audience interaction whenever appropriate. Keep it simple, a show of hands in a large audience, a few simple questions, carefully planned, for a smaller group. Plan these questions carefully and be ready for any kind of response–the audience may surprise you.

Never apologize in your opening. Don’t tell them it is too long, the content is technical or boring, that your slides are going to be too busy, or that you are not an expert. Put on your game face and tell them you are so happy to be there and looking forward to sharing information with them.

Rehearse your opening out loud until you know it cold. Make it short and snappy so it is easy for you to remember. Better yet, rehearse this with a trusted colleague or record your voice and listen back until you have really nailed it.

Work on making the people connection first. Skip all the detailed information, facts, figures, research and technical jargon. Tell a story. Talk about why your ideas matter. Give them an informal quiz or test. Make them think. Make them feel something. Show them you care and you are going to provide something of value. Now they are ready to hear what you have to say!

Remember that listeners form a first impression in just seconds. Make the most of your openings with thorough planning and rehearsal so you can start off on the right foot with your audience.

Technical Writers describe error messages that appear within many documents and applications. They are useful, necessary, and required. Without these warning messages, readers\users would not know that, e.g., an incorrect key was pressed or that some information was missing to complete a task. Error messages describe what to do (or not), what information is required, or whom to contact to correct a situation.

Error messages exist within documents, such as:

• Technical Specifications which developers use to program and present different types of error messages indicating where, when, how, and what.
• Functional Specifications which describe expected error prompts and information required to complete tasks.
• User Guides which warn users by defining errors (what to expect – where and when) if certain prohibited tasks are done and how to correct the problem.
• Ready Reference sheets which list commands as well as what errors might occur, what they indicate, whom to notify, and how to correct certain problems.
• Test Plans which help locate problem areas.
• Bug lists (or List of Errors form) which contain anomalies from testing. e.g., while performing software testing to identify defects flaws and errors in application codes, the detailed steps that led to the errors are noted here. Without this completed form, developers would not be able to replicate the occurrence and hence correct it.
• Feedback forms which include questions such as ‘Who is not satisfied with the document and Why’. Asking appropriate questions help to find problem areas, e.g., material was written for the wrong audience, contains incorrect or bad formats, or has errors.

To prevent errors within a document:

• The front matter of certain documents should present a list of readers/checkers approving the document, thereby ensuring its completeness and accuracy. This will avoid problem areas, i.e., missing tasks within an application, missing reports, incorrect data, etc.
• The material should be produced as a technically accurate document.
• The contents of global documents should be examined and presented as a clear, concise, error free
• The writer should be vigilant and, put themselves in the shoes of the reader, and maintain direct communication with stakeholders.

Error messages are also written for:

• Developers to ensure that accurate data is located, gathered, and present a clear understanding of data repositories.
• Disclaimers to avoid liability for errors or omissions.
• Data analysts to investigate data discrepancies and to detect and resolve errors.

Benefit of Errors:

• They help to teach, especially when using animation to display problems and resolutions.
• They help to maintain and manage accurate data.
• They help to provide editing and proofreading for grammatical errors.

The Technical Writer must ensure accuracy, completeness of technical documentation, and meet company standards, even when providing error messages. Technical Writers are also editors when ensuring documentation that is error free in content and in the usage of grammar, spelling, etc. This is especially important when producing material (i.e., marketing, training, global, or compliance documents) that reflect upon a company’s image.

Some meetings and training sessions seem to drag because you can’t get a good discussion going. Other times, people start talking and can’t seem to stop, or arguments and conflicts devour precious time. In order to facilitate effectively, you need to know both how to get a group started, and then how to manage the discussion.

Based on my experience as a seminar leader, these are my Top Ten Ways to manage interactivity:

1. Start with easy-to-answer questions. These questions should be closed ended and not sensitive in nature, so that your audience feels comfortable responding. As you continue to build trust, you can move into more sensitive issues, and ask more open-ended questions.
2. Call on the group at large, not an individual. Pose your question to everyone, then as you look around, select the person or persons you want to call on. Usually they are the ones who are making eye contact with you. This approach helps everyone stay engaged, and you are less likely to put someone on the spot.
3. Use the silence. Once you have asked a question, don’t jump in with your own answer. Count to ten, if you need to, before saying anything. Let the group have time to think and respond.
4. Ask participants to write down their ideas. Have paper or note cards handy. This is especially helpful with a quiet group, when time is short or when emotions are high.
5. Foster small-group discussions. With a quiet group, ask them to first have a discussion with the person sitting next to them or at tables, and then ask them to report on highlights of their discussions. Do this early in your meeting to set the expectation for engagement without having to state it outright.
6. Ask for a volunteer to write comments or answers on a flipchart. This will keep you from having to turn away from the group to write, allowing you to keep the group engaged, or to keep an eye on a talkative group.
7. Incorporate physical movement. Have individuals move into small groups, walk up to the front of the room to post their ideas, or stand beside a flipchart to deliver their findings to the large group. Use games and puzzles that get them physically engaged.
8. Manage side conversations. Make steady eye contact with those who tend to chat, stand closer to them, or use silence until the room becomes quiet. By using these “silent” techniques, you can usually maintain control without having to say anything.
9. Don’t shy away from conflict. Disagreement can be a sign of independent thinking, and can lead to better solutions in the long run. When conflict arises, try to disagree with the statement rather than with the person. If the emotional temperature gets too hot, you might suggest a short break before continuing.
10. Use courteous language. Words such as “please” and “thank you” and inclusive terms like “Let’s look at our next agenda item” or “Shall we check for consensus now?” foster a climate of respect and cooperation.

The next time you host a meeting or training session, try to increase engagement using these techniques or others you feel would be appropriate for the audience. Most likely everyone will benefit from a more engaging conversation.