De-Risking D365 Projects

Delivering successful Dynamics 365 and Power Platform projects requires more than technical capability. How effectively risk is identified, assessed, and managed plays a huge part.

All projects carry risk. The differentiator between success and failure is not the amount, but the ability to recognise and importantly manage that risk.

This article shares practical lessons from complex Dynamics 365 implementations, highlighting where risk commonly arises and how organisations can take a more disciplined, proactive approach to de‑risking delivery.

Types of Risk

To de-risk a project, we need to understand it in all its forms. Risk typically falls into four broad categories:

• Business risk — the risk that the solution fails to meet genuine business needs, deliver measurable value or even contributes to harming normal business operations.
• Technical risk — the risk of architectural failure, instability, or unmanageable complexity.
• Reputational risk — the risk of delivery failure impacting stakeholder confidence or organisational credibility.
• Commercial risk — the risk of cost overruns or contractual exposure.

Where to look for Risk

One of the benefits of Dynamics 365 and other low-code projects is that properly scoped and managed, they are inherently lower risk as the technology has already been proven to work. The development team are usually already up to speed on that technology and for common sets of requirements, it can almost be as simple as ‘Rinse and repeat’.

But there are areas that consistently produce greater risk, and these should always be carefully identified and scrutinised to avoid falling into a predictable trap.

Requirement Fit

Specifically for low-code platforms like Dynamics 365, one of the key places to look for risk is in the degree of ‘fit’ between the business needs, and the platforms capabilities.

A key guiding principle when implementing these platforms is to favour adoption over adaptation. Adoption allows the organisation to benefit from the existing feature set, whilst adaptation introduces increased complexity and maintenance overhead.

A degree of adaptation is expected and supported; however, you need to understand platforms like Dynamics 365 are not indefinitely flexible, they are bounded by their architecture. There is always the risk a requirement cannot be met, and so a comprehensive discovery to understand both functional and non-functional requirements, and their criticality to project success is important in managing risk.

Organisational Culture & Digital Maturity

One risk that is often overlooked is the culture of the organisation and their digital maturity.

When working with platforms like Dynamics 365, it’s important that the organisation is able to make compromises in order to work with the technology. There should be a clear focus on ‘what they need’ to do rather than ‘how they want’ it to happen. Working with existing features dramatically shortens development time, whilst working against them can cause increased complexity, lead time, risk and maintenance effort.

There are also other risks around the digital maturity of an organisation, for example they may limit access to tooling or services that developers rely upon.

Skills & Experience

One of the biggest challenges in implementing a low-code platform like Dynamics 365 is in understanding the underlying technology. Nowhere is this more important than in the management of a project.

Often managers experienced in software development try to manage the implementation as any other software development using methodologies developed for that purpose. The reason this is a problem is that it isn’t a software development project, it’s a product implementation.

This can manifest in many ways, for example bringing in a UX designer on to the project who sets the expectation that product should work in a specific way which is not aligned with existing functionality. It could also involve using a Business Analyst to gather green field requirements requiring a lot of custom extension work rather than a Functional Consultant who will ask leading questions to map requirements to existing functionality.

A lot of the issues stem from the fact that there are enough similarities between the two types of project to make the mistake easily, but sufficient differences that doing so can cause major problems.

Integrations

Integrations are one of the highest risk aspects of any Dynamics 365 implementation. The issue with integrations is that they inherently contain two types of complexity — what I call ‘surface’ and ‘depth’ complexity.

Surface complexity includes complexity that is visible before integration starts and can often be planned for. The number of fields, data types and mapping.

Depth complexity is where the risk lies and includes all those complexities and nuances that you can’t know until you start the integration work. These could include undocumented validation rules, legacy behaviours, poor data quality, or special characters embedded into the data.

Whilst data cleansing before integration reduces some of the unknowns, the residual uncertainty around depth complexity always makes integrations inherently risky.

External Dependencies

Requirements that depend on other projects, teams, or suppliers also carry increased risk. Parallel initiatives may be delayed, deprioritised, under‑funded, or cancelled entirely. In practice, shared integration capabilities are often among the first areas to be de-scoped when pressure mounts — particularly if they do not directly benefit the owning team.

It is important to realise that when you are dependent on a third party, your priorities are not necessarily theirs. Commercial, organisational or contractual differences can cause priorities to be mis-aligned.

Complex or Unique Requirements

Complex or unique requirements are often inherently risky as there is an unknown element to them. This introduces uncertainty into estimation, design, and delivery.

They may also require extension of a low-code platform and so instead of adopting the product, you may be forced to extend it with code. As a general principle, low-code methodology cautions against extending the platform with custom code where possible as this introduces increased risk and maintenance overhead.

Some extension is expected, but as a general principle we should aim to keep this at 20% or less of the overall feature set. Higher than this and it is worth exploring alternative platforms with a better fit, or a custom code solution.

Managing Technical Risk: Evaluate the Riskiest Assumptions First

