Treat a data project as “hire someone to draw a few charts” and the cycle burns on new skins and new subjects. Run it as engineering and every stage has something you can sign: the KPIs you must watch, the table or API behind each chart, a definition finance and operations share, a page that can ask into documents, and which meeting turns off parallel Excel.
List the three to five KPIs you must watch, the owners, and current definition conflicts. How to cut the operations entry: Which KPIs belong on the leadership dashboard first. Keep a separate list for the floor. Do not mix it into the operations quote.
Which table or API sits behind each chart. Do not draw what you cannot extract. When systems are many, standardize APIs first; see More systems connecting: standardize APIs or draw charts first. When quality is poor, wash in harm order; see Data quality is poor. Build the dashboard first, or clean first.
Finance and operations reach written agreement on the same number, then development starts. If you cannot write it, do not start, or you will still walk the trace tree after go-live. See The system is live and numbers are still wrong. How to trace it.
Build the report you can ask into first, then the decorative wall layer. Add real-time by decision window. Default operations to T+1; see Does it have to be real-time, or is T+1 enough. If the old platform can be inherited, extend it; if not, rebuild. See Rebuild the old reporting platform, or extend it.
Accept against real weekly-meeting topics. Turn off parallel manual sheets. If you cannot stop them, you are not done. See Nobody looks at the dashboard. Is it still worth building. Turn on alerts, permissions, and audit together so you do not ship a read-only exhibit.
Who decides determines whether the project idles at step 4. If nobody signs “this sentence can be calculated externally,” design loops in “change the color again.” At inventory, name who supplies facts, who reviews definitions, and who signs visuals—two rounds at most. More than two usually means KPIs are not set. At kickoff, also write what you will not do: phase one does not load full history, does not do second-level, does not connect a new system that is not yet stable. Shrink scope and definitions can be signed. Cost and cycle depend on which phase you stop at; see What dashboards or a data platform cost, and how long they take. Why start from an operations dashboard: Why an operations dashboard is not optional.
Click a swing into a document. Use one account to verify permission cuts. Use one failed extract to see whether it alerts. Use a rehearsal weekly meeting to confirm parallel sheets can close. Those pass, then it is launched. DaXi Technology delivers operations dashboards, floor screens, and the necessary definitions and APIs in this order, and can plan them with operations systems and device collection.
At kickoff, write what you will not do: phase one does not load full history, does not do second-level, does not connect a new system that is not yet stable. Shrink scope and definitions can be signed. Changes go in writing so verbal “add a chart” does not thrash extracts.
Collect content and permissions as required fields per KPI, not “just open the database.” Opening a database is not the same as being able to reconcile. The master-data owner needs a name.
Visit one week after launch: is the weekly meeting still using attachments; are exceptions still announced in chat. That judges landing better than design satisfaction.
Submit the KPIs you must watch and the systems they are scattered across. Tool vs custom is a step-two choice, not step one.