7 reasons why you need a data project manager

Due to technological progress in the last years, the success of a data project is less likely to hinge on tech, but much more likely to depend on deployment and adoption.

We measure success of a data project in terms of ROI.  ROI happens when people use data to make data driven decisions. Such, we need to make sure not only that we have data, but also that this data is used. In most cases, data availability is not an issue, but even when it is, the reasons are often usage related.

A Data project manager, or data usage ambassador, or data application ambassador, is a person who ensures that there is consistency between data products built by the data team, and data consumption and adoption by the stakeholder teams.

Why do I need a Data project manager?

1. We already solved tech (mostly)

Having been in the data industry for some time, I have been witness to progressive change in our ability to integrate and prepare data. It used to be that most ETL was done with tools, and random snippets of various languages would calculate various reports.

Nowadays it’s easy sailing and clear sky. There’s a decently documented API for everything, often with a Python wrapper. There are managed big data solutions that make data size a challenge of the past for the typical business. There are multiple flavors of open source ETL frameworks and workflow engines that make logging, alerting and dependencies no longer a challenge.

Now we do everything with Python on Docker, and everything is abstracted away, allowing us to focus on the business logic. Connections, credentials, temporary file storage, logging … those used to be managed by hand. All the jobs are idempotent and the code is all deployed and tested with ease in the new CI-CD setup.

Yes, there are still many potholes on our way, and they will probably not go away soon. Of those, I would name test and QA environments.  Currently most companies still struggle due to the complexity of maintaining either an expensive and slow clone, a selective load, or simulated (eg, Postgres to validate redshift code) or all of the above.

2. Using data proficiently is a complex process that requires follow-through.

The reason data usage is a challenge is because it’s a pull process. The team must need to use data in order to be motivated to use it proficiently.

Typically, most departments are too busy working to worry about working better. It takes a significant amount of time (hours) to familiarize yourself with a data model of a business. It takes understanding of how the real process works and at the same time how it maps into data.

This understanding is what makes someone data driven. This understanding takes hours to develop while actively working with the data and analyzing the contents. This cannot be learned in a quick meeting about the state of data or from a dashboard.

Such, it is ideal to have someone available to explain data usage and advocate possible use cases, while being focused on ROI rather than on the analysis itself, keeping implementation simple.

3. Bad usage breaks tech.

Vanity reports. Any report that does not serve the purpose of data driven optimization is out of scope for BI.  However, it doesn’t mean we won’t build them.

When you as a manager check those reports, you get a dopamine hit and it makes you happy, so any yes-men will be quick to provide. Typically these reports are high maintenance due to hardcoding and provide low ROI. But we can’t blame you for asking, since you haven’t been educated on the topic.

Such, a neutral party can often distinguish trash from gold, and take the pressure off the developers.

The requester in this situation is not to blame, because the expectation of seeing a good number raises dopamine and can be addictive. Such, it can easily mislead the brain into thinking it’s doing something useful. Sadly, half the numbers will be below average and will send your dopamine down as well.

The developer just does what the requester asks, without arguing if it makes sense or not, since he often will not have full visibility over usage.

Such, a data project manager must navigate this minefield with care and spare the time of the developers, lest there is nothing left for useful things.

4. Follow-up

Once something is built, feedback is required so further development can happen as soon as possible. Ideally, while the topic is still fresh with the developer. A user who finds the report they asked for to not be useful will often not follow up, or put it off until they reallllly need it (when the boss asks for the numbers). At that point, it will be too late to deliver something good, and the cycle will repeat.

5. Because what you see is all there is. If you don’t know it exists, you cannot imagine using it.

Being data driven means making decisions based on data. It means optimizing business processes and answering business questions. Typically those questions have a lot of hidden complexity, just like a real business.

Mapping that question to data is never a 1:1 process, but rather an approximation that can be calculated with the data you have. For example: How would buying a competitor affect our acquisition? We look at their acquisition channels, we look at the intersection, we look at the impression share for shared ads. But we first need to know these kinds of things exist.

Lack of interest in the topic and expectation that ‘data will build it for you’ is what cost of opportunity is made of.

Such, the best ideas will come from those that are intimately familiar with both the data and the stakeholders, but of those the stakeholders hold the higher complexity.

6. Data doesn’t tell me what to do.

Data tells you where opportunities exist in a process, to give you visibility over mitigating those issues. Data does not tell you how to mitigate them. You can use data to A/B test hypotheses  – but you have to have hypotheses, budget for testing, and cooperation from the teams.

Such, data departments by themselves are limited in scope if not empowered to research. Data is like R&D, not like magic mirror on the wall. It’s the trip, not the ticket.

You need a person to push these agendas along, in order to make progress. Most developers are surprisingly better at software development than they are at stakeholder management, so that’s why you need a people person.

7. Because Ambassador is too esoteric.

We need an ambassador to represent the connection between data availability and correct data usage.

We need an ambassador who must make sure what is built is used, or quickly adapted to fit the needs.

We need an ambassador that aligns management KPIs with process KPIs to give teams clear steering through numbers.

We need an ambassador to explain the importance of dimensional questions to identify issues, ownership over KPI to create hypotheses, and data for A/B testing.

Finally, we need those ambassadors to exist. Luckily they already do, in the form of a project manager. Let’s just slap Data on there and welcome them among our data crews. They will be invaluable to the company by optimizing the ROI on data itself.

Leave a Reply

Your email address will not be published. Required fields are marked *