My experience with SAP offshore development is that no matter how detailed your spec is their lack of experience with standard SAP transactions and functionality means they will never properly test their own creations. Their results are more than just full of bugs, often times they crash when attempting to do even basic testing. Repeat testing by expensive functional resources happens so frequently and consumes so much hidden time from parallel project activities that entire project timelines are frequently affected.
Functional resources have to babysit and handhold these SAP offshore resources through the whole process because of the language barriers and lack of experience. More functional time, more project management time, more unplanned distractions from functional Realization activities and your entire project timeline can be wiped out. If that happens you have to pay even more for a missed development date because you have to move your go-live date. And that cost is completely hidden from you by some of the shell games they play on their supposed efforts. All of that functional time and the risks to the project timeline point to some of the real hidden costs of SAP offshore development. Develop, test, bugs, fix, develop, test, bugs, fix, rinse and repeat at least a dozen times.
A common SAP offshore practice is to keep throwing “crap” at you saying it is “done.” With all of the crashes and bugs that are so common with offshore development, and especially all of the program crashes, how much testing could they have done? The bigger question is how much is this really costing you and how do you find the hidden costs?
SAP Project Timeline and Budget Due Diligence
Because of the nature and pace of SAP project work whenever the issue of blown budgets and blown timelines come up most companies rarely perform root cause analysis or due diligence. Instead the accusations and recriminations fly in the heat of the moment. Meanwhile the offshore developers keep saying “we finished x development on y date… the functional teams didn’t support us…” or “the specs were bad and we had to make 20 changes…” You name it, the extent of the excuses are never ending.
Evaluating Hidden SAP Offshore Development Costs
Because of how SAP “functional” consultant time (needed to support the offshore development) is hidden from you it never shows up anywhere in the rates you were quoted. You really have no idea about the real Total Cost of Ownership (TCO) for that offshore SAP development. The offshore company constantly claims the “specs were not detailed enough” or every microscopic change and adjustment becomes a “change order.” I’ve even seen this where standard SAP functionality was completely broken by the development and the developers insisted because there was nothing spelled out in the design spec about allowing standard functionality to continue working a change order would have to be separately paid for!
On new SAP implementations the functional time premium can easily cost you 50% to 75% (and in some cases even exceed 100%) of the total development hours. Think about that for your next quote as you try to put the pen (or your spreadsheet) to the numbers. Have you really factored in the amount of high priced functional resource time needed to support those “inexpensive” offshore developers? Between writing “super enhanced” specification documents, repeated endless functional testing of buggy SAP development, “training” of inexperienced developers, language barriers, “babysitting” the actual development, and the lost opportunity to focus on other functional Realization activities can kill any supposed savings. It’s all a shell game. You pay just about the same amount (and on many occasions even more) with far more headaches and lower likelihood of making your go-live date.
Even after all of this, there is still one more hidden cost that is not realized immediately at go-live–, the cost of poor coding. You may have significant performance problems, constant bug fixes, and a whole host of other maintenance activities that you never planned or budgeted for. Now this is true of any development but because of the language translation issues and the modest (at best) quality of coding you are likely to have incrementally more production maintenance costs with the offshore development.
Some Considerations to Help Reduce The SAP Offshore Development Shell Game
First and foremost NEVER accept the offshore development group’s code review options. One way you can help to combat so much of this is to budget for at least one local developer, even at premium rates, to serve as a quality checker. They do not have to review all of the code from all of the developers but they should look for the “tells” of experience over inexperience. And your SAP statement of work (or SOW) as well as your contract with the offshore developers should include various protections about the quality and expectations of the development work and functional consultant time and contributions. That SAP SOW should also include some definition around what a “change” is and what a “defect” is. Without that everything will be considered a “change request” and destroy any supposed savings.
Next week the wrap-up part 3 of this series: Where Does SAP Offshore Development Make Sense? There are some situations where it is a great cost saving alternative.
Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.
- Sapsow com