As Microsoft releases more and more features, modules and wonderful goodness into the Microsoft Dynamics 365 platform it is good to build out your understanding of the maturity of each feature. The maturity defines the number of layers of updates or changes that any given feature might have experienced as well as it's depth of functionality. You can also relate this to the version of a feature; although, the version is not always the deciding factor. It is possible to have a very mature version 1.0 feature.
Why is this important? It helps to set the expectations of where the strengths and weaknesses are as you adopt the platform and extend the features. It also helps you understand and manage your expectations around what the speed of change will be with regards to a specific set of features.
Extract from the people on your team who have worked with the platform for many, many years - You need to knowledge share around the age and growth of key features. It is also important to have these conversations so you can stretch all resources into considering alternative approaches including the experienced team members. Change is not only constant in this wild world of the Microsoft Stack, but it is also speeding up.
So how do we go about understanding maturity?
As much as I would like to list every known feature in the system (I might save that for a future blog post), I think the key area to start with on each project is with a list of the features that are relevant. When working on a custom service/call center project you might not care as much about the sales automation processes or when working with an xRM or AnyRM project you might not need to be as concerned with cases and knowledge management.
So once you have a high level understanding of the areas of the platform that you want to leverage, make a quick chart of maturity. There are a few items that you want to capture as follows:
1) When was the feature released? What version (your choices include version 1.2 all the way up to version 9.1.x.xxxx)
2) Understand how the feature or area of the platform fits within the Microsoft Roadmap. Is this a feature that is waning into deprecation or is it positioned for rapid growth?
3) Acknowledge what the team knows about the strengths and weaknesses of the feature. A good brain sharing exercise.
4) Understand the feature dependencies. Take for instance, Cases - Cases have a wide set of dependent entities and functionality that goes fairly deep from SLAs to Contracts to Knowledge Base(s) and Closures.
5) Acknowledge what can and can't be configured.
6) Understand which ISVs (third party vendors) have bundled offerings that extend the features so you know your choices. Take for instance Accounts - There are numerous offerings that validate addresses and that help with extracting data on accounts from the internet. There are also numerous social engagement offerings including Microsoft's own Microsoft Social Engagement (MSE) Offering.
7) Always keep an open mind for the way that you would solve a problem on your last project is not always the same way to solve the exact same problem on your current project.
and lastly do a little deep diving into who on the product team or what group among the product team owns the feature set. This research is a key exercise for anyone attending one of the many conferences. Understanding or even meeting the product team who updates and extends features can help you better understand the vision and growth.