Impact of change during the life-cycle of a SAP Implementation

21 April 2010

Mark Chalfen

Mark Chalfen

Former SAP S/4HANA Global Lead

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.

 newnewnew

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.

View comments

Comments

Blog post currently doesn't have any comments.

About the author

Mark Chalfen

Former SAP S/4HANA Global Lead

Mark tells it straight - as an ex-boxer, what else would you expect?  Both his knowledge and experience of SAP products allow him to cut to the chase dispelling myths and hearsay.

As a result of working closely with various SAP Finance Product Management teams on product development, Mark understands these products inside out. This depth of understanding has led to him become a ‘thought leader’ in his field; after all, it is not often SAP consultants have helped shape and develop the very product they are selling.

Having such a strong relationship with SAP alongside being an SAP Mentor and Moderator means that Mark has an extensive network within SAP. For clients, this relationship proves to be a huge advantage and leads to configuration issues being resolved rapidly.

Mark has worked on short proof of concepts through to year-long multi-million pound global roll-outs. However, no matter how large or small the project, the true value Mark brings to his work is in the guidance he provides to senior stakeholders. In essence, he assists them to implement more effective processes and drive better behaviours within their finance teams.

Helping organisations transform their business with SAP S/4HANA is Mark’s current focus. The benefits of S/4HANA are numerous, including the simplification of tasks, embedded analytics and improved user engagement. Whilst the eventual move from SAP Business Suite into S/4HANA is inevitable, the journey to it is not always clear. Mark’s ability to understand an organisation’s needs coupled with his deep understanding of S/4HANA provides clarity and eases their transition.

Bluefin and SAP S/4HANA - welcome to the one horse race

We use cookies to provide you with the best browsing experience. By continuing to use this site you agree to our use of cookies.