Having worked on a number of full implementations of ERP, as well as smaller projects that implement specific functionality in mature SAP solutions, one of the critical success factors is managing change. I was always told - put the hard work in at the start of the project and the implementation will become easier. Some clients are too eager to begin the build of the system that certain detail in the preparation and blueprint phases are missed. The outcome of this, are late changes are requested by the business that normally impact tight timelines leading to further pressure on a normally stretched project team.
The key message here is to fully engage with the business at the start of the project. Don't be afraid to go into detail in your workshops as all of the detail you capture will reduce the chance for change during the project. Further to this you need a strong business representation to reject all changes that are not deemed critical to the success and the agreed go live.
The diagram above is a representation of the potential impact of changes that are made during a project lifecycle.
Duration the preparation phase of a project the scope is normally agreed. However you should clearly state the areas that are in and OUT of scope. By carefully getting agreement of what is out of scope, and strong project management significant changes during later phases can be stopped. The significance of when changes are requested becomes clear throughout the project lifecycle.
Take a change that is made during the Blueprint phase. The likelihood of changes during this phase will generally be high as the Blueprinting phase will provide further detail to the agreed scope detailed in the Preparation phase. Any change requested here, needs to be verified against the agreed scope, making changes to the signed off scope if required.
When a change is made at the start of the realisation phase, the impact has now grown - both the scope needs to be reviewed and amended, as well as reviewing and amending the signed off blueprint document. Changes may need to be agreed as the realisation phase represents the system build and it could be some of the assumed functionality may not fit the business requirement.
Moving through the project lifecycle - at the end of realisation any changes requested here, would require all of the steps as at the start of the realisation phase, as well as, the unplanned system build, and also the unit and integration tests will need to be amended and repeated.
Finally during the final preparation phase, a change that is requested here would be due to a significant issue from User Acceptance Testing. Obviously if this is business critical the change will need to be made, however the impact to the project will impact everything that is included at the end of realisation, as well as potential impacts on training documentation, data migration routines and User Acceptance Tests.
Once UAT has been signed off - the hard and fast rule has to be NO MORE CHANGES. Normally in a project lifecycle the duration between, UAT and cutover is normally short, any change requested here can impact the go live of the project.
Remember, functionality can be applied after the go live, you need to determine if the change is business critical, i.e. will impact the client -affect the ability to sell, provide wrong information to customers or not allow warehouses to receive stock.
So the message here is clear, to all project managers, key business users and integration managers, you need to be in the ear of the project sponsor advising them, that changes are OK, but lets get them raised early. The indirect costs associated to a last minute change never get fully recorded. Your project team will be under significant pressure to deliver, so the project sponsor needs to be brave and strong and knock back all non critical change requests.