Back in the day when I was working on implementing ERP system implementations the ASAP methodology was seen as best practice and used by SAP Partners and SAP alike. The consultants within the team had to learn the various different phases of the project and understand what was expected to be achieved. A typical ERP project for a large enterprise could not be performed in less than 12 months. This lead to the cost of the projects being deemed expensive by the client. The main gripes from clients related to the time and cost of the projects and the lack of tangible benefits realised during the implementation.
Over the past few years the Agile methodology has become more popular for SAP implementations. One of the reasons for the switch is due to the change made by SAP within the product suite. 15-20 years ago SAP had ERP or (R/3) as their core product which tried to put a number of systems and
processes into a single system. Overtime SAP moved away from this model by releasing products like CRM, SRM, SCM, BI and started acquiring a number of solutions as well. The main difference between ASAP and Agile was the speed new functionality was released to the customer. By reducing the scope and releasing small chunks of functionality the business started to feel the benefits earlier with less cost. It also helped prioritise the scope of the functionality as the items that provided the least benefit would not get prioritised and may never make it.
For a consultant, there was a big learning curve. I worked with Agile around 4-5 years ago and it was a big shock. I had to learn about “sprints” and “scrums” and I had to work much more as a team player. Plenty of consultants struggled with Agile, and technical consultants sometimes found the change more painful as they had to open up and communicate as part of a wider team. I quickly saw the benefits of the methodology not only from a customer delivery point of view but also personal growth. I had changed my perceptions around project implementations and I currently promote Agile implementations even for large customers with large scopes and timeframes. This opinion was backed up a couple of years ago with a visit to Walldorf and a chat with a Product Manager. Whilst in his office I saw some new wallpaper but on close inspection it was the detail of the current sprint that they were part of. I believe and I am happy to be corrected here, the Agile methodology has been adopted by MOST SAP Product Management teams which allows new functionality to be released more frequently which is great.
However the new methodology I am referring to is not Agile but it is the “RDS methodology”. As far as I am aware there is not a formal name for this so I will refer to it as methodology “X”. The new methodology aligns closely to Agile but it is far from Agile. From a consultants point of view there are a number of differences.
- The scope is fixed and defined up front. Normally the scope is defined during the project not before the project.
- The ownership of tasks will differ. For example testing and training is the responsibility of the client not the SAP Partner
- Most of the decisions are made prior to the start of the project. Within Agile the team will decide the priority of the releases and work closer together.
- Changes to scope are not allowed without a change request. Agile allows scope creep as long as it falls into a sprint.
What does this mean to consultants?
Consultants that have moved from ASAP (Waterfall) to Agile should be able to move to “X”. The RDS methodology of “Start, Deploy and Run” is pretty basic and allows for rapid deployment.
The biggest concern I have with the new methodology is how changes are managed. The RDS is fixed price, scope and time. Any change to the scope will impact the price and time of the project. Customers will be used to Partners allowing them to make changes, prior to the Blueprint, and squeezing in changes by keeping the timeframe. Customers and consultants need to learn the scope of the RDS as this is the legal requirement. It is similar to a consultant sticking to the scope defined in the Blueprint, but the biggest challenge will be the customer not asking for additional changes.
The customer should be aware that changes are not allowed, and if they are required they will impact the price and time. It is therefore prudent for the client to ask for a change fund to be built into the project plan. RDS although popular is fairly new. One of the messages from SAP is that customers come back to the RDS methodology once they have implemented, and there are customers who have bought programs of RDS’s (6-10) in one go.
As with the change to Agile, the project manager become critical for the success of the project, and it is recommended that both the SAP Partner and the customer have their own project manager. They will need to work closely to align the expectations of the consultants the customer’s business users to ensure it is a success. It is clear to me that a project manager with RDS experience will become a sought after resource over the coming months.