PeopleSoft upgrade: a job well done!
Upgrading from one version of PeopleSoft to another one is a complex job. This post gives an overview for a practice case of an upgrade from HRMS v8.3 to HCM v8.9 for three individual hospitals, located in different area’s but with a co-working system.
A mixed team of people from both technical and functional backgrounds from Logica was appointed to fulfill this task.The RFP consisted of a number of guarantees that we were required to give to the client. It also included that the hospitals would like to complete the upgrade within a specified period of time.
The hospitals had implemented PeopleSoft HRMS v8.3 in 2003 and all three houses had their separate environments. The customizations were applied to all three houses, but the house also carried out on their own small customizations as and when needed. In 2003 also a payroll interface was built, which provided a data dump to the hospitals payroll system with RAET.
In early 2007 the hospitals asked Oracle to do a feasibility for a combined upgrade for the three hospital. Oracle’s findings in short was that it was possible since 60% of the customizations were common among the three houses. Furthermore Oracle also proposed a number of improvements that can be brought about in the Application during the upgrade to make better use of the vanilla PS functionality instead of customizations. The report from Oracle also consisted of a list of customization with a brief analysis and information of which houses have this customization in use.
The bid team comprised of two functional and two technical PeopleSoft consultants. One of the functional consultants did the knowledge transfer planning and filled in the proposal, I did the functional planning and the techies did the Technical planning for the bid. We had a project manager as a bid manager who coordinated and brought us all together. We made a very attractive proposal with an ambitious plan where the three upgrades were to kick off from one of the locations but then were to run parallel to each other with go live dates within two weeks of each other. All in all the project was to run from September 2007 and finish off with all three upgrades by the end of March 2008.
The project started in September 2007 with a Project Manager, two technical consultants and two technical consultants including myself. We started off first with due diligence. In the due diligence phase we visited all the three houses and talked through the respective functionality that each house was using. The report that Oracle had made led us into the discussion that if this is a Technical Upgrade of PeopleSoft tools and application, or if this includes enhancements. Oracle had recommended enhancements to the existing Payroll interface within the Hospitals. For us this meant a complete redesign of the system since the payroll interface was 100% customization and any changes to its design meant redesigning 70-80% of the existing customizations. This would mean extensive testing and parallel runs for a number of months. Even in the best scenario this meant that we would not be able to meet our April 2008 deadline.To overcome this obstacle a joint meeting was held with us, the clients and Oracle. After day long deliberations we reached compromise where the payroll interface stayed the same, but minor changes to the Application could be done where needed.
During the due diligence phase we also realized that we were short of resources. We needed at least three technical resources and three to four functional resources at least during the analysis phase of the project. The project manager arranged for an extra consultant as another functional resource. The advantage with this was that this consultant had already done a lot of work for one of the clients and was well versed in the Dutch payroll. By the beginning of October we had one more colleague joining us as the fourth functional resource to complete the team.
The plan was now that two of the functional consultants would serve as Functional resources during the analysis phase and then they would switch to technical resource during the build phase, since they were well versed in technical and functional side of Peoplesoft HRMS.For the analysis phase we started going through all the documentation available for the customizations within the system. When compared this to the online system we soon realized that this wasn’t complete. Our first plan of action then was to inventorize the customizations. I started by creating a spreadsheet where every customization we could find in the documentation from the original 2003 implementation Fit Gap analysis. I did this for all Personnel Administration customizations, the rest of the three functional consultants did it for Absence module, Salary and Payroll and other interfaces respectively.
With the inventory in our hands we held the first workshop where we talked through all customizations with functional and technical admins of all the three hospitals. The purpose was to get the list complete. The workshop went smoothly and we got to know about a few more customizations that we hadn’t identified and viola we had a list of all customizations. Using this list now as the bible the functional team started the Fit Gap analysis of the 8.9 vanilla application against the 8.3 customized version of the application. The distribution of work remained the same as in the inventorizing phase. The four of us created a fit gap document each where all the customizations from 8.3 application were there. For each customization we made an analysis of how this should be solved in 8.9. If the exact same solution as in 8.3 was to be taken over then this was not a gap since the actual code from 8.3 could be taken over to 8.9, but if this needed to be changed because of the new structure of 8.9 or just because the 8.3 solution was not ideal solution then this was identified as a Gap. We then held our second and third workshops which were for the Fit-Gap Analysis. In these workshops we went through all the customizations and our analysis and the clients gave their feedback on our analysis. By the end of these workshops we were able to get the agreement of the clients on the Fit-Gap analysis. Based on the gaps from the Fit Gap analysis we made detailed functional analysis and documented those in functional change orders. These change orders were sent by e-mail to all the clients. Based on these change order we held another workshop where we got an agreement on the change orders by the clients. These change orders were all generic change orders which mean that this functionality was built originally by original implementation partner and was being used by all or at least two houses. We then started work on the Fit Gap analysis for local customizations which were house specific and developed by the houses themselves. As with generic Fit Gap we created change orders for local customizations as well where development was needed.
While we were busy in functional analysis, the technical consultants were busy with helping the technical administrators from the hospitals to setup their upgrade environments. After setting up the environment in the first hospital, they started the initial move there. Since we were ready with our change orders, the technical team that now included the two functional resources who changed their roles to techies along with the existing two technical consultants. The technical team then started creating technical change orders. After the technical change orders were ready the technical team then started development of the Gaps.
Once the development was done, this was applied to the upgraded version and we were ready for Unit Test. For Unit Tests, I created a spread sheet with five hundred business rules to test. These were all the rules that we had specified in our change orders plus the rules from the old change orders from original implementation which we had 1 to 1 taken over from version 8.3. Sharing this spreadsheet on the network I and the other functional consultants started unit test. The first few days we got many errors that we reported back to the Technical team by making TPR’s (Test problem report/ Bevindings). The technical team fixed these problems and we retested those until the tests were passed.
After the initial move was completed at the first hospital, the technical team started the initial move in the second hospital. Meanwhile I prepared a system test list. This list was not as elaborate as the Unit test list but this included complete end to end testing. This meant that not only the business rules were tested we also tested the vanilla and customized functionality in terms of business process. For example a person’s complete life cycle was tested, from hire, to transfers, job changes, multiple jobs, sickness, time off, position change all the way till retirement or Termination. During the process were also the effects on the Salary Interface and other interfaces were tested. This list had about 100 process which consisted of in total 350 test steps. Once the list was complete I started system testing in the first hospital. This took around two weeks. Obviously as in unit test all failed tests were solved by the technical team and retested by myself.
Once the system test was complete at the first hospital the system was ready for delivery control. Delivery control in the first hospital was the most elaborate test, since not only the functional and technical administrators from all three hospitals were involved. Thankfully the delivery control tests went smooth. Obviously there were errors reported but the serious ones were resolved right away by the technical team and the remaining ones were categorized as cosmetic or wishes. During the delivery control the other functional consultant had assumed the role of the test coordinator. We used a MS Access based database where we stored all our Test findings. All errors reported by all sorts of tests were entered and maintained into this database. The test coordinator took up the responsibility to assign issues to different people within the team based on the status and ensuring that all issues are resolved. This continued to do till the end of the project.
While the delivery control started in the first hospital, I had moved on to the second hospital for Unit testing. This unit tests lasted about 1 week since a majority of errors were already resolved in the previous testing in the first hospital. The errors that we found in the second hospital were picked up by the technical team these were subsequently resolved in the first hospital since the first hospital was our home base and all development work was carried out there and moved to the other sites as and when necessary.
During the same period the initial move was also started by the technical team in the third hospital.
In January 2008 the hospitals had a change in their Collective Labour agreement. This resulted in some new customizations in the PeopleSoft 8.3 application which were not part of our Fit Gap analysis and subsequently also not in the original development and testing. This meant that the new functionality also needed to be developed or moved from 8.3 to 8.9 upgrade environment. This was done during and after the delivery control phase at the first hospital by the technical team. For me this meant that I needed to test all this functionality. For this I created an additional unit test list which consisted of tests related to the new releases in 8.3. I completed the list and carried out the test in the first hospital where it went relatively well.
The Initial move at the third hospital was by the time complete and I started the unit tests there. The first couple of days of unit tests their went very slow as we had some unforeseen problems with the database links. Due to the distance to the third site, I couldn’t work more then 2-3 days per week. So I returned back to the second hospital and carried out the system test and additional unit tests.
The unit tests in the third hospital continued but meanwhile the technical team had completed the first test move in the first hospital. I returned to first house for a day and performed a Test on the First test move. This went very smoothly and only 1 issue that was resolved quickly. The Test move tests comprised of about 50 odd tests which were performed to check if the installation of the application was fine and all pages, reports, processes, interfaces and application engine programs were working. I then returned to the third hospital and completed the Unit tests.
The first hospital was by the time ready with second test move and the second hospital with the first test move. We tested the second test move at the first hospital and tested the first test move test at the second hospital.
From the time of delivery control the first hospital started their own sets of Functional Acceptance test and User acceptance tests. All issues that came out of these tests were coordinated by the test coordinator and resolved by the technical team.
By this time the first hospital was into the final move phase being performed by the technical team. Meanwhile I was at the third hospital to perform the system test and additional unit tests. During this time the Final move at the first hospital was successful and the test coordinator himself performed the final move testing. The first hospital went live on 15th February 2008.
During this period first test move was performed at the third hospital. I had meanwhile returned to the second hospital for testing second test move. As with the previous test move this also went smoothly. The Functional acceptance test and User acceptance tests were carried out and the second hospital went into the Final move. I returned to the third hospital to perform the test on their first test move. We had also promised this hospital to load their word templates for use with the XML publisher. The other two houses had done this themselves, but the project manager had promised the third hospital that we will do this for them as goodwill.
Meanwhile the second hospital went live on Wednesday 12th March 2008. The third hospital had now started their second test move.I was then sent back to the third hospital for the last time to complete the loading of word templates. I stayed on and also completed the test on second test move. The third hospital then went into their final test move stage. The final move at the third hospital went smoothly and they went live on March 28, 2008. The project manager and the technical team had stayed over for the last week with very little sleep during the last move, but ultimately all sites were live.
Although functionally and technically speaking the upgrade project was like any other upgrade project. But the parallel running of three upgrades together coupled with the distance among the three sites made it much more challenging. Thankfully we had an excellent project manager, who took over the complete burden of planning upon himself. This ensured that we could focus fully on our individual tasks ahead without needing to plan over the future tasks.
All in all it was a great team effort and a job well done.
Viewed 15944 times by 3906 visitors
Posted by:
Raheel Khan (2 post(s)).
Raheel is an experienced HCM-ERP implementation Consultant and team leader with over eighteen years experience of design, development, implementation, training and testing in several environments. He has experience of the whole project lifecycle, across a range of market sectors, in particular Banking & Pharmaceutical in companies as ABN AMRO, Deloitte, Unilever, MSD, ING and KPN. In the past years Raheel has gained a reputation for doing large international implementations.Starting his career as a developer, he stumbled into HR and PeopleSoft 13 years ago. Since then he has been a fulltime PeopleSoft HCM devotee. However his passion is still innovation.
One Response
Hi,
I need a sample Excel file which would have the details pertaining to number of resources required for QA Testing from initial Stage to Final Stage
[Reply to this comment]
2027
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
