My last two posts have been a detour from my regular themes, into something that might remind you of human resources. I’ve explained what Microsoft Dynamics consultant does, and how it looks through phases of Sure Step implementation, and I promised to conclude this journey with explaining what I believe to be the 5 most important qualities every great Microsoft Dynamics application consultant must posses. So, here you go.
Don’t you just love when users come up with new feature ideas at a microprocessor clock rate. Even before you finish developing one, five new requests pop up. This is a disease, and it’s called featuritis!
[Updated]
I had to update this post a little bit, see below for the details, but the killer feature had to go 🙁
[/Updated]
Remeber that tool “Automated Version Management” that I published here and on Mibuso five months ago? It has just got an update: version 2.0.
A few days back, while prototyping a new solution for a customer, one of the key users said: “But in our old software it didn’t work like that.” I was about to try to explain why the change, but then the user’s boss said:
– We aren’t implementing a new solution so that everything can stay the way it was.
How often does it happen to you that your customers say to you a similar thing: “But in our old system…”? What do you say to them? How do you approach change when your consultant proposes a new way of doing things, or a new approach to a common problem?
Four months ago I attended a conference, where I had a chance to listen to Miha Kralj, an architect at Microsoft, talk about architectures. It was one of the best presentations I ever attended, and ever since I had this topic in queue, but never really had chance to write about it. Most of the stuff he talked about reminded me of some bad experiences about architectures on projects I’ve worked on. Most of stuff here is also not my original contribution to the universal pool of knowledge, and I reuse it with the permission of the author, so Miha, thanks! What I did, however, is that I applied general principles to specific Microsoft Dynamics NAV situations.
The biggest jeopardies often lurk where we least expect them. When implementing an ERP system such as Microsoft Dynamics NAV, what should be one of our best allies, turns out to be our mortal enemy. It has a simple name: The Standard. Standard processes, standard functionality, standard documents, standard system. All these gizmos can turn into gremlins in a blink of an unattentive eye.
Standards are tricky. If during due dilligence, or diagnostic or analysis phase, we hear the prospect or customer utter the word “standard”, what do we instinctively do? Well, in a standard system, it’s pretty obvious what the standard is, and when the customer says that they “just have standard processes” it means that these processes are just covered with such a standard system, right? So we instinctively tend to skip the more detailed analysis of these, because after all, they are standard.
I’m still in Vegas, and this city is crazy. But it’s funny, us people in IT have a thing or two to learn from these people in gambling business. We have all been hearing from our customers how they want their systems reliable, available, and so. Well, what I’ve been seeing here for the past two days is a highly-available 24/7 service with full redundancy and failover clustering all in place. There are roulette and blackjack tables and slot machines in every free square foot, so it’s pretty darn scalable, too. There is zero downtime, entertainment never stops, and that’s pretty much the reason I write this post now, instead of sleeping. I almost feel the music is louder by the minute, probably proportionally so to how sleepy I am. I’m too old for this sh*t.