Technology projects, regardless of type all share one common trap. It’s a trap that we all try and avoid, but one that we tend to fall into more often than we should. I call it ‘kitchen sink’ syndrome and data projects are by no means immune to this.
The story has been told many times. We start to build a data strategy and reach out to stakeholders. We ask them which data would make their lives easier and how should we present it. We’re excited, keen to get the project started, but they come back with a huge shopping list of metrics that they ‘absolutely need’ – without these the project will surely be considered a failure.
Our heart sinks a little bit, this could be a long project, and it all feels a bit insurmountable.
The truth of course is that not all of this is needed, at least not at the outset. Regardless of job role, most of our decisions are driven by a handful of key metrics. Sales teams care about conversions, marketing teams care about CAC and LTV, operations teams are focused on project outcomes, and senior management on revenue and market share. Sure, I’m simplifying here and there are others (particularly in specific settings), but the point is that our job is not to deliver every possible metric presented in every possible way.
What’s behind this trap?
Before we can address how to handle this situation, it’s worth taking a minute to note why it occurs. As humans we’re often more fearful of losing something than we are motivated to gain something – it’s just seems to be something that’s hardwired into our brains.
At the same time, many stakeholders will implicitly assume that they get one and only one chance to shape a project. From their perspective, best to get everything on the table now and make sure I’m not short-changed in this project!
So how do you address this?
Avoiding this trap sounds complex, but there are three key principles that can help if they are adopted and effectively communicated with stakeholders:
This is not a ‘big bang’ project:
A data project is not well suited to a ‘big bang’ approach, where one day you turn on the data warehouse and immediately stop using every other reporting tool (e.g. those prized Excel files). It’s an incremental roll-out, which will be supported by existing reporting tools until the time comes to fully transition.
It’s an iterative process:
A data project is not linear by nature. You don’t start, build and then finish. It’s an iterative cycle of developing, getting feedback and improving. Stakeholders can rest assured that they’re not going to ‘miss the bus’, as they’ll have ample opportunity to feedback and shape the project as it progresses.
Identify and validate the most important metrics:
It’s common sense to start a project with the metrics that add the most value and ‘move the needle’ for the company. What’s often missed is the process of validating why these are important in the first place, as it’s often too easy to take stakeholders on face value (after all they’re the experts).
But the smarter thing to do is to drill down deeper, ask why metrics are important, what do they enable the stakeholder to do, and what does that mean for the business? The smartest thing to do is to agree a scoring system before the project commences that everyone can buy in to (which also doubles up as a roadmap for the long-term project).
Wrapping Up
I’m smiling as I re-read the text above and write this concluding paragraph, as I’ve made it sound so easy. Of course, in practice it is often more nuanced than this, or else far fewer people would fall into the trap! The most important piece of advice I can give here is to set out the stall early by adopting and communicating the principles above. Trying to change course part way through a project is a lot harder – as expectations are easier to set than change.
