Adopting a common language in your project

Volumes have been written about the need for executive sponsorship and business buy-in as key factors that can make or break your business intelligence project. These factors are of course true of most, if not all IT projects and I am of the opinion that the understanding of this need has matured over time in the industry.

Indeed, the common frameworks and methodologies in use in our industry, for example TOGAF ® (The Open Group Architectural Forum) in the architectural space and PRINCE2® (Projects In Controlled Environments) in the project management area, all reinforce this need.

In my experience, however, an equal challenge is that the business often lacks a common language, or worse, assumes that the meaning of ‘something’ is universally understood when in fact it may have many meanings across the business.

What does this mean?

Business intelligence projects should ideally be viewed as enterprise information assets, and as such tend to cut across internal organisational functions. Within these functions it is likely that the business expresses common concepts using descriptive phrases, but does not recognise that these phrases may also be common in another part of the business, albeit with a different meaning.

Take this example of common phrase in the life insurance industry, that of start of a life insurance policy.

• To the customer, this is likely the day that they signed the policy documents.
• To the finance department, this could be the day that the first premium is received.
• To the product owner, this is likely the day the policy that the policy comes into force.

So when a consumer of a business intelligence solution sees an attribute called ‘policy start’ they often automatically assume the bias of the function that they are most familiar with, sometimes with undesired consequences!

What can be done about it?

Business intelligence professionals are accustomed to identifying these kinds of issues in their engagement with the business, and subsequently highlighting the associated risks to the solution and to the organisation. The conversations needed to resolve these issues are sometimes surprisingly tense as functions can be quite parochial in nature.

Typically, such projects benefit from the formation of a cross functional information governance group. This group has the mandate to receive requests from the project to agree and define the common language required to make best use of these enterprise information assets. (The information governance group of course has other roles.)

Early identification and resolution of these kinds of issues is important to ensure the development of a robust data model that represents the business. More than ever it is vital to ensure that the focus of efforts in this area are on the business.

Technology is an enabler only, not a mechanism for overcoming the lack of a common language. It never fails to surprise me how common this issue still is, and the lack of will to address the problem, rather than only the symptoms.