Although every implementation project starts with the mantra 'avoid customization', few succeed in obeying this worthy objective.

By customization, I mean anything that requires code level change.

When you or your partner change or add code, you are engaging in a software development project. However minor that change or addition maybe.

Therefore you need to treat customizations as mini software development projects that require:

1. specifying - to budget costs and timelines and deliverables
2. testing - both QA and UAT testing
3. documenting - creating some kind of release note for the deliverable
4. deploying - from the TEST environmnt to the LIVE environment
5. logging in the changelog

(1) The specification methodology depends on your organizational preferences: A traditional  functional specification or an Agile user story and acceptance criteria combination for example.

(2) Usually the partner/vendor would do the Quality Assurance testing prior to delivery of code into your TEST environment and your users will do the User Acceptance Testing in the TEST environment before it can be deployed to LIVE.

(3) Often documentation is ignored but this will cause problems later as both partner support staff and client users have to 'figure out' what was done when the code fails to perform as expected or needs to be changed.

(4) Deployment is a formal processs step that must be notified to all stakeholders and executed at a specific date and time so that users can be notified to avoid any surprises.

(5) All development should be change-logged in a separate changelog table rather than relying on comments in the code that typically only developers can see or understand.

LESSON: Treat all customizations as mini software development projects.

Implementation 2