Learnings from a multi country phased out Peoplesoft HRMS implementation

• Understand the overall architecture and AS-IS structure of the various countries. Even if a phased out implementation strategy is sought out, it is extremely important to understand the working of the various countries in as much detail as possible. This will ensure that no major design changes are required at a later phase. It is a common observation that projects planned in silos (drawing up a design document with just one country in mind) run into major design issues at later phases as the initial design does not cater to the later phases.

• Traditional Waterfall or other sequential styles of project management does not work. This is especially true in cases of a new implementation/ migration from a legacy system to Peoplesoft scenarios. The learning curve of the users in the new system is large, their expectations are hinged on their experience of the old system and they are unaware of the capabilities of the current system. Fundamentally the users will be in a very fuzzy state and it takes time for them to come to terms with the new system. So don’t expect your requirements to be frozen. Any plan that looks at freezing requirements after the analysis phase will fail.

• Get the user to participate in development early. This is one of the most crucial points in a multi country implementation. There will be a number of screens/ functionalities that will be common across the various countries – thus its extremely important to let the users participate actively in the development of those common functionalities. A common mistake is to involve only the users of the current countries being implemented in the testing phase and realize that users of other countries have different requirement on the same panels later. The rework required at this stage can be damaging. To prevent such a happening – involve users of all countries in the development of common panels and functionalities.

• Evolutionary Prototyping is a wonderful model to use in this case (development of common screens and functionalities). Evolutionary Prototyping is a concept where the development team comes up with early prototypes (even when the requirements are not completely finalized) and lets the users test the same and come with suggestions. The prototype evolves in this manner and finally the desired product results. This is an extremely powerful method for the development of user screens and common functionalities.
• Different Project Management models for various phases. The nature of implementation varies from phase to phase. The initial phase represents a period of high risk, uncertain requirements, skeptical customer, inexperienced team members etc. The project becomes more predictable and stable as the phases progress. It makes lot of sense to use different Project Management models at the initial and later stages. Its also effective to divide the initial phase into overall system architecture analysis into one part and phase specific analysis, design and development into another. The System Analysis phase should adopt a combination of Spiral and Waterfall model. As this is a purely analysis phase, the waterfall model gives great control over the progress. The Spiral method concentrates on a specific phase with emphasis on risks and tackling the risks. For the second part, abandon the Waterfall approach and go for a combination of Spiral and Customer Oriented Development methods. This will ensure that optimum development speed is achieved with customer involvement. As the project phases out, we have the option of going for a Waterfall model or an Agile model. Waterfall because the project is more predictable and this will enable good control over various phases. But this is not a high productivity model as its extremely rigid. So its best to go for an Agile method (XP/Scrum etc.). Agile models are development oriented models. It places great onus on the capability, experience and commitment of developers. This will leverage the experience of the developers as well as deliver the product at a faster rate. One of the best practices in case of a phased roll out is to leverage the learning of the past phases in the current and future phases. Each phase in the migration will almost follow the same steps. Project management can ease out if effort is made to evolve a specific migration process document that can be followed for the coming phases.
  
• Never leave the most complex roll outs to be the last. Though it’s a good idea to start off implementing the easiest country first (will let the developers get a good idea of the architecture, gain confidence, evolve processes and more importantly give customer confidence), it can be disastrous to put off the implementation of the toughest phase till the end. The reasons for that are as below:
• This phase might have the most complex architecture and if not properly designed, it might require major redesign to the existing architecture. It is easier to make a change to the design earlier in the project.
• The most complex phase will require maximum effort and user intervention. Its always better finishing such tasks earlier in the project as you can catch up for lost time later in the project with easier tasks.
• Motivation levels of employees fag with the timeline of the project. Make use of the initial excitement and energy to get the toughest phase implemented.
• Any unforeseen event will be more difficult to handle in the end (performance drop, code overwrite, attrition etc.)
• Planning for the Roll Out dates. A multi country implementation that is spread across more than one fiscal/calendar year need to plan the rollout dates prudently. Certain points to be considered:
• Will it affect Year End processing? If so, what is the window of time when migration cannot take place? Should all migration happen before Year End? Is it ok to process Year End in two separate systems? This has to reflect in the project plan.
• Will scenarios where an employee has data in two different systems affect any processing? For example, let’s say the project involves the migration of two countries from a legacy system to an ERP. Suppose the migration of one country has been completed and suppose an employee is transferred from the second country (legacy) to the new country (ERP) after the Go Live. Now the employee data is spread across the two systems for the current year. Will there be any process (for example Payroll processing/ Leave Processing) that looks at the cumulative data of the employee for processing? This is a major design question, but generally applicable to all implementations.
• Serial-Parallel-Series approach. Can we have a mix of Phase wise and Big Bang approach? This would be the optimum plan. Ideally the project should start with one current phase (Series) and once the team gathers significant experience of the system, more than one country/phase can be implemented in parallel. This will help speed up the complete migration process. A final approach could be looking at the application in general after the implementation of all the phases and pitching in for system wide improvements (Series).

• An alternate phase wise implementation strategy is given below. This method is built on the fact that any phase wise implementation can be thought of as a Wheel and Spoke model (refer the illustration below). The system consists of a Central Core that encompasses common setups, screens, data, reports and architecture. All the other phases can be visualized as plug-ins to the core. Thus, the critical activity is getting the Central Core setup and deciding on the integration points for various plug ins. Once this is designed and developed, any number of plug-ins can be seamlessly integrated to the core. Consider the design and development of the core itself as a separate phase. This lays the foundation of a very stable integration of various phases. Combining the Series-Parallel approach to this would mean that the Central Core is implemented first, followed by Phase I in a Series manner. Now that the team has sufficient experience and processes being mature, Phase II and Phase III implementations can be taken up in parallel.