Skip to Content

Shoot the Systems Integrators, save the future SAP projects !

I have been following Mike Krigsman’s blog for a while now, and he is one of the few people who present a balanced view on why and how IT projects fail. If you have not seen it yet, please check it out at


In my career as an SAP consultant, I have seen my fair share of failed projects. Some of the best programs I wrote as an ABAPer never saw the light of day, thanks to that project being cancelled for overshooting time and budget.. I have also been sent as part of rescue team to other projects – some times we could pull them back, and at others we had to watch the ship sink.


So the big question is “Why do some of these big SAP projects fail ?”


There are many reasons – and hence there is no simple answer.

The three popular answers are

1. Systems Integrators are absolutely clueless – and they are to blame. They give jazzy sales presentations and do not deliver to their promises.

2. SAP, the company that made the software, did a poor job with creating the functionality – and that there were lots of enhancements and work-arounds that were needed before the system could work for the customer.

3. Customer is to blame. They did not understand the implications before they bought the software from SAP and hired the SI to implement the solution.


There is of course the problem of blaming all three parties – “Is blaming all three at the same time the same as not blaming any one” ? I would vehemently say “No”. Complex problems do not always have simple answers in black and white.


In this blog – let me express my thought on the SI problem. I will post follow up blogs on the other two after this to complete the picture. As always – these are just my opinions, and not my employer’s.


Why do you even hire an SI in the first place?


The idea behind most hiring decisions is that the SI has done something similar to the solution the customer wants some time in the past, probably multiple times. So this is a way for customer to reduce the risk on the project. SIs also bring some kind of tools, accelerators and best practices to the project that should help with the efficiency aspect. The question is – how much of this is actually put to practice in actual project delivery?


SIs also get hired to augment the customer’s internal SAP COE in project delivery.


Watch out – you can fail before you start !


Assuming SAP was the right solution for the customer in the first place, failure can start right at the point where a customer issues an RFP. Poorly crafted RFPs usually result in poorly executed projects. If the customer did not know what they wanted, then who would? If the customer does not have a qualified team in place to create a good RFP, then they should hire some one external to do that.


Then comes SI selection. An SI might have done similar projects in the past – but all the people who are coming to your project might not be the ones who worked on that similar project in the past. Most SIs will have some kind of ramp plan to get the rest of the team up to speed. But this might not always be the case – and the customer should take an active interest in making sure a plan exists to make sure all the key people in the project are well equipped to make use of the work that has been done in the past. Also, the customer should closely interview the project manager and key team leads to make sure they can work comfortably with each other for an extended period of time.


It is not enough to evaluate if the SI has all the skills required to do a project. It is also important to check if the SI has the ability to recover quickly and efficiently should something unexpected happen to the project. Such factors like number of SAP consultants employed, past projects, strength of relationship with SAP, references etc must be carefully evaluated before choosing the SI. Buying decisions are not simple – so customers should put their best efforts to get the right partner to implement the solution.


SIs try their best to adapt to their customer’s organizational culture. But that does not mean they are able to influence that culture meaningfully. Every company has a certain culture that impacts how the employees function and how they take decisions. And in large multi-national type customers – there will be sub cultures. All of this have to be factored in when the project is estimated. Otherwise, the project will not have a realistic time line to meet, and will be doomed for failure before it starts.


Then there is the issue of writing up the contract. Contracts with SIs are usually of two types – “Time and Material” or “Fixed Price”. Conventional wisdom is that the former generally favors the vendor and the latter favors the customer. However , the devil is in the details. When the contract is written – some boundary conditions need to be set up for scope, schedule, cost etc. Since not everything is known up-front – this usually results in a lot of assumptions. When these assumptions change – SIs will request Change orders, and it has a monetary impact. When some one complains of cost over run in SAP projects – what usually gets forgotten is that some assumptions made at the initial contract time had changed too. Without the provision of Change requests, most SIs will not be in business after running a couple of big projects.


Of course, this leads to the question ” Didn’t the SI know better than to provide this low ball estimate in the first place?”


Shouldn’t the SI know better?


Sure they should.  Most of the established SIs have metrics from past projects that help them with estimating with decent accuracy. But these estimates are based on assumptions. For example, if the number of enhancements go from 20 to 200, of course there will be an impact to cost and schedule.


Also, when new technology is involved – there might not be a benchmark to estimate against. For example – when CRM webclient came into picture, it was pretty hard to estimate effort needed to implement it accurately for all the enhancements.


There is also a chance of competition between SIs driving down the estimates. If the RFP is not written well, SIs competing for the work will get creative in their assumptions to bring down the total cost to the customer, with the intention of minimizing sticker shock. So instead of saying we expect 200 enhancements, the SI can say that we are expecting 100 enhancements now, and if that changes – they will need a change request. If the buyer is smart, then they will rationalize across all RFP responses and do an apples to apples comparison. If the buyer is not smart, the more creative SI usually will win the bid and the customer will start seeing a lot of change requests over time.


Who takes the decisions here?

