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:
- Over eager salespeople minimising risks around complex solutions.
- Over eager buyers wanting to buy into the brand. I’ve seen entire customer panels talking about SAP Business ByDesign making this mistake.
- 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.
- 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.
And Vijay Says... 
@vijay – I hear you but I’m not letting this one go so easily. I thought you said ‘we can call on 20 years experience’ or something very similar. How much repetition do you need in order to price and track progress?
In this theory, if you are over-running then you didn’t resource the project correctly.
This is a much more disciplined approach and as such I’d argue much more focused upon outcomes. Timesheets are about inputs. That distracts from outcomes.
In my practice, we ditched timesheets once we realised that final pricing had nothing to do with what was on the tab. We became much more profitable and clients were happier. Go figure.
LikeLike
There is a difference in estimation between a 99% predictable process like building a car over and over, and implementing a project which probably only has 50 to 70% similarity with past work.
What is comparable from the car example is the initial PLM process of building a NEW car from concept to prototype, where at best they can reuse. 70% from past .
Even in Toyota Manufacturing , they track thousands of parameters constantly to make sure there are no big variances . it is an integral part of their continuous improvement philosophy.
If u look at how long it takes to create a complex custom object in a project between 99 and 2012, u can see how much improvement has happened .
Customer satisfaction has nothing at all to do with time sheets anymore since they never see it. It is just an essential internal controls mechanism.
Finally, if time sheets are done away with, probably it will make employees happier. But as a pain point faced by employees, I doubt time sheets are in top 5. Expense sheets are probably number 2, right after compensation.
LikeLike
Last comment on this one. I’m struggling to understand how you can talk to certainty of outcome via a fixed price offered in advance but then say you can only reliably replicate 50-70%? What do you do about the parts you don’t know?
Cust sat is impacted in my experience. Customers saw better quality of outcomes. In most recent times, I’ve been asking other colleagues about impact and they report similar results. Employees are much more motivated.
When we did our thing it was a shock to the system for sure but staff saw immediate benefit. They like that they are accountable rather than simply punching a digital clock. They get ownership in ways a timesheet doesn’t provide.
I always thought the timesheet carried the risk of being a crutch upon which staff could lean, padding here and skimming there in the real world but smoothing out when recording time so that true visibility was lost. Take away the crutch and they can’t hide.
The key to making all this work is meticulous pre-project planning with the client to ensure that I concentrate on the key needs I expect to be problematic.
FWIW – every project I do is ‘custom’ and so for I’ve not experienced an issue that I could not overcome or renegotiate by way of change order. The only time I’ve had an issue is when I mistakenly volunteered something that was out of scope and didn’t think through.
As a side note – I am not suggesting that anyone dispense with costing systems. I am suggesting there are better ways to do it while encouraging better pricing methods.
LikeLike
@Vijay – can’t get this comment into the thread. I guess if you employ people on a time basis then yes – a timesheet would be needed. Otherwise, I don’t see the legal need. More commonly, I see SIs attempting to shift time over-runs into mythical change orders or loading change orders to make up for past estimate failures.
LikeLike
Let’s say I pay you a fixed amount of money to work for me, and not record the time you spend on each of the three projects I put you on. Each project I put you own gets me a different amount as revenue.
I now have no way of knowing how to estimate the 4th project, how to find my profit for each project or even if I am withholding the correct tax from your paycheck if these projects are in a different state than where you live etc.
So just because I don’t give a time sheet to the client to collect billing does not mean I can do away with time sheets .
LikeLike
There is a different way to manage this by allocating costs in advance. This is what Toyota does. That way you can easily manage any payroll tax issues regardless of state.
LikeLike
Yes true, but that only works for repetitive work. which is also done effectively by better consulting companies. Many of them can now predict profitability and risk of most projects before work commences. We still need to measure progress to make sure we catch variances at the earliest and mitigate them. Time sheet is one of those things that help with tracking progress.
LikeLike
Vijay
Great discussion here. I wanted to comment on Dennis’s post earlier but ZDNET has some issues with comments. So I will riff it here.
Your blog reiterates the age old question, are all involved parties on the same page? I would argue that the issues Dennis put forward are not just for SAP but any major implementation project that rips the age old back office systems and replaces it with a packaged functionality. In my experience here are some of the reasons for implementation failures
1. IT and business are not always aligned. Business wants process improvements, IT wants to reduce TCO. Sometimes a pre-packaged solution may not be the middle ground. Plus, the sales guys coming in and showing souped up demos that are not standard out of the box, only adds to the rift.
Remedy: Clean up the house first before calling for external help. IT is a support function for the business and not the driver. Also, business needs to be open to change their age old processes and adopt pre-packaged solution offerings where applicable
2. Fixed bid projects are not the right answer always. Sometimes, because of their own inability to control scope, businesses go for fixed bid projects. What businesses are doing is instead of letting their own managers take an educated decision on scope, they are letting the consultants and system integrators control the scope. If businesses know their business, shouldn’t they be better in controlling scope than a SI doing it for them?
Remedy: Know what you want, why you want and when you want it. It’s your business, you know it the best
3. Waterfall vs agile approach. I know we have beaten this down to death but for some reason it never gets old. Yes, it is definitely possible to get a feel of a prepackaged solution way early in the game but unfrotunately businesses are so used to their own data, many times, a prepackaged solution with mocked up data doesn’t seem the help the business comprehend what they are signing up for. Spend months on blueprint and realization, after which users don’tlike what they see.
Remedy: Yes you are a special and a unique business, but you are not that unique. Your customer base is the same as your competitors. So, have an open mind, question the status quo, do you really like what you see?
4. Sometimes, SIs are risk averse. This happens with all SIs, big and small, tier 1 and tier 2 etc. SIs have a methodolgy and they tend to adopt it with blinders on.This may not be OK in some cases because one size doesn’t fit all.
Remedy: It is perfectly OK to fine tune your methodology to the needs of a particular client or business. After all, no one solution is 100% perfect.
5. It’s not always about selling. This goes for both SIs and businesses. SIs should realize, deliver what you signed up for, add-on sales will automatically popup. Also, businesses should learn to treat the recommendations from SIs as recommendations and not as sales pitches.
Remedy: Business should engage the SIs as partners in the journey, not bodies contracted to get the job done.
Deep down, I think Business, IT and SIs all want to do the right thing as everyone’s success is dependent on other parties success as well. However, it is the organization’s DNA, team dynamics, skill set issues and bureaucracy that causes some projects to go down south.
To the apples and oranges comparison Dennis made, I agree, Force.com is a great application, no doubt, but they will face similar issues once they start penetrating in to the areas where packaged solutions play a major role, which is big back office implementations. Point I am trying to make is, it’s not the technology, it’s the people and process which is the problem here.
As usual, all my comments here are only my opinions and not necessarily that of my employer.
Thanks
KK Ramamoorthy
LikeLike
KK – could you email me at dahowlett [at] gmail [dot] com about the issues on ZDNet? I am trying to help techs bottom this as it is a recurring issue.
To your point re: Force.com – FinancialForce.com has successfully built accounting system of record on that platform and has it scaling out nicely to customers wanting multi-year deals. Customers are spending more on renewal which is always a good sign. However, I am painfully aware of some limitations on the platform itself.
LikeLike
Excellent riposte VIjay. One point upon which I cannot agree. The billable hour thing. You’ve said yourself that it is impossible to know in advance all that would be needed. Change orders arise etc. How are those priced? Are you saying that staff are not assessed or required to maintain timesheets? I can argue on root cause but that’s a much longer conversation I’ll save for when we next meet.
LikeLike
We are very sophisticated now for estimating effort for scope and changes in scope since we have the data from past 20 years to do that with good accuracy . So change orders are also fixed price, not by hour.
We still need time sheets to understand cost and to adhere to legal and admin rules. But that is just for internal use.
LikeLike
I suspect that when you boil it down, this comes back to time expended as a basis for estimation in part because you cannot replicate past teams nor can you guarantee consistent performance.
Legal? That’s a new one.
I am seeing a significant trend to completely remove timesheets. In all cases it leads to better margins because the emphasis moves from cost to value. Check out Verasage.com. Clients end up with better outcomes as Verasage methods only work when outcomes are the focus. They make a very good argument for removing the timesheet altogether, something I did over 20 years ago.
When I first went into practice and saw timesheets I was horrified. My question at the time which still holds true: “When I go to the garage do I expect that I’ll get a parts and time bill? No – I expect a simple price I can understand.”
LikeLike
Why is legal a new one? Every employer has legal requirements to satisfy on tax, fair pay, immigration etc that need time and expenses accurately captured.
But remember the client does not get a time sheet ever in this model. They just get one invoice that references a milestone, and backed up by contractually agreed deliverables . Client doesnot have to worry if it took 50 hours or 500. If SI under estimated, SI takes the loss.
LikeLike
Vijay, I have over 15 years of implementing SAP projects and another decade of IT projects. The single root cause of SAP projects to fail is incorrect expectations. The sales team expected it to be easy. The delivery team expected the customer to participate more. The PM expected different resources from the company. The client IT team expected more from the Software, the SI, and the Business. The Business expected the SW, IT, and the SI to do more. We each see the world from where we want it to be. Unfortunately, it is human nature.
I have seen a few projects fail due to technology, but the technology did not fail, it just could not go as big or fast as the client wanted. I have found only a single way to overcome this expectation gap – simplicity.
If you can find simple ways to communicate the expectations, every gets the same view. It is what I ask of my architects. Don’t tell the client it will run 128K SAPS. Tell them how many users. When bringing multiple parties to the table, use RACI charts so everyone at least knows the title of assigned tasks. There is still room for variability, but it moves you closer to equal understanding.
I believe the simplicity of SaaS is one of the key drivers. I buy the function that I need. No one asks me what I want, so I assume it has all I need. For instance, SalesForce.com is small subset of what SAP CRM can offer. However, I don’t have an up front cost. It is ready quickly. The cost benefit ratio is 1:1 in that if I have sales person, I pay for them and if not, I don’t. Can you imagine if I set up a SAP CRM system you wouldn’t want complete view into all the inventory or current sales yet that doesn’t come up until well after the client has been up on SalesForce for some time.
We have a very complex world. Many of our solutions are even more complex. I’m a huge believer in Occam’s Razor (http://en.wikipedia.org/wiki/Occam%27s_razor). If we drove our projects, our contracts, and expectations around what is the simplest solution that solves the problem and no simpler, I believe we’d avoid a lot of failures.
At least that is what I expect.
LikeLike
Top answer. Human nature is an odd thing isn’t it.
LikeLike
I am a big fan of simplicity too, Chuck. There are 3 things I like to add
1. Striking the right balance when making things simple is difficult because what is simple for you might not be simple for me
2. Expectations can only be set in the boundaries of budget and time. How many times have you an I both seen change management and reporting and user interface work being removed from scope to save short term budget, despite knowing that it is a terrible idea in long term ?
3. We – consultants, clients and sap-do great on viability and feasibility of to be solution, but not always such a good job when it comes to DESIRABILITY . And that I’d mostly because systems are built for managers who pay for it, and not for end users
LikeLike
I started with a Big 6 consulting firm in 1995. When I was going through experienced hire orientation, I sat there with 74 other people and listened to a partner tell us his version of reality.
“They say that there is a skills deficit – that you can’t find enough good technical skills. That’s not true. I can find them all day long, if I’m willing to pay top dollar for them. They’re not cheap sometimes, but they’re always there if you need them. What I can’t find, at any price, is good project managers. If you want to make yourself indispensible, become a good project manager and you can write your own ticket.”
I thought it was hogwash at the time. Now I know that truer words were never spoken.
LikeLike