SAP Project Failures – it ain’t a binary issue


We all have our perspective on why SAP projects fail. Michael Krigsman, Dennis Howlett, Michael Doane , Vinnie Mirchandani et al have riffed at length on this topic. I am not sure what is left to be said, and then I saw this post today by Dennis.  Intransigent clients to blame for failed SAP projects?  . I wondered aloud on twitter whether I should just add a comment, or blog as a reply. Dennis said I should riff, and here I am riffing 🙂 . As always – this is just my personal view, not my employer’s view. Intransigent is not a word I have ever used myself, and I had to look it up. I will save you one google search as the prize for reading my rant – it means “uncompromising”.

Since Dennis is comparing the positions of Michael D and Michael K – you might want to read their pieces first (links in Dennis’ blog above) before reading further. Just as Dennis agrees and disagrees with the other 2 gents, I also agree and disagree with Dennis, and with both Michaels. I am sure readers will also agree and disagree with me and all the other guys and gals who opined on this topic. In short, this is not a binary issue at all. I agree with Dennis on that one.

Michael Krigsman deserves credit for his Devil’s triangle concept. SAP and Customers have some share of the blame when projects fail. Off late, I have started to say “Devil’s Polygon” – since there are other parties also involved in a failure, like the “buy side” advisers who originally told the client to buy software, or choose an SI, analysts who highlight failure, but not success etc.

Michael Doane is spot on talking about his reasons for ASAP not living up to its billing, and the problems of aiming for “just go live” as ultimate goal of a project. He is also completely correct on pointing out the failures of some kinds of COE set ups, and where he pointed out the problems of cutting training budgets. Like Doane, I am also not a fan of RDS in general. I already riffed on that here Rapid Implementation – is the promised land finally here ? . I already left a comment on his blog today with some thoughts. Racing to Mediocrity: The False Grail of an Accelerated SAP “Go Live”

Now on to where I beg to differ, and where I want to augment their view points.

Both Howlett and Krigsman both make one argument that is just not true anymore – they just use different words. (yeah, that is right – they actually have common ground after all 🙂 ).

Dennis says (emphasis added by me to show where I disagree)

Senior people I know at both Deloitte and IBM have told me they are committed to customer success. Snicker if you want but they are only too aware of the problems. Both tell me that customer expectations are never well aligned to what can be achieved as originally envisaged but claim they do their level best to make sure clients understand what is realistic during the blueprint phase. I have no reason to disbelieve their intent but we have to remember that they are employed by firms that are driven by the concept of the billable hour and not outcomes.

And Michael K says in his RDS blog that

Enterprise customers are weary of open-ended, hourly consulting arrangements.

I had a big smile on my face when I read these two statements. They are a misrepresentation of market reality . There was a period in time where most SIs did almost all contracts on Time and Materials (T&M) basis. I have not seen even 10% RFPs ( in last 5 years at least ) that will let an SI bid for a project on T&M. Vast majority of customers want the SI to be held to outcomes – based on fixed prices for well defined milestones. There are a handful of T&M projects where client generally runs the project, and just want specialized skills from SI for some roles. Essentially, the concept of billable hour is barely alive in the projects that the big SIs work on. It is still very much the concept for independent contractors.

 

When scope can be defined and bound, there is no reason to do it as a T&M project in general. And when scope changes there is an agreed up on change control process that uses change orders. That concept applies to RDS too. RDS is fixed price, but will need change orders if customer wants anything more. SIs follow the same model – so there is no substance to this argument at all.

 

Apart from the contract point of view – these SIs have a brand to protect, that will only work when customers are happy, and will do repeat business.So there is no good reason for an SI to make a client unhappy.  But like in every other buying situation – the customer should carefully consider all options and make a good business decision. SIs are not the only vendors customers deal with – most often, SIs are not even close to the top 5 vendors based on  spend for the whole company. So it is not as if the customer will just be fooled by a clever SI off the cuff . Even when they don’t have sufficient procurement expertise in house, they can get external help for that.

