Tuesday, February 27, 2007, 09:23 PM
To be a profound, or at least half-way decent, communicator you must know the basics of communication. That being said, let's begin with why communication is important.
Did you know that a third (1/3) of project managers spend at least 20 hours in meetings every week, and an even greater percentage spend approximately 2 hours a day reading and responding to e-mails?
So, basically you are spending at least 6 hours of your day in meetings and reading e-mail. How crazy is that? No wonder 8 hour work days seem somewhat impossible.
If you can't, with a great deal of accuracy, express your ideas, decipher all the messages you get bombarded with on a regular, and regurgitate the ideas of others, it will be virtually impossible to run your project successfully. Why? Because, you'll be spending all of your time trying to manage mass disorder caused by miscommunication.
Before we go any further, let me just set one thing straight. Being able to speak well doesn't make you a good communicator. Sorry. You can use the most impressive words that Merriam-Webster has compiled, but if no one knows what the heck you're saying why even bother opening your mouth?
Communication is not about how many big words you know, or how proper your speech. Don't get me wrong, it is important that you speak with some level of intelligence, but not to the point where you can't get a clear message across because you can't get past trying to speak eloquently.
There are many types and methods of communication that you must be familiar with if you are to be a profound communicator.
They are:
Interpersonal Communication
Presenting
Written Communication
Nonverbal Communication
Communication via Telephone
Facilitating
As not to overwhelm you, because we can go on forever speaking on this topic, I will just touch on each of the above types/methods of communication and give you some tips on how you can improve upon each of them.
Interpersonal Communication is considered the most effective form of communication, because it involves speaking one-on-one or face-to-face with another person. Delivering your message face-to-face makes you more believable and the person on the other end of your message more receptive to what you are saying. He/She has the opportunity to see your facial expressions and hear the inflection in your voice. In essence, believability makes it easier to get your message across.
TIP: It is not always possible to deliver your message one-on-one. You should never interrupt someone and demand attention they cannot give at the moment. Being rude can cause friction, and cause the person to be less receptive to your future visits.
Presenting at one time or another is unavoidable if you are going to be a successful Project Manager. Even providing a status update to your client(s) or sponsor(s) is considered, to some extend, a presentation. Whether you are giving your presentation to a virtual audience or an audience locally, your presentation needs to be clear, informative, concise, and engaging.
TIP: Most important take away about presenting is, make sure you are well prepared and triple check that your presentation is both informative and engaging. An awesome message will never make it across to an audience who has glazed over eyes.
Written Communication spans greatly. Some examples include e-mail, memos, letters, formal business documents, and instant messaging. This form of communication gets people in the most trouble in that it is extremely tempting to get too relaxed when composing e-mails and instant messages. Don’t get caught in this trap. Sending messages that are too informal could give people the wrong impression about your level of professionalism.
TIP: Some key points to keep in mind when composing written communication are: do not use ALL CAPS; use appropriate punctuation (no unnecessary exclamation points); take the emotion out of your message; complete your sentences; check your spelling and grammar.
Nonverbal Communication accounts for about 65% of the message others derive from your communication. Over 50% is from body language, and another 10-15% is from tone and pitch of your voice, facial expressions, and gestures.
TIP: To be a profound communicator, this is the area to master. Some tips to take into account are: stand or sit up straight when speaking; maintain natural eye contact (you aren't trying to stare them down); try not to fidget; remain highly enthusiastic and confident; make sure the message your mouth is giving matches the message your tone, pitch, face, and body are giving.
Communication via Telephone is the second most effective method of communication, next to face-to-face conversation. Remember when speaking on the phone to remain professional, always return missed calls, stay on topic, watch your tone and pitch, and ask questions to confirm your message is understood and that you understand the other person's message.
TIP: Telephone communication is the next best thing to face-to-face communication. Use it often, when interpersonal communication is not viable.
Facilitating is one of the major roles of a Project Manger. That being said, it is expected that you perform this role skillfully. As a facilitator your primary task is to ensure everything flows smoothly. Being a facilitator does not mean that you schedule forever long meetings so that you can give the project team status on everything you have done on the project, or that you are the only person giving opinions, suggestions, and input.
TIP: To be an effective facilitator you should: be an active listener; encourage dialogue; encourage an environment of respect; stay on task; start and end on schedule (it is okay to finish early if you don't have anything else to cover); ensure accurate and timely documentation.
Communication is essential for Project Managers to be successful. With the fundamentals outlined above, profound communication is within your reach.
Talibah Adenouga, PMP
Founder of JANOP
tadenouga@janop.com
www.janop.com
[ add comment ] | permalink
Saturday, January 27, 2007, 10:16 AM
The most fundamental key to creating a dynamic, or at least half-way decent, requirements document is that you know what a requirements document is and why it’s important. So, let’s start there.
What is a requirements document? Oh, I’m so glad you asked. A requirements document is basically a summation of what it will take to implement your project. This document captures the meat of what you need done, what you desperately require to make the project you are working on a success.
There are several different types of requirements document, which is why I’ve not gone through the trouble of capitalizing this combination of words as a formal title. Whatever name bestowed upon the document you create, or facilitate the creation of, be sure that it is very specific.
You must clearly explain what needs to be accomplished, in such a way that all who read your document will have a complete understanding of what needs to be accomplished. There must be no room for speculation.
When creating, or facilitating the creation of, your requirements document you may be asked to identify those items that are “must have” versus “like to have”. If you take this into account throughout the process, as requirements are unveiling themselves, you can make note of those that can be “scoped out“ when and if asked by the persons or groups who have to implement the changes or are sponsoring the project. However, items that are “like to haves” should be minimal. If the items are not required, then they shouldn’t be in the requirements document…unless of course included per executive request or at gun point (which at times can feel like the same scenario).
You should consider capturing the following when creating your requirements document:
Project Name
Document version - you should differentiate between draft version updates and baseline version updates, and state the difference between the two on the document itself. Baseline version updates should require something slightly less than an act of Congress to change. So, be careful when deciding on the best time to baseline your document.
Project Description - summary of what you are trying to accomplish with the project.
Project Objective - the purpose of the project.
Scope and Limitations - helps to clearly define what things will and will not be accounted for in your project and most importantly reduces Scope Creep.
Assumptions - specific information that the requirements were based on, but may not be factual or may change before the implementation of the project.
Dependencies - systems, groups, processes that need to be in place before certain requirements can be implemented.
Impacts - those items that will either affect your project’s execution or will happen as a result of the execution of your project. Be extremely specific here. Full disclosure is key. It is better to tell another group(s) or Project Manager upfront that the changes you need to implement may/will affect them. You do not want a group of people pissed off at you for creating a bunch of extra work for them, that they were not ready for, because you didn‘t bother identifying potential impacts.
Specific tasks required to achieve the project objective.
The group(s) or individual(s) who will perform the specific tasks identified.
A plan for project implementation.
Any training that is necessary.
Testing strategies.
Any supporting documentation that further explains the requirements captured.
Definitions of unfamiliar terms or acronyms.
Signatures or approvals from the core team indicating that the
requirements captured are complete, including the date approved and the team member’s role.
There are two main things to keep in mind in the pursuit of a well
defined, clearly documented, dynamic requirements document. The first is that you are not called to create this document on your own, just like you are not called to do everything in the project. You need to engage a team of individuals that have a great deal of insight you may not have to help you brainstorm and iron out requirements for the project you have been given to manage. The second is that including more information than necessary is better than not providing enough information.
So now that you know what a requirements document is, what goes into it, and what to keep in mind when creating it, you should have no problem delivering a remarkably Dynamic Requirements Document.
Signing off for now. Until next time, go forth and be dynamic.
Talibah Adenouga, PMP
Founder of JANOP
tadenouga@janop.com
www.janop.com
[ add comment ] | permalink
Back
