My AX 2012 Upgrade Project Plan - Planning Phase
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 future blog, but at this point I had the team defined, so I created another one pager for our team organization. We grouped the team into the PMO (me) plus the development team, the functional team, the reporting team, the steering committee team, the super users team and the infrastructure team. With this document, we all knew who everybody was and what their domain was. You can get the idea of that one pager from the project charters Team box.
The development of the project plan was an iterative process where I did my research on upgrades, discussed with our solution architect, and then also interviewed each developer on their area of expertise for their best complexity and risk "guesstimate". Then I was fortunate to have my company engage us with the Dynamics AX R&D team where we spent 4 days in Bellevue discussing our project. Up there, my personal goal was to review the estimates and task sequencing of the project. We had 3 iterations with the Microsoft SAs. At this point I felt more confident the plan looked in the right direction. So the first milestone: Baseline Project Plan was completed!
Other artifacts of value to us were the backup and recovery plan, the production release plan and the very important and critical to success testing strategy and plan.
Critical success factor alert! You need to know, that an upgrade to AX 2012 is going to be a huge impact to your users in terms of the look and feel (think Office 2003 vs Office 2010), ribbons, fact boxes, fast tabs, yikes! So, for us, we decided to treat the upgrade as a change management project from day one. You should too!
We developed a training strategy and plan that would be used as training users in the new version, but also as early testing of upgrade iterations. Also, we had a goal of doing "one on ones" with all key super users and then small 3-4 person sessions with 2 trainers. Big rooms with many people do not work very well. Remember that your users will go from experts to feel like novices in one day and that is very frustrating for anyone. You can mitigate this feeling by having your user base be involved in the project early. We started to get our users familiar with the AX 2012 UI by doing user experience sessions to map fields from the old version and see if we could streamline some fields (less to upgrade). This gave our users their first peek at AX 2012.
The Production transition plan artifact was more for operations so I will not bore you with that one.
To maintain our user base and stakeholders engaged in the project, we developed a communications strategy that included standard meetings like the steering committee meeting, UX regular sessions, email notifications, training sessions and our weekly project status newsletter flier: AXtra! which we decided to print on paper and deliver to our users in person. This made the project real, we met everyone and there is still something special about paper:
Other communication artifacts was my confidence matrix on the state of the project. A one pager (notice a trend?) to be provided to project sponsors in the steering committee. I used a red/yellow/green scheme to visualize areas of concern and added a little explanation reminder to discuss in the meeting. The below image shows the one ate the end of the planning and analysis phase:
The next major artifact was the benefits realization plan. This document lists all the goals, objectives and expected benefits of the upgrade, and we used it as a living document to document if the benefits were met after the upgrade.
I know there is a lot of stuff here, and I am happy to answer questions or provide more detail on the artifacts if you need more :)
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 future blog, but at this point I had the team defined, so I created another one pager for our team organization. We grouped the team into the PMO (me) plus the development team, the functional team, the reporting team, the steering committee team, the super users team and the infrastructure team. With this document, we all knew who everybody was and what their domain was. You can get the idea of that one pager from the project charters Team box.
The development of the project plan was an iterative process where I did my research on upgrades, discussed with our solution architect, and then also interviewed each developer on their area of expertise for their best complexity and risk "guesstimate". Then I was fortunate to have my company engage us with the Dynamics AX R&D team where we spent 4 days in Bellevue discussing our project. Up there, my personal goal was to review the estimates and task sequencing of the project. We had 3 iterations with the Microsoft SAs. At this point I felt more confident the plan looked in the right direction. So the first milestone: Baseline Project Plan was completed!
Other artifacts of value to us were the backup and recovery plan, the production release plan and the very important and critical to success testing strategy and plan.
Critical success factor alert! You need to know, that an upgrade to AX 2012 is going to be a huge impact to your users in terms of the look and feel (think Office 2003 vs Office 2010), ribbons, fact boxes, fast tabs, yikes! So, for us, we decided to treat the upgrade as a change management project from day one. You should too!
We developed a training strategy and plan that would be used as training users in the new version, but also as early testing of upgrade iterations. Also, we had a goal of doing "one on ones" with all key super users and then small 3-4 person sessions with 2 trainers. Big rooms with many people do not work very well. Remember that your users will go from experts to feel like novices in one day and that is very frustrating for anyone. You can mitigate this feeling by having your user base be involved in the project early. We started to get our users familiar with the AX 2012 UI by doing user experience sessions to map fields from the old version and see if we could streamline some fields (less to upgrade). This gave our users their first peek at AX 2012.
The Production transition plan artifact was more for operations so I will not bore you with that one.
To maintain our user base and stakeholders engaged in the project, we developed a communications strategy that included standard meetings like the steering committee meeting, UX regular sessions, email notifications, training sessions and our weekly project status newsletter flier: AXtra! which we decided to print on paper and deliver to our users in person. This made the project real, we met everyone and there is still something special about paper:
Other communication artifacts was my confidence matrix on the state of the project. A one pager (notice a trend?) to be provided to project sponsors in the steering committee. I used a red/yellow/green scheme to visualize areas of concern and added a little explanation reminder to discuss in the meeting. The below image shows the one ate the end of the planning and analysis phase:
The next major artifact was the benefits realization plan. This document lists all the goals, objectives and expected benefits of the upgrade, and we used it as a living document to document if the benefits were met after the upgrade.
I know there is a lot of stuff here, and I am happy to answer questions or provide more detail on the artifacts if you need more :)
Looking forward to following the blog. There is some great information here.
ReplyDelete> Remember that your users will go from experts to feel like novices in one day
A bit harsh, as the look-and-feel is different but many of the processes remain the same. I like how you have overcome the issue.
The project status newsletter flier is an excellent idea.
Regards, Ian
Harsh but true although you are correct that having the same process does help ease the anxiety of the change in look and feel. It was more like, "where is that button now?" and "why is this now here instead of there?" and "I can't find that form anymore" etc kind of issues. Funny that we migrated to AX 2009 from an AS400 and they hated the AX UI and then when we migrated to AX 2012 suddenly they liked the AX 2009 UI!!! Today, our users are all good and happy and back to experts :)
ReplyDeleteThanks for your comment!
@Andre, Thanks for sharing very good information. Very interested to hear about your reporting and BI story in one of your future blogs.
ReplyDelete