Dynamics 365 Implementation Project Plan Template

While there’s no official consensus on the exact percentage, experts agree that more than half of all ERP implementations end in failure.

McKinsey estimates around 70% fail, while Gartner gives a range–between 55% and 75%. If you’re looking for more tangible flops, you can check out CIO’s list of 16 famous ERP failures.

We’re not trying to scare you. It’s just that it’s important to understand how hard it is to pull off any ERP implementation.

Developing a project plan is a complicated process involving multiple stages, moving parts, and large, cross-functional teams that might not be ready for change. You’re also dealing with tons of data, deciding which integrations/processes are worth keeping—or need to be replaced. It’s a lot.

While every implementation is different, we’ve compiled a checklist outlining key activities at each stage. You might use this as your D365 implementation project plan template—and adapt around your organization’s unique needs and pain points.

Read on to learn more about what the ERP implementation process should entail.

Define Goals & Success Criteria

The first step in your Microsoft D365 implementation project plan is defining your goals and how you’ll measure success.

“Define what success looks like: Make sure the goal can be measured and think about this goal when doing requirements. Think about the future and not just what you are currently doing. Identify bottlenecks in your processes.” – Nick DiAngelo, Senior Consultant

Questions to answer:

• What do you hope to gain from this project?
• What are your most immediate short-term goals?
• What are your long-term goals?
• What’s your timeline for achieving them?
• What will it take to make it happen?
• Who needs to be involved?
• How much will implementation cost?
• How long will it take?

Gather Business Requirements

Sreenath Reddy Girigari, Directory of Delivery, “requirements gathering is crucial to any Microsoft D365 implementation project plan. It adds value every step of the way. And, when you’re working on tight timelines and a limited budget, exact documentation of all requirements becomes even more critical.”

Carrie Gabris, Consulting Mgr BC Enterprise, emphasizes that it’s important to understand the difference between business and configuration requirements.

“Discuss business requirements. Do not discuss configuration questions for Business Central setup. Business Requirements are the NEED, BC is the tool. Bottom line: configuration questions are needed to set up the tool, they’re not to be confused with “requirements.” – Carrie Gabris, Consulting Manager, BC Enterprise

You might host workshops with each department to learn about pain points and challenges, as well as how people actually use existing tools.

Questions to answer:

• What systems are you currently using for Sales, Marketing, HR, Finance, Supply Chain, Operations, Business Intelligence?
• How old are those systems?
• What challenges does each team face? Bad data? Lack of access? Missed revenue opportunities?
• What kind of infrastructure are you working with?
• Are there proprietary systems in place that are hard to upgrade/support/integrate with new solutions?
• What legal & regulatory requirements are you responsible for?
• Do you need to support inventory management? A complex quote-to-cash cycle?
• Are you operating in multiple locations? Warehouses? Countries?
• Are you dealing in multiple currencies?
• Do you need your system to handle different billing/pricing models?

“Make sure you have a group of people working together internally to review functional design documents. Make sure you all log into the system together and walk through some processes. Watch online demos available that show the UI in action. Ask your implementation partner about integrating with Office 365 and the Power Platform and see if you can get demos for your use case.” – Sam Miller, Account Executive

Review Current System & Evaluate New Capabilities

Carrie Gabris warns against trying to replicate old processes in a new environment.

She says, “be sure it doesn’t become a lift, move, and drop situation. You’re not attempting to implement your current solution into Dynamics 365. It must be deconstructed to be reconstructed in an improved solution.”

You’ll want to ask the right questions when defining the customization.

Your goal here is uncovering as much information as you can about current processes–in context with real users.

Try to answer the following questions:

• Which departments are impacted?
• Which fields are impacted?
• What are all the requirements of the field and field type?
• Is the customization specific to a certain group of users?
• What barriers prevent employees from achieving goals?
• Where are they wasting the most time?
• What information are they missing?
• Identify new capabilities offered by D365—divide them into two groups: must-haves and nice-to-haves.
• Also, ID features you can remove. That way you’re starting with a new system that only contains the features/functions relevant to your business. You can add/modify them later.
• Do the results/outcomes of the customized transactions need to be reversible?
• Does custom functionality need the ability to be enabled or disabled? Without asking these questions and accounting for all of this then that scenario, the custom code will have bugs.

Anthony Dossier, Client Success – BC Support Engineer adds, “one of the biggest mistakes clients make is not adding hover-text to the custom fields.” This defines the purpose and function of new fields and explains their impact on other fields and data.

Change Management

Modernizing your ERP is as much a cultural transformation as it is a technological one.

Companies need to dedicate the appropriate amount of time and resources to preparing their entire organization ahead of time.

Carrie Gabris emphasizes that key users must be involved throughout the entire process–starting at the very beginning. For reference, key users are your internal subject matter experts (SMEs), champions, and power users driving adoption across the organization.

She says, “throughout the execution, they should be showing glimpses to their team members, and discussing functionality hits and misses. The biggest issue for end-users is fear of not knowing what’s being constructed and wondering if they are going to be able to manage the change.”

A Few Things to Keep in Mind at This Stage:

• Functionality and usage should not be “new” to end-users during training
• Key users should do end-to-end testing
• They should document & screenshot processes
• They should capture relevant data
• Business rules must be created & communicated
• Train-the-trainer… most cost effective and forces full ownership of the solution.

Carrie adds that, “key users can serve as ongoing support before support issues are escalated to a partner… saving time and money in the long-term.”

You need at least one “power user” that understands processes across the entire business–beyond their own functional area. This is essential for making sure you get the big picture view.

Functional users play an important role, too. This group knows the ins and outs of specific processes because they use them every day. They’re in the best position to identify bottlenecks and barriers–and provide valuable feedback for how to improve.

