Infosys Microsoft Alliance and Solutions blog

« Windows 8.1 Preview Bits - First Impressions | Main | Dispatcher in WPF: Under the hood »

Global Implementations & Rollouts: Some best practices

Just fresh out from a Global Implementation for Dynamics AX 2009 and as I am still digesting the learnings, I have now been put into another global implementation which is half way through and I am seeing again the same cycle of mistakes occurring, client after client. I thought I would share my experiences here so as to make them relevant for everyone considering planning, implementing or involved in a global implementation. I plan to share these experiences in a series of blogs thus making them readable and easy to digest for the reader.

First let us harp on what we mean by a Global Implementation and Rollout?

Any implementation which involves using the same platform across different countries or diverse businesses is a Global implementation. They all start from client side with great fanfare, huge RFP's for identifying the single platform. In most cases, this start itself takes quite a few months, sometimes a year, till the customer finally kicks of the implementation sometimes along with a system integrator and sometimes they equip themselves with an IT team so that they can do it by themselves. 

The first and the most common mistake, that is invariably present in small projects as well, is a clearly defined team with proper global business process owners. Normally the implementation project manager identifies this team and plan from his side however inputs/team details of client project team are never captured leaving the poor implementation consultants clueless on whom to contact for which business process.

The second mistake that I have always seen happening is lack of global requirement register and its translation to a SMART requirement. This task in itself is difficult and invariably always comes on the implementation consultant to write the global requirement rather than the SMART requirement. What the implementation consultant do is just document their understanding of the business process and some statements which try to point that this is a business requirement.

What we actually need to understand here is the need of the Business Process Owners to give a clear defined signed off set of Global Requirements and the implementation consultant job should be to just convert these into a SMART requirement. If we avoid this mistake and start writing SMART requirements based on the global requirements in the initial stages itself we will save a huge amount of pain in the further stages of the project.

Finally in a hurry to complete the milestone the consultants do their best and manage to get a sign off on the requirement register. Then starts the painful process of functional design and fit gap analysis. It is at this point that the real skills of the implementation consultant are shown. Some common mistakes that I have seen here is lack of parameterization and challenging the business to change their process as per new system without impairing the requirement.

This can be avoided if everyone understands that what is been designed is a Global Blueprint template. This template designed should be such that any feature or functionality required by a particular section of business or by a particular region can be easily switched ON or OFF. This is what parameterization is actually about.

As a thumb rule
·         All system changes should be parameterized so that they can be easily called out for.
·         Any requirement which can be met with an Out of Box business process should call for a change in client business process first. If such changes are demanded they should be identified and documented clearly and given to client with a cost impact.
Another approach that I have seen, and which is a rather good approach, is to first do an Out of Box implementation for either a single module or a small business region/entity and then start doing system or process changes.  This however requires heavy buy -in and acceptance from businesses to adapt directly to a new system.  It also requires a huge amount of change management and active stakeholder involvement to keep the project in the right direction. This approach commonly helps in avoiding all the above pitfalls which I was discussing earlier.
Think about how to avoid these mistakes in your roll outs and implementation and let me know your views and thoughts. In the next blog on this series, I plan to cover on common mistakes in development and testing for a global implementation.


Thanks Jay for the interesting read and though provoking post. Will wait to read the issues faced in the remainder of the implementation life-cycle.

Unless, I am missing something, what do you mean by 'SMART' requirements?

Hi Rahul,

Not sure why my comment didnot get posted earlier. SMART requirements means
Time -Bound
There is a wiki blog on this and I am sure google can churn out loads of stuff on this.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter