Project risk management is about making decisions regarding uncertain events that might impact the business or the project in a negative or positive way.  It involves estimating the probability that these events will occur as well as the potential magnitude of their impact.  These assessments and decisions on mitigation can be erroneous for any number of reasons.  In my experience cognitive biases are often times at the foundation of these assessment errors.  Cognitive biases are psychological tendencies that cause the human brain to draw incorrect conclusions.  The concept of cognitive biases as it relates to decision making was introduced in literature in 1972.  Since that time, more than 100 specific biases have been identified.  These tendencies can be a product of experience, social or cultural environment, or motivational.

Consider the opportunities for biases to impact the risk management processes in the face of the different motivations and experiences of the Systems Integrators; Your Project Team, Line Managers and Senior Executives. This leads me to the fifth imperative of ERP Implementation Risk Management (For imperatives 1-4, check out Part II:  The Silver Bullet and Part III:  Executive Engagement):

Imperative 5: Leaders need to recognize that biases exist in assessing risks.   Before you can solve a problem, you need to recognize that you have one to begin with.  One thing we can categorically state is that risk assessment is influenced by the biases of the individuals participating.

To develop a better understanding of how these biases affect the risk management process, we have outlined a few of the biases most frequently observed.

Anchoring Effect – This is a tendency to rely too heavily or anchor on a past reference when making assessments.  A general tendency of the human condition is to believe that the right answer is close to an answer provided by an expert.

Confirmation Bias- A tendency to search for information or opinions that are closely aligned with your own to validate your thinking.  Often times, members of the same organization or project team will fall into the confirmation trap as they have a common set of program / project experiences.

 Selective Perception – Guarding your own interests or constituents.  In the space of ERP implementations, this bias tends to manifest itself in assessing go-live readiness.  There is a clear tendency of system integrators to minimize the probability of business disruptions when the reward for such thinking is an increase in the probability of attaining the on-time or under-budget delivery bonus.

Availability / Recency Biases – We will categorize these two together.   These biases are a tendency to utilize information that is available in memory.  This tends to be events that were unusual, vivid, or the most recent occurrence of an event.  Take the example of assessing the probability of a server failure when the assessor recently experienced such a failure on a prior project.  In this case, there is a good chance that the assessment of the probability and impact of such an event will be biased.

 Optimism or Positive Outcome Biases – Program managers by their nature often carry this trait. It is extremely difficult to do this job unless you believe a lot of things are going to go right.  This human tendency also manifests itself when there is a negative consequence to delivering bad news.

 Hubris or Illusion of Control – This bias manifests itself in the belief that program managers have the ability to control events that they clearly cannot.   This often occurs when considering an individual’s ability to sway an executive’s opinion of a situation.

Given the significance of cognitive biases and the influence they have on the risk management process, it is important to understand a few of the techniques that can be ued to minimize the effect of these biases.

1. Work with Multiple Anchors – obtain multiple independent opinions of probable risks and potential impacts.  Having in hand 2-3 assessments that are not influenced by each other will help in properly positioning risk on your matrix.  If the assessments are significantly different, it may properly cause you to dig deeper into the situation.

2. Probe the Expertise of the Experts – when an expert is providing an assessment of a situation you expect them to draw on their past experience and education.  Program managers need to dig deep into the assessor’s credentials to confirm relevant industry, geographic, domain, and project team experience.  It is critical to make sure your experts, are in fact, experts.

3. Make decisions based upon empirical data vs. intuition – whenever possible, sequence your assessment process such that you are gathering data first and then assessing risk next.  Asking for an opinion and then obtaining the supporting data is a leading cause of the confirmation bias.

4. Tapping Into Un-Biased Experts – engage experts from outside the core project team who have a limited stake in the outcome.  The best advice is often times from those who have the least to gain or lose.

By merging these four techniques, we form the sixth imperative of ERP Implementation Risk Management:

Imperative 6: Engage independent agents in assessing risks.  Independent experts can provide separate assessments for anchors, probe the expertise of the system integrator, offer empirical data, and most importantly, maintain a limited stake in the outcome.

A good program manager is not one who believes they fully understand all aspects of a program, but rather one who encourages good questions so that big decisions and significant risks are fully vetted.   Our next post in this series will dig into the inter-relationships of risks and the compounding that can occur.

We welcome your thoughts, feedback and the opportunity to engage in collaborative discussions.  Please do not hesitate to contact David Blake with any feedback or inquiries or leave us a comment. We look forward to hearing from you.

Good program management practices in risk management focuses teams on the following two aspects: treating risks that they can control and working on contingency plans for risks that are uncontrollable. It has also been demonstrated that people are more likely to accept risks they view as controllable and voluntary.  It then stands to reason that by increasing the span of controllable risks there is a higher probability of overall program success.  This expansion of control can be realized through exercising the appropriate level of executive engagement.  In this post, we will look at some of the nuances of structurally engaging stakeholders / executives in the execution of the program risk management processes.

First, let’s define the characteristics of a stakeholder as individuals or organizations:

•             That stands to gain or lose through the success or failure of the project

•             Provides funding for the project

•             Participates in or has invested resources in the project

•             Is affected by the outputs or outcomes of the project

•             Is in the “chain of accountability”

