How to control scope creep

By Katrina Burke, Head of Enterprise Solutions on
In the first part of this blog (The art of the RFP) I dealt with the importance of being specific when defining the business processes that will be impacted by the intended project. I now turn my focus towards mitigating the problem of scope creep.

It goes without saying that the design phase of a project is critical.  It’s here that an organisation ensures its business processes will be supported to enable its performance. During design phase, an organisation works closely with its selected system integrator (SI) to map out and lock in what will be delivered.  Unfortunately, this is also the phase that puts the budget at risk as the mutually agreed scope starts to creep.  This can happen for a number of reasons:

  • Additional processes come to light that were not confirmed within the scope
  • Business nuances where processes are done a specific way, which may result in additional configuration or even development
  • Different divisions within the organisation undertake the same business activities in different ways
  • Business initiatives change resulting in greater scope to support an initiative

There are two key methods available to provide greater rigor around scope creep.  Firstly, start the design process with a working standard SAP solution and secondly, implement a Design Authority that challenges all scope changes.

Start with a working system

For many consultants this is not a new concept. SAP has been driving this approach for many years and the new SAP Activate methodology has this premise at its core.  Despite it being a known approach, it is often ignored.  The design phase of projects commence with a shopping list of requirements and a white board to collect more.  This quickly becomes an exercise in the creation of a “Gold Plated”, heavily engineered solution that no longer resembles the software selected.

Prior to any workshops commencing the SI should establish a working environment so that during workshops the question is not, ‘What do you need?’ but rather, ‘This is how SAP does it. Is there any reason why this wouldn’t work for the organisation?’

Scope often increases when the business user cannot visualise the solution they are getting and hence they can fall into the trap of conceptualising the solution independently of the software that has been selected. Demonstrating solutions on a real working system makes the process tangible and applicable. This has the net effect of having greater alignment with standard SAP delivered processes and reducing the need for overly complex configuration that can occur when you ‘crow bar’ the process into SAP.

Implement a Design Authority

The primary role of the Design Authority on a project is to challenge any non-standard process and every listed development for WRICEF (workflows, reports, interfaces, conversions, enhancements and forms).

Before a design element is written into the design document of a functional spec, it should first be put before the Design Authority.  This Design Authority is often peopled by representatives from the SI and the customer. However, the decision primarily rests with the customer. Often a non-standard process or WRICEF identified in design will result in a change request to the initial scope.  Hence it is critical that the customer is fully across why it is needed and what the cost implications are of including it, as opposed to changing the business process and excluding the item. 

In effect the Design Authority is presented with a business case for inclusion of the particular process in question. This works well if there is a regular weekly meeting and a register to record any suggest deviations from the standard solution. These can then be discussed, and either an increase in scope approved or denied.

For further information please contact us at info@uxcoxygen.com