My AX 2012 Upgrade Project Plan - Deployment and Operations phase - User Training

So, we completed the walkthrough of how we planned and upgraded our AX 2009 to AX 2012. Remember how I emphasized that this is also a change management project because it will impact your users heavily during and on their initial performance with AX 2012. Although familiar in terms of process, it will look different. I write this and I am already thinking our next major upgrade, which due to AX moving to the cloud, will have a redesigned HTML5 UI (I assume). So this will apply for that upgrade as well.

So, for this blog, I will break our final part of the project plan into two major phases:
  • The Deployment phase (Training and Production Release)
  • The Operations phase (Post go live support and operations)

In terms of deployment, we were very focused in ensuring our users would be familiar and well trained in using AX 2012.
In my previous blog, I shared with you the process of how we did parallel testing to ensure the system was production ready, but it also did a great job in ensuring our users were well trained in the new version as they were actually doing the same tasks twice a day, once in the old version and once in the new version.
Before the parallel testing marathon though, we had multiple tactics in our training strategy:
  • One on One sessions with our super users - During these one on ones we focused on first of all demonstrating what the new AX would look like, review the current forms and elicit opportunities to remove unused or irrelevant fields (Simplify where possible, and less to upgrade). Having the super users early onboard in reviewing the system would ensure we could scale helping others if needed after go live. Being part of the design, help them feel included, and also felt they had a say in the direction of the redesign of forms and thus an easier path to user adoption.
  • Guerrilla Training sessions - Inspired by Sun Tzu's art of war and guerrilla tactics, we decided to train our user in very small groups, 3-4  per class with 2 trainers (functional analysts, plus sometimes developers). The classes were very focused on processes, not overall AX 2012 capabilities and overview. But processing specific tasks that were real life cases. It required developing training materials to match the process topics. So we created focused 10-12 page guides, rich with images and thin with words (no one really likes to read in this modern age). It worked very well, users got trained and were ready for parallel processing, we found bugs, and developers got a first hand perspective on how users used the system to perform their tasks. Plus, in small rooms, there is nowhere to hide, all were active and involved. In a room with 30-40 people ... lot's of lost focus and learning potential.
  • Sandbox access - All users who had one on ones and then participated in guerrilla training classes were granted access to our sandbox install of AX. The intent was to allow users to go and safely explore the new version. Only a few used it, and most did not. Basically, if not mandated or under supervision, there was no incentive as people are always busy and playing in a sandbox has low priority in a busy day.

Parallel testing really was the critical success factor as it forced everyone to try every scenario with real life tasks in a safe environment.
On my next blog I will share with you our release checklist. Beyond the upgrade cockpit checklist which focuses on upgrade tasks. We developed a massive 127 step checklist to coordinate the go live weekend. Looking forward to sharing it with you.


  1. Where is the Training overall phased approach? Thanks.

    1. Hello! Apologies for the delayed response! I have been off for a while :)
      What do you need? more detail on the training or if it was phased?

  2. I think you mean if the training was done in a phased approach? If yes, then yes it was:
    First we did the one on ones, that was intended to help us streamline the forms but also introduce the new look and feel of AX 2012. This started with the supervisors and super users.
    The major phase was the guerrilla training sessions. This is where we had the smaller groups going through our processes with the latest upgraded version we had. So, the prerequisite here was to have a working upgrade, even if it was not perfect. And this was also phased, aligned with upgraded functionality and forms :)
    What I got out of this was testing by users, and pressure on the Dev team to have a version ready for training!
    Finally we granted all interested with our sandbox. An install containing the latest upgraded system for them to play with.
    I think the 9 weeks of parallel testing provided very detailed training as they were testing and learning the system as if it were the live system.

    Hope this answers your question!

  3. Hi Andre

    Firstly thank you for sharing your upgrade experiences with us via this blog. Very illuminating and helpful. Our upgrade team also watched your part of the Convergence presentation you gave, which was also very interesting.

    There were a couple of questions around things like your overall investment, the time you took ultimately to complete the upgrade, and your risk appetite. It seems like you were heavily focused on the "Quality" dimension, and less so on the "Cost" and "Schedule" elements.

    Also, your parallel testing: How did you manage to get your Finance area to do essentially double their work for nine weeks? Are they well resourced? Did you have to spend a lot on overtime and additional resources? It sounds like a great outcome having 9 weeks of testing, familiarisation, and training, but it must have come at a cost.

    We are at the early stages of a 2009 to R3 upgrade. If you are happy to share more details of your project artefacts with us, it would be of great help. We are an apparel retailer, and are in no way, shape, or form associated with your industry.

    Thanks again for your investment in this blog



  4. Thank your for your comment and I would be happy to share more detail. Indeed, for us it was about quality. We had just migrated from an AS400 to AX 2009, and we had a ton of issues from that in terms of process and data. The 2012 upgrade served to not only ensure the upgrade was great but we also refined and tested and resolved legacy problems inherited from the AS400 migration.
    You probably don't have this and may not need 9 weeks of parallel testing, but 3 or 4 after solid functional testing.
    We had 100% commitment from our CFO, which is why we were able to have such a long period of parallel testing. Our team was also willing to go the extra mile on those weekend upgrades. Our CIO was also 100% committed and we did have all the resources we needed.
    There was a slight performance hit on the accounting team during the 9 weeks and that resulted in an increase in backlog items to be followed up on after the upgrade. We did catch up pretty fast and the benefit was clear in terms of the whole department was fully fluent on the new system from day one, so perhaps the slight performance hit was a great investment as the post go live was productive without disruption to performance of the team. I wonder if less parallel testing would have been more expensive post go live in terms of issues surfacing in production and needing hot fixes and downtime, or user frustration in live production needing extra training and error resolution due to not being fluent with the system. Our agile approach and focus on early discovery of rework was definitely a success factor.
    Happy to have a call with your team sometime :)


Post a Comment

Popular posts from this blog

My AX 2012 Upgrade Project Plan - Planning Phase

My AX 2012 Upgrade Project Plan - Deployment and Operations phase - Deployment Checklist

My AX 2012 Upgrade Project Plan and Roadmap