In the case of an ERP implementation this typically involves the COO, CFO, and the CIO.  By this broad definition we will also bring the Software Provider and the primary system integrator into the mix.  It should be noted that these players also fairly represent the five risk effect areas and five sources of risk outlined in ERP Implementation Risk Management Part II: The Silver Bullet. Before getting into the specific methods to involve stakeholders, I first need to get into three specific problems that need to be overcome.

Problem #1:  Differing organizational nomenclature and business area understanding.   Integrating the organization typically means bringing together areas of the business that have largely remained as functional silos.   These islands of operation develop a language of their own and tend to be motivated by different performance measures.   Consider the discussion measuring the potential impact of a go-live, attempting to balance the priorities between a timely closing of the books and making a major shipment to a critical customer as promised.   Now add an IT professional that is attempting to explain risk associated with cloud computing and you have all the conditions necessary to create the proverbial tower of babble.

Problem #2:  Risk evaluation is fundamentally subjective.  Risk assessments depend on the judgment of experts.   Experts whose theoretical models are filled with assumptions and biases.

The question becomes “who do you trust?”.

Problem #3: Stakeholders do not benefit equality from the identification of risk.   To understand these problems simply consider the scenario of the Systems Integrator that is attempting to land the big contract.   The SI is out to win the business, so limiting the discussion to what is easily controllable puts them into a better position to win the deal.

To address these problems we will introduce two additional risk management imperatives:

Imperative Number 1:  Utilize a knowledgeable impartial facilitator to engage stakeholders in a risk evaluation workshop. A well-managed session will enhance the risk management process by influencing/ synchronizing the stakeholder’s perception and making them more conscious of the context of their responsibilities in mitigation. This is often times referred to as “attention shaping”.

Stakeholders should emerge with a new appreciation of other stakeholder interests, business constraints and a new awareness of common interests that did not previously exist. The identification of common objectives is also critically important in fostering a sense of collective responsibility and collaboration between the key stakeholders involved facilitated session.  We are broadening the scope of the controllable risks in effect.

A facilitated session should have 3 primary goals:

A.            To influence individual perceptions or risk.  By creating a greater awareness of risks and the controllability of risks, stakeholders should develop a greater acceptance or risk, increased trust in other stakeholders, and an understanding of what commitment on their part is required to mitigate risks.

B.            Synchronization of perception. Through the sharing of concerns and the clarification of expectations and potential dangers, stakeholders should come to a shared perception of risks and a collective understanding of the actions required to mitigate.

C.            Improved probability of affective mitigation efforts. Actions developed in these sessions foster both a collective and individual ownership of the mitigation activities.  Clear priorities can be established that will enhance the speed and quality of future decision making.

A well facilitated session will typically identify as a primary mitigation of risk as the assignment of the appropriate talent to the program.  We have discussed this subject in previous blog posts so it will come to no surprise to those that have been following along.

What I want to explore now is the idea of full-time vs. part-time assignment to the team, while it is abundantly clear that user involvement in design, testing, and deployment is critical to the success of the program.  It has not been well documented why full time organizational assignment is beneficial in achieving the goals of the enterprise.    Recent project team productivity studies have shown that full time assignments provide three benefits:

1.            Individuals are more likely to focus on the total business case. Freed from the organizational structure of their previous department, individuals are more likely target benefits and risks that pertain to the entire organization vs. what is specifically in it for their department.  Therefore, increasing the probability of program payback.

2.            Increased sense of ownership of delivery.  Studies have shown that individuals that are organizationally assigned to project teams tend to take actions to improve the delivery process and more aggressively move to mitigate risks.   Part time resources or full time resources assigned to the project, but not organizational moved, tend to follow the process, but if something goes wrong with the process claim no ownership.  They in effect “let the process happen”.

This leads to are next point:

Imperative Number 2:  Executives should demonstrate commitment to the effort, and increase the probability of success through the organizational assignment of top talent to the project.

Senior Executives and stakeholders are recognized as being a critical component of success to any broad based ERP or IT enabled transformation initiative.  Executives can demonstrate their support and commitment to their own people and the rest of the organization by taking ownership of risk.

In the next installment of this series we will dive deeper into the biases that surface in risk management and how to reduce the impact.

Quite simply, an ETLA represents Adobe’s contractual means to move all of their enterprise customers to a subscription based licensing model.  The writing should have been on the wall (and it was at UpperEdge) that Adobe was going to push their enterprise customers in this direction after Adobe introduced the subscription only offering Creative Cloud to the consumer market last year.

This move to a subscription based licensing model is very similar to the approach taken by many large IT vendors (SAP, Microsoft, CA Technologies…to name a few).  It should not come as any surprise given the strong likelihood that such contractual arrangements will create vendor lock-in and allow for such IT vendors to capture from you and your organization lucrative recurring revenue streams (i.e. high attach rates).

Adobe’s move to the ETLA has effectively removed the traditional ELA that Adobe had in place with the majority of their enterprise customers.   Under the traditional ELA model an organization had the choice to terminate their relationship with Adobe or chose not to renew and walk away with perpetual rights in the products being utilized and those that have been paid for up until termination of the relationship.  Under an ETLA, you still have a choice to terminate (or not renew) but you walk away with nothing.   There are no license rights in perpetuity.   If you want to keep using Adobe and the products that your enterprise has become “tied” to, then you really have no choice but to renew another three year commitment with annual payment obligations.  Even if you don’t need and/or want any of the latest updates that come with such subscription.  An ETLA and the price associated with it include Maintenance and Support (“M&S”).

