Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time. And so on and so forth.
As a matter of fact, if you asked me to pick one single most important phase in a Sure Step project, then it’s the design. No second thoughts here, whatsoever.
Here I list the ten most important reasons that I believe make design absolutely indispensable.
Microsoft Partners often postpone the actual purchase of the customer’s NAV license until the project is fairly close to go-live. In the meanwhile, they do the development and the testing on-site (or off-site) using their own partner license.
I’ve heard arguments (or better: excuses) to engage in this practice, and I have a very strong opinion on this. So, when is the right moment to actually purchase the NAV license for your customer?
Well, regardless of the fact that 1) you are contractually obliged to purchase the license for your customer at the first moment they get in touch with the solution (which is fairly early in the project), and the fact that 2) you are violating your licensing agreement with Microsoft if you deploy your partner license on third party’s infrastructure, there is 3) a fairly compelling technical reason why you might never want to even try doing any project work involving customer with your partner license.
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.