Download White Paper on this topic

DEFINITION of ‘Unconfirmed Detailed Software Functionality Data’:  Any representations about the functional capabilities of software solutions that are not emphatically known to be accurate. Further the data are typically too detailed to be even partially confirmed by a selection team seeking this type of information.

SoftSelect’s Long Listing Process:  It may be counter-intuitive, but the high-level indicators of suitability reliably tell more about a software package's general functionality than a matrix of one thousand points of functional data. If a particular software product has a market leading penetration into a specific company type, then it stands to reason that they have matured the type of functionality that is necessary. On the other hand, there are compounding problems with depending on unconfirmed functional data.  After 1800 business software projects, we have conclusively proven this at SoftSelect since we changed to the high-level indicators of suitability listing method in 2002.

Companies Screening a Long List:  Whether you receive unconfirmed detailed functional data from an entity that monitors software vendors or receive a software vendor’s reply to a list of functional questions specific for your firm, this data is simply counterproductive to your team’s efficient and accurate decision making. The reasons are: 

• Compounding inaccuracies:  Unconfirmed detailed functional data is subject to the following multiple levels of compounding inaccuracy by the time it is used by a company seeking business software.

• Constant change in how a specific vendor can achieve specific functions (new releases, increasingly legitimate collaboration with other solution providers, etc.)

• Ambiguous statement of functionality; therefore specific vendor’s represented capabilities may not actually be sufficient for a particular company’s needs

• Errors in how a company searching for software interprets a functionality statement from some entity providing software functional data

• Functional data answer codes that do not sufficiently model all legitimate answer options (there are more options than ‘yes’ or ‘no’)

• Blatant misrepresentation in a software vendor’s answers to functionality questions—this is not all the fault of software vendors as there is pressure to over represent their offerings as it is assumed the competition will do the same

• Functional match statistics:  Functional data from a specific research source only partially correlate to what is important to a specific company. All vendors compared with these statistics will have hidden strengths and weaknesses based on their ability to meet the other important requirements not included. Therefore, functional statistics comparing different packages can never be assumed to be fully accurate for a specific company seeking software—even if the underlying functionality data was deemed to be perfect.

• Functionality parity: Typical functionality offered by viable software vendors, in a particular software product category (e.g. ERP or PLM), has significantly reached parity. There are fewer functional differences, which become major influencers, if the selection team reviews candidate solutions properly. Contributing to functional parity for viable solutions are:

• Reasonably integrated point solutions meeting specific functions not directly met

• Aggressive challenge to a company’s ‘unusual’ workflow (that is not support by most or all candidate solutions) to see if it can be changed or eliminated

• Having deliberate flexibility in adapting to the workflow of a new system during implementation planning

• Functionality wrinkles: For functionally broad systems like ERP, each generally viable solution will have hundreds of wrinkles (‘work-arounds’ or ‘less-than-optimal’ methods) in how it meets workflow objectives for a specific company. Depending on characteristics of the selecting company these wrinkles will be different with specific solutions, but at about the same level for all viable solutions. Therefore, these low-level wrinkles should not compete with top-level functionality selection criteria. Functionality data is often used to make low-level wrinkles influential.

• Non-functional factors:  These factors, such as total cost of ownership (including upfront cash requirements), implementation processes, vendor viability, to mention a few, should be very influential and are not reflected in functional data.

• Encourages shortcuts: Selection teams accessing unconfirmed detailed functional data have a tendency to depend on it, largely based on 1) typical pressure to finish the selection event and move on with solving the problems that originated the selection project, and 2) no other structured method is readily available to measure candidate solutions.

• BPM engines: In the foreseeable future Business Process Management (BPM) engines (containing standardized process libraries) will be increasingly used to piece together company-wide business systems. The resultant business systems will significantly contribute to a specific business more easily participating in modern collaboration with suppliers, customers and other business partners. By virtue of the BPM engine approach, functionality data on early BMP offerings would be largely irrelevant and eventually completely irrelevant.

Important note: These comments on the limited or even counterproductive nature of unconfirmed detailed functionality data do not mean the business process requirements plan is not valuable and necessary. It is very important to note that detailed requirement/issues development is critically important for:

• Helping identify and define functional priorities and unusual work flow objectives that should be directly tested with candidate solutions

• Facilitating pre-implementation planning/readiness improvements and optimizing the new business software after the initial implementation work

This is why SoftSelect includes procedures early in selection process to build the requirements and issues plan even though very little of the detailed plan is influential in the choosing a solution.