The assumptions made in the RFP get verified in actual execution time. And this means a lot of decisions will need to be made. The pertinent question is “Who will make these decisions”?


I have seen extreme decision making behavior in my clients – on one hand, there are clients who completely trust the SI to make the call. On the other hand, there are others who expect every single decision to be taken by some one who works for the customer. Neither one is efficient – and every project has to spend some time up front on deciding on a governance model. Too strict a decision making process leads to a lot of wasted time and effort, and too lax a process gets you inconsistent and sometimes bad decisions. I have often noticed that such troubles are plentiful in projects that do not have a reference architecture established before micro design starts.


SIs should definitely be held to a very high standard when it comes to their recommendations on solutions. They are paid for their educated opinion, and hence the customer has every right to expect the SI to give a high quality answer. However, it several cases – it is not the SI who takes the decision. Customers(and Analysts too) sometimes point a finger at the SI (and SAP too) at the drop of the hat, without understanding the root cause. And of course the SI (and SAP) will defend their position, and this leads to a lot of unproductive “he said she said” scenes.


Trust between SI and customer is the most critical aspect in decision making. If you walk into a new project and hear a lot of references to “contract” and ” meeting minutes” ,you should smell a rat right away. Trust is hard to earn and even harder to maintain – and SIs should strive to earn and keep their customer’s trust at all times.


And finally, the “Offshoring caused the project to fail” conspiracy.


A lot of project failures get attributed to the global delivery model. I am yet to see a client who is not cost sensitive. And unless there are extremely bad experiences in past or there are legal issues, most customers want a big part of their project done offshore so that they get better pricing. SIs have been doing global delivery for many years, and they have a relatively successful model to do it. However, the customer should clearly understand what is included in the agreement with the SI. When I say customer here – I mean the IT and Business team who are going to work with the SI, and not just the legal and procurement teams.


Here are some common scenarios where misunderstandings can happen dime a dozen, and SI gets blamed readily.


1. Customer signs up for global delivery, but only for 8 hours a day local time, say in India. However, when project reaches a critical stage, customer expects 24 X 7 coverage from offshore

Most SIs will do something better than the contractual obligation of 8 hours, but there are practical limitations. Every one in offshore teams might not have a broadband connection at home to work at night, and there are laws in some countries were women cannot work in an office past a certain time and so on. 24 X 7 coverage is more costly than 8 X 5 coverage, and that is the usual reason why several customers ask for just 8 X 5. But all that history is readily forgotten in the heat of the moment – and every one gets frustrated. So before they say no to anything other than 8X5 offshore time, customers should think hard.


2. Absence of a ” frequently updated” communication plan in place.

Every project will have a bunch of problems. You should know up-front on who to call and who to escalate if there is a problem. A lot of grief in projects can be done away with, if all parties agree to a communication plan and stick to it.


3. Bypassing the agreed up on protocols

Processes and Methodology exist for a good reason. Follow them, or live to pay the price. When teams are distributed all over the globe – then specs should be crisp, and the team onsite should be willing to field calls from offshore team early in the day or late at night. Most SI teams have a process in place for this. However, the process breaks when customer employees, who are not used to these odd hour meetings, do not play by the rules. This is a tricky situation – customer leadership usually signs a contract saying their team will be available to do such and such, but they might not always consider the views of the actual employees who have to live through this for several months or years. This leads to immense frustration for all parties.


4. Cheaper does not mean lower quality.

I get immensely frustrated when I hear people equating the lower price of offshore resources to lower quality. This is completely false – and I can vouch that some of the smartest people I have worked with in SAP space are from offshore teams. There are 4 SAP Mentors that work for my employer including me – and 3 of them are in India, and all three are more accomplished in SAP than I am. The decrease in quality mostly happens when the delivery process breaks – and not because people have poor skills. But since process does not have a face, and people do – people get the blame.


5. You cannot have your cake and eat it too.

Offshore delivery usually follows a factory model. And like in manufacturing, it needs standardization to succeed. Standardization is not as easy as it sounds, and the offshore team rarely has any control over the onsite team or the customer. When offshore gets a spec, they review it internally and raise questions to the people who wrote it. Reviews are usually done by an experienced person who can consider all aspects of design. And once the reviewer gets all the clarifications, the spec is handed over to some one else, probably with less experience, for development. The development is then reviewed again by more experienced people and bugs fixed before sending it back to onsite team, where a second review might take place. This is a tedious process – and it needs a certain amount of time to finish. When offshore teams have to deliver in a shortened time frame, usually due to some pressure from onsite team or customer, then they have to let go of some part of the process and this has a big impact on quality. Moral of the story – if you use global delivery, you should clearly understand the process and the estimation process and see if you are comfortable with that. You should commit to giving the offshore team the estimates number of days to finish their tasks – if you flog them to rush through the process because scope changed or something – then you should understand the risk on quality and be able to live with it. If you are not comfortable doing this – then spend some more money and get more SI resources onsite where you save on the communication time (and can may be use an agile model) as a trade-off for cost.



