Avoid Enterprise Software Project Failure: 7 Expert Tips

No matter how you look at them, ERP and most other big application deployments are risky, difficult, and expensive. But much of the analysis on why these projects go awry misses the point. These are not technology projects; they're business transformation projects. And unless the people charged with procuring the software and service understand that fact, they're exposing their companies to unnecessary risk.

Anyone who has been through a failed ERP project knows that the software is rarely the cause. The culprit is much more likely to be a failed organizational change management program or poor team (customer, vendor, or both). In other words, you can focus on the contract and the software as much as you like, but in the end it will be the systems integrator that will make or break your project. So you had better get that part of the deal right.

For 20 years, my practice has been devoted to representing customers in technology-driven business transformation projects, and it's clear to me that the process used to buy services in this area is broken and getting worse. These are not commodity deals, and unless their complexity is taken into account, they will fail. Here are seven tips that may help you in your next project:

1. Establish a relationship and then contract to the relationship. Most people do the exact opposite. For example, most of your contracting time should be spent on the schedules and not on the main agreement. The schedules are where the action is, particularly the fee and governance schedules.

2. Negotiate within the RFP process for as long as you can. A good vendor sales team is worth a lot of money in consulting dollars. Use it. This is a complex sale, and vendors like the opportunity to actually get in there and sell. This is where you learn about "solutioning" capability and where you can truly mitigate risk. Remember that problem-solvers solve problems and are likely to be on your side. It makes no sense to (a) try to mitigate risk before there's a deal; or (b) try to solve your problems with the risk mitigators.

3. It's very unusual to truly understand your requirements to the point where you can put them in a contract. Use a process that lets you refine your requirements as your RFP process progresses, so that you can retain credibility as you learn more. I've found that basing elimination (down-selection) of vendors on conditions (which can't be overcome) rather than objections (which can be overcome) really helps in this area. It's by overcoming objections that a good, experienced vendor team will help you refine your requirements.

4. The contract is important, but it's the fee and governance schedules that will get you a successful implementation. Good contract terms that are too expensive to enforce are of little value when you have a failed implementation.

5. Think of governance less as a vehicle to enforce your contractual rights and more as a way to incubate ideas and encourage innovative thinking. These deals typically require significant business process redesign, and good governance will encourage thinking out of the box. Change control should be part of governance.

Global CIOs: A Site Just For You Visit InformationWeek's Global CIO -- our online community and information resource for CIOs operating in the global economy.

6. Remember that you're selling as much as you're buying. In order to ensure that your relationship with your systems integrator reflects both of your expectations without adding to the perception of increasing risk, you have to be a high-performing team even before you engage with the vendor/provider for the first time. The RFP drafting process can help you form this kind of technology buy-side team.

7. Later, when you get to contract talks, rather than thinking of that process as positional negotiations, think of it as an opportunity to reconstitute your high-performing team to include the right SI personnel. The goal should be to emerge from the negotiations with a customer-supplier team ready to tackle operational issues because it practiced doing that during the RFP and contracting processes.

I would never argue against having a good contract. I would, however, argue that such a contract is the byproduct of a well executed sourcing process. Unfortunately, to too many buyers, this means driving hard on cost and contract terms and missing the real benefits that a good process will yield.

These kinds of projects will always be expensive and risky. But those negatives can be mitigated by ensuring that the underlying economics of the deal work for both parties; that there are controlled mechanisms for change; and most important, that at the end of the process there's a strong working relationship between the customer and the SI. Even with the strongest contract, when the going gets tough, the quality of your relationship is the best predictor of your ability to succeed.

Ed Hansen, a partner in the New York office of Baker & McKenzie LLP, has nearly two decades of experience representing clients in complex technology-enabled transformation projects.

The Optimized Enterprise, a unique virtual event, will feature presentations and discussions on the key topics related to creating a more competitive and efficient financial services organization. It happens June 23. Register now.