By Nigel Turner, Information Management Consultant, NHT Data Consultancy Ltd.
The Roman philosopher and statesman Seneca once observed “Every new beginning comes from some other beginning's end.” Writing this as a guest blogger for Harte Hanks Trillium Software marks a beginning for me, but also marks the end of another beginning.
For most of the last 30 years, I worked in various IT, data management and CRM roles in a major global telecommunications company, British Telecommunications. BT is an organisation with a $30 billion (£20 billion) turnover, 100,000 employees in over 150 countries, and more data than it’s possible for most of us to envisage.
A former colleague once worked out that if all the data held by BT was printed on A4 sheets, and these were laid end-to-end, they would stretch from the Earth to Saturn and back, a distance of over 1.6 billion miles across the cold, dark void of our solar system. For the less cosmologically conscious amongst us, this is a very long way indeed.
In this context, where the company was storing vast quantities of data and it was growing exponentially year-on-year, the challenge of data governance was never going to be easy. And it wasn’t. Here’s an example of how things could and did go wrong with data when BT started its data improvement & governance journey back in the mid-1990s.
It centred on one particular town, Wolverhampton in England. Business reporting applications had identified a trend which suggested many customer faults had arisen as a result of vandalism of BT network equipment. So BT launched into action, quickly authorising a business case to better secure and protect its equipment in the hope this would discourage further attacks. But one sceptic decided to relook at the data before committing the expenditure.
He discovered that all fault data in Wolverhampton at that time was inputted by a lady named Veronica. So he thought it worthwhile to talk to her. When he did so he had a surprise. She told him that when she entered details of a fault onto the main reporting system, she used a one digit field to enter her initial (V) to show she had input the record. Unfortunately the field in question was intended to capture cause of fault, and, you’ve guessed it, V was the input code for Vandalism.
The business case was rapidly and quietly filed away under ‘close shaves’, Veronica was put right and the problem rapidly disappeared.
This taught me a few home truths about data quality and data governance. First, problems arise for all sorts of reasons, usually a combination of people, business process and IT issues conspiring together to make things go wrong. This case also showed that data governance is not about better IT alone but better business practice; in this case IT was not a major cause of the problem.
This was one of many data quality issues that surfaced at that time. So BT decided to act. My role was to coordinate a programme of activities to start to address the problems. Ultimately this programme, which evolved to embrace the whole enterprise, lasted for close to ten years, proving data governance is not a short term fix but a long term commitment to continuous improvement.
By the end of the programme, BT saved hundreds of millions of dollars as a result of better data governance and improved data quality. Near the culmination of this journey, industry analyst firm Gartner commented that ‘BT is one of the few companies that is actually meeting the challenge of managing data quality effectively.”
Over the next few months my future blogs will outline our data governance journey. I’ll relate how we took our initial steps, secured business and IT support along the way, got going with improvement projects, and what we found when we reached our destination. I’ll also touch on the times when we got lost and had to find the right road again. It was a long haul but well worth the trip in the end.



