Shoot the Systems Integrators, save the future SAP projects !

[Former Member]

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 http://blogs.zdnet.com/projectfailures/

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.