Sure Step in action: Degree of Fit

I’d like to have a BMW X6. A fantastic car. Only, I’d like it to be convertible, because I love the feel of wind in my hair while driving into summer sunset. I could use a glass roof as well, it makes the interior feel much more spacious. And of course, it can’t have that automatic transmission—I don’t care if it’s not a hybrid car, it simply must have the continuously variable transmission, no matter the cost.

I’ll never have a car like this.

An important factor of Microsoft Dynamics implementation project success is determining and understanding the Degree of Fit. It’s a numeric indicator which explains how close, or far, the customer’s requirements are from the standard application.

Determining the Degree of Fit

Degree of Fit is determined during the Fit Gap & Solution Blueprint engagement in Diagnostic phase of Sure Step. The goal of this engagement is to identify the high-level process, functional and non-functional requirements and to define the solution approach.

Generally, there are three four possible outcomes of requirements identification:

• Standard feature: This is the preferable outcome. It means that the requirement is met outside the box with the solution as is, without any configuration or setup. Most of the times, there are a lot of these, because majority of tasks and processes are common to all companies and are therefore covered in standard solution. Examples of such requirements are possibility to handle inventory in multiple locations, establishing and observing credit limits for customers or handling reservations of goods throughout the system.
• Configuration: When functionality exists in the system, but the system has to be configured or set up before it can be used, it is called configuration. These are as good as standard features; in fact, they are standard features which require some consulting work before they can be used. Examples of requirements which are addressed by configuration are ability to treat domestic and export customers in different ways, handling sales or purchase approval workflows or setting up a specific requisition planning system.
• Customization: The least desirable outcome. Whenever there is a requirement which can’t be met by standard functionality, it has to be custom-developed. Things like Configure-To-Order manufacturing or automated customer billing are not supported by standard Microsoft Dynamics solution and require some (or possibly extensive) custom-development.
• Workflow: If there is fair, but not complete match between a requirement and standard functionality, and customization would otherwise be required, there is a possibility that the company decides to undertake an organizational change instead, and adapt the process to fit the standard functionality, instead of customizing the standard functionality to fit the process. There are hundreds of reasons why this is a far better approach than customization, and I’ve blogged about them in Monkey Policy, Top 7 reasons why to avoid (much) customization, and in many other occasions I can’t even remember. Why it was termed “workflow” instead of “organization”, beats me, but this classification will count as fit, and should be considered always before customization. (Added on August 30, 2010)

Standard feature and configuration requirements are said to be fit while customization requirements are called gap.

Simply put, the degree of fit is the percentage of fit requirements in the sum of all requirements. Say that during your due diligence you identified 87 requirements, out of which 63 are fit, your degree of fit would be 72.4%. Can it be any simpler?

(Add-ons or ISV solutions from third party vendors also count as fit (even though Sure Step would like to have you believe they don’t), so it is critical to identify possible add-ons which might be used—any standard feature of an add-on solution is treated equally as any standard feature, thus contributing to the degree of fit.)

Understanding the Degree of Fit

Standard features and configuration requirements count towards the degree of fit, while customizations don’t. Although all Microsoft Dynamics solutions come with comprehensive customization capabilities, and there is hardly a feature that can’t be custom developed, any requirement which calls for custom development takes you a step farther from standard solution, and makes your Dynamics less Dynamics and more something else.

From the degree of fit perspective, every requirement is equal. This means that there is no weight given to a requirement, and two customization features will take away from the degree of fit in an equal amount, regardless of their individual complexity.

But it’s confusing, isn’t it? How can all requirements have same weight?

Well, naturally, they don’t, but with any requirement you should try to get them to about the same level of weight during analysis, fit and gap alike. If a customer says they need configure-to-order manufacturing, you could declare it a gap and move on, or you could dissolve the big “we need configure-to-order manufacturing” requirement into several smaller ones, to really find out what it is that the customer truly needs. You might be surprised to find out that that one big gap requirement comprises several smaller ones, some of which might be even fit. Similarly, if the customer says they need purchase approval workflows, you could declare it fit; but you are better of analyzing it a little bit deeper—you might find out there are several smaller gaps to what seemed one big fit at first.

Only if you analyze the requirements to about the same level of detail will your degree of fit be a useful metric; otherwise it might be comparing apples and oranges.

In my next post, I’ll explain how the degree of fit maps to project scope and risks, and how to engineer the degree of fit to drive a successful implementation.

(Post was updated on August 30, 2010)