You must be Logged on to comment or reply to a post.
      • Project(IT or non-IT) fails or successful because of 3 factors:
        – People
        – Process
        – Technology

        Often sales department in IT firms are not in sync with delivery and to win projects they promise sky.
        Unfortunately many times delivery department also follows project management practice for sake of doing it, which result failed or delayed project.

        You need strong governance in place to avoid delayed or failed projects.

  • But obviously compelling discussion content. Vijay you are fast becoming the owner of the title “most commented on blogger”.  It appears that only one of your many posts failed to garner comments.   Would that be because the discussions around that topic happened in other mediums (ie twitter)?  I agree with Vitaliy.  You do have a love to open Pandorra’s boxes.  But somehow you elegantly avoid all the biting and stinging things coming out.  Well done.
    • I did not realize that all but one of my blogs had some comment or another. Thanks for pointing it out, Marilyn. That is really nice – it shows how involved our community is. And as I have said before, community provides 75% of the content of my blogs via their comments – and I love interacting with fellow SCNers here. I learn a lot in the process.

      The one without comments is actually the one about which  I joked with Jon Reed that one of our mentor guys will probably come with an axe after me. Looks like I flew under the radar. I think my content was not interesting enough to attract any one to read it. Hopefully, I will do better next time around.

        • yes I did – saw it on twitter, and I even posted a comment under it. Benioff has a real knack for starting interesting conversations, and getting great PR for his company due to that.
      • Vijay, you do a great job of getting conversations going and, as Marilyn says, for wading into provocative topics in thoughtful ways. I’m looking forward to the rest of this series to see how you view the role of the customer and the vendor in project failure. I tend to be wary of this topic only because I find that each “failure” tends to have a unique anatomy, with different parties dropping the ball. Michael Krigsman has certainly documented these problems with great detail in his blog.

        I think Benny is right that poor communication is often a fundamental flaw. A lot of it, in my view, is a lack of clear and realistic expectations of what software can do – and the pitfalls of overcustomization. And let’s not forget overzealous salespeople and SIs that are more concerned with billing huge hours than with solving problems and passing on knowledge. And I’m not just picking on the big SIs – smaller SAP partners have made similar mistakes – cashing out on a project that ends of failing and poisoning/harming their rep. Look forward to next installment!

        – Jon

        • Failures are unique – I agree, but people tend to forget that the number of succesful projcts far outweigh the number of failed projects. Good news hardly ever gets good press. I have very seldome seen an analyst praising an SI for a succesful implementation, where as they are ready to pounce at the slightest hint of failure.

          I am organizing my thoughts on SAP’s and customer’s contributions to this – and hopefully I should be able to post my thoughts in few days.

  • Ofcourse, certain part of this article is arguable, but the failure reasons are real. I would not blame the customer, but the SI Managers and the Product fulfilling the business expectations.

    And, on the flipside, for one of the failed projects I wrote a custom program to fill in the missing functionality, 18K lines with complex logic for 9 months. that code never saw the light 🙂 Code was successfully testede but the Project 🙁

  • there are a couple of things you did not mention about off shore, but I find quite important. The most common problem of all failing projects to me seems to be in communication. Whether it be miscommunication or no communication at all it always seems to go that direction.
    Now, with offshore there are some specific communication problems, such as that it’s far away (otherwise it wouldn’t be offshore 😉 and once you haven’t done it you will not be aware what that means in detail.
    Another thing is language. Although English is quite common all over the place, the opinion about what is good English seems to be quite local and unfortunately depending on nationality. And there is nobody specifically to blame, as we all carry our own part of this – which does not help communication either (We just had the case of a german politician switching to EU politics – a language disaster I must say).
    Last but not least: The cultural difference. I once had a course about that and it actually helped a lot. I can only recommend it. Obviously it is hard to convince a customer to do such thing before engaging with offshore, but it would be worth a try. It makes things so much easier.


    • Completely agreed, Benny. Cultural differences and language barriers exist all the time in geographically dispersed teams. I have had this issue in Europe, Asia (including India and I am an Indian), Americas ..every where. A lot of people from English speaking countries frown and mock when some one from a non-English speaking country talks to them in English, and that is downright unfair. If these guys try to talk in Mandarin or Hindi – we can see who is funnier 🙂
      And due to “halo effect”, this gives them the impression that the guy not speaking like them might have lesser technical abilities too. I am not saying every one is like that – just that I have seen a LOT of people doing this.

  • Communication is knack, but does not mean you cannot learn the art especially in IT projects. I have seen many times same development work/issues get resolved quickly in 2-way communication every time by some and not by others by effective and efficient communication.
    Also what are some of the primary reasons? the reason for this I found at-many-a-times, some folks are not motivated to doing the right thing and look for reasons to blame and letting it fail. Sometimes it also requires some hand-holding, which some on-site folks are reluctant to perform. In a global delivery model you need to be able to put your self in the other person’s shoes to be effective.

    I am reminded of famous quote from a movie by a legendary Indian actor who said English is a funny language, it is indeed.