Introduction

When thinking about developing a new data analytics program, two questions you need to address are:

1. What services do you need to provide?
2. To whom do you need to provide these services?

I’m assuming here that your organization already provides products or services of some sort and that, through a new or enhanced data analytics program, you want to take advantage of the data associated with these products or services. Also, if you’re like many other organizations, the processes and systems that support your existing products and services may be run somewhat independently.

Partly as a result of this, the data associated with these processes and systems may need to be organized and managed somewhat differently from what you’re doing now.

This is especially true when your organization has been around a long time or has grown by acquiring other companies. Even if a comprehensive manufacturing or financial system underpins much of your organization, you probably also have a variety of specialized systems supporting individual operations that may need to be handled (i.e., “governed”) differently in order to gain maximum value from improved analytics.

An initial focus on management requirements

Which gets us back to (1) what services does your data analytics program need to provide, and (2) who are the customers for these services?

Answering these questions has implications both for the technology used for data management and for the manner in which you structure and manage the business processes associated with improved analytics.

While I believe you have to do both of these things I’m going to focus here on the second question. I’m fairly “old-school” when it comes to planning and building information systems. That is, first you decide what your requirements are and what services you need to provide, then you decide which technologies you need to adapt, develop, or purchase to help you meet those requirements.

Basic management questions

Here are some questions to ask to help you determine the management requirements for your new data analytics program:

1. Do you need to support users both inside and outside your organization?
2. Do you need to support users with a range of analytical sophistication, i.e., “Help me find and interpret the data!” versus “Just give me the file!”
3. Do you need to manage and potentially standardize data from a variety of sources and formats?
4. Do you need to support both day to day decision-making as well as longer term planning and strategy?

Once you start to answer these, how do you decide on the type of organizational structure and staffing you’ll need? The answer will depend to some extent on the level of maturity or sophistication your organization already has with respect to managing data and making it useful. This involves determining your staff’s basic analytical skills and how comfortable they are with crunching numbers and interpreting the results.

It also involves the possible need to add skills and tools. For example, analyzing and interpreting unstructured data requires a different skill set and tools from “standard” structured or financial data. The same goes if there’s a need to organize and manage real-time or sensor-based data on top of existing service call, customer, or transaction data.

Back office and user facing services

Another important consideration will be the need to balance when the service organization must take the lead on analysis-supporting and infrastructure activities, and when it must respond to requests generated by its target users. These are sometimes referred to as “back office” and “user facing” services.

“Back office” activities might include building and maintaining data and other resources in advance of need. They might include: developing or purchasing a variety of tools that need to be learned and customized; building and updating specialized data warehouses or repositories; and, transforming, formatting, or standardizing data for use in a variety of systems.

How all these processes integrate with your organization’s existing systems and processes – and with the people who manage these processes — must be addressed — and the sooner the better.

Basic service functions

“User facing” services may need to accommodate different types of requests involving:

1. Communicating with various users about their needs.
2. Developing simple (or complex) profiles of these requirements.
3. Deciding what resources will be needed to satisfy the requirements.
4. Managing and tracking the work that needs to be done.
5. Following up when the deliverable is turned over.

As suggested earlier, some users will be satisfied with file downloads, APIs, and well-documented clean data. Others will need more support of a developmental or analytical nature along with consulting or technical assistance.

It is quite possible that the same organization may need to provide both types of services. So, what kind of organizational structure will make sense given a likely diversity of requirements?

Potential organizational models

Several possible models come to mind, each of which might contribute something to your own organization:

1. An IT department that supports various enterprise functions and systems (including the development and/or support for specialized tools).
2. A project management organization (PMO) that provides management and administration support to multiple projects at various points in their life cycles.
3. A customer service or call center that methodically intakes, processes, and satisfies the data analytics needs of a diverse and changing user population.
4. A collaborative and potentially research-oriented organization that actively engages both in data analytics and supports the collaboration and sharing of data with other researchers.

An important question raised by the fourth alternative is the degree to which the data and its analysis will be “open” and shared with other organizations and users.

Are you building a resource that will focus primarily on data and analytics that are primarily to benefit the sponsoring organization? An examples of this might be an analysis operation associated with liability insurance and the services associated with it. Data analytics in such an environment might appropriately be viewed as competitively focused and therefore confidential and not to be shared. Services could be focused on key enterprise decisions and functions such as risk analysis, pricing, product development, and market research, functions that are typically not conducted “out in the open.”

