Insights on public sector analytics

The failure is almost never the technology

It's tempting to blame the tool — Power BI, Tableau, whatever was chosen. But after delivering analytics platforms across BC's health authorities, justice sector, and government ministries, I've never seen a project fail because Power BI wasn't capable enough. The failures are almost always human, structural, or architectural.

Failure mode 1: They built what they could measure, not what decisions needed to be made

The most common failure: starting with the data you have instead of the decisions you need to make. A report full of numbers is not a decision tool. A report that tells a specific person — a charge nurse, a deputy minister, a caseworker — whether to act right now is a decision tool.

When I start a new engagement, the first question I ask stakeholders is not "what data do you have?" It's "what's the last decision you made that you wish you'd had better information for?" The answer tells me everything I need to know about what to build.

"A report full of numbers is not a decision tool. A report that tells a specific person whether to act right now — that's a decision tool."

Failure mode 2: The data refresh is too slow to matter

A report that updates once a week showing last week's emergency department census is a history lesson. It cannot change anyone's behaviour today. A report updating every 15 minutes showing today's capacity by unit and predicted surge times — that changes how a charge nurse allocates staff in the next two hours.

The refresh rate should be determined by the decision cadence. If the decision needs to be made daily, update daily. If it needs to be made hourly, update hourly. Azure Data Factory and Power BI's incremental refresh make this straightforward once the architecture is right.

Failure mode 3: The report was built for the person who reports, not the person who acts

Most organizational reports are built for whoever needs to demonstrate progress upward in the hierarchy. The language is aggregate, the timeframe is monthly, and the audience is leadership. But the people who can actually change the numbers are often frontline workers — charge nurses, caseworkers, transit dispatchers — who need different information, at different frequency, in a different format.

• Build separate report views for different roles — with row-level security ensuring each sees only what's relevant to them.
• Involve frontline staff in dashboard design, not just executive approval. Their feedback in week 2 is worth more than a VP sign-off in week 8.
• Ask: would this person look at this report before making a decision, or after? If after, it's not a decision tool — it's a reporting obligation.

Failure mode 4: Nobody was trained, so nobody uses it

Deploying Power BI is not the end of the project — it's the beginning. If frontline staff don't understand what they're looking at, don't trust the numbers, or don't know how to interpret what the report is telling them to do, the dashboard becomes wallpaper within 60 days of launch.

Budget training hours equal to 20% of development hours. Minimum. Not a one-hour "here's how to filter" session — structured training that covers what each metric means, what threshold should trigger an action, and who to contact when something looks wrong.

What actually works

• Start with one specific decision. Build the report backward from there. Expand scope only after the first report is genuinely being used.
• Put the data refresh rate in the Statement of Work. Make it a requirement, not an afterthought.
• Design for the person who needs to act — not the person who needs to report.
• Budget training hours at 20% of development hours. Minimum.
• Schedule a 60-day post-launch review. What's being used? What isn't? Why?

The technology isn't the hard part. The discipline to keep the project anchored to real decisions — through every requirements meeting, every design review, every stakeholder pressure to add "just one more metric" — that's the hard part. And it's worth it.

The conversation most vendors don't have

When First Nations organizations ask about data analytics, the first conversation with most technology vendors is about tools: "we use Power BI" or "our platform runs on Azure." The first conversation with us is about governance: who owns this data, who controls how it's used, and what happens to it when we're gone?

That difference isn't just ethical. It's the difference between a platform a community will use and trust indefinitely, and one that gets abandoned the moment the vendor relationship ends.

What each OCAP® principle means architecturally

Ownership: The community collectively owns the information generated about its members, families, and territory. This means data cannot be stored in a vendor's cloud subscription, a federal database, or a provincial system that the Nation doesn't control. We deploy all data to infrastructure that is legally and technically owned by the Nation.

Control: The Nation controls how data is collected, who accesses it, how it's used, and what happens to it when a project ends. In practice, this means we build the governance framework before we write a single line of code. The governance is specified by the Nation, not designed by us.

Access: Community members have the right to access data about themselves. Community leadership determines who else does. In our platforms, this means role-based access control built around the Nation's actual governance structure — not a generic healthcare hierarchy or a government org chart.

Possession: Physical or digital custody of the data lives with the Nation. For many communities, this means on-premise deployment: Power BI Report Server and SQL Server running on hardware that the Nation owns and controls, located on Nation territory.

"The governance is specified by the Nation, not designed by us. Our job is to implement what they decide — not to decide what they should have."

Why cloud-first is not always the right answer