Dennis then quotes Vinnie

 It is Vinnie Mirchandani’s lamentthat after so many years and thousands of implementations, we still don’t have a good way of bringing projects in on time and at reasonable cost.

If IBM was truly innovative it would be automating and commoditizing much of that labor – its own and that of the rest of the market.

What I find disconcerting is that even at the top IBM confuses its nice margins from milking old software and old data centers and old partners like SAP as “innovation”.

Vinnie has the right ideas and he has a lot of experience, but I feel he is just not up to date on current state of affairs on how IBM and other big SIs execute projects. I think his expertise is more on the contract negotiation and deal management side, and less on execution side. I see from his bio that several years ago, he worked in outsourcing too. But just as deal management has changed from those years to today, project execution also has changed.  There is plenty of automation in projects – including SAP projects, and the percentage of automation tasks and accelerators are only increasing with time. And the fact that IBM is the leading SI for SAP implementations worldwide ( check SAP awards, Gartner and Forrester reports etc or just ask customers ) pretty much speaks for itself. I know from Vinnie’s blogs that he likes “new” technology and is a fan of consumer technology, and less of enterprise technology. I respect that – he is entitled to his opinion, although I couldn’t disagree more if I tried. I did try here Innovation and the Time dimension and Vinnie responded with this IBM: SAP, Sabre and Smart Systems

Dennis says about Krigsman’s Devil’s Triangle that

I don’t doubt that aspects of the analysis hold true but my experience suggests that there is always a root cause that can be identified which in turn leads to some of the symptoms Krigsman observes in hindsight.

Well – I have almost never seen a (as in one single) root cause in project failures. Project failures are multi-dimensional, and there is never “a” root cause. It is not just SAP projects – if your car and some one else’s car hits each other, the insurance companies will apportion the blame. It is just an academic fantasy to try to find one root cause. The one aspect of Devil’s Triangle that could be made better is to make it more quantitative in project failure analysis and apportion the blame based on data. I am sure Michael should be able to do this, since he has been following failures for a while now, and should be having enough data to quantify.

Dennis goes on to say

Where I believe both fall down is in the recognition that failure can almost always be traced to:

  1. Over eager salespeople minimising risks around complex solutions.
  2. Over eager buyers wanting to buy into the brand. I’ve seen entire customer panels talking about SAP Business ByDesign making this mistake.
  3. Customers not having enough information during the decision taking process. There is a lack of truly independent voices prepared to vigorously speak to reality. Way too many who know the reality are afraid of upsetting their paymasters.
  4. A lack of willingness by customers to acknowledge that they didn’t do all they could have to mitigate risk. There are exceptions to this acknowledgment – check SAP Me Sideways.

As I mentioned before there is no “always can be traced to” point of failure for projects – there are many other reasons other than the ones Dennis points out.

I agree with point 1 above. Sales people are paid to sell, and all I can say is “buyer beware”

I partly agree with point 2. But this is more true for newer products and less so for ERP and other business suite and BI software. Buying into a brand is not always a bad thing, since there is slightly less risk that the vendor will fly by night, or go belly up in short term. But on the flip side – using that as a sole criteria is a terrible idea. I don’t think customers are stupid – and what they say on panels is rarely indicative of how the majority views the world. Panels are usually organized by vendors and of course they will cherry pick a few that will speak well of their products.

I mostly disagree with point 3. Who has the independent voice ? A customer is best served by listening to multiple people and then making up their own mind . I expand on my thoughts here Let he who is without sin cast the first stone

I agree with point 4 as a general statement – but it is a lot more nuanced than how Dennis puts it. I also think SAP and SIs owe it to customers in educating them on what is possible and what is not, and then standing their ground on that.

Dennis responded to a tweet I made yesterday night from my cab ride home from the airport.

More prosaically this exchange between myself and Vijay Vijasankar, associate partner IBM last evening illustrates both the cynicism and playful snark that abounds around SAP projects:

@vijayasankarv: Landed in PHX to see note from one of my delivery project execs that she is going live successfully . Back to back successful projects yay!!

