Yesterday, in my What does a Microsoft Dynamics consultant do? post I started explaining the job of an application consultant. As promised, today I’ll explain what duties an application consultant has in each of Sure Step phases.
I wonder what people do with Google (or any other search engine for that matter) results past page two, or three. Or ten.
The other day a visitor came to this blog by googling this question: What does a Microsoft Dynamics consultant do? Two things I don’t understand: first, how far in the search results did they have to go—my blog most certainly didn’t land on first ten pages; and second, did they find here on my blog what they were looking for?
I decided to improve both.
Some time back, as I was riding a taxi from Prague airport to Holiday Inn hotel, I wondered about the fixed price I was about to pay for the ride.
– “Airport to city is 700 flat.” – said the driver when I asked how much approximately will it cost.
Common wisdom goes that flat rates mean you get it worse than if it wasn’t flat. Indeed, if it was on meter, and if the driver took the shortest route (I had a GPS device on me, I could’ve easily checked it!), the fare would’ve been lower. And yet, I decided I loved the flat rate.
Have you considered a career in Microsoft Dynamics? Yes, I know, many of you have are most likely already happily employed by a Microsoft partner company specializing in Microsoft Dynamics solutions. Good.
Methodology is a tough topic. There are good methodologies, there are bad methodologies, there are good methodologies gone bad. Methodology is not a silver bullet, it won’t just make any problems disappear, and is hardly ever the single source of success or failure. But a methodology can be a major contributor to success. I could put it this way: you stand much better chances of success if you apply a methodology, then if you don’t. With something as critical as an implementation of business software, methodology is a key success factor. According to Jim Johnson of Standish Group, it’s number nine on their ten identified most important success factors.
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?
I was involved with three go-lives this month. Not all of them required the same level of engagement, that was the major survival factor for me, but nevertheless I got into an interesting discussion with a colleague.
– So it was three projects this month, huh? All of the NAV? – she asked.
– No, it was one NAV, two of them were business intelligence ones.
– Ah, ok, so they are not business critical. – she concluded.
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.
About six months ago, when I was buying a car, a friend of mine, in a typical The Good, the Bad and the Ugly fashion, told me that there were two kinds of cars: good cars, and French cars. I bought a French car. I bought a Peugeot 407 SW (Peugeot says their cars are engineered to be enjoyed) and although I could do so, I am not going to make this a post about what went wrong with this car already so far. This is going to be a post about how the simplest of the features of an ERP system can influence customer (dis)satisfaction, and create long term decisions for, or against a car vendor. Also, not typical for me, I am speaking from the shoes of a customer, rather than consultant, this time. Quite a change for me.