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, the order the whole thing has to run in, and a phase by phase implementation checklist you can work through with names against it.

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: on the Microsoft side 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, and we take on the Dataverse side of Project Operations as part of that work rather than as a separate practice. For organizations where Microsoft licensing is not the right fit, we also build custom CRM on React, Node.js, PostgreSQL, and .NET. 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.

What is the short answer on implementing Project Operations?

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.

Which Project Operations deployment shape should you decide first?

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.

What should requirement mapping capture 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.

What is 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.

What is on the Project Operations implementation checklist, phase by phase?

The sequence above explains what to do and why it runs in that order. This is the tickable version of it: five phases, every task tagged with the track it belongs to, and a condition for leaving each phase. Print it, put a name against each line, and work through it. The tracks let a resource manager, a finance lead, and whoever owns billing each find their own items without reading the whole list.

It is written against the pitfalls that actually stop these rollouts rather than against a feature list. Most of them are in the time and expense track, because a professional services automation build only produces trustworthy utilization, margin, and invoices if the timesheet is filled in accurately and on time. That is why compliance is measured in phase 1 before anything is configured, why the capture experience is usability tested in phase 4 by people who were in none of the workshops, and why the first submission in phase 5 is supported live rather than announced by email.

Phase 1. Pre-implementation discovery

Before an environment is provisioned

Nothing here is configuration, and everything here is what the configuration will be built from. A phase one that produces documents rather than opinions is the single cheapest insurance available on this kind of programme, because every item below is something that would otherwise be discovered during testing with data already sitting on top of it.

Platform. Write the deployment decision on one page, naming the system that must issue the statutory invoice for legal and audit purposes, and have the finance lead sign it before anyone provisions an environment.
Billing. List every contract type you actually sell, with its invoicing trigger, its treatment of work beyond a cap, its named approval owner, and the currency it is signed in. Pull three real signed contracts per type as the evidence.
Billing. Pick one closed engagement per contract type and keep its issued invoices in a folder. These become the acceptance tests for the billing rehearsal in phase 4, and collecting them later is much harder than collecting them now.
Resourcing. Export the current role list, name the skills that genuinely decide a staffing call, and delete every skill nobody has staffed against in the last year. A small true taxonomy beats a large stale one.
Costing. Get the fully loaded cost rate per role from finance in writing, including employer side contributions, benefits, and non billable overhead, with the date it takes effect from. Gross salary is not a cost rate and every margin figure downstream inherits the difference.
Time and expense. Document the timesheet cycle exactly as it runs today: the due day, who chases, who approves, who deputises, and what happens when the approver is on leave. You are configuring to this cycle, not replacing it in the same quarter as the system.
Time and expense. Measure current timesheet compliance by team and write the number down. Without a baseline, the post go live compliance report is an opinion, and the pitfall this phase is guarding against is exactly the one nobody can prove is happening.
Resourcing. Collect the real public holiday calendar for every country you employ in, plus part time patterns per person. The calendar is the denominator in every utilization figure, and the default calendar in a new environment matches almost nobody.
Platform. Draw the boundary with the finance system on one page, including who owns revenue recognition, and have finance sign that too. Two systems that both believe they own the invoice is the most expensive category of rework on this module.
Reporting. Write down the six to ten questions leadership asks every month, then build nothing for them yet. The questions decide which fields have to be reliable; the dashboards come after the numbers are trusted.

Do not leave this phase until: You can say, without looking anything up, which system issues the invoice, how many contract types are in scope, what the fully loaded cost rate is per role, and what timesheet compliance is by team today.

Phase 2. Core configuration

The longest phase, and the most predictable one

Build outwards from the sales side, because a project contract is fed by a quote. Every task below has a phase one document behind it, which is what turns configuration workshops into decisions rather than debates.