An alternative approach would be represented by NCI’s Genetic Data Commons which, at first glance, looks like a “traditional” open data portal with a search function, file downloads, and APIs. Looking closer, though, you see a complex operation that embeds itself within research processes performed by many different institutions. It provides support for data sharing for cancer research and the people and institutions involved. The goal is to support open research via data sharing, not just journal article publishing.

Conclusion

The point here is that a data analytics organization doesn’t just crunch numbers and build predictive models and visualizations. It’s an opportunity to manage data as a resource in a way that potentially must cross traditional organizational boundaries if it’s to be successful.

As suggested above, there are a variety of models the organization can follow with an initial design being driven by which users and uses cases will be targeted, how much support (and of what kind) will need to be provided, how the data to be analyzed will be gathered and managed, and the extent to which the organization’s processes and deliverables will be open or shared.

Editor’s note: Neo Technology’s Emil Eifrem argues that the increasingly sophisticated techniques used by organized criminals makes them a highly suitable target for graph database supported countermeasures in the fight against fraud. Find them at Neo4J.com -bg

Tahir Lodhi headed up one of the largest credit card fraud schemes ever charged by the US Department of Justice, and in January this year he pleaded guilty to conspiracy to commit bank fraud, admitting how he’d worked with co-conspirators to create thousands of fake identities to gather up tens of thousands of credit cards.

According to court records, Lodi and his confederates fabricated more than 7,000 false identities to obtain tens of thousands of credit cards, running up $200 million in charges. The gang set up 1,800 fake “drop addresses” – ranging from post office boxes to houses – to maintain the web of deception. These addresses were also used to obtain credit card terminals that helped them run up further charges on the fraudulent cards.

In addition, several jewelry stores were in on the scam, using multiple credit card processing accounts to accept large numbers of transactions and splitting the proceeds between the gang members.

Steering clear of false positives

One wonders how this ring operated undetected for such a long time, especially as they were using very common fraud tactics. Initially they used the cards to pay bills, boosting their creditworthiness. Then, after some time, they spent the maximum on all the accounts, did not repay them and disappeared without trace.

This may be a very common pattern, but it is not an easy one to detect using traditional database methods. Standard tools for tackling fraud utilized by banks – such as monitoring for deviation from normal purchasing patterns – involve working with discrete data, rather than examining the bigger network of relationships.

Discrete data may pinpoint sole operators, but it can’t easily find shared characteristics that typify fraud rings. In addition, such methods often turn up false positives, which can be detrimental to customer relationships.

Traditional database approaches are hobbled by the fact that they can only really model data as a set of tables and columns, carrying out complex joins and self-joins when the dataset becomes more inter-related. Such queries are technically difficult to construct and expensive to run. There is also the problem of performance faltering as the total dataset size grows.

The connections involved in fraud rings are always exponentially large (e.g., the Tahir Lodhi case involved 18,000!). Such huge numbers make it very difficult to spot a sophisticated ring instead of a few individual cases of fraud. Plus, if fraud rings are operating cross-borders or continents, as is often the case, they are even more challenging to track.

Stopping the fraudsters connections

Fraud detection applications are not a new concept, but continuously changing techniques used by sophisticated fraud rings are making their detection far more difficult. Gartner cautions “Don’t consider legacy fraud detection technology adequate if the vendor fails to keep up with criminal trends. Replace or complement the technology with solutions from vendors that continue to innovate, which is a necessity when combating rapidly evolving criminal behavior” (See Gartner’s Market Guide for Online Fraud Detection)

This is where the power of the graph database comes in.

Graph databases have been developed to work with data at scale, by manipulating the patterns within it. Graph databases, utilized together with a data query languages like Cypher, provide a simple semantic for detecting fraud rings and navigating the data connections in-memory, even in real time. This makes noticing the connections between fraudsters and their activities far more open to detection.

Unlike most other ways of looking at data, graph databases are designed to exploit relationships in data, which means they can uncover patterns difficult to detect using traditional representations such as tables. Forrester says over a quarter of enterprises will be using such databases by 2017, for instance (see Forrester’s Graph Database market overview).

Graph databases were initially developed in-house by the big social web giants back at the end of the 1990s. Google, for instance, using graphs, exploited the connections in every Web document to rank search results, namely the “Google algorithm.” Now these technologies – that it took these Web giants many engineers-hours to construct – are available to the wider market.

