Hire Microsoft Dynamics 365 consultants

It is a common job title for one person who does both kinds of consultant work. That means workshops and configuration, plus data loads, integration settings and sometimes code. One person can manage both on a small system with a short backlog. On a larger project, the two kinds of work compete for the same days, and nobody checks the person's own design. If you want one person for both, list both sets of tasks in your role brief. Our written reply to the brief says whether we can staff both parts, and the assessment covers those tasks, not the title.

Only when someone on your side must judge the partner's designs. Your partner's architect designs within the partner's contract. Consider your own reviewer when several apps, partners or integrations meet, or when a design decision would be costly to reverse.

For one review of a proposal or a design, a consulting engagement with written findings is usually enough.

For reviews throughout the project, you need a solution architect in your team. Agree in writing how your architect and the partner raise disagreements, and who decides.

Part-time allocation is agreed per engagement, so state what you need in the role brief. Part-time suits work with natural pauses, such as design reviews before each release or test preparation before a product update. It suits daily configuration during a rollout less well, because questions wait between working days. Plan fixed working days, and name a person on your side who collects questions in between.

Most consultant work runs well remotely: workshops by video, configuration through named accounts in your environments, and test support in shared sessions. Some sessions are easier in person, such as a walk through a warehouse. If you need any on-site sessions, list them in the role brief. Whether on-site work is possible is agreed in writing per engagement, and so are the working hours that overlap with your team.

Start with the role whose output the others wait for. Requirements come before specifications, so in most workstreams a functional consultant starts first. A design question that crosses apps or systems comes before both. So an architect starts first when teams disagree about record ownership or how integrations behave. A technical consultant can start first when the requirements are approved and the work waits on environments, data loads or developer specifications. Put the order in your role brief. Each role still gets its own assessment and your interview.

It happens, for example when a configuration backlog turns out to be a design problem. Tell us early. We rewrite the role brief with you around the real gap, and the new role goes through its own assessment and your interview. Nothing written so far is lost, because the requirements and test scripts are already in your workspace. Any change of person follows the notice and replacement terms agreed in writing per engagement.

Through the hours each role needs, and the rework that a wrong choice causes. A functional consultant in a rollout joins workshops, configuration and test sessions, so the work fills many days. An architect's reviews come at decision points and often need fewer hours. Rework follows a mismatch, such as an architect doing routine configuration or a functional consultant asked to write code. MS Dynamics Guys agrees the rate basis, allocation and term in writing per engagement and publishes no rates. Microsoft licenses are not part of the price. They stay with you or your licensing partner, including any license that the consultant's named account needs in your tenant.