Writing Skills

Before You Write It Down, Know This

Many people are intimidated by writing. Even so, there are times when writing is the best way to communicate, and oftentimes the only way to get your message across.

Write With Necessary Caution...

When writing, be mindful of the fact that once something is in written form, it cannot be taken back. Communicating in this way is more concrete than verbal communications, with less room for error and even less room for mistakes. This presents written communicators with new challenges, including spelling, grammar, punctuation, even writing style and actual wording.

Thankfully, today’s technology makes memo, letter and proposal writing much easier by providing reliable tools that check and even correct misspelled words and incorrect grammar use. Unfortunately, these tools are not fail proof and will require your support, making your knowledge in this area important.

The Importance of "Style"...

Some of the most basic tips to remember when writing include:

• Avoid the use of slang words
• Try not to use abbreviations (unless appropriately defined)
• Steer away from the use of symbols (such as ampersands [&])
• Clichés should be avoided, or at the very least, used with caution
• Brackets are used to play down words or phrases
• Dashes are generally used for emphasis
• Great care should ALWAYS be taken to spell the names of people and companies correctly
• Numbers should be expressed as words when the number is less than 10 or is used to start a sentence (example: Ten years ago, my brother and I…). The number 10, or anything greater than 10, should be expressed as a figure (example: My brother has 13 Matchbox cars.)
• Quotation marks should be placed around any directly quoted speech or text and around titles of publications.
• Keep sentences short

While the above tips cover the most common mistakes made when writing letters, memos and reports, they in no way cover everything you need to know to ensure your written communications are accurate and understood.

While this takes some practice, there are many sources available to assist with writing style, including “The Elements of Style”, by Strunk and White. One glance in any newsroom or on the desk of even the most accomplished writers and you are sure to find this small, easy-to-read, easy-to-understand, no-nonsense guide to writing. It is clear, concise and perhaps the best book of its kind. If you plan on writing a great deal of letters or even proposals, it is strongly recommended that you pick up this nifty guide, which by the way, will fit in your shirt pocket.

Letter Writing Hints...

When writing letters, it is best to address the letter to an individual. And, when beginning the letter with a personal name, be sure to end it with an appropriate closing, such as ‘Sincerely yours’. If you cannot obtain an individual’s name, consider ending it with a more generic (less personal) closing, such as ‘With kindest regards’.

For normal business letters, your letter should start with an overall summary, showing in the first paragraph why the letter is relevant to the reader. It’s not a good practice to make the reader go past the first paragraph to find out why the letter was sent to them.

The body of the letter needs to explain the reason for the correspondence, including any relevant background and current information. Make sure the information flows logically, ensuring you are making your points effectively.

The closing of the letter is the final impression you leave with the reader. End with an action point, such as ‘I will call you later this week to discuss this further’.

The Importance of Careful Proofing

Perhaps the most important thing to remember when writing a letter is to check it thoroughly when it is completed. Even when you think it is exactly what you want, read it one more time. This “unwritten” rule holds true for everything you write – memos, letters, proposals, and so on.

Use both the grammar and spell check on your computer, paying very, very close attention to every word highlighted. Do not place total faith on your computer here. Instead, you should have both a printed dictionary and thesaurus nearby to double-check everything your computers editing tools highlight, as these tools are certainly not always reliable, for a variety of reasons.

When checking your written communications, make sure the document is clear and concise. Is there anything in the written communication that could be misinterpreted? Does it raise unanswered questions or fail to make the point you need to get across?

Can you cut down on the number of words used? For instance, don’t use 20 words when you can use 10. While you do not want to be curt or abrupt, you do not want to waste the reader’s time with unnecessary words or phrases.

Is your written communication well organized? Does each idea proceed logically to the next? Make sure your written communications are easy to read and contain the necessary information, using facts where needed and avoiding information that is not relevant. Again, outline the course of action you expect, such as a return call or visit.

Close appropriately, making sure to include your contact information. While this may seem obvious, it is sometimes overlooked and can make your written communications look amateurish. This can diminish your chances of meeting your written communication’s goals.

Achieving the Unachievable

Achieving the Unachievable

By: Ann Drinkwater, PMP

Dramatically altering business processes and instilling organizational efficiency typically involves system automation. To succeed at system-related projects, it is important to join business and IT professionals early in the process. Business users typically think in terms of strategy, competitive positioning and how the project will impact their day-to-day operation, whereas IT implementers generally think in terms of analytical logic. Bridging the communication and cultural gaps between these groups can be a challenge, but very rewarding to the project and future joint endeavors.

In order to find inefficiencies in existing business processes and create new work strategies, the business community should first perform a comprehensive review of all activities within all related functions. This exercise will help to determine bottlenecks and potential areas for improvement, where elimination of non-value and redundant activities should be carefully considered. This due diligence, along with recommendations for improvement, must be performed before involving the IT group. Once the business user group has a strong understanding of what is needed to improve organizational operations, the case can be made to IT. There will be a much better chance for success if this upfront analysis and identification of needs is performed before involving the technical team. This doesn’t mean the business group should define the technical implementation, but they should definitely have clear business goals and rules that will drive the implementation. A well thought out business plan will also help raise implementer confidence in the solution they are being asked to build.

