For nine years, my data had to be good enough for a judge

I spent nine years at the Bhabha Atomic Research Centre as a Scientific Officer, Grade C to D to E. My domain was Civil. My actual job was data.

Running a large infrastructure project from an assistant executive engineer's seat means handling procured items, outsourced items, quantities, dates. Today I'd call those facts and dimensions. Back then I called them the job.

Forecasting is the visible half

I started with detailed tenders, taking quantities straight off architectural drawings. Where rate models existed, I used them. Where they didn't, I built them: rate-based cost models across materials, labour and machinery, forecasting budgets on projects up to ₹500 Cr (roughly $50M).

The other half starts when the work does: protecting the capital. That meant reconciling billed quantities against measured quantities, and catching the discrepancy before it was paid out as an overpayment.

The report that slips before the invoice does

Every month I put together progress reports across sites, mapping physical completion against financial metrics. That report tells you a project is slipping before the invoice does. So you can write to the contractor while there is still time to fix it.

Once, it went past tracking. A contractor fell behind schedule. What we had logged daily, in loggers, site registers and files, became the evidence base. I turned it into a liquidated damages proposal that defended our position.

Two contractors looking at your face

I ran the tender award process end to end: compiled data from every site, took contractor bids into Excel, turned the comparison into presentations for the board. Looking back, that is where my analytics work began.

When the board asks why contractor A won and not B, with both of them looking at your face, you don't answer with opinion. You show the scoring. Where A earned points. Where B lost them.

The answer has to hold at two levels. It has to satisfy the board, and it has to satisfy contractor B. If it doesn't satisfy B, you present the same numbers again, this time to a judge, because B sued. That happened sometimes.

Sites run into disputes too. Ours did. The daily logs settled them.

The data outlives the project

The tooling was Excel: advanced lookups, pivot tables, automated templates.

The requirement was harder than the tooling. The data could not die with the project. It had to survive execution, then the maintenance period, and sit there as backup years later in case someone came asking.

Collect from every site, reconcile, model, report, keep it defensible. That is a pipeline, end to end. I just didn't have the word for it yet.

I learned data work in a place where the reviewer could be a judge.