The fight against fraud is ongoing and growing as more financial transactions go online. As fraud operations become more global and sophisticated, those in counter fraud need to use the best technology available to track relationships in data.

Legacy systems to do not have the capabilities to detect fraud in real-time. The way forward is to augment current fraud infrastructures with connected analysis provided by powerful graph databases.

Back in 2014 I published a guest post on the Open Data Institute’s web site titled How important is the quality of open data? Here’s a quote from that piece:

Setting aside for the moment how we define “quality” … database managers have always had to concern themselves with standards, data cleaning, corrections, and manual versus automated approaches to data quality control. In fact, I’m not convinced that “adding” quality control measures throughout the process will significantly add to costs; in fact, adding quality control measures may actually reduce costs, especially when data errors are caught early on.

I was reminded of this while participating  in a recent Data Analytics  session sponsored by DorobekINSIDER: LIVE as similar questions about data quality were raised by session attendees. (Note: when you click the “listen to the archive” link on the DorobekINSIDER LIVE page you need to register to listen to the audio.)

Unfortunately, there’s no simple answer to the question, “How clean does our data have to be to make use of it?” other than, perhaps, “Clean enough to support its intended use.”

If you’re doing exploratory data analysis to help you decide how much data prep might be needed to make your data public, that’s one thing. On the other hand, if you are using your data to calculate input to an invoicing system, or you’re preparing data to distribute publicly for re-use by others, that’s another.

Either way, before you can logically consider what the consequences are of analyzing, interpreting, and using your data, you’ll need to know what data you have and who owns it, both from technical as well as business perspectives. A data inventory should probably be one of the first things you  do when you are considering an upgrade to your organization’s data analytics capabilities. Such an inventory should also include the interdependencies of the various systems involved — and the identities of who controls them.

The question of “where to start” on a data analytics program was another important question raised by the DorobekINSIDER attendees. While I’m all for taking a strategic view when considering how to best organize and manage an organization’s data (for example, such as that promoted by CMMI’s Data Management Maturity Model) it’s also possible that taking too “strategic” a view can lead you down the path of too much analysis in rapidly changing situations, especially if you have to document for the first time the degree to which your various systems and applications depend upon each other for data.

With that in mind here are a few suggestions to ponder when you are considering improvements in how you analyze and use data; note that “data quality” is only one of the many things you need to be considering:

1. Be honest about costs. They’ll bite you if you aren’t.
2. Focus first on solving important problems, not just on “low hanging fruit.”
3. Look first at available data before proposing significant changes to your data management infrastructure.
4. Don’t be surprised if process changes are more complex and time consuming than buying new tools.
5. Know what data you have, who owns it, and who controls it.
6. Identify and engage with the data experts in your organization regardless of where they are organizationally. Encourage them to collaborate if they aren’t doing so already.
7. Engage early and often with senior management, not just with your project’s sponsor.
8. Don’t automatically assume that your IT department is the best place to control your analytics projects, even though they probably know more about project management than anyone else.
9. Deliver useful analytical results early and often even if the underlying data are suspect. Since you’ll need to prioritize data corrections and standardization processes, the more that management understands about what you’re doing, the better.
10. Don’t just recruit and hire data analysts. Also consider upgrading middle and upper management’s analytical skills.
11. Don’t get so caught up in planning exercises that you’re accused of “analysis paralysis.” On the other hand, if you don’t engage in meaningful planning while developing initial deliverables, any early disappointments could stop you in your tracks.
12. Expect the unexpected. If you already knew what analysis of your data will tell you, you wouldn’t need to analyze your data, would you?

Related reading:

• Dashboarding Open Data Program Governance
• Data Cleanup, Big Data, Standards, and Program Transparency
• Data Program Governance and the Success of Shared Digital Services
• Don’t Let Tools Drive Enterprise Data Strategy
• Management Needs Data Literacy To Run Open Data Programs
• Managing Data-Intensive Programs and Projects: Selected Articles
• Open Data and Performance Measurement: Two Sides of the Same Coin
• Problems and Opportunities with Big Data: a Project Management Perspective
• Transparently Speaking, Are Bad Data Better than No Data At All?

“If data analysis is Big Data’s “tip of the spear” when it comes to delivering data-dependent value to customers or clients, we also must address how that spear is shaped, sharpened, aimed, and thrown – and, of course, whether or not it hits its intended target.”