From the initial strategy discussion to the intricate details of what needs to occur, it is critical to keep the lines of communication open and continually remind ourselves of potential areas of misunderstanding and strain. An abrupt and demanding approach can create implementation barriers, preventing both sides from meeting their goals. With two differing groups working together, there will inevitably be some level of difficulty. Before you get to the point of no return and statements such as, “it’s impossible” or “it can’t be done,” you should carefully plan for and craft your approach to the conversation.

Stakeholder backgrounds and views must be considered in all communication. By invoking a joint problem solving approach, both groups are more inclined to openly “receive” the necessary information and support the project, moving forward together. Below are my suggestions for eliminating barriers.

1. Clear Problem Statement. Provide all involved sufficient background and detail. It is very difficult to correct early miscommunications and perceptions. First impressions count and once judgments are formed; it can be quite tough to reverse. Say the business group intends to revamp an existing system from the ground up, but what the IT group hears is the desire to add complex logic to an already complex, archaic system that's hanging on by a thread. In this situation, the business group may encounter steep opposition. To head this off, the business group should clearly present the reason(s) change is needed and leave the implementation aspect to the team responsible for the work. Reassurance should be given that implementation details will lie in the hands of the technical experts.
2. Acknowledging the Level of Effort. Create a supportive environment by listening to the concerns of the technical team. It is important to approach the technical team with an understanding approach of the complexity of their work, versus implying the level of effort is insignificant and easily accomplished. Focus should be on clarifying the needs of the project and working together to determine the best way to achieve those goals.
3. Allow IT to Present Impacts. While technical implementers usually have many projects waiting in the wings, it is important to involve them in decisions involving what gets implemented and of course how it gets implemented. This helps create buy-in, helps the team understand the importance and expected value of the project and also helps develop a relationship between groups. Allowing the group responsible for the work to present their initial reaction and findings to the business group is vital. If IT has reservations about code stability and how additional dependencies can falter an already weak structure, the business group needs to understand the risk. While the ‘how’ of implementation is in the hands of the technical staff, working together to determine possible solutions and workarounds is necessary and invaluable to the overall relationship.
4. Identify Available Resources. Barriers may also surface due to the complexity of the request and already stretched resource levels. Once the team fixates on these aspects, other, important project details may be not be heard. The technical team may view the project as just another daunting task. Working together to determine the necessary skills for the project and available resources will help settle any panic that may result from request overload.
5. Jointly Determine Timelines. The technical team may immediately compare the situation to previous, unrealistic schedule demands. Time boxed delivery dates not accounting for the level of work are not nourishing for the team or the project. Often times a middle ground can be reached and select portions of the project be delivered on a set date, versus the entire project. Determining how much time is involved for the work outlined is the first step. Next, both teams should meet to discuss delivery expectations, closely reviewing the time estimates on what can be achieved reasonably. Clearly setting the expectation of what you need and when it is needed is required in all project discussions.
6. Learn From the Past, but Move On. The technical team may not see past previous implementation plans and projects that went awry. While we obviously need to learn from our mistakes and previous project blunders, we should not immediately expect similar, undesirable outcomes for other projects. Showing the technical team you are working with them to ensure success and that you will provide them with the resources necessary to be successful creates healthy reflection and relationships.
   

Employing collaborative and effective communication, polishing your approach in working with others, and creating an environment of openness and healthy exchange will improve your working relationships. Below are three key focus areas:

1. Communication. I can’t underscore this one enough. Clear and effective communication is an absolute must to set the stage for what is needed, when it is needed, and by whom. Clear communication can go a long way in easing anxieties and setting expectations. Effective communication and involving the technical team and business community early on can help squelch inaccurate perceptions and expected demands. The sooner the technical team and business user group are included with the project, the sooner they will become part of the project. In my experience, it is helpful to have those that will be performing the work involved in very early, contractual commitment discussions involving milestones and other schedule parameters.
2. Empathize. Work together to holistically solve business issues, versus an isolated, one-on-one approach of “this is what I need from you.” Sensitivity to the work involved and other project commitments without offering too much of an opinion on how to proceed will improve the reception and tone for future interaction.
3. Create an Open Environment. Developing an open and supportive relationship goes hand in hand with reviewing things objectively. If the technical implementers know you are a reasonable and supportive person, they will be more inclined to voice their technical opinion in a healthy and proactive way, instead of taking the discussion to one of a defensive nature.

The project manager, business analyst, and business users must learn to communicate effectively with the technical team to overcome initial obstacles. It’s often hard to overcome the wall that someone erects when faced with a difficult or uncomfortable topic, so early identification and mitigation is key. Once you cross the “it’s impossible” threshold, both parties have usually become frustrated by the discussion and have often stopped listening to reason.

As businesses continue to look for ways to operate in the most efficient manner, there will be an increasing need for effective relationships between IT and business users. Basic communication skills and genuine interest in team members will be two areas that can make or break this union.