This presentation highlights the importance of having well documented requirements in place and highlights the important role of requirements in the various stages of product selection process.

2. Introduction:
• The IT strategy of an organization may dictate that Commercial Off the Shelf (COTS) products be
bought to service business requirements.
• Once a decision is made on build vs. buy, organizations expect that having a well drafted RFP
would lead to the selection of the most appropriate product.
• The consequent impact in such a situation is that product selection dictates requirements
definition and refinement rather than business requirements directing product selection and
implementation.
• In such situations, organizations end up buying products that may not be the best t for their
business needs and end up facing the consequences of wrong product selections.
• This presentation highlights the importance of having well documented requirements in place
and highlights the important role of requirements in the various stages of product selection
process.

3. Benefits of having Well Defined Requirements in Pre-Product
Selection Phase :
At the time of documenting requirements, the functional requirements should be grouped based
on priority. Mandatory and essential sub-groups should be of higher priority. Non-functional
requirements grouped in a similar manner help evaluate a product on dimensions of performance,
scalability and reliability. Having well documented requirements prior to the product selection
process helps in the following manner:

4. Benefits of having Well Defined Requirements in Pre-Product
Selection Phase :
• Reduce the number of products under consideration at an early stage based on a preliminary
evaluation. For example, products that do not meet compliance requirements would not qualify to
be shortlisted. Similarly, products that would not meet technical requirements can be discarded
from the consideration set at this stage itself. Certain database and hardware considerations would
be a constraining factor during product selection and these can be easily identified from non-
functional requirements and constraints in the requirements catalogue.
• If requirements are not defined in reasonable detail (both functional and non-functional) the
selected product vendor later drives the requirements - largely driven by the product features
available. This results in organizations trying to t their business requirements to the product
features, resulting in an incorrect / sub-optimal product choice that does not meet all business
requirements.
• Help evolve standard screening criteria by eliminating subjectivity during evaluation. This can be
achieved through assignment of appropriate weights to various critical parameters during the
selection / scoring process. Product with capabilities that meet vital / critical / important
categories of requirements would score higher during selection.

5. Benefits of having Well Defined Requirements in Pre-Product
Selection Phase :
• Ignore product capabilities that are not relevant to the solution requirements. Over 64% of
product features are not used by organizations post implementation, according to a study done by
Standish Group in 2009. Having well defined requirements would prevent unnecessary
expenditure on implementing features that do not serve any purpose.
• Identify product capabilities that will enhance current business processes. These features can be
taken advantage of to augment and refine business processes that can result in greater
efficiencies.
• This is the phase where business needs to invest time and resources. Once the product selection
phase commences, the responsibilities get diluted between business and IT. Better quality of
requirements definition by business early will result in better quality of delivery from IT
organizations both in product selection and later downstream project phases .

6. Benefits of having Well Defined Requirements in Pre-Product
Selection Phase :
In summary, having well documented requirements helps draw up a preliminary shortlist of
products that need to be investigated further for suitability, by easing the evaluation process and
making the scoring process objective.

7. Role of Requirements during Product Walkthrough :
• This phase of the project is the most important. Once there is an initial shortlist of products, this
is the time when the project team is able to explore the product features by conducting a detailed
product walkthrough of the shortlisted products.
• This walkthrough can be driven by the detailed requirements checklist which focuses on product
functions. At the end of this process, the project team would be able to identify the list of product
modifications and interfaces.
• Some of the requirements would be met through configurations, some would entail custom
development / customization and there would be some features that need to be taken up at a later
date as enhancement.
• Product walkthrough sessions can be productive if requirements had been documented in the
first place. This would enable the project team to arrive at meaningful conclusions when comparing
various competing products by using the same yardstick for comparison.
• Another important advantage is that these sessions would be guided by the organization’s
project requirements and not be driven by product features that vendors offer.

8. Role of Requirements in Product Implementation :
• Upon completion of the product walkthrough and finalization of product selection, the project
team can prioritize the implementation phases of the product based on the pricing received from
the vendor for customizations and configurations.
• Based on the requirements priority, the project team can make an informed decision on those
items that would be in scope and prioritize the releases. Having detailed requirements done ahead
of the implementation helps the project team negotiate and decide the scope of the solution with
the stakeholders instead of letting the product features dictate the solution scope.
• Depending on the time to market requirements and the budget constraints, the project team
may decide to pursue a release strategy that addresses critical requirements first (for example,
compliance related requirements) and subsequently address the roll out of less critical
requirements that may also require customization efforts from the product vendor.

9. Conclusion:
It would be worthwhile for organizations to spend time on requirements documentation prior to
the process of product selection. The RFP and the subsequent product selection process should be
driven by the requirements documented earlier. Allowing the product vendor to define / influence
the requirements process leads to a wrong product selection, consequences of which would be
lack of alignment of the technology organization to business.