@dahowlett:@vijayasankarv you make that sound like a rarity…2 successful projects that is?

Do you see how in this example go live remains the primary goal? Doane would likely say: ‘Let’s take a peek in another year.’

I have no idea what made Dennis think “go live remains the primary goal”  or that “it is a rarity” when he read my tweet. He just jumped into a conclusion that fits his hypothesis without any basis. This go live is for a big application maintenance project that has been thoroughly planned and executed, and the go-live I mention is one of the many phases of a several year long program. And yes, we celebrate every success and we analyze every failure to the minutest detail to make sure we never repeat it.  The reason I tweeted out the back to back success is just out of sheer pleasure of watching my hardworking teams not missing a beat despite all the challenges that were thrown their way. I would have gladly explained all of this if he cared to ask before he jumped to the conclusion he arrived at. But since Dennis and I have great respect for each other, we can very easily joke about all of this – with plenty of snark mixed in 🙂 . I only bothered to explain since he put this in his blog, and I did not want readers to misunderstand.

Enough about the failures and its analysis. What about “how to prevent failures ?”.  Since failures have no one cause, prevention also does not have one silver bullet. It is a multi-dimensional endeavor that needs a lot of people with diverse opinions and backgrounds to play together. The fact that there are plenty of successes (of course less published because of poor news value) means it is not rocket science. And it is not – I have worked in and managed several successful projects, and can vouch that it can be done with sufficient common sense and patience. I just don’t have enough time and energy to go into the details of that now – since I promised to help organize my kiddo’s seventh birthday party tomorrow, and she is standing here with an annoyed expression. So off I go after I hit the publish button.

What are the plans for SAP’s planning solutions portfolio?


A quick jog down memory lane, as I am flying from PHL to SNA. About 10 years ago, I went to an SAP training course in Northern CA to learn SEM-BPS . My background at that time was all ABAP, BW and some SD/FI on functional side. Till today – that BPS training by Peter Jones has been the best class I ever took for an SAP technology, and till date – BPS is the fastest I ever came up to speed on any SAP technology.

With all its technical beauty, BPS had its fair share of problems too. One such issue was the front end in Excel. It was a powerful front end, but BEx had an excel front end too. It was not an efficient process to use BPC excel for planning, and then switch to BEx for reporting. As a result, we used to replicate a lot of reporting functionality into BPC layouts to make life easier for users.  Needless to say, users were not thrilled – and this was not good for TCO.

BPS was not the slickest way to do planning in an enterprise, but it did its job within its limitations. SAP did the right thing soon after – and brought out integrated planning – popularly known as BI-IP. Now, BEx was the one client for planning and reporting. But IP could not do everything BPS could do – and there were a lot of consultants who hated it, and thought it was a step backwards compared to BPS.

 

One  issue with IP was lack of CRM integration. CRM planning could not be done with IP – it still needed to be done using BPS, due to a UI limitation. So market planning, TPM etc continued to use BPS while others moved over to IP.  Incidentally, the CRM integration to BPS is nothing to write home about – it is as un-user friendly as it gets. But it did its job at the time.

Then SAP acquired Outlooksoft. When I was a BPS consultant, I used to think that SAP will surely buy Hyperion. But Oracle bought them instead, and SAP took Outlooksoft, which is a Microsoft based product.

Outlooksoft’s strength was superior user experience. When I played with it – not in a project scenario, I think it was at an SAP booth at Teched or SAPPHIRE – I liked it, and thought it was pretty fast too. The only thing I did not like was that there was no netweaver integration. But SAP said they will come out with a netweaver version soon, and they did.

By now, SAP had at least 4 planning options – BPS, IP and 2 outlooksoft versions, which got renamed to BPC. Well, same with consolidations part of the house too – with EC-CS, BCS, BPC, Cartesis. As far as I know – everything was and is supported till date, and there is a “it depends” answer if SAP is asked what tool to choose.

