Why IT staff should care about how the business defines its terms

ESTIMATED READING TIME: 4 MINUTES

When someone from your business asks IT to build a “solution” to meet their business need, it’s the start of a long process that both parties hope will be successful.

But we know that’s not always the case.

And when it isn’t, the business will blame IT for blowing out time and/or budget and for the end product not being what they wanted.

IT will likely be able to point out that they delivered what the business asked for, but what they asked for wasn’t what they really wanted, and how were IT meant to know that?

It’s a hot mess and it’s unnervingly common.

Achieving ‘knock it out of the park’ success with your IT projects rests heavily on that early communication being clear and accurate.

The fact that it’s often impossible to know if the communication is accurate means the risk of failure is high.

Solving the “semantic gap”

There have been many attempts by IT to resolve the “semantic gap” issue through different software delivery methodologies.

The latest approach hangs its hat on business glossaries. Business term definition can certainly mitigate communication issues. However, having a glossary doesn’t, in its own right, solve the communication problem.

To truly reduce communication-based errors and failures in IT project success, solid definitions of key business terms, definitions written to a clear and consistent structure, that outline the specific data-related parameters of the term, are needed.

When all the business terms used in the project’s foundational documentation have this kind of definition it can help eliminate a lot of unidentified miscommunication.

It will mean that IT staff will know exactly what the business staff mean when they say “We want to see the current X, Y and Z figures” because your glossary will list X, Y and Z and the definitions of X, Y and Z will include exactly what source data is used to create those figures, exactly what analyses or statistical mathematics need to be applied to that data, and how to present it so the business staff understand what they’re looking at.

And the project is more likely to succeed because the requesting business staff used those same definitions to draw up the initial request. Everyone is using the same language.

That’s a truly useful and effective business glossary.

How it works in practice

Let’s say your HR team want a software solution that allows them to see a staff member’s tenure time, leave accrual, percentage of sick leave taken each year and stats on their use of leave without pay, as well as flagging any other relevant data (like complaints made against that staff member).

With this kind of request, IT could go to the relevant databases, create a great dashboard-style user interface that pulls these raw numbers and calculates percentages.

But you know that it’s never that simple.

What do HR mean by “leave accrual”? All types of leave? Annual leave? Current accrual level or historical too?

I’m sure your IT staff have learned the hard way that they need to ask a lot more questions.

So, imagine if both IT and HR use a single business term definition “encyclopaedia”.

HR choose the terms they use in their solution request, based on the definitions of those terms in the encyclopaedia. Those definitions include details about what data IT need to use and what needs to be done to that data, in order to supply HR with the actual information they want to know.

If “Leave Accrual” was a term in the encyclopaedia, its definition would include exactly what type of leave to include, the location of the raw data and the calculations required to determine this figure. It would also include any other data to be factored into the final equation and restrictions that must be applied to information created using this data, such as sensitivity or privacy.

With this kind of definition at the fingertips of both the requesting HR staff and the IT staff fulfilling the request, the likelihood of project success, first time, is significantly increased.

The “measure twice, cut once” principle of successful IT-Business projects

To achieve such a glossary requires effort, no question.

Definition writing must involve both business and IT staff. It requires a lot of clarifying conversation about the meaning of each term before you begin writing the definition. It may involve doing some analyses on data to ensure understanding. And it could certainly bring to light bigger problems with the use of language across the organisation.

The scope of writing such a glossary can seem too big to make it a practical undertaking.

It’s akin to the old craftsman’s adage, “measure twice, cut once”. Double the time you spend preparing and you’ll reduce the risk of wasted time, effort and money re-doing what was incorrect the first time you tried.

It’s the same with glossaries. Devote the time, effort and resources required to define your terms really well now, and the far greater cost of time, effort and money in failed projects will be eliminated.

As a consultant in business term definition writing, I know both the great benefit in this approach and the hard sell it is to get support across the business and IT for this kind of thinking. Ideally, your organisation will see the benefit in establishing a glossary and resourcing it strongly enough to get it written and functional quickly.

I also know that’s unlikely.

So in reality, it may fall to IT staff, at the point of presentation of a request from the business, to undertake term definition activity before any other scoping takes place. We suggest insisting on a term definition meeting, at the outset of the project, before which IT staff have identified all the business terms in the project document that need a clear definition.