Platform. 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. Fix the Dataverse region and base currency at creation, because neither can be changed afterwards.
Platform. Design security roles around who may see cost rates and margin rather than around the org chart, then test them by signing in as a consultant and trying to read a colleague cost rate. Reading the role matrix is not a test.
Resourcing. Configure resource roles, the skills and proficiency levels behind them, and resource calendars loaded with the real holidays and part time patterns from phase 1. Verify by checking one person available hours for a known month against what payroll believes.
Costing. Enter the bill rate and the cost rate per role with effective dates, including at least one historic date so a past project keeps the rates it was delivered at. Test by repricing a closed project and comparing the margin to the figure finance reported at the time.
Billing. Build a project contract and contract lines for each contract type from phase 1, each with its billing method, chargeability rules, included roles and transaction classes, and the milestone schedule where the work is fixed price.
Billing. Encode the awkward chargeability cases explicitly: travel time, rework, pre sales, internal projects, and out of policy expense. Anything left to individual judgement produces inconsistent margin data that no report can repair afterwards.
Time and expense. Build the capture experience on the device consultants really use, prefilled from bookings so the weekly task is confirmation rather than data entry, with mandatory fields cut back to what the invoice genuinely needs.
Time and expense. Configure time entry, expense entry, and their approvals to the cycle documented in phase 1, with a named deputy on every approval step. Approval steps without a deputy are where billing stalls in August.
Resourcing. Turn your four or five engagement shapes into project templates with tasks, effort, dependencies, and milestones, staffed with generic resource requirements rather than named people so demand against capacity stays visible across the pipeline.
Costing. Carry cost and revenue on the estimates and set a baseline once a plan is agreed, so a project manager sees budget against actual as time is approved rather than at month end. That is the difference between renegotiating scope creep and reporting it.

Do not leave this phase until: In the test environment, a project manager can create a project from a template, book a generic role, have a consultant enter time against it on a phone, approve it, and watch it land on a proforma, with nobody from the project team sitting next to them.

Phase 3. Data migration

Runs in parallel with configuration, not after it

Migrate the least you can defend. Every row you decline to move is a row that never has to be reconciled, and the rows that matter most are the ones that make this month comparable with last year.

Platform. Agree the cut list in writing: 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.
Platform. Put an alternate key on the legacy project identifier and the legacy resource identifier before the first load, so a reload repairs records rather than duplicating them. Retrofitting this after a bad load is a bad week.
Costing. Load historic rates with their original effective dates before you load historic time. In the other order, migrated actuals get priced at this year rates and every historic margin in the new system is quietly wrong.
Time and expense. Migrate approved time in its approved state, carrying the original entry and approval dates rather than the load date, so utilization by month is comparable across the cutover instead of showing a spike in the week you migrated.
Billing. Migrate open contract balances and unbilled work in progress, then reconcile the total unbilled figure against the finance system to the currency unit before anyone signs the load off.
Resourcing. Load bookings only for the forward window you genuinely schedule against, usually the next one or two quarters. A year of speculative bookings makes the schedule board unreadable on day one.
Platform. Run at least two full rehearsal loads into test, on a clock, reconciling each time and recording how long the load took, so the cutover window is a measured number rather than an estimate somebody offered in a meeting.

Do not leave this phase until: Two rehearsal loads have reconciled on unbilled value, open contract value, and hours per person per month, and you know how many hours the real load will take.

Phase 4. Testing and the billing rehearsal

Before any go live date is confirmed

Test against reality rather than against the specification. Every item below compares the new system with something that already happened, because a test that only proves the configuration matches the design document proves nothing about whether the design was right.

Billing. Rehearse a complete billing cycle end to end: real time entries through approval, into a proforma, across the integration, out as an invoice in the finance system, then reconciled. Run it with the people who will really do it, on the day of the month they will really do it.
Billing. Re run the closed engagements collected in phase 1 through the new configuration and compare the output line by line with the invoices you actually issued. Each difference is either a configuration bug or a contract nobody could explain, and both are worth finding here.
Time and expense. Usability test the timesheet with four consultants who were in none of the workshops, on their own phones, at the end of a real week. Count the seconds and the clicks per line, because that number is what compliance will be decided by.
Time and expense. Test the approval path with the deputy rather than the approver, with a late submission, and with a week that spans two projects and a day of leave. Those three cases are where approval configurations usually break.
Costing. Verify one margin figure end to end: one project, one month, cost rate times approved hours, checked against what the report shows and against what finance calculates independently. Do this before anyone sees a dashboard.
Resourcing. Verify utilization for one person for one month against their calendar, deliberately choosing a month containing a public holiday and a part time day. A wrong calendar makes a whole quarter of utilization look plausible and be wrong.
Platform. Test the integration failure path on purpose: force a failure, confirm the alert reaches a named human, retry, and confirm the idempotency key prevented a duplicate invoice. An integration nobody has watched fail is an integration nobody has tested.
Reporting. Check that the six to ten leadership questions from phase 1 can be answered from the data as it now exists, and be honest where one of them cannot be. It is a much better conversation now than in the first month end.

Do not leave this phase until: An invoice produced by the new system for a real past engagement matches the invoice the firm actually issued, and where it does not, somebody can explain why in one sentence.

Phase 5. Go live and the first month end

Cutover week, then four to eight weeks of hypercare

Go live is not the finish line for this module, because the numbers only become real once a full billing cycle has run through the new system. Plan the first month as part of the project rather than as business as usual.

