It finally happened. Someone gave you money for your own analytics or data warehouse project. You’ve got enough visibility (and enthusiasm) that you think you can make a difference.
Whether you’ve done this before or are new to the experience, you’re looking forward to finally solving your business’s top challenges.
We’ve been consulting with data project sponsors for 20 years, so we’ve seen what makes a data project work, as well as everything that can go sideways. Unfortunately, problems are inevitable, but if you are aware of them, you can also work to mitigate them.
So before you get started, here are three essential things to know.
Expect to find data problems
When looking at data closely for the first time, you will discover configuration errors with software. Software teams may interpret this as blame. This fear can become acute when badly-handled data limits the scope of a CEO’s pet project.
Expect to find problems with your data sources, and actively look for them.
It shouldn’t surprise you to find them either. Your analytics project will enable new levels of precision in reporting, and most software teams don’t have the data expertise your team will need. In other words, you should expect to find data problems your software teams can’t. A successful analytics project should solve data problems you don’t even know you have.
The discovery of these mistakes might cause conflict. Other teams could feel threatened. You should manage the conversation with maturity and find the best-available business solutions.
Software teams should see you as an ally in the production of good data.
It’s still best to prepare for possible conflict, and the surest preparation is visibility. Establish trust in your team by collaborating on your plans and publishing your data quality metrics. Make it clear you’re listening to your data suppliers on the software teams, and integrating the data they collect in good faith.
There will be tradeoffs you weren’t expecting to make
While you might unintentionally make enemies, you will also discover allies.
The data access problems you’re trying to solve aren’t unique to you. Other people in your organisation need your data too. They also need the reliability you bring to the table, and are willing to help in exchange. But that means tradeoffs you weren’t expecting to make.
You may be able to take advantage of an ally’s high-profile data scientists by giving them access to your data. Your ally will inevitably need more than you’ve got. But if you make sharing resources productive for both of you, you’ve started something good.
In the short term, lots of expectant allies can look like too much demand. When word gets out that you’re building a data warehouse, everyone in the company will come to you, from the CEO to the people answering the phones. All of those competing demands have a way of clogging up your funnel and making your team nervous.
We think allies are integral to building your information supply chain. They want to add value, whether as informed customers of your data or contributors of business logic. At the very least, you can listen to allies and look for opportunities to help them execute their plans with the data you’ve got.
You should try for a “yes, and …” approach instead of “either-or.” This will help make it easier to identify synergies. The data you need is useful to more than one team. They’re counting on you to get it to them.
Embrace the potential of a pivot
When you’ve accounted for bad data and expectant allies, what you deliver depends on what you actually have.
However, you don’t yet know what you have.
Your original dashboard might have needed to connect millions of service calls to their orders, but only 5% of the calls have that capability. Or you need to assess delivery times on orders, but your e-commerce system doesn’t track actual delivery, just estimates. These seemingly catastrophic discoveries happen all the time. Expect them in the data world.
For these projects, you’re the Chief Data Product Officer of your very own data product startup. The data warehouse is your factory. Your project starts with three things everyone needs:
1. A reason to build reports
2. Some funding
3. Your willpower
Many product companies start with far less.
In the case of your particular data product startup, the demand your allies pass to you has to be matched with the raw materials collected by upstream software. Sometimes the software doesn’t collect the data everyone knows you need. That means you will have to pivot, likely more than once. You also need to be able to pivot expectations on the data products you can deliver.
This is where a “yes, and …” approach pays dividends. All of the business processes in your company rely more or less on the same basic data sets, spread across the enterprise. The more internal business needs you to understand and the more data you’ve got access to, the more options you have to pivot to.
If you can deliver for your allies, provide regular data quality reporting, and keep an open mind to possibilities, your analytics project will be more likely to succeed.
