Risk

Sure Step in action: business process change

  • Reading time:5 mins read

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 ReadingSure Step in action: business process change

Sure Step in action: a blurry Degree of Fit?

  • Reading time:4 mins read

image 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 ReadingSure Step in action: a blurry Degree of Fit?

Sure Step in action: more about Fit Gap Analysis

  • Reading time:5 mins read

image 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 ReadingSure Step in action: more about Fit Gap Analysis

Do you need contingency reserve?

  • Reading time:4 mins read

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 ReadingDo you need contingency reserve?

Is an ERP implementation project just a project?

  • Reading time:5 mins read

image “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 ReadingIs an ERP implementation project just a project?

How to prevent failure: project education

  • Reading time:3 mins read

According to Standish Group, top causes of failed IT project are these:

  • lack of end-user engagement,
  • unclear specification,
  • changes in scope,
  • lack of management support,
  • lack of planning,
  • unrealistic and unclear goals.

I haven’t seen too many failed Microsoft Dynamics NAV implementation projects, but those that I did see fail, have failed precisely for a selection of these reasons.

Take a closer look at the list above. Doesn’t it seem that the blame lays mostly on the customer? But is it really customer’s fault?

Continue ReadingHow to prevent failure: project education

Sure Step in action: Degree of Fit

  • Reading time:5 mins read

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.

Continue ReadingSure Step in action: Degree of Fit

Business case – do I eat it or?

  • Reading time:7 mins read

It’s a well known fact that IT projects fail every so often. Standish Group has been researching the success and failure factors of IT projects for a decade and a half, and they publish their results in their CHAOS report every two years or so. According to their 2006 report, only about 35% of projects can be categorized as successful, while 65% are declared unsuccessful. In this report, word unsuccessful can mean anything from exceeding time and/or budget (46% of projects) or failing altogether (19% of them). With such a huge proportion of projects going astray, maybe there was something wrong with these projects from the very beginning. Were the time and budget unrealistic? Were the project requirements, or even objectives, unrealistic? Maybe. Or maybe not. How can you tell?

Continue ReadingBusiness case – do I eat it or?