Managing the expectation gap

How to introduce Business Enterprise Software without making enemies

Introduction

The decision whether a particular product meets the needs of the business should be made by those responsible for the business. This is as true for software purchases as any other significant expense. It is just as true that an informed decision should take into account all the relevant factors, not just the sexy list of features demonstrated or promised by the vendor.

This is obvious stuff. So why, when Enterprise Software is involved, are there so many pitfalls?

A typical problem

Consider the following scenario: An important department in a large firm has identified a need for a new system which will allow them to manage large volumes of information more effectively. They discuss the requirement with their dedicated IT department, which quickly establishes that this is not something they should be building from scratch as a dedicated system, but one where a third-party product should be used as the basis, with extensive customisation to meet the precise needs of the business.

A small team of business and IT folk is put together to identify the most suitable product, and some vendor demonstrations are arranged. In accordance with firm policy and good practice, the team includes representatives of the firm-wide architecture and engineering functions who point out that there is already a recommended standard product in this space, complete with a managed service team who can offer an off-the shelf solution.

Meanwhile, one of the vendor demonstrations has enthused the business team, who feel that it can do everything they need 'out of the box', and that the next version, due out in a few months, has some particularly attractive features.

The enterprise engineering team's view of the product is very different. They are worried that it has been implemented in a way which will not easily scale to the large, multi-site environment required, and although the user interface and built-in features are attractive, the underlying engine is clearly inferior to what is already available in the managed service.

Much discussion ensures, but at the end of the day, none of the choices available is particularly attractive. Does the team:

• Adopt the existing enterprise product, with an uphill struggle to sell it to the business, and probable long-term dissatisfaction
• Introduce the business preferred product, and risk it running out of steam as it rolls out into production

A common result is significant delay while political in-fighting takes place, and the eventual introduction of yet another product into the firm.

When the dust settles, the business gets the product it wanted, but is unhappy with its performance, horrified with the costs of running it, and bitterly disappointed that when the exciting new features arrive in the next version, it is over two years before they are able to see them in productive use.

Analysis

The existence of problems like the one above is not news to most organisations. Indeed, many of them have entire layers of middle management devoted to handling these situations. Despite the intellectual energy and (usually) good intentions of all involved, the end result is usually to avoid disaster, but not poor outcomes, such as an unnecessarily high cost base, hard to tackle complexity, and unacceptable timescales for innovation.

The particular aspects of the above scenario and other like it which are specific to the use of third-party products are as follows:

• The basic capabilities of the product are determined by a separate organisation, with its own agenda. You may have some influence, but it is likely to be indirect. So you need to be really comfortable that the product is a good fit for your requirements not just in the short-term but over an extended timescale
• You need to remember you are in a customer/supplier relationship at all times, even when there are detailed technical discussion of the sort which usually take place amongst technologists who tend to ignore or downplay the commercial aspects to focus on the intellectual problems. Successful software vendors are as adept at selling to techies as they are to end-users. They just use different tactics.
• Once you've introduced an enterprise solution, it can be extraordinarily difficult to get rid of it. If in five years time there's something much better from someone else, you'll probably need to adopt that as your new strategic solution. However, you could still find pockets of the original product in use many years after that. (See my other article Old software never dies...).
• It's very easy for IT management to have a policy which says that there should only be a single strategic enterprise product in any particular application niche. In reality, the capabilities of different products overlap in complex ways, and it may simply not be possible to avoid having several products in play each of which can do some of the same things well.
• Many products are themselves built on top of other enabling products from major industry players. The two most common examples are databases and web applications servers, which are often a vital requirement of third-party software. While all the enterprise players will pay lip service to supporting vendor-neutral standards in these areas, it is a fact of life that each of them will have certain preferred products ( sometimes right down to individual version numbers and operating system variants ), and it can be time-consuming and difficult to optain support for issues which arise on different infrastructures.But are you really prepared to ban the product which best meets the business needs simply because they like Oracle and you like SQL Server ( or the other way round ).
• Some enterprise software is available as open source, which has its own complex set of advantages and disadvantages. See Open Source benefits and pitfalls.
• There's no generally accepted meaning to 'enterprise software'. Firms can brand their products as such without any meaningful committment to meeting even the minimum characteristics which a large enterprise would wish to see. The good firms will work hard to do well in these areas, but even they can be seduced by the need to get product to market and to focus on the sexy new features which will capture new customers, at the expense of the aspirations of those already tied into mult-year maintenance deals. Have a look at A manifesto for purchasers of Enterprise Software for some ideas of what's missing.

Approaching some answers

Fully addressing all of the above requires a mult-pronged approach.

All large organisations and many smaller ones will have a sourcing function whose job it is to negotiate significant contracts with vendors. They will usually have a well-defined relationship with the legal department, but the way in which the IT function is involved is often surprisingly ad-hoc, consisting of little more than picking names out of a hat of senior IT managers and making them responsible for vendor relationships. If you want to be good at this, you need something more.

• Yes, you need people in IT who manage the overall relationship with the vendor, at a senior level, whose job it is to know how to work with the vendor, how to leverage complex relationships involving multiple offerings, and how to work effectively with other departments. For large companies working with large companies this can become close to a full-time job.
• But you also need people in IT to manage individual decisions about the use of these products and the selection of new products or alternatives. These folk need to have a different mindset - focused on the firm-wide value proposition, taking into account all the existing commercials across multiple offerings, and not becoming an inadvertent advocate for a particular solution, a.k.a. an unpaid salesperson.
• Your cost-benefit analysis for introduction of a brand-new technology needs to think about the long-term lifecycle, and that means you need a credible methodology for putting numbers to the costs and benefits, rather than being swayed purely by the 'coolness factor' or a simplistic comparison with the alternatives, including entrenched ones.
• And, most importantly of all, your entire decision making process needs to be informed by your corporate strategy and policy in these areas, which means that you need to have such a thing, and it needs to be comprehensible and usable.

Introducing all of the above may seem daunting, and, to be honest, even with help from external experts like us, it can take time to have an effect. But all is not lost. There is one particular step you can take almost immediately, and which is relatively simple.

Prepare your own corporate checklist of non-functional requirements for any enterprise software you buy, and insist that these requirements are incorporated with a suitably high weighting into any RFP you issue. If your selection procedure doesn't involve an RFP, then you can still insist that the vendor provide full answers to your questions before you purchase, and where those answers are unsatisfactory ( as some undoubtedly will be ) make sure that you think through the consequences and translate that into business language and get business sign-off before you sign on the dotted line.

So what sort of requirements are we thinking of. Here's a taster:

• Does your product require the use of a separate database product. If so, which ones, and which versions is the current version of your product certified to work with? What long-term assurances can you offer regarding the stability of these choices as your product changes. How soon after new versions of the database vendor's product become available do you certify them against your products.
• Does your product contain embedded within it any significant components, such as web application servers, which require administration and deployment of those components, and where the use of an existing corporate infrastructure is not a viable alternative? If so, please provide details.

Conclusion

The most useful lessons to be learned depend on your role in the organisation. If you're the CIO, you should be honing a coherent strategy around the use of third-party enterprise software, which recognises the complexities above and you should be implementing the kinds of structure and roles to which we've alluded.

If you're on the business side, you need to understand , or at least accept, the reasons why making enterprise software work well in the large is difficult and what some of the consequences of a free-for-all are.

And if you're an enterprise architect or engineer, and have to live with the rules and corporate culture you have, you don't have to learn all the tricks the hard way - there are others who've trodden a similar path and whose experience you can leverage.