Giving Vantagepoint a Memory

A client migrating from Ajera to Deltek Vantagepoint brought me on specifically to handle dashboards. That sounded contained. It wasn’t.

Ajera gives firms a lot of latitude in how they surface financial data, and this client had built real business processes around dashboards they checked daily. My job was parity in VP. Parity turned out to be the easy 80% — the last 20% is where the actual work

The ask

Backlog — Contract value minus Spend at Burn Rate — visible at every level of the Work Breakdown Structure (Project > Phase > Task), and as historical snapshots, not just today’s number. They wanted to see where Backlog stood three months ago at the Phase level, the same way they could in Ajera.

VP doesn’t work that way. Dashparts pull live data only. There’s no native mechanism to freeze a moment in time. This wasn’t a configuration problem I could solve by clicking around the platform longer — it was a data availability problem. The data literally didn’t exist anywhere to query.

The architecture

If VP can’t store historical state, you build the layer that does.

I designed a custom hub inside Vantagepoint’s Screen Designer, paired with a stored procedure I wrote to populate it. The procedure runs on a monthly schedule: it queries the active Project, Phase, and Task records, calculates Backlog at each WBS level, and writes a snapshot record into the custom hub — a frozen point-in-time slice of data that VP itself will never overwrite or recalculate.

Each snapshot record carries the full WBS context — Organization, Phase Number, and the other grouping attributes the client needed. That mattered more than it might sound: it meant their team could build dashparts that slice the data however they wanted — by org unit, by phase grouping, by time period — without being boxed in by VP’s live-only data model ever again. This wasn’t a one-time report. It was a data layer they could build on top of indefinitely.

The result

They got historical Backlog visibility at the Task level — something VP simply doesn’t offer natively — and the dashboard flexibility they’d relied on in Ajera. The engagement expanded: they came back and asked for the same pattern applied to Pipeline, tracking monthly Pipeline history through time using the identical hub-plus-MERGE approach.

The bigger pattern

This is the first instance of what I now think of as a repeatable methodology — I call it the Shadow Data Layer. The short version: any time a client asks VP to remember something, aggregate across projects in a way the dashpart engine won’t support, or combine data from separate hubs, the answer is usually a variation on the same six-step build. This Dahlin-style snapshot pattern has since shown up in five other engagements, each with its own twist, all running on the same underlying architecture.

I’ll be writing that methodology up on its own in a few weeks, once a few more of these land. This one was the first, and it’s still the cleanest example of the core idea: when the platform can’t do something, sometimes the right move isn’t to wait for a feature request — it’s to build the small piece of infrastructure that makes the platform capable of it.