You've just stepped into a new role. Maybe you're the new Chief Data Officer, Head of Analytics, or IT Director. You've inherited a data platform that, according to everyone you talk to, "isn't working."
The previous team spent significant money and time building it. Leadership expected transformation. What they got was disappointment.
Now it's your problem.
This guide provides a practical 90-day framework for assessing what you've inherited and deciding what to do about it.
Week 1-2: Listen and Learn
Before making any decisions, understand what you're dealing with.
Talk to stakeholders
Schedule conversations with:
Executive sponsors: What did they expect? What was promised? What would success look like now?
Business users: Who was supposed to use this platform? Do they? Why or why not? What do they use instead?
Technical team: What was built? What works? What doesn't? What would they do differently?
Finance: What was spent? What's the ongoing cost? What was the expected ROI?
Listen for patterns. If everyone tells a different story, that's diagnostic. If everyone agrees on what went wrong, that's useful too.
Review the evidence
Gather documentation (or discover its absence):
- Original business case and requirements
- Architecture and technical documentation
- Current costs (infrastructure, licensing, personnel)
- Usage metrics (if they exist)
- Previous assessments or post-mortems
What you can't find tells you as much as what you can.
Assess technical reality
Work with your technical team (or bring in external help) to understand:
- What infrastructure exists and what state is it in?
- What data sources are connected? Which work reliably?
- What data quality issues exist?
- What's the performance like under real workloads?
- How much technical debt has accumulated?
Don't trust the documentation. Verify.
Week 3-4: Diagnose the Failure
With information gathered, identify what actually went wrong.
Common failure patterns
Technology-led implementation: Platform was chosen for technical reasons before business requirements were clear. The technology works; it just doesn't solve the right problems.
Scope explosion: Started focused, expanded endlessly. Never delivered because the finish line kept moving.
Data quality landmine: Platform was built assuming clean data. Reality was messier. Nobody budgeted for the data quality work required.
Adoption failure: Platform technically works but nobody uses it. Training was insufficient, user experience is poor, or the platform doesn't actually help with real work.
Resource starvation: Project was understaffed, or key people left. Platform was never properly finished or maintained.
Vendor mismatch: Partner or platform wasn't right for the organisation's needs, complexity, or maturity level.
Governance vacuum: No agreed definitions, no data ownership, no quality standards. Everyone created their own version of truth.
Your diagnosis should identify which patterns apply. Usually it's several.
Quantify the situation
Put numbers on it:
- Sunk cost: What was spent to get here?
- Ongoing cost: What's being spent to keep it running?
- Opportunity cost: What's the cost of not having a working platform?
- Recovery cost: What would it take to fix this?
Be honest about sunk costs. Money already spent is gone. The question is whether future spending can generate value.
Week 5-6: Evaluate Options
Based on your diagnosis, consider the realistic paths forward.
Option A: Focused remediation
When it fits:
- Core architecture is sound
- Specific, addressable issues are causing failure
- Business value is achievable with targeted fixes
- Team (or reinforcement) can execute the fixes
Typical scope:
- Fix critical data quality issues
- Complete missing integrations
- Improve user experience and training
- Implement governance that was skipped
- Rebuild trust through quick wins
Investment: $40,000-100,000 over 3-6 months for focused work
Option B: Phased rebuild
When it fits:
- Architecture needs significant changes
- Original scope was wrong; new scope is clearer
- Lessons learned would change fundamental decisions
- Platform can be rebuilt in phases while maintaining current state
Typical scope:
- Preserve what works; replace what doesn't
- Rebuild with smaller initial scope
- Phase delivery to show value incrementally
- Build internal capability alongside delivery
Investment: $60,000-200,000 over 6-12 months depending on scope
Option C: Strategic pause
When it fits:
- Organisation isn't ready for data platform (culture, skills, priorities)
- Business requirements have changed significantly
- Other priorities should take precedence
- Better to wait than to fail again
Typical scope:
- Stabilise current state (stop bleeding)
- Reduce costs to maintenance minimum
- Preserve documentation and learnings
- Plan for future attempt when conditions are right
Investment: Minimal—focus is reducing ongoing costs
Option D: Complete restart
When it fits:
- Current platform is fundamentally wrong
- Technical debt exceeds rebuild cost
- Organisation has budget and appetite for fresh start
- Clear vision exists for what success looks like
Typical scope:
- Decommission existing platform
- Start fresh with different approach
- Apply lessons learned rigorously
- Build modern platform with proven patterns
Investment: $80,000-400,000 depending on scope and complexity
Week 7-8: Build Your Case
You've diagnosed the problem and identified options. Now build the case for your recommended path.
Frame it honestly
Leadership already knows something failed. Don't pretend otherwise. Your credibility comes from honest assessment, not spin.
Include:
- What was spent and why it didn't work (briefly—don't blame-shift)
- Current state and ongoing costs
- Options with realistic investment and outcomes
- Your recommendation and reasoning
Define success clearly
Whatever option you recommend, be specific about what success looks like:
- What will be different in 6 months? 12 months?
- How will you measure progress?
- What are the key milestones?
- What could derail the plan?
Vague promises caused the original failure. Don't repeat them.
Address the trust deficit
Previous failure eroded trust. Your plan needs to rebuild it:
- Smaller initial scope with visible outcomes
- Regular checkpoints where progress is demonstrated
- Clear criteria for go/no-go decisions
- Accountability for delivery
Week 9-12: Execute Quick Wins
While seeking approval for larger changes, execute improvements that don't require major investment.
Stabilise what exists
- Fix critical pipelines that are breaking
- Document what's undocumented
- Clean up obviously wrong data
- Improve monitoring and alerting
Deliver visible value
- Build one report or dashboard that people actually want
- Answer one question that leadership has been asking
- Automate one manual process that's clearly wasteful
- Train one team on how to use what exists
Quick wins build credibility and demonstrate that improvement is possible.
Build relationships
- Identify business allies who want this to work
- Find technical staff who can be champions
- Connect with peers in other organisations facing similar challenges
- Engage vendors or partners constructively
Recovery is a team effort. You can't do it alone.
Common Mistakes in Recovery
Learn from others' recovery failures:
Repeating the original mistakes
If scope explosion killed the project, don't propose an expanded scope for recovery. If lack of governance caused failure, don't skip governance in the recovery plan.
Moving too fast
The urge to show progress quickly can lead to shortcuts that cause new problems. Sustainable recovery takes time.
Ignoring culture
Technology wasn't the only problem. If the organisation doesn't trust data, isn't ready for self-service, or lacks analytical skills, technology alone won't help.
Underinvesting in change management
Failed platforms created cynicism. Recovery requires winning back hearts and minds, not just fixing technology.
Going it alone
You don't have to figure everything out yourself. External perspective can accelerate diagnosis and provide credibility with stakeholders.
When to Get Help
Consider external support when:
- You need objective assessment free from organisational politics
- Technical evaluation requires expertise you don't have in-house
- Leadership needs independent validation of your recommendations
- Implementation requires skills or capacity beyond your team
- You want someone who's seen this before and knows the patterns
External help doesn't mean abdicating responsibility. It means getting the right expertise for specific needs.
Related Reading
- Why Data Platform Projects Fail
- Your Data Warehouse Isn't Working—Here's Why
- Building a Modern Data Platform for Australian Enterprises
- How to Set Your Power BI Team Up for Success
- Self-Service BI: Why It Never Works (Until It Does)
Inherited a struggling data platform? Book a call with our team. We help Australian businesses assess failing data initiatives and develop realistic recovery plans. Honest assessment—we'll tell you if the best option is to stop spending money.
