Are you a consultant for a Microsoft Dynamics 365 implementation partner?
Well, if so, this blog article is for you, but even if you’re not a consultant you will still find it interesting. Chris Bell, our Senior Product Development Manager, discusses the challenges consultants face when joining a Microsoft Dynamics 365 project once it has already started, and more importantly, how to overcome those challenges.
Any implementation consultant joining mid-way through a Microsoft Dynamics 365 project can face several challenges that can hinder their progress.
A typical Dynamics 365 implementation follows a lifecycle of phases; starting with the Analysis and Design phase, where customer requirements are gathered, and the delivery team ‘solutionise’ (which for those of you that don’t know the term, means putting together a solution) those requirements. The next stage is the Build phase, where configurations and data are created, tested, and refined. Lastly, are the Deployment and Support phases, where the customer’s ‘go-live’ is prepared, executed, and monitored as they begin to use their Dynamics 365 environment for their business transactions.
However, consultants don’t always join projects at the same phase, it all depends on the individual project, the available resources, and the consultant’s existing commitments. It’s not uncommon for consultants to join a project well-after the requirements gathering has taken place. Nor is it uncommon for consultants to leave a project before the Go-Live date. These types of changeovers make it hard for consultants. They must focus on getting up to speed very quickly to meet tight deadlines, whilst also making a good impression with both the client and their own project team.
Below, I’ve listed out what I believe are some of the key challenges that consultants face (and I, personally have faced) when joining an already established Microsoft Dynamics 365 project.
Challenge 1: The ‘Dusty’ Requirements Backlog and Solution Blueprint.
When first joining a project, a consultant is often provided with a great deal of documentation to read through, to quickly understand a customer’s business, and system requirements. While these documents are often very detailed and paint a comprehensive picture of the project scope, it can often be challenging to understand how that initial scope translates into the configuration, data, and the actual system processes. It can also be challenging to understand how a project scope may have evolved over time, as, unfortunately, these types of initial documentation aren’t always kept up to date as a project progresses.
To help solve this issue, it’s essential to research beyond just the documentation initially provided. I would recommend looking at the following environments and materials. By reviewing these, it will provide a broader and more current perspective of the scope and journey that it has taken to get to a specific point in a project.
• User Acceptance Testing and GOLD Environments
By comparing the original requirements in the UAT environment to the existing configurations within the GOLD environment, you can see if/how they have evolved. You could also look at some recently created transactions in a test environment to check how the transactions were created and if they included everything you would expect.
• Azure DevOps: Structure and Bugs
Azure DevOps and Jira are tools where the majority of project and delivery management is performed, so they’re likely to be the most up-to-date sources of information. You’ll be able to check if there are any requirements within these tools that weren’t referenced in the project’s original documentation. I would even recommend checking the date the requirement work items were created and look for any outliers (rogue data points).
• Training Material
Training material created for the customer can be helpful as it will often assume that the reader has no prior knowledge of the system set-up, or business process. By familiarising yourself with the steps that end users will be performing in the system, you can use your system knowledge to begin to figure out the configuration and data behind it.
Challenge 2: The Unwritten Assumptions.
Another challenge consultants often face is that as a project progresses and gains momentum, it can often build up a backlog of unwritten, or even unnoticed assumptions along the way, such as:
“Well of course, this isn’t a consideration…”
“We don’t need to populate this field…”
“Obviously, there’s no need to include this data entity…”
These types of assumptions become second nature to people involved in a project, so much so that they may not even notice that it’s barely written down in any documentation or backlog! If you’re not naturally acclimatising to a project over time, it can be difficult to get a grasp on the unwritten assumptions.
To tackle this challenge, I would recommend that when reading up on the project or being inducted by an existing member of the project team, to not only understand what the customer does do, but what they don’t do. As much insight into a project can be gained from keeping track of what is specifically not required, as well as what is required. Next time you’re reading through the documentation take note of what isn’t mentioned. Or, when looking through the customer’s test environment, make a note of what setup is missing, or which key fields aren’t populated. While this information might not help too much in the short-term, it will be invaluable for future configuration, as it can inform the assumptions and considerations that need to be considered.
Challenge 3: Misunderstandings and Missing Information.
When joining a new project, it’s natural for there to still be outstanding configuration, development, or training required for specific areas of the system. Ideally, you will have a comprehensive handover given to you, enabling you to understand the progress made thus far, and identify the remaining tasks that need attention. Even so, when learning requirements second-hand, it’s completely normal that some details may have been missed, or not fully understood by the time you are invited on to the project. In fact, key misunderstandings or missing detail can potentially result in challenges further down the line, leading to further revisions and delays, especially as when joining a project mid-way through, a lot of the simpler problems will already have been solved!
When meeting a customer for the first time, as a consultant, your goal is to make a good impression, which can often make you reluctant to ask the so-called ‘silly questions’. However, going back to basics and taking the time to fully understand the requirement from the customer’s perspective can prove to be invaluable in the long run. For complex areas, taking some time with the customer to confirm you understand the requirement correctly will undoubtedly pay dividends in the long run. Establishing yourself as someone who listens, and genuinely cares about the customer’s needs is one of the best first impressions you can make on a project. You’ll have plenty of time to prove your system knowledge as the project progresses.
GYDE365 – a solution to all the above challenges
As a consultant working on multiple Microsoft Dynamics 365 projects at a time, finding ways to help make your job easier is a priority. Ideally, as a consultant you’re likely to need a solution to help you catch up on the status of projects and understand what is and isn’t in scope, very quickly.
Well, at Seer 365, we have the solution that consultants need to help save time and make their jobs easier. We provide a suite of applications, via our GYDE365 Platform, which help to make the discovery, analysis, design, and implementation phases of a Dynamics 365 project far more streamlined.
But, how can these specifically help consultants?
Our GYDE365-Design application reduces the time, risk and cost of Dynamics 365 projects by automating key components of the Analysis and Design phases.
GYDE365-Design provides auto-generated Solution Design documentation and a detailed functional requirements breakdown, allowing consultants to quickly understand the requirements of a project. It also prevents any confusion with those “unwritten assumptions” and avoids any information about the project being missed or misinterpreted, particularly if you are not involved right from the start.
GYDE365 gives all parties involved the confidence that everyone is using the same up-to-date information, not a mixture of disparate spreadsheets that include data that is no longer relevant, or missing information on the latest configuration of Dynamics 365.
Want to find out more about GYDE365?
Visit our website or request a demo: www.seer365.com
Written by Chris Bell
Chris Bell, our Senior Product Development Manager, has been with Seer 365 for almost two and a half years. Chris helps to continuously develop our GYDE365 platform, to meet the needs of our partners. Previously, Chris has worked as a consultant for one of the largest Microsoft Dynamics 365 implementation partners.