A Team Sport

We often remark that Analytics is a team sport. The idea of the brilliant data scientist locked away in a quiet room unlocking the secrets of the business with sophisticated analysis that only geniuses can understand simply does not work in the business world. Business problems are messy, data is never clean enough, and customers are not always rational. Scientific analytic principles developed to tame well-behaved atoms and molecules rarely provide clear answers when applied to populations whose first mantra is “break all the rules.”

Having said that, analytics provides insightful pictures into patterns of behavior that are used to predict trends and response. Additionally, analytics in the business environment must be coupled with hard-to-quantify soft knowledge, that is, expert, intuitive knowledge based on hands-on experience and direct interaction with the business process.

As such, close interaction between the business managers and the analytic developers is an essential ingredient to develop analytics that drive action. Because the process we describe embraces change and continuous improvement, frequent communication among the principal parties in the project is necessary to ensure the project stays focused on the goal and does not meander off course.

The Cassandra Effect

If the analytics are developed apart from the participation of the managers with the responsibility to use them, they may have difficulty adopting the analytical solution due to lack of trust in the methods used. This is often called the Cassandra effect. Cassandra was the daughter of King Priam and Queen Hecuba of Troy. Greek legend has it that Cassandra had the gift of prophecy or foresight to see the future but also the curse that no one would believe her. According to legend she foresaw the tragedy of Troy but was powerless to change the course of action because she was not believed. Analysts who develop predictions and forecasts in isolation from the managers whose necks are on the line to deliver the results risk the same fate with their insights and information disregarded even when they point to the correct course of action.

Analysis Paralysis

We have all run up against the bane of modern business with access to so much rich data—analysis paralysis. As we discuss in Decision Theory and Guided Analytics, when presented with too much information or too many choices, the manager can become overwhelmed, not sure of which way to turn. This does not mean that we supply incomplete or limited information that risks steering the manager in the wrong direction; rather we present analysis results that shed light on the key levers that a manager needs to address the situation at hand. The good-enough principle is crucial in the early stages of an analytics project to ensure we are addressing the right priorities and are focused on decisions that matter. Other supplemental analysis providing nuance and detail can follow later.

How do we know which levers are key and which are supplemental? A well-constructed Decision Analysis and Monetization Strategy can provide the map to identify critical leverage points to address early and those that can be developed over time.

What Do You Want? What Do You Have?

Using the data of the business to tap into new revenue opportunities or unlock trapped productivity is the essence of our proposition that internal business data is the best asset for monetization that businesses have. The nature of a data monetization project is that the opportunity is not well understood, hidden in the trends and patterns of the data, and lost in the averages.

In large organizations, IT is typically the steward of the business data, responsible for data quality and security and most familiar with what data is available. IT processes rely on structure and discipline to ensure they can protect and deliver quality data to the organization. Marketing and Finance are typical consumers of the data for analytics. When a marketing analyst embarks on a Monetization Strategy project, one of the first stops will be to IT with a data request. The IT manager will ask for data requirements, but oftentimes the analyst does not have great visibility into the data sources available and what is needed at the outset may be different from where the analytics will end.

A tug-of-war may ensue, with the analyst presenting requirements in broad terms, hoping to cast as wide a net as possible, whereas in reality she may only use a portion of the requested data. However, retrieving large quantities of complex data can be a time-consuming process for the IT manager, and if all clients follow similar strategies, IT can easily become overwhelmed with “data gopher” activities and fall behind delivering its core processes. The IT manager will attempt to narrow the scope; the analyst will fight to keep it broad.

If the IT manager and analyst are able to form an agile team where agreements are made to work with small batches in an iterative fashion, the analyst has the opportunity to learn the data needs as the analysis progresses and the IT manager spends less time pulling large amounts of unused data.

Many organizations, realizing the waste of valuable IT resources spent chasing data, have begun to make data sources more readily available to the business through on-demand business intelligence (BI) “sandboxes” in the data warehouse where users can run their own queries, or analytic data marts, which are separate databases storing the data to support analytics. This opens up much more visibility to the business manager but at the same time creates a responsibility to learn how to work with data more directly in a responsible manner.

A Picture Tells a Thousand Words

As discussed in the chapter on Guided Analytics, visualization is powerful. Data visualization should be imbedded early in the process as part of the Decision Analysis phase; don't wait until you get knee-deep into the Agile Analytics phase to start visualization efforts. Visual presentation of information requires unique data modeling and structure, triggering serious rework if not included early in project.

Not Every Child Is Beautiful

The products of analytic projects can become like children to the core team members who work together from inception to production. Just as no parent has an ugly child, project teams risk losing perspective about the value of their analysis. Many a team has spent countless hours, over many months, preparing a strategy presentation for the executive management only to be sent back to the drawing board because they had veered off course. Early and frequent results review meetings between team members and stakeholders help to ensure that the project stays on course. As new information and learnings become available, these can be shared with stakeholders at an early stage, as the insights gained may prompt the leaders to modify the direction.

Meet Early, Meet Often

An agile process thrives on frequent communication among team members. We find regular, short stand-up meetings of the working team are necessary for team members to keep in sync yet preserve enough time to get work done. We will put in place weekly status meetings to drive broader communications and provide vehicles for issue and risk escalation. An agenda should be followed but should be flexible enough that the team can deal with expected issues. The time should be strictly limited to encourage members to be prompt and focused. Agenda items not covered are placed on the agenda for the following meeting.

Between meetings, members are encouraged to ask questions as they arise and resolve via email or chat. If the project is significant enough, a war room could be set aside where members can work side-by-side and address issues in real time.