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.

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

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

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

6

Project Management gaps

• What is the budget? How are we tracking against it?• What is the scope?• What is our resource allocation?

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.

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

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.

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.

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

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

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.

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

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.

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

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?