deal

World Class Functional Requirements – blog

When looking to purchase technology services, an RFP is typically the first step in the development of a long term, mutually beneficial relationship.

Developing an RFP requires much thought. Contract frameworks, project scope, timelines, budget, and performance benchmarks are just a few of the things that need to be considered. One of the more fundamental considerations (and one that can be under valued) is the ‘functional requirements document’ (FRD) that provides a clear definition of the functionality that a buyer expects to receive from a supplier. This document ensures that an appropriate solution is designed and delivered, and acts as the primary yardstick against which success will be measured.

Creating a functional requirements document is not easy. It requires a full understanding of both what is needed AND what is possible. To add to the complexity, it typically draws on the knowledge and insight of a variety of people from different areas and perspectives, and from both inside and outside of the organization. Even the simple act of coordinating input can be challenging.

At Integris Applied we employ a six step approach to the development of functional requirements during the RFP process. While it would be impractical to document the entire process, the following is a summary that can serve as a check-list of activities that should be considered.

(1) Compile Service Requirements: Any existing statements of work and/or service level agreements should always be reviewed to ensure that the current service lifecycle addresses all planning, transition, operations and retirement activities. In addition, it is imperative to establish early stakeholder participation and ensure business needs and ‘pain points’ are quickly identified and documented.

(2) Capture The Market’s View of Requirements: Buyers should engage the marketplace when building the FRD. Publishing draft requirements to qualified service providers for their comment is an example of marketplace engagement. This allows appropriate modification and enhancement prior to final RFP publication. One especially useful activity is to conduct clarification sessions with potential suppliers (as allowed within procurement guidelines, rules or policies) to gain a broad understanding of the appropriate level of detail needed for the requirements document.

(3) Assimilate Market Feedback & Confirm Stakeholder Requirements: Incorporating the findings from interaction with the market and stakeholders ensures that the requirements document is both comprehensive and practical. It validates that the desired services are available and allows for refinement of the final RFP.

(4) Determine An Appropriate Service Model: There are several different approaches that can be taken to acquiring services. For example, services can be acquired at an individual component level (mainframe, server, end-user computing etc) or consolidated into broader service areas. Similarly, they can be accessed via a multi-sourcing service integrator or from independent service providers. An assessment of the market view, stakeholder requirements and current environment can help identify the service model that will be most relevant/appropriate.

(5) Establish Qualification Criteria (and Pre-Qualify Suppliers): While it’s useful (and sometimes a stated requirement) to consider a diverse pool of suppliers there’s little point in considering any that would be unable to deliver on stated requirements. It is important to take the time to establish qualification criteria (within procurement rules) such as experience, availability and organizational fit. Qualified vendors can then be invited to participate in further discussion about requirements and their ability to deliver those requirements.

(6) Prepare the RFP: The sixth and final step is to incorporate the functional requirements into an RFP. Providing context to the FRD with data such as existing technical architecture, current performance analysis, and long-term technology vision will improve supplier understanding of the business requirements their client plans to achieve.

These six core activities will help any organization buiild a compehensive functional requirements document with buy in from internal and external stakeholders. With similar diligence and perspective applied to other elements of the RFP, buyers of technology services can improve the outcomes they receive from suppliers and thereby improve the manner in which they serve their customers.

Randy Tucker & Jon Crawford, August 2018