Stop buying platforms without a plan
Intro
If you work in technology leadership in WA, you have probably seen this play out. A vendor demo dazzles the executive team. The board wants dashboards yesterday. Procurement spins up a licence for Fabric, a lakehouse on Databricks, or an enterprise rollout of Snowflake. The project gets a name, a logo, and a steering committee. Six months later, you are still arguing about definitions, the cost line has crept north, and the business has lost interest.
Buying modern data platforms before you have a strategy is like building a new mine site without a plan for roads, water, or people. The equipment might be world class, but nothing moves. The result is predictable. Fragmented data. Conflicting KPIs. Shadow models built in spreadsheets. Shelfware that quietly renews every year. And teams who stop believing the next tool will fix anything.
Here is the hard truth. Technology is an accelerator. If your direction is unclear, accelerators help you get lost faster. A clear data strategy sets the destination and the rules of the road. With that foundation, tools like Microsoft Fabric, Databricks, and Snowflake become what they should be. Enablers of business outcomes that matter.
This article makes the case for strategy first. It unpacks the pitfalls of tool first thinking, defines what a practical data strategy should include, and offers a simple checklist you can use before you approve the next licence or cloud service.
Why tools alone do not solve data problems
Tools are necessary. They are not sufficient. A great platform gives your teams capability. It does not decide what problems to solve, how to measure value, or who is accountable when things stall. When organisations treat the platform as the solution, a few patterns show up.
Cost blowouts. Consumption based services increase quietly. Sandboxes multiply. Nothing gets turned off. Surprise invoices arrive at quarter end.
Shelfware. Licences are bought for everyone to avoid arguments. Adoption never reaches the threshold to justify the spend.
Shadow IT. Citizen teams move faster than central data groups. Models spread in OneDrive and personal workspaces. Security is inconsistent. Trust erodes.
Misaligned priorities. The programme funds pipelines and curated layers, but the business needed a reconciled view of revenue by product. Delivery looks busy without moving the dial.
The common thread is absence of intent. Without a strategy, the organisation cannot answer basic questions.
What are the top three decisions we want to improve using data this year
Which metrics define success and how will we calculate them
What is the order of work to achieve those outcomes with the least waste
Who owns the data, the processes, and the risks
A platform cannot answer those for you. It also cannot fix organisational constraints such as unclear accountability, fragmented budgeting, or low data literacy. In those environments new tools often magnify the pain.
What a data strategy should cover
A useful data strategy is short, practical, and connected to business intent. It avoids slogans and sets out a sequence of decisions. At minimum, it should cover three areas.
Align with business objectives
The strategy starts with the organisation plan. If you are in mining, the priorities might be safety, ore recovery, and cost per tonne. In healthcare, it might be elective surgery wait times and community access. In government, it might be transparency and service delivery speed.
Translate those goals into questions and metrics.
Which decisions have the highest upside if we improve accuracy or speed
What are the critical measures for those decisions and how do we define them
Which data sources are essential and which are nice to have
How will we know the initiative worked within a quarter, not a year
Then map data initiatives to these goals. For example.
Reduce unplanned equipment downtime by improving predictive maintenance models for haul trucks at Pilbara sites. Measure mean time between failures and parts inventory turns.
Improve theatre utilisation and discharge planning to cut elective surgery wait times at Perth metro hospitals. Measure average length of stay and re admission rates.
Provide a single view of customer interactions across licensing systems to speed up approvals in a state agency. Measure end to end processing time and satisfaction scores.
Note that none of these talk about tools. They describe outcomes and how to tell if the work is helping.
Define governance and ownership
Governance is not a report that lives on SharePoint. It is a set of habits embedded in delivery. Clear roles stop projects drifting and make risk manageable.
Set up simple ownership rules.
Data domain owners. Accountable for data quality, definitions, and access approvals within their domain such as operations, finance, or clinical.
Product owners. Accountable for the value case and roadmap of a data product such as production yield, workforce analytics, or case management views.
Platform owners. Accountable for the underlying services such as Fabric workspaces, Databricks clusters, and Snowflake accounts.
Governance council. Makes cross domain decisions, handles conflicts, and signs off standards.
Then define a small set of working standards that stick.
Naming conventions and semantic layer rules so everyone calculates the same KPI the same way.
Access patterns based on sensitivity and role. For WA Government this often aligns with existing information classification schemes.
Data quality thresholds and how they are monitored.
Change management for data products so the business knows what changed and why.
Keep it light. The goal is decisions that help work ship faster and safer, not a library of PDFs.
Establish maturity milestones
A strategy without a path to capability is just a wish list. Your roadmap should build skills and value together. Plan for shorter cycles with clear benefits.
A simple three stage model works well.
Prove value. Pick one high value use case in a single domain. Deliver a basic version quickly. Avoid enterprise wide ambitions at this stage. Build trust by solving a real problem.
Expand capability. Formalise data product ownership, add a semantic layer, and standardise a handful of patterns for ingestion, transformation, and testing. Start enabling power users with structured training.
Scale responsibly. Introduce shared services such as data catalogue, lineage, and cost monitoring. Expand to adjacent domains. Tighten governance where needed. Continue to retire low value work.
Each stage has exit criteria. For example, you might require two consecutive quarters of adoption growth and a documented reduction in manual reporting effort before expanding to a new domain.
The payoff of strategy first
When you anchor to strategy before buying or expanding tools, you see three benefits.
Faster ROI
Value shows up sooner when you commit to a small number of outcomes, define how to measure success, and cut work that does not help. Teams stop building foundation pieces that may never be used. Instead, they build only what is required to deliver the next outcome, then iterate.
Time to first value matters for executive support. When the CFO can point to reduced manual effort or better inventory turns in a quarter, future funding conversations are easier.
Reduced risk
Strategy first does not eliminate risk. It makes risk visible and manageable.
Cost risk is reduced because spend is tied to specific outcomes and phases. You turn off experiments that do not work.
Security risk decreases because access patterns and responsibilities are clear.
Delivery risk reduces because product ownership and roadmaps allow better sequencing and expectation management.
Stronger adoption and cultural buy in
People use what they trust and what helps them do their job. Clear definitions, consistent access, and visible ownership build trust. When teams help shape the roadmap and see quick wins, they invest their attention. That is when self service becomes a strength instead of a headache.
Questions to ask before you buy
Use this checklist in steering committees or procurement meetings. If you cannot answer these, hold the purchase.
What are the one or two business outcomes this spend will improve in the next two quarters
Which decisions will be faster or more accurate because of this work
How will we measure success and when will we review it
Who owns the data domain, the product, and the platform settings
What is the minimum capability we need to deliver the next outcome and nothing more
How will we control access and ensure privacy for sensitive data
What are our data quality thresholds and how will we monitor them
What training will the target users receive and when
Where can we turn something off or stop doing low value work as this goes live
What must be true to expand this beyond the first domain
A simple framework you can adopt
The following framework keeps delivery honest and aligned with value.
1. Anchor outcomes
Agree the top three outcomes with the executive. Put them on a page. Include the metrics that prove success. Revisit monthly.
2. Assign ownership
Nominate domain owners and product owners. Give them time and decision rights. Confirm the platform owner has the authority to enforce tenant level standards.
3. Standardise the essentials
Set a small number of standards that all teams follow. Naming conventions. Security patterns. Testing approaches for data pipelines. Communication of changes.
4. Deliver in quarters
Plan in quarterly increments. Each quarter should finish with a valuable outcome used by real teams. Treat everything else as optional.
5. Build capability with intent
Train users closest to the work first. Use short, hands on sessions with real data. Avoid broad awareness campaigns until there is something worth using.
6. Monitor and adapt
Publish adoption, data quality, and cost metrics. Talk about them in the open. Use them to decide what to stop, start, or continue.
Practical guidance for common tool choices
CIOs in WA often juggle the trio of Fabric, Databricks, and Snowflake. Each can be valuable in the right context. Strategy first thinking helps you avoid common mistakes.
Microsoft Fabric
Fabric is attractive because it brings storage, engineering, and analytics into a single SaaS experience. Start small. Use a single workspace tied to a defined outcome. Lock down tenant settings to avoid a sprawl of personal workspaces. Establish your semantic layer rules early so reporting products share consistent definitions.
Databricks
A strong choice when you have data science workloads or a need for scalable processing. Resist the urge to boil the ocean. Focus on one domain where advanced analytics matters, such as predictive maintenance in mining. Agree how models will be promoted and monitored. Plan for handover to operational teams before you build complex pipelines.
Snowflake
Snowflake is compelling for scalable storage and cross organisational data sharing. Avoid treating it as a dumping ground. Start with one curated dataset tied to a business outcome. Define ownership at the account and schema level. Pay attention to cost monitoring early to prevent uncontrolled growth. Align your access model with organisational privacy obligations.
Across all three, apply the same questions. What problem are we solving now. Who owns it. How will we know it worked. What will we stop doing as a result.
Putting it together
Here is a short scenario to illustrate how these pieces connect in practice.
Outcome anchor
Reduce unplanned downtime for haul trucks at three Pilbara sites. Target a five percent improvement in mean time between failures within two quarters.
Ownership
Operations is the data domain owner. Maintenance analytics leads the product. Platform team manages Fabric tenant, Databricks clusters, and Snowflake accounts.
Standards
Common asset hierarchy and event definitions. Access model that separates operational from sensitive data. Pipeline testing approach with a minimum set of checks.
Quarterly delivery plan
Quarter one. Ingest maintenance logs and telemetry for target fleets. Define failure events. Build a minimal model to predict failure risk. Create a reporting view for maintenance planners.
Quarter two. Integrate parts inventory and work order history. Tune the model. Add a weekly dashboard that shows predicted failures and parts availability. Begin decommissioning the old spreadsheet workflow.
Capability
Train maintenance planners on the new reports. Provide short refreshers during shift handover. Share adoption and model performance metrics in site stand ups.
Adaptation
If results are not moving, pause feature building and review data quality. If adoption is low, talk to planners and remove steps. Decide whether to expand after two quarters based on real gains.
The same thinking applies for healthcare wait times or government approvals. The tools are not the hard part. Deciding what outcomes matter, who owns what, and how you will learn quickly is the work.
Conclusion
Modern data platforms are powerful. Without a strategy, they create motion without progress. Strategy first means you pick the right battles, in the right order, with the right owners. You measure value early and often. You build only what you need for the next step. And you earn the right to expand.
If you take one thing from this article, make it this. Pause before you approve the next tool or the next expansion tier. Ask the questions in the checklist. Align to outcomes. Start small. Build capability deliberately.
Ready to get your strategy right before buying tools. Book a discovery call.