The 5 Principles for Implementing Successful Dynamics 365 and Power Platform Projects

I recently attended a talk at DynamicsMinds 2026 from none other than Andrew Bibby, Co-Founder of Proximo 3, where he spoke on why Dynamics 365 projects fail, and why they can be so difficult.

He opened with some alarming statistics that immediately caught my attention - mainly that around 70% of CRM projects fail to deliver real business value.

Andrew mentioning that statistic really stuck with me, and it inspired me to write this article. Partly for my own reference, partly to reflect on Andrew's teachings, and partly to add some of my own experience from the field to see if it can help anyone else.

This is meant as a reference article. Something to come back to when you're in a position where a D365 or Power Platform project isn't going the way you anticipated, and is struggling to make it over the finish line.

It covers principles I believe are timeless, with specific learnings from the Microsoft Business Applications space sprinkled throughout.

The 5 Principles of Successful D365 / Power Platform Implementations

Let me start by introducing the principles themselves. I believe they are:

• Define a North Star
• Communication Is the Key
• Ruthlessly Scrutinise Requirements
• Find the Right People
• Get Leadership Buy-In

In this article we'll work through each one in depth, what it means, why they matter, and how you can implement some of them for yourselves.

Define a North Star

In every successful D365 / Power Platform implementation I've seen, there is a defined point of success which is measurable. This is what I call a North Star.

A North Star should be discussed and agreed upon before any development work begins, as it sets the scene for a shared goal that all stakeholders can get behind.

Without one, you're wandering aimlessly through what can be a long project lifecycle, without actually knowing where you need to end up.

The North Star is the point the project's success is weighed against, and every decision along the way is weighed against it too. Sometimes you'll need to do discovery and run workshops to define it properly at the start, and that is never time wasted, but time invested.

Abraham Lincoln supposedly said "Give me six hours to chop down a tree and I will spend the first four sharpening the axe". Defining your North Star is sharpening that axe.

All stakeholders must be made aware of the North Star, and it must be measurable. Because at the end of the project, it's the North Star that decides whether the project was a success or a failure.

Communication Is the Key

This one is taken from Andrew's session, and it reframed the way I think about communication within projects as a whole. I'd always assumed communication was just what it was, and that you were limited to whatever routes leadership gave you.

If leadership didn't want the project team speaking directly to the impacted users, and instead acted as a bridge between the two, then things would inevitably get lost in translation. That was just how it went.

Andrew reframed this. Rather than vertical lines or siloed bridges where things get lost in translation, communication within these projects needs to flow both ways, between all affected project representatives.

At the simplest level, that comes down to three entities:

• Leadership
• Project Team
• Impacted Users

And all three should have some active involvement in the project, with communication flowing in every direction simultaneously, rather than being siloed.

Now to some of you this may sound like common sense, but this setup can genuinely make or break a project, for a few reasons.

Without communication channels like this, things are far more likely to get lost in translation. You would spend time and resources building things the impacted users don't find valuable at all, and the project team ends up misaligned on the North Star.

So this principle is about getting those channels set up. And don't get me wrong, it doesn't have to be explicitly documented exactly what they are. My rule of thumb is that outside of the project team - across Leadership and the Impacted Users - you want at least one main sponsor who keeps everyone aligned and focused.

Ruthlessly Scrutinise Requirements

Requirements are one of the most important pieces of the puzzle. They can be the difference between an implementation delivering value and not. Setting standards for how you capture and manage requirements is an important step, and not one to take lightly.

Requirements are multi-faceted, with a lot of different areas to consider. Capturing them is a story of its own, and it can be done in any project management tool like Jira - or, my personal preference given we're working with the Microsoft stack, Azure DevOps (which also opens the door for native ALM on your D365 and Power Platform projects). Each requirement should be defined against the stakeholder it's going to affect, and prioritised based on when it needs to get done.

I like MoSCoW for prioritisation - Must, Should, Could, and Won't. It's simple, it's standard, and it's easy for everyone on the team to get their head around.

Gathering requirements is a skill in its own right, and should be done with care. Your options include workshopping, user interviews, and discussions with leadership. One thing I'll say though - when you're gathering requirements, having at least one affected user in the process is essential. The last thing you want to do is guess what people actually want in the solution.

Now, the reason this principle is called "Ruthlessly Scrutinise Requirements" is that they should be airtight before anyone starts building against them. You don't want holes in your requirements, and you want the project team to understand and trust them completely.

