Over the last few months I've had more than my fair share of involvement in SAP HANA and it feels what has happened in the market is very interesting. It's not really different to any other IT product lifecycle - check the Gartner Hype Cycle if you don't believe me - but it's very concentrated in this particular product.
What is clear is that the theoretical potential of in-memory computing is huge. It is reasonable to suggest that even the more audacious of blogs written but the likes of Jeff Word, VP of Something at SAP, and Bob Evans, VP of Strategic Communications at SAP have wrote, might not be crazy, in a future sense.
What is also clear to those that are close to SAP HANA implementations, is that it is a Version 1.0 product. With that comes the usual early implementation problems, lack of features and lack of mature administration tools and the like. What is even more to those close to the software industry, is this this is not exceptional to the SAP HANA product - but it is common to almost every piece of software produced in the market for the last 30 years.
Why is SAP HANA different?
This is hard to say, but I suspect it's down to just how heavily SAP marketed its readiness, and just how much SAP HANA was going to change the world. In doing so, they managed to create an expectation in the financial analyst, industry analyst and Enterprise IT communities alike. Honestly, those people really should know better, because software can't be the second coming!
So when SAP HANA shipped to great fanfare and turns out to be an excellent data mart and calculation engine - rather than the solution to world hunger - all three communities were offended. What's more, some people bought the hype a bit too much and SAP HANA risked being oversold on a number of occasions.
Today that leaves everyone - especially the financial analysts - a bit frustrated. That's odd because it looks likely that SAP are going to hit or even beat their sales numbers for HANA, which is pretty good going. But I suppose if you market something so heavily, people may just buy it.
It's new technology - so what?
What seems to be really interesting about SAP HANA is that now the dust and hype has settled, it is just another new technology tool. A pretty good one at that. However what is really interesting me today is the psychology behind the Technology Adaption Lifecyle. What makes some customers jump to implement new tech (Early Adopters) and what makes other customers wait until they are absolutely sure the tech is mature before they implement it (Laggards).
This seems to vary by geography and also by industry vertical as well. Partially, the geography is economically driven, which drives certain buying patterns. There is also the cultural dimension - the North American market is more likely to invest in tech earlier, than for example the UK market.
New technology and business logic
None of this makes any sense to me. For me there are only two real relevant questions:
- Does this technology provide business value? Lets take SAP HANA as an example. There are some clear cut examples where SAP HANA provides obvious and simple business value - for example reducing month end close, increasing revenue, or decreasing operational cost. Or perhaps fraud reduction. Either way, value is measurable and an estimate for whether and how long value will take to attain.
- When can it be implemented? Once you have decided that it provides value - and that needs to be put in the context of IT and business strategy, so you don't end up with a smorgasbord of point solutions - the only other real question is when to implement. Put in the context of a wider roadmap this should be quite easy to answer, but the important point is the longer you take to implement it, the longer the time to value.
Technology maturity is secondary here because if you have decided that it provides business value - and therefore is fit for purpose - then you really ought to get on and do it as soon as possible. The reason for this is that technology innovation provides your organisation the platform upon which to be unique in your market - and if done well, it is this that will make you more successful than your competitors.
Technology maturity and other project success factors
That said, I so often hear the words "well we'll see how someone else gets on first". When I hear that, I hear "we don't mind being second best". The reason for this is because whilst technology maturity is a primary factor in business and market success, it is not a primary factor in project success.
If you look at Enterprise IT projects, they fail for a lot of reasons. Take a look at Michael Krigsman's ZDNet blog, he has some good examples. But in my experience of SAP projects, they usually fail for a small number of reasons. By the way, these are the top three things that I look to mitigate when putting a project together.
Quality of people. Poor quality people design bad solutions, document them badly, and execute them badly. The A team may cost 50% more than the B team, but they multiply the chance of project success. By going with the lowest bidder, you are tacitly admitting that price is more important than success.
Governance. Great project managers put in great governance. They kick poor quality people off the project and they challenge the team. Risks are identified - and more importantly - mitigated. Butts are kicked. Doors are kicked down when necessary. People are held to account to what they said they would do. This is what makes for a successful project.
Relationships. The big one is the distance between the implementing team and the people who will be using it. If the organisational structure is not in place for those people to communicate then it is impossible for the project to be a success. If the business-as-usual support team does not support the project, the same will happen.
Technology maturity as a project risk
What technology maturity is however, is a project risk factor. Early-lifecycle products are slightly more expensive to implement. They require good quality people (didn't you want those people anyhow?). It is necessary to identify defects earlier, because they may take longer to resolve and more effort.
With very early-lifecycle or beta software, you also need some specific things like links into the product team. SAP for example, do this really well. They have a Ramp-Up system which assigns a coach to your project to link into the product team, and additionally have a Customer Solutions Adoption group (formerly known as the RIG). When used well, these can be used to help ensure success.
But really the point I'm trying to make is that this is just one more thing on the risk register - one that your great project manager added to the list on the first day of the project. Compared to other things like quality of requirements, availability of business resource and quality (and time) of testing, technology maturity is secondary.
In my personal experience, I have seen projects use beta and Ramp-Up software that have been a fantastic success because the new technology innovation provided unique business value. I've seen projects using very mature software that have been a total failure much more often, and it's usually because of people, governance or relationships.
My advice: worry less about technology maturity, and more about business value. And if, once you've cut through the hype, something new like SAP HANA can provide your business competitive advantage - get on and do it.