Functionality does not equal data.

Dear Project Manager,

I am contacting you as there's something important I need to share. Not only that, I would like us to work together to share this with others. This something is: Functionality does not equal data.

Let me explain.

When we do IT projects, we concentrate on an element of functionality. Examples may be the customer interface, the mobile application, or the stock ordering system. We concentrate on a “thing” (piece of code, application, vendor product) that "does something".

This applies whether we are waterfalling, going agile or dev-opping.

With this way of looking at the world the project deliverable is a discrete segment of functionality. Yes, it may plug in upstream and downstream, but basically it’s a stand-alone bit of kit that does something. Once you have your requirements you can set the developers going and Bob’s your interface, mobile app, or stock order.

The trouble is many projects use the same way of looking at the world to consider data. These projects only consider data created by – or flowing through – their discrete functionality. This doesn’t quite work, because the particular project functionality is only a small segment of all events that will occur to the data during its lifecycle.

Let's use an analogy. Let’s equate our project to, say, building a new valve in a water pipeline. The valve represents our element of functionality. It does something. And after it is built you, as a project manager, can look on a valve well built, and say that the functionality to stop (or start) the flow of water has been achieved.

However if we are looking at the medium that is controlled, it doesn’t just sit inside the specific functionality. Data, for example, flows from the first customer touch point all the way to the board reports and the regulator. It’s moving all the time, and changing all the time. The data reaching the end user is the cumulative product of all events that occurred over its journey.

If a project does not think about data then great harm can occur. The valve may do the job of stopping the water, but it also might introduce impurities (e.g. oil). Functionality is achieved, but the water is polluted for everyone downstream. Quality is impaired. Every project should ensure that it cares for the data flowing through it. The mantra should be “do no harm”.

So we need to change our viewpoint – or more accurately incorporate the viewpoint that sees the project functionality as a small valve in a great system, that takes data from the start of it's journey to the end.

I know you are understandably project focused, but we should not ignore data because it is not “functionality”.

In short, we need to think about the information as well as the technology.

I know you are an enlightened Project Manager, so I know you know this. But there are lots of people in the world who miss this fundamental point. Let’s see if we can educate them. I’ll help.

Kind regards

A Data Practitioner.

John Parkinson

Author, The Data Quality Blueprint, A Comprehensive Step by Step Guide to an Effective and Long Lasting Enterprise Wide Data Quality Solution.

Thank you for reading: Below are listed some other recent articles I have written that you may be interested in.

Data on the Menu: Explaining Data Disciplines

What is Data Architecture

Explaining the Data Strategy: Information Principles

Ten steps to information requirements

Where does the data strategy fit in?

Getting Engagement with the Data Strategy

Explaining the data strategy

Projects: Solving the Data Problem

BCBS239 and the Information Management Strategy of the Future

External Audit: How can data governance help?

Success Stories: User Stories and Data Governance

Corporate Governance and Data Governance: Are you in control?

How to Manage Third Party Data #2 Responsibilities of the receiver

How to Manage Third Party Data #1 Responsibilities of the supplier

The Principles for Data Quality Remediation

The Rise and Rise of Reference Data Utilities

Data Governance and the Three Lines of Defence

How has Data Governance changed as a result of increasing regulatory requirements and the need for greater transparency?

Rise of the Machines. How Machine Learning and Artificial Intelligence can change how we approach data quality.

Understanding the misunderstood. What actually is Data Governance?

From Corporate Information Factory to Corporate Information Assembly. How will Information-as-a-Service change data governance?

Data Governance & Communications. Alignment of people throughout the enterprise.

Avoiding the Data Swamp. How do we govern big data?

What is the Data Management strategy of the future? How will organisations balance Information Integration, Information Creation & Information Legacy?