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)
Hi Vjeko, I recently did a degree of fit analysis for a new project and I wasn’t sure what to do with the number when I had it. I’m looking forward to your next post that might shed some light on this. I also found that my degree of fit showed quite a lot of gaps but that was because a lot of the standard requirements didn’t get recorded. There didn’t seem any point in recording requirements like, ‘it must be possible to adjust G/L Balances’ when everyone knows you can do it. Instead what we found was the majority of recorded requirements were the points that were either very important to the users, or they thought the system may not be able to do or they were gaps. I think you will get different results from a requirements gathering workshop (which is where my requirements came from) as opposed to an RFP (which tend to list all requirements). As analysts, is it our job to try and write an RFP-style set of requirements if one does not exist already? Isn’t this a massive amount of work for very little gain?
Now I understand why I secretly visit both of your blogs-you are both right and bring forward excellent, though-provoking topics. 🙂
BTW Dave, we LOVED the Everyone Lies post (and I’m still waiting for the ‘selective-Tourettes’ -as we call it follow up).
What we’ve struggled with periodically when writing requirements with clients is that often times we expect our sales team has done an adequate job of doing discovery to get us to this point. More times than not, they have gotten about as much as they can (or should really-we need them selling, not analyzing), then it becomes our responsibility to work with the client to throw back the covers a bit.
If you fail to mention any of the standard, out of the box functionality to a client, they will not be very helpful in identifying where their business processes differ. They should not be expected to be ‘product experts’ at the time of discovery/analysis, rather a well-trained consultant should be able to throw out a little, to get the conversations started, then gravitate to those items they clearly know are not possible in the proposed solution.
Having a mixture of both in a requirement document helps the client also explain to their team ‘why’ there needs to be a customization or third party product. If it’s written well, it should be understandable without someone needing to be certified in the application.
Configuration is what we strive for as it is usually a lot less expensive for a client to change some business processes-those that are relatively new (or will resolve a long-standing problem) but it still needs to be documented as a requirement.
If it’s not documented that the accounts payable manager will need to balance the accrued purchases account to an outstanding report every month in order for a modified screen to provide the correct totals, then you can rest assured when it’s time for deployment they will not remember anything about it.
To bad every engagement doesn’t go to the level of an RFP being generated-but you are right Dave in that it would be incredibly costly-and then there wouldn’t be any money left to implement the requirements.
What I’ve heard through the grapevine is the next release of Sure Step is certain to have better requirements gathering questionnaires to hopefully help in this whole area. I’m looking forward to seeing the new release-and you can bet I’ll come back here to find out about it first.
As always Vjeko-thank you for your excellent topic, and when you do get that dream car, I hope you’ll post a pix of it here for the rest of us to drool at! 🙂
Chris
Hi Dave,
About gaps: my firm opinion is that all requirements should get recorded. If the customer will be adjusting the G/L balances, then it has to be recorded as a feature, and analyzed to see whether native functionality is a gap or a fit. It might end up being a gap, although in probably 99%+ cases it will be one big fat fit.
About RFP: yes, you’ll definitely get a different results from a requirements workshop than from an RFP. In my experience, a lot of RFPs are far away from what customers really need – they are often written by a hired third-party consultant, and are very generic (depending on the third-party consultant’s experience in the industry and the RFP template they used). But the RFP form is generally very good at articulating specific requirements, and fit/gap worksheet should really resemble the RFP, but you should by no means merely copy the RFP into the fit/gap worksheet and call it a day, because the RFP rarely lists all the requirements (and rarely are the requirements at the same “level” of depth, to give a reliable degree of fit). RFP (if it exists) should be used as a starting point. It might be “a massive amount of work”, as you point out, but I believe it is not a “very little gain”–on the opposite, it is a huge gain. Requirements are the cornerstone of every project, and the more detailed you get them up front, the less rework and hidden gotchas the project will bring later on, IMHO this is BIG gain. Just to illustrate, I’ve seen a project where the consultant has deemed a requirement a fit, while it was one huge gap, and the problem was terminology: the customer had one idea of a techincal term, while the consultant had the other (and it was a huge functionality area lurking behind what seemed a standard minor feature at first); if proper analysis and documentation of this big requirement had been conducted in the first place, it would have saved hundreds of hours of work and rework.
I really hope my next post will shed some light on what a real use of the degree of fit might be.
Best regards,
Vjeko
Hi Chris,
Excellent comment! And it explains very well why all requirements should be listed. But I do think that detailed requirements worksheet should exist. It might be costly, but that’s where the project management tools and templates (and Sure Step!) step in: you can have fit/gap worksheet templates for various industries, customer sizes, functional areas etc. that you have created, updated and developed during your previous projects. It is also a good project management practice: frequently updating and utilizing what PMBOK calls “organization process assets”.
Another thing that seldom happens is that fit/gap worksheet is updated throughout the project as a part of change management process. If you get a new requirement, either a fit or a gap, during later phases, it should really be recorded in the fit/gap worksheet (which becomes part of your OPA).
And about my dream car–when I get it, I’ll take you on a test drive! 😉
Best,
Vjeko
A bit Off Topic, but I have SureStep software for use with my students (University of Applied Sciences in the Netherlands) version 2.1.2.0, but I cannot see anything about NAV. Ther is GP and AX, but no NAV in teh several documents.
Am I missing documents or is this version not tergetted at NAV?
Hope to get your answer.
Thanks.
Hans
Hans, you’ll certainly get my answer 🙂 If I do anything, I do reply to comments here.
Anyway, do you not see any of NAV content, or do you just believe there is not enough NAV content in your version of Sure Step? I have Sure Step 2.1.2.0 and I have a lot of NAV content there.
Tell me, when you open the Sure Step application, in upper right corner, what do you see in Product drop-down list? Do you only see GP and AX listed, or do you have all five Dynamics products (AX, CRM, GP, NAV and SL)? When you select NAV under Product, then go into “Documents”, do you get an empty list?
Generally, NAV is a little bit underrepresented in Sure Step, and as far as I know it is going to get better in the future, but still there are a lot of NAV documents there.
Please let me know if this helps, or you need more specific info.
Best regards,
Vjeko
Hi Vjeko,
I’m a bit ashamed. Yes there is a drop down list and I did not see it. Thanks for your help.
Hans van der Hoeven
Avans University of Applied Sciences,
The Netherlands
Winner Excellence Award in Academic Alliance EMEA, november 2008