Packaged Software (COTS) Selection
Marathon has assembled a team of senior Business Analysts and
technology experts who have been performing packaged software
(COTS) selections since 1985. This volume of work and the
experiences derived from it have allowed Marathon to develop and
execute an effective Requirements Definition and Package Selection
methodology. The methodology has been utilized in dozens of client
engagements in all types of organizations, ranging from small
non-profits, through local governments, to global manufacturing and
distribution firms. When the methodology is executed, the projects
have a 100% success rate.
Replacement of a mission-critical application with a Commercial
Off The shelf Software (COTS) product and the required packaged
software selection process is one of the riskiest IT projects an
organization can undertake. Package selection is often affected by
such factors as:
- Ill-defined business
requirements resulting from a lack of
specificity
- Insufficient consensus on
requirements and relative priorities
- Lack of management commitment to the
packaged software selection process
- The inability to clearly
communicate the business requirements to the software
vendors
- Lack of continuity between the software
selection and the implementation plan
- The possibility that internal
politics will affect the software selection
process
Adding to these internal project factors is the probability that
the scope of the project will result in an elevated level of
visibility throughout the enterprise. Therefore, any project or
organizational disruptions will be highly visible and gather the
kind of notability that adds to the risk.
The Marathon software selection methodology accounts for all of
these factors. Specific tasks, milestones, and methods have been
developed with two goals in mind:
- Identify the software solution that gives the client the
optimum blend between functionality and cost
- Minimize project risk, both in the software selection and the
eventual implementation of the selected software product
The Marathon software selection methodology segments the process
into two or more major phases, depending upon client need. The two
phases that are present in most software selection projects are 1)
Requirements Definition, and 2) Software Selection. If necessary, a
middle phase may be added to scientifically answer the "Build
versus Buy" question, if the "Build" option exists.
Phase One of the packaged software selection process is the
definition of business and technical requirements for the new
system. This also includes client-specific constraints such as
budgetary factors, ability to manage an application of far reaching
scope, time lines, regulatory activities, and others.
Requirements are defined through a series of executive,
managerial, and user interviews to identify functional
requirements. User and work group operations are observed.
The first deliverable in the packaged software selection process
is the Requirements Definition Report. This comprehensive
management report is the cornerstone for all packaged software
selection tasks that follow. The Report contains the Requirements
Traceability Matrix, descriptions of client work flow, and a set of
Preliminary Recommendations intended to focus client attention on
those internal factors that could impact the software selection
process or eventual implementation.
The Requirements Definition Report and its final acceptance by
the client requires a great deal of scrutiny and interaction with
the appropriate levels of client management and staff. As noted
previously, the Requirements Definition Report must accurately
reflect all of the factors affection the packaged software
selection.
Phase One of the packaged software selection project is
characterized by the following:
- A very high level of client and client management
interaction
- Incrementally defined milestones that enable client management
to monitor project progress
- A significant level of emphasis on the definition of relative
requirement priorities
- A disciplined Change Management process, directed toward
controlling project scope
- A tight Risk Management process, striving to prevent risks from
becoming issues
- A huge amount of two-directional information and knowledge
sharing
When Phase One is completed, requirements will be identified and
prioritized; consensus will be achieved; and expectations
concerning the packaged software's functionality will be
aligned.
Phase Two of the packaged software selection process addresses
the identification and evaluation of viable software solutions. It
ends with the identification of the optimum solution. In cases
where the packaged software selection process is executed, the
eventual identification of the optimum solution is usually a clear
call.
Identification of viable packaged software vendors begins
approximately 75% though Phase One. The software selection team
typically has a sufficient understanding of the requirements and
constraints to identify packaged software vendors who fall within
the client's range of requirements. The viable packaged software
vendors are selected to receive a Request for Proposal (RFP) and
respond to the client's requirements with a proposal.
Vendors are provided with the specifics of the client's
functional and delivery requirements and are required to respond to
each individual requirement. Vendor responses are scored in
accordance with the defined requirement priorities and each
vendor's ability to meet those requirements, either through
existing software functionality, or proposed software
modifications.
Results of the proposal scoring portion of the software
selection process are discussed in detail with the client. Relative
strengths and weaknesses are considered and one or more vendors are
invited to demonstrate the capabilities of the proposed
software.
Marathon coordinates the software demonstrations as part of the
packaged software selection process. This enables the client and
vendor to focus their energies on the high priority items and
maximize the time spent on this part of the software selection.
During the demonstrations, vendors are expected to validate
their specific responses to the defined requirements contained in
the RFP. Failure to do so results in a lower score.
At the conclusion of the demonstrations, Marathon conducts a
series of meetings with the client project team to determine if
enough information is present on which to make a purchase
recommendation to management. If so, the purchase recommendation is
consolidated list of recommendations concerning the purchase of the
software and the pending implementation.
The final deliverable in the packaged software selection process
is the Vendor Evaluation Report. This presents the results of the
vendor evaluation tasks, including the purchase recommendation. It
also includes a series of final recommendations, with supporting
rationale, for client consideration. The delivery of the Vendor
Evaluation Report concludes the packaged software selection
project.
The client benefits resulting from a structured packaged
software selection process include:
- The client establishes a strong foundation of known
requirements and relative priorities
- The client develops a solid understanding of what the selected
software package will and will not do
- Investment requirements are clearly defined
- The risk of omitting a major functional requirement is greatly
reduced
- The risk of selecting a weak vendor is greatly reduced
- Internal issues that can impact the software selection and
eventual implementation are identified for management
attention
- The use of a structured software selection process sets the
tone for the implementation project
- Marathon functions as the client's advocate during the packaged
software selection, setting the stage for continuity throughout the
implementation project
In addition to the use of a structured requirements definition
process in a packaged software selection engagement, Marathon
frequently uses this method when a large custom software
development engagement is under consideration. All of the benefits
associated with Phase One of the packaged software selection
process transfer to a software development project.