Platform. Choose the cutover date against the billing calendar, ideally at the start of a period, and specifically not in the week a quarter closes. The billing team is the one group that cannot absorb a surprise that week.
Time and expense. Run the first timesheet submission with live support on the day it is due, in the room or on a call. The first submission sets the habit, and a consultant who gets stuck once at six in the evening is slow to try again.
Time and expense. Publish compliance by team from the first week, with a named owner per team. A drop that is visible in week two is a nudge; the same drop discovered in month three is the pitfall that quietly ends the value of the whole programme.
Billing. Run the first billing cycle with the previous process still available as a fallback, and reconcile both before the invoices go out. Keep the fallback for exactly one cycle, because a fallback nobody retires becomes the real process.
Costing. The first time payroll changes after go live, add a new cost rate with an effective date rather than editing the existing row. This one habit is what keeps last year margins intact for the rest of the life of the system.
Resourcing. Review the schedule board weekly with the resource manager through the first month, because that is when the difference between a booking and a task assignment surfaces in front of real people with real conflicts.
Platform. Hypercare through at least one complete month end and one complete billing cycle, which usually means four to eight weeks rather than the two that get budgeted.
Platform. Name the internal owner of the rate model, the contract templates, and the approval chains, write down the change process for each, and put the two Microsoft release waves a year in that person calendar so updates are tested before they land.

Do not leave this phase until: One full month end and one full billing cycle have completed inside the new system, timesheet compliance is at or above the phase 1 baseline, and the rate model has an owner whose name is written down.

If you would rather run this checklist with people who have worked through it before, that is the work described on our Dynamics 365 consulting and developer page, either as a fixed scope project priced per milestone or as a dedicated developer working inside your own team and your own backlog.

When integrating with finance, which system 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.

How do you configure 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.

How should you manage 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 do 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 does Solzet deliver 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. It is the same Dataverse and Customer Engagement platform our senior engineers deliver Sales, Customer Service, and Field Service on, so nobody is learning the platform 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. If the Project Operations licence is what makes the business case fail, a professional services firm can also get resourcing, time capture, and billing preparation from a custom-built CRM with no per user Microsoft licensing, and we will tell you which route pays back.

What do buyers ask about a Project Operations implementation?

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.

Is there a Dynamics 365 Project Operations implementation checklist we can work from?

Yes, and it is on this page, organised into five phases with a condition for leaving each one. Pre-implementation discovery produces documents rather than configuration: the deployment decision, the contract types with their invoicing triggers, the fully loaded cost rate per role in writing from finance, the timesheet cycle as it runs today, the real holiday calendars, the finance boundary, and a baseline compliance number by team. Core configuration builds environments and security, the resource role, skill, calendar and rate model, the project contracts and billing rules including the awkward chargeability cases, and the capture experience itself. Data migration moves open engagements, historic rates before historic time, approved time in its approved state, and open unbilled work in progress, rehearsed twice on a clock. Testing re runs closed engagements through the new configuration and compares the result with the invoices you actually issued, and usability tests the timesheet with consultants who were in none of the workshops. Go live covers the cutover date against the billing calendar, a supported first submission, weekly compliance from week one, and hypercare through a complete month end and a complete billing cycle. Every task is tagged Platform, Resourcing, Costing, Billing, Time and expense, or Reporting so each owner can find their own lines.

What should be on a Project Operations go live checklist?

Eight things, and none of them are configuration. Choose the cutover date against the billing calendar, at the start of a period and not in the week a quarter closes. Support the first timesheet submission live on the day it is due, because the first submission sets the habit. Publish compliance by team from week one with a named owner per team, so a drop is a nudge rather than a discovery in month three. Run the first billing cycle with the previous process available as a fallback, reconcile both, and retire the fallback after exactly one cycle. The first time payroll changes, add a new cost rate with an effective date instead of editing the existing row, which is what keeps historic margins intact. Review the schedule board weekly with the resource manager through the first month, because that is when the difference between a booking and a task assignment meets real conflicts. Budget hypercare for one complete month end and one complete billing cycle, usually four to eight weeks rather than the two that get planned. And name the internal owner of the rate model, the contract templates, and the approval chains before the project team leaves.

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 takes on the Dataverse and Customer Engagement side of Project Operations from Yerevan, Armenia, as part of its wider Dynamics 365 Customer Engagement work: 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.

How does your firm 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, or a custom-built CRM without Microsoft licensing, would get you there for less. Solzet is a CRM consultancy in Yerevan, Armenia, delivering Dynamics 365, the Power Platform, and custom CRM to clients and Microsoft partners across Europe and the US. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.