Improving ROI for infotech projects usning a language-driven approach

ESTIMATED READING TIME: 6 MINUTES

Projects Continue to Fail

The return on investment for information technology projects is questionable. According to the Project Management Institute (PMI), 12% of IT projects are total failures¹.

Total failure means that a project:

• did not meet business objectives, and
• exceeded project budget, and
• did not meet the project deadline.

Of the remaining 88% of projects:

• 27% didn’t meet their goals,
• 38% exceeded their initial budgets, and
• 45% were late.

Overall, 36% of projects failed to meet their business objective, but all forms of failure can lead to exposed financial and/or reputational risk, for example, incorrect information or late submission for regulatory compliance reporting.

Why Projects Fail—the Semantic Gap

To reduce the likelihood of project failure, it is important to understand the reasons for failure. One area on which the IT profession has focused over several decades is referred to as the "semantic gap", being the difficulty of translating natural language business requirements into the software languages and designs of information technology.

Looking at the PMI statistics for reasons why projects fail, the second largest cause of failure (40%) is due to poor requirements gathering, with those ranking at 5^th and 6^th (both at 28%) being inadequate or poor communication, and inadequate vision or goal. These three reasons have one common denominator: communication of knowledge.

Closing the semantic gap over the decades has been the cornerstone of successive IT design methodologies employed in the form of computer-aided software engineering (CASE) tools. So why are we still seeing a high percentage of project failures due to communication?

We argue that CASE tools are designed for technical specialists and, while they aid in improving IT design capabilities, they do not necessarily aid business stakeholders in better articulating their objectives or validating those objectives against system solution designs.

Another consideration is the increasing speed at which organisations demand IT solutions. Gaining agility in project activity is at odds with meticulous IT design activities, which are treated as unnecessary bottlenecks in project delivery that are, therefore, bypassed. The unseen result is increasing "technical debt" —the evolution of poorly documented and overly complex solutions for which maintenance eventually becomes prohibitively expensive.

Infotech Snake Oil, People and Culture

The infotech industry vendors continually promote technology as a solution to what is essentially a people and culture problem. For example, data catalogues are promoted as a means of solving technical debt by exposing data elements and data flows and exposing these for knowledge capture through collaborative engagement with the business community. However, this bottom-up approach generally fails to engage the business subject matter experts because:

1. business leaders see technical issues as the jurisdiction of their technical services teams,
2. the approach does not provide value to business operations, and
3. business operations teams are not provided with the incentives and resources (funding and staff).

All the above exacerbate the communication challenge.

What is needed is an approach that addresses the semantic gap from the non-technical side; a fresh perspective that enables business capability to better capture and communicate their needs so that technical services can better deliver value from their technology investment.

Language-driven Solutions

The approach we posit is in line with an emerging language-driven movement, but rather than implementing technology-centric semantic mapping CASE tools, is based on best-practice capture and dissemination of business knowledge—business definitions and business rules. This approach requires the building of business capability through appropriate tools, techniques, and language education.

So, why can’t CASE tools and data catalogues with glossaries solve the problem? The reality is that they do help, but technology cannot address the human processes needed to connect business reality with data, especially those around data discovery.

As an example, in this post, the author provides a great example of how visualisation of semantics using a knowledge graph shows the connection between glossary entries for "vendor", "vendor identifier", and "vendor name", and the data elements "VEND_ID" and "VEND_NUM". However, there are a few points that need to be explored before we can accept these connections as valid:

1. What is actually stored in these data elements? Years of inadequate system maintenance may have introduced technical debt due to shortcuts in design or creative data entry. This results in misuse of data elements because:
   • it’s easier (cheaper and quicker) to repurpose an existing data element than create or change the database design; and
   • when front-of-house operators need to capture data that the system isn’t designed for, they can combine data and store it in other fields. An example of this was at a telecommunications company where we witnessed call centre staff creating additional "product codes" to capture information that they needed to pass to fault-repair technicians, such as "customer has a dog that bites" and "customer only speaks Portuguese."
2. What if the data elements are sourced from different systems? Are there value overlaps or value collisions? For example, two different identifiers being used to reference the same vendor, or two different vendors encoded in the different systems with the same identifier.
3. What if the ERP (enterprise resource planning) system is configured to capture vendor and customer name in the same data element and you need to consider another element in the same row of data to separate the two sets?
4. Are there any business questions that are simple enough to be supported by these simple connections? Most business questions need a complex combination of data to provide value, and these data sets typically require complex database queries.

All the above scenarios need to be addressed by careful analysis of data to ensure it aligns with the business glossary entries. This requires:

• really clear definitions of the business terms (concepts) with rules about how these terms relate with others to provide an overarching picture of how the business community understand the business across functional silos, and
• development of data artefacts, such as the complex queries mentioned above, that align with, and can then be associated with, the appropriate set of glossary terms.

Business Needs, Process, and Community

If a business knowledge discovery process is used to populate the business glossary with quality definitions, and the data discovery process is used to develop appropriate artefacts (that can be verified by the appropriate business stakeholders), these definitions and artefacts can be referenced together—what we call a business encyclopaedia. Also, if these processes are driven by business needs with a top-down approach, we can achieve:

• more effective communication and understanding across functional areas, and between business people and data people;
• reduction in wasted effort from trying to catalogue all data elements, instead focusing on what elements are necessary to support business needs;
• identification of data that is not fit for purpose, as well as what data is fit for what purpose; and
• reduced risk to the organisation with regard to information supply and infotech project delivery.

It must be emphasised that building a business glossary is as much about building a glossary governance community. A business glossary—or business encyclopaedia—on its own is fruitless. Its success is based on:

• uplifting business language capability for knowledge capture,
• sharing and establishing business processes for managing and governing the community and content respectively, and
• having the support of language management specialists.

---

At Intraversed, we have witnessed real improvement in business value through this language approach to data management.

But don’t take our word for it. This article written by David Miller, CDO of Macquarie University proves the value of having a partnership with us: Tech-Exec magazine, issue 17 page 60.

Join the discussion on LinkedIn