Given this push, you may be left asking yourself, what can we do?

As we have covered in numerous prior blogs regarding subscription based and/or cloud agreements, it is important to ensure you negotiate key elements into your contractual documentation with Adobe.  In addition, it is critical that you take time to carefully evaluate and understand whether or not you actually need all of the products that you are signing up for as part of your subscription.  For instance, if Creative Cloud Enterprise is being considered and could potentially become part of your ETLA (Adobe may present this as a Creative Suite ETLA or Creative Cloud ETLA) then it will be important to ascertain how much value (i.e. likelihood of utilization) your organization may receive from some of the products included as part of Creative Cloud Enterprise (that you are paying for starting day one), products like Fireworks and Audition.   If you determine that there are products that you will not need (perhaps ever), then it will be important (as part of your negotiation) to raise this to Adobe with the expectation that they offset your concerns with either a deeper upfront discount or scaled pricing (or a combination of both) where your annual payments align with your increased utilization.  In other words, with scaled pricing you would receive additional deeper discounting in year one than in year three because you are not utilizing particular products until year three.  If you can present to Adobe a ramped utilization of the products you are forced to purchase under their offering (i.e. part of a large product suite like Creative Cloud Enterprise) or even a likelihood that there will be no utilization during the forthcoming subscription term, it will be hard for Adobe to justify the associated cost with the offering they are selling you.  If Adobe is truly looking to form and/or maintain a partnership with your organization (which I am willing to bet will be mentioned throughout their proposal presentations and discussions) then they should only be interested in selling you a solution.  If you are not utilizing all of the products purchased Adobe will be hard pressed to justify their offer as a true solution.

The bottom line is, unless you are in the business of negotiating with Adobe, it is impossible to ensure you have asked all the right questions, achieved a competitive discount, negotiated all the proper protections and executed a best-in-class ETLA.  This is where UpperEdge can be of assistance.

We welcome the opportunity to discuss how best to approach your upcoming discussions with Adobe.   If you are like many of the organizations we have had the pleasure of speaking with, you truly can’t afford to get this wrong. Unfortunately, it will be impossible to avoid this significant and potentially painful change by Adobe.

Please do not hesitate to contact me at amansfield@upperedge.com with any feedback or inquiries.

In “Don’t Become an ERP Horror Story – Implement Solid Risk Management”, we contend that project risk management is the silver bullet in the successful implementation of a business transformation and outline 5 areas where risk management can go off the rails:

1. Failure to establish the proper context of the risk management process
2. Neglecting to engage senior stake holders in the risk identification
3. Not recognizing and addressing biases in the identification and assessment process
4. Failure to account for risk interrelationships and the potential amplification of risk
5. Lack of rigor in tracking and treating risks.

In this post we dig deeper into the first of these items: failure to establish the proper context.

There are a number of good standards and practices prescribed to effectively manage project based risk. PMBOK (Project Management Book of Knowledge) and ISO 31000 Standard: Risk management – Principles and guidelines, are two examples. A gross simplification of the processes is as follows:

A. Identify the scope of what you want to go right that defines program success
B. Determine what can go wrong / or much better than planned
C. Figure out if there is anything you can do to prevent or enable these events
D. Take the appropriate actions consistent with the level of risk you are willing to accept
E. Track and communicate
F. Rinse and repeat

Our first failure point, failure to establish the proper context, deals with the first two steps in the process. I would stand to reason, that if you don’t properly identify the scope of what defines program success, there is a pretty good chance that you will have some big misses in the identification of what can go wrong. Thus, I will start with getting point A right.

A best practice ERP implementation risk management process will focus on managing the risk associated with five broad business outcomes:

1. Limited disruption to the business during the execution of the project. Business should not be substantially impacted through the draw-down or talent, or the improper manipulation of the current legacy environment.

2. Implementing the project in an efficient and timely manner. Staying within the framework of the budget and delivering on time.

3. Minimizing the impact of the initial deployment. Avoiding disruptions in customer service and a timely closing of the financial books.

4. Achieving the tactical benefits associated with the program. Typically this involves measured improvements in key business performance indicators like reductions in working capital, improved on-time delivery, or S&A efficiency.

5. Achieving strategic benefits. Examples might include opening up new markets, increased product portfolio, or improved management decision making.

Commonly, during the course of the program’s execution, a team can get focused on the second point related to staying within budget and on time. This focus on budget and schedule performance may become laser-like when System Integrators get involved. In particular, those System Integrators are motivated by contracts that reward this particular outcome. This is not a criticism of System Integrators or these types of contract structures, but rather to stress the importance to the Program Manager that all five business outcomes are essential and that the programs risk management processes must address all five with the appropriate rigor.

This leads us to our first imperative:

Imperative 1: ERP implementation risk management processes must consider five domains of risk effects: current state business performance, program execution performance (cost, schedule, and quality), future state business performance, program operational benefits, and program strategic benefits.

