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.
Continue reading Sure Step in action: business process change
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?
Continue reading Sure Step in action: a blurry Degree of Fit?
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.
This is not the first time I blog about it. I explained the meaning of the Degree of Fit, as well as its value in determining the risks of customizing the solution, and then I shared some thoughts about how to use hourly estimates from the Fit Gap worksheet. But every time I think of Fit Gap or I teach it at a course, there seems to be so much more to it.
There are a couple of more points I’d like to address about it:
- How (and why) to engineer the Degree of Fit?
- Isn’t the Degree of Fit a bit too blurry?
- Are the five fit/gap categories really all there is about it?
- Can you inherit a Fit Gap Analysis results from another consultant?
Let’s discuss the first topic today: engineering a desirable Degree of Fit.
Continue reading Sure Step in action: more about Fit Gap Analysis
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.
Continue reading Do you need contingency reserve?
“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.
Continue reading Is an ERP implementation project just a project?