My AX 2012 Upgrade Project Plan - Design Phase

Hello there, thanks for following the blog! In this blog, I am going to share with you our design phase for our upgrade. Now, it is perhaps not a traditional pattern design or solution design but more of an upgrade design. Most of the tasks in this phase are self explanatory, and I will just comment on some which were critical, and some that we actually did not complete as intended.
To me, developing the project plan is the key exercise, the file the project is created on, quickly loses value as the project progresses and the rapid adaptation to change and unforeseen issues occur.

Agile or Waterfall? We decided to go agile with Scrum rather than a more logical waterfall approach for an upgrade. In my opinion, agile is great at adapting to unknowns and waterfall is great when you know the exact scope. With an upgrade, we argued that since it was "an apples to apples" upgrade, that it was clear in terms of scope, but we also were aware that there were many unknowns to us and therefore we ran the project as a scrum project. In fact, I used the optimized version of this project plan to create the initial foundational collection of Product Backlog Items for the Scrum TFS project. Don't worry, I will share with you those details as well.

So, in scrum terms, I will write this blog up as a retrospective on our design phase:

What went well:

• Critical success factor alert - Using TFS for version control and process management - I plan to dedicate a blog post just on the topic of how we used TFS with our project, but in essence, we had an offshore team, multiple contractors, many workstreams and all work was centralized in TFS. We used the source control integration with AX as well, and still do today, and we are experimenting with Git as well. We used the Scrum template for TFS to manage the work. I converted the project plan I am sharing with you into initially 14 sprints. We completed the upgrade in 19 sprints.
• HR Integration design - Before starting our AX 2012 upgrade, a separate workstream had started to implement AX 2012 for HR. We identified this workstream as a risk early since we could not wait for the upgrade but had to later merge the two implementations. Lesson learned, implement your base AX 2012 platform first, then build modules, we spent a lot of energy trying to stay connected and informed on the HR workstream, and then a lot of work merging the HR implementation into our upgraded version. Being aware of this risk early and addressing it from day one was a success.
• Interface design - We had multiple other systems integrated with our AX 2009. With 2012, we redesigned the whole interface pattern for integrating with other systems. We moved away from inbound/outbound tables, stored procedure jobs to web services based integrations. We also outlawed SQL stored procedures in our implementation. So all our reports and queries were all X++ based. This will prove it's value on our next upgrade. For us, having so much logic encapsulated in SQL, resulted in having to rewrite all reports and any job based on SQL.
• Functional Specifications - this was less about documenting detailed requirements, but more about documenting key business process flows and mapping them to AX 2012 functional areas. We went for a top down approach to requirements and documented as long as there was value to our planning. Guiding principles, key agreements on how we do workflow were more important than detailed specs. In agile terms we wanted our developers to feel they had autonomy on the detailed implementation as long as we all followed the same guiding principles for our processes.
• User Experience specifications - We identified the UI changes as a big impacting factor to our users, therefore, we did do intense UI design work with our key users, printing all AX 2009 forms, printing the equivalent in AX 2012, streamlining fields etc. Having your key users involved in the UI design is very important as it becomes their design rather than your design imposed on them. Our functional team documented the standard form patterns developers would use by type of functional area. This way, we were all following the same UI design guidelines.

What did not go so well:

• Automated build and TFS best practices - We are still working on it. We failed at having that magical process of just pushing a button and automatically build environments. We did start and had followed existing build powershell scripts for AX and TFS. But we never really focused or had a dedicated "DevOps" guy willing to make it work to perfection. This means, all code deployment is still manual for us, and we go from DEV to TEST to INT to PROD, so I am still pushing our team to complete this task. Most importantly as we are thinking cloud, we need a good robust code deployment and build automation. Any good ideas and experiences, let me know!
• Business Driven Process Design - We hoped to do a process redesign project prior to the upgrade, but did not. Our scope and objective was an apples to apples upgrade. I, personally would have preferred to take the opportunity of such a change program to build in process improvements. Since we anyways were going to impact our users with a big change, the process redesign would have been absorbed in the project. And, a more streamlined process, would have also had us perhaps eliminate redundant or non essential code, which would have meant less to upgrade.
• Development of test scripts - We decided to go for test automation, and for that we needed to develop a library of test scripts. Believe it or not, we did not have any test scripts for our AX 2009 implementation, so we started from scratch. At the end, I will say, we did accomplish to write our desired library of test scripts (Over 1000 scenarios). I put this here in the what did not go well section, because we were writing test scripts based on our AX 2009 implementation in parallel with the upgrade, so they did cost a lot of refinement and rework throughout the project, and my initial estimate of 2 weeks, well, it took 2 months. We also followed a benefits driven approach. We designed our test scripts and test plans top down, from key processes to major sub processes. Our scripts read close to how a user training manual would for a new user.

What we would do differently:

• Business process redesign before a major upgrade first - We are now in the process of redesigning a key process in our system, and the outcome, most likely, will result in some refactoring or implementation of a different module to accomplish the functional requirements from the business. That project will have an impact to our users again during design, implementation and UAT.
• Test plan development - We now have a suite of test cases and plans. We have implemented best practices in terms of adding test cases as we release new functionality, or edit existing ones based on process or code changes. We treat our test plan and cases as a living library. You should too, or your test scripts only will cover areas where you have scripts, and over time not test new items. If I had the time and resources, I would rewrite all test cases directly as test cases in our test automation tool (AXeptance), rather than in Test Manager and then recreate them in AXeptance. We are now in a hybrid mode, where we have a set of scripts in Test Manager and a set in AXeptance.
• Automation - A must. During the upgrade, a compile took 4 hours. Today we are in CU7 and it takes 20 minutes. But during the upgrade, we could only do major releases over the weekend. And there is a risk of burnout, if we are working 7 days a week because we did not automate the process. It is in our backlog and goal for this year. My wish is to never have to have anyone work on a weekend. And automation is going to be the key. Not only code releases and builds, but automated execution of our AXeptance test scripts as well, so basically, as close to continuous integration as we can come with AX.

I would love to read your comments on how your experiences, and also let me know if there are more details you would need for your project. Until the next one!