I had no clue how good my laptop was. Seriously. Today it kicked ass of an 8-processor server.
Tomorrow we have a go-live of a Microsoft Dynamics NAV deployment, with manufacturing customized to support configure-to-order functionality. Refreshing manufacturing orders now calculates dynamic BOMs and routings, and it takes time.
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.
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?
[I edited this post once again. I see that it produces a lot of confusion, because people seem to think that this is what I claim, while I tried to convey that this is what some claim, but I think is false. Therefore, I strike this altogether, and redirect you to my original column at MSDynamicsWorld.com. Please, read that, not this. Thanks, and sorry for this mess.]
[I decided to edit this post and exclude all the argumentation it originally contained. There is no need for me to argue the same topics twice, and I really recommend that you visit and read my original column at MSDynamicsWorld.com]
(more…)