In every phase of the project, you are dealing with actual users who will use the system and are the folks who'll be experiencing the most change. The usual human psychology is to resist change, be it a new process or a new system. As part of an implementation project team, you may find that many of the issues that are raised by the users are not completely aligned to the scope of the project, the signed requirement, or the solution design specs, and the success of your project is dependent on how these changes are managed.

For a CRP lead/project manager, it is very important to review and highlight any such change, and take it through the change management process, as any change may impact the system design, timeline, budget, risk, goals, and many other factors. These changes must be addressed carefully, as the implementation of any change, without proper analysis, can potentially derail the project effort.

Training is a good opportunity to help prepare people for the change. The more training that is provided, the higher is the confidence of the users in embracing the change and the system, resulting in less pushback. Let's explore the various options for managing change with users of the system, as follows:

• Empathy: Listen carefully to what the end users are asking and trying to achieve. They may be going through nervousness, apprehension, and fear, and hence there is a need for you to stay calm and show empathy; many of the concerns can be sought out with effective communication.
• Signed scope: Always be on top of signed scope, whether you are an advisor/partner/customer implementation team member, and treat any unresolved request as a new candidate for change, which must then go through the change management process.
• Impact: Once the change is identified, it must be adequately documented, added to the Requirements Traceability Matrix (RTM), and analyzed with the right stakeholders.
• Workarounds: Once the change is analyzed and identified to be included in the scope, the project manager should re-baseline the project, while the implementation team should look out for various solution options.
  Similar to the original requirements' analysis, the change must also be analyzed for suitability in the original solution; also, where it's a system gap, always look for suitable workarounds to try and have minimum impact, to agree to solution specs, and yet be able to address the change.
• Pushback: If a change is identified as not critical, not system-related, not urgent, or not factual, the change management team, CRP lead, advisor, and project manager must try to push the change back to the business and the end user.

A popular methodology is Organization Change Management (OCM), which is used in training plans to ensure that the project stakeholders know what to do when a change is reported or adapted by the users of the system. In large projects, we have seen a dedicated team for OCM, who report directly to the steering committee, possess solid business knowledge and system backgrounds, and are efficient in soft skills. When there is no dedicated OCM team, there should be a designated person who owns this OCM effort, known as the change management lead.

The CRP lead, change management lead, and the project manager must utilize a lot of political power to fight battles where the change that is requested from end users is not something that is a must-have, is out of original scope, and the impact to the business is not high and is not needed immediately. This is possible when changes are properly logged, analyzed, and approved before any effort is spent on implementing the change.