Your have surely heard about Sturgeon’s law that “90% of everything is crap”. Dynamics 365 is one of the most comprehensive and feature rich business application in the marked and trying to learn or use all the features would be lifelong study effort beyond the capacity of any person. I can say with 100% certainty that nobody in the world deeply knows about all the available features and functions. When implementing Dynamics 365 at a customer, we often see that only a fraction (10%?) of the available features is being implemented. Does this mean that 90% of what we have in Dynamics 365 is “crap”?

The definition of “crap” is subjective and sometimes controversial, so it’s not always obvious whether something should be viewed as “crap”. But for one person involved and looking at the entirety it could get this impression. The other element is that “crap” is a retrospective experience. You don’t know if something is “crap” unless you understand what is not “crap”. Like Thomas Edison had to evaluate 10.000 prototypes for a lightbulb before he cracked the solution(myth). Did he have 9999 crap’s and one success?

To identify the “crap”, there are one VERY important activity in any implementation that becomes a critical prerequisite to succeed within a constrained availability of resources (time, money, people).

Scoping!

I wanted to share with you some of my best practices on how to address scoping on a very early stage in an implementation project, to identify more quickly what to spend time and focus on. For this there are 3 major pillars of focus in any implementation project: Processes and Responsibilities, People and Planning, Systems and Data

When we are running projects, we therefore always start with a discovery phase where we try to find the right direction and what the implementation project should focus on. The main deliverables are a Project Blueprint/SOW, Process Scope Definition and a Draft Solution Design. This allows the main project to be focused on the 3 pillars from a strategic perspective. Too often I have seen projects jumping into actions and details too early, and skipped scoping (aka “Cut the crap”)

Processes and responsibilities

Doing things in a new way with some degree of business process reengineering can have a positive effect on organization. New cloud technology and new ways of handling responsibilities are key enablers. At inspirit365 we have a process library that consists of 850 processes that is organized into 3 levels and are End-to-End focused. The processes describe responsibilities and are tailored towards how out-of-the-box Dynamics 365 functionality and features are supporting the most common processes. The Level 1 and level 2 processes are for classification, while level 3 is how to perform the processes in the system. As the processes organized around standard features there is a very good way of understanding the end-to-end flow.

To ensure we end up with a relevant list of processes we are running a MoSCoW process, to scope out “the crap”, and will classify the processes in scope according to the following classifications

In an implementation project we will prioritize the “Must have” processes and define the implementation of these processes as the critical path. The other classifications are improvements. What we also try to scope is we should aim for creating a “test script” that will be typically used in UAT and for training purposes.

In essence, we quite quickly get an actionable WBS structure we can divide among the project team, and that can better ensure that the processes are successfully implemented. When we run this scoping classification, we often see that we and up with a fraction of the 850 processes we have in our model. But the important takeaway is that processes vary for each customer based on what they need.

System and Data

To support the processes, we want to quite quickly setup a “baseline” of Dynamics 365. A baseline is a system that is not empty but is populated with as much fundamental setup as possible. Here I like to use what already exists in Dynamics 365; Data Management Templates and build a DevOps hierarchy list of all essential elements that needs to be considered and in what sequence you should set them up on. You can find these standard templates here:

Then you just “load default templates” to create lists of what you should consider and in what sequence you should set them up in.

After you have created this, then just copy the lines into excel and import them into DevOps. We then have a WBS “checklist” of most of the elements that we should consider setting up in the baseline system. When working on this list, we can very quickly see the status of setting up and for scoping what needs to be set up. I also suggest adding the URL to the setup and taking a screenshot of the setup as a documentation of the setup.

This gives a fantastic transparency, and we very quickly can identify what have been setup, and what is identified as “crap”. We also get a fantastic insight of the status of the implementation project. We know exactly what have been done, and what remains to be concluded. Processing through these work items does not take too long, and after a few days of setting up the baseline we are ready to model the processes in Dynamics 365.

People and planning

We have a model that guides the project successfully through an implementation from Discovery/Strategy, Initiation, Implement, Prepare and Operate and as a reference I recommend to use the Microsoft Implementation guide “Succeess by Design”. What we have done is to create our own WBS structure based on main deliverables, that allows to create a clear visibility of the scope, estimates and effort from a commercial perspective. To give a peek into how this looks from a DevOps WBS perspective we have codified all deliverables. And in DevOps we can then follow up the progress all through the project. As we have structures, we can also assign and scope the deliverables down to the essential elements. This allow us to be focused and scope down as much as possible.

Summary

Scoping is an essential. It sets more realistic project objectives and straighten the priorities. The more “crap” you can remove from the initial scope the higher chance you will have to have a successful go-live. My experience is that “scoping down” give a more controllable implementation than “scoping up”. If you have not created your own process-model a good starting point would be to collect as much as possible from Microsoft Learn or from Microsoft docs. From there you can build WBS structures that allows for repeatable scoping with customers. And remember that 90% of everything is crap.