There is nothing more confusing in a project than everyone on the project using many different terms to delineate one concept or object, or everyone using one term to encompass many different concepts or objects. An example: I am currently supporting a Business Process Diagram repository, which is basically a backend database that holds diagrams and their annexed symbols, that pictorially communicate business processes in a flowchart (BPMI) format: Processes that describe how an employee is supposed to perform a task, for instance; inducting a new employee into the organisation. The vendor of the application gives to the database schema it uses the name of 'Encyclopedia'. I call it a 'database' when dealing with the Architecture team, other people call it a 'dictionary'. The first time I heard someone talking about a dictionary in a meeting, I thought they were talking about hash table constructs. The labelling gets more confusing however. Within the diagrams there are five levels of symbolism that form a hierarchy which are called: - Framework
- Agency
- Level 3 Sub Process
- Level 4 Sub Process
- Level 5 Diagrams According to one group on our project, Level 5 Diagrams are actually at Level 6 and the 'real' Level 5 is a Level 4 and the 'real' Level 4 is missing, and they have proven this argument correct. According to a different group, Level 5 is not a Level 6 and a Level 6 would be an embedded sub-process of a Level 5. In response to the latter group's description of the hierarchy, the former group asked if anyone could see the irony in the latter group's description? Fair point. When printing reports, Level 5 is referred to as a Level 2 and Level 4 becomes referred to as Level 1. ('?) So what did the initial requirement specifications describe? Nobody knows because when myself and the new Architecture team came on board we found there was absolutely no documentation on any decisions made or designs approved. == WHAT WENT WRONG == Two parties who initially made up the project came together to taxonimise their business processes and loosely agreed upon a set of terms to be used to discuss their concepts. Later into development another party joined and realised that what had been set up as classifications did not cater for their business needs and redefined the terms to cater for their business process modelling. The initial programmer named all objects within the application differently again due to confusion. Coding has become an effort of interpreting what the client is requesting depending upon their own flavour of the vernacular. Our system for corporate knowledge management has become a case for risk management. == HOW COULD THIS HAVE BEEN AVOIDED == An initial glossary of terms with their definitions should have been agreed upon and published for all to view and use. This is tantamount to clear corporate communication and the facilitation of expedient programming solutions. This is probably the worst case of miscommunication I have experienced and highlights the necessity for any project to make it a priority to build a dictionary of terms to be used and then publish them before construction of a system begins. |