The second part of establishing the proper context involves the proper examination of all sources of potential risks. Many times we have seen programs get focused only on the risks that they believe they can directly control. This can leave anywhere from 40-70% of all risks unchecked. There are many articles, studies and publications that outline possible risks for execution and all can be valuable in assessing your own risks. What tends to be unimportant are the lists that prescribe the 5-10 things you need to get right.. or can go wrong with ERP. The subject is far more complicated and complex than a top 10 list. We segment the risks into five broad categories to guide your assessment process.

1. Talent – often times sited as the number one success factor talent is a source of considerable risk. This segmentation includes executive talent, project team talent, system integrator talent, end user engagement, and the overall assumptions regarding productivity and collaboration.

2. Technology – If the package you select does not fit your future expectations for your business model then you clearly have taken on a great deal of risk. Included in this category are software, infrastructure performance, vendor delivery performance, and system resiliency and security.

3. Implementation Process – ERP implementation includes the transformation of IT systems, data, people, and business processes. Risks can manifest themselves poor execution of these processes or failing to adequately link them together in a cohesive fashion.

4. Management and Governance – Ineffective project management, poor decision making, and the lack of executive involvement all fall within this area. A poorly designed / executed risk management process also falls into this category.

5. External – Often times these risks are totally ignored by project teams, but frequently they become the penny on the tracks that throws the train off the rails. Included in this grouping are legacy system stability, data quality, regulatory changes, unplanned mergers or divestitures.

Developing a solid view of sources of risk, leads to our second imperative:

Imperative 2: Develop a broad and deep understanding of potential sources of risk by engaging with a trusted advisor that has both the catalog or potential risk points but also the experience to understand the effect of these risks on all 5 business outcomes.

In our next blog post on this subject we will explore the importance of engaging senior level stake holders in the risk identification process.

1.  Consistent and predictable revenue streams

If there is one thing software vendors love most, it is predictable revenue streams. With the cloud, customers do not receive a perpetual software license in exchange for a one-time fee.  Rather, software is licensed or “rented” along with maintenance and support services for a period of time or subscription term. Once the term expires, the software licenses and associated maintenance and support services expire unless the subscription is renewed.

Software vendors now see the benefits of this model as every time a subscription term expires this presents another opportunity to negotiate a new fee at a higher rate. For financial modeling purposes, software vendors are able to obtain a predictable annual revenue stream for the term of the subscription, plus inflation adjusted (and additional profit mark-up) subscription renewal fees after the term expires.

Software vendors can be reasonably confident in these renewal fee price increases due to added leverage. Once a business software application has been incorporated into an organization’s business processes it becomes extremely difficult to terminate, as this will require a replacement product to be already licensed, deployed, and users to have undergone sufficient training. This migration process can take months up to years depending on the software application and the complexity of a customer’s organization. Plus most organizations do not even consider subscription renewals until a few months to a few weeks prior to their expiration, and the vendors are well aware of this. Also remember, under the subscription model a customer cannot just terminate maintenance or refuse an upgrade and still utilize their old application licenses until they find an alternative. The license right to use the application terminates if the subscription is not renewed. Therefore, software vendors can be confident in knowing that even if customers do not agree with any increased fees, in a vast majority of situations customer’s will have to grumbly accept them as they begin to realize it is the least intrusive and least expensive option available.

As an added benefit, software vendors will have the flexibility to not only increase fees, but to also modify licensing rules, metrics, definitions, structures, etc. after each term. This allows vendors to close any license and subscription loopholes that may be identified, terminate license and subscription policies that no longer prove useful, and further monetize software revenue.

2.  Elimination of defending maintenance and support value

As stated above, maintenance and support are no longer separate from the software licenses. Under the perpetual license model, vendors could not tie or attach maintenance and support to the license fees as this would violate revenue recognition rules. Vendors had to defend the value of their maintenance and support service offerings to secure those revenue streams and their annual fee increases. In recent years customers have been more willing to utilize alternatives to vendor provided maintenance and support – either through third party providers or moving to a self-support model for more mature applications. Now vendors will no longer have to separately defend maintenance and support as the subscription fee bundles access to the software and maintenance and support as part of the subscription service.

As an added benefit, software vendors can stem the tide of third party support providers stealing maintenance and support revenue as the subscription model eliminates this possibility. Learn whether or not third party maintenance and support is a good fit for your organization.

3.  Built-in version adoption

One of the biggest challenges software vendors face is customer adoption of new releases of previously licensed software. As technology is rapidly changing, vendors are continually updating their software and developing new applications, sometimes on new platforms. Since the new applications are developed on the latest technology or platform, some older applications may be incompatible with the new application. This means that customers who may benefit from a new application often have to upgrade their older applications to newer versions in order to integrate and receive the full benefits – resulting in a larger and more complex process with greater costs and a longer timeline. Many organizations are faced with a cost/benefit equation that is difficult to justify until there is enough pent up demand and potential value that accrues over years.

In the cloud, the software vendors host the environments running their software applications as part of the subscription service they provide to customers. The vendors have full control of the environments and can determine when to release and deploy new application versions as well as integrate new products. Gone are the days of software vendors spending countless hours and money trying to build a business case for their customers to adopt the latest product release. Customers can now receive the immediate benefits of being on the latest product release without the added implementation costs associated with on-premise software.

4.  Self-help remedy for compliance or payment disputes

