Global Implementations & Rollouts: Some best practices -Part 2
When we talk of global roll outs, there are very few countries which will completely agree and abide by all the core product and its processes. They are fewer businesses which accept the reports in the same format as produced by the new ERP. Invariably every System Integrator has to account or accommodate for such changes, which means that there is a need for customisation and development. Till date I have never seen a complete Out of Box implementation with zero customisation and development.
In the context of a global implementation, each and every phase & especially development have far reaching consequences on the upgradability of the core product. SI teams generally take the first country in line, look at the requirement and the process and if they feel it is a customisation, they would hastily get a sign off.
The development stage preparations have to start well in advance and one best practice is to get the client involved and informed as to how development is going to happen. The best way is to publish a document on development methodology for the client and explain them the rationale behind approaching development. The development methodology has huge ramifications on roll out planning and can lead to a huge agony for PM's if not duly thought of in the infant stages of the project.
We had talked about parameterizing any system changes in my previous blog. This should form the basis of the development. One good practice that we adopted in an earlier implementation was to create development projects specifically for each Change request and follow the same naming convention for the development project as well. This is especially required for global implementations due to the length of time for which they run.
This had its own pros and cons
1) Readability of code greatly increased as suddenly developers were able to relate back to the CR document and CR number
2) IT Auditors were all the more happy as they now found a trace from the requirement, to design and inside the code base.
3) Deployments were easier and releases were more streamlined as a complete piece of code for a CR was available in a single package.
4) Code removal was easier in scenarios where on progressive testing the CR failed and still the release was needed to be made as per committed time
Some cons observed were
1) When we had a development scenario where multiple developers wanted to work on an object which was present in several CR's, the PM had issues in scheduling and planning the work. This led to a slight increase in development time as now a Wait time was introduced based on object availability
2) Additionally this delay also caused a delay in delivery & testing of CR's when the same object was impacted in 2 CR's. Some time it led to multiple rounds of testing of same CR to ascertain that new changes had not impacted the old CR.
To a certain extent, we removed these delays by allocating all CRs which impact the same object to a single developer.
One more good practice that we adopted and which helped us a lot was, writing comments within the code piece. The comments made sure that the developer's intent in changing an object are properly documented and served like a history book for the next developer.
I still have a few things to blog about regarding development and as I align my thoughts behind this topic, do let me know your views on this blog.