Introduction

In Meeting the Mission of Transportation Safety, Richard McKinney, U.S. Department of Transportation’s CIO, describes four components for what I call an “enterprise data strategy”:

1. Data governance
2. Data sharing
3. Data standards
4. Data analysis

He also mentions additional factors relevant to DOT’s data strategy:

1. The volume of data is increasing and we need to be ready for it.
2. Managing data is not the same as analyzing it.
3. We need to be thinking now about what type of analysis we need to be doing and what resources will be needed to do the analysis.

Based on the 20+ personal, telephone, and email interviews I’ve conducted so far[2] as part of my big data project management research I would add a fourth item to McKinney’s list:

4. We need to spend at least as much time to planning and managing the people and business processes that make data analysis possible as we do the analysis process itself and the technologies that support it.

Tip of the Spear

If data analysis is Big Data’s “tip of the spear” when it comes to delivering data-dependent value to customers or clients, we also must address how that spear is shaped, sharpened, aimed, and thrown – and, of course, whether or not it hits its intended target.

We also want the processes associated with throwing that spear to be both effective and efficient.

Making the data analysis process – the tip of the Big Data spear — effective and efficient is where good project planning and management come in.  Challenges to doing this in connection with data intensive projects are identifiable and include:

1. Siloes. Data are often generated and managed in system- or mission-specific siloes. As a result, creating and implementing an effective enterprise-level data strategy that rises above and encompasses multiple programs, systems, and/or missions requires not just data analysis skills but a mix of technical, organizational, and political skills – not just good “project management.”
2. Sharing. Making data accessible and useful often means that data need to be shared with systems and processes outside the control of those who “own” the data to be analyzed. Key steps in sharing data are that (a) data need to be identified and inventoried, and (b) technical and business ownership of the inventories data must be determined. In many organizations this inventorying is easier said than done and may require both manual and automated approaches to creating the necessary inventories.
3. Standards. Efficient and sustainable analysis of data and metadata may require development or implementation of data standards. Existence and use of such standards differs by industry, data type, and system. The costs for developing and adopting standards to facilitate data sharing and analysis will also vary and may have cost and schedule implications at the project, program, enterprise, and industry or community levels.
4. Delivering value. Modern data analysis tools and techniques provide mechanisms to identify patterns and trends from the increasing volumes of data generated by a steadily widening variety of data capture mechanisms. Challenges in predicting what will be found when data are analyzed places a premium on making sure we are asking the right questions. This in turn impacts our ability to justify project expenditures in advance.

Portfolio Management

Responding to the above challenges requires not only project management skills but also a project planning process that takes into consideration alignment with an organization’s goals and objectives.

As one of my interviewees suggested, the challenge faced in complex “big data” projects has just as much – if not more — to do with overall strategy and “portfolio management” as with how individual projects are planned and managed. Effectively designing and governing a portfolio of projects and processes requires not only an understanding of how the portfolio supports (relates to, is aligned with, interacts with) the organization’s objectives; it should also incorporate a rational process for defining project requirements and then governing how the organization’s resources are managed and applied.

Given how pervasive and fundamental data are to an organization’s operation, skill in data science and analytics is a necessary element but such skill will not be, in many cases, a guarantor of success. Technical and analytical skills must be accompanied by effective planning, oversight, and management in order to ensure that the data analysis “spear” is being thrown in the right direction.

Delivering Value Quickly

Ideally a portfolio of projects will support an organization’s strategic plan and the goals or missions the organization is charged with pursuing. We may also need to “get tactical” by delivering value to the customer or client as quickly as possible, perhaps by focusing on better-controlled and better-understood product centric data early on via a “data lake” approach.

Doing so will be good for the customer and will help create a relationship of trust moving forward. Such a relationship will be needed when complications or uncertainties arise and need to be dealt with.

In organizations that are not historically “data centric” or in organizations where management and staff have a low level of data literacy, an early demonstration of value from data analysis is especially important. An agile approach to project management, accompanied by openness, transparency, and collaboration, will help to accomplish this.

Unfortunately, challenges such as those identified above in many cases cannot be addressed effectively in tactically focused short-term projects given the usual pressures of time and budget. Such challenges can be complex or rooted in how the organization has been traditionally structured and managed.

Still, it’s not unusual for a tactically-focused “sprint” project, even while delivering an effective model or other deliverable, to uncover the need for a more global (or strategic) approach to managing data, metadata, data security, privacy, or data quality.

