The Unambiguous Information Society
Communicating your message unambiguously means it can only be understood one way. Whether speaking or writing, do your best to strive for clarity. Before you speak or write, examine the message closely for any ambiguities or potential holes that could lead to a misread. Obviously, you will not always have the luxury of self-examination before you speak or write, and in these instances repetition is the way to distil or parse the message to its essence. Repeat yourself, or ask repeatedly for clarification, until both parties get the point.
Strive to communicate explicitly. Over communicate if necessary. Continue breaking down your message into simpler and simpler terms until your point gets across. Questions and answers are the tools we use to establish clarity. If no one asks any questions at a meeting or presentation or after reading a specification, consider this a red flag. Chances are the point is not getting across. Clients, stakeholders, and team members count on you to communicate all apects of the project clearly and explicitly.
Distilling technical minutiae into clear, unequivocal language is a challenge for everyone on the team. Look at the following.
PROJECT MANAGER:Does the system only check user name and password for authentication?
DEVELOPER:E-mail is the unique identifier for authentication in the system.
PROJECT MANAGER:What about user name and password?
DEVELOPER:Yes. Those, too.
PROJECT MANAGER:So user name, password, and e-mail are all used for authentication?
DEVELOPER:No. Only e-mail.
PROJECT MANAGER:So a user can put in the wrong user name and password but use an e-mail address the system recognizes and get in?
DEVELOPER:Yes and no. A user can have multiple identities but only one e-mail address.
PROJECT MANAGER:So what you are saying is a user could enter any old user name and password along with an e-mail address the system will recognize and get in. Right?
DEVELOPER:Yes, the user can enter any login they want, but if the e-mail address is not in the database, they won’t get in. If the e-mail addresses match but not the user name or password, they will get a message saying the login is incorrect.
PROJECT MANAGER:So, then, they can’t get in?
DEVELOPER:They could if they enter a user name and password that matches what is stored in their profile.
PROJECT MANAGER:So, then, what you are saying is user name and password are not the only fields being checked for authentication?
DEVELOPER:Well, actually, yes, but technically, no.
PROJECT MANAGER:I’m going to shoot myself now. Care to join me?
DEVELOPER:Not today, thanks.
Source: Real Web Project Management: Case Studies and Best Practices from the Trenches by Thomas J. Shelford, Gregory A. Remillard
[tags] e mail address, mail project, unequivocal language, communicating your message, self examination, minutiae, ambiguities, red flag, information society, repetition, stakeholders, clarification, questions and answers, clarity, authentication, team members, instances, holes[/tags]