It is often forgotten that customizing packaged software is software development.
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:
specifying - to budget costs and timelines and deliverables
testing - both QA and UAT testing
documenting - creating some kind of release note for the deliverable
deploying - from the TEST environmnt to the LIVE environment
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.