Balancing Tactics and Strategy

When focusing on delivery of useful data-related deliverables it always pays to keep two questions in mind:

1. What needs to be done immediately to make data useful?
2. What does this tell us about what needs to be done more globally in order to maintain and increase data usefulness?

Attention to enterprise-level data strategy while delivering useful results in the short term has implications beyond what is being attempted in an individual project’s scope. Treating data as an enterprise resource may even require changes to how the enterprise itself is managed. As we all know, it’s not unusual for change to be resisted.

An effective enterprise level data strategy will be one that balances the management of a portfolio of individual data intensive “agile” projects with parallel development of an upgraded enterprise data strategy. Doing one without the other could have negative consequences, for example:

1. Focusing only on a narrowly defined data intensive analytics project by itself may generate immediate value through frequent useful deliverables but may not address underlying technical process issues that impact long-term efficiency and sustainability.
2. Focusing only on an enterprise data strategy without delivering tactical benefits reduces the possibility that that less data-savvy managers understand the “big picture” down the road.

As experienced project managers know, concentrating on “quick and dirty” or “low hanging fruit” when under the gun to deliver value to a client in the short term can generate short term benefits. This same approach, however, may actually increase costs over time if strategic data management issues related to data standards or quality are repeatedly kicked “down the road.” Also, delivering a “strategy” without also engaging users in development of real-world analytical deliverables might mean that strategically important recommendations ends up gathering dust on the shelf somewhere.

Communication Strategy

As experienced project managers understand all too well one of the most important elements in effective project management is communication:

• Communication among project staff
• Communication with the client
• Communication with stakeholders

In the case of the big data or data intensive project, even when focused on delivering incremental value to the customer by focusing initially on specific or narrowly targeted goals, we want communications about project activities, especially among key stakeholders, to focus both on tactical as well as strategic objectives.

This may require accommodating a variety of communication styles as well as different levels of data and analytical literacy especially when both business-focused and technology- or analytics-focused staff are involved. But if we do follow this balanced approach we will:

1. Deliver a useful project.
2. Develop a trusted relationship with the client.
3. Build the foundation for a realistic sustainable enterprise data strategy going forward.

Summary

In summary, how a data-intensive project is planned must take into account both short- and long-term goals. This planning process must be a collaborative one and, even if led by the organization’s IT department – not an unusual situation – it must involve business or operating units right from the start in order to ensure success.

I’ll be turning my attention to this planning process in future posts. If you’re interested in learning more about this process please let me know.

Related reading:

• Big Data Project Management Research Report #1: Setting the Stage
• Big Data Project Management Research Report #2: What’s In & What’s Out?
• Getting Real about Project Management, Collaboration, and Communication
• How I.T. Projects Are Selected Needs To Change, But How?
• Introduction to PLANNING AND MANAGING BIG DATA PROJECTS: SELECTED ARTICLES
• Pixar’s Lessons for Project Communication & Collaboration
• Planning for Big Data: Lessons Learned from Large Energy Utility Projects
• Problems and Opportunities with Big Data: a Project Management Perspective
• Ten Basic Suggestions for Planning and Managing Data Intensive Projects
• Understanding the Challenges of Big Data Project Management: “The Data Must Flow”
• Understanding the Challenges of Big Data Project Management: The Business Case

[1] Copyright (c) 2015 by Dennis D. McDonald, Ph.D. Dennis is an independent Washington DC area management consultant. His services include preproposal research and analysis, proposal development and costing, marketing and sales support, project and program management, project plan development, requirements analysis, and strategic planning. Reach him by phone at 703-402-7382 or by email at ddmcd@outlook.com. An earlier version of this post was published at http://www.ddmcd.com/spear.html and distributed at the Dec. 8, 2015 ATARC Federal Big Data Summit in Washington, DC. 

[2] Thanks are due the following for sharing their thoughts with me: Aldo Bello, Kirk Borne, Clive Boulton, Doug Brockway, Ana Ferreras, Keith Gates, Douglas Glenn, Jennifer Goodwin, Jason Hare, Christina Ho, Randy Howard, Catherine Ives, Ian Kalin, Michael Kaplan, Jim Lola, David McClure, Jim McLennan, Trevor Monroe, Brian Pagels, John Parkinson, Dan Ruggles, Nelson Searles, Sankar Subramanian, and Tom Suder.