In the days of monolithic application systems, software evaluation and selection used to be much simpler than in today's increasingly integrated environment.

Today, businesses are moving away from building or acquiring large, monolithic application systems. Using a service-oriented application design, application software is broken down into its constituent parts, that is into smaller, more modular application components or services. These application services make use of infrastructure software that has also been decomposed into discrete system services. All of these discrete services can be deployed across any number of physical machines that are connected to the Internet. This modular service approach provides great flexibility in terms of system design.

Infrastructure requires integration

Clearly, the transition to SOA comes at a cost in that software system complexity increases. At the same time, infrastructure plays an ever bigger role. For example, workflows and business rules are part of almost every software package, be it Business Process Management (BPM), Customer Relationship Management (CRM), Enterprise Content Management (ECM), Business Intelligence (BI), or Enterprise Resource Planning (ERP). Thus, workflows and business rules assume characteristics of shared services. Integration becomes key!

Talking about the same thing

Leaving the subject of increased complexity aside for a moment, there is another aspect to consider. While certain acronyms are frequently used, IT experts are far from sharing the same definition of common terms. For example, the BPTrends report "The State of Business Process Management: 2008" rightfully states that "Business Process Management, or BPM, means different things to different people".

Planning to acquire a COTS product - implementing a custom solution

Chances are that the software mix in your organization and the technical infrastructure are unique. As a consequence, your organization has unique requirements when it comes to the evaluation and selection of new software.

Initially, the expectation often is that a COTS (Commercial Off-the-Shelf Software) product is to be acquired. However, in the end, it is all about a custom solution that meets the specific requirements of your organization.

What does all this mean for software evaluation?

The acquisition of a custom solution requires a custom RFP. You can basically approach software evaluation and selection from either one of two ends.

The top-down approach

You can start out with an evaluation of existing products in the particular domain. You would define criteria that guide you in the evaluation process. However, there is a danger that you overlook things. It is just like overlooking something in the fine print of a contract. Sometimes, overlooking something important in a contract has a devastating effect.

In addition, you expose a bias towards features. Potential issues related to infrastructure may not be detected until later in the evaluation process. When infrastructure-related issues eventually surface, a lot of money and time may already have been lost.

The bottom-up approach

Alternatively, you can start with an evaluation specification which contains all the relevant requirements that the software package is expected to meet or exceed.

However, given that your requirements profile is unique, how would you go ahead? There are two basic options.

Option 1

You create a requirements profile from scratch, including explanatory statements that help potential vendors understand the context. Depending on the total number of requirements, it would normally take you 10 to 20 person days to complete an Evaluation Specification. An Evaluation Specification is understood to mean a requirements profile augmented with explanatory statements that helps vendor representatives better understand the context. For example, explanatory statements would clarify certain terms.

Option 2

You start out with a pre-built Evaluation Specification. However, a pre-built Evaluation Specification is generic and thus cannot be tailored to meet your specific needs. Even if it comprised all requirements ever imaginable, it would not be adequate. On the contrary, you would need to weed through a large number of requirements and delete superfluous ones. The more requirements a pre-built Evaluation Specification contains, the more extra work is entailed.

The bottom line is that a pre-built Evaluation Specification provides you with a starting point. You need to add additional requirements and remove those requirements that are not needed, no matter how comprehensive an Evaluation Specification is.

Of course, it would come quite handy to have a source from which additional requirements as well as explanatory statements could be imported. This would save you from the effort of having to define requirements yourself.

How the EAS helps you create a RFP in record time

The Evaluator's Application Suite (EAS) provides for a very flexible solution. You can start out with a pre-built Evaluation Specification and import additional requirements from the repository. The repository structure represents a hierarchical tree, which is composed of branch nodes (requirement categories) and leaf nodes (requirements).

A requirement category is the subject matter of all requirements assigned to it. It contains a description of the category that you can import into your Evaluation Specification via cut & paste. Thus, you can make sure that you and vendor representatives have a mutual understanding of the subject matter.

Requirement categories are hierarchically organized. For example, there is a category named "Interface", which is subdivided into categories "Application Programming Interface" and "User Interface". There can be multiple hierarchy levels.

As already mentioned, requirements form the lowest level in the tree hierarchy. You can import requirements via drag & drop.

Currently, the repository contains more than 700 requirement categories and more than 1,100 functional requirements. Repository contents are continuously updated in order to cope with technological progress.

Of course, you can also import non-functional requirements (a.k.a. non-behavioral requirements) from the repository.

When you are done with your Evaluation Specification, you generate a Request For Proposal (RFP), which is a matter of minutes.

The benefits are obvious: You can create a high-quality RFP in a matter of a few days, which results in a tremendous productivity boost. 

How to create an RFP from scratch

How to create an RFP from a pre-built Evaluation Specification