Dynamics AX Programming Projects: Estimations, Test Environment Notes

Former Axapta, Microsoft Dynamics AX is getting its market share, especially in Supply Chain Management, Process Manufacturing, International Business.  If your system is already implemented, the next phase might be integration with external applications, customizations, managerial reporting.  In large organization Corporate ERP custom coding project should be planned, as processes disruption, caused by beta version bugs might be risky and at least not desirable.  Through the years of Microsoft Dynamics modifications we figured out the elements of risks and how to reduce it with reasonable budget.  We would like to share the discovery with you.  This publication is not intended to programmers, it is rather for IT managers and key decision makers:

1. Estimations.  It is reasonable to have several circles here, where the number of hours is coming closer and closer to the final real figure.  By talking to the prospect about modification project the first what we are trying to understand is the magnitude of the changes and its feasibility (maybe add-on already exists on the market and there is no need in programming at all).  Then in Analysis phase (according to Microsoft Sure Step methodology) consultant should be able to collect detailed information and get final numbers.  When project is started, consultants might still find something which was not known to the interviewed employees and manager, which requires attention and you may expect change order to be submitted for your approval

2. Test Environment as critical part of the plan.  If this is not created either on the consulting firm server or directly on the test server at the customer office – project has way higher risks either fail completely or go over budget.

 And here is why.  Corporate ERP application alteration is often (if not always) depends on the dataset of your production company.  Initial coding and following quality assurance is not efficient if developer and QA engineer test it against demo database, where such parameters as account format, naming conventions (customer, vendor, etc.) are different.  Plus, business logic alteration is based on the existing settings (as it is not practical in unique project program all possible situations as "what if…")

3. Wait with Custom Coding project, have your users to become familiar with standard processes, and see if simple setting might do the work.  Reasonable portion of custom modules was abandoned, because customers decided to stick to better designed standard procedures, or because the initially estimated importance of the alteration was later on reassessed as very low.  This is why we do not generally recommend something like "turnkey" solutions where modified logic is programmed prior to going live

4. Technology layer.  It is typically not seen by the end user, or at least they are not exposed to its complexity.  It might be X++ in MorphX, or it might be FRx/Microsoft Management Reporter if you are thinking about complex consolidated financial reporting.  Discussion about programming languages might dis-focus you from critical decisions, which are described in the paragraphs above

5. Microsoft Sure Step.  In fact each AX reseller is required to have Sure Step certification.  This is project management methodology, specially designed for Microsoft Dynamics projects: implementation, version upgrade, customization.  If the project is initiated and executed with documentation created in Sure Step – both your consulting firm and your organization will get documentation on the state of the art level with compliance to project management theory