The Business Case for a Business-wide Glossary

ESTIMATED READING TIME: 7 MINUTES

This is the third and final blog in a series focusing on the work of Business Analysts (BAs).

In the first blog, we covered the pro’s and con’s of workshops and one-on-ones, and the situations we think best suit each. You can read that blog here.

In the second we talked about glossary software and why it’s worth the cost. You can read that blog here.

When looking at the cost of a glossary specific software platform, the obvious elephant in the room is whether the cost is really justified.

And the answer is, of course, no it isn’t… if you’re only using it for a single project.

Today, we’re discussing why it should be a BAs goal to establish an organisation-wide business term glossary, which can be used for each and every project, as well as many other purposes throughout the organisation.

Why Organisation-wide Business Term Glossaries Should Be a BA’s Goal

While we recognise that it’s usually the needs of a particular I.T. project that lead a BA to undertake business term defining activities, our position (as experts in glossary building and term definition writing) is that business term glossaries should be seen as an organisational business-as-usual (BAU) activity.

There are several reasons we believe this:

1. We love writing definitions but we don’t like re-inventing the wheel.

Once a project has invested time and effort into establishing definitions for core business terms, it makes sense that those definitions become formalised throughout the organisation and used for other projects and activities. Think of the time it’ll save you on the next project. Don’t keep re-establishing base language for each project individually!

When a glossary is established and implemented through the organisation as the single source of truth for language and metric definition, future projects can get underway much more quickly and effectively because everyone is using standard language already.

2. Your project isn’t the only place problems may arise from use of unclear language.

Most good BA’s start with definition writing because they understand how it can undermine project success if we don’t mean the same thing when we use the same term.

It’s just common sense.

But if terms are used differently among the stakeholders of your projects, there’s a good chance that the meaning of those terms is unclear in the requests for, understanding of, and creation of, reporting materials between divisions and units.

Therefore, there is significant benefit to an organisation when they invest in establishing universal common language. We’ve written some case studies about just this kind of benefit – read them here.

3. The cost of creating project glossaries for each project is high.

How much time do you (or your organisation’s BAs) spend on term definition, per project?

Now estimate the dollar value of that time.

And now, add to that the time the project team spend debating which set of reference data (valid values for a term) is correct? And estimate the cost of that.

(of course, they may be time pressured, so they go straight to creating a new set of reference data and ignore the confusion this will cause to future projects, not to mention by mis-matching data and dashboards – the cost of this can be astronomical)

We worked in one organisation that was able to estimate the effort spent redefining common terms across one year’s worth of projects. Consequently, they calculated that a full ROI on the investment of an organisation-wide glossary would be achieved in just eight months.

4. The potential cost of not having standardised language across the organisation is high.

Projects fail due to lack of consistent language across the organisation. The cost of trying to fix these failures can be huge.

We were once engaged by a company to sort out why the IT compliance reporting component of a project had failed to deliver against requirements. The amount spent on this reporting component was over $200k. But the risk to the organisation for not being able to report compliance could have resulted in a much, much higher cost.

We identified the root cause of this reporting problem for them and it all came down to the definition of one word.

Here’s another example. We once worked in an organisation where, due to the absence of a standard definition of a core metric, getting correct numbers to senior staff was impossible. Several different divisions used their own method for capturing data for this metric, so each report on the metric gave conflicting numbers.

Over time, this led to the development of a complex and expensive set of business and IT system processes. These processes evaluated the various data from the different platforms and estimated a final report number.

And the cost of all that “work around” development, to achieve only an estimated number? Over $6M.

5. Unseen risk

Unseen risk is the most serious of all potential dangers for businesses without a single, universal business glossary.

Glossaries, at first glance, can seem like a rather uninteresting administrative activity, without much impact. But when we do not have standardised definitions of core business terms and metrics, incorrect reporting and misunderstood figures and metrics create risk for decision makers.

But even more worryingly, these poor quality figures don’t announce themselves as poor quality.

Let’s say the senior management team request a report on customer retention for a 12-month period. They have a particular understanding of what the “customer retention” figure means.

However, in the division that deals with customer accounts, the term “customer retention” isn’t used. They do measure “account retention”, which sounds similar. So they assume this is what the senior managers are after.

This was a logical assumption to make – but unless it’s checked with the senior managers to make sure this is what they’re after, it represents potential trouble.

If the senior team intended to review a certain number/calculation they refer to as “customer retention”, but which is different from the number/calculation the customer accounts team provide (because they’re providing “account retention”) then no one in this process realises they’re not talking about the same information or calculation of information.

That’s unseen risk.

And it should scare senior management teams.

The Business Case for a BAU Business Term Glossary

Given the cost of establishing and successfully maintaining a glossary, including the cost of the software that supports this activity, one question always jumps to mind – how to justify the investment.

It can easily seem like too much cost. Too much time. Too much effort.

We understand.

Glossaries don’t seem, at first glance, to matter enough or be important enough to be given any ongoing and deliberate budget, time and energy.

Therefore, a business case must be put to managers to justify undertaking it.

An effective justification or business case is usually the deciding factor between whether glossaries get the resources they need or not.

And the key to a successful justification is a clear and unequivocal Return on Investment (ROI).

Calculating the ROI

So, we’ve decided to lay out the key activities to undertake to help you calculate the costs and savings associated with project-based versus organisation-wide glossaries, which should give you solid evidence for the ROI of the latter.

1. Start small and work smart: don’t try to boil the ocean. Start with a pilot glossary. Pick a new project and convince the project manager that a shared business term glossary will help the team. Have them establish a simple collaborative space to store definitions, e.g. a confluence page or shareable document, and have one person assigned to its upkeep (probably you, the BA). Make sure the team understands the importance of collecting this information and tracking its use.

2. Track all time invested in understanding the term and writing the definition, its valid values and their meaning. Make sure that the project manager has established an activity code for booking this time separately from the analysis stage.

3. Track all time relating to resolving conflicts. This needs the PM to establish separate activity against which the team can book time spent resolving issues caused by conflicting values between the definition and the data being captured. It also needs the issues to be documented along with the methods for resolving them and, ideally, have the time tracked against each issue.

4. Have the team track the number of times they use the shared glossary.

5. At the end of the project, you should have figures that represent:

• the cost of creating the glossary content;

• the potential savings (value) to other projects for reusing the glossary content;

• the cost of resolving issues caused by not having quality definitions;

• the value of knowledge captured and reuse of the method for resolving issues;

6. This last step requires extrapolating the above metrics across the organisations projects that are similar in nature.

The final point to remember is that your pilot glossary is not, and must not, be the final solution! Remember, a corporate-wide glossary, and more importantly its content, need to be supported by effective governance and business-as-usual management processes. And this support and governance will need to scale beyond that of the pilot glossary. Therefore, you need to choose software that will effectively enable the BAU at scale for the whole organisation to benefit.

Join the discussion on LinkedIn