Don’t you hate it when the big strategic project you’ve invested time, money, and other resources in ends in failure?
How do you prevent that? You’ve hired the best business intelligence (BI) and analytics leaders, your CEO is invested in the success of your program, and you have the best technology in the market. So isn’t it time to start building requirements?
Not so fast. With failure rates that are often over 50%, it’s clear that the path to success or failure begins well before the project does.
After spending over 20 years in business intelligence and analytics as a buyer, seller, manager, and implementer of solutions, I’ve found three factors that almost all modern data strategy programs have in common.
It’s been my experience that if you consider each of these factors before you begin a project, your chances of success in everything that follows improves significantly. What are these three factors, you ask? Let’s jump in.
Treat data as a utility, not a luxury
I’ve been involved in hundreds of analytics projects over the past couple of decades. Although each project was different, there were many common factors as well.
One of the most common factors: almost everyone treats data as a luxury. Think about other luxuries in your life—jewelry, money, cars. We enjoy those things, but we lock them away so that only approved people can access them.
Sounds like our data, doesn’t it? And we don’t just use security controls to restrict access, we also use skill and position. Do you want to create your own reports? Go to training first. Do you want access to that data set? You’re not approved, you’re not in the right department.
What’s the most precious resource on earth? I’d argue it’s water. Life can’t exist without it. We all need it. We wouldn’t go anywhere without it. Isn’t that how we want our organizations to think of data?
If you truly believe in building a data-driven organization, start thinking of data as a utility, not a luxury. All the other decisions you make about data will be driven by your perspective about how it should be treated. Until everyone in your business takes it for granted and wouldn’t make a decision without it, you won’t really be a data-driven organization.
Bring the data to the people
Once we accept that data should be a utility, not a luxury, we have to think about how to get people access to data. Any future solution should be framed around getting data to people where they are, not getting the people to the data.
Here’s an example: let’s say that you know that your SVP of Sales needs data to determine who her most successful salespeople are.
The traditional way we’d answer this business problem is to determine what solutions best align with your architectural goals. Once implemented, you’d meet with the SVP and ask her to define the metrics that drive her business. You’d then build dashboards and reports that meet those requirements, and train the end users to use the solution. Maybe you’d also assign an analyst to the Sales department for any ad-hoc questions.
This workflow is changing rapidly. Here’s the new way: meet with the SVP, and ask her to define the metrics that drive her business. Make those metrics available in the tools the sales people already use. Why should they leave Salesforce Chatter or Slack to ask questions?
Find solutions that enable users and that get the data to them, don’t require them to learn new tools and processes. It’s the difference between getting your water from the faucet (a utility), or directions to the community well and 5 gallon cans to carry it in (a resource).
Drive from the business
Another common factor to almost every BI project I’ve been involved in is that they’re driven from IT, by requirements. In general, I think we do a good job defining requirements, and building solutions that meet them. We just don’t do it at the right time.
Most technology implementations are driven by IT, and requirements come from overall architectural guidelines first, and the line of business second. We often don’t ask the ultimate end users for requirements until it’s time to produce artifacts—reports and dashboards—from those solutions.
By then, it’s too late. What we can produce is limited by the platform choices we’ve already made. And let’s not even talk about the projects that fail because our BI department spent 6 months implementing the perfect solution while the business moved on and did something else.
Instead, take an iterative approach—small, valuable deliveries to business users. Every component tied to specific business value. Find the most valuable business problem you can. The thing that costs a lot of money. The the third rail that nobody wants to touch. And solve it.
What are your secrets?
What do you think is key to a successful data strategy? Share in the comments below.