GP Customizations–Documentation Critical
I was looking at this great piece of flow diagram for GP customization from Mark Polino this morning. He draws an important parallel between delivering a quality customization versus delivering a customization based on time constraint. Any developer working on a piece of code for customizing the application has to do it right instead of thinking to do it fast.
(Image courtesy: Mark Polino’s Dynamic Accounting.Net Blog)
Yes. This is the case. I have experienced this earlier. One instance when I was doing an implementation for a telecom sector client in one of my previous job assignments, there was a customization written by an earlier developer . I was told by the client that the developer did deliver it well but he has to do it fast due to time constraint. Ultimately this was a complete start over again.
Clear understanding of requirements is important for a successful delivery of a customization. We should also keep in mind to always respect the business logic of the application while writing the customization. We also get to see sometimes wherein customizations happen to change the business logic of GP and this even though may serve the immediate requirements of client, but it seriously affect the customers in longer term. We have to educate the customers also when they fail to understand the limitation of an application and to what extent a customization can be done.
Another important point which I feel can be included in the Flow diagram is that there MUST be a clear documentation of customization. Why, what and how are the three areas that need to form part of the document for any customization. Without a clear documentation of the initial customization and its later changes, it is a piece of junk which is useful for nothing for the client in my knowledge.
Here’s the summary
1. Do it Right
2. Understand Requirements
3. Educate the Customer about limitations, if any
4. Maintain Precise documentation
