SAP Community Network delay: an alternative view

This weekend my email and Twitter feeds have been humming over the delay in the launch of the SAP Community Network. Michael Krigsman praises (sic) SAP for the delay but only offers the management view of why it was delayed. There are no insights into what happened behind the scenes and what led up to what I consider a failure. To that extent, Krigsman's analysis is incomplete.

For the many readers who will not be familiar with this project or its importance, some context is needed:

Background and context

SAP's Community Network is designed to achieve a number of objectives. Not only is it a place to hang out and brag about your latest achievements, it serves as an invaluable customer resource, a place for discussion on new technologies, and yes, a place to whinge and moan about what doesn't work so well. I have long argued that it is an excellent example of what an enterprise community can look like and remain a huge fan of what I see there. SAP sets the bar on community like no other company I know.

Over the years, advice, hints, tips and code have all been contributed. In recent years, SCN as it is better known, has become the first resource customers are encouraged to search for information that helps with their deployments. As a result, SAP saves a LOT of money not having to field initial first line support. Estimates vary but I have seen figures in as broad a range as $25-50 million per annum. A small amount in the context of the whole but not inconsiderable.

But SCN is an ageing platform that is showing its vintage. Search can be problematic. Material sometimes mysteriously vanishes and as for usability? Well - it was designed at a time when community contributors were stuck with writing HTML rather than the rich WYSIWYG UIs with which we are currently familiar.

Going forward, SCN will need to support a lot more than it does today. If SAP is to attract a new generation of developers then SCN has to be refreshed. It has to not only look modern but function as cleanly and smoothly as any social network with which a consumer will be familiar. If it doesn't achieve that then SAP cannot hope to recruit the extended army of developers it needs in order to make its mobile and cloud platforms world beating.

What went wrong?

Internal to the SAP community, there has been much anticipation about what is coming. Project leaders have been promoting the new community - as they should - and building up expectation. The fact they have had to pull back at the last minute is unquestionably a failure to deliver on expectations that were repeatedly set over a long period of time.

I don't for example accept the fact there was no top down pressure to roll out in 2011 as adequate an explanation when you've been telling stakeholders the project was due to be delivered. In similar vein, all projects carry timelines and deliverables, including go live. From Krigsman's post:

The original date was driven by desire to improve community experience rather than a specific external deadline.

To now imply there really wasn't a deadline or expect that to be accepted as reasonable is ignoring everything I know about project delivery.

In recent months I have participated in a number of webinars and conference calls where we were told about some of the upcoming features and shown the new UI. When the project is delivered I believe that users will be pleasantly surprised. If my experience is anything to go by SAP will deliver something that is a world apart from what we have today - and all for the better. That makes this delay particularly disappointing. To its credit, SAP has been taking some feedback but there have been important gaps.

Feedback I have received from multiple sources tells me that throughout the lead in to the go live there was almost no talk about user acceptance testing, unit testing, regression or volume testing. There are conflicting views on whether all of this is necessary for a project of this kind but the fact there seems to have been almost no discussion along those lines with extended stakeholder groups is a concern.

But what really worries me is that some of the technical problems outlined in the follow up explanation imply problems of a kind I am surprised Krigsman didn't shout out. Before going any further, I give SAP top marks for quickly explaining the technical issues and for management unequivocally shouldering responsibility. That deadens a lot of the pain. Unfortunately, those explanations open up different lines of question.

Single sign on for example seems to be a problem when surely that should have been ironed out a long time ago? It turns out that SSO is a core component for SAP's long term web infrastructure program and has undergone a degree of refinement. Out in the field I am hearing grumbles that it is 'flaky.' Like all technical problems it will get fixed but this is a core component for SCN. Not having a reliable SSO would be a deal killer. Why was this not managed into the project such that if there was going to be a delay then it could have been flagged up earlier.

It struck me that a project like SCN could have been rolled out piecemeal. This is because it consists of forums, blogs, wikis and other social paraphernalia. Did it all have to be in place on day one? In other projects I have been involved with of a similar nature, the rollout has been more of a 'rolling thunder' approach. This allows users the opportunity to get used to the new in stages. It works. In this case, I am in a minority and that is probably more a reflection of my lack of understanding than the approach. Either way, the team were stuck with a Big Bang delivery. These are almost always problematic. My question then is simple - was this ever going to be feasible given all the pieces that make up the puzzle?

In the explanatory post, SAP points out the many moving parts the company is hefting. A big chunk comes from Jive but there's a lot of internal work going on as well. In essence, SAP has been hefting three components, all of which are in motion:

• The Jive platform - which went through some 500 bug fixes between version 5.0.0.0 and 5.0.1.0.
• Important internal development that impacts the new community platform.
• Development specific to the community roll out.

It must have been obvious at some point in the past that managing all of that was going to require deft handling and that delay in any part of that equation would have knock on effects.

As with all projects of this size, there is going to be disagreement but from what I can gather there were breakdowns in communication going back months. That is usually a signal that the project is becoming unhealthy. Yet as far back as the late fall, SAP was telling me this project had a go live date of December 5th or 12th with no inkling of major issues.

The Community response

Despite all the above, the SAP community has been remarkably forgiving. In Tweets and G+ comments the general consensus is that SAP made the right decision. I wonder if the same would have been said if one of the big SIs was in this predicament.

Looking at the list of issues, it was the only decision SAP could have made. There was no Plan B other than an as yet unspecified delay. I fully appreciate the risk of SAP ending up with egg on its face and fighting multiple problems while in flight. That doesn't detract from the disappointment and yes, there is a functioning facility albeit it is as crabby now as it was last week when the hold decision was made.

What those who are praising the decision are failing to see are the project implications for SAP as a whole. As a highly visible project, SAP has the unenviable task of delivering the best it can. But as I have said before, quality isn't enough, a refrain to which I will no doubt return. On what I had seen, SAP stood - and still stands - a good chance of delighting and surprising its users.

Project management issues

The more one looks at this project the more one is drawn towards the conclusion that a level of inexperience in managing projects of this scale overwhelmed the team. That should not have happened. Why for instance was it only at the last minute that the gravity of problems became such that the project shuddered to a halt? Was none of this foreseen or was SAP plain unlucky? Something somewhere went awry in the planning. How can you not for example plan adequately for delays when working in different time zones? That must have been a known quantity from the get go? Having experience of that myself I understand the pressures but there are ways around it. I am sure there is a lot more to add but I throw that out as an example.

Why does this matter?

In recent times, SAP has been drawing back consulting and development for customers to itself. This has caused some alarm among SIs, concerned that this is not core SAP business. Yet it makes some sense in the context of the big bets SAP is making around technologies like HANA. If a project of this kind, which some might see as a 'nice to have' but which I personally believe is critical for the company's future, can expose project management questions, what does that say for SAP's ability to manage projects more broadly?

The good news is that those who have had their heads in the code now have a chance to breathe and regroup. I know some of these people personally. I've worked with some of them and they are fine individuals. In private conversations, they are upbeat and happy that a new date has yet to be fixed. The pressure is off, but it is a temporary reprieve.

As we approach SAP Influencer Summit this week, I don't doubt I will get plenty of feedback from those both in the know and those in the peanut gallery. Whatever the outcome, I hope SAP takes lessons from this for the future. Much depends upon it.