- A task and the hours logged against it are one record; splitting them across two systems is the shape that fails.
- Either Deltek owns execution and reporting sits on top, or Project Operations owns the whole execution lane and hands off once at invoicing.
- Whether time entry can move out of Deltek settles most of these evaluations on its own.
- A visibility gap is a reporting project, and costs a fraction of a platform migration.
An engineering and architecture firm of a couple hundred people came to us with a project-management problem and a shortlist. Their projects, time, and accounting all ran in Deltek Vantagepoint. Their planning did not. One group planned in Microsoft Planner, another in Microsoft Project, someone kept a spreadsheet of deadlines, and someone else typed dates into Vantagepoint. Nobody planned twice in the same place.
The committee's original brief was modest: find something like Planner, but better. By the time it reached us, it had grown into a much larger question, which was whether the firm should be running Vantagepoint at all. They asked us to scope Microsoft Dynamics 365 Project Operations to sit alongside it and keep the two in sync.
We could not recommend it in that shape. The reasoning generalizes, so it is worth laying out: any firm running Deltek that is evaluating a project platform to sit on top of it arrives at the same fork.
The shape they asked for
The request was specific, and it is the most common version of this request. Tasks would be planned and executed in Project Operations. Time would keep being logged in Vantagepoint, because that is where payroll, benefits, and the employee record live. The two systems would stay in sync.
That last sentence is where the cost hides.
A task and the hours logged against it are not two records. They are one record split down the middle, with both halves editable on both sides. A project manager moves a deadline in Project Operations on Tuesday morning, a crew logs eight hours against the old date in Vantagepoint that afternoon, and the sync has to decide which system was right. Multiply that by every field, every user, and every awkward bit of timing, and the sync stops being plumbing you install. It becomes a process somebody runs.
When the two systems disagree about a task's dates or its hours, which one is right? Every answer we could build cost real money to maintain, and it would keep costing through every future update to either product.
The estimate made the point better than we did. It came to 11 workstreams over nine to eleven months, and the largest single line in it was not the build. It was data migration, and not because the initial load was difficult. It was because both systems would have to agree about every project, milestone, and task from the first week onward, which turned the migration into a moving target for the length of the engagement and a standing job after go-live.
There is a second thing worth naming. Vantagepoint and Project Operations overlap heavily: tasks, scheduling, resource assignment, time entry, and invoicing. The firm was already licensed for most of what it said it was missing. A second system that does the same work as the first is where technical debt comes from, and it earns nothing back unless it replaces the first system at something.
One question sat underneath all of it, and the firm raised it before we did. Nobody currently there had configured Vantagepoint, so it was genuinely unclear how much of the pain came from the product and how much from a setup that had drifted over the years. That question has to be answered before a replacement can be justified, and answering it costs a small fraction of replacing anything.
The two shapes that work
There were two coherent versions of this project. The version on the table was the incoherent middle.
Deltek owns execution. Task management gets rebuilt inside Vantagepoint, so planning, assignment, deadlines, and time all happen in the one system that already holds the contract and the ledger. What remains is a visibility problem rather than a platform problem, and it gets solved with a reporting layer on top: Power BI, extended with Microsoft Fabric if the reporting has to span other systems too. Reporting reads and never writes back, so the entire class of conflict never exists.
Project Operations owns the whole execution lane. Projects, tasks, schedules, resource assignments, and the time logged against those tasks all move to Project Operations and stay together. The lane ends at invoice creation, where a single handover carries a rolled-up, invoice-ready package into the financial system for accounting, cash, and treasury. That integration surface is small, it runs one direction, and nothing flows back.
Both work for the same reason: every piece of information has exactly one owner. The middle option fails because a task and its hours end up with two.
Two systems that must agree about the same number, forever, is one of the most expensive promises in software.
How to tell which one you are in
If you run Deltek and you are weighing a project platform on top of it, these are the questions that decide it. They sound like details. They are the decision.
- Can time entry move? If hours have to be logged in Deltek because payroll, benefits, and the employee record live there and are not going anywhere, then task execution should stay in Deltek too. Tasks and the hours booked against them belong in the same system. This question alone resolves most of these evaluations.
- Is finance attached to the ledger, or to the project? If Deltek's real job is the general ledger and the close, the execution lane can leave cleanly at invoice creation. If Deltek is also where project managers work the project day to day, moving execution out means moving them out, which is a change-management project rather than an integration.
- Is the gap execution, or visibility? "We cannot see status, percent complete, risks, or schedule performance without calling a meeting" describes a reporting gap. Reporting gaps get solved with a reporting layer over the system you already run, for a fraction of the cost and none of the sync risk. Buying a platform to fix a dashboard is the most expensive way to get a dashboard.
- Who owns budget versus actuals, and change orders? Those follow the contract and the ledger, which usually means Deltek. If a new platform is expected to own forecasting while Deltek keeps the actuals, the sync problem has just moved into the money column, where it is harder to live with and far more visible when it drifts.
- What is resource planning measured against? Crew availability and utilization are only as trustworthy as the actual hours behind them. A scheduling tool that cannot see real time entry produces a plan nobody believes by the second month.
- What can move without an argument? Documents can. Contracts, proposals, drawings, change orders, and reports have one writer at a time and no competing system of record, so a document library with version control (SharePoint, in a Microsoft shop) can absorb that whole requirement with no sync at all. If a chunk of your requirements list is really document management, carve it out and solve it on its own. It is the cheapest win available.
- Would you be running two systems that do the same job? Write down every capability both products cover. If that list is long and the new platform is not replacing the old one at any of it, the overlap is a cost with nothing on the other side of the ledger.
The scale argument is worth checking
Growth is the reason most often given for leaving Deltek: we are bigger now, so we have outgrown it. Sometimes that holds. Often it does not. Deltek runs the project and accounting operations of firms with billions in revenue, and Dynamics competes for those same organizations, which means the two products sell into the same range rather than into different tiers of it. So when growth is the argument for a replacement, the argument has to name the specific capability that runs out and roughly when. Headcount by itself is not that argument.
The step before the software decision
The most useful thing said on that call was not ours. The firm's principal named a step that came ahead of any vendor step. Five or six domains inside the firm each understood their own corner of how work got planned and delivered, and nobody held the whole picture. Before anyone could specify software, the firm had to decide how it wanted to work.
That is where these evaluations usually stall, and no vendor can clear it for you. A shortlist cannot be scored against requirements that do not yet exist in a single document.
What we can do is a paid discovery phase, deliberately system-agnostic, with one job: document how the business runs today, settle who owns what, and describe a future state you can hand to anyone. The deliverables are process diagrams and a data dictionary of that future state that names no product, so you can take it to a Deltek consultancy, to us, or to anyone else, and collect fixed-fee proposals against one specification instead of estimates written against four different readings of your business. If we go on to build the solution, the discovery fee credits toward it.
The firm we were talking to put the discovery option in its board write-up rather than the implementation. That was the right order.
If you are weighing this
If you run Deltek and you are looking at a project platform to sit on top of it, the conversation that helps starts with two things: where time gets entered, and who is allowed to change a task. Bring us those answers, your Deltek setup, and whatever requirements document your committee has been assembling, and we will tell you which of the two shapes you are in.