KPI Dashboard – what to understand before you commit.
You asked me to review Toby's KPI Dashboard Project Plan and give you an honest, independent view – what looks right, what's missing, and what questions are worth asking before the next phase is approved.
First thing worth saying: this is a genuinely impressive piece of work. It's detailed, technically rigorous, and shows a solid grasp of how these projects actually succeed or fail. Toby has done the hard thinking on data architecture, source readiness, risk, and staging – that's not easy to produce, and it's far better than most consultants deliver at this stage. The effort is real and it shows.
What follows isn't a critique. It's a set of questions designed to sharpen what's already here and make sure you go into the next phase with full clarity. Work through them with Toby and Jordan – if either can't answer something clearly, that's useful information in itself.
Before anything else, it's worth being clear on what a KPI dashboard is and what it should do for your business – because the plan as written jumps quickly into technical detail without properly answering this question first.
The plan is built around the data you have. It should be built around the decisions you need to make.
A good KPI dashboard exists for one reason: to help you and your team make better decisions, faster. Which jobs should we take on? Are we pricing correctly? Is a branch underperforming or just having a slow month? Do we have the capacity to commit to new work?
The current plan starts by asking "what data do we have and how do we connect it?" It should start by asking "what decisions does Ricky need to make each week, and what information would make those decisions easier?" The data work follows that question – not the other way around.
This isn't a fatal flaw in what Toby has produced. But it does mean the first thing worth doing, before any technical work begins, is sitting down and listing the ten decisions you make most often as a business owner. That list becomes the foundation the dashboard is built on.
This is a substantial, well-structured document that goes well beyond a surface-level plan. The depth of thinking on data architecture, source readiness and risk staging is genuinely impressive. Here's what stands out.
Work through these with Toby and Jordan. Some are strategic, some practical, a few are commercial. All of them matter before any build is approved. Tap any question to see why it matters and the exact wording worth using.
Before the KPI list is finalised, it's worth mapping each metric back to a specific decision you need to make. If a KPI doesn't help you make a decision, consider whether it belongs on the dashboard at all. This exercise takes an hour and will make everything that follows sharper.
"Before we finalise the KPI list, can we spend an hour mapping each metric back to a specific decision I need to make? I want to build a dashboard that helps me run the business – not just one that shows me data."
Toby has clearly mapped out the different dashboard audiences – you as MD, senior managers, the operations team, sales and estimating, finance, HR/WHS, and a data quality view for maintainers. That structure is sound. The open question is whether each of those departments has actually been consulted on what they need to see, or whether the plan is working from assumptions. Department-level views are deliberately deferred until after the executive dashboard is proven, which is the right call – but it's worth confirming that the relevant people are aware of that sequencing and bought in.
"For each department view in the plan – have those teams been consulted on what they actually need to see, or is that still to come? And are they aware their dashboards come in a later phase?"
Toby has done solid work here. The plan identifies a clear first-build candidate list across executive health, operations, sales, finance and HR/WHS – with a readiness classification for each area showing what's source-ready, what needs staging, and what to defer. That framework is genuinely useful. What's still needed before build approval is the next layer of detail: a plain-English definition for each included KPI, the exact formula, the agreed source, and any exclusions or caveats. Things like "commercial conversion rate" and "labour margin" mean different things depending on how you calculate them today – those definitions need to be locked before a developer starts building.
"Before we approve the build scope, can we produce a one-page KPI definition sheet – plain-English meaning, formula, source system, and any known caveats for each included metric?"
It's worth seeing a wireframe or design mockup – even a rough one – as a required sign-off step before any development begins. A significant investment deserves a clear visual of what you're actually getting. If it looks wrong on paper, it'll look wrong when it's built.
"Before we approve the build, can we see a visual design of what the dashboard will look like – screen by screen?"
There's a meaningful difference between a dashboard that shows you a number and one that lets you ask "why?" – clicking into gross margin to see which branch is pulling it down, or filtering by job type or period. The plan doesn't make this clear. It's also worth asking about AI-assisted analysis on top of the data, which could surface insights automatically rather than waiting for someone to notice a trend.
"What level of interactivity are we building? Can I click into a number to understand what's behind it? Is there any consideration of AI-assisted analysis on top of the data?"
The plan connects your systems to a dashboard. But if you're going to do the hard work of cleaning and connecting data, it's worth storing it properly in a central place – not just piping it straight to a screen. A central data layer means you could use the same data for AI analysis, reporting, automations, or future platforms without starting from scratch each time. The plan doesn't address this.
"Is the data we're connecting going into a central store we own and can build on – or is it being piped directly to a dashboard and only usable there?"
Jordan's technical response is reassuring on the Calendar. He's confirmed it stores almost everything needed for operational reporting, that it's highly reliable with no material outages on record, and that his preferred extraction pathway is direct database access or reporting views rather than building a new API – which is exactly the right call for a project of this size. MYOB and Pipedrive are also confirmed as clean first-stage sources that work well together. The one question still worth sitting with: rather than building a separate dashboard that pulls data from the Calendar, is there a case for building the dashboard view directly inside the existing portal? That would mean one system for Jordan to maintain rather than two staying in sync as the business evolves.
"Given Jordan's preferred pathway is direct database access anyway, is there a case for housing the dashboard inside the existing portal rather than as a separate system? What are the trade-offs?"
The plan describes the technical architecture in a lot of words. A single visual – showing which systems feed into the dashboard and how – would be far more useful. You should be able to look at one diagram and understand the whole picture. Interestingly, the earlier draft of the plan had this diagram. The final version removed it.
"Can you give me a simple one-page diagram showing how each system connects – what feeds into what, and where the data ends up?"
The plan lands on two platform options: extend the existing custom portal, or build a Power BI layer. Jordan has been pretty clear that Power BI is a risk – he can't support it at pace, and every time the underlying data changes, there's a real chance things break in ways he can't fix quickly. The custom portal keeps everything in Jordan's hands, which is good for speed, but creates longer-term dependency on one person. What the plan doesn't explore is whether there's a middle ground – tools designed to sit directly on top of a clean database and produce proper BI dashboards without the complexity of Power BI or the single-developer risk of a fully custom build. Tools like Metabase, Retool, or Apache Superset are worth a conversation. They're maintainable by someone with Jordan's skill set, they connect directly to database views, and they'd give you real dashboard capability without locking into a platform Jordan can't support or a fully bespoke build that only one person understands.
"Before locking in the platform, have you looked at tools like Metabase, Retool or Superset? They sit directly on top of a database, Jordan could maintain them, and they might give us a better balance between proper dashboard capability and long-term supportability than either Power BI or a fully custom build."
The plan refers throughout to a "consultant/dashboard builder" as a separate role from both Toby and Jordan. That implies a third person – but they're never named, and it's not clear whether their cost is inside the $20k–$45k estimate or additional to it. It's worth getting clear on exactly who is doing what and what each person costs.
"Who is the dashboard builder referenced in the cost estimate – is that you, Jordan, or someone else? Can you give me a breakdown of who does what and what each person's time costs?"
$20k to $45k is a wide range – more than double at the top end. For a project of this size, a tighter estimate before committing would be prudent. Beyond the build cost, there will also be ongoing expenses: platform licensing, hosting, third-party tools. These aren't clearly itemised anywhere in the plan.
"Once the technical validation is done, can I get a firmer cost range for the build? And separately – what will this cost to run per month once it's built, including any software or hosting fees?"
The plan assigns you as the decision-maker and approval authority, but doesn't quantify what that means in practice. Walkthroughs, validation sessions, testing, reviewing outputs – this will take real time from you and your team. Understanding that commitment upfront is worthwhile.
"What's the realistic time commitment from me and my team during the build – per week, and for how long? What do you need from us and when?"
Building the dashboard is one thing. Making sure the numbers it shows match reality is another. There should be a defined period after the build where outputs are checked against your existing reports – and if something doesn't line up, it gets fixed as part of the original scope, not charged as extra work.
"What's the testing and sign-off process after the build? Is there a warranty period where errors get fixed at no additional cost?"
Once the dashboard is part of how the business runs, downtime has a real cost. Jordan is a one-person operation – which is fine, but it's worth understanding: if the dashboard goes down on a Monday morning, what's the expected response time? Is there a backup plan? Who do you contact? None of this is addressed in the plan.
"What are the support arrangements once this is live? If something breaks, what's the expected response time – and what's the plan if you're unavailable?"
Your software stack will change over time. MYOB gets updated. Pipedrive fields get renamed. The Calendar evolves. Each time something changes in a source system, there's a risk it affects the dashboard. Someone needs to own that – not informally, but as a defined responsibility with a clear process. The plan doesn't name that person.
"Who owns the integrations between systems once this is live? If one of our source systems changes, what's the process for making sure the dashboard still works?"
The dashboard you're building now is a display of data. The natural next step – which is coming regardless – is AI that analyses that data and surfaces insights automatically. If the infrastructure is built correctly now, adding that capability later is straightforward. If it's not, you'll be paying to rebuild. Worth asking about now, even if it's not part of the immediate scope.
"Is the way we're structuring the data compatible with adding AI analysis on top of it in the future? What would we need in place now to make that easier later?"
Before you approve the next phase, it's worth being clear on how you want to resource and govern this project – not just who does the work, but who owns what, where the IP lives, and what you're committing to long-term. There's no single right answer here. These are genuine trade-offs and the right model depends on what matters most to Thomas Scaffolding.
First, a quick read on the two people already in the picture.
Continue with Toby as the project lead and planner, with Jordan handling the technical build. You provide oversight and approvals at key decision gates.
- Toby's availability remains consistent through the build phase
- Jordan has enough bandwidth alongside his other work for Thomas Scaffolding
- You're comfortable with decisions being made between two independent contractors without a clear escalation point
- No single accountable owner if something goes wrong or the two disagree
- IP and institutional knowledge sitting with contractors, not internally
- Scope creep risk if there's no independent check on what's being built and why
Hire an internal resource – a digital operations manager, a junior developer, or a data analyst – who owns the day-to-day relationship with Jordan and Toby, manages the project internally, and starts building institutional knowledge inside the business.
- You can find the right person at the right seniority – someone technical enough to ask the right questions without needing to build everything themselves
- The role has scope beyond this project – data, systems, reporting across the business
- You want IP and knowledge held internally long-term
- Higher upfront cost – salary, onboarding, ramp-up time
- Risk of hiring too junior and having them blocked by Toby or Jordan's technical depth
- You still need external expertise for the strategy and specialist build components
Engage a BI or data specialist – a local boutique, an IT partner, or a senior freelancer with specific dashboard and data architecture experience – to own the build phase alongside Jordan. Toby stays in a planning and QA role, but the technical execution has a specialist behind it.
- You want proper BI expertise on the dashboard layer without hiring full-time
- The specialist can work with Jordan's database environment rather than around it
- It's a time-bounded engagement with a clear handover
- Adding a third contractor increases coordination overhead and cost
- IP still sits externally unless there's a clear handover plan
- Quality varies enormously – seniority and fit matter more than cost here
Use an offshore developer or a junior local resource to handle execution under Jordan's technical direction. Toby or an internal person manages the project, Jordan provides architecture oversight, and the offshore resource does the build work.
- The scope is well-defined and the build is repeatable – clear inputs, clear outputs
- Jordan has capacity to review and direct the work properly
- The budget is constrained and the risk tolerance is reasonable
- This project has enough complexity and ambiguity that under-resourced execution is a real risk
- Jordan's time gets consumed directing rather than building, which may not be efficient
- Lower cost upfront often means higher cost to fix later
Whichever model you choose, it's worth being deliberate about where the knowledge lives. Right now, a significant amount of how Thomas Scaffolding's systems work sits in Jordan's head. As you add a dashboard layer and more integrations, that concentration of knowledge either gets worse or gets better – depending on how you structure the engagement.
The questions worth asking before you commit to any model: Is the code documented? Who can maintain it if Jordan isn't available? Are the KPI definitions and business logic written down somewhere you own? Can someone else pick this up in twelve months without starting from scratch?
The answers don't have to be perfect on day one. But they should be part of the plan.
A suggested structure for the next phase
Given where this project sits right now – post-discovery, pre-build, with real technical complexity ahead – a practical starting point would look something like this: