Using the Projects Module for ETO in D365: Projects, Planning, and Production
Today I will write about something I get asked about constantly: how to actually run engineer-to-order (ETO) work in Dynamics 365, and specifically how the Projects module ties together with planning and production. It is a fair request, because ETO is where the three areas stop being separate modules and start being one process, and the place they meet is the project.
WHY ETO IS A DIFFERENT ANIMAL
In make-to-stock or even make-to-order, the item is known, the BOM exists, and you are mostly deciding quantities and timing. ETO breaks that assumption. Each order is, to some degree, designed for the customer: the BOM and route may not exist until engineering creates them, lead times are long, the commercial deal is often fixed-price or milestone-billed, and the thing the business actually wants to track is not an item, it is a job with a budget. That last point is the key. In ETO the natural unit of control is the project, not the item, and Dynamics is built to let the project be that unit.
THE PROJECTS MODULE AS THE ETO SPINE
The Projects module (Project management and accounting) gives you the container that holds everything else. A project carries the work breakdown structure, the budget or estimate, the cost categories, the work in process (WIP), and the rules for how cost becomes revenue. For ETO you almost always want a fixed-price or an investment-style project rather than a simple time-and-material one, because you need WIP to accumulate and revenue to recognise against an estimate rather than billing costs as they land.
A few structural pieces matter from day one:
• Project contract and project. The contract holds the customer and the funding rules; the project (or project hierarchy) holds the work. One contract can carry several projects when a job has distinct phases or deliverables.
• Categories and groups. Project categories classify hours, items, and expenses; the project group ties the project to its ledger posting and WIP rules. Get these right early, because they decide whether your cost lands where finance expects it.
• Estimates and forecasts. The project forecast (hours, items, expenses, fees) is both your bid model and the baseline you will measure actuals against for the life of the job.
ITEM REQUIREMENTS: WHERE A PROJECT BECOMES DEMAND
Here is the connection most people miss. A project does not create production demand just by existing. The bridge is the item requirement. An item requirement is a project-owned line that behaves, for supply chain purposes, almost exactly like a sales order line: it represents a quantity of an item that the project needs by a date, and it is visible to master planning as demand. When you deliver against it, it generates the packing slip and the customer invoice, and the cost flows to the project.
So the modelling decision in ETO is this: the engineered end item (and any major sub-assemblies you want to track) becomes an item requirement on the project. That single act is what pulls the planning and production engines into the job. Everything downstream pegs back to it.
PLANNING: TURNING PROJECT DEMAND INTO PEGGED SUPPLY
Once the item requirement exists, master planning treats it like any other demand and explodes it. It nets against on-hand and existing supply, then proposes planned orders: planned production orders for what you make, planned purchase orders for what you buy, and planned transfers where relevant. The crucial ETO behaviour is project pegging. Planned orders created from a project-marked demand stay pegged to the project, so the supply, and later the cost of that supply, is traceable to the job rather than disappearing into general inventory.
Two planning choices deserve thought in an ETO setting. First, you can also feed the project forecast into planning, so that anticipated demand from a likely job shows up before the item requirement is firm; this helps with long-lead components you must order before engineering is finished. Second, marking and pegging discipline is what keeps project cost clean: if you let project-pegged supply get consumed by other demand, your job costing leaks. The same care I argued for in the scheduling article about not letting the schedule drift applies here to not letting the pegging drift.
PRODUCTION: EXECUTING AND CHARGING BACK TO THE PROJECT
When you firm a project-pegged planned production order, you get a normal production order, with one important difference: it is linked to the project. It still behaves like any other production order, so everything I wrote about shop floor execution and feedback still applies; routes are scheduled, material is consumed, jobs are reported. The difference is where the cost goes. Material consumption and route or job hours on a project-linked production order post as cost onto the project, building WIP there, instead of (or as well as) running through standard manufacturing variances.
This is also where ETO costing diverges from the standard-cost world I described in the costing article. For a one-off engineered item, a frozen standard cost is often meaningless, so the project becomes the costing object: you compare accumulated actual cost against the estimate, not a unit standard against a roll-up. When the production order reports as finished and the item is delivered against the item requirement, the finished good and its cost settle to the project, and the customer can be invoiced per the contract.
THE WHOLE THING END TO END
Put together, an ETO job runs like this. You win the work and create the project and contract. Engineering produces the BOM and route, often using configuration or an engineering-change process so revisions are controlled. You build the estimate and forecast. You raise an item requirement for the engineered item, which becomes demand. Master planning converts that demand into pegged planned orders. You firm them into production and purchase orders, produce the item, and post the cost back to the project as WIP. You deliver against the item requirement, invoice the customer per the contract milestones, and recognise revenue against the estimate. Throughout, the project is the one place that shows budget, committed cost, actual cost, and remaining work in a single view.
WHAT GOES WRONG, AND HOW TO AVOID IT
• Treating the item as the unit of control. Teams coming from make-to-stock try to manage ETO through items and inventory and lose the budget view. Lead with the project; let items be the demand it raises.
• Broken pegging. If project-pegged supply is allowed to satisfy other demand, job cost and availability both lie. Keep marking intact from planned order through to consumption.
• Estimate that goes stale. In ETO the estimate is a living control, not a bid you file away. Engineering changes mid-job are normal, so re-baseline the forecast when scope moves and watch estimate-versus-actual continuously, not at close.
• Wrong project type. Picking a time-and-material project when the deal is fixed-price means no meaningful WIP and revenue that lurches with cost timing. Match the project type to the commercial reality.
TAKEAWAYS
ETO in Dynamics is best understood as a project with a manufacturing engine attached, not a manufacturing order with some project notes attached. The Projects module holds the budget, the estimate, the WIP, and the billing rules; the item requirement turns the project into demand; master planning turns that demand into supply that stays pegged to the job; and project-linked production orders execute the build and charge their cost straight back to the project. Get the project type, the categories, and the pegging right, keep the estimate alive as scope changes, and the three areas behave as one process instead of three modules arguing with each other.
Next time I will look at project estimates and revenue recognition for fixed-price ETO work: building a credible forecast, posting and adjusting estimates, and how cost-to-complete drives what the customer sees.
In this series: previous article Shop Floor Execution in D365: Production Floor Execution and Job Feedback Discipline
Today I will write about something I get asked about constantly: how to actually run engineer-to-order (ETO) work in Dynamics 365, and specifically how the Projects module ties together with planning and production. It is a fair request, because ETO is where the three areas stop being separate modules and start being one process, and the place they meet is the project.
WHY ETO IS A DIFFERENT ANIMAL
In make-to-stock or even make-to-order, the item is known, the BOM exists, and you are mostly deciding quantities and timing. ETO breaks that assumption. Each order is, to some degree, designed for the customer: the BOM and route may not exist until engineering creates them, lead times are long, the commercial deal is often fixed-price or milestone-billed, and the thing the business actually wants to track is not an item, it is a job with a budget. That last point is the key. In ETO the natural unit of control is the project, not the item, and Dynamics is built to let the project be that unit.
THE PROJECTS MODULE AS THE ETO SPINE
The Projects module (Project management and accounting) gives you the container that holds everything else. A project carries the work breakdown structure, the budget or estimate, the cost categories, the work in process (WIP), and the rules for how cost becomes revenue. For ETO you almost always want a fixed-price or an investment-style project rather than a simple time-and-material one, because you need WIP to accumulate and revenue to recognise against an estimate rather than billing costs as they land.
A few structural pieces matter from day one:
• Project contract and project. The contract holds the customer and the funding rules; the project (or project hierarchy) holds the work. One contract can carry several projects when a job has distinct phases or deliverables.
• Categories and groups. Project categories classify hours, items, and expenses; the project group ties the project to its ledger posting and WIP rules. Get these right early, because they decide whether your cost lands where finance expects it.
• Estimates and forecasts. The project forecast (hours, items, expenses, fees) is both your bid model and the baseline you will measure actuals against for the life of the job.
ITEM REQUIREMENTS: WHERE A PROJECT BECOMES DEMAND
Here is the connection most people miss. A project does not create production demand just by existing. The bridge is the item requirement. An item requirement is a project-owned line that behaves, for supply chain purposes, almost exactly like a sales order line: it represents a quantity of an item that the project needs by a date, and it is visible to master planning as demand. When you deliver against it, it generates the packing slip and the customer invoice, and the cost flows to the project.
So the modelling decision in ETO is this: the engineered end item (and any major sub-assemblies you want to track) becomes an item requirement on the project. That single act is what pulls the planning and production engines into the job. Everything downstream pegs back to it.
PLANNING: TURNING PROJECT DEMAND INTO PEGGED SUPPLY
Once the item requirement exists, master planning treats it like any other demand and explodes it. It nets against on-hand and existing supply, then proposes planned orders: planned production orders for what you make, planned purchase orders for what you buy, and planned transfers where relevant. The crucial ETO behaviour is project pegging. Planned orders created from a project-marked demand stay pegged to the project, so the supply, and later the cost of that supply, is traceable to the job rather than disappearing into general inventory.
Two planning choices deserve thought in an ETO setting. First, you can also feed the project forecast into planning, so that anticipated demand from a likely job shows up before the item requirement is firm; this helps with long-lead components you must order before engineering is finished. Second, marking and pegging discipline is what keeps project cost clean: if you let project-pegged supply get consumed by other demand, your job costing leaks. The same care I argued for in the scheduling article about not letting the schedule drift applies here to not letting the pegging drift.
PRODUCTION: EXECUTING AND CHARGING BACK TO THE PROJECT
When you firm a project-pegged planned production order, you get a normal production order, with one important difference: it is linked to the project. It still behaves like any other production order, so everything I wrote about shop floor execution and feedback still applies; routes are scheduled, material is consumed, jobs are reported. The difference is where the cost goes. Material consumption and route or job hours on a project-linked production order post as cost onto the project, building WIP there, instead of (or as well as) running through standard manufacturing variances.
This is also where ETO costing diverges from the standard-cost world I described in the costing article. For a one-off engineered item, a frozen standard cost is often meaningless, so the project becomes the costing object: you compare accumulated actual cost against the estimate, not a unit standard against a roll-up. When the production order reports as finished and the item is delivered against the item requirement, the finished good and its cost settle to the project, and the customer can be invoiced per the contract.
THE WHOLE THING END TO END
Put together, an ETO job runs like this. You win the work and create the project and contract. Engineering produces the BOM and route, often using configuration or an engineering-change process so revisions are controlled. You build the estimate and forecast. You raise an item requirement for the engineered item, which becomes demand. Master planning converts that demand into pegged planned orders. You firm them into production and purchase orders, produce the item, and post the cost back to the project as WIP. You deliver against the item requirement, invoice the customer per the contract milestones, and recognise revenue against the estimate. Throughout, the project is the one place that shows budget, committed cost, actual cost, and remaining work in a single view.
WHAT GOES WRONG, AND HOW TO AVOID IT
• Treating the item as the unit of control. Teams coming from make-to-stock try to manage ETO through items and inventory and lose the budget view. Lead with the project; let items be the demand it raises.
• Broken pegging. If project-pegged supply is allowed to satisfy other demand, job cost and availability both lie. Keep marking intact from planned order through to consumption.
• Estimate that goes stale. In ETO the estimate is a living control, not a bid you file away. Engineering changes mid-job are normal, so re-baseline the forecast when scope moves and watch estimate-versus-actual continuously, not at close.
• Wrong project type. Picking a time-and-material project when the deal is fixed-price means no meaningful WIP and revenue that lurches with cost timing. Match the project type to the commercial reality.
TAKEAWAYS
ETO in Dynamics is best understood as a project with a manufacturing engine attached, not a manufacturing order with some project notes attached. The Projects module holds the budget, the estimate, the WIP, and the billing rules; the item requirement turns the project into demand; master planning turns that demand into supply that stays pegged to the job; and project-linked production orders execute the build and charge their cost straight back to the project. Get the project type, the categories, and the pegging right, keep the estimate alive as scope changes, and the three areas behave as one process instead of three modules arguing with each other.
Next time I will look at project estimates and revenue recognition for fixed-price ETO work: building a credible forecast, posting and adjusting estimates, and how cost-to-complete drives what the customer sees.
In this series: previous article Shop Floor Execution in D365: Production Floor Execution and Job Feedback Discipline
No replies yet. Be the first to respond!