Updated recently
Last updated:
Quick Answer: This dynamics 365 project operations guide explains the product as a delivery, time-capture and billing system rather than a planning tool. It covers project and portfolio setup, the work breakdown structure, resource management and capacity, time entry templates, expense reporting, project invoicing, and the hand-off into Dynamics 365 Finance where the actual project accounting lives. If you are new to the wider suite, start with our Dynamics 365 complete guide first.
Dynamics 365 Project Operations Guide: What the Product Actually Covers
Project Operations grew out of “Project for the Web” and sits on the Power Platform data model, which means the project data is reachable from Power Apps, Power Automate and Power BI — that is the single most important structural fact about the product, and it is where most of the consulting value now sits.
| Area | What it does | What it does not do |
|---|---|---|
| Project and portfolio management | Projects, work breakdown structures, project tasks and milestones, templates, teams and role assignments, portfolio views across a book of work | It is not a critical-path scheduling engine; complex dependency-driven scheduling still lives in tools like P6 |
| Resource management | Resources, capacity, skills, calendars and shifts, resource requirements, bookings against project work, and resource team structures for bench or staff augmentation | It does not replace a workforce management system for shift-based operations |
| Time and expense | Time entry templates, time entries, timesheet approval, expense reports with categories and attachments | Payroll is not in scope — hours feed billing and costing, not payslips |
| Billing | Project invoices generated from billable time and expenses, invoice books, billing rules, and the customer/account that receives the invoice | Collections, credit control and statutory e-invoicing compliance live in Finance |
| Procurement | Purchasing requests and orders raised against project costs, for project-specific purchasing | Full procurement and supplier management is a Finance function |
| Reporting | Power BI content over the project tables, plus out-of-the-box operational views for delivery managers | Advanced financial and utilisation analytics usually need a purpose-built model |
Read the third column carefully. It is where scoping conversations go wrong, and it is why a good consultant can run a smaller, faster project than a bad one. The pay bands behind these roles are in the Dynamics 365 Project Operations salary guide.
The Project Model: Project, WBS and Task
Everything hangs off the project. Inside a project sits the work breakdown structure — a hierarchy of activities, some marked as summary tasks that roll up the ones beneath them, others as leaf activities that carry the work. In parallel sits the project task layer, which is where start and end dates, dependencies and assigned resources live, and which is what the scheduling views read.
Conceptual illustration — Dynamics 365 Project Operations data model
(not a UI script)
Project: PRJ-2026-041 "Core banking migration" customer: a private bank
WBS: 1.0 Delivery
1.1 Discovery summary task
1.1.1 Requirements leaf activity
1.1.2 Design leaf activity
1.2 Build
1.3 Data migration
Project task: 1.2 Build, start 01-Jul-2026, end 30-Sep-2026,
depends on 1.1 Design
Team: delivery pod A — 8 members, 5 FTE effective capacity
Resource: RES-204 Anil K role: senior developer
capacity 8h/day, 5 days/week, calendar = standard
Time template: "Consulting daily"
default role: senior developer, billing category: billable
Time entry: 12-Jun RES-204 -> WBS 1.2, 7.5h, billable
Expense: 12-Jun RES-204 -> travel, category: travel, INR 1,850
Invoice: generated from approved billable time + expenses, currency INR
Two modelling decisions decide whether the implementation survives. First, the WBS versus the project task distinction. The WBS is a structure of work; the project task is the scheduled, resourced, date-bound view. Teams that try to model everything in one of the two end up with either a beautiful WBS and no schedule, or a schedule with no cost structure. Second, the billing category on the time entry template. This is a small field with an enormous financial consequence, and we will come back to it, because it is where the real war stories live.
Resource Management: Capacity, Requirements and the Staff Augmentation Model
Resource management is the area that most distinguishes a Project Operations implementation from a generic task list, and in India it is usually the business driver.
The core objects are resources (a person, with a role, a calendar, a capacity expressed in hours per day or week, skills, and optionally shifts), resource requirements (a stated need for a skill or role on a project for a period, which is how a demand plan is captured), and resource bookings (the assignment of a resource to a project activity for a window of time). Add resource teams — named pools such as “SAP practice” or “Data engineering bench” — and you have the classic IT services model where a pool of people is managed, allocated to projects, and billed from the hours recorded.
Here is the honest engineering caveat that catches people out: in the standard configuration, Project Operations records an overallocated booking rather than refusing it. If you book a lead consultant at 100% on three overlapping projects, the system accepts it and the capacity view shows the overload. That is a deliberate design choice — hard blocks frustrate planners who need to model a “soft” commitment — but it means the data discipline that prevents a 300%-utilised delivery manager is your responsibility, not the application’s. Either you configure a validation that raises a warning on overallocation, or you build a utilisation report that surfaces it weekly. The firms that get this right treat utilisation as a managed metric with an owner; the ones that get it wrong discover the problem at month-end billing.
Scheduling views, resource calendars and the demand-versus-capacity picture are where Power BI earns its place: a delivery manager does not live in the transaction screens, they live in a utilisation and pipeline view refreshed daily.
Time Entry, Expenses and Where the Money Leaks
Time capture is deceptively simple and commercially sensitive. A time entry template defines the defaults: the project, the role, the activity or project task, the unit of measure, and critically the billing category — whether the hour is billable, non-billable, overhead, or whatever your rate card says. A time entry is what an individual records against a resource and an activity, usually for a date range, and it then goes through a timesheet approval flow before it can be billed.
Expenses follow the same shape: an expense report carrying one or more expense lines with a category, a date and an amount, submitted and approved alongside timesheets.
Where the money leaks is almost always in the template defaults and in what the submitter is allowed to choose. The three failure modes worth knowing before you build anything:
- A missing billing category on the template, so everything defaults to billable — including internal training and transition-project effort.
- An open project task list on the timesheet form, so people book hours against the wrong activity, and the invoice line allocation is wrong even though the total hours are right.
- No pre-billing reconciliation, so the invoice goes out before anyone compares expected versus actual billable hours per project. The first time you catch a material variance is when the CFO asks.
Each of those is a design decision, and each was learned the expensive way by somebody. None of them are visible in a demo environment, which is exactly why demo-led implementations leak margin in month one.
Billing and the Finance Hand-Off
Project Operations can generate project invoices itself, from approved billable time and expenses, and it can maintain invoice books that control numbering and defaults. But the accounting consequence of a project — cost, WBS-level actuals, revenue recognition, collections, statutory reporting — happens in Dynamics 365 Finance, in its project management and cost accounting capabilities.
The integration has a recognisable shape. Time and expense data from Project Operations needs to reach Finance as cost transactions against the correct project and WBS, so that the project’s actual cost and earned revenue can be computed. A project in Project Operations typically has a corresponding project in Finance, and the mapping between them is configuration and data work, not magic. Where the two are not mapped, the client gets billed correctly but the project margin is never reported — a very common and very expensive mistake in Indian implementations, because the delivery team works from Project Operations and finance works from Finance, and neither is looking at the other.
Getting this hand-off right is the difference between a configuration consultant and a delivery solutions architect, and it is the single most valuable thing a Project Operations consultant can know.
What Actually Happens at Work: The Schedule Board That Nobody Trusted
An engineering and infrastructure services firm with about 1,600 employees deployed Project Operations to give its PMO a live view of 70 concurrent projects. The rollout went well technically. Six months later, the PMO head quietly stopped using the schedule view and went back to a weekly spreadsheet, and the project sponsor asked why the new system was “always a week behind reality”.
Three causes, all of them structural. First, the schedule was never the source of truth — the delivery teams still updated their own spreadsheets, because entering dates into a second system was not in anyone’s contract. The Project Operations schedule was therefore a mirror of a mirror. Second, bookings did not reflect reality: the resource booking model captured who was assigned, but a delivery manager routinely swapped an engineer for two weeks to cover an escalation without touching the booking, so the resource view showed people available who were actually on site. Third, and this is the part that broke trust, the utilisation data was wrong in a way nobody could see. Time was being booked to a generic “internal” project for chargeable rework and support work, so those hours never appeared against the delivery project. The PMO’s “available hours” figure was therefore overstated by roughly 30%, and when the schedule was compared against actual effort, every project looked over-budget and nobody believed it.
The recovery was unglamorous and effective. They cut the scope of the schedule view to one honest question — “who is committed to what, in which week” — and rebuilt bookings to be the single input, with a rule that a resource change updates the booking or the plan is wrong. They removed “internal” as a catch-all project and replaced it with explicit chargeable and non-chargeable categories, which fixed the utilisation numbers. And they stopped asking the schedule to predict completion dates, because a task-based system fed manually cannot. Six months later the PMO was using it daily, and the honest summary was that the tool had been sold as a project management system when what the business actually needed was a resource and billing truth source.
The transferable lesson: in Project Operations, trust comes from the data that money depends on — time, bookings, billing categories — not from the schedule view. Build that first.
Training Resources
Project Operations delivery runs on the Power Platform, and the build skills — model-driven apps, Dataverse, Power Automate, Power BI — are where the market pays. Get them with SkilBrill Power Platform Functional Consultant Training, which includes labs on Dynamics 365 Project Operations scenarios such as time entry templates, resource capacity dashboards and project billing reconciliation. If you are also chasing a credential, our Dynamics 365 Project Operations certification path guide explains what actually exists.
FAQ
What is Dynamics 365 Project Operations used for?
It is an operational delivery, time-capture and project-billing system: projects and work breakdown structures, resource management and capacity, time and expense, and project invoicing, with the accounting hand-off into Dynamics 365 Finance. It is not a detailed critical-path scheduling engine.
What is the difference between a WBS and a project task in Project Operations?
The work breakdown structure is the hierarchy of work and where cost and effort are structured; the project task carries the schedule — dates, dependencies and assigned resources. Teams that try to hold both in one object end up with either no schedule or no cost structure.
Does Dynamics 365 Project Operations include payroll or accounting?
No. Payroll is out of scope, and the project accounting — cost categories, WBS-level cost transactions, revenue recognition, collections — happens in Dynamics 365 Finance through a mapped project structure. That integration is the most important part of the implementation.
How does resource scheduling work in Project Operations?
Resources carry a role, calendar, capacity, skills and shifts. Resource requirements capture demand, and bookings place a resource against project work for a period. In the standard configuration an overallocated booking is recorded and reported rather than blocked, so overallocation discipline is the customer’s responsibility.
Is Dynamics 365 Project Operations easy to learn?
The concepts are approachable if you understand project delivery. The difficulty is the data model and the Finance integration — and both are valuable, transferable skills that pay beyond this product.