Another added benefit for the software vendors is eliminating ambiguity and confusion in the audit process and enforcement of audit results. By maintaining control and hosting their software applications, software vendors can easily track actual usage of their software by their customers, allowing them to quickly identify any unauthorized or excessive use scenarios and issuing an invoice for such additional license fees. Also, if a customer objects or unreasonably challenges the audit findings, the vendor has the ultimate leverage in being able to simply shut off a customer’s access to their software, which includes stored customer data. This provides the necessary incentive for customers to settle audit finding fees quickly and without dispute, or at the very least the vendors will be paid the fees while the dispute process proceeds. The result is a tremendously enhanced ability to enforce license compliance, extract license fees, and reduce large amounts of overhead costs currently required to enforce license compliance.

There are likely many other benefits for software vendors under the cloud model, but these 4 are some of the most compelling. We welcome your input, feedback and the opportunity to discuss other vendor benefits as well as the risks and implications to customers. Please do not hesitate to contact me at jlazarto@upperedge.com with any feedback or inquiries. To learn how you can ensure your organization navigates the cloud landscape successfully, be sure to check out our “SaaS Matters” blog series as well as our “Negotiating Cloud Agreements” webinar.

]]> http://www.upperedge.com/2013/03/4-reasons-software-vendors-are-salivating-over-the-cloud/feed/ 0 http://www.upperedge.com/2013/02/3-keys-to-negotiating-successful-cloud-agreements/ http://www.upperedge.com/2013/02/3-keys-to-negotiating-successful-cloud-agreements/#comments Mon, 25 Feb 2013 15:28:46 +0000 Adam Mansfield http://www.upperedge.com/?p=1713 Continue reading →]]> Nowadays it is both impossible and impractical to avoid the Cloud. Regardless if your organization is a growing SMB or finds itself within the Fortune 500 or Global 2000 list, it is highly likely a cloud solution is currently under serious consideration or has already been implemented. Many different types of cloud offerings have been implemented such as Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) as companies have been drawn to the cloud’s promises of agility, flexibility, reduced costs and faster time to benefits realization. The debate on whether these promises are delivered is for another post, so please check back in with us in a few weeks as we debate the cloud’s impact on fostering and sustaining vendor lock in.

Within the SaaS (Software-as-a-Service) category of the cloud, vendors such as Salesforce.com have been quite successful in gaining significant market share within the CRM (Customer Relationship Management) space as organizations and their respective sales branches have decided this would be a good place to start their journey into the cloud. Also, in the HCM (Human Capital Management) space, vendors such as Workday, SAP (through its acquisition of SuccessFactors), and Oracle (through its acquisition of Taleo) are aggressively pushing their cloud based offerings to the market. Salesforce.com and Workday continue to sell based upon a best-of-breed approach while continuing to develop and broaden the capabilities of their respective platforms.  SAP and Oracle, on the other hand, are laser focused on their installed base, leveraging their pedigree and vast resources to push their customer base to integrate their respective cloud solutions with existing on premise environments.

If currently performing due diligence on a cloud solution, we recommend you spend ample time conducting numerous reference calls while assessing the likely cost/benefit ratio of the solution against the more intangible agility and flexibility benefits. Be sure to balance reference calls coordinated by the vendors with those provided by more impartial sources (i.e. sourcing advisors, research firms, your peer network…etc.)  Once comfortable with the solution and model, we recommend you approach the negotiation with the same attention and rigor that you would apply to any other enterprise agreement.

The following list is a summary of three key items UpperEdge recommends be addressed to ensure you execute a best-in-class cloud agreement. For a more expansive list of items to address, be sure to check out our “SaaS Matters” blog series as well as our “Negotiating Cloud Agreements” webinar.

1. Ability to Scale

Many cloud agreements afford you the ability to purchase additional users or services as your need increases during the term of the agreement. However, it is also important to have a mechanism in place to adjust the economics should your actual demand (i.e. usage) decrease. Since most cloud agreements require upfront annual commitment levels (i.e. user count, defined scope of services/capacity), there is plenty of room for “shelfware” and/or “shelfservices”. Therefore, it is critical to ensure your vendor affords you the contractual right to reduce your commitment level and receive a corresponding reduction in the go-forward fees. If you agree to include an upfront payment schedule, require a refund and/or credit towards future use. Lastly, if your cloud agreement permits you to purchase additional users or services/capacity, ensure the prices and fees for such additional users and/or services are clearly stated in the contract. Without this certainty you may find yourself hit with numerous incremental and unbudgeted price/fee increases.

2.  Renewal Terms and Pricing

As mentioned above, the nature of certain cloud agreements fosters increased vendor dependency and heightened scenarios for vendor lock-in. In its simplest sense, cloud agreements are subscription arrangements which require renewal if your organization wishes to continue receiving the services and/or functionality delivered by your chosen provider. Once an organization and its user base are up and running (hopefully with increased agility and productivity), it is very difficult and often impossible to not renew. Doing so would require extensive upfront resources, time, transition planning, migration execution, and renewed change management. The cloud vendors know this which is exactly why they love selling cloud solutions. Given the risk of dependency and lock-in, it is important to negotiate the length of your renewal term(s) (i.e. terms/durations beyond the initial term) as well as the associated price/fee protections in advance of signing the initial deal.

