Waterfall, Agile, now “Sim”?

Dan Woods in Forbes (here) highlights one of the emerging trends in development: user-interface simulation.  This takes agile development a step further, because…

[b]y creating a simulation of the user experience, instead of a full-working version, a team can avoid a large amount of work but still get a full test that can confirm requirements. Simulation accelerates the agile cycle by lowering the cost of each iteration and improving the quality of the feedback. At the end of several simulation iterations, designers have a rock-solid sense of what is needed.

Simulation also provides a better way to test the quality of business processes because it improves on the typical flow diagrams that only sophisticated users can understand.

iRise is the vendor that Woods mentions and that I’ve heard of (here).  They have a SAP-oriented solution (here), but I can’t vouch for it yet.

Also, because this piece is in Forbes, I’ll bet that smart c-level folks will soon be asking their PMOs about whether they are incorporating this approach into their methodologies.  Time to crack the “sim” books!

The SAP/Oracle Choice re: Integration

With the release of SAP Business Suite 7, the debate about the SAP and Oracle integration strategies has heated up.  Loraine Lawson at IT Business Edge (here) uses two posts by Ray Wang (here) and Dan Woods (here), to contrast the two approaches.

Of course, I agree with Lawson and Woods that the SAP approach is better :-).  I also agree that the Forbes audience — C- or high-level business folks — will eat up the SAP message.  However, IMO, it isn’t quite so simple.  Per a paragraph from Woods’s Forbes piece.

Companies implementing new applications or consolidating many companies must ask which foundation is best: a productized and unified platform for business automation or a collection of products that needs to be integrated. Best-of-breed is another way of saying that the user, not the vendor, is responsible for integration [emphasis mine]. 

My experience is that some firms and industries like to have that responsibility and chafe at having processes “pre-integrated.”  Again, I don’t think that is a great default position — one ends up automating non-differentiating processes nearly from scratch — but many pharma and financial firms in particular have tried to “grow their own.”  It is a legitimate strategy if you are truly creating competitive advantage via custom development and integration.

What SAP has done with the Business Suite and its business process platform strategy is to accommodate that desire to be different.  Enterprise SOA allows such customers to get the benefits of process integration without forgoing the capability to differentiate (by assembling or building enterprise services on top of the platform).

SAP Business Suite 7.0 — life w/out upgrades?

I haven’t a chance to dig into the details of SAP Business Suite 7, but it looks very promising w/r/t implementation costs and other TCO drivers. The enhancement package approach was a great start, but the new Business Suite should be a more comprehensive breaking of “the upgrade barrier” (per Ed Toben of Colgate-Palmolive).

Here are a couple of videos on the new suite: Jim Hagemann Snabe on the strategy (here) and a SAP Business Suite 7 demo (here).

Perils of being a “brand protector”

I’m sure you all have seen the bad publicity SAP Services got via a news story on Bloomberg about the Shane Company bankruptcy filing.  Josh Greenbaum picked apart the piece pretty comprehensively (here) and the Shane Company itself came out with provided a statement that SAP can use to clear the air (NOTE: struck out section reworded in bold to clarify):

Press coverage resulting from the Shane Company Chapter 11 bankruptcy filing has unfairly characterized SAP as the cause of Shane Company’s cost overruns based on the software applications licensed from SAP in 2005. Project implementation cost overruns were caused by a failed implementation process utilizing multiple third-party industry experts.  After not meeting expectations, the Shane Company contracted SAP Services to restart the project which they played a key role in implementing, stabilizing, and further enhancing the system.  In fact, we have a strong business relationship with SAP and will continue working with them as we emerge from our Chapter 11 bankruptcy filing.

It is a different consulting business when you’re the services arm of a product company, especially one with a prominent brand.  SAP Services must be vigilant to ensure that our brand value protection efforts aren’t in vain.  It is tough enough to get projects back on track without then seeing stories that suggest we weren’t effective.

Podcast on barriers to successful IT/CRM

Michael Krigsman over at IT Project Failures hosted the first in what he hopes will be a regular series of “Town Hall” podcasts (here)  It was originally supposed to be a meet-up, but the weather was dodgy at best so the session went virtual. 

Anyway, Paul Greenberg moderated an excellent discussion that covered a lot of ground.  As Michael notes, Paul’s CRM background focused the conversation

…on issues drawn from customer relationship management. CRM brings together core business functions — how a company interacts with customers — with technology intended to streamline and improve those relationships. Since these goals are business-oriented, CRM offers excellent examples of non-technical failures connected with technology implementation projects. For example, one participant noted corporate managers sometimes deploy CRM hoping to control end-users, who in turn reject the system in a predictable failure. 

Be warned… I jump in at about the 30 minutes mark!

More on saying “no” to customers, stakeholders, etc.

Pawel Brodzinski had a good comment (here) on my post about saying “no” the right way (here), which links to his post laying out his full perspective on the customer is always right principle.  I replied to his comment — agreeing with the principle, but cautioning on its application — which I’ve posted below:

