Learn about the risks, challenges, and best practices for implementing Microsoft Dynamics AX in enterprise manufacturing and supply chain environments. Hear about a couple of our Microsoft Dynamics AX implementation stabilization case studies.

1. CONNECT. INFLUENCE. LEARN.
Stabilizing Dynamics AX Implementations:
Case Studies

2. Introduction
In this session, we will present case studies from example Dynamics AX
projects which Merit Solutions has taken over mid-stream. These case
studies reflect our focus on raising the bar in AX implementations in the
following ways:
• Proper investment in analyzing business requirements before beginning
implementation
• Adhering to basic best practices in project management and
governance which may seem to be more costly in the beginning, but
always result in successful implementations.
• Avoiding the temptation to cut corners to “save time”. In the end, this
nearly always results in schedule, scope, and cost overruns in the project.
2

3. PWC AX project survey
A recent survey of AX implementation projects
was performed by PWC.
Findings include:
• 85% of projects fail to achieve core objectives
• 30% of projects have post go-live issues affecting P&L
• 70% of implementations are over-customized
• 40% of implementations have inadequate business
process documentation
• 60% of implementations have training geared toward AX
process rather than tailored to business process
3

4. Why does this happen?
Contributing Factors:
• Excessive focus by VARs on selling software rather than business process
• Lack of Project Management
• Lack of Project Governance
• Not adhering to best practices for documentation and development
4

5. A Sales Culture
• The typical sales model for packaged ERP software is to “get the sale”
by whatever means possible
• Because of this, gaps in the solution are minimized during the traditional RFP –
demo sales cycle
• The rude awakening happens when the implementation team comes in
• How can this be mitigated?
• Greater investment in business analysis before a particular solution is even
selected
• Detailed requirements which come from this analysis
5

6. Project Management gaps
• What is the budget? How are we tracking against it?
• What is the scope?
• What is our resource allocation?
6

7. Case Study 1: Restructuring Project Management
Client X: Is involved in a Dynamics AX implementation which has no budget, schedule,
or scope. This project has gone on for years with no end in sight, with no visibility in to
hours spend or progress.
Merit Response:
• Development projects are only started once a timeline and budget are established.
• Tracking against these timelines and budgets are reported weekly to client Program
Management
Result: Spend is immediately brought under control. Projects are managed to timeline
and budget.
7

8. Project Governance gaps
• Has a governance structure been defined
at the outset of the project?
• What are the roles of the constituents of the
project?
• Status reporting:
• What are the reporting deliverables for
each role/work stream?
• What is the reporting frequency?
• Timely and accurate status reporting can
allow course to be changed before
schedule or budget are exceeded.
• Status reporting drive accountability
8

9. Case Study 2: Implementing Project Governance
Client Y: The AX implementation lacks scope;
development is not prioritized, requests for
new features are handled in an ad hoc
manner by consultants working with
functional groups on an individual basis.
Sometimes conflicting development projects
are pursued by parallel functional groups.
Implementation of features and
development projects are entered in to
without consideration for cost or scope.
Implementation is initiated without official
approvals of any requirements
documentation by business SMEs, resulting in
significant rework every time a new feature is
deployed.
9

10. Case Study 2: Merit Response
Merit worked with the client team to establish
the following:
• Client side Program Management Office. The
client PMO has responsibility for arbitrating
project scope and cost, and having final
approval over all projects.
• Client side Work Stream teams consisting of
relevant SMEs from the business together with
Functional Consulting resources. Work Stream
teams are formed once project work is
approved; these teams do not hand projects
to Development teams without approved
requirements documentation
• Result: Less rework and waste after
implementation go-live. Control over project
spend and scope.
10

11. Documentation
Top excuses for not documenting customizations or system configuration or business process:
• We don’t have time for that
• It isn’t necessary – the customization requirements can be communicated verbally
between the developer and the user
What does this lead to?
• Tribal Knowledge – the operation of the system will be known by the developer and the
user who specified the requirements, but not:
• End users who need to be trained
• New employees/users of the system
• What if someone wins the lottery?
• Customizations done without buy in and approval from all the relevant parties
• Rework due to requirements not being clearly defined –this results in an extended User
acceptance process
11

12. Case Study 3: Documentation best practices
• Client Z: Implementation projects are entered in to with little to no
requirements documentation. When documentation exists, it is not kept up
to date when requirements change. Development is done by verbal and
email communication between end users and functional and development
resources.
• Result: When projects are deployed, UAT testing fails repeatedly because
requirements are not well defined. Some features are deployed, but then
multiple bugfix projects are spawned because undocumented and
unidentified requirements are found after deployment
12

13. Case Study 3: Merit Response
• Defined document artifacts are required for feature implementations:
• Requirements
• Functional Design Specifications
• Documents require approval before development is initiated
• Result: Less rework after deployment. Drastic reduction in “triage” projects
created after deployment.
13

14. Development best practices
• Environment maintenance
• DEV-TEST-PROD environments are crucial, enforcement of proper code promotion
procedures is crucial. Otherwise, the “gold” production environment
configuration is unknown.
• Code commenting, and code check-in/check-out processes must be followed
• This is especially important when merging code projects from multiple
development teams
14

15. Case Study 4: Development best practices
• Client A: Multiple Work Streams are submitting code to be merged and
promoted to production. Code commenting and revision history notation are
not enforced across the developer teams. The developer in charge of merging
the code must spend hours weekly conferencing with various development
teams to decipher which code must be merged in to the Production
environment. Only one “super-developer” who is intimately familiar with the
code is able to perform the merge activity; the task can never be successfully
shared among a team.
• Result:
• Code promotions often fail because code that worked in the test environment does
not work once it reaches the production system.
• Code is sometimes incorrectly merged and reaches production, resulting in the
necessity to roll back code updates from the production system after deployment.
• The singular code merge “super developer” is a critical path. If he ever is unavailable,
project activity comes to a halt.
15

16. Case Study 4: Merit response
• Merit implements Standard Operating Procedure for development teams
involved in project. Code projects submitted for testing and promotion must
meet minimum code commenting and revision history standards for merging.
• Build Master team is formed, with 3 development resources who can be used
interchangeably to perform code merges. If the Build Master on duty cannot
decipher the proper code merge directives, the project is rejected.
• When projects are reworked, this must be notated so that the merge team
supersedes the previous work appropriately.
• Result: 95% reduction in failed code merges. 100% reduction in costly rollbacks of
code promotions
16

17. In summary
• What processes and methodology does your implementation partner follow?
• Do they do a great sales demo, or do they thoroughly analyze your business
requirements before proposing a solution?
• What are their practices around Project Management and Governance?
• What are their practices around documentation?
• Business process and system design documentation
• Testing documentation
• What are their practices surrounding development and customization?
17