News Article 10/09/2008

Buying the right software (Digital Ship, September 2008, p.28)

Purchasing a software system for any company can be an expensive business, and has potentially disastrous consequences if a poor choice is made. Having a well thought-out procedure is the first step in conquering the Everest of IT selection, writes Martin Nygate, Ulysses Systems

Since the introduction of packaged business software to the market in the early 1980s, companies and individuals have been struggling with the challenges posed by these innovative new products.

These struggles focus not only on the definition of requirements but also the methods used to identify, evaluate and select the most suitable product that meets the need of the company.

The results have been varied, from global success and market leadership on one hand, to crippling defeat – sometimes even insolvency, on the other hand.

The productivity gains and efficiencies promised by software vendors have materialized for some companies, but this is offset by the seemingly bottomless pit of investment that has been the experience of less fortunate companies.

Why is this? Why is it that some companies have benefited from the IT revolution, yet others have not? And, what can you do to make sure that both you and your company do not fall into the same bottomless pit that too many others have tumbled into?

Purchasing methods
Purchasing products is a well researched and documented area. Depending on the company's policies and procedures, purchases of low value items often required only superficial purchasing procedures, but more valuable capital investments required much greater scrutiny and involvement from different levels of management.
The dilemma facing companies intending to invest in high value and often mission critical goods and services has been the focus of sophisticated purchasing procedures.

Request for Information (RFI), Requests for Proposal (RFP) and Request for Quotation (RFQ), have all been used extensively to identify the item that meets a company's requirements in the most cost effective fashion.

However, the paradigm has shifted. Purchasing business software is as remote from buying conventional goods as selecting a business consultant - so why are we often using the same methods to select software as our ancestors used in buying machinery?

Buying products traditionally relies on identifying a list of quantifiable features such as speed, weight, height, output, and so on, to provide a matrix of comparison that, when combined with cost, can deliver an indication of the choice product.

However, software inherently has very few similar quantifiable metrics. Software by its nature is an intangible. At its most basic level, software is a list of instructions embedded into a CD that costs less that $1 to produce.

In many cases, the CD is not enough to ensure that the desired outcome is achieved. We need help - services, in the form of consultancy to configure the software to our own unique requirements.

With no tangible quantifiable metrics to compare one software solution to another so that we can compile the magical comparison matrix, how can we be sure that we are purchasing the right software for our company - an often mission critical application?

First, we need to stop trying to adapt antiquated and non relevant conventional purchasing practices to a category of investment that has no precedent in commercial life.

We have to rethink the conventional process of selection through personal preference and persuasion by flashy demonstrations and sharp salesmanship, and instead focus on a sound strategy.

Why do we need software?
This question is asked time and again, often by board members who are not yet comfortable with the concept of software.

Many senior board members started their professional career without the use of software and the natural reluctance to change means that they are inherently suspicious of any revolutionary business tools.

All too often critical software investment decisions are held up in the boardroom because of the inabilities of the internal sponsor to clearly articulate why the company needs software, and the financial and operational benefits this investment will deliver to the company.

Software investment is driven by various factors, internal and external, such as regulatory pressures, transparency, access to strategic information and even the simple desire to align your company with the rest of the industry.

So how do I make sure that I buy the right software for my company? Here I will suggest a four step approach.

1 - Scoping Document
A scoping document needs to be drawn as the first and most important element in the selection process. This document is at the heart of any requirements identified. It is, in comparison to conventional purchasing process, the 'technical specifications' of the requirements.

However, it is much more than that. The scoping document is formulated as the foundation on which the whole decision to purchase software is built, and as such it needs to well designed, solid, yet sufficiently flexible to evolve with the process.
This document identifies the challenges facing the company at the root cause level and not at the superficial level. These challenges need to be quantified in tangible (financial) and intangible (operational) terms so that, whatever the decision may be, at the post implementation stage you can obtain clear and definitive indications on a financial and operational return on your investment.

For example, is meeting regulatory requirements or increasing efficiency NOT a root cause challenge? Reducing wastage by X per cent, or increasing the ratio between managers and their subordinates from 1:10 to 1:15 - this is a quantifiable challenge.

This document will have the added advantage of quantifying, in financial terms, the tangible benefits of any software solution, so that you will have a clear indication of the value, and therefore the cost, that you are willing to invest in any software purchase.

No doubt that the creation of such a crucial document is difficult, it requires careful consideration and situation analysis, as well as the ability to identify current challenges and future goals.

