Service Providers (or colloquially partners) often refrain from undertaking organization or process changes during implementation projects of Microsoft Dynamics solutions. And it comes as no surprise: there are many risks related to it, and customizations are taken as a more traditional approach.
Customizations are easy to predict, they do come at risk, but at least the risks are known and often easily managed entirely within service provider’s organization and reach, while organizational change is unpredictable, and often exceeds consultants’ knowledge, experience and expertise.
However, with or without intention or consent, organizational change will always happen. No solution has ever been 100% fit, and since the customer must do their business with the solution, the remainder from fit to 100% will always and without exception be satisfied with an unmanaged, unintentional, but evolutionary process change.
Instead of leaving it all to chance, Sure Step offers much better ways.
Sometimes the Degree of Fit might seem like comparing apples and oranges. With 90 extremely detailed fits, and 10 high-level gaps, the degree of fit seems high, but it isn’t. 90 extremely detailed gaps, and 10 high-level fits, make the degree of fit seem low. In either case the degree of fit is unreliable and it doesn’t tell you anything at all.
For a degree of fit to be reliable, all the requirements should be specified roughly on the same level of detailedness. If they aren’t, you might have an extremely risky project before you, and you just don’t see it. Or you might have a slam dunk, and you stand scared to death by the non-existent risks you see all over.
In situations such as these you have to level the requirements to get a more meaningful figure, otherwise your Fit Gap Analysis doesn’t serve its purpose.
But how exactly do you tell apples from oranges in a requirements list?
Fit Gap Analysis is one of the core activities of the Sure Step. It’s in fact so important that on most projects this activity should be done twice: the first time you do it on a very high level just get a quick overview of customer’s processes and requirements, and the second time you dive deep down into details to figure out everything.
If projects were completely predictable, there would be no need for risk management. Everything could be planned and executed according to plan. However, we know better. Unexpected things happen, disrupt the original plans and cause time and cost overruns. In IT projects, these overruns are far too common to be ignored.
“Software projects are no different from other projects”.
This statement is being repeated over and over at project management courses and seminars, even endorsed in books.
It’s true that software (and ERP implementation, as a subset of software) projects have many traits in common with projects in other disciplines. But ignoring their specifics is almost as wrong as saying that software projects are completely different than other projects.