Most cloud vendors want you to renew for multiple years. A multi-year renewal term means multiple years of renewal bookings which eventually convert to recognized revenue. We recommend companies negotiate the ability to renew in one (1) year increments as this ensures you have appropriate options and reinforces the mindset that your cloud provider must earn your business every year.

When it comes to the prices and fees associated with the renewal term, most cloud agreements will include a stated price increase after the initial term (i.e. on the renewal date).  This may come in the form of a stated cap (i.e. 2% or CPI) on the increase.  Not having a stated price increase and/or cap on the increase further enhances your exposure to price/fee increases as the lack of clarity could make you susceptible to mid-term as well as renewal date increases. The impact of these increases tends to be compounded as the magnitude of the increase is unknown and typically unplanned. UpperEdge recommends companies negotiate no price/fee increases until three years from the first renewal date.

By way of example, if the initial term of the contract is three years, then the price/fee afforded the organization over the initial term should be available and applied to the next three one-year renewal terms. Essentially, you are asking your cloud provider to invest in the relationship by providing you the same discount they used to win your business once they have secured your business. Subsequent to this price/fee flat-line period, we recommend all price/fee increases be contractually limited to CPI or another measure to which the parties agree. Incorporating a cap at this point limits your cloud provider from trying to make up for perceived lost revenue.

3.  Termination Rights and Obligations

Cloud agreement should provide your company with the ability to terminate for convenience with no associated penalty or “termination fee”. In addition, the ability to terminate for serious or continuous failure to meet committed service levels (i.e. uptime, response time, resolution, etc.) must be included within the agreement. Service level adherence is critical when dealing with a cloud based solution especially when the application and/or service is critical to the business. Having the ability to terminate should there be service level non-conformance is one way to ensure your vendor is standing behind their service levels rather than simply providing you with “objectives” and/or “targets.” A vendor’s reluctance to provide this trigger for termination should be a red flag. Ensure the vendor’s obligations upon termination are clearly stated. This includes the return (in both the vendor’s data format and a platform-agnostic format) and removal of data (i.e. certification that your data has been removed from the vendor’s servers) as well as an obligation to provide appropriate transition services.

Finally, do not permit your cloud provider to have the contractual right to terminate or suspend services other than for cause. If a business or enterprise critical application or service, you can’t afford to have the vendor choose when it wants to walk away from the relationship.

We welcome your feedback and the opportunity to discuss how best to approach your upcoming cloud negotiations. Please do not hesitate to contact me at amansfield@upperedge.com with any feedback or inquiries.

Before you seriously consider moving away from your SAP and/or Oracle support relationships, it is critical that you first carefully consider and address the following questions:

1.  Is your software application stable and established? If not or if you cannot say with a high degree of certainty that it is, your organization may be better off maintaining its relationship with its existing software vendor. When your software environment is immature and/or continually changing, it is important to stay with your primary software vendor to ensure your organization is able to increase functionality or add licenses when necessary.

2.  Does your organization need regular, cutting edge software updates? If yes, third party support may not be for you because your current support plans should include first-rate coverage for these regular upgrades. If, however, you have an established infrastructure that does not need regular updates to keep the business running smoothly, third party support could be a solid option because your organization will not be forced to prematurely and unnecessarily update.

3.  Are you invested in your software vendor’s next generation of software? Do you think your organization will use whatever the software vendor’s R&D comes up with in the upcoming months or even years? If yes, you may not want to move away to an alternative support option. Part of what support fees fund is R&D… so if you will benefit from this down the road, you may not want to ruin the symbiotic relationship you have with your software vendor. If, however, you do not believe you will stand to benefit from the results of your software vendor’s R&D/efforts, you have uncovered another reason to transition to a third party support provider.

4.  Are you or your legal department overly concerned with the ongoing legal battles Oracle has waged on the market? If yes, you may want to hold off on transitioning to a third party provider as many companies that provide this support are facing legal battles with Oracle. TomorrowNow, Rimini Street and CedarCrestone are three very public examples. TomorrowNow admitted to wrongdoing, but the potentially industry-changing Rimini Street and CedarCrestone lawsuits are still under way and both companies have not admitted to any misconduct. In fact, in a response filed last month, CedarCrestone has actually alleged Oracle has engaged in an “unlawful and systematic attack” against the third party support market and has unlawfully achieved an “overwhelming monoply share” in what would otherwise be a free market for tax and regulatory updates. Depending on the outcomes of these cases your decision to move your support to a third party may prove to be costly. If such support is ultimately deemed an illegal business practice, you and your organization will be faced with two less than favorable options. You can bring the support in house or you can attempt to go back to Oracle. Going back to Oracle for support will require you to pay Oracle back maintenance/support fees plus a significant reinstatement penalty unless you negotiatied the proper protections into your contracts (i.e. maintenance agreement/schedule).

There is no question that the third party support options offered by Rimini Street, Spinnaker Support, netCustomer and CedarCrestone deserve your attention given the high cost associated with your current maintenance/support contracts. They provide a low cost (half price in some instances), personalized and responsive alternative which, for many organizations, is more suitable and attractive than support provided by vendors like SAP and Oracle. For other organizations, however, third party support is simply not appropriate. It is important that you know which type of organization you are before you seriously consider transitioning.