Effective risk management begins early. A well established principle — reflected in frameworks such as the UK Government Digital Service approach — is to evaluate the riskiest assumptions first.

The objective is not to prove that everything works, but to establish quickly whether critical assumptions are invalid before significant investment has been committed.

Proofs of concept are valuable tools for reducing technical uncertainty, but they should be used with a clear understanding of their limitations.

Technical Teams Need to Look Beyond Technical Risk

One mistake I learned from is to look beyond the technical risks when trying to de-risk a project. A team may demonstrate that two systems can be technically integrated using a proof of concept which may lead them to conclude that the risk has been addressed. However, technical feasibility does not mitigate commercial, organisational, or contractual risk.

I worked with a third party to successfully integrate our system with theirs to provide our mutual customer with an integrated view of their data. Unfortunately, it turned out the third party’s system was not compliant with our mutual customer’s security policy. We identified this as part of our due diligence prior to go-live. Whilst outside our control, this created an unacceptable risk, and we were unable to go live until the third party was able to make their system compliant.

I have also experienced many cases when working with a third party that we needed to integrate with that the API’s we had been told were in development did not materialise, fell behind or were even cancelled.

In practice, integrations that appear technically sound can still be blocked due to other reasons. Projects that focus exclusively on technical risk often discover too late that the real constraints lie elsewhere.

Managing Business Value Risk: Avoid Doing the Wrong Thing Right

A particularly dangerous and often overlooked risk is delivering a technically successful solution that fails to deliver meaningful business value.

This risk can emerge gradually. Minor delays or scope reductions are accepted as reasonable compromises. Over time, these accumulate until the solution no longer supports the original business objective, despite appearing stable and complete from a technical perspective.

Without explicit value based checkpoints, projects can drift into a state where delivery continues simply because it’s part of the project plan. It’s important that these check gates are built into a project to force the team into making an honest evaluation and a conscious decision to proceed or not.

The real danger is without these check gates is teams can become desensitised to deteriorating conditions. A slow gradual loss of value rarely triggers decisive action, yet it can steadily undermine the projects value to the point that if it had happened all at once, the solution would be unacceptable.

Not providing business value can also be present from the beginning when the stated goal does not successfully address the business need. This can be identified with a thorough discovery phase.

For example, I saved a significant sum of money by not implementing a system to autonomously hasten suppliers in relation to orders that were behind schedule.

Sending the hastening emails manually was time consuming, particularly as they often did not receive a response and so needed to be repeated regularly.

During discovery, by talking to the suppliers directly, I was able to ascertain that they already knew when the order was due but did not respond to emails as they had no update to give and the request was still within their published lead times. Rather than automating a manual process which did not provide benefit, we focused on ordering with sufficient lead times that suppliers did not need to be chased.

Beware the Slowly Developing Risk

Just like the slow erosion of functionality can fail to trigger a response, risks can also develop too slowly to trigger action.

For example, sometimes critical enablers like tooling or a service are delayed for a few weeks. However, it’s not uncommon in very large organisations for that enabler to be ‘a few weeks’ away for an exceptionally long time!

This is often through competing priorities, resource scarcity and or shifting budgetary landscape. The work itself may only take a few weeks to execute but getting it prioritised can take much longer.

The real danger here is the nature of the risk. When the solution is two weeks away, the appropriate business decision is usually to accept the delay and absorb it. It wouldn’t be sensible to cancel a whole project over.

However, when those two weeks become a rolling two weeks, or a multitude of small delays occur, that approach can put a project at significant risk.

One effective approach is to define explicit, time‑bound red lines — clear exit or escalation criteria that trigger a governance review or a decision to stop or at least pause the project until there is a more permissive environment.

Cancelling a project is not failure. Continuing with no means to complete it is.

Risk Management Must Be Active, Not Administrative

A common issue across projects is confusing active risk management with risk recording.

Tools such as RAID or RADIO logs are useful when actively owned, regularly reviewed, and linked to concrete actions. Too often, however, they become static records that document risk without reducing it.

That said, disciplined documentation does matter, particularly in supplier client relationships. Recording advice given, decisions taken, and risks accepted can protect both reputational and commercial interests when outcomes are later scrutinised.

Key Takeaways

From delivery experience across Dynamics 365 projects, several principles consistently hold true:

• Risk should be identified and addressed as early as possible, particularly in integrations and dependencies.
• Technical feasibility alone does not equate to programme viability.
• Business value should be actively protected, not assumed.
• Clear red lines help prevent slow, incremental failure.
• Risk management must be continuous and deliberate, not passive.

Ultimately, successful Dynamics 365 delivery is not just technical capability, it’s about building the right solution, with a clear understanding of the risks being accepted

If you want to learn more about the Microsoft Team here at Capgemini, take a look at our open roles and consider joining the team!

De-Risking D365 Projects was originally published in Capgemini Microsoft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Original Post https://medium.com/capgemini-microsoft-team/de-risking-d365-projects-781f749b3736?source=rss—-333ebfdadb74—4