Sometimes it is about saying no — or as the Japanese say “Yes, but.” There are times when we don’t take business, especially when we are being “forced” to do so. But if we aren’t taking their money, is that customer really a customer? IMO, no, at least not for that topic.

Of course, I agree that the customer is always right — which makes it critical to be choosy about one’s customers. But the application of that principle is tricky. PMs who allow scope creep to happen on their projects often justify it with a customer service rationale — “the users asked us to build it.” But are the users really the customer of the project? Aren’t the executives who chartered the project and the company they represent the customer? Too many IT staff and PMs are very confused about who is the “real” customer.

Accountability for “soft stuff” deliverables

Per an earlier post (here), I have a bee in my bonnet about “supporting” deliverables and how to measure their success.  The excellent comments from Glen and Stephen (here) pointed to the answer.  From Glen:

We are looking for cost savings, efficiencies, and other process improvements. This is the typical work flow process improvement approach. Extend that to the human processes – monetized – and you can define MOP’s and MOE’s [measures of performance and effectiveness respectively].

In retrospect, it should be obvious that training deliverables — and their measures and incentives — should make such deliverables accountable for the relevant process/solution/project/program success measures.   In other words, CRM call center training should be judged by the how well the call center solution delivers the intended capabilities.

This approach is not so obvious to many training professionals, largely because many have never been held to the same standard as process owners.   My experience — from observing a particularly savvy SAP customer — is that a few pointed questions do concentrate the trainers’ minds:

• Are you worried that the training does not support the actual execution of the processes?
• What do we need to change in our training approach so that it delivers value to the project?
• Why am I spending money on training if it can’t be held accountable for project/process succeess?
• Do you still wonder why trainers aren’t better paid?

A good upgrade “why to” list

Regular Crossderry readers know I’m partial to ERP upgrade tips and advice (here, here, here, and here).  This list by Beth Stackpole stood out as one of the more practical and insightful “Why to upgrade” lists around.  In particular, point four is often overlooked.

1. Upgrade an ERP system that’s more than five years old.
2. Upgrade when ERP system integration is difficult.
3. Upgrade when an ERP system is missing the “modern” features and functions required to efficiently run the business.
4. Upgrade when employees, partners and consultants aren’t using the system — or aren’t available to fix it.
5. Upgrade when it’s obviously time, whether the hard upgrade ROI is clear or not.

As they say… read the whole post.

PM Quote of the Day — Vince Lombardi

Practice does not make perfect. Only perfect practice makes perfect.

When I was younger, I never got the point of practice.  Sure, I knew that it would get me in shape and knock of the rust off.  However, I never got the idea that practice would help me perform better under pressure.  Too many times I found myself over-thinking a situation because I hadn’t practiced enough to make it automatic.  I finally started to realize that realistic practice in all sorts of endeavors — in particular, public speaking and presenting — helped to take the edge off along with the rust.

Practice?... We're talkin' about practice?

Lombardi’s point also applies to how we test our processes and systems.  Too often I’ve seen customers and consultants assume away difficulties in their desire to save testing time and money.  Even worse, this saving “spasm” usually comes towards the end of the project, just as the testing was about to get serious.

The best testing practice (so to speak) I’ve seen came at a global firm that does dirty and dangerous work.  As you might imagine, that company is very conscious of safety and quality.  That firm called their last round of testing not integration or user acceptance, but “business simulation.”  Business simulation didn’t simply involve folks following a script.  We brought the system, interfaces, and data up like go-live, then encouraged the users to go “do their jobs” and call support if something went wrong.

Sure, such an approach is expensive.  But how much is that peace of mind that comes with a no-holds-barred validation that the system and its support conformed to requirements worth?

This downturn’s test for SaaS/On Demand

This almost-inevitable downturn will answer one of the open questions about SaaS/On Demand: How “recession-proof” is Saas, really?   Already, an number of SaaS vendors have seen their forecasts taken down, just like normal enterprise vendors (here and here, for example). 

Of course, many still believe that SaaS is recession-proof (see Jeff Kaplan posts and comments here and here).  I certainly don’t believe that as a blanket statement.  In fact, I believe that on demand vendors that focus on edge processes will be in deep trouble.   That’s because one of the benefits of SaaS to customers is the ability to stop consuming whenever they like — and edge applications will get stopped first. 

It is funny how we don’t hear about the benefits of “consumable” services now that consumability doesn’t exactly match the “SaaS is immune” narrative.  Per my earlier rants on this topic (here and here):

The ease with with one can consume services — which certainly does promote usage — is matched by the relative ease with which one can stop consuming services.  If one can get in easily, one can get out easily…. Also, trying to mitigate that risk by locking-in revenue with longer subscription periods sounds good, but it makes SaaS/On Demand too strongly resemble an On Premise relationship.

That last sentence is one example of the On Demand catch-22: as SaaS gets more embedded in the enterprise core, the more it behaves like on premise (e.g., SFDC’s lengthening sales cycles). 

Maybe Harry Debes isn’t so crazy after all (here and here)!