The technology industry has a strong bias toward cloud deployment. It's often faster, more scalable, and simpler to maintain. For some First Nations communities, cloud deployment requires trusting a corporation — often a foreign-owned one — with data about community members' health, justice involvement, and family situation. That's not a technology decision. It's a sovereignty decision, and it's the community's to make.

We've delivered platforms in three configurations: fully self-hosted on Nation-owned hardware, Nation-controlled Azure tenant, and hybrid approaches where aggregate data is in the cloud but identifiable records remain on-premise. The right answer depends on the community's connectivity, IT capacity, and governance preferences — not our preference for what's easiest to deploy.

The mistake most analytics projects make with Indigenous data

The most common mistake: treating Indigenous clients the same as any other government client — building a standard cloud platform, connecting it to federal and provincial databases, and delivering a dashboard that the community's health workers use to input data that flows to a system the community doesn't control. This is not an analytics platform. It's a data collection system that happens to show the community some of what it's collected. The distinction matters enormously.

How we actually start First Nations engagements

• We start with a governance conversation with Nation leadership — before any technical discussion. Who needs to approve this? What data will be collected? Who can see it? What happens at project end?
• We ask to speak with Elders and health directors, not just IT contacts or procurement officers.
• We do not begin any data pipeline development until a Privacy Impact Assessment is complete and approved by the Nation.
• We train internal Nation staff to operate, maintain, and evolve the platform — the goal of every engagement is to make ourselves unnecessary, not indispensable.

The result: platforms that communities trust, that serve their actual needs, and that continue functioning and growing long after the engagement ends. That's what OCAP® looks like when you actually implement it.

The evaluator's reality

Government procurement evaluators are experienced, well-intentioned professionals who are also deeply busy. They're evaluating your bid in addition to their regular job. They have a scoring rubric. They're looking for clear, direct evidence that your proposal satisfies specific criteria — they are not looking for creativity, narrative flair, or impressive-sounding technical jargon.

The single most important frame for writing a government analytics bid: make the evaluator's job easy. Every section of your proposal should be structured so that someone can read it, look at their scoring rubric, and immediately identify where you've addressed each criterion.

Read the RFP three times before writing anything

This sounds obvious. Most vendors do it once, quickly, then start writing. Read it three times with different questions in mind:

• First read: What are the Mandatory Requirements? These are pass/fail — missing even one gets you disqualified regardless of how good the rest of the bid is.
• Second read: What are the Rated Criteria and how are they weighted? These tell you exactly where to invest your writing effort.
• Third read: What does the language tell you about the client's actual concerns? The words they choose reveal what they've been burned by before.

Mirror their exact language

If the RFP asks for "demonstrated experience delivering Power BI dashboards in a healthcare setting" — your section heading should be: Demonstrated Experience Delivering Power BI Dashboards in a Healthcare Setting. Evaluators are scoring against their rubric. If they're looking for that phrase and it's not in your proposal, they may score you lower even if the capability is clearly described elsewhere.

"The single most important frame for writing a government analytics bid: make the evaluator's job easy."

Quantify everything. Every claim.

The difference between scoring 8/10 and 10/10 on an experience criterion is almost always the presence of quantified results.

• "Reduced emergency department report generation time by 97%" scores higher than "improved reporting efficiency."
• "Delivered a platform to a 1,200-bed regional health authority" scores higher than "worked with a large BC health organization."
• "94% forecast accuracy validated against 18 months of holdout data" scores higher than "high-accuracy forecasting capability."

Address compliance explicitly, not implicitly

Healthcare and government RFPs always include compliance requirements — FOIPPA, PHIA, security standards, data residency. Don't assume evaluators will infer that you're compliant. State it explicitly: "All data will be stored and processed within BC Azure Government Cloud regions. A PHIA-compliant Privacy Impact Assessment will be completed prior to any data pipeline development."

Add a compliance confirmation table: one column for the requirement, one column for your status (✓ Compliant), one column pointing to where in the proposal you've addressed it. This alone can move you from shortlisted to selected.

Submit 24 hours early

Government portals have hard timestamp cutoffs. Submissions received one second late are rejected without exception or appeal. Portal systems get slow near deadlines as multiple vendors submit simultaneously. Technical failures on submission day are not accepted as grounds for extension. Submit 24 hours early. Every time. No exceptions.

Request a debrief after every bid — win or lose

Government clients must provide debrief meetings when requested. This is one of the most underutilized tools in government contracting. A debrief tells you exactly how your proposal was scored, where you lost points, and what the winning bid did differently. Three properly debriefed losses will teach you more about government procurement than any book or course.