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.


Analyzing Project Success – talent wins games, teamwork wins championships !

I am on cloud nine at the moment – our team successfully finished a huge big project go live in a “minimum fuss” way (THE way go-live should be) and I am getting ready to party hard with the gang.

It was a journey that started in the fall of 2009 – and the team is as intense today as they were 2 years ago. But the one thing that gives me more satisfaction than anything else is that there was no “us and them” between client team and “my” team apart from a contractual/legal perspective. I hold this as the prime reason for our success – we could have done every thing else right, but without this “joined at the hip” partnership – we would not be here today celebrating, and smiling ear to ear. Due to confidentiality reasons – I cannot disclose the client or the exact work we did, but I thought some one would benefit from my experience if I shared a few highlights from the project. If I manage to get the legal hurdles cleared, I will make a second post to complete the picture.

The client brought in an A team from their side – and the project was owned by a senior executive from business. Both business and IT leadership reported to her. Consequently, everything was done with the sole objective of making sure business got what they needed. The Program manager, technical manager, development manager, architects and project managers were all great people with great domain expertise – and they all wanted to “get the job done”. Even when they disagreed (passionately), they had the maturity and trust in each other to discuss and get to common ground.

Right from the start, we partnered at all levels of the program organization – from developers to sponsors. We had several hiccups along the way ( attrition issues, technical issues, relationship issues etc) – but since we had strong relationships, there was no difficulty in having honest conversations on what is happening , and how we are going to solve it. In a large complex program spread over multiple locations – this is critical. Nothing was ever hidden in status reports – full transparency, and joint plans to solve problems, and joint parties to celebrate successes .

A fantastic example of the partnership that I remember on top of my head was when we were finalizing scope early on. I, and another person brought up a discussion that the number of reports to be developed looked out of whack based on past experience. The leadership team took it seriously, and went back to discuss more on this – and came back with a scope that was about a third of what was originally proposed. They identified redundancies, and lower priorities and diligently worked through to save the project a lot of unnecessary work. I had made this recommendation on reducing scope, despite it meaning my team will bill significantly lower hours and there by make less $$ . The point is – $$ billed is not the biggest success factor for a consulting company. The primary goal for the consulting company is extremely high customer satisfaction leading to long term partnership, and being elevated to ” Trusted Adviser” status with the client. My mentors taught me that lesson early in my career, and I try to teach that to the next generation of PMs that come after me.

Change requests have a big bad name in project management field, especially with analyst community – and the word on the street is that SIs use it to milk a client dry. I never had any trouble in this regard – all changes were discussed in detail and agreed on, before we proceeded with any change requests. Every change had full justification and agreement, and I am very proud of the fact that not once in the whole life of the project did any one have to say “lets see what the written contract says”. That is the beauty of having a solid relationship across all parties involved, and a solid process to govern the project change control.

As I look back in time, the one thing that strikes me most is the sheer number of people who learned valuable skills and experience in the project from both client and our side. Leadership is all about empowering the team , and delegating authority and not just responsibility. While the project had a well defined escalation path, a lot of decisions were successfully taken by people closest to the issue, with appropriate heads up given to management for integration purposes. Having gone through this experience, I am sure we are all well positioned for success at whatever comes next in our careers. It gives me a lot of satisfaction that a lot of leadership talent was identified and nurtured through the program.

One thing I learned in the course of the last 2 years is that there is no one-size-fits-all way to motivate a big team. Some get motivated by money, some by getting additional responsibility and visibility, yet others by periodic change of roles within the project and so on. My project leaders and architects are exceptional – they found what made every team member tick, and acted on it, taking my help where needed. I still remember being fascinated by developers in my team pretty much competing for fun on who will find the most bugs, who will fix the most bugs and so on – over weekends and holidays, on their own time. How awesome is that? I could not be more proud of my gang – they rock. We have our fair share of disagreements – but team work and a common goal of making the project successful, ensures we get over them in the shortest time, and healthiest manner possible.

Last but not least – there is a lot I am thankful to my support staff, ,my managers and my mentors. A two plus year project of this size meant that I had to ask for help periodically. They not only gave me support and guidance behind the scenes – they also came in person and celebrated our successes. They cared – and we appreciated that a lot, and it is a lesson we will take with us as we progress in our own careers.