So much for history – lets fast forward to the shiny new world of HANA. So the stand-alone HANA is mostly a datamart on steroids, with no generic killer app till date. SAP came up with CO-PA accelerator, which is pretty good. Then there is smart meter analytics – which I never understood why SAP did, instead of something else with more widespread appeal across the install base. And all this time – SAP, customers and partners have been asking “where is the HANA killer app?”.

So the next generation of HANA came where BW could use it as a database. The moment I heard about BW on HANA – the thought that crossed my mind was “wow – this is exactly what SAP needs. Not just for reporting, but for planning”. BPC netweaver is not exactly the fastest planning engine I have seen. In fact, I am not so sure how well it will work with big amounts of data, unless customers also buy BWA.  I am sure SAP will claim it is quite good on performance etc based on what they have seen – but based on my own limited experience, it has some ways to go.

Remember the BPS question of why do I need separate excel client for BPS when BEx already has one –  And then SAP coming up with IP that solved that issue? One would have thought that lesson was learned well by SAP – but guess not. BPC has its own excel client, while BEx, and Analysis for office also have excel clients. It beats me why analysis client couldn’t have been enhanced to cater to BPC too. There is more – remember the postable nodes in BPS that saved many a project some valuable time in implementing? Where did that disappear in the new products?

In my mind – BPC on HANA is a no brainer for SAP to prioritize. That is a killer app that SAP and Partners and Customers can all be happy to implement without the necessity for marketing  hype. Now, I do know that BPC on HANA is in the works, and will come out some day soon. I also understand from some blogs on SDN that SAP is building a planning layer in HANA that is different from BPC (but probably can be used by BPC later I suppose). The question is how many evolutions will it take before it moves all the performance hogging functionality into the HANA layer and provide true disaggregation, and lightning fast performance?

 

Since ECC on HANA is also around the corner, will it take away investment from BPC on HANA?

And will SAP converge its planning technologies? Can SAP incorporate the best of BPC’s user experience, IP/BPS’ netweaver integration, NGAP’s HANA friendliness, R’s predictive abilities , BWA’s OLAP processing speed etc into one coherent product? or- as a buddy warned me today on twitter – will it end up with BPC’s integration and BPS’ user experience if SAP went down this route?  And will SAP come up with a full fledged cloud based planning environment along the lines of tidemark ?

I am sure SAP has some smart people doing its product portfolio planning, and that everything will converge at some point. But the sooner it happens – the more their customers will appreciate it.

I am not sure if the agile development paradigm used by SAP these days will help or hurt the speed of such integration. When different scrums happen for BPC, BW, NGAP etc – the project manager in me keeps thinking they will find it harder and harder to prioritize integration dependencies. Each product might get unique benefits for sure – but customers only care about overall solutions at the end – not individual products. With a distributed development organization like SAP, I would expect this to create more silos – not less. I have seen fiefdoms develop in big globally distributed teams I have managed in my past life – but those were in implementation projects, not product development. I have heard that SAP uses scrum of scrums to address this issue – so I trust they have a grip on this. And in any case, I am out of my depth when it comes to product development – so I will leave it at that.

Random parting thoughts –

1. Now that SAP plans to put HANA as the engine on every SAP product runs, and since Vishal has announced ECC will work on HANA in Q4 – I wonder if planning will stop being a separate system, and get folded into the business suite. On first thoughts it makes sense to me for a large set of customers to do cross domain planning to pull it back into business suite, and then let HANA deal with OLTP/OLAP planning loads efficiently. Planning is one of the most collaborative aspects in an enterprise – so I think streamwork integration is also a no brainer in this situation.I have no idea what are SAP’s thoughts on this – but I am very curious on what is the strategy for planning in the nirvana state.

2. A more technical question – if HANA is the database for BW going forward, will it make sense to convert most cubes to an account modelling structure to make use of columnar storage? Has any one tried to compare this with a traditional key figure model in BW on HANA to check performance?  If my instinct is right – and account model does help – it is definitely a plus for BPC, since it only supports account model now.

Only time will tell – or may be one of the EPM leaders at SAP can explain that to me at some point, ideally as a comment here, so that everyone can read it.

Innovation – the price to pay