Another good bit of advice is to have a senior member of the technical team enforce estimations across the requirements. This can be a bit tricky, so I always recommend giving Pessimistic, Realistic, and Optimistic estimates if you're going to do it - and those can then be broken down into smaller estimates for the individual tasks sitting under each requirement.

Being able to spend real time on requirements, and getting people who understand how to write them and ask the right questions, is so important. BAs are great at this. Requirements can be defined broadly at the beginning, or specifically per sprint if you're running agile. And if you're capturing requirements per sprint, you need to make sure the devs genuinely understand their tickets, or it'll slow the whole sprint down.

Find the Right People

Projects live and die by the people working on them. This section might come across as a little harsh to some, but success on a project largely comes down to exactly that. The Solution Architect's job to align with this principle comes down to two main things:

1. Ensure people are in the right seats.
2. If they're not, switch them or take them out of the game.

Let's cover both in a bit more detail.

Ensure People Are in the Right Seats

This is about team roles. Often on projects people need to be adaptable - for example, a Solution Architect might find themselves doing project management tasks more often than not. My advice here is to avoid that wherever you can, and make sure people are doing the work they're actually being paid to do. In that example, every hour the Solution Architect spends on project management is an hour taken away from their real area of expertise and value. More often than not, it's worth bringing in a dedicated Project Manager or BA to handle the bulk of that work.

The same goes for technical tasks, particularly around BI and Azure. In the Microsoft space there are so many tools we can reach for. Once you've defined which tools you're using in the requirements, find the right expertise for each piece of work. Don't put a Power Apps person on a Power BI deliverable, especially if it's a MUST requirement.

Of course, you have to use your intuition here. Not every project can have every person sitting in exactly the right seat - if that were the case, far more projects would succeed. But when you see team members being stretched thin, drifting away from the work they do well, that's when you invoke this principle ruthlessly.

If They're Not, Switch Them or Take Them Out of the Game

This is the part I said might come across as harsh. If there are people not pulling their weight, it's the Solution Architect's job - with leadership's support - to find out why, and to resolve it as best they can.

Individuals genuinely have the ability to kill a project, and you need to make sure that's taken care of.

Examples of this include:

• Sprint goals being missed, particularly because of one individual.
• Sprint tasks repeatedly not being completed by one individual.
• Bad blood in the team and poor communication stemming from one individual.

This can start as a friendly chat - understanding why someone's performance has drifted, and what you can do to support them.

If that can't resolve it, the person moves seats. And if that still doesn't resolve it, they're replaced.

Finding great people is one of the hardest things to do on these projects, so do execute this with caution when you're building the team to take it on.

Get Leadership Buy-In

This isn't the same as the communication principle. That one was about the flow between all relevant stakeholders, particularly the three entities. This principle is about having the backing of leadership and getting their buy-in.

If leadership doesn't support your implementation, or see it as a side-project, it will fail. Leadership are the hammer in the organisation, so to speak. They're the ones who get things moving when things stall with IT, and the ones who can share the broad organisational vision behind the project.

Now, if you're reading this, chances are leadership have already signed off on the project and committed to investing in it. But it's your job to make sure you have their full attention and buy-in. If a D365 / Power Platform implementation is treated as a "side-project", you won't get the commitment you need across the organisation to make it a success.

And when things get tough, and people need a nudge, that leadership buy-in becomes crucial.

Leadership can free up time for your important stakeholders to attend workshops, sit through interviews, and keep the flow of your project moving. You don't want to start any project without it.

Don't get me wrong - you're not going to get the entire leadership team on board. But at the very least, I'd recommend finding one sponsor who can get things moving throughout the business.

Conclusion

So those are the five principles I'd recommend coming back to:

• Define a North Star
• Communication Is the Key
• Ruthlessly Scrutinise Requirements
• Find the Right People
• Get Leadership Buy-In

You may have noticed, none of these five principles are actually about the technology.

The tooling is very rarely the thing that sinks a project. What sinks projects is the human side.

That's why I believe these principles are timeless. The tools will keep changing - the AB-series certifications, the agents, the next wave of Copilot features - but the reasons projects succeed or fail have stayed remarkably consistent.

So if you're in the middle of a project that's struggling to make it over the finish line, come back to this list. Start with the North Star, because if you can't measure what success looks like, none of the rest can save you. Then work your way down.

Get these five right, and you've already done more than most to avoid being part of that 70%.