A manufacturing company’s general manager sits through a presentation from the IT team: a new data warehouse infrastructure, analytics licenses, and a consulting package. The total budget is substantial. The slides are polished, the references international. The board is ready to approve. But no one has asked the obvious question: ‘What exactly will we measure at the end of this, and how will we know it worked?’ This is precisely where big data projects begin to go wrong.
Big data has become one of the most discussed concepts in the technology agenda. The volume of unstructured data sources is growing: web server logs, customer interaction records, supply chain movements, production line output. The promise of turning all of this into actionable insight is genuinely compelling. But the history of enterprise software tells us something important: the distance between acquiring technology and creating business value is far wider than most executives anticipate going in.
The first question a board must ask concerns business objectives. Which specific business problem does this project solve? ‘Making better decisions’ or ‘becoming data-driven’ are not sufficient answers. Which process, which decision, and by how much will its quality improve? What is the measurable financial or operational impact? If no clear answer comes back, the project is not yet mature enough for approval. A big data infrastructure is not an end in itself; it is a means to a defined purpose. Technology acquisitions without a defined purpose have a well-documented track record in enterprise software, and it is not encouraging.
The second critical question concerns data readiness. What is the quality, consistency, and accessibility of the company’s existing data? Big data projects frequently stumble on a hard reality: source systems hold data in different formats, under different definitions, and at varying quality levels. If the sales system and the accounting system identify the same customer under different codes, merging those two sources requires data cleansing and standardisation work before any analytics can begin. That work takes time and money. In project presentations, it tends to appear as a single line item; in practice, it is often the most demanding phase of the entire effort.
The third question is about competency. Who will run this project, who will own it, and who will interpret the outputs in a business context? Analytics tools do not begin working the moment a license is purchased. They require people who can operate them, translate findings into business language, and act on conclusions. Bringing in external consultants is a legitimate option, but at least one or two people inside the organisation must be capable of owning the work after the consultants leave. A system that falls into disrepair once external support ends is one of the more common and expensive outcomes in big data projects.
The fourth question is about measurement. How will you define success? Six months after the project closes, which indicator will you look at to determine whether the investment was worthwhile? Total cost of ownership — TCO — must go beyond licenses and hardware. Internal labour, training, ongoing maintenance, and the cost of any opportunities deferred during implementation all belong in the calculation. ROI analysis must be built on this foundation, not on abstract efficiency promises. The board should ask the presenting team for this calculation explicitly and should not approve without seeing a concrete answer.
Among practical challenges, budget management deserves particular attention. Big data projects have a consistent tendency to exceed initial estimates because scope expansion is nearly unavoidable. Integrating one data source surfaces new questions; new questions generate new data requirements. A phased, controlled approach — focusing the first stage on a single business question, measuring the result, and expanding from there — produces more sustainable outcomes than building the entire infrastructure at once. It also limits risk and accelerates institutional learning in a way that a single large deployment rarely does.
The board’s final decision criterion should be straightforward: if the presentation in front of you clearly sets out the business objective, the state of data readiness, the competency plan, and a measurable definition of success, put the project on the evaluation agenda. If any of these four elements is missing, send the presentation back and ask for it to be completed. When a big data investment is reduced to a technology purchase, the infrastructure gets built but the value does not get created. Protecting that distinction is exactly what a board is there for.
This article was originally written in Turkish by Gökhan MERCANOĞLU on April 11, 2011 and has been automatically translated into English and other languages using machine translation.