Home > Services > Security Solutions > Solution Selection

SOLUTION SELECTION :

Application Solution Selection Process :

Scope :

A small Application Solution Selection project will typically have a narrow scope (e.g., 3 high-level processes); a small number of qualified vendors, and is completed in just over a month.

On the other hand, large projects will typically have a large scope (e.g., 10 high-level processes), a large number of qualified vendors (e.g., 10 to 12 vendors), and is completed in 3 1/2 months. Projects of larger scope (e.g., SAP, integrated packages) should be partitioned into two or more parallel and coordinated projects.

Several factors can increase the level of effort or duration of the project beyond those cited above. If an RFI or RFP is used as an information gathering method, additional time should be allotted in the schedule to allow vendors to prepare their responses.

Additional effort and duration should be added to projects where business and technical requirements, or models and documentation of vendor packages are not readily available to the team. If the required application is functionally or technical complex, the evaluation team may need more time to understand the requirements and possible solutions.


Risk based Approach :

The experiences of organizations with application packages have generally been mixed. Because application packages are chosen as a quick path to implementation, pressure can be imposed on the evaluation team for a quick evaluation and selection.

In some cases, this has led to the acquisition of a package that requires significant customization or to an implementation failure. Significant customization or redevelopment of an application package can be very costly and time-consuming because the development team usually lacks knowledge and understanding of the package's technical implementation.

Organizations that customize more than 50% of the package's functionality generally spend more time and money on a package implementation than on a comparable custom development project.

The level of detail, rigor, and effort applied in evaluating and selecting packages should be commensurate with the level of risk. If the required application package is small in scope, interfaces with few systems, runs on a single platform at one site, and is inexpensive, a quick evaluation process can be used. Because the risk is controllable and the cost of selecting the wrong package is minimal, a process that uses checklists and focuses on a small number of market leaders can be completed in short order.

On the other hand, if the required package is large in scope, interfaces with many systems, runs on multiple platforms at sites around the world, and is expensive to buy and maintain, a formal and rigorous evaluation process should be used. Because the business exposure is significant, an approach that employs sufficient detail and rigor can prevent the organization from making a costly mistake.

The Application Solution Strategy stage has been designed to evaluate business and technical risk and to select a package evaluation approach that is appropriate given an understanding of the key risk factors.



Principles-Based Evaluation

Deciding on "what's important" early in the evaluation and selection process is key to focusing the evaluation team and conducting a successful evaluation. Consequently, this Application Solution Selection process uses a "principles-based" evaluation process to ensure that key principles are established during the first few days of the project to guide and facilitate the team's decision-making. These principles address important package issues such as: