Update Jul 2008

How to Buy The Right Software for My Company - and Myself! PART 2

The right way to select software - a four step approach
In last month''s article, we described some of the difficulties related to buying software together with a review of some of the current existing methods employed to differentiate between product selection and purchases.

This month we will document an easy, four step approach to software selection that will serve to ensure a greater predictability for the eventual outcome of the investment. This defined process will also enable senior management and decision makers to be confident that appropriate due diligence has been undertaken and a rational common sense approach has been adopted to ensure budgetary approval.


Step 1: The 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 the 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 be 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 of the financial and operational returns on your investment.

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

This document will have the added advantage of quantifying the tangible benefits of any software solution in financial terms 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.

There is no doubt that the creation of such a crucial document is difficult. It requires careful consideration, situational 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.

Step 2: Selecting the right vendor and the buy vs. build deliberation
The most common and established method of reviewing any potential software vendor that could meet the challenges set forth in the scoping document is searching the internet.

There is no doubt that this is the most cost-effective and simple method, and in the majority of cases, that 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 1980's and 1990's 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 internal business processes to meet with the prescribed processes of the software developers.

With rapidly increasing levels of sophistication for the design and development of software, second generation software was designed and built taking into account flexibility requirement. 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 deliberation. 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.

Step 3: Evaluating the vendors
Having identified the leading vendors in your vertical market who are 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 with 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 if it requires 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 behavioral pattern and the design of the interface.

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

Step 4: Comparing the identified challenges to the software performance
With the short list of companies who have demonstrated to the satisfaction of the user community that their software is adaptive to the usage pattern, the final step in the evolution process is focusing on benchmarking the short listed platforms.

The proven method for benchmarking is to identify a number of critical challenges highlighted in the scoping document and to request that the software vendor demonstrate how it would resolve this challenge with its software.

This would require the software vendor to configure its platform to meet this business requirement.

However, we need to be aware that many software vendors have the ability to create a simple change in the imbedded workflow that seemingly meets the configuration changes requested by the customer. However, upon deployment, these configurations prove to be un-scaleable 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 short listed vendors be prepared to demonstrate how their software deals with on-the-spot critical configuration issues that they will not provided with in advance of the presentation. This will ensure 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.

Conclusion
The successful selection process of software is as different from the established and conventional process of purchasing goods as to merit 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.