Copying the Code Behind the Curtain

A Business Systems Analyst at an AEC firm came to me with a visualization problem: a line chart, one per employee, showing cumulative expected hours climbing steadily from January to December — a straight baseline from bottom-left to top-right — plotted against actual hours charged. Not a snapshot. A trend.

The goal was utilization over time, not utilization right now.

Deltek Vantagepoint can’t do this natively. It can tell you expected hours for a given day. It has no mechanism to aggregate those hours cumulatively across weeks into something a trend chart can consume. There was no out-of-the-box path from what VP shows you to what he needed to see.

The requirement, precisely

Weekly cumulative expected and actual hours, per employee, for a full year — accounting for holidays, non-working days, hire dates, and termination dates — in a form VP’s dashpart engine could actually render. And it needed to happen without a stored procedure, without IT approval, and without custom infrastructure sitting outside the platform.

That last constraint mattered more than it might sound. Stored procedures require coordination, carry system risk, and are harder for a client to adjust independently. He wanted to move fast and show leadership something real — not wait on an approval cycle.

The build

We landed on a custom grid, built inside VP’s screen designer, living on each employee record — one row per week of the year, fifty-two rows total. A scheduled workflow, using nothing but SELECT statements, runs on a recurring basis and populates each row with that week’s expected and actual hours. Once the grid fills in, VP’s dashpart engine — a relatively new platform feature — pulls straight from it and renders the trend line, weeks on the X axis, compared against expected hours.

Staying workflow-only was a deliberate call, not a default. It kept the whole thing inside something he could see, edit, and reason about without escalating to a dev team.

The part that actually took work

The tricky piece wasn’t the chart. It was getting expected hours right. VP calculates expected hours internally, accounting for holidays and non-working days — but none of that logic is documented anywhere.

So I opened SQL Profiler, pointed it at my own demo database, and watched VP’s own queries execute in real time while triggering the calculation myself. That surfaced the underlying logic directly, which I could then reproduce inside the workflow’s SELECT statements. It’s a technique I keep coming back to across engagements: when the platform won’t document how something works, you watch it work and reverse-engineer what you see.

Where it got iterative

After the first build, leadership reviewed it and came back with two real changes: account for holidays and non-working days in the expected-hours calculation (solved by the profiler work above), and shift the start/end window to align with each employee’s hire date and fiscal quarter rather than a fixed calendar year. Termination dates needed handling too, so expected hours wouldn’t keep inflating for people who’d already left.

Each change came back as its own discrete ask, and we folded them in one at a time rather than trying to guess the full spec up front.

Where it landed

Leadership approved the solution once the holiday and hire-date logic were in. It’s in final review before full rollout — no stored procedures, no custom infrastructure outside the platform, just a workflow engine doing something it was never really built to do, because we gave VP a place to remember its own history week by week.

The pattern shows up more than people expect: Vantagepoint is very good at telling you where things stand right now. Getting it to remember — or to trend, or to aggregate in a shape it wasn’t designed for — usually isn’t a wall. It’s a data layer nobody’s built yet.