My AX 2012 Upgrade Project Plan - Analysis Phase

What do developers love most? Writing code of course! And what if you are a passionate AX developer, working on AX 2009 and are going to be part of an AX 2012 upgrade? Well, jumping into AX 2012 as soon as possible!
So, it was my job to be the boring PM that had to explain that no one was to start coding anything until the boring analysis phase was completed.
And I was right!

Critical success factor alert - Make sure your team (both technical and functional) understand the target version as well as the current version so they can make the right decisions for your upgrade.

For a few weeks, our technical team was divided into areas of interest in the system, and had the tasks to study the AX 2012 documentation, play with the AX 2012 sandbox to get to understand what we were dealing with. None of our team had expertise in AX 2012 really, we were really early adopters!

For every key area, both functional and technical team members had to develop a document that would describe the way we currently had implemented a pattern, describe the AX 2012 pattern, and then come up with a pros and cons analysis and a path to how to upgrade.

Knowing the task was a big one, we also had support from our management to engage with the AX R&D team. We spent a week in Bellevue which helped as an accelerator for our team. Also, while in Bellevue, we were able to validate our project plan, which is what I was most interested in.

Below are the details of the analysis phase of my project plan. You may have customizations in other areas so use this as inspiration not a template:




















I divided the phase into requirements and technical analysis. Under requirements, I wanted us to really understand the target system we were going to land on. So, from infrastructure requirements (which I will write in a future post related to performance) to learning the upgrade framework and attend the sessions in Bellevue. To have this sink in, we ran a "dirty" iteration "0"/"R&D" upgrade to see what that looked like. Basically a "throw away" upgrade with no code fixes or data upgrade scripts ran. Kind of scouting the terrain before a battle :)

For the technical analysis, each team member had one or more areas to analyze with the output being an assessment and upgrade path decision. Every one presented to the team in our "team code review" sessions so we all could comment, contribute and learn from each other different areas of AX 2012.

Critical success factor alert - The upgrade decision matrix. This was the main artifact from this phase. In this document, we listed out all the impacted patterns, how we had it implemented in the current version, what options we had to chose from for the upgrade, the decision made and all reference materials and accompanying document from the technical analysis. Very useful document as it helps keep our focus on upgrading to patterns we would use and minimize unnecessary work on the upgrade.

Now, we did fail in one of these analyses, we did not really understand date effectivity, and that cost us a lot of headaches and rework! Basically, we had custom processes that used start dates and end dates. During the analysis, this looked like a pattern that should be upgraded to the date effectivity pattern. Well, in AX 2012 this meant something different and we had a lot of refactoring to do post upgrade. So, make sure to run team code reviews on the upgrade decisions you make! If you want to know details, let me know.

The functional team updated our functional fit gap analysis, but this document was less important for the upgrade for us, since we had a mandate of an apples to apples upgrade. No new features and requirements in the upgrade.

Critical success factor alert - Conduct a user experience analysis. We knew early the UI was going to change significantly and we used time to go visit all super users and do an analysis of all the forms used in our custom modules with the goal to remove as many "unnecessary fields" as possible. In addition to this "pruning" exercise, we would also bring up AX 2012 screen prototypes printed on paper to sit and write on with our users. This way we could do some UI design with them in a non-threatening way, and also reduce the number of fields to upgrade. I would say we eliminated 10-15% of fields, in hindsight we could have taken out 20-30%. So, challenge each fields value to your process.

Next, I will either answer questions from you or write up the design phase. Let me know!



Comments

Post a Comment

Popular posts from this blog

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

Image
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 ...
Read more

My AX 2012 Upgrade Project Plan - Planning Phase

Image
Before I dive into the plan details, I would like to remind you that the exercise of developing the plan is what really is critical to your success. So my plan may not work for you verbatim! You have to go through this process yourself :) Ok, enough with the caveat, here we go, below is the expanded section for the planning phase of the upgrade project plan: The first artifact I developed was our project charter, or the first draft of it. In it I included the project goals and objectives, guiding principles, team stakeholders, high level roadmap, key activities and what is in and what is out of scope. For example, for us, process redesign was out of scope, our upgrade was "apples to apples". Key for me was to keep this as a one pager. Something I could give as a handout to a new tea member or an interested stakeholder. Here it is, I blanked out the team members to maintain their anonymity: I will write about building our team in a fu...
Read more

My AX 2012 Upgrade Project Plan and Roadmap

Image
So I was appointed to take on the task of upgrading our AX 2009 system to AX 2012. I was new to AX but experienced as a developer, architect and then project and program manager in my career. So I had to do a lot of research, but I struggled to understand how big was this project? How many people will be needed? What are the types of skillsets needed? Is this a purely technical exercise? What is the optimal sequencing of tasks? The research did not provide the answers I needed, I found a lot of technical material on how to do upgrades, white papers etc. But not much else. I did find Sure Step, but it did not provide me much either, although I used the Sure Step phases and color scheme on my project plan which I will share with you. I thought that would make it easier for AX resources to get used to, it did kind of do the trick. Here we go, below is the collapsed view of my AX 2012 upgrade project plan after 12 or 13 iterations in terms of task sequencing and task estimated duration...
Read more