Designing Microsoft Dynamics NAV Implementations - Part 2

The last blog on this topic covered pre-design activities.  We'll pick up from where we left off and cover the design process itself.  There are probably a number of ways to carry out design, so this is one potential methodology. 

The design process roughly consists of:

1) Design requirements meetings
2) Analyzing the notes from the meetings.
3) Designing solutions and translating the concepts into functional and technical specifications. 
4) Reviewing the specifications with the client, updating them until full agreement is reached. 

We'll cover each step independently:

Design Requirements Meetings

A good way to structure meetings is to keep the number of attendees reasonable and to break them into 2-3 hour sessions.  Schedule breaks.  The designer should have ready access to NAV to be able to demonstrate out-of-the-box functionality.  The client should have ready access to the legacy system to demonstrate current functionality.

It is vital to use a written guideline to drive the meetings.  An agenda is only a start.  A functional design template is best which is pre-written and covers all the topics that will be covered in the design with key data pre-populated in the template.  Without a design template, it will be far to easy to "forget" to mention an important detail, get side-tracked and lose focus.  The written guideline should be included as one of the pre-design activities.  The design template should be tailored for the client prior to the meetings.  Note any gaps between the standard product and client requirements and any pre-sales data gleaned from prior meetings.   

With the pre-design activities in place - 1) Client has agreed-upon a design approach, 2) Client understands their internal processes, and 3) Client has been trained, the client is now in a position where design collaboration can be most effective.  

The meeting starts with the process of the area being designed.  For example, sales order entry.  Review the as-is process and to-be process diagrams if you have them. Otherwise, you will need to capture, but not necessarily diagram these, during the meetings. 

Have the client demonstrate their functionality.  In this case, how to enter an order.  Note any gaps.  Demonstrate the same functionality in NAV.  Note any gaps and get the requirements for the gaps.  For example, the legacy order entry screen contains fields that are not in NAV.  How are they used?  it turns out they print out on the invoice and is required by certain customers in order to pay the invoices. 

The designer notices the pricing in the legacy system operates quite differently than NAV.  This was not brought up in the RFP stage or in any of the demos.  NAV picks the lowest price available while the customer's system picks prices in a set hierarchical pattern.   This is non-negotiable as prices are contracted with customers and therefore NAV requires customization.  The designer asks questions until and notes the requirements down, preferably in the design template itself.  Personally, I don't use pens or pencils in design meetings.   It saves much time to simply type the requirements in the template itself. 

NAV order entry is demonstrated and the client is satisfied it will meet their needs minus the previously mentioned items.  The meeting is complete. 

Analyzing Notes from the Meetings and Designing Solutions

Now is the fun part - designing the implementation.  I like to work in small segments so I work on each segment of the design in turn.  In some cases, design may involve converting notes into a clear statement of the requirements in plain, clear terms.  In other cases, you will need to "figure out" how to accomplish a goal in the ERP system.  Putting concepts on paper is a good way to visualize solutions and "trying" out various scenarios by entering transactions in NAV can be revealing.  I find it successful to design in the physical universe - sketching, drawing, typing data into Excel, entering transactions and testing.  I don't spend a lot of time "thinking" in me 'ead.  And of course, Google may have passed up the dog as man's best friend.  Don't be afraid to use it.  There may be third party solutions or someone may have already solved the problem.  

The end product will be functional and technical design specifications that effectively capture and communicate the requirements to its intended audience.  The functional specifications must be understandable by the client and project personnel.  The technical specifications should be thorough and clear so that developers can read them and execute without a lot of further discussion.  

Reviewing the Specifications with the Client

It is now the responsibility of the designer to ensure the client and project personnel understand the design.  This is best done in person and updating the document per client feedback.  The document is sent back to the client for review and further iterations are made until the design is finally agreed upon.  

Design Continues throughout the Project

It is fait accompli that the design will not be 100% accurate or complete and therefore one should expect that it will continue to evolve throughout the project.   Development should be delivered iteratively with frequent client demos and feedback sessions.  Client should be hands-on in the development stage.  The product will then shape and mold to the client's requirements iteratively and the remainder of the project will have the greatest chance of success. 

Summary

Design is not an art.  It is a science and requires a number of skills- the foremost is the ability to communicate effectively and clearly verbally and in writing backed with extensive product knowledge and implementation experience.   It requires the ability to ask questions so as to obtain requirements and to steer group meetings to achieve the goals of design.  It requires the ability to research and come up with solutions to problems. 

A good design communicates to all those will consume it- client and project resources.  Functional specifications should be in simple, clear language, not peppered with a volley of technical acronyms.  Technical specifications should follow suit and should be thorough enough so that developers can run with it. 

Sufficient time should be spent on the design process.  It is time well-spent and is necessary to ensure the success of the project.