Your status meetings are too long, are attended by people that have (at best) tangential involvement, and tend to wander with the desire to check off as many of last week’s “open” meeting items as possible. Stop the madness with these important realizations.
The Magic and Danger of Misunderstanding
Distinguished writer Arthur C. Clarke once noted that "Any sufficiently advanced technology is indistinguishable from magic." In my mind, we are beginning to witness this in our world of increasingly complicated projects.
The problem is that technical systems are getting increasingly pervasive, integrated and arcane all at the same time. As a result, it is far easier for stakeholders to misunderstand issues and features. Misconceptions are very problematic because incorrect assumptions can result in difficult--if not impossible--project expectations.
As systems and technology become more advanced, people will likewise begin to make an increasing number of assumptions. The issue surrounds experience, buzzwords, special terms and numerous other issues that combine to create confusion for stakeholders.
Assumption: Since the program is Web-based, we will be able to get to it from anywhere.
Project Team Perspective: Due to security concerns, the application can only be accessed from inside the firewall. Thus, "anywhere" is relative and maybe not what the stakeholder has in mind as either a benefit or issue.
Assumption: Since this new application is rules-based, we can make it do anything.
Project Team Perspective: We don't have the time or the budget to make it do "anything." Here, stakeholders may have expectations that could be met with more time and a larger budget, but not within the scope of the current project or phase of the project.
Assumption: This is the most advanced application, it must also be the easiest to use.
Project Team Perspective: It requires triple the time of the current application in your department but benefits the entire corporation tremendously. The project team will need to work with the stakeholders to help the affected group plan for the changes.
These examples illustrate that people often see, hear or read about something and then have a tendency to make inferences based on hearsay, past experience, what the system would do if they designed it, etc. Moreover, if the product is sold such that it can purportedly do anything, then lay-people may expect everything and create a completely impossible project scope.
A project team must be careful to ensure that stakeholders understand what the technical capabilities are of whatever solution and clearly document issues, risks, etc. False assumptions can literally be deadly.
Communication and Comprehension
At the heart of this danger are C&C, communication and comprehension. The project team must not only communicate features, but also must actively solicit requirements, feedback and determine the level of understanding. It is not enough to simply broadcast what a potential solution can do and gather feedback.
The state of understanding must be gauged and addressed, as well. As project complexity increases, risk increases and thus the need for clear understanding increases. Many would say that true communication necessitates the bi-directional exchange of information and determination of communication effectiveness. To an extent, this is true. The emphasis here is that not only must the important point(s) of the discussion be clearly delivered, but also an extra effort must be set forth to ensure that the points are understood and assumptions are not formed.
To delve deeper into the communication issue, more than one misunderstanding and resulting failed project can be traced to the increasingly convoluted world of technical terminology.
 Network Attached Storage.
 A line of servers that Dell Computer used to make.
 Redundant Array of Inexpensive Drives.
 Storage Area Network
Always bear in mind that it is one thing to have a discussion with another engineer or technical party. In that situation, it is fine to use technical terms, albeit maybe with some clarification from time to time. However, meeting with a stakeholder from a non-technical area and then bombarding that person with technical terms is counter-productive. Either the person will be offended, think you are a clueless "techie" or make an assumption that your solution can do something that it, in fact, cannot. With that latter case, once an incorrect assumption is formed, it can be a real problem to correct depending on how far it perpetuates and what decisions are based upon the error.
Lack of Context
Another element to consider is that people may understand certain terminology and have a degree of understanding, but they may lack the same level of context that you have. In other words, they may understand at least one meaning of the term but not why it is important to the project or why you feel they need to hear your message.
For example, if I want to value everything using an average cost, then what does "average cost" mean? Is it the average of all costs since the first purchase? Is it the average of the last 90 days of purchases? Is it a weighted average? As you can see, "average cost" can be calculated in nearly limitless ways. For everyone on a project to use average cost appropriately, they must all have a common understanding of what it is. This is a simple term, too; just imagine terms and acronyms that someone has never heard of.
Compounding the issue of confusing terminology is that people can feel embarrassed to admit they do not understand something. An entire room of people may not understand an acronym or phrase, yet nobody will ask for clarification. Why? Because no one person wants to look foolish in front of his or her peers or, worse yet, superiors.
Not to be all doom and gloom, I do have some suggestions for you to consider when communicating in the future:
Do Not Assume. Do not assume that the audience knows all of the terms you use and the context they are used in. Assumptions can seriously damage not only one project but forever mar your reputation and ability to get future work. Likewise, being able to adequately explain technical matters to stakeholders can go a long ways toward building a good reputation and assuring future work.
Define Terms. When you use technical terms and/or acronyms, be sure to explain them. Try to use simple language, give similar terms and try to explain things more than one way.
Examples and Props. I recommend that people not just give a definition but also use examples and props whenever possible. These things can make phenomenal differences. If you are explaining a complicated quoting system, then having flowcharts, screen captures and sample documents can move the discussion from theory to the real world. Bear in mind that some people can handle theory, some need to actually see things and some need to touch, use or hold whatever it is. Always remember that different people often learn in different ways; attaining comprehension may necessitate more than one method of explanation and/or training be used.
Questions are Okay. When appropriate, always tell the audience to feel free to interrupt if something is said that they do not understand. I put it this way because in small meetings, this approach is fine. In large meetings and/or formal presentations, this may be totally inappropriate, in which case you must be sure to clearly define all terms because questions may need to be held until the end. Also, in this situation, have notepads for people to jot notes down so they can remember questions when it is time to finally ask them.
Glossaries. If a project involves many people and they will be hearing terms for the first time, then consider assembling a project glossary. It will hold terms that the team will use and various stakeholders will encounter. As new terms are discovered, they should be added to the glossary. This is very valuable as everyone may know a term, but each may have a different understanding.
Standards. There are many standards, whether we are talking about wiring, bolt size, metal hardness or even accounting and corporate governance. By using standards, you can leverage a wealth of existing documentation and terminology to help reduce confusion. If external standards do not exist, then create internal standards such that methodologies and terminology can evolve and be consistently applied.
Third Parties. If you have a problem conveying something, then look for another party who understands what you are trying to communicate, understands the position of the other person(s) and then have that third party try to explain matters. Sometimes, a fresh face can work wonders. Sometimes, just having things explained by a person who has been "in the trenches" (someone with a similar outlook and experience as the other party you are talking to) can make a big difference.
WIIFM (What's In It For Me?). Always drive home why something is relevant. Don't leave it up to the audience to infer if something is important or not. Clearly call it to attention.
It is easy for stakeholders, or any audience, to misunderstand communications during projects, particularly when specialized terminology is involved. Project teams must be very capable of explaining concepts to the various parties involved and recognize the need to tailor messages for each audience. It is critical that stakeholders understand what is going on and how they are, or will be, affected. If people make false assumptions for whatever reason, difficulties and even debacles can result.
George Spafford is a project management consultant and instructor, living in Saint Joseph, Michigan. In total, George has more than 10 years of experience in information technology and project management. His areas of personal interest include project management, software engineering, organizational learning and maximizing the value added by information technology to an organization. He can be reached at [email protected].
Want more content like this?
Sign up below to access other content on ProjectManagement.com
Already Signed up? Login here.