The Pareto principle (the 80-20 rule) and how it applies to ERP implementation costs:

The implementation consulting group tells the customer that he can get 80% of what he needs for $50,000.  The customer then makes the assumption that getting the final 20% will be another $10,000 or maybe in a far out case $20,000.   But if we apply the Pareto principle we see that 20% of the cost of the project will get us 80% of the needed functionality.  The remaining 20% of functionality will cost us 80% of the total project cost.  In this example we got 80% of the functionality needed at a cost of $50,000 (20% of the total cost).  Therefor to get the remaining 20% of functionality it will cost us $200,000 (80% of the total cost).     The consulting firm will take the lead and get you 80% of the functionality you need and charge $50,000 and will then turn it over to the customer to finish the remaining 20%.  And since management doesn’t want to spend much more than $50,000 this ends up looking like a doable thing.  When it ends up costing $200,000 the customer feels misled and many outsiders will wonder how an estimate can be so far off.  But the consulting firm will have been accurate in their statement that they can get 80% of what they need for $50,000.

This example plays itself out most frequently in two of the most difficult parts of an ERP implementation.  Defining the business processes and converting the legacy data.   80% of the business processes can probably be defined relatively easily and may fit quite well with any predefined business processes that come with the ERP package.  But the other 20% are what makes each company unique.  These processes will take considerable time to review.  A variety of different choices may present themselves as viable approaches.  Only a thorough analysis of the needs and piloting them in a variety of different ways will yield the best business practice that take advantage of the ERP packages capabilities and address the unique needs of that company.

With converting of data there can be much data that comes over relatively easily.  The existing data may be very clean and the mapping very straight forward.  But for some areas the mapping will be very complicated as the structure of the old system may be completely different than the structure of the new system.  The legacy data may be in multiple spreadsheets, Access databases and be inconsistent and not current.  Not only is the cleanliness of the data important but much time may have to be spent to figure out how you map that old data to the new structure.  80% of it may come over seamlessly while the remaining 20% will take 4 times longer.