The document outlines the key steps for deploying a Dynamics AX project, including diagnostic, design, development, deployment, and operation phases. The deployment phase focuses on end user training, change management considerations, final data migration, system testing, user acceptance testing, cutover to production plan, and post production support plan. The operation phase includes providing post go-live support, transitioning to support, formal project closure with lessons learned, and system acceptance sign off.

1. Some steps and rules to
deploy aDynamics AX project
How to succeed !
Slides written by Guy de Lussigny

2. Diagnostic: this phase captures scope and commences at the earliest
possible stage, usually pre-award of a contract
Steps to
deploy it
Implementations have many similarities
across these products, Sure Step has been
structured as a general methodology with a
product-specific layer for each product. The
general content consists primarily of
prescriptive phase-by-phase and activity-by-
activity descriptions for completing an
implementation, and also includes
information on the Project Management
discipline.
Design: this phase embarks upon a technical design for the solution build,
to define:Entities, forms, processes, workflows, roles & permissions,
reports, data migration, and integration touch points.Custom feature
designs (these are identified through the Sure Step Fit Gap process)
Development: if design is sufficiently detailed a traditional waterfall
process would follow: An alternative would be to consider an agile
approach (this adds value when requirements are not fully appreciated
and further exploration / visualisation is needed) . Tollgate reviews
involving project team members provide quality and momentum
assurance
Deployment: deployment planning prepares for go live, and covers
elements such as: End User Training, Train the Trainer, Operational
Guides, Change Management Considerations, Final Data Migration,
System Testing (Processes, Integration, Data Acceptance, etc.), User
Acceptance Testing, Cutover to Production Plan, Post Production Support
Plan
Operation: on release to live the project team would normally provide
Post Go Live support and resolve, questions, issues, or skills transfer
requirements. Thereafter there would be a: Transition to Support,
Formal Project Closure Complete (includes lessons learnt), System
Acceptance and Sign Off
Slides by Guy de Lussigny

3. A Few Steps for a successful project
%
%
%
%
%
Deployment: deployment planning prepares for go
live, and covers elements such as:
- - End User Training, Train the Trainer,
Operational Guides,
- - Change Management Considerations,
- - Final Data Migration
- - System Testing (Processes, Integration, Data
Acceptance, etc.)
- - User Acceptance Testing
- - Cutover to Production Plan
- - Post Production Support Plan
Slides by Guy de Lussigny

4. Setting training goals. The first objective in providing software
training for end-users is minimizing any productivity losses
associated with the software transition. This means to have
to, as quickly as possible, get them up to the skill level
required to do their jobs at least as quickly and accurately as
they were doing with the old software
End User
Training,
Train the
Trainer,
Operational
Guides
Assessing end-user needs An important element in creating the
training plan is to evaluate the technical skill level(s) of those
who will actually use the software on a daily basis.
Training delivery methods * Individual hands-on instructor *
Hands-on classroom style instructor-led training * Seminar
style group demonstration * Computer Based Training (CBT) *
Book-based self-paced training
Creating a training program End-user training is more effective
and memorable if you tailor it to your own organization's use
of the software, rather than generic lessons.
Making thetraining program scalable A scalable training
program is flexible enough to accommodate both small
numbers of users (for example, when new employees join the
company and need to be trained on the software) and large
numbers (as is necessary in an organization-wide rollout of a
new product)
Slides by Guy de Lussigny

5. 1. Have a clear vision: Executive leadership must communicate a clear picture of where the organization is today, what
success looks like in the future, and the organizational culture required to achieve it. This must be done consistently
throughout the strategic planning process, using multiple communication channels.
2. Influence the right people at the right times: People accept personal responsibility for change at a different pace. Identify
early adopters, or those that carry greater influence over staff first. Get their support for cultural change and their
commitment toward being a catalyst. This is best accomplished during 1:1 discussion between executive leadership and key
staff.
3. Leverage what’s already working: Identify current initiatives, actions, or processes that reinforce the behaviors of the ideal
organizational culture. Identify areas of success to further strengthen as strategic opportunities during a SWOT exercise.
Think practical and pragmatic, not always big picture. What are the little things that are working that can be easily
replicated across the organization?
4. Invoke the heart: Don’t just let people be aware of change. Make them feel it. Speak to the emotional impact that positive
change will have on individuals and the team dynamic. Communicate how organizational change improves the quality of an
individual’s work experience. This should start during pre-planning, staff-wide communications, staff meetings, and all-staff
town hall meetings.
5. Demystify the elephant: The big, bad and scary doesn’t have to be overwhelming. Break it into smaller, more palatable,
bite-sized pieces. Change the individual pieces, not the entirety all at once. These components of the bigger challenge, or
opportunity may become your organization’s Strategic Priorities during the Strategic Planning Process.
6. Personalize it: Personalize the impact of a cultural shift staff-wide during communications. Answer the question, "what’s in
it for me?" How an organization answers this question needs to be incorporated into communication channels supporting
the Strategic Planning Process.
7. Let people see it: Help leadership, including senior management, visualize the change. Use pictures. Use analogies. Use
comparisons. People believe things they can see. When management sees the picture, they can help tell the visual story.
8. Magnify small wins: Do something about the small things that have the biggest impact first. Highlight areas where cross-
divisional collaboration and coordination has already taken place.
9. Tell the story: An audience loves a good story. Share it often, from different perspectives, including those from a divisional
perspective. How is the strategic planning process positively impacting the division? What’s changing? What’s changing as a
result of the strategy’s execution?
Change
Management
Considerations
Slides by Guy de Lussigny

6. In system testing the behavior of whole
system/product is tested as defined by the
scope of the development project or product.
Final Data
Migration &
System
Testing
System testing should investigate both
functional and non-functional requirements
of the testing.
System testing is carried out by specialists
testers or independent testers.
System testing is most often the final test to
verify that the system to be delivered meets
the specification and its purpose.
It may include tests based on risks and/or
requirement specifications, business process,
use cases, or other high level descriptions of
system behavior, interactions with the
operating systems, and system resources.
Slides by Guy de Lussigny

7. Testing is a set of activities conducted to facilitate discovery and/or evaluation of properties of one or more
items under test.[3] Each individual test, known as a test case, exercises a set of predefined test activities,
developed to drive the execution of the test item to meet test objectives; including correct implementation,
error identification, quality verification and other valued detail.[3] The test environment is usually designed
to be identical, or as close as possible, to the anticipated production environment. It includes all facilities,
hardware, software, firmware, procedures and/or documentation intended for or used to perform the
testing of software.
UAT and OAT test cases are ideally derived in collaboration with business customers, business analysts,
testers, and developers. It's essential that these tests include both business logic tests as well as operational
environment conditions. The business customers (product owners) are the primary stakeholders of these
tests. As the test conditions successfully achieve their acceptance criteria, the stakeholders are reassured the
development is progressing in the right direction.
- User acceptance test (UAT) criteria (in agile software development) are usually created by business
customers and expressed in a business domain language. These are high-level tests to verify the
completeness of a user story or stories 'played' during any sprint/iteration.
- Operational acceptance test (OAT) criteria (regardless if using agile, iterative or sequential development)
are defined in terms of functional and non-functional requirements; covering key quality attributes of
functional stability, portability and reliability.
- User
Acceptance
Testing
- Cutover to
Production Plan
- Post Production
Support Plan
Slides by Guy de Lussigny

8. In system testing the behavior of whole
system/product is tested as defined by the
scope of the development project or product.
Cutover to
Production
Plan & Post
Production
Support
Plan
System testing should investigate both
functional and non-functional requirements
of the testing.
System testing is carried out by specialists
testers or independent testers.
System testing is most often the final test to
verify that the system to be delivered meets
the specification and its purpose.
It may include tests based on risks and/or
requirement specifications, business process,
use cases, or other high level descriptions of
system behavior, interactions with the
operating systems, and system resources.
Slides by Guy de Lussigny

9. Operation
%
%
%
%
%
Operation:
on release to live the project team would normally
provide Post Go Live support and resolve,
questions, issues, or skills transfer requirements.
Thereafter there would be a:
- - Transition to Support
- - Formal Project Closure Complete (includes
lessons learnt)
- - System Acceptance and Sign Off
Slides by Guy de Lussigny