If you determine that third party support is a viable option for your organization, we highly recommend you challenge the various providers to demonstrate how and why their support offering is the best fit for your organization.

January 2010 – Oracle files lawsuit against Rimini Street alleging massive theft of Oracle’s software and support materials, alleging co-founder Seth Ravin duplicated TomorrowNow‘s “corrupt business model” at Rimini Street.

February 2010 – Oracle subpoenas Rimini Street’s competitors: Spinnaker Support (at the time provided support for Oracle’s JD Edwards software), CedarCrestone (at the time provided support for Oracle’s PeopleSoft software), and netCustomer (at the time provided support services for Oracle’s PeopleSoft, JD Edwards and Siebel software).

March 2010 - Rimini Street countersues Oracle for anticompetitive practices – alleging that Oracle engaged in copyright misuse, defamation, disparagement, trade libel and unfair competition under the California Business and Professions Code. Co-founder Seth Ravin maintains that Rimini Street acts within its customers’ rights under their software licenses.

November 2011 - Oracle subpoenas 275 Rimini Street Customers, prompting increased claims that Oracle is employing scare tactics.

April 2012 - Rimini Street announced tripling in sales for Rimini Street Support of Oracle applications.

July 2012 - Rimini Street reports another quarter of record revenue, in spite of the litigation

September 2012 – Rimini Street is named winner of a bronze Stevie® Award in the customer service category of The 9^th Annual International Business Awards.

October 2012 - Rimini Street boasts 150% growth in bookings for Oracle support at Oracle OpenWorld and also announced plans to expand services to cover Oracle Hyperion products, including Planning, Essbase, Financial Management, Financial Close Management, Strategic Finance and Management Analytics.

December 2012 – Rimini Street’s Seth Ravin compares the Oracle lawsuit to music publishers fighting digital music downloads … “For them this is the last stand, they are not going without a fight. But you can’t stop change with litigation.”

January 2013 – Rimini Street reports largest sales quarter in company history and record 2012 results.

Now that you have a picture of developments to date in this Oracle v Rimini Street case, stay tuned for updated timelines and analyses. Also, feel free to check out our previous posts on Oracle’s moves against third party support:

• Timeline Series – Oracle v SAP/TomorrowNow 
• Third Party Support – Oracle’s Ongoing Attack
• Oracle – Protecting the Support Revenue Stream
• Oracle vs SAP & Oracle vs Rimini Street: What these Cases Mean to the Software Support Market

To quote the great Winston Churchill, “the farther back you can look, the farther forward you are likely to see.”

Taking this wisdom to heart, we have endeavored to look back at SAP, explore the actions of its main competitor Oracle, study the recent economic climate, and then look forward into the future. Here is what we’ve found.

1.  Just like Oracle, SAP feels entitled to charge 22% for maintenance.

We saw this back in 2008 when SAP sent out letters to its customer base that Standard Support (17%) would be replaced by Enterprise Support (22%) in 2009. While SAP professed various customer benefits and requests for this decision, everyone knew the real reason was Oracle had already been charging 22% for years. SAP wanted an equal revenue stream.

2. Customer rebellion to the Enterprise Support increase was partly driven by the severe economic downturn that took effect shortly after the announcement was made.

The timing of SAP’s announcement ran up against a perfect storm of the financial crisis, the housing crisis, the 2008 Presidential election, and the forthcoming economic disaster that would lead to substantial layoffs and organizational downsizing. Not exactly the best time to increase fees. But we had the advantage of seeing SAP gradually change its sales approach and positioning of support policies (remember Premium Support at 22%, the precursor to Enterprise Support?) for a couple of years prior to the announcement. So this support increase had been in the making and the timeline decided well before the announcement was made. What SAP could not predict was the perfect storm that began to take hold in September 2008.

3. SAP has since been mindful not to increase support fees while the economy is sluggish.

SAP learned its lesson well, do not raise fees while customers’ businesses are hurting or be prepared to face a tremendous amount of backlash. Essentially, do not do anything blatant enough to offend your customer base to the point that they stop investing in you. The market spoke and SAP listened, as demonstrated by the firing of Leo Apotheker and extended ramp period for Enterprise Support to reach 22% to 2016.

4. SAP has modified language in its support fee protection clauses to “aggregated” or “cumulative” CPI.

SAP’s prior language effectively provided that annual support increases would be tied to the prior year’s increase in CPI, if SAP chose to increase support fees on its customer base. Now the aggregated language effectively provides that SAP may increase support fees based on cumulative annual CPI changes going back to the date of the last support fee increase or the execution of the specific license purchase, whichever is later. In effect, this means that if SAP does not raise support fees for 5 years, and assuming CPI increases 3% each year, SAP can raise support in year 6 by approximately 15.9% (3% compounded annually). SAP has explained to customers that this provision allows them to proactively budget for these downstream increases. This is like having an adjustable rate mortgage that will reset in 5 years – you know an increase is coming but you do not know how much or how you’re going to pay for it.

5. The Enterprise Support ramp period reaches 22% in 2016.

By 2016, a full 8 years after the economic crisis took hold and the Enterprise Support increase was announced, SAP is betting that economic conditions will be stable and customers will be accustomed to annual support increases from the 8 year ramp period.

6. SAP’s spin on the substantial support fee hikes will be about the sacrifices they have made out of respect for their customers.

