By Thomas White, Solution Architect, ModernOps
Partners across the Microsoft channel are moving toward fixed fee professional services, and some are setting dates when fixed fee will become their standard commercial model. That direction makes sense. Customers want greater predictability, and Microsoft’s emphasis on fixed scope and defined outcomes is clear.
But fixed fee is not simply a different way to invoice the same implementation. A partner has to understand which parts of a Business Central implementation are predictable, where uncertainty actually exists, and how much risk can reasonably be absorbed without pricing itself out of the market.
Customers like the idea of a fixed fee, but many do not demand it because it shifts other types of risk back onto them. The issue is not just price certainty. It is whether the work can be defined tightly enough for a fixed price to be fair and practical.
Requirements are often unclear at the start Many software projects begin before the customer fully understands what they need, especially around workflows, integrations, reporting, security, data migration, and user adoption. A fixed fee requires specificity, and customers may not be ready to provide it.
Vendors price in risk If a vendor accepts a fixed fee, they typically include a risk premium. The customer may end up paying more upfront than under a time-and-materials model if the project goes smoothly.
Scope disputes can become painful Fixed-fee projects can create friction over whether something is “included.” Customers may prefer a more collaborative model rather than constantly negotiating whether each request is in or out of scope.
Some implementation work is genuinely uncertain Data quality, legacy systems, custom integrations, regulatory requirements, and third-party dependencies are hard to estimate accurately. Customers may recognize that forcing a fixed fee could lead to conservative vendor behavior or reduced solution quality.
The real fixed-fee question is how much uncertainty remains
For a seasoned implementation team, not every part of a Business Central project should carry the same level of uncertainty. There is a substantial portion of a typical implementation that experienced partners perform repeatedly: standard configuration, core financial setup, project governance, common data-migration activities, testing preparation, training, cutover planning and other repeatable delivery work.
The more accurately a partner understands the actual operating cost of that repeatable work, the less contingency it has to add to the entire project. That matters because fixed-fee pricing creates a balancing problem. The partner has to account for risk, but it still has to submit a competitive price. Simply adding a large percentage to a T&M estimate is not a mature fixed-fee model. It is simply charging the customer for the partner’s uncertainty.
A partner that can predict 70 or 80 percent of the delivery model with reasonable confidence has a very different risk profile from a partner that treats the entire implementation as variable.
The question is not whether every hour can be known in advance. The question is how much of the delivery model is repeatable enough that the partner can price it with confidence, and how deliberately the remaining uncertainty is handled.
That is where experience matters. A seasoned solution architect should be able to distinguish standard, repeatable delivery work from the areas that genuinely require more caution. Standard configuration should not carry the same uncertainty as an unfamiliar third-party integration. A known conversion pattern should not be priced the same way as unprofiled legacy data. A documented standard process should not carry the same contingency as custom development whose requirements have not yet been validated.
A practical middle ground
A practical middle ground is often a hybrid model: fixed fee for discovery, configuration, training, or clearly defined milestones; time-and-materials for uncertain work such as integrations, data cleanup, or custom development; and a clear change control process for everything else.
The percentages and commercial structure will vary by partner and by project. The principle is more important than the specific model: separate work you understand well from work whose cost genuinely cannot yet be predicted.
The stronger the partner’s delivery history, standards, estimating data and solution discipline, the smaller the unknown portion of the project should become. That directly affects competitiveness.
A partner that understands its repeatable delivery cost does not have to burden every proposal with an excessive risk premium. It can price the predictable work confidently, isolate genuine uncertainty and protect margin without making the customer pay for avoidable ambiguity.
Fixed fee can work very well for Business Central implementations. We have delivered projects this way successfully for years. But the commercial model cannot compensate for weak requirements, inconsistent solution design, uncontrolled customization or poor knowledge of delivery cost.
A fixed fee does not eliminate project risk. It makes the partner responsible for understanding it.
Three questions to answer before making the commitment:
Which portions of our implementations are genuinely repeatable?
What does it actually cost us to deliver them?
Where does our historical project variance come from?
The competitive advantage will not belong to the partner willing to assume the most risk. It will belong to the partner that understands its delivery model well enough to remove as much uncertainty as possible before the project starts.
A partner can price risk. A mature partner reduces it.
Questions? Let's book some time.
Thomas White, Solution Architect, ModernOps, Thomas@modernops365.com