A buy side response to the enterprise buyer's Bill of Rights (and a partial solution)
My first post of today pointed towards an all too familiar enterprise project 'fail' and the documented experiences of one project person trying to reach completion on a now two year implementation. Coincidentally (I didn't know this was in the pipe), Mike Krigsman provides a critique of Forrester's Enterprise Software Buyer's Bill of Rights v2. As I read through Mike's critique noting lead analyst Ray Wang's response, I started to become uneasy.
While both Mike and Erik Kimberling separately make the assertion that unrealistic expectations can and often will derail an implementation project from the get go, I disagree with Mike's assertion that:
The bill of rights does protect the customer, which is the stated aim, but only covers half the territory needed to produce successful projects. Although the report does not advocate that customers deny their own responsibilities, I am concerned some may inappropriately use the bill of rights as an excuse to do just that.
[My emphasis added]
Logically speaking, if we're talking about Mike's Devil's Triangle, then from the buy side, we're looking at a third and not a half. Be that as it may, there is an inherent assumption in Mike's analysis that buyers are in the same position of understanding as vendors and SIs. That's simply not true. While I can perfectly see why some buyers might attempt to use a Bill of Rights to squeeze the pips on a deal, vendors and SI's almost always have much better information they can use to leverage against customers. Why?
The principle reason is that vendors and SI's have been doing implementations for upwards of 15 years. They have thousands of implementation and customer experiences they can leverage such that when a customer raises an objection they have a canned and often plausible response that often includes the 'buy more' phrase.
On the buy side, an enterprise project and especially an ERP project may be the first and only time that customer staff come up against an SAP/Oracle etc. I recall well AMR's Bruce Richardson once saying to me: "You do ERP once, concrete it over and hope you never have to dig it up." Given that the odds are so heavily stacked in the vendor/SI's favor from the get go, it seems incongruous to me that you can realistically expect the triangle to be anything close to equilateral. Hence lead analyst Ray Wang's articulation of a Bill of Rights.
You only have to consider how vigorously SAP's German user group fought against the maintenance price hike and then compare that with the way ASUG pretty much rolled over to see yet another problem: differences in perception and a sometimes lack of willingness to question the vendor. I can't tell you the number of times that buy side people have expressed concern that if they create too much noise then the vendor will retaliate. That's especially true in the SAP user groups, less so in the Oracle groups which have been much more independent in their thinking and actions.
Looking at our anonymous correspondent's documented account, it is abundantly clear that there is serious misalignment. This would seem to be normal rather than the exception. The SI involved is making basic mistakes that should never be part of the buyer's problem. Here's a great example and one that strikes at the heart of what this person believes to be the vendor's business model:
In some of the consultancies, the people that work for them are employees, but many are only on short term contracts - say 18 months to 2 years. These consultancies will hire people for the specific project based upon need and skill. Unfortunately, many of the people hired are of varying quality - and in some cases, they end up working in a module area that they are not particularly skilled in. I've also seen that the consultancy can hire in a person who is in turn a private contractor, and these generally get paid by the day or week. I also understand that in some cases, the larger consultancy contracts out part of the work to a smaller firm. And of course, the smaller firm can then hire in the actual people, who might even be employed by yet another business.
You see, some of these consultancies specialize in specific areas - HR, Accounts, or groups of modules such as those that make up the manufacturing process. The concept is fairly sound - you hire in the expertise in the area that you have the need. This allows you to act as a consultant even if you don't have the required specialization.
But with all of these different people, using different employment methods and structures of reporting, you find communication problems even in the relatively simple projects. From experience, many of the individuals like to work in [a] particular way and use specific methods or practices - in some cases, these clearly don't meet the specific requirements, and I've seen that they often go against the defined goals.
Now, for a lot of people, this will seem a strange way of working - but you have to understand that this is the SAP business model. They are NOT in the business of selling software - they actually want to sell the knowledge and experience of the consultants, either as business consultants, project management, training, education services - basically all of the additional items that are perhaps a bit harder to quantify.
[My emphasis added]
I doubt SAP would agree although it is clear their business is moving more towards a services model. But this leads me to a critically important point I have been arguing with SAP both on SAP Mentor back channel sessions, on blogs and at SAP Mentor sponsored events. It is not one that is well addressed either in Mike or Ray's analysis.
Current SAP education is no guarantee of ability on any SAP implementation to the point where it has to be radically overhauled. I have argued that SAP could drastically reduce the incidence of failure if there was a coherent certification program in place that is the equivalent of a professional qualification. To me this is so basic I cannot understand why it is not a mandated requirement.
The most common argument used against such a move is that consultants would either have to fund the cost themselves and/or employers would need to provide 'time out' for study and examination beyond the common six week's classroom that newly minted consultants go through.
Instead, the large incumbent SI's claim they have their own systems of training and that if SAP doesn't like it well - they know what they can do about it. Take a hike. If ever there was a case of the tail wagging the dog then that's it. In the meantime, guess who gets caught in the crossfire? The customer of course.
In the days when implementing SAP (read also anything Oracle has acquired and to a lesser extent Microsoft) was a matter of coding to assemble building blocks, you could be forgiven for arguing that much beyond ABAP (read also Oracle DB/PeopleSoft, JD Edwards etc) skills was enough to at least get you to some sort of go live. Today's software is much more complicated. Even SAP acknowledges that to get the best out of its solutions requires significant business process expertise that is pretty thin on the ground. Here is the analogy I like to draw:
When I was training to become a professional accountant you needed to know a bit about a lot of things to get through the examinations. You learned on the job and went to school. Your employer provided an apprenticeship program through which you learned and were mentored. Once qualified, you could choose to specialize.
Qualification was something you could confidently show an employer as the basis upon which you could be trusted to do certain things. It doesn't work all the time but a good 80-90%. Roll forward 35+ years. You'd still have to do the same but today it is likely you will automatically specialize in a narrow sliver of a topic. It is also mandated that you will engage in continuing professional development in order to retain your status. That's because the world has become much more complicated.
I see no fundamental difference between 'my' old world and that of enterprise applications implementation. If anything I'd argue that the creation of a structured program of education would serve as a genuine differentiator that could crush many of the problems we see articulated through both Ray and Mike's analysis.
I'd go further and insist that if you're buying enterprise software then you sign up to learn about it the same way anyone else would have to. That way you open the door to developing centers of excellence which already exist in some companies and so create the environment where companies can become self sustaining in their post implementation operations. That's value delivered for my services and support dollars with a genuine ROI that can be seen, assessed and measured. It also addresses some of the inequality problems inherent in the Devil's Triangle and goes some way towards Mike's notion of customers accepting responsibility.
The burning question is how willing the vendor community will be to act upon these ideas. After Ray wrote the first Bill of Rights, he said:
Given the complexity that users faced, experiences from 250 client advisory, inquiries, and face to face discussions were applied towards the productization of IP into syndicated research. On December 18, 2006, we released 36 user rights in a report titled “An Enterprise Software Licensee’s Bill of Rights” (see Figure 1.) Expanding on these 36 rights, we then battle tested the Enterprise Software Licensee Bill of Rights with 12 vendors (i.e. Agresso, Deltek, Epicor Software, IFS, Infor, Lawson, Microsoft, Oracle, QAD, Sage Software, SAP, and Sterling Commerce) across 97 criteria in the industry’s only policy based evaluation - The Forrester WaveTM: Enterprise Apps Software Licensing And Pricing, Q4 2007, released October 15. 2007. During the evaluation, we were pleasantly surprised to find that most vendors were open to this idea of a mutually agreeable bill of rights. In fact, many commented that this was the upfront communication needed to create a win-win relationship.
Anyone out there see genuine signs of progress and change? If our anonymous friend is a reasonable proxy then the answer must be a resounding no.