Last year, I spent some time with the person who runs SAP's RampUp program in the UK. I will explain why later, but what struck me as incredibly interesting is that she described how difficult it is to persuade UK customers to join the program.
What is RampUp?
For the uninitiated, SAP's RampUp program is their mechanism to get new product to market. It could be likened to Microsoft's Beta programs but there are a number of key differences. The main one is that RampUp is generally a means to limit the number of people on the product early doors, rather than a statement of the quality of the product.
For a product to exit RampUp, it has to meet a certain number of criteria. For example a certain number of customers must have gone live, a certain number of software issues must have been resolved, etc. There are a strict set of KPIs and some products never leave RampUp. This has the added benefit of not ending up with products with 1 or 2 customers, that have to be supported for years. Software is like sex in that respect - one mistake and you have to support it for 18 years.
Why are we afraid?
My experience is that many SAP customers adopt a "N-1" policy. They look at the latest version and use the one before instead. This is a risk based approach, usually because they have experience of some previous project which failed. Usually that product was new to market and there were a bunch of problems with it. And they blame those problems for the project overrun, failure, or whatever else went wrong.
Once tarnished with that brush, customers tend to keep well away from new software, especially in Enterprise IT, and particularly where it forms part of core business process - where money will be directly lost if the IT system goes down.
What if there's no choice?
I got involved with the SAP RampUp team because I was involved in a project last year that was under extreme pressure. Another SAP Partner had walked off customer site, citing that the project was undeliverable. We had come in at the last minute and the project was deliverable in our estimation, provided that we changed the approach and delivered it a different way.
Because the project was so important - it was effectively required for legal reasons and the ROI was substantial, the customer agreed to our revised terms and we kicked off the project.
It then became very evident that the current version of the SAP product had some shortcomings, which had been addressed in the new version that was in RampUp. In short, implementing using the brand new version would slash development time and mean that we were more likely to be able to meet our tight deadlines.
I stuck my neck out at this time and made the case hard to use the new version, despite this being an organisation with a "N-1" policy. The customer agreed and we went with it - and there was some pain. Bugs that needed SAP attention at short notice and some additional pressure due to the new technology. But, it turned out to be clearly the right thing to do.
Is technology really the problem?
I've made this point before and I suppose I make it again, but I believe strongly that it's rarely the technology that's the problem - provided it is a good fit. There's only three things (in my estimation) that make projects a success, and you need at least one of these on a project that doesn't fail.
1) Quality people
Great people see problems earlier, design around them and have a restless curiosity that means the project gets delivered. Great project managers see risk and opportunity ahead of time and keep the team motivated. Great functional consultants read the business, challenge the business community and change the way the customer thinks. Research shows that great technical consultants are a different breed - you either have it or you don't, in the programming world.
2) Governance model
The process that surrounds the project delivery can make do with lesser quality people and can mitigate all sorts of problems. I have seen projects delivered with OK people and fantastic governance, and be a success. Plus, good governance helps spot the weak or badly positioned people and weed them out.
What's more, a good governance model ensures that technology problems are resolved and escalated. SAP's RampUp model ensures you have a thing called a RampUp coach who is suppose to be a subject matter expert. You have to pay for this and the technical qualities of the coaches vary, but they have a governance framework that allows direct access to SAP development. They track the project internally and it gets massive attention if required.
3) Business sponsorship
Why are you doing the project in the first place? If you don't have a business sponsor - one who can make decisions based on the governance model, then you're doomed when the going gets tough. In our example, we had a business change director who was the sponsor. That person was able to make some tough decisions on things which had wait until phase two, be tough around the requirements and tough internally when the organisation wasn't being as agile as it needed to be.
Why do we implement IT projects in the first place? Really only one reason - to maintain a competitive advantage in the business world. This may be shrouded by cost reduction or some other KPI but essentially we implement technology to gain competitive advantage.
And this is why I don't understand why organisations choose to implement on anything but the latest tech - to gain the best competitive advantage. You need great people and great processes but that has to be a given in this impossible world in which we live.
And with the new tech that SAP is bringing to market this year - in Memory and Mobile in particular, businesses can get huge benefits if they are willing to adapt early and change.