SAP will claim that, just like any other business, annual increases are customary and necessary to keep up with inflation. But SAP was empathetic to the plight of its customers during the economic downturn by not charging annual increases for all these years, and thereby absorbing this cost until economic conditions improved. Therefore, if increases occurred annually as was originally planned, customers would be paying this amount in 2017. If anything they should be thankful they were able to “save” the customary annual increases during the economic downturn.

7. SAP can hedge against the outcome of Oracle’s lawsuit against Rimini Street.

Oracle is suing Rimini Street who is a provider of third party support for Oracle and SAP applications. Oracle is threatened by the potential loss of its monopoly for support of its software and is claiming Rimini Street has an illegal business model for a variety of reasons. SAP certainly has a vested interest in the ruling on this case. SAP is also probably loathe to bring its own lawsuit against Rimini Street considering Oracle was successful in suing SAP’s prior subsidiary company TomorrowNow, which was founded by Seth Ravin who is coincidentally the founder of Rimini Street. By 2016 the Oracle lawsuit against Rimini Street should be decided as well as any appeals that are sure to follow. SAP will have the benefit of knowing the ruling and seeing its market impact before it decides to raise support fees. Further, based on the decision, SAP can decide how aggressively they want to increase support fees and do a better job at more accurately reading what percentage increase will receive a grumbling acceptance versus an enraged customer base as was the case in 2008.

So while the dates and percentages may differ, looking into our crystal ball one thing is abundantly clear – SAP will increase support on an annual basis, it’s just a question of when and how much. Prudent customers should leverage future license opportunities to mitigate these support fee increases.

• Waste Management sues SAP for $100M
• Overstock.com Restates Earnings Due to ERP Implementation
• Levi Strauss Earnings Drop 98% with ERP Implementation
• Marion County California Starts Over and Sues Deloitte Consulting for $30M
• Avantor Sues IBM for Implementation Disaster
• US Air Force Scraps ERP Implementation After $1,000,000,000 in Spending

What do these examples of recent ERP horror stories teach us? ERP implementation disasters come in every shape and every size. They are not specific to a software package, system integrator, industry, geography, or company size. Each failure has its own story and its own pedigree.

Hundreds of independent studies both privately and publically funded have been conducted to identify the critical success/failure factors associated with ERP implementations. The standard list of failure factors should hold no surprises:

• Executive Engagement
• Solid Business Case
• Correct Software Package Selection
• Rigorous Project Management – Give Your ERP Program a Tune-Up
• End User Participation
• Business Re-engineering… and many more

There is a broad understanding of the factors which bring about project success or failure, so why are there still so many ERP disasters? Why don’t the methodologies and project management techniques that have been honed and exhaustively written about over the last 20 years always work?

I believe that the answer to this question can be traced back to the failure in one sliver of the ERP implementation process – Risk Management. ERP implementation risk management processes are specifically designed to identify potential risks to a program, assess the magnitude of the risk, and prescribe treatment that is appropriate to the specific risk level. If executed appropriately, these processes should theoretically incorporate the success and failure factors that have been identified. This leads to the more interesting question… if the ERP implementation risks are already known and there are well established processes to manage risk, then why do the risk management processes fail?

Risk by definition, is not a problem. Risk is the anticipation of a future problem. Risk leads an insidious and elusive existence. It is present and absent, hard to pinpoint but very important. If everything goes according to plan, nothing bad happens. But as the saying goes, without risk there is no reward. The only way to eliminate risk entirely is to do nothing at all, which by the way brings its own risks to the business.

I have spent the last year reading all the research papers I could get my hands on, studying the press as it relates to ERP implementation disasters, and going through all of the ERP implementations I have been involved with to identify what goes wrong with the risk management process. From this research I have concluded that there are five things that repeatedly derail ERP implementation risk management.

1.  Failure to establish the proper context. Risk management processes are often designed around the risks associated with a single domain of risk effects – delivering the project on-time and on-budget. These risk management processes are designed to ignore the four other domains of risk effects and hence fail to identify and mitigate risks that can later take a project down.

2.  Flawed executive engagement model. If executives are not actively engaged in the risk identification process an opportunity is lost to develop a common view of success and to synchronize perceptions of risk. Engaging executives early also enables the project team to develop a more balanced view and take ownership of risk.

3.  Not recognizing and addressing biases in the identification and assessment process. Even in ERP implementations, all of us make decisions that are based upon cognitive biases. Whether cultural, organizationally driven or experiential, we all have them. Failure to recognize these biases can lead to an inappropriate assessment regarding the probability of a particular risk event occurring or the potential magnitude of its impact.

4.  Failure to account for risk interrelationships. In an analysis of ERP risks it is not always obvious how risks interrelate. Understanding how the realization of one risk might increase the probability of another risk is important in assessing the overall impact of a potential risk.

5.  Lack of rigor. Executed properly, risk management practices are embedded into the core decision making, ERP status reporting and deliverable tracking of a program. Failure to scrupulously incorporate the practice of risk management can lead to risk management simply becoming a program cost overhead.

In future blog posts we will examine each one of these 5 above mentioned failure points individually and identify what you can do to improve your ERP implementation risk management process.

For more ERP project management advice from ERP Lead, visit ERP Lead.