Everyone and his brother is out there on social media lamenting on lack of disruptive innovation.  While I don’t pretend to be a big innovator, there is a portion of my work that can be termed as “innovation” , or even “disruptive innovation”.  And after a few years of doing this, I can say with confidence that it comes at a high price, and it is not for everybody. Admittedly, I have come close to getting out of “innovation” a few times – but have continued to keep at it.

 

First issue is identifying what to work on. On an average, I consider 10 ideas to pick one to work on. These ideas come up as I talk with customers, colleagues, mentors, mentees and some times while watching TV or reading a book in a plane.  I will jot it down the soonest I can – and usually have an assortment of paper napkin sketches, notepad files etc where ideas are scattered.  I am not the only one who comes up with ideas – everyone in my team contributes ideas. Then I shortlist these based on only one criteria – is this something that can make my customer’s life easier in a tangible manner? If the answer is no – I ruthlessly cut it off.  This hurts egos more than one would think – especially my own. Some ideas that look brilliant as I jot it down in a plane ride look ridiculous when I think about it over a weekend.  And occasionally, it upsets my team when I kill one of their ideas. This needs to be done with some balance – if all you do is kill idea after idea, it just becomes a de-motivator.

 

Next up is recruiting a team to work on the idea. This is probably the hardest part – not everyone likes to do everything. And people have a life outside work, and value their work life balance. I have to respect that, and still make it work. And where I work, the team is spread across the globe – and typically we catchup over late evenings and weekends to work on innovations. No one pulls rank when it comes to innovation – people are free to join and drop off . My philosophy is that if people work on innovations voluntarily, it works out better than if it is forced down their throats based on official rank. So far it has worked out well – and I could not have asked for a better set of colleagues to work with.

 

It also improves teamwork and delegation abilities. I understood early on that delegation is the key to success. And I try to teach that to everyone in my team. The trick to delegating successfully is to make sure the team understands what is being delegated, and what is their authority and responsibility.  You cannot just delegate responsibility ! But once they are comfortable with taking on authority, and willing to be held responsible – the results are unbelievable. Irrespective of the result of the actual innovation project – they develop into amazing leaders, and it is the biggest gratification I get in my job. I did not invent this – my managers took this approach with me, and I am paying it forward for the next generation.  Some times, things don’t work out as planned and an inexperienced person might screw up. It is up to the manager to make sure there is sufficient support when failure happens, and no one is thrown under the bus.  Especially when it comes to disruptive innovation, this is key. If you cannot live with this – don’t start down this path.

 

And then there is the price to pay on family life, hobbies etc.  I had to sacrifice a lot, and so have many people I know. My wife supports me to a great extent, and without that I would not have taken this up. It is hard to balance – and once you are deep into an innovation project, it is extremely hard to switch off completely. This is rather unfair for the family, and has to be carefully weighed before starting, and then periodically throughout the project.  At the moment, the only way I handle this is to take breaks between innovation projects so that there is some balance on personal front. The work-life balance is a personal decision – and if you care enough about your team, you should watch out for their work-life balance too.  All of this needs to be factored in when you plan the project. Nothing ever works to plan, and you need to balance aggressive milestones with a dose of reality.  This is a learning process, and I am definitely in the first half.

 

Finally – disrupting the “life as usual” for a customer, or for your own company is a challenge. it does not matter if you spent 3 months working every waking hour on this project. If you cannot make a business case and SHOW things will get better, no one will accept your innovations. And then you have 2 problems -1. risk of wasting the blood, sweat and tears spent on current project, and 2.  getting investments for next project from management.  And you would have broken a lot of glass before the final solution is pitched – so there is a potential long term price to pay as well.

 

And one last thing – be prepared to take the least amount of credit for success, and maximum amount of criticism for failure.  It is easy to know if this is working or not – if it is not working, you will soon find that there is no one left working shoulder to shoulder with you any more.

 

So with this big price tag – will I do this ever again?  ABSOLUTELY ! I won’t change a thing – it is the most satisfying part of my job 🙂