Most people who read this would have made an assumption that this was an SAP project – with me being an out-and-out SAP guy, and an SAP mentor and all that. Well, this was NOT an SAP project. It was my first non-SAP project too. I am an extremely hands on person when it comes to technology – but I had to learn to trust the technology experts on this gig. It was very unpleasant for me at the beginning, since I am used to providing a lot of technical input to my team in SAP projects . But I learned that there are many people with MUCH better technical talent than me – and I should just trust their judgment. That was a HUGE lesson for me, and one of the most important ones I learned. Of course I did not learn it fully (yet) and occasionally jump in and make comments based on what I think are corresponding scenarios in SAP 🙂 . I must also say that this has made an impact on my view of SAP. There is a lot SAP practitioners can learn from the non-SAP world, and I am glad I now have this experience under my belt.

Success is multi-dimensional. A lot of times projects get measured along time lines and budgets alone. We surely managed by SPI, CPI etc – but that was just one of the many dimensions. We were clear on conditions of satisfaction, and both my client counterpart and I were committed all the way to make sure we kept each other in the loop on what is happening. It is a professional relationship I cherish, and I am sure it will continue past this project too.

As Michael Jordan said ” Talent wins games, but teamwork and intelligence wins championships” . I second that – 3 cheers to the team ! There is more work to be done for remaining phases of the program – but for now,let us Party 🙂

Change Management – Why haven’t we solved it yet?

It is not new news that Change Management is a big deal, and all transformation projects – probably “all” projects – need to invest in it.  We knew this decades ago – and for the most part, we still fail to do this. WHY?  I have worked in various roles on ERP and non-ERP transformations.  And I have also had the opportunity to formally and informally review projects that I did not work on directly. Here are my very biased five thoughts on this topic. They are not discrete – they are all intertwined.

1. Enterprise software is built assuming that users have to be formally trained in it

Some of the newer solutions have shown us why this is not an optimal solution. If software is built assuming that user should find it intuitive, incorporating training aids and simulations into the framework, a lot of change management challenges will go away.  From a sheer usability perspective, many established enterprise vendors have made big advances – but that is true only when you compare their new solutions to their own older versions, and not on an absolute scale.  This needs to be fixed on product development and project execution fronts – and it needs serious paradigm shifts in how we do both.

2. My best practices are not the best for you if you “blindly” copy mine

Instead of using best practices as a template, a lot of projects use them as holy grail and force fit business processes into it. ERP vendors and SIs and independent consultants are all culpable. This was the big selling point for ERP – we already have everything, just make your business run according to “our” model, and all will be well.  Even though we have seen a million times why this does not work, we still do it.  There are valid reasons to take this route – it costs less project budget spend and only needs a shorter time line, it minimizes support costs etc.  We just conveniently forget that this is akin to tail wagging the dog.

3. Business is not static – things change ALL the time.

Debits and credits still show up where they showed up before we were born, but these are a minority. They are an exception to the rule, and not the rule itself.

For example, in the world of financial planning – people who run a business might change how to do planning every so often. If you always had done operating income at product line level, and gross margin at customer level – all your allocation rules will need to be changed if you suddenly need a net margin by customer. Most ERP type solutions cannot respond to such changes in real time. Is there any wonder that spreadsheets still rule the world despite an army of vendors and consultants advising against them?

Same thing for logistics – you might have always sold in a “sales order, delivery, billing, payment” order. Now the new VP wants to change it to “Get payment first and then deliver” . Traditional ERP needs time to respond to this – config changes, code changes, testing etc. And by the time it hits production – sales clerks might not know how to do the new model for sales. These same “dumb” users can figure out 5 changes in an iPhone App after an upgrade, without any one telling them what to do. Why?

My bank has changed its website features at least 10 times in last 5 years. I never once had to call the bank to find out how to use any of them. Then why is it so hard for a company when it comes to giving a system or process for employees without making them pull out their hair?

4.  You get what you pay for. No more, no less

