When talking w/ Michael Krigsman (podcast here), I spent some time trying to drive home my belief that customers must own their projects more.  IMO, part of the problem is driven by the confusion between accountability and responsibility.

Wideman’s invaluable Comparative Glossary of Project Management provides definitions of accountability that are useful:

Accountability:  Being answerable to one’s superior in an organization for the exercise of one’s authority and the performance of one’s duties. OR Being answerable for results.

“Being answerable” gets to the ownership that accountability is all about. Unfortunately, many definitions of responsibility muddy the waters:

Responsibility: The duties, assignments, and accountability [emphasis mine] for results associated with a designated position in the organization.

Throwing in “accountability” contributes to the confusion many have. In some ways including accountability in responsibility makes it sound, well, less-than-accountable.  Here’s how I try to keep it simple:

• Responsible = Those who do the work in question.
• Accountable = The one who signs off on the work that “Responsible” provides.

When managing vendors and integrators, we have to remember that as customers we need to make sure that we’re always the “A” in the RACI.

Yesterday, softwareadvice.com tossed Don Fornes’ post on SAP’s SME solutions over the Crossderry transom.  All-in-all it is a good overview, with a couple of caveats:

1. Industry coverage of the SAP Business Suite and All-in-One is depicted as equal and that’s a stretch.  Perhaps I need to brush up on my SAP release strategy, but I recall that industry solution coverage for All-in-One is not nearly as extensive as that of the full Business Suite.
2. I like that Don highlights the NPV calculations you need to make for on demand vs. on premise.  It is easy to forget that what looks cheap now ain’t so cheap after you’ve been paying for a few years.  However, he’s not clear what the $27,416 NPV represents.  It looks right per user (at $149/month and using his assumptions of a ten-year life for software and a 6% discount rate).

Here’s the promised link — Enterprise IT: Inside an SAP customer — to my recent podcast w/ Michael Krigsman.  I’ll elaborate a bit on f these themes in future posts.  As I mentioned earlier, the interview stoked my blogging fire again!

Michael Krigsman and I had a chance to chat last week — he recorded a podcast w/ me that will be up on his blog before too long — and thankfully the chat got my blogging mojo going again. 

I don’t want to steal our podcast’s thunder, so I’ll focus on a tangent from our call — SAP’s innovation problem.  Michael himself has hoped that SAP’s leadership change would help to bring more innovation to market.  Ray Wang put it more bluntly in his take on Leo’s ouster:

[T]he issue is not sales. It’s products. Snabe and Vishal will need strong product vision to right SAP and point it in a forward direction. Engineering and products need more attention to bring out trapped innovation at SAP.

“Trapped innovation”… that’s so much of what I saw at SAP.  There are many cool technologies floating around, but they don’t fit in the “margin now” mindset that has pervaded the company.   The company is stuck in the classic [successful]  innovator’s dilemma:

By only pursuing “sustaining innovations” that perpetuate what has historically helped them succeed, companies unwittingly open the door to “disruptive innovations”.

Even worse,  SAP had deluded themselves into thinking they were responding appropriately — what was marketed as real innovation was simply new wine in old skins.  Exhibit 1 — 2007-2009 versions of Business ByDesign.