In the absence of this document, it makes no difference what software you ultimately decide to purchase since you will never have the information you need to quantify a success or failure of the software purchase at the post implementation stage.

2 - Vendor Selection
The most common and established method of reviewing any potential software vendor that could meet the challenges set down in the scoping document, is to search the internet.

No doubt that this is the most cost effective and simplest method, and in the majority
of cases, this is the correct way to proceed.

Combined with internal market experience and perhaps attendance at industry specific exhibitions, companies should have few problems drawing up a short list of companies that promote targeted software solutions to industry verticals.

Before drawing up this list, companies often focus on the option of developing software internally or via outsourced software development companies.

This is most often the focus of companies that have strong internal IT departments with internal competence for software development. However, the buy vs. build deliberation is to a large extent no longer relevant.

During the 1980s and 1990s, software development was often hard coded, with little ability to adapt. Hence, companies investing in software solutions were required to change their internal, well structured and time tested business processes to meet with the prescribed processes of the software developers.

With the rapid sophistication of design and development in software, second generation software was designed and built that takes into account the requirement for flexibility.

Second generation software focused on the ability to configure companies' unique business processes to the operations of the software - simply put, the software adapted itself to the companies' business needs.

The culmination of these developments established a new breed of vertically targeted, industry specific, packaged software platforms that offered an alternative to the build vs. buy deliberations.

The contemporary approach is Buy AND Build - Buy the appropriate software platform and Build your business processes with the in-built tools provided by the software vendor.

Using the selection criteria set down in the scoping document, this will allow you to configure the software to face the challenges identified.

3 - Vendor Evaluation
Having identified the leading vendors in your vertical market, offering a platform that has been uniquely designed for your industry, the next step is to invite these vendors to demonstrate their products in front of the user community.

At this stage, the focus should be on the ergonomics and usability of the software application, and the alignment to the level of technical and IT competence of the user group. The interface is of paramount importance to ensure that the users are capable and willing to use the software.

Any successful software implementation is dependent on the active and enthusiastic participation of the user group.

Ultimately it does not matter what software platform you purchase and at what price, if the users find the software too difficult to use, or too inconvenient, or requiring too much expensive and time consuming training - the software deployment will not be a success.

The evaluation of software usability is a subjective matter by nature. It is about the look and feel of the software, combined with the similarities between a user's current business behavioural pattern and the design of the interface.

Experts in cognitive intelligence and human behaviour have identified that software focused on an individual's unique role in the organisation, combined with the tasks that the user performs, have a significantly higher adoption rate due to the inherent ease in which the user can identify with the operations of the software.

4 - Challenges vs. performance

With the shortlist of companies who have demonstrated to the satisfaction of the user community that the software is regarded as adaptive to the usage pattern, the final step in the evolution process should focus on benchmarking the shortlisted platforms.

A proven method for benchmarking is to identify a number of critical challenges highlighted in the scoping document, and to request from the software vendor to demonstrate how they would resolve this challenge in their software.
This would require the software vendor to configure their platform to meet this business requirement.

However, we need to be aware that many software vendors have the capabilities of creating a simple change in the embedded workflow that seemingly meets the configuration changes requested by the customer, yet, upon deployment, these configurations prove to be un-scalable or unsustainable.

The demonstration of these configuration changes may seem workable, but in reality they may be no more than linked screen shots.

Hence, it is also advisable to evaluate the flexibility and adaptability of the software in a real time scenario.

It is recommended that the shortlisted vendors be prepared that during the customer presentation they will be asked to demonstrate, on the spot, a number of critical configuration issues that will not be provided to them in advance of the presentation.

This will ensure that that the vendor will be forced to clearly demonstrate the flexibility and adaptability of the selected software platform.

To ensure fairness and ease of comparison, all vendors need to be tested simultaneously with identical challenges, hence these spot challenges for configuration need to be very focused and specific, to avoid the need for extensive and time consuming configuration.

For example, a spot challenge such as integration with another software package could not be demonstrated in-situ without prior investigation, but a challenge such as a change to the workflow, the inclusion of a company specific document, or the addition of a new user, could.

In conclusion, the successful selection process of software is as remote from the established and conventional process of purchasing of goods as to demand new and different ways of thinking.

With a sensible and relevant procedure in place, we can avoid the pitfalls experienced by many companies and have confidence in buying the right software for your company - and yourself.