The primary reason, I think, is that the people who control the purse strings for a project usually think of change management as a “nice to have”.  Whether it is to train users, or to communicate changes, or to make software that is intuitive – it costs time and money. You get what you pay for. If the axe falls on change management budget, then it is also falling on the chance of success.  Sending blast emails to all users, you know – the proxy-written for a big wig type mails, is not a substitute for change management. I don’t read them, and neither does any one else I know.

5. As size of a company increases, the lesser your chance of getting a representative sample to make decisions

A senior executive from logistics is probably the wrong person to address the requirements of the shipping clerk. But often, requirements workshops are usually filled with people far removed from actual business process.  As size of a company increases, it becomes very complex to get a sample of people who can make good decisions that affect all of the company.

How do you measure success and failure of projects?

There are quantitative and qualitative ways to describe the success or failure of a project.

In general, a project is considered succesful when it meets its objectives while staying within an agreed up on budget and time line. This sounds simple enough, except that it is not !

First, who decides if a project is succesful? And if a project passes a series of tests and goes live, is it considered succesful? The common model is to celebrate success at go-live. But going live is just the beginning of the journey. It takes a fair amount of time to judge if the business got sufficient value out the project. Also, at what cost? Did they have to hire more people to support the implementation? Can they make enhancements to the functionality as requirements change, without costing an arm and a leg? Do we attribute this to the original project?

Since I am more familiar with SAP projects than non-SAP projects, let me quote examples from SAP area. In the nineties, SAP was not as rich in functionality as it is today. Many implementations had dirty modifications to source code to make it work according to requirements. These were called succesful projects at the time. 15 years later, these same modifications have caused the customers a lot of trouble in upgrading their systems. So do we still call them succesful?

Second, all stakeholders have to agree to a set of objectives that a project has to meet. Sounds simple enough – but then, it is kind of hard to accomplish too. First, there is the legal issue – if you cannot express it in a language that lawyers agree to, the objective will not be present in the contract. And if it is not in the contract – it is hard to ensure it will be met. Then there is the question of the definition of who a stakeholder is. In large projects, there are many people who are affected, and it is impossible to get them all enlisted to create a list of objectives. So a subset of people is assigned as leads or representatives, and they may or may not know how the new project is going to affect the work of the whole population. 

In one of my first succesful SAP projects, I remember going to the office the day after go-live and finding a large number of trucks backed up from the loading bay all the way into the street. Guess what? no one remembered to capture the requirements of the picking department – so they tried to do it the old way, like they have done all their lives – and then could not update the system with the results. Thankfully, we could solve it with some quick work around – but the point is – you cannot figure out every one’s requirements all the time in big projects.  Voice of the majority does not mean something is right – there are plenty of exceptions in every business process, and they all should be handled.  Consultants swear by “Mutually Exclusive and Collectively Exhaustive” – just that as scope increases, the chance for hitting this paradigm decreases.

Third – how do you agree up on project time line and budget? It is by estimation, which is an inexact science by definition. Based on prior experience, some one thinks that a certain task will take a certain amount of time to finish.  Just as the stock market has taught us that past performance is not a good measure of future (for the short-term),  there is no guarantee that these estimates will hold true across the life of the project. Techniques like PERT make us eliminate bias by using formulae that goes from pessimistic to optimistic. But as all experienced project managers will attest – estimates are best guesses, irrespective of techniques. 

Now – this means estimates have to be revised as projects progress and we have more data. But the question remains – if I estimated $2M today, and then re-estimated after 3 months to find that it actually costs $3M – is the project already a failure? The world outside the project typically looks at projects with this perspective. Once an estimate is made for time and money, then the world expects it to be set in stone, come what may. There is no room for re-estimation.  So most projects get into this situation that they are set up to fail from the beginning.

Finally, no project has unlimited resources – so scope and timeline usually is subservient to available money. This means some one has to prioritize scope. And in this process, some requirements will need to be dropped. Despite the due diligence in this exercise – it is hard to avoid a decrease in value to some part of the customer organization. But when the project finishes and these gaps get exposed – usually it is put as a failure of the project.

Now, I am not the only one to have this knowledge – most customers, consultants and software vendors know this. But why would not this situation change? Just a rhetorical question of course 🙂