Data & Analytics Development in New Zealand

The dashboard is the last week

Data projects are bought as visualisation and delivered as archaeology. The chart at the end is genuinely quick. What comes before it is not:

• Finding where each number actually lives, which is rarely where people think.
• Deciding which system is right when two of them disagree.
• Handling the three years when a field was quietly used for something else.
• Reconciling customers who exist twice, spelled differently.
• Getting the business to agree what a customer, a sale, or an active account actually is.

A quote that skips all this is not cheaper. It has moved the work to you, and you will meet it in week four when the numbers do not match what finance believes.

Your numbers disagree for a good reason

When sales, finance and operations report different revenue, it is usually not a bug. Sales counts an order when it is placed. Finance counts it when it is invoiced. Operations counts it when it ships. All three are correct, and all three are different numbers.

The valuable output of a data project is often not the dashboard — it is a written definition, agreed by the people who argue about it, of what each report counts and when. That decision is yours to make; a good developer will force the conversation and write the answer down.

Do you need a warehouse?

Three reasons justify one, and if none applies, reporting straight against your source system is simpler and cheaper:

• You are combining systems. Reports that span your CRM, accounting and operational systems need somewhere to meet.
• You need history the sources do not keep. Many systems overwrite: the current stock level exists, last Tuesday's does not.
• Reporting is slowing down the systems people work in. Heavy queries against a live database make the application sluggish for everyone.

Ask any developer proposing a warehouse which of the three applies. A clear answer is a good sign; "best practice" is not one.

Licences are a permanent line item

Tools are licensed per person, per month, and the total surprises people regularly. Twelve users at $20 is $2,880 a year, forever, and it grows with headcount.

Count everyone who needs access, including occasional viewers — the branch manager who looks monthly still needs a seat. Ask what tier is required for features in the proposal, because scheduled refreshes and sharing often sit above the entry level. Then compare that annual figure against the build cost, because over five years it may be the larger number.

Build for the questions people ask

The most common way a reporting project fails is not technical. It is a beautifully engineered dashboard that answers questions nobody was asking, while the report people actually rely on stays in a spreadsheet.

Before briefing anyone, collect the questions the business asks every month and the spreadsheets people maintain by hand. Those spreadsheets are the specification: someone cared enough to build them manually. If the new system does not eliminate them, it has not replaced anything.

Refresh, and failing loudly

Ask how often data refreshes, how long that takes, and what someone sees when a refresh fails.

The dangerous failure is the quiet one: the dashboard still renders, the numbers look plausible, and they are four days old. People make decisions on them for a fortnight. Every pipeline should show when it last ran successfully, on the report itself, and should tell someone when it did not.

Who can change it afterwards?

Reporting requirements change constantly — a new region, a new product line, a new way of grouping customers. If every change is a call to a supplier, the system becomes expensive and then becomes ignored.

Ask what your own team can modify without help, and get a demonstration on your own data before final payment. There is a genuine trade-off here: more governed systems are harder to change but harder to break. Decide which side you want deliberately rather than discovering it later.

What to compare across quotes

• The cleanup share. How much is data work, and what happens if the data is worse than assumed.
• Definitions. Who agrees them and where they are written down.
• Licence total, annually, for everyone.
• Refresh and failure. Frequency, and what a failure looks like.
• Self-service. What you can change without them.
• Warehouse justification, if one is proposed.

Bring the spreadsheets

You do not need to specify a tool or an architecture. Bring the questions the business argues about, the spreadsheets people maintain by hand, and the list of systems the numbers live in. Developers who do this work weekly will tell you which reports are straightforward, which depend on cleaning something up first, and which cannot be answered at all until the business decides what it means.