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.
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.
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.
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.
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.
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.