A technical enquiry becomes a cost estimate, a contract and a delivery project. Each stage introduces decisions that the next team needs: assumptions, exclusions, deliverables, payment terms and later variations.
When these are re-entered independently, the business can have several reasonable-looking versions of the same engagement. A connected platform needs to preserve the agreement between commercial and delivery teams, as well as the records inside each function.
Define which records represent the engagement.
An enquiry, a contract and a project are related records with different responsibilities. Keep their identities and relationships explicit. One contract may support several delivery activities; the software should reflect the actual business arrangement.
Project-operation platforms span these functions. Microsoft describes a connected scope across sales, resourcing, project management and finance in its Project Operations documentation. The architectural question for a custom application is which records and decisions must cross those boundaries.
Start with the handovers that currently require reconciliation. Ask which enquiry revision was priced, which scope was contracted and which project is delivering it. A shared project number alone will not answer all three.
Reference: Microsoft — Dynamics 365 Project Operations overview
Carry decisions through the handovers.
Give each handover a defined source, a destination and an accountable owner. Preserve the approved version while allowing the receiving team to add the information it owns.
- 01Commercial
The enquiry, agreed scope and contractual record.
- 02Delivery
Project tasks, team time, expenses and accepted changes.
- 03Finance
Approval status, billing basis and issued invoices.
Scroll horizontally to read all columns.
| Handover | Information to preserve | Receiving team’s decision |
|---|---|---|
| Enquiry to estimate | Scope revision, assumptions, exclusions and requested deliverables. | What to price and which questions remain open. |
| Estimate to contract | Accepted commercial basis, agreed scope and payment terms. | Which agreement governs the engagement. |
| Contract to project | Deliverables, responsibilities, milestones and agreed variations. | How delivery is planned and who owns the work. |
| Delivery to invoicing | Relevant contract terms, approved milestones or billable records. | What is ready for commercial review and invoicing. |
Treat a variation as a decision with a history.
A scope change can affect delivery effort, dates and commercial terms. Record the proposed change, its status, the affected work and the approval required. Distinguish an internal estimate from an accepted contractual variation.
Keep the earlier agreement available after a change is accepted. Teams need to understand what moved and why. The record should also make it possible to find delivery work performed while a commercial question was still unresolved.
This is where a connected application earns its place. It can put the relevant variation, project task, time entry and contract reference within reach without assuming that changing one field automatically approves the rest.
Build reporting from records people maintain.
Define the source and meaning of each management view. A task marked complete, an approved timesheet and an invoice issued are different events. Make the reporting cut-off and approval status visible so readers know what the numbers represent.
Paradigm brings enquiries, contracts, project work, timesheets, expenses and reporting into one application scope. A management view should link back to those records and show their approval status, with the underlying relationships and handovers made explicit.
For a first release, demonstrate one enquiry moving through the agreed records, including a changed scope and an incomplete handover. That exercise tests the connections between departments before the team invests in additional reporting views.
- Name the owner and source of each business record.
- Preserve approved scope and commercial revisions.
- Connect variations to the delivery work they affect.
- Explain the status and cut-off behind a management view.
Reference: Paradigm — enterprise operations software
Sources & further reading
The handover model is Gray Foundry’s design perspective. Microsoft provides a published example of the connected project-operations scope; Paradigm is the application reference for the modules described here.
