To understand the challenges when working with Customizations better, please allow me to explain my understanding from the Customization Lifecycle.  The starting point is the functional GAP list. Any GAP can lead to a customization (but not have to). The decision is driven by priority, gain, costs, future functionality, accepted workarounds etc. Let's assume the customization has been accepted as such - including estimation. (Otherwise this blog would not have any value)

Now the customization life-cycle starts and could look like this:
-    Functional specification
-    Technical specification
-    Technical development
-    Functional setup
-    Module Test
-    System Test
-    Integration Test (if required)
-    Acceptance Test
-    Production mode
-    Usage
-    10 x Rework
-    10 x Retest
-    2 x Upgrade
-    2 x Upgrade Test
-    Usage
-    10 x Rework
-    10 x Retest
-    1 x Upgrade
-    1 x Upgrade Test
-    Usage
-    Review for Retirement
-    Accepted Retirement
-    De-installation

What I like to highlight herewith is that any material and documentation you create upfront or during the first phases will usually be used multiple times, partial or complete, will be enhanced, reviewed, retested. The better the quality right from the beginning is, the better we can perform the next steps.

What I see very often is the wish to remove a customization, our customers are upgrading and they like to get at least some of the customizations replaced with standard functionality. To be able to support this process best, the customization documentation should contain at least the following key information:

• What is/are the business process(es) where this customization is used or linked to?
• Who was involved in the different customization phases?
• What are the objects comprising the customization?
• What is the setup necessary for the customization?
• What setup comes with the customization, what has to be done via other tools or manually?
• What are the test steps and test results (in all test areas)?
• What are linked customizations? 
• What is the customization complexity?
• How is this customization classified?
• Which technologies were used?
• How many days were needed to create/test/upgrade the customization?
• Etc.
  

If all this is available, a replacement / retirement can be done much more efficient and precise, or an estimation and upgrade itself can be executed with much better support.

In the following blog entries I will explain in more detail why we suggest tracking such information, by whom this task shall be done and how.

Volker Eckardt