Finally, you’ll need a project champion to lead the charge.

This person has strong project management skills and is prepared to guide the implementation process and keep everyone on track and aligned around the same goals.

Design & Development

As you’re planning the design and development stages of D365 implementation, you’ll want to make sure you focus on must-haves first (essentials you’ll need on go-live day).

Your “nice-to-haves” might change post-launch after you’ve spent more time in the system.

Make sure to use data from your test case results, gap analysis, and sessions with each department to design the new system and map processes. While the focus shifts toward identifying customizations, data, and integrations, it’s important to keep end-user feedback top of mind.

This will inform what data you’ll migrate, which processes to keep, and which ones you’ll replace using the new functionality.

Here, You’ll Want to Answer the Following Questions:

• Are you starting from an on-prem or cloud solution? What version?
• Do you have any existing customizations or ISV solutions?
• Are integrations to other systems required? If so, how will you interface with the external systems?
• What data needs to be integrated? What directions? How often?
• Does any data need to be migrated from a legacy system to D365 BC for this development to work properly?
• What automation is needed? (data in, data out, posting)
• Is data transformation needed? (what is provided to D365 BC need to be evaluated and then changed to a valid D365 BC date element)
• How many reports (Sales invoices, Purchase Order Documents, Check requirements, WIP reports, project status or management report) are required for the organizations that may be complex?
• Will simply adding a logo to a simple format work?
• Do you have required notifications/workflows that you heavily rely upon?
• Are new fields/tables required? Describe what you understand the prospect will need.
• Who needs to see the fields?
• Are the new fields/tables editable?
• Where do they need to see the fields? i.e. setup screen, customer ledger, General Ledger
• What reports are required?
• What tool will be used to create and generate the reports?
• What are the current business applications in your environment and is there integration between those systems?
• What technology is used for those integrations?
• How many integrations need to be built?
• Does the integration need to update extension tables and fields?
• How fields might need to be updated/imported?
• What is the source of the data? (Concur, ADP, External operating system)
• Where does the data need to be imported? (GL, AP, Inventory)
• Does the integration need to return data to the source system?
• Does the integration need to create or update master records? Which ones?
• Does the integration need to transform any data? (Source Item number to BC item number?)
• What level of automation is required? Immediate and automatic? (API’s?) Scheduled and Automatic (Containers)? Manual and as needed?

Testing & User Training

Anthony Dossier advises clients to use “real data-based training that accounts for most common scenarios across all systems, departments, and processes.”

You’ll need to develop well-documented step-by-step, click-by-click standard operating procedures, complete with screenshots and details of all fields and steps involved.

“In general, get engaged, watch videos, read training manuals, understand the table/field structures and the system architecture, learn the terminology of the new system, learn where data flows from and where it flows to.” – Anthony Dossier, BC Support Engineer

• Develop a training plan—should include hands-on live sessions, self-guided lessons/tutorials, and a plan for developing skills long-term
• User acceptance testing (UAT)
• Cutover phase—typically lasts a few days & allows orgs to start working with the new system before retiring the old one—in case they hit any unexpected snags.
• Gives clients time to run through day-to-day tasks and address issues, while also maintaining business continuity.
• Activities might include running sales reports, processing orders, bank reconciliation, etc.

Nick DiAngelo says, “issues often come from clients not testing all of their scenarios. Take the time to develop test scripts and ensure they are complete before cutover.”

Anthony weighs in again stating, “when scenarios and critical processes go untested, users don’t know how to use the system at go-live. To avoid this issue, make learning the system and completing UAT the top priorities, instead of focusing too much on go-live deadlines.”

Make Sure You:

• Track testing scenarios
• Provide detailed steps if an error occurs. Include what the expected result was and the actual result.
• Hold people to a timeline–UAT usually runs over if there’s no project sponsor or manager keeping the team on track.

Deployment

Don’t force the go live if you’re not fully ready to hit some target deadline. That’s focusing on the wrong objective.

“Ensure all artifacts and necessary configurations are in place during deployment. Additionally, maintaining a proper deployment checklist that covers every detail that must be in place before the go-live.” – Sreenath Reddy Girigari, Director of Delivery

Before Moving Forward, Make Sure That:

• Adequate unit testing was performed by enough users
• Documents were fully tested/reviewed during testing. Some might be missing necessary information.
• Reporting was fully addressed. In other words, you’ve proven that reports address specific questions and make it easy for users to understand the situation and take the appropriate actions.

Post Go-Live

After you’ve launched the new system and completed the cutover, you’ll need a strategy for managing and improving the system long-term.

A few things to work into your ongoing plan:

• Create a system for ongoing testing, regular reliability & network performance checks
• Establish & document communication protocols for unexpected downtime
• Make sure you have strong (and redundant) data backup processes
• Make room in the budget for overtime/temp staff to support teams as they learn to work in a new system

Final Thoughts

Carrie Gabris has one final piece of advice. She tells clients to “be open to change. The requirements you currently have in place may be a result of your current system’s limitations. You’ll need to be open to process changes in order to utilize D365 best practices to improve business outcomes.”

Your Microsoft Dynamics 365 implementation project plan is a massive undertaking. It involves a lot of time, teamwork, and a ton of in-depth cross-functional planning.

What’s more, many orgs don’t have experience with D365 implementations. And some have little to no experience with the cloud, in general. Even those companies that consider themselves experienced cloud users might struggle with the more technical aspects of implementation. Think–mapping business processes, preparing data, converting custom code.

Working with a solution provider increases chances of success. You’ll work with experts who’ve been through it before, understand the risks, benefits, and how to get the most from your D365 investment.

Ready to get started on your D365 implementation project plan, reach out to us today.