Ask any organisation why a Dynamics 365 project ran over time or over budget, and the answer rarely points to the technology. It points to requirements that only became clear during the build, to wishes that contradicted each other without anyone noticing beforehand, or to a scope that gradually grew because no one had sharpened the original question enough.

This is precisely the gap that the business analyst role fills, and it is a role that is regularly missing in smaller and mid-sized Dynamics 365 projects — not because it is considered unimportant, but because it is often silently left to the consultant or developer, without explicit time or attention being set aside for it.

What a business analyst actually does in a Dynamics 365 project

A business analyst translates an organisation’s wishes and processes into requirements that are usable for an implementation. That sounds simpler than it is. A department head who says “we want better visibility into our sales opportunities” hasn’t formulated a requirement yet — that statement needs to be translated into concrete questions: what information is currently missing, who needs that information and when, what does success look like, and what is the difference between a reporting need and a process problem that runs deeper.

The translation to the right platform level

In the context of Dynamics 365 CE and Power Platform, this also means translating those requirements to the right level within the platform: does this belong to a modification of an existing entity, a new Power Apps application, a Power Automate flow, or actually to a process change that doesn’t require a system change at all.

The principle: That translation step prevents technology being deployed for a problem that should really have been solved at the process level, and vice versa. Not every bottleneck calls for a system change.

Why this often goes wrong in smaller projects

In larger implementations, a separate business analyst is common practice: someone who gathers and documents the requirements, independent of who builds the technology. In smaller projects, with a tighter budget and a smaller team, this role is often skipped or improvised. The consultant building the system gathers the requirements at the same time, often under time pressure and without the structure a dedicated analysis phase would offer.

The result: requirements passed on verbally that get distorted along the way, assumptions that are never made explicit and only surface at delivery, and a scope that grows the moment the client comes up with new wishes during the build that were never checked against the original requirements.

What a solid requirements analysis actually delivers

A thorough analysis phase delivers a number of tangible results. A clear requirements document that serves as a reference point during the build and at delivery — not to tick boxes bureaucratically, but to be able to have scope discussions based on a documented starting point instead of a retrospective recollection. A prioritisation of wishes, so it’s clear what is a must-have for the first release and what can be a later extension. And early signalling of requirements that contradict each other, before that contradiction becomes visible halfway through the build and leads to rework anyway.

The licensing and architecture component

For Dynamics 365 and Power Platform projects, this also has a direct licensing and architecture component: a requirement that actually calls for a standalone Power Apps application instead of an extension within D365 CE itself has consequences for who needs which licence.

Sooner rather than later: That trade-off is best made early, not after the build has already started. Revisiting an architecture choice afterwards costs considerably more time — and often licensing costs too — than when it was thought through properly from the start.

Why this role pairs well with technical expertise

A business analyst who doesn’t know the underlying technology runs the risk of drafting requirements that are functionally logical but technically unfeasible or unnecessarily expensive to build. A business analyst who does know the technology can already think along about feasibility and approach while gathering requirements, without letting the analysis phase get bogged down in a premature technical discussion.

This is one of the reasons I often fulfil this role myself alongside the technical role in a project: not as a replacement for a dedicated analysis phase, but as a way of keeping the distance between what an organisation needs and what gets technically delivered as small as possible.

“Most rework discussions aren’t about who made a mistake, but about an assumption that was never spoken out loud. A good analysis phase surfaces those assumptions before they become expensive.”

What sets a structured analysis phase apart

A project that starts with a thorough requirements analysis has the following characteristics:

  • Requirements are documented — Not as scattered notes, but as a document that is referred back to during the build.
  • Priorities are explicit — Everyone knows what is a must-have for the first release and what can follow later.
  • Contradictions surface early — Conflicting wishes come to light before the build, not after.
  • Technology and process are assessed separately — A wish is only translated into a system change once that is genuinely the right solution.
  • Scope is a reference point — New wishes during the build are checked against what was agreed, not silently added.

A project without this phase can run perfectly well — until the first conflicting wish, unspoken assumption, or scope change presents itself halfway through the build.

When should you bring in help for this?

For organisations considering a Dynamics 365 or Power Platform project and noticing that their own requirements aren’t yet sharp enough to hand over to a build team, a targeted analysis phase upfront is an investment that almost always pays for itself in less rework and fewer scope discussions later.

This doesn’t only apply at the start of a new project. For a project that is already underway, where the requirements have gradually become unclear, it also helps to take a step back and sharpen the original question again before building further on a shaky foundation.

Conclusion

A Dynamics 365 or Power Platform project doesn’t only stand or fall with the technology that gets delivered, but with the question of whether that technology solves the right problem. A business analyst who understands both the organisation and the platform isn’t an extra layer of bureaucracy — it’s the step that prevents a project from becoming more expensive, longer, and more frustrating than necessary.

It’s work that is barely visible upfront, but that makes the difference during the build and at delivery between a smooth project and one full of scope discussions and rework.

Are your requirements sharp enough to build on?

I offer a focused requirements analysis as a standalone step, also independent of a follow-up assignment for the implementation itself. Let’s take a no-obligation look at where your project stands.

Request a no-obligation consultation →