Skip to Content

Are you ready for the new SAP implementation methodology?

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.

You must be Logged on to comment or reply to a post.
  • Very interesting post Mark. As a Business One partner we have been (unknowingly) working to many of the principles of RDS Methodology for some time namely:

    Scope is defined up front and signed off by customer before work commences

    The customer takes ownership for aspects of the project like testing

    Changes are not allowed as they impact project cost and delivery date

    Scope creep is allowed within agreed tolerances otherwise a change request is needed

    We based it on Prince2, ASAP and Agile to ensure we had a solid structure that can fit in to a short timescale and a customer budget.

    • Hi Tim,

      Thanks for the comment.

      I think the methodology and process will work with both parties aligned.

      My biggest concern with RDS is the change management and comms within the project.

      I think there needs to be some spare budget for changes – or a second phase to ensure the solution aligns to business goals.

      • I agree, if the end customer has embedded Prince2 in their organisation then they should allocate a Change Budget anyway. It seems obvious but not many of our customers do even though we advise them

        • people are taking SAP at face value.

          Fixed price means fixed price – however they need to realise the fixed price is based on the fixed scope. change the scope and the price changes.

          I think in their positioning slides this should be drawn out more.

    • Hi Tim,

      how do you reconcile Prince2 and Agile? from what I have seen from those companies and consultants that have been trained in and implement it they are about as far apart as you can get – or perhaps that is just the people I’ve met?

      • We have a good team with a mix of backgrounds and have taken a “best of both worlds” approach. It seems to work well for us on Business One projects.

        • Exactly, not prince2 nor agile are the goal. Your project end result is! Apply the methodology that most suits your needs. Don’t be a method-fundamentalist. Be pragmatic.

  • Nice post Mark, thanks for starting up the discussion.

    Hope that we do not skip doing things agile with SAP. Just got used (and very happy with it 😉 to the close collaboration between business and IT folks, focus on top prio’s and the fast and frequent delivery.

    As far as I have understood with RDS you can have a working solution in no time. But as you said with a fixed scope. How about using the RDS as a sort of sprint 0 activity. Install the base, do some demo’s and then define your project backlog and start sprinting. Or am I missing the point?

    Kind regards


    • Hi Twan,

      I think you have got it spot on.

      For some customers – the RDS can be used to build a PoC or first sprint (drop).

      A second sprint could be planned to review the solution and detail further changes.

      The next sprints could be the changes.

      The issue could be that there are now over 100 RDS’s and not all of these would use this model.

    • How interesting – we both came to the idea of using RDS as spike in an agile implementation. A pretty big spike! I think from what I have seen though, with the inherent documentation “overload” that is part and parcel of RDS and the lack of understanding of what is being delivered at a code base level, it would be hard to argue that an RDS could really fit as an agile sprint. But at least it would be “production ready” 🙂

  • Very interesting post Mark,

    I’m not sure that I’d see RDS as Agile – in fact I’d push it far more towards waterfall. It has the same steps and inherent inflexibility, and therefore possibility to have a fixed price. The difference is just that much of the waterfall steps we all know and hate are done up-front.

    I see RDS as the short-term solution to bidding against SaaS solutions, both give you a running solution in a very short time frame, allowing SAP to come to a more level pegging with the SaaS offerings. Although I would suggest running the Agile approach over the RDS implemented solution after it has been put in to make sure it actually matches the business requirements. My long term solution is of course build a SaaS solution that you can sell yourself and implement that using Agile methodologies (strangely enough one might muse that this is exactly what SAP did with SuccessFactors and how it is implemented.)

    I’m interested in your comment “As with the change to Agile, the project manager become critical for the success of the project” Not so much that I disagree that strong project management and change control are required for an RDS role-out, more that I’m not sure that the same could be said of many agile approaches. It is more my understanding that scrum for instance doesn’t have a project manager –

    I’m interested in the agile projects that you’ve been involved in, how did the role of the PM play out?

    Thanks for a very interesting post.

    • hi Chris,

      There are various theme’s to Agile.

      The PM was called the “scrum master”.

      He was the facilitator of the team – documented the scope of the sprint, updated the project plan for the sprint, ensured the correct resources were brought into the sprint phase at the right time,

      In a two week sprint – we defined the scope day 1 with the team. The functional and dev team worked up to day 6 (out of 10) – days 7-9 were testing (internal test team) and 9-10 was cutover, and support. Bug fixing took place between 7-9.

      consultants were part of various scrums and sprints, so the scrum masters needed to ensure the right resource was available at the right time.

      we found that there was work to convert standard PM’s to scrum masters – and I believe there will be work required to turn PM’s into RDS PM’s.

      I can update the blog when i have more facts around actual implementations and issues.

    • Officially there is no PM in scrum. A scrum master facilitates the scrum process, does not lead the process.

      But in my experience in doing SAP projects agile, there is still an important role for a project manager next to a scrum master. The scrum master focuses on the internal processes, the realization of the scope by the team in close collaboration with the product owner.

      The project manager facilitates the teams environment. Budget, steering committee, cutover, training, … especially in a multi scrum team environment really helpful for your scrum team. And when you work in a political environment let the PM manage the politics 🙂

  • This is irresistible debate, so I must join 🙂 , sadly this discussion/debate has happened whenever we do a small tweak in an existing process for certain requirements and name it differently. I have been managing deliveries at micro and macro levels for a long time now, and recently managing projects along with deliveries. I am also a certified scrummaster(so know a bit on scrum and agile principles 😉 )

    Let’s see RAD(Rapid Application Development) first. RAD is possible if we know some part of the requirements for sure. We develop this and demo to customer. By then, either some more requirements get known or we get suggestions from the demo and do another rapid development.

    Risking oversimplicity, SCRUM is RAD with processes and discipline around it.

    Now RDS does waterfall with clear responsibilities around it, for e.g. with testing owned by clients. From what I read here, I do not see any change in process. I will be happy to be corrected here, if someone thinks otherwise. Doing so, it also brings back the problem due to which W.W. Royce(who gave us waterfall model) descibed in the same model why it is a ‘flawed, non-working model’. He explained that such models are only suitable for doing builds of hardware, which can not be easily changed.

    Similarly in RDS:

    The scope is fixed and defined up front.

    Most of the decisions are made prior to the start of the project.

    Changes to scope are not allowed without a change request.

    So, IT IS RIGID, and the last point means that it tried to solve the ‘flawed waterfall model’ in the usual way. So, if at all, I will compare RDS with waterfall, not with AGILE/SCRUM.

    What RDS says is that if SCOPE is clear, we can deliver very quickly, on budget and within defined time. This again may be true of product development organizations, or some consultant-clients who already know what they need(yet to find or read about one!) So, we will keep doing RDS after RDS for customer and make it RAD 😛

    Sorry, but I politely disagree that this is a useful methodology for any application software development, let alone complex ERP implementations(relatively). But this is only the usual flexible me who has opened up to many methodologies and found them trying to be too idealistic or patronizing . I will be very interested to read further views on this.

    • Excellent discussion folks!

      One of the key benefits of Rapid Deployment Solutions that I believe is being glossed over here is the preconfiguration based on best practices. Yes, the fixed price can be offered because the scope is fixed, but this scope is based on SAP’s experience with nearly 200,000 customers, in order to efficiently and quickly put in place the standard processes by solution. For example, take the SAP CRM for Sales rapid deployment solution: why should a customer configure how they process a contact, a lead, and opportunity? What real value does that bring?

      On the other hand, there may be some areas where solution uniqueness can really payoff, and bring true competitive differentiation… maybe it’s in their quoting process, maybe an area of post-sales service, etc. The whole point of rapid deployment solutions is to move forward quickly and efficiently for where the customer shouldn’t re-build the wheel and can take advantage of the best practices in the solution, and then build out, whether it’s T&M or an engineered service to layer in solution uniqueness, all fueled by the savings achieved by that rapid deployment solution.

      Take a look at the SAP HANA rapid deployment solutions. When was it possible to implement an SAP innovation in less than 5 weeks and to know what you were going to have in place at the end of the day? With the rapid deployment solutions for HANA, customers get those data models in place, leverage the predefined reports… they get a very fast ROI, and then of course from there, they are going to start thinking about what their own specific use cases will be. But rather than doing that upfront, they’ve already had a success on their hands and see the value and business impact that SAP HANA can delivery. Ditto for Mobility, Analytics and Cloud…

        • Ah, well this was an informative read Peter Russo. This reinforces all my points per RDS. Luckily these RDSs are provided by SAP or partner companies, so this waterfall model-variant may work per RDS with an assumption(absurd for clients who believe what they do is good practice, and new implementations should preserve the way of working) that the best practices which are the basis of design of these units are indeed used by customers, so are hard requirements. We are talking of having deployment units(components), and trying to solve the build problems in deployment arena, thus talking more and more of assembly and less and less of build. These RDSs may be mixed and matched to suit the customer requirements as closely as possible to provide a base version of solution. Further iterations then may use further RDSs and custom development to fill in the gaps rapidly.

          Change management is indeed difficult then, what with RDSs having prerequisites and versions and compatibility issues with other RDSs. Put in change request from customers which makes one of the RDSs in the chain unsuitable or worse a different but incompatible RDS is found suitable. Technical validation as in ADS process may help here. Hmmm looks like this may work if suitable hooks are available to enhance RDS functionality. Also, need to understand what causes RDS incompatibility-is it use of different versions of software layer(like EA-HR) making this a harder break, or just some functionality/behavioral difference taken care more easily if enhancements or extensions allowed. Need to closely look at how RDSs are delivered for use by clients. Reserving any further comments till then.

          Nevertheless, this appears a good approach for new implementations where there is a good (>50%) match in requirements which can be met with RDS mix-and-match. And isn’t this an ideal state that CXOs dream of- industrialized software. This makes SAAS work like a dream. This also fulfills what I personally call as ESAAD(Enterprise Software As A Delivery unit)- a phrase coined by me earlier when the SOA and ESOA were being talked about and best-of-breed vs Single provider discussions were in vogue. My opinion has always been best-of-breed deployment/delivery units from a single provider or with clearly defined compatible interfaces from “partner” vendors, and happy to see RDSs combined with ADS almost reach there, but as I said will need to see this up-close to comment further. In today’s terminology, to quote from an authority in this area, this is agile manifesto on top of LEAN.

  • My name is L.Rameshbabu.Iam very much interested in the RDS methodology.

    Start deploy and run.My question is how the implementation differs from one user to another

    user.Please share your experience

  • SAP’s Partner Service Delivery offer Partner Quality Programs that guide and support SAP Partners through all SAP Methodologies and offer a Quality Accreditation on completion.

    Read about how partners are benefiting from these services

    Success Stories

    S user required to access portal page and ebook below.

    Partner Quality Hub eBook

    PQH Portal Page

    To organise an introduction and how to participate contact your Partner Services Advisor or contact

    • Hi Niall, I appreciate how your comment has relevance to the post, but even a “on the topic of this post and how RDS can help you” would have been appreciated before all the very useful and helpful links! I love SCN because it sells SAP through it’s member’s contributions, not because it is an open sales platform for SAP.

      Thanks for your contribution to the discussion. 🙂 I look forward to more partners being engaged in this “new” methodology.

      • @Chris & Niall

        The question here should be – do Partners have to prove their knowledge of the new project methodology prior to being approved an RDS Partner?

        Do contractors that SAP employ to deliver RDS projects have to attend training?

        Would it be worth having a SAP Partner delivery acreditation? This will have its pro’s and con’s

        Time and cost being the biggest con.

      • @Chris apologies

        @Mark I am happy to share qualification details required also coming around the corner are more offerings on how SAP approach delivery of all type projects.