The Problem of Nomenclature
As an IT Architect, one of my central duties is
to bridge the gap between customers (those who need new systems and new
functions), consumers (those who will use the new system or function), managers
(those who have to fund and support the project) and the technologist who build
the systems. The biggest issue that I face is often the fact that each group
has its own vocabulary to describe the situation. This makes communication and
understanding difficult and it leads to misunderstandings and improper design
assumptions and bad outcomes.
Fowler and Scott (UML Distilled 2nd Edition ) talk about four different risks when
designing IT systems: Requirements Risk (are we building the right thing),
Technology Risk (will the pieces fit together, do we have the right pieces),
Skills Risk (do we have the right people) and Political Risk (are there
political forces that could derail the project). I have seen mismatched
nomenclature - different words used for the same thing or the same words used
for different things - cause great problems throughout a project.
Mismatched nomenclature can add greatly to Requirement Risks within a project. If the various players (customers, consumers and technologist) do not have a common vocabulary, then the project will be difficult to define and the requirements will be impossible to document. Mismatched nomenclature can also increase the Political and Technology Risks in project. If one group thinks that project is impacting or about a different subject than another, they may impede the progress of the project. The interference can be due to the fact that the group thinks the project is not "high priority" because it does not match the issues that are at hand or that the project is "overstepping its bounds". Technology Risk can be increased because project members or management may misunderstand the technology needs or impact of a project.
The use of UML to describe a project (as a standard language for parts of the project) can help with some of the mismatch. The use of a standard methodology (Enterprise Unified Process , RUP, etc) can help with another portion. The most critical practice is to develop and publish, in an open and accessible spot (an intranet or web site), a on-going definitions document. Review the document frequently and share it with the team members and managers. Make sure everyone is agrees and understands the definitions. Add to the list as new terms are generated. Use the terms that the customers and consumers are most comfortable with. If the team cannot agree on the language, then they will have great difficulties agreeing on the substance of the conversation.
Mismatched nomenclature can add greatly to Requirement Risks within a project. If the various players (customers, consumers and technologist) do not have a common vocabulary, then the project will be difficult to define and the requirements will be impossible to document. Mismatched nomenclature can also increase the Political and Technology Risks in project. If one group thinks that project is impacting or about a different subject than another, they may impede the progress of the project. The interference can be due to the fact that the group thinks the project is not "high priority" because it does not match the issues that are at hand or that the project is "overstepping its bounds". Technology Risk can be increased because project members or management may misunderstand the technology needs or impact of a project.
The use of UML to describe a project (as a standard language for parts of the project) can help with some of the mismatch. The use of a standard methodology (Enterprise Unified Process , RUP, etc) can help with another portion. The most critical practice is to develop and publish, in an open and accessible spot (an intranet or web site), a on-going definitions document. Review the document frequently and share it with the team members and managers. Make sure everyone is agrees and understands the definitions. Add to the list as new terms are generated. Use the terms that the customers and consumers are most comfortable with. If the team cannot agree on the language, then they will have great difficulties agreeing on the substance of the conversation.
Posted: Tue - July 1, 2003 at 04:56 PM
