Developing a big data program requires alignment of the objectives of the initiative with the needs of the business. Usually it is the other way around -- start with business needs. Because many of these programs are stood up by the technology organization, the business may not have enough understanding of what is possible to articulate their needs in a big data context.

A program has to be developed in alignment with a current need. In the case of a panelist during a recent panel I led with CIO and SVP level people, it was detecting fraudulent transactions. That capability allowed business users to ask new questions about customer behaviors once the infrastructure was in place. So beginning with a more mundane, and simpler, objective that has clear value will allow the organization to start the process.

As maturity is developed, more interesting applications can be designed. As one of the presenters said, “you cannot ask for some money (but you don’t know how much), for a project (that will take time but you don’t know how long), to produce a capability (that you are unsure of)” There is no funding for “science projects” with ambiguous outcomes.

Unfortunately, many big data programs have become extended science projects without clear goals or an end state. Successful big data projects build off of more modest initiatives that have measurable ROI. If a strong BI capability is in place, add customer support call log content to the analysis of call center statistics. Leverage a sentiment analysis tool that allows identification of negative tone which can indicate unhappy customers. Look for trends across categories, products, departments, call centers and types of agents. Look for feedback about specific processes -- those call center logs and customer complaints will pinpoint exactly where the internal process issues are.

Creating a Realistic Vision

Big data programs need to be part of a vision of how the organization will transform digital processes. What capabilities will achieve the strategic and competitive goals of the enterprise through leveraging of any source of data that can be imagined – whether that is practical today or not? How would the organization embed products, services and related information in the customer’s world in ways that would make the business indispensable? What does each business unit need to achieve to be part of that grand enterprise vision?

This stimulates creative thinking about the future state that can then be brought back to reality. What are the challenges and gaps in processes to achieving some version of that future state? Where do decisions take too long or where is information missing? What does the business want to know about customer motivations and behaviors, about competitors, product performance in the field, about the marketplace?

Create a compelling vision for how the enterprise will operate in the future and how new ways of interacting with data, content and information will speed time to market, increase agility, provide just-in-time knowledge across departments and serve customers in ways that strengthen the relationship, increase revenue and immunize the organization against competitive threats. The grand vision is the North Star that aligns smaller, incremental projects along the way. You’ll never get there, but you will have strategic direction and common goals for all of your data initiatives.

Build a Viable Business Case, Leverage Foundational Capabilities

Because big data programs can be ambiguous and it takes time to go through the maturity curve, you should set up programs that capitalize on tangible capabilities and outcomes in order to support some experimentation and learning.

A good deal of the work that needs to be completed to put analytics and big data capabilities in place will not have a direct, short-term return. Those capabilities need to be developed while addressing other problems that do have a direct return. Call those “quick wins” – they show the enterprise the value of the investment in the short run while the long term vision articulates the path to more ambitious goals.

Some of the foundational capabilities need to be in place before there is much that can be done. In this context it is a matter of the cost of doing business (CDB) as opposed to a return on investment model (ROI). We cannot always justify efforts through strict return on investment calculation of value today, but we know we have to have this to compete in the future. That argument will only hold up with a tangible capability that can solve problems today and model “archetypical” future state solutions from similar organizations in the marketplace.

Detailed Business Requirements in the Short Term

Since the future state will likely require additional maturity in order to clearly articulate detailed business requirements, short-term capability requirements are developed based on use cases and business scenarios that solve more immediate problems:

  • What insights are required today and what are the inputs required for those insights?
  • What analytical tasks are manual, labor-intensive or difficult?
  • How can additional data sources inform a problem or observation?
  • What unstructured data will need to be brought into the picture?
  • Who in the business owns the data?
  • How will customers, processes, content and data be described in business terms?
  • What are the supporting business processes that enable data sources to be curated and ingested?
  • How will the data be secured?
  • What are the business requirements for testing results and ensuring quality?

Short term requirements need to begin with specific users, business processes, data sources and expected insights and outcomes that are achievable with the current state of knowledge and maturity.

Consider big data programs an extension of current capabilities. There are nuances and details that require new ways of thinking about data and content -- especially around bringing in unstructured information into analysis.

Editor's Note: This is the second in a three part series. Read the first post, How Big Data Projects are Different