Project Return

How to create an effective Request for Proposal (RFP) for seeking software development?

November 2nd , 2020

Today, there are no businesses that are not impacted by software and technology. Irrespective of the size of companies, leaders must manage the process of buying software services. Unlike physical products, procuring software services, and the subsequent software project management is not everyone’s cup of tea!

Through this blog, I intend to highlight:

  • Basics of RFP vs. RFQ
  • Structure and components of a great Request for Proposal
  • The relevance of systems to manage the process of creating a Request for Proposal

Basics of RFP vs. RFQ

It may be worthwhile to reiterate that a Request for Proposal is used when the customer seeks a solution to his problem from an external entity. Example: a sick person visiting a doctor for seeking a solution to his sickness.

In a Request for Quotation (RFQ), the customer knows his problem as well as the solution but seeks a quote from a vendor. Example: a sick person needs to buy medicines from a pharmacy based on his ‘doctor’s prescription.’

It is important to note that:

  • A Proposal to an RFP is evaluated based on the strength or value of the solution; the price may not be the deciding factor.
  • A Quotation to an RFQ is evaluated based on the price, discounts, and payment terms; usually, price becomes a deciding factor.

It must be now evident why a Request for Proposal is important while buying software services.

Why do we need a great-looking RFP?

  • Clearly explain the business problem(s) to potential service providers
  • Allow potential service providers to come up with the best solutions.
  • Enable better estimation of timelines, resources, and costs.
  • Support evaluation and selection of potential proposal(s) from service providers.
  • Manage the overall customer-service to provide engagement and relationship cycles.

Structure and components of a great Request for Proposal

Creating an RFP depends on the nature of the industry, the complexity of the software, as well as capabilities (features and functionalities) desired. Advanced software such as artificial intelligence, machine learning, the internet of things (IoT), blockchain, and others may result in a lengthy and granular level of details. In general, a good RFP must cover:

  • Customer company overview

This section provides an overview of the company history, its industry, domain, nature of the business, customer profiles, business locations, and others.

  • Background of the RFP

This section should clarify the background of the RFP.

Some examples: company shifting to digital transformation or company looking to improve overall efficiency, productivity, and effectiveness through automation or enhancing the software project management maturity from level 2 to level 4.

  • Business Objectives

This section outlines the aspirations of senior management from a strategy execution viewpoint.

An example: to support a single version of the truth or to be an enabler for excellence in project delivery.

  • RFP-Specific Program/Project Objectives

This section should indicate the specific objectives that this RFP aims to accomplish. The success or failure of the potential service provider would be linked to the objectives described here.

An example: create a single integrated software project management environment that seamlessly works with all the business units as well as the existing enterprise applications such as ERP, CRM, Accounting, and others.

  • Stakeholders

This section indicates the stakeholders who have either interest and/or influence on the outcomes of the RFP Program/Project.

  • Existing Pain Points

In this section, the customer elaborates on different pain points that exist and how they impact the organizational goals and objectives. These pain points could vary depending on the nature of the RFP.

Some examples:

    • Unpredictable / Unstable performance of the existing software project management system.
    • Lack of visibility into resource availability vs. business demand.
    • Non-standard ways of managing programs and projects.
    • Documentation is managed offline via spreadsheets, documents, and emails.
  • Functional Requirements

This section describes in detail, the functional requirements that the ‘proposed’ software needs to address. In some cases, a separate document may be provided which may take the form of a Systems Requirement Document.

Some examples:

    • Ability to manage project schedules, tasks, and manage resources and integrated with the mobility workflow in case of resource transfers.
    • Ability to determine the headcount availability and integration with skillset and competencies. Tracking of the project: planned vs. actual schedule and effort.
    • Must have a lesson learned module
  •  Proposal Requirements

In this section, the customer outlines the information that potential service provides must provide; examples include:

    • Description of the service provider’s business (history, background, core services, management & team, etc.)
    • Description of the service provider’s credentials (clients, similar projects delivered, awards & recognition, association with industry bodies, etc.)
    • Description of the service provider’s approach to meeting customer objectives.
    • Description of how the project would be planned and executed.
    • Description of recommended solutions including best practices, etc.
    • Details of pricing and the format for the same.

There could be many more dimensions that could go into RFPs based on the value and complexity of the software intended to be procured.

Key Takeaways for Customers

  1. If customers are serious about seeking the best proposals from potential service providers, they must invest quality time and effort during the process of crafting Request for Proposals.
  2. Considering that organizations seek different products and services from diverse service providers, they should invest in systems that make the process of creating RFPs templatized, efficient, and faster!

TouchBase Proposal Management is designed to help both customers and service providers to streamline their process of creating and responding to proposals by integrating with project delivery with all the dimensions of software project management.

We are glad we developed TouchBase Proposal Management.

It is now up to you to try!


Name of Author


Srikanth PV comes with two decades of global corporate and consulting background across industries with diverse roles including Strategy, Leadership, and Management.

Currently, Srikanth is Head, PPM Content Management at ProductDossier focused on content management strategy aimed to empower customers create and enhance value through its flagship digital solution - TouchBase. Srikanth is also a former member of the Board of Directors of PMI Bangalore Chapter. View his detailed profile on LinkedIn at https://in.linkedin.com/in/srikanthpv-ppm



Return

Top