Implementing Dynamics 365 Project Operations: Key Considerations
A technical guide to a Dynamics 365 Project Operations implementation: the deployment choice, requirement mapping, project planning, resourcing, time and expense, the integration to your finance system, and the order the whole thing has to run in.
A Dynamics 365 Project Operations implementation is decided before anyone opens a configuration screen. Settle the deployment shape first, because only the lite deployment runs entirely on Dataverse and stops at proforma invoicing. Then map requirements in the order the product is actually built in: the contracts you really sell, the resource roles with the cost and bill rates behind them, the work breakdown structure, and the weekly time and expense cycle your consultants will follow. Configure billing to those contracts, integrate to the finance system that issues the invoice, and build reporting last. This is how our Yerevan team runs it.
Two notes before the detail. First, the deployment shapes, licence names, and prerequisites around Project Operations are Microsoft product decisions and Microsoft revises them, so confirm the current shape and the current licensing in Microsoft documentation before you build a plan or a budget around it. What does not move much is the sequence the work has to run in, and that is what most of this page is about. Second, our scope, stated plainly: Solzet delivers Dynamics 365 Customer Engagement and the Power Platform, meaning Dataverse, Sales, Customer Service, Field Service, Customer Insights, Power Apps, Power Automate, and PCF. We do not implement finance, accounting, or supply chain platforms. Where you already run one, we integrate the project system with it rather than replacing it, and that boundary is designed into the build instead of being discovered halfway through.
The answer in three lines
The deployment shape is the first decision, and it is not technical
Project Operations ships in more than one shape. The lite deployment runs on Dataverse next to Dynamics 365 Sales and stops at proforma invoicing. The heavier shapes pull in a separate Microsoft enterprise finance back end, which brings its own programme, its own licences, and its own timeline. Choosing between them decides the cost, the duration, and how much of your finance process moves at all, so it belongs in week one rather than in a later phase.
Configure the contracts you sell, not the ones in the demo data
Project Operations is a billing and resourcing system with a project plan attached. Every serious configuration decision, meaning contract lines, billing rules, chargeability, and approval paths, follows from the commercial models you actually sign: time and materials, fixed price against milestones, retainers, and the mixed contracts nobody wants to admit to. Write those down before the first configuration workshop and most of the build stops being a debate.
Time and expense adoption is what decides whether it worked
Every downstream number, meaning utilization, margin, forecast, and the invoice itself, is produced by consultants filling in a timesheet on a Friday. A rollout with immaculate configuration and forty percent timesheet compliance has failed. Design the capture experience and the approval cycle around what the firm already does, and treat it as the deliverable rather than as the last item on the plan.
Decision one: the deployment shape
This is the decision most implementation guides bury on page four, and it is the one that sets the budget, the timeline, and who is even on the project team. It should be settled in week one, with a written rationale.
The lite deployment, which is where most services firms land
Runs entirely on Dataverse alongside Dynamics 365 Sales, so it sits in the same environment, the same managed solution pipeline, and the same security model as the CRM. It covers opportunity through project planning, resourcing, time and expense capture, project contracts, and billing up to a proforma invoice. It stops there deliberately: the statutory invoice, the ledger, and the tax reporting stay in your finance system. For a firm of twenty to a few hundred consultants that is usually the right answer, because the part of the process that genuinely needs to move is the part before the invoice.
The heavier shape, which adds a separate finance back end
The resource based and stocked shapes bring in a full Microsoft enterprise finance back end, with subscription billing, revenue recognition, and the general ledger inside the same platform. That is a genuinely different programme: different licences, different consultants, a longer timeline, and a much larger change footprint across the finance team. It is the right answer when project accounting has to live in the same ledger as everything else and the organization is already committed to that platform. It is the wrong answer when somebody chose it because it appeared in a feature matrix.
How to actually decide between them
Ask one question: where does the statutory invoice have to be issued, and by which system, for legal and audit purposes. If the answer is an accounting package you are keeping, the lite deployment plus a designed integration is almost always the shorter and cheaper route to the same operational outcome. If the answer is that finance is moving to the same platform anyway as part of a wider programme, the heavier shape stops being extra scope and starts being alignment. Everything else, meaning feature comparisons and roadmap slides, is secondary to that one question.
What the choice locks in
Licensing and its renewal shape, the length of the programme, who is on the project team, whether your finance function is a stakeholder or a participant, and how much of the integration you own. It also decides how reversible the decision is. Moving from a lite deployment to the heavier shape later is a project, not a switch, so treat this as an architecture decision with a written rationale rather than as a licensing formality. Record why you chose what you chose, because the person who inherits the environment in three years will need it.
Requirement mapping: what to write down before the first workshop
Project Operations is a billing and resourcing system with a project plan attached, so almost every configuration decision is downstream of a commercial one. These seven documents are what turn a configuration phase from a series of debates into a series of decisions.
The commercial models, in the words the contracts use
List every way you charge: time and materials, fixed price against milestones, retainer, capped time and materials, and the mixed contracts where a fixed discovery is followed by a variable build. For each one write down what triggers an invoice, what happens to work done beyond the cap, who approves it, and which currency it is signed in. This list becomes contract lines and billing rules almost directly, and a build that starts without it will be reworked after the first real billing run.
The delivery shapes you sell, as project templates
Most firms sell four or five recognisable engagement types under many project names. Capture each one as a work breakdown structure with its phases, typical effort, dependencies, and milestones, and that becomes a template a project manager can start from rather than a blank plan. It also exposes disagreement early, which is useful: two partners describing the same engagement type differently is a scoping problem you would rather find in a workshop than in a variance report.
The resource roles and the two rates behind each one
Roles, the skills and proficiency levels that qualify somebody for them, the bill rate you charge, and the cost rate the margin is calculated from. Both rates need effective dates so that historic projects keep the rates they were delivered at when this year's increase lands. Build the cost rate from real payroll cost including employer side contributions rather than from gross salary, because every margin figure downstream inherits that number, and an optimistic cost rate produces a reporting layer nobody trusts.
The time and expense cycle the firm already runs
When timesheets are due, who chases them, who approves them, what an expense policy actually allows, and how billable against non billable is decided in a disputed case. Configure to that cycle. A rollout that invents a new weekly rhythm at the same time as it introduces a new system is asking people to change two things at once, and the timesheet is the one that quietly loses.
The approval chain, with names against it
Time approval, expense approval, contract approval, and the point at which a proforma is signed off for invoicing. Each needs a named owner and a named deputy, because approval steps with no deputy are where billing cycles stall in August. Where an approval is really a two person conversation rather than a workflow, model it as such instead of building an approval nobody honours.
The reporting questions partners actually ask
Write down the six to ten questions the leadership team asks every month: utilization by person and by practice, margin by project and by contract type, revenue forecast against pipeline, work in progress, and unbilled time by age. Those questions decide which fields have to be reliable, and reliability is a configuration and adoption decision rather than a Power BI one. Build the reports last, but know the questions first.
The boundary with finance, drawn on one page
One diagram, one page: what the project system owns, what the finance system owns, what crosses between them, in which direction, and how often. This is the artefact that prevents the most expensive category of rework, which is discovering during user acceptance testing that two systems both believe they own the invoice. It belongs in scope from day one, not in a later integration phase.
The implementation sequence, step by step
Steps 1 to 3 decide the shape of the programme. Steps 4 to 7 build outwards from the sales side, because a project contract is fed by a quote. Steps 8 to 11 are where the value actually appears and where rollouts most often stall. Steps 12 and 13 prove it and hand it over. The order matters: reporting built before capture is stable is the classic way to lose the leadership team.
Settle the deployment shape and write down why
Decide between the lite deployment on Dataverse and the heavier shape that adds a separate finance back end, and settle it in week one. Drive the decision from where the statutory invoice has to be issued rather than from a feature comparison. Record the rationale, the licences it implies, and what it means for the finance team, because this single choice sets the budget, the timeline, and the size of the project team more than any configuration decision that follows it.
Map the commercial models before the first configuration workshop
List every contract type you sell with its invoicing trigger, its treatment of overrun, its approval path, and its currency. Do the same for the four or five engagement shapes you deliver, captured as work breakdown structures. Configuration workshops that start from this document produce decisions; workshops that start from demo data produce discussions. This step costs a few days and removes most of the rework that would otherwise appear after the first billing run.
Design environments, licences, and the security model together
Separate development, test, and production environments, your own publisher and solution rather than the default one, managed solutions promoted forward, and source control from the first commit. Choose the Dataverse region and base currency at creation, because neither can be changed afterwards. Design security roles around who may see project financials rather than around the org chart, since cost rates and margin are the most sensitive data the system will hold and a consultant seeing colleague cost rates is a real incident.
Model the sales side first, because it feeds everything downstream
A project contract is fed by a quote and an opportunity, so a messy pipeline produces messy contracts. Get accounts, contacts, opportunities, and quote lines right in Dynamics 365 Sales first, with one customer model shared by sales and delivery rather than two. Configure the path from closed won to project kickoff so the plan is created from the opportunity instead of retyped, and so the people selling the next engagement can see how the current one is going.
Build the resource model: roles, skills, calendars, and both rates
Define resource roles with the skills and proficiency behind them, the bill rate and the cost rate per role with effective dates, and the resource calendars loaded with your real public holidays rather than the default calendar a new environment ships with. Get the calendars right before anyone measures utilization, because the calendar is the denominator: a wrong holiday set makes an entire quarter of utilization reporting wrong in a way that is not obvious from the number.
Configure project planning and the work breakdown structure
Turn the engagement shapes from step two into project templates with tasks, effort estimates, dependencies, and milestones. Set a baseline once a plan is agreed, because the baseline is what later shows where a project drifted and when. Carry cost and revenue on the estimates so a project manager sees budget against actual as time is approved rather than at month end, which is the difference between renegotiating scope creep and reporting it.
Configure project contracts, contract lines, and billing rules
Build the contracts from step two: contract lines with their own billing method, chargeability rules, included roles and transaction classes, and the milestone schedule where the work is fixed price. Test each contract type against a real past engagement rather than an invented one. If a contract you genuinely sell cannot be expressed cleanly, that is the moment to decide whether to change the configuration or change the contract, and it is much cheaper now than after go live.
Roll out time and expense capture as the adoption programme it is
Give consultants the simplest capture path that produces correct data, on the device they will really use, with the weekly rhythm the firm already runs. Prefill what can be prefilled from bookings, keep the number of mandatory fields to the ones the invoice needs, and make the approval step fast for approvers. Train on the fortnight, not on the feature list, and publish compliance weekly from day one so that a drop is visible while it is still a nudge rather than a crisis.
Integrate to the finance system that issues the invoice
Approved billing data leaves the project system as data, and the issued invoice number, date, and payment status come back onto the project contract so a partner sees real billing status without opening the accounting package. Build it with a service principal rather than a personal account, an idempotency key so a retry cannot double invoice, a retry policy, and a failure path a named human is alerted on. Reconcile the two systems on totals per period, not on spot checks.
Migrate only the project history you will actually use
Open engagements, their contracts, and enough time history to make the current period and the utilization comparison meaningful. Closed projects from six years ago belong in a read only archive or a reporting store, not in the new system, and every row you decline to migrate is a row that never has to be reconciled. Use an alternate key on the legacy project identifier so a reload repairs rather than duplicates.
Rehearse a complete billing cycle before go live
Take real time entries through approval, into a proforma, across the integration, and out as an invoice in the finance system, then reconcile. This rehearsal is the single most valuable test on the project, because billing is where configuration errors become customer facing and where nobody gets a second chance to look competent. Run it on real data, with the people who will really do it, on the day of the month they will really do it.
Build the reporting layer last, on numbers people already trust
Utilization, margin, work in progress, unbilled time by age, and forecast against pipeline, answering the questions written down during mapping. Building this first is the classic mistake: a dashboard fed by half adopted timesheets teaches the leadership team that the system lies, and that reputation is very hard to recover. Ship reporting once the capture and the billing cycle are stable, and it lands as the thing that finally made the platform worth it.
Hand over with hypercare, an owner, and a change process
Four to eight weeks of hypercare through at least one full month end and one full billing cycle, a named internal owner for the rate model and the contract templates, and a written change process for the things that will move: rates, roles, templates, and approval chains. Add the two Microsoft release waves a year to somebody's calendar so updates are tested before they land rather than discovered in production.
Integrating with finance: who owns what
The clean design rule is one sentence: the project system owns what should be billed, and the finance system owns what was billed. This table is the one page artefact that prevents the most expensive category of rework, which is discovering during user acceptance testing that two systems both believe they own the invoice.
| What | Which system owns it | What crosses the boundary |
|---|---|---|
| The customer record | Shared, with one master. Usually the CRM side owns the commercial customer while the finance system owns the legal billing entity, and the two are not always the same organization. | A stable identifier held on both sides, matched on a tax registration number or an equivalent key rather than on the company name. Name matching is what produces two customers, two ledgers, and an argument in month three. |
| The project contract and its lines | The project system. This is where the commercial model lives, and it is the reason the module exists. | Usually nothing crosses at contract signature. What crosses later are the amounts the contract produces, which keeps the interface small and the failure modes few. |
| Approved time and expense | The project system, unambiguously. Capture, approval, chargeability, and the audit trail behind them all belong on the Dataverse side. | Cost lines where the finance system needs project cost for the ledger, usually as a periodic summary rather than as a row per timesheet line. Sending every line across is a common early design that nobody enjoys supporting. |
| The proforma invoice | The project system produces it, and in most jurisdictions it is not a document a tax authority recognises. It is a statement of what should be billed. | On approval, out to the finance system as the source for the real invoice, with the project contract, the period, and the lines it was built from carried along so the invoice can be explained later. |
| The statutory invoice, the ledger, and tax | The finance system, always. Invoice numbering, tax treatment, electronic invoicing where it is mandated, credit notes, and the general ledger are its job and not something to reproduce on the project side. | Back the other way: invoice number, invoice date, and payment status onto the project contract, so a project manager sees billing reality without a login to the accounting package. |
| Revenue recognition | Depends on the deployment shape and on your accounting policy, and this is the item most likely to be assumed rather than decided. | Settle it in writing with the finance team during mapping. Whichever system owns it, the other one must not quietly calculate a second version, because two revenue numbers in two systems is the fastest way to lose the finance team as a sponsor. |
| Reporting and analytics | Neither, ideally. Utilization, margin, and forecast are read from both sides rather than owned by one. | A reporting layer that reads project data from Dataverse and billed and paid data from finance, joined on the identifiers above. Build it once the underlying numbers are trusted, not before. |
Where local tax rules decide the boundary for you, the detail matters more than the diagram. For firms delivering from Armenia, the VAT, electronic invoicing, currency, and holiday calendar constraints that shape a Project Operations build are covered on our Dynamics 365 for professional services page, which also sets out what a local implementation involves end to end.
Configuring time and expense so people actually use it
Everything the platform produces is manufactured by a consultant filling in a timesheet on a Friday afternoon. This is the shortest list on the page and the one that most decides whether the implementation was worth doing.
Design for the phone as well as the laptop, because the consultant on a client site at six in the evening is exactly the person whose entry you most need and least often get.
Prefill from bookings. If somebody is booked to a project on Tuesday, the timesheet should already say so and ask only for confirmation and hours, which turns a data entry task into a review task.
Keep mandatory fields to what the invoice genuinely needs. Every optional field somebody made mandatory in a workshop is a few seconds per line multiplied by every consultant every week, and it is paid for in compliance.
Make approval fast and batched. Approvers are usually the busiest people in the firm, so an approval experience that needs eight clicks per line becomes an approval that happens on the last day of the month, if at all.
Decide the billable and non billable rule in advance and encode it, including the awkward cases: travel, rework, pre sales, and internal projects. Left to individual judgement it produces inconsistent margin data that no report can repair.
Publish compliance weekly from the first week, by team, with a named owner per team. Visibility does most of the work here, and it costs one automated flow.
Treat expenses as a separate rollout with its own policy, receipt handling, and approval path. Bolting expenses onto the timesheet training is how expense adoption gets forgotten until the first client challenges a rebilled cost.
Managing project resourcing
Resourcing is where a services business makes or loses its margin, and it is the part of the configuration that quietly decides whether your utilization reporting is true.
Generic requirements first, named people second
A plan should ask for a senior consultant for twelve days in March before it asks for a specific person. Generic resource requirements let you see demand against capacity across the whole pipeline, and they let the resource manager fulfil them from the bench rather than from the memory of who was free last time. Plans written straight to named people look precise and forecast badly.
The skill model earns its keep or it does not exist
Skills and proficiency levels are only worth maintaining if the schedule board actually filters on them and somebody keeps them current. A skill taxonomy with sixty entries that nobody updates is worse than five that are true, because it produces confident searches with wrong answers. Start small and add categories when a real staffing decision needed one.
Calendars are the denominator, so get them right first
Resource calendars carry working hours, public holidays, and part time patterns, and every utilization number is a division by them. A new environment ships with a default calendar that matches almost nobody, and loading your real holidays and working patterns before go live avoids a quarter of reporting that looks plausible and is wrong.
Bookings and assignments are two different things
A booking is capacity reserved on a person; an assignment is work on a task in the plan. They are related but not the same, and treating them as interchangeable is a common source of confusion between project managers and resource managers. Decide which one your organization schedules against, make that the rule, and keep the other in step deliberately.
The scheduling engine is shared, which is genuinely useful
The same universal resource scheduling foundation underneath Project Operations also drives Dynamics 365 Field Service, so a firm that schedules both project consultants and field engineers is working with one scheduling model rather than two products. If field work is the harder half of your business, the trade offs are the subject of our comparison of Dynamics 365 Field Service against dedicated dispatch tools.
Cost rate discipline is the whole margin picture
Bill rates are visible and get attention. Cost rates are invisible and decide every margin figure the leadership team will look at. Build them from fully loaded payroll cost, review them on a schedule with an owner, and keep effective dates so last year's project keeps last year's truth. This is the least glamorous configuration on the project and the one most likely to be wrong.
If the scheduling half of your business is field engineers rather than project consultants, the buying decision underneath it is a different one, and we compare the options in Microsoft field service dispatch software against dedicated scheduling tools. What a delivered scheduling and resourcing build looks like in production is in our field service digitization case study for a European manufacturer.
Where these implementations actually go wrong
None of these are product defects, which is the point. Every one of them is a decision taken late, taken by default, or taken by somebody who was not in the room.
The deployment shape was chosen by accident
Somebody picked the heavier shape because it appeared complete on a slide, and a services firm of eighty people found itself running a finance platform programme it never intended to buy. Or the reverse: a lite deployment was chosen without noticing that group reporting genuinely required project accounting in the same ledger. Both are recoverable, and both are much cheaper to avoid.
Configuration started before the contracts were written down
Contract lines and billing rules configured against demo data get rebuilt after the first real billing run, and the rebuild is more expensive than the original build because there is now data sitting on top of it. This is the most common single cause of a Project Operations phase overrunning.
Timesheet adoption was assumed rather than designed
Compliance drifts to sixty percent, the reports become approximately true, partners stop opening them, and within two quarters the firm is running the old spreadsheet next to a platform it is still paying for. Nothing about this failure is visible on a project plan, which is exactly why it needs its own workstream and a weekly number.
The finance integration was left to a later phase
Billing is the point of the system, so an integration scheduled after go live means the first months are run by exporting spreadsheets, which teaches everyone that the platform does not really do billing. Design the boundary on day one even if you build it in month four.
Cost rates were built from gross salary
Employer side contributions, benefits, and non billable overhead left out of the cost rate produce margins that are uniformly optimistic. The reporting layer then looks excellent and disagrees with the accounts, and the finance team stops trusting the platform. Fixing it later means recalculating history.
Nobody owned the model after go live
Rates change, roles change, engagement templates change, and approval chains change when people leave. Without a named internal owner and a change process, the configuration slowly stops matching the business, and eighteen months later the system is described as inflexible when what actually happened is that nobody was allowed to maintain it.
The rollout was treated as a software install
This is the same pattern we wrote about in field service, where implementations fail on data, on scheduling rules that do not match how work really happens, and on adoption nobody planned for, rather than on missing features. Project Operations fails the same way and for the same reasons, which is why the sequence on this page puts the human steps in the middle rather than at the end.
The same pattern, written up for a different module, is in why mid-market companies fail at D365 Field Service implementation. If a rollout has already passed the point where more build helps, the useful next step is a forensic audit and a scope reset rather than another sprint, which is what rescue and project takeover is for.
How Solzet delivers a Project Operations implementation
This is our scope stated plainly, including where it stops, so you can tell before a contract whether we are the right team for the shape of your programme.
We deliver the Dataverse and Customer Engagement side of the module
Project planning and templates, the resource, skill and rate model, project contracts and billing rules, time and expense capture, and the reporting layer, all inside the same environment, managed solution pipeline, and security model as your CRM. That is the platform our senior engineers work on full time, so nobody is learning it on your project.
We integrate to your finance system rather than replacing it
We do not implement finance, accounting, or supply chain platforms. Where you already run one, we design the boundary, build the integration through the Dataverse Web API, Power Automate, or a custom connector with authentication owned by a service principal, and make sure the invoice reference comes back onto the project contract. Saying where our scope ends is more useful to you than claiming the whole stack.
We start from your contracts, not from a demo environment
The first workshop produces the list of commercial models, engagement shapes, and approval owners described above. It is unglamorous and it is the artefact that most reliably keeps the build inside its window, because it converts the configuration phase from a series of debates into a series of decisions.
We build the code where configuration stops
C# plugins and custom API against the Dataverse event pipeline where a pricing, approval, or validation rule cannot be expressed in configuration, and PCF controls in TypeScript and React where a standard control is not enough for the screen people live in all day. Our engineers hold Microsoft certifications including PL-200, PL-400, and PL-600, plus the module certifications MB-210 and MB-230.
We treat time entry adoption as a deliverable
Capture designed for the device consultants really use, prefilled from bookings, trained on the rhythm rather than the feature list, and a weekly compliance number published from the first week. If the timesheets are not being filled in, nothing else we built is producing value, so we would rather be measured on that than on a feature checklist.
We rehearse a full billing cycle before anyone goes live
Real time entries through approval, into a proforma, across the integration, out as an invoice, and reconciled, run by the people who will really do it. That rehearsal is what turns a go live date into a decision the leadership team can make with evidence rather than with optimism.
We build on proper solution lifecycle management
Separate development, test, and production environments, changes made in unmanaged solutions and promoted as managed ones, source control in your Azure DevOps, GitHub, or Jira, and the two Microsoft release waves a year tested before they land. What was configured is a versioned, reviewable change rather than an edit somebody made in production and forgot.
Certified engineers in one time zone
We deliver from a single hub in Yerevan, Armenia, at GMT+4, which leaves 4 to 6 hours of daily overlap with Western European hours and 6 to 8 with the UK, so workshops, standups, and training happen live rather than by email. We work on B2B contracts with NDAs, GDPR compliant data processing agreements, and IP ownership defined in the statement of work, in English, Armenian, or Russian.
The engagement models behind this, meaning a dedicated developer inside your team, a fixed scope project priced per milestone, managed support, or white label subcontracting for Microsoft partners, are on our Dynamics 365 developer and CRM consulting page.
Frequently Asked Questions
What are the key considerations when implementing Dynamics 365 Project Operations?
Six, roughly in this order. The deployment shape, because only the lite deployment runs entirely on Dataverse and stops at proforma invoicing while the heavier shapes bring in a separate finance back end and a much larger programme. The commercial models you actually sell, since contract lines and billing rules follow directly from them and configuring against demo data guarantees rework. The resource model, meaning roles, skills, calendars, and both the bill rate and the fully loaded cost rate with effective dates. Time and expense adoption, which is what every downstream number depends on and is the most common reason a rollout quietly stops delivering value. The boundary with your finance system, drawn on one page on day one rather than in a later phase. And sequencing, because the reporting layer built before capture is stable teaches the leadership team that the system lies.
How long does a Dynamics 365 Project Operations implementation take?
It depends on the deployment shape, the number of distinct contract types, whether the sales side is already clean in Dynamics 365, and how much of the finance integration is in scope, so any duration quoted without seeing the environment is guesswork and we will not put one on a page. What is predictable is where the time goes. Requirement mapping and the contract workshops take longer than people expect and save more than they cost. Configuration of planning, resourcing, and contracts is usually the most predictable part. The finance integration and the full billing rehearsal are where surprises appear. Time entry adoption is not a phase at all, it is a programme that runs from the first week to well past go live. A lite deployment for a firm with two or three contract types and one integration is a materially different piece of work from a multi entity rollout on the heavier shape, and the honest way to get a number is a scoping conversation.
Do we need the full deployment, or is the lite deployment enough?
Answer one question first: where does the statutory invoice have to be issued, and by which system, for legal and audit purposes. If the answer is an accounting package you intend to keep, the lite deployment on Dataverse plus a designed integration usually gets you the same operational outcome faster and for less, because the part of the process that genuinely needs to move is the part before the invoice: selling, planning, resourcing, capturing time, and deciding what should be billed. The heavier shape earns its cost when project accounting genuinely has to sit in the same ledger as everything else, or when finance is moving to that platform anyway as part of a wider programme, in which case it is alignment rather than extra scope. Feature comparisons are secondary to the invoice question, and moving between the two shapes later is a project rather than a switch.
How does Project Operations integrate with a finance system?
Through a boundary you design before you build. The clean design rule is that the project system owns what should be billed and the finance system owns what was billed. Approved time and expense stay on the Dataverse side with their approval trail. The proforma, once approved, crosses to finance as the source for the real invoice, carrying the contract, the period, and the lines behind it so the invoice can be explained months later. Invoice number, invoice date, and payment status come back onto the project contract so project managers see billing reality without a login to the accounting package. Build it with a service principal rather than a personal account, an idempotency key so a retry cannot produce a duplicate invoice, a retry policy, and a failure path a named person is alerted on, then reconcile on totals per period rather than by spot check. Revenue recognition is the item most often assumed rather than decided, so settle in writing which system owns it and make sure the other one does not quietly calculate a second version.
What is the biggest reason Project Operations rollouts fail?
Time and expense adoption, by a distance. Every number the platform produces, meaning utilization, margin, forecast, work in progress, and the invoice itself, is manufactured by consultants filling in a timesheet at the end of a week when they would rather be doing something else. A rollout with immaculate configuration and sixty percent compliance produces reports that are approximately true, which is worse than no reports, because partners stop opening them and the firm goes back to the spreadsheet while still paying for the platform. Treat capture as its own workstream with its own design, its own training, and a weekly compliance number published by team from the first week. The second biggest reason is configuring billing against demo data instead of against the contracts you really sign, which produces a rebuild after the first real billing run.
Should we configure Project Operations or extend Dynamics 365 Sales instead?
It is a real question and the answer is not always the module. A firm that needs project tracking, resource visibility, and margin reporting, but bills in one or two simple ways, can often get there with a well configured Dynamics 365 Customer Engagement build on Dataverse, with Power Apps for capture and Power BI for the reporting, and without the extra licence. Project Operations earns its place when the billing models are genuinely varied, when contracts mix fixed price and time and materials, when resourcing across a bench is a daily decision rather than an occasional one, and when project accounting has to be defensible rather than indicative. We would rather make that judgement with you during scoping and build the simpler thing if it fits, because it is a much cheaper conclusion to reach before the licences are signed than after.
How do we set up resourcing and utilization tracking properly?
Start with generic resource requirements on the plan rather than named people, so demand against capacity is visible across the pipeline and the resource manager fulfils from the bench instead of from memory. Keep the skill taxonomy small enough that it stays true, since a large unmaintained taxonomy produces confident searches with wrong answers. Load real resource calendars with your actual public holidays and part time patterns before anyone measures anything, because the calendar is the denominator in every utilization figure and the default calendar in a new environment matches almost nobody. Decide whether the organization schedules against bookings or against task assignments, make it a rule, and keep the other in step deliberately. Then hold both rates per role with effective dates, building the cost rate from fully loaded payroll cost, so that this year's rate change does not rewrite last year's margins.
Can Project Operations and Dynamics 365 Field Service run on the same platform?
Yes, and they share more than the platform. Both sit on Dataverse and both build on the same universal resource scheduling foundation, so a business that schedules project consultants and field engineers is working with one scheduling model rather than two separate products with two separate concepts of a resource. The practical caveats are worth knowing: the work item is different, since a project task and a work order are not the same object with the same lifecycle, and the two modules are licensed separately. Where a business genuinely does both, the shared foundation is a real argument for keeping them together rather than buying a point solution for the field half.
Who implements Dynamics 365 Project Operations for mid-market firms?
Solzet implements the Dataverse and Customer Engagement side of Project Operations from Yerevan, Armenia: project planning and templates, the resource, skill and rate model, project contracts and billing rules, time and expense capture, the reporting layer, and the integration to the finance system that issues the statutory invoice. We do not implement finance, accounting, or supply chain platforms, so where you run one we integrate with it rather than replacing it, and we say that before the contract rather than during the project. Delivery is by senior certified engineers holding PL-200, PL-400, and PL-600 along with the module certifications, at GMT+4 with 4 to 6 hours of daily overlap with Western European hours, on B2B contracts with NDAs, GDPR compliant data processing agreements, and IP ownership defined in the statement of work.
Tell us how you actually bill
Send us your contract types, how many consultants you resource, and which system issues your invoices. You will get a straight view of whether the lite deployment covers you, what the integration boundary should look like, and whether a well configured Customer Engagement build would get you there for less. Solzet is a Dynamics 365 Customer Engagement and Power Platform consultancy in Yerevan, Armenia, working with clients and Microsoft partners across Europe and the US.