Why I left SAP…”macro” negatives

Second-guessing oneself is a risk when deciding to leave a leading company, so I needed to ensure that I had no regrets when I left SAP.   In particular,  I didn’t want short-term personal or “micro” stumbling blocks to obscure great “macro” opportunities in the rest of SAP.  Unfortunately, there were too many big picture concerns that nagged at me, at least from my less-than-exalted perch:

  • The “Post-Shai” Backlash:  The reaction to Shai’s departure was almost giddy in many quarters, which wasn’t a surprise.  The real surprise was the scale, scope, and snarkiness of the reaction.   A lot of non-Palo Alto folks minimized Shai’s contributions when it was convenient — see Peter Zencke on Shai’s “second tier” involvement with BYD — and blamed him when it wasn’t convenient (e.g, BYD didn’t perform because of NetWeaver). 
  • Condition of SAP’s Product Portfolio:  For those familiar with the BCG Matrix, IMO the SAP portfolio is unbalanced.  Nearly all of the SAP portfolio can be classed as either cash cows or pets.   I just don’t see enough “stars” on the solution horizon. 
  • Confronting the Reality of Business ByDesign:  Speaking of pets, there was way too much happy talk about BYD for far too long.  The funding that was poured into BYD — while SAP increased its margins — came out of the hides of other parts of the company.  

This last point highlights the fundamental doubt I had about the validity of SAP’s strategy: Was it still able to produce “stars” organically?  A “not-invented-here” mindset only works when you’re still able to invent.  It is one thing to miss on product development, it is another to deny the miss. 

 Leo is certainly aware of this issue, but this unwillingness confront reality has continued to spread IMO.   I’m not sure that SAP understands just how much damage it has done to itself by running some sides of the company with a gimlet eye, while other sides seems to be living in the best of all possible worlds.

PM Quote of the Day — George Canning

But of all plagues, good Heaven, thy wrath can send,
Save me, oh, save me, from the candid friend!
 

PM Quote of the Day — Jane Austen

I cannot speak well enough to be unintelligible

PM Quote of the Day — Carolyn Wells

Actions lie louder than words

Well, approach “x” worked for me when I worked at company “y”

Well, these magic beans worked for me at AIG...

Well, these "magic beans" worked for me at AIG...

Pawel Brodzinski had a wise corollary for my original post on naysayers (here).  He puts it well…

The distance between rejecting things you don’t believe in and forcing others to do things you believe in is pretty short.

It is great to bring a successful practice to a new situation, but one had better be ready to answer some basic questions:

  1. Why will “approach x” work for this problem or opportunity?
  2. What about our situation may make “approach x” difficult or not applicable?
  3. How will we resolve, mitigate, etc. the issues and risks implied the “What” question above?

I’ve never seen “solution y” successfully implemented…

Go to the mirror...

Go to the mirror...

There are some assertions — or maybe I should say incantations — about process or solution failures that never cease to puzzle me. One of my favorites is:

In my “x” years of experience, I’ve never seen “solution y” successfully implemented…

I’ve heard this about TQM, activity-based costing, Six Sigma, SAP, Oracle, Java, etc., and ad nauseum. No matter how successful or tested the approach, the person who invokes this formula believes that his/her “say-so” settles the matter.

Now I wonder: do those who use such rhetoric ever consider what they’re really communicating? Because I know what I’m thinking: “Hmm…solution ‘y’ doesn’t seem to work when person ‘z’ is around.”

Deliverables, work packages, and the schedule

This temptation to fix a schedule and get to work is constant in enterprise IT.  It is particularly alluring for any application tied to a SOX-compliant landscape — some governance models only allow two opportunities/year to deliver — where project durations strongly suggest themselves and time is always “a-wasting”.

Of course, as Glen Alleman reminds us here, starting with the schedule  is wrong.  I won’t recapitulate his post here, but I’ll borrow from his comment to another post which points out the fallacy in this kind of thinking:

[M]any…process improvement projects have failed, along with Enterprise IT, because the WHY of the effort is not established or well understood. The principles establish WHY we should be doing something. The practices of course tell us HOW.

This rush to “get working” short-circuits on of the most important functions of a WBS: stakeholder management.  Properly defined deliverables and work packages aren’t simply inputs to the schedule, budget, etc.  If nothing else, a WBS  is the most accessible framework for a discussion with one’s stakeholders that ensures that the what of the project supports the why of the project.  Wouldn’t it be a good idea to make sure that why and what are elaborated and priorities agreed upon — even at just a couple of levels — before getting down to who, when, where, and how?

Follow

Get every new post delivered to your Inbox.

Join 2,659 other followers

%d bloggers like this: