Where I have been for the past eight months…
This blog started enthusiastically, I had as many as 14 posts per month. Taking into account that blogging was only a hobby, I blogged like crazy. Then I went silent.
No, I wasn’t tired from blogging, I didn’t experience a writer’s block, quite the contrary! I was working on a project. A top secret one. Now it has been done, and here are the results: a book called Implementing Microsoft Dynamics NAV 2009.
You are consulting for a customer, and they ask you:
– “There is a problem with setup for this item, when I calculate the requisition plan, the system suggests purchasing it, while I have it on another location, and I’d like it to suggest transferring it from that location, instead of purchasing it. Can you fix it?”
Assume you aren’t completely sure in the answer. What do you tell them? What do you do?
!!! Check out my book Implementing Microsoft Dynamics NAV 2009 !!!
The long awaited Microsoft Dynamics NAV 2009 has been released for download earlier this week, and has just been publicly announced at Convergence 2008 Copenhagen. If you have PartnerSource access, you can download Microsoft Dynamics NAV 2009 here.
This one is the most important release of Microsoft Dynamics NAV ever, as it brings a completely new architecture, a shiny new user interface, web-services enablement and much more.
Last Friday, while enjoying a not-at-all healthy Salisbury steak with cheese, I had an interesting discussion with a partner: should NAV consultancies create default databases?
A default database (in this context) is a packaged solution built upon standard Microsoft Dynamics NAV, where a consultancy has introduced a number of features that they sell to all their customers as the standard solution, instead of standard NAV. The modifications to standard NAV can range from simple report adornments to minor feature improvements to full-scale horizontal or vertical functionalities.
One of many improvements the latest version of Microsoft Dynamics Sure Step methodology has brought along is the revised purpose of the Functional Requirements Document (FRD). This document has long served as cornerstone of every Analysis process of every implementation project: it was the main deliverable of the Analysis phase and it both documented customer’s requirements and explained how they will be met with Microsoft Dynamics NAV solution.
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!
Recently, a reader, commenting on my last post about Sure Step, pointed me to an article by Karl E. Wiegers
“Read My Lips: No New Models!” I initially responded to the comment, but I figure the comments aren’t read as often as posts, so I decided to blog it.
It’s doubly funny that the reader is using Dr. Wiegers to devalue and dismiss Sure Step: firstly, the article has really nothing to do with implementation methodologies at all, and secondly, when I delivered Sure Step training at WinDays pre-conf earlier this year, I gave to each attendant a copy of Karl E. Wiegers’s latest book “Practical Project Initiation”—at the time it was the best book available that matched both the message of my training and the point of Sure Step as a methodology.
Each phase of Microsoft Dynamics Sure Step methodology is equally important in an implementation project. You could argue that analysis is the most important, or that design is the most important, or that operation is less important. I’ll paraphrase Scott Adams here and ask: how one phase can be more important if each of them is completely necessary? Well, except for Diagnostic phase.
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.