Is it One Issue Masquerading as Several - Or is It Many Things Masquerading as One?

There's nothing more confusing in an exceedingly project than everybody on the project using several different terms to delineate one concept or object, or everybody using one term to encompass several completely different ideas or objects.
An example:
I'm 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 meant to perform a task, for instance; inducting a replacement employee into the organisation.
The seller of the application provides to the database schema it uses the name of 'Encyclopedia'. I call it a 'database' when addressing the Architecture team, alternative people call it a 'dictionary'. The primary time I heard someone talking concerning a dictionary in a meeting, I assumed they were talking regarding hash table constructs. The labelling gets more confusing however.
Within the diagrams there are five levels of symbolism that kind a hierarchy which are known as:
- Framework
- Agency
- Level three Sub Method
- Level four Sub Process
- Level 5 Diagrams
According to 1 cluster on our project, Level 5 Diagrams are actually at Level 6 and also the 'real' Level 5 is a Level 4 and the 'real' Level four is missing, and they have proven this argument correct. Consistent with a totally different cluster, Level five isn't a Level half dozen and a Level six 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 may see the irony within the latter group's description? Truthful point.
When printing reports, Level five is called a Level 2 and Level 4 becomes referred to as Level 1. (???)
So what did the initial demand specifications describe? Nobody knows as a result of when myself and the new Design team came on board we have a tendency to found there was absolutely no documentation on any decisions created or styles approved.
== WHAT WENT WRONG ==
Two parties who initially created up the project came along to taxonimise their business processes and loosely arranged a group of terms to be used to debate their concepts. Later into development another party joined and realised that what had been set up as classifications did not cater for his or her business needs and redefined the terms to cater for their business method modelling.
The initial programmer named all objects inside the application differently once more due to confusion.
Coding has become an attempt of deciphering what the consumer is requesting relying upon their own flavour of the vernacular.
Our system for company data management has become a case for risk management.
== HOW COULD THIS HAVE BEEN AVOIDED ==
An initial glossary of terms with their definitions ought to have been approved and published for all to read and use. This can be tantamount to clear company communication and also the facilitation of expedient programming solutions.
This is most likely the worst case of miscommunication I've got experienced and highlights the need for any project to create it a priority to create a dictionary of terms to be used and then publish them before construction of a system begins.

Article Source: http://www.gamblingarticlessite.net

Doris Hill has been writing articles online for nearly 2 years now. Not only does this author specialize in Reference Encyclopedia Dictionary, you can also check out his latest website about: Multivitamins For Men Which reviews and lists the best Herbs For Libido

Please Rate this Article

5 out of 54 out of 53 out of 52 out of 51 out of 5 

Not yet Rated