Do you know? Does your team know? Thanks to Abbot and Costello, we have one of the greatest miscommunication dialogs of all time. It was pretty simple, really:Costello: Well then who’s on first?
Costello: I mean the fellow’s name.
Costello: The guy on first.
Costello: The first baseman.
Costello: The guy playing…
Abbott: Who is on first!
Costello: I’m asking YOU who’s on first.
Abbott: That’s the man’s name.
Costello: That’s who’s name?
Costello: Well go ahead and tell me.
Abbott: That’s it.
Costello: That’s who?
OK, so you understand what is going on. WHO is the first baseman’s actual name (strange, but true, at least for this comedy dialogue). It’s comedic because as outsiders, we recognize that, but Abbot and Costello are so closely involved in the conversation, that they fail to see each other’s viewpoint. They never stop to think about where the misunderstanding is coming from. They continue to approach the conversation as if they completely understand what is happening.
While Abbot and Costello are doing it for comedic value, we stumble into these misunderstandings constantly during our projects. Why? We fail to define the terms up front, so we move forward without thinking that someone else on the project team (or even outside the project team) misunderstands what we are communicating. How can we overcome these misunderstandings of project terms?
One of the best techniques that you can use early on in the project is a glossary. This is a repository for all of the terms and definitions for the project. Think of how easily Abbot and Costello could have communicated if there was a definition for the first baseman. It would have explained his position and the fact that he had a unique first name of WHO. Perhaps they would not have even had to have that conversation since the positions were defined in the glossary.
The glossary is like the dictionary for your project. Any term that is unique to your project must be defined in the glossary. And if you think that people may misunderstand it, list it in the glossary. Some tips on your glossary:
- Fully define any acronyms that your project is using. Sometimes this can completely ward off confusion. I worked a project once where everyone on the team said that CRIS had this information or CRIS did those calculations, etc. A new project team member did not understand that CRIS was actually an acronym for a system rather than a person’s name. He asked how to get in touch with this “Chris person” and no one understood what he meant.
- Don’t include business rules within the definition. For example, if you are defining a pilot, you may want to say that a pilot is one who flies an aircraft. You do not want to include rules such as, “every pilot must have a current medical (FAA physical evaluation) in order to fly an aircraft. If they are under 40, a third-class medical certificate is obtained every three years – if they are over 40, they must have one every two years….” Just keep it to the definition of the pilot. The rules will be referenced in another section.
- Don’t “bundle” definitions. Is a customer a customer? Think about it – do you have different types of customers that you treat differently? Airlines do. They have first-class customers, frequent-flier customers, elite-level customers, etc. They certainly treat them differently when they board the aircraft, so define them differently since they are treated differently.
So does your team have a definition of first base? And does it describe the position so that anyone reading your document understands what it means?
- A Requirement from the Business May Not Be a Business Requirement - May 13, 2013
- My Time is Up! Time to Re-certify my CBAP! - April 8, 2013
- “Yeah…but so what?” - March 11, 2013
- When Did Process Improvement Start? - March 5, 2013
- Email: Help or Hindrance? - January 29, 2013
- Good BAs Define Requirements for Orange Juice - September 4, 2012
- Why Use Business Analysis Templates at All? - August 20, 2012
- When is Analysis Complete? When You’re Finished! - June 18, 2012
- Attack of the Conflicting Business Rules - May 17, 2012
- Interface Analysis – it’s not just an afterthought - March 26, 2012