Dynamics 365 Projects
Are you scoping a new applications project and think Dynamics 365 could be all or part of the solution? Starting a Dynamics CRM or Dynamics 365 project can be a daunting task even for the most experienced decision maker. All your research might indicate that Dynamics 365 is a good fit for your business, but if you don’t know enough about the benefits, pitfalls and how it fits with your business, how can you be sure it is the route you really want to go down?
You might be considering some of the following points:
Undoubtedly, every Dynamics 365 project will be different. Each project’s success will be determined by a variety of factors. One of the best ways to decide on an approach is to look at types of Dynamics CRM and 365 projects that are commonplace in the industry. Since the long forgotten days of Dynamics CRM 3.0 and 4.0 to the multi-faceted platform Dynamics 365 we have now, most Dynamics professionals will have experience of working on some of, or a mix of the below types of project.
A pilot is usually an easy decision – get some proof that Dynamics 365 is a fit for your requirements before you invest a lot of time and money. A pilot may be as small getting an experienced Dynamics professional to demonstrate the functionality to the management team so they are sure how to proceed, or it may be a small production pilot for a line of business application with some custom configuration, workflows or entity modelling. Because of its no-code configurability, Dynamics 365 is ideally suited to get quick proof of concepts up and running.
Tip: Keep the scope tight. Focus on a single simple to medium complexity use case if possible. Don’t use inexperienced resources. If you do, the pilot may fail because of sub-optimal configuration or a lack of understanding of out of the box features. If the pilot is successful, consider a Minimum Viable Product (MVP) implementation next. An MVP is a product with just enough features to gather validated learning about the product and its continued development.
The Lift and Shift Project is common in public sector organisations who go are forced to go market periodically and are primarily looking to refresh their technology stack. It’s a ‘lift and shift’ because it involves lifting the existing process from their current system and shifting them to Dynamics 365. There is no intent to change or transform the business process. The old stack could be Oracle, Salesforce, Lagan, Onyx or any number of Case Management systems or bespoke applications. Ideally this type of project will involve a team of experienced Dynamics CRM consultants working with the customer to understand their current business process and map them to appropriate Dynamics functionality, training users to use the feature rich functionality that Dynamics provides.
Tip: Work with the Dynamics 365 product set, not against it. Challenge the business owners to see if the business process can be simplified or rationalised. Don’t try and replicate the old system exactly – no need for a square peg in a round hole. Because the process may have been designed as a lift and shift, you may be under time constraints to implement quickly, but there are enough feature rich function in Dynamics 365 where real value can be added without a lot of effort.
This is similar to the Lift and Shift, but is often part of a wider organisation transformation project, where there are set goals for some or all business areas to realise economies or to provide new value added functionality. It involves documenting your ‘As-Is’ processes and mapping them to ‘To-Be’ processes. This will often involve some of the value added elements of Dynamics 365 being considered well in advance. For example, Dynamics 365 Portals may be part of the solution proposed to channel shift customer contact, thus reducing costs to your department or business.
Tip: Document and Understand the high level goals of the transformation. Always keep those goals in mind when modelling new processes from old processes. Consider reporting requirements from the outset when modelling Dynamics entities. Don’t off-shore the consultancy element on transformation projects, on-site workshops with responsible business owners work best here. If you must off-shore parts of the project, do it only for discrete pieces of development work which have been demonstrated and agreed.
These types of project only work well where your business has a very strong technical and Business Analyst function.
Tip: Hire or Supplement your licence purchases with real world Dynamics Consultancy – not just classroom training. Alternatively if you already have a strong team who need to learn Dynamics 365, give them some headroom at the start of the project for familiarisation and learning.
Even the largest businesses have small teams who do their own thing. This is where Dynamics 365 may be used as the small cog in the big wheel. Dynamics CRM historically was considered by many as ‘just a sales and marketing tool’. With Dynamics 365 it has emerged as a strong platform which can be used for many line of business applications, but it is still great at Sales and Marketing functions for small teams! Your marketing team may only have 3 or 4 users, but those users probably know the nuances and functionality of Dynamics better than a lot of consultants.
Tip: Support your existing end users however small a group they are. Look at using 3rd party tools or apps such as Click Dimensions or Dynamics 365 Portals or many of the other third party tools available for quick wins. Harness the knowledge of your existing users to facilitate using 365 across other areas of your business. These users will be your best asset if you want to pilot other areas of your business.
This type of project is like the small cog, but the scope and remit has increased gradually as users see the value that Dynamics 365 provides. A Dynamics 365 implementation may have started off as a simple system to store sales and leads. These types of implementations are typically business led with little custom .NET development. After a few years, without so much as a Project Kick Off or a Tender document in place, the same system may be actively used for Sales, Marketing, Stock Taking, Correspondence tracking, Bug Reporting, Complaint Handling or many other business processes.
Tip: Assign a person or team to own the CRM system. Encourage them to attend conferences and become a Dynamics 365 Evangelist! Like the ‘small cog’ type of implementation, these product owners will be your best asset if you want to pilot the use of Dynamics 365 other areas of your business. It’s often worthwhile getting independent health checks to make sure the organic changes being made don’t steer too far away from best practice.
Historically, each major Dynamics CRM, and now Dynamics 365 release introduces new functionality, but with each release some old functionality may be deprecated. Deprecated means that you are being given notice that a feature will be removed in a future version so you should stop using it. When that feature is subsequently removed something may break. The good news is that for implementations based on CRM 2013 or later, customisations made in a supported way are less likely to cause a massive amount of rework at upgrade time.
Tip: Make sure your configuration team and developers only use supported customisation techniques. Don’t over-engineer. Schedule upgrades regularly. Dynamics 365 offers you Sandbox instances to help test upgrades, so do your testing there instead of in production.
Unfortunately complex upgrades happen – especially when upgrading from CRM 4.0 and 2011 systems to Dynamics 2013-365. This is because both the user interface and the underlying architecture has changed so much in the interim. CRM 4.0 provided a set of web services which were deprecated in CRM 2011 and finally removed in 2013.
If no thought has gone into how the system should be designed the implementation may be an example of Spaghetti Configuration.’Spaghetti Configuration’ is named as such because configuration is conceptually like a bowl of spaghetti, i.e. twisted and tangled.
Complex upgrades are more likely for a very bespoke xRM projects or systems which require more than one major upgrade. There is no direct upgrade path from CRM 4.0 to Dynamics 365 – it must be completed in stages.
If the original project was developer led and involved heavy coding or the use of unsupported techniques these will need to be identified and fixed. If your system has been heavily customised using old web services, these components may need to be completely rewritten. Thankfully complex upgrade projects are becoming less prevalent as Dynamics 365 becomes more mature. Your focus should always be on working with Dynamics 365 features instead of building your own.
Tip: Complete a test upgrade or migration as soon as possible. This will help you get a feel for scope and effort required to rectify the broken elements. Use the Microsoft provided Custom Code Validation tool which indicates known broken code and configuration. Consider replacing customised functionality with new out of the box features if the new version provides equivalent functionality. Try to upgrade regularly to major versions.
A decoupled architecture (aka “headless”) is gaining in popularity in the development world generally. With Dynamics 365 Team Member CALS being inexpensive, Dynamics is a fantastic platform for building and logical and physical data models with automatically provisioned and supported web services, report models and security. Why go to the hassle of using SQL as a data store when Dynamics 365 web services can give you so much more and abstract that complexity from you? The modern REST and ODATA based web services can be used by your own client applications as well as third party systems in the future, without you ever having to build an integration layer. If you are using Dynamics 365 Online, you also get Azure level reliability in terms of up-time.
This approach could be used by a bespoke mobile app, an integration hub or a bespoke ASP.NET application. The great thing about using Dynamics 365 in this way is that you have a ready built user interface to manage your data and reporting tools to analyse it.
Tip: Use Dynamics 365 Actions in a headless implementation to expose custom and business specific configurable web services which are easily updated with no-code configuration.
“A little bit of knowledge is a dangerous thing.”
Often poorly configured systems in production may run into performance problems because the configuration team have not been guided by best practice configuration practices. For example, if all users have System Administrator permissions, they may misconfigure workflows which mean the workflow server is sitting at 100% CPU for most of the day. If the Dynamics default solution has been used to make all configuration changes, it becomes hard to track changes and move them between environments when the need arises.
If a greenfield project is running into trouble before go-live, the earlier you bring in experienced Dynamics consultants the better.
Sometimes a rescue project can be as simple a re-configuring a few workflows. Sometimes it may involve totally refactoring the solution to meet the requirements with a more structured and thoughtful and future proof approach.
Tip: Get your implementation team trained up front to avoid it getting this far. Get some advice from experienced Dynamics 365 Consultants. Always consider potential future business requirements and build a draft road-map. If you need to get rescued, call in some experts with real world Dynamics experience, not just people who know the theory or who can step you through a training manual.
This article was originally published by Brian Illand on his own Blog on 12th January.