That's why in April I began what will be a series of five articles covering how to cut through the vastness of information and get back to the very basics of effective business analysis. In my first article in the series, I discussed the importance of understanding overall business goals. The next step is developing a common vocabulary to be shared by your entire team.
A Glossary of Terms
At the very beginning of a project, it is absolutely essential that you and your team develop a glossary of terms, which is a type of requirement model that lists in alphabetical order the terms, definitions and aliases that may be required to support the development of your solution. The document will ultimately be the foundation from which all of your requirements are developed.
As obvious a suggestion as this might seem to be, I would estimate - and it's a generous estimation, mind you - that only about 10 percent of organizations today actually take the time up front to create a glossary of terms.
What is the difference between a client, a user and a customer? What is an executive sponsor? Are sponsors and stakeholders the same? What is the difference between business requirements, user requirements and specifications? And, what about all of those acronyms that we only vaguely understand? What do those mean? These questions and many others should be discussed and agreed upon and then documented in your glossary of terms.
The easiest way to do this is through brainstorming sessions with key personnel. Once everyone is in the same room - either real or virtual - the group should work together to hammer out as many essential terms as possible. In order to build consensus on definitions, the facilitators of these brainstorming sessions should use voting techniques in lieu of all-out dictatorship.
Avoid Confusion Today . . . And Tomorrow
With tight deadlines and demanding stakeholders always a concern, it's tempting to bypass the busy work of developing a glossary and assume everyone is on the same page. I can tell you from firsthand experience this type of shortsightedness will do nothing but hurt you - both today and tomorrow.
It's a simple fact: words and phrases mean different things to different people -especially when we enter the always-dicey realm of corporate jargon. If terms aren't understood from the get go, misunderstandings of expectations, wants and deliverables are inevitable, and they could lead to conflicts throughout the life of a project. A comprehensive, well-put-together glossary will save you valuable time and energy, allowing you to focus your efforts not on simply communicating but on developing the most effective solution.
Create a Living Document and Share It
Technology has been wonderful for businesspeople - and not just because it allows us to secretly watch hockey highlights from our desks. Technology today has made it easier than ever to create, share and store information. A glossary of terms is no longer a bunch of pages that you bind together and then stick somewhere on your bookshelf. You should always think of a glossary of terms as a living document that has the power to evolve and grow along with projects, programs and organizations.
Even after a project has been long completed and celebrated, its glossary of terms is still valuable and should still be maintained because it can be used as a baseline for future projects. Aside from some unique particulars, the terms and acronyms will be applicable to teams throughout your organization.
And, this brings me to the sharing of information. If your organization has an Intranet site or one shared location for information, glossaries of terms should be housed there and made available to everyone. Glossaries are excellent tools for educating new employees and saving them from having to smile and nod at all of your confusing acronyms for their first six months on the job. Knowledge sharing is an easy, efficient way to help increase another kind of sharing - profit sharing.
Next Time: Requirements Sources
Next time, for my third article in this five-part series, I'll cover how to determine the sources from which you will extract your requirements. In the meantime, I'll allow you to document your own definitions for extract and requirements.
This is the second in a five part series of articles by Glenn Brûlé.
Glenn R. Brûlé