How to write a request for proposal for a web project?

STRATEGY
DEVELOPMENT
How to prepare an RFP?

How to write a request for proposal for a web project?

With the spread of digital services, the key processes of companies - their revenue generation, and their operation - are partly or entirely connected to online channels.

Whether it is about a company website, ERP, webshop, CRM or online marketing activities, similar projects have great importance in the life of every company, from SMEs to large multinational companies.

Often - due to a lack of in-house  resources or limited specialized knowledge - decision-makers hire experienced external partners, i.e. a digital agency or IT company to realize the planned project.

In this post, using many years of agency experience and lots of tender participation, we will show you how to prepare a professional request for proposal (RFP).

To prepare and submit a bid, the development company/digital agency must receive detailed information to understand scope and business needs.

Information can be shared in several ways, starting from consultation and demos, through written demand lists (briefs) and up to the request for proposal documentation for larger projects.

In our experience, good RFP leads to more bidders and more accurate bids, and ultimately means possible cost savings and the selection of the best contractor.

 

What does RFP stand for?

RFP is an abbreviation of Request For Proposal. The document compiled by the client, in which it summarizes, presents the planned IT project, the client's needs and all other necessary information that the agency or IT company may need. Hereinafter we refer to it as the RFP.

 

The RFP is not just a document describing the web development, as it includes, among other things:

  • Definition of the project - business and professional goals, scope of the task, requirements, expected results
  • Contractual conditions, commercial terms, sometimes a specific contract draft,
  • Technological constraints and requirements that must be adapted to
  • The selection process, the steps and timing of the tender process, participants and evaluation rules, decision criteria.
  • Expected content, structure and declarations of the offer.

 

In addition to the RFP, RFI (Request for Information) and RFQ (Request for Quotation) can also be used depending on the scope of the information requested from contractors and the business purpose of the request for proposals.

Both precede the Request for Proposals (RFP) and their role is to prepare the RFP itself.

The RFI assesses the range of possible applicants and the various technical, professional and implementation alternatives they propose, while with the RFQ, the client requests prices for a defined technical content in advance, usually with a non-binding value, from market players.

The purpose of the former may be to identify a widespread, existing infrastructure or an innovative new technology, while the latter is to define the budget of the project more precisely, e.g. for corporate annual planning or for the planned call for tenders.

 

The role of the RFP

The FRP is a useful document for both the client and the future contractor. Since they want to make an agreement based on mutual understanding of the project, it is important that the document is of good quality, i.e. well defined and comprehensive.

 

In some cases, the client hires an external consultant or even a digital agency to compile this document or a part of it before the project.

The time and money spent on this work pays off as contractors prefer to bid on a detailed request for proposals. Knowing that this way they have a lower risk in understanding the task, a more competitive offer will be submitted, which ultimately leads to a more favorable project price

Below is the point of view of the two parties in a little more detail.

 

The purpose of the client with the document:

  • Reach a common understanding on a task in-house, even by involving several affected areas
  • to find contractors who meet the expectations and may be able to implement the planned task.
  • Presentation of the bidding company and the project to the bidders.
  • Validation of the idea, getting to know proposals, alternatives, and technological possibilities through the recommendations of the applicants.
  • Compared to the planned budget, the task is to learn about market pricing and possible trade conditions.
  • Concentrated transfer of information, instead of many separate consultations and negotiations.

 

From the entrepreneurs' point of view, the RFP helps

  • Deciding whether it is worth investing energy in making an offer.
  • Ask targeted questions based on the document, which can clarify many open issues existing in this phase.
  • To provide alternatives that better suit the client's needs.
  • elaborate how you interpret the client's needs, what solutions you consider optimal for them and why. The agency can even raise new proposals.
  • To realistically assess the time required for implementation, to provide an optimal offer in terms of cost and time.

 

The RFP document is usually prepared by several stakeholders

  • The project or product manager, who is responsible for the RFP as a quasi-project and often defines the professional/business needs.
  • In larger organizations, lawyers and procurers are responsible for conducting the tender and its rules.
  • In the case of a special field, an external consultant can help with the work.
  • And let's not forget the company's other IT partners, e.g. Hosting, ERP, CRM, online marketing agency that can be connected to the project.

 

How to write a request for proposal for a web application project?

 

There are no strict elements of the written request for proposal. You can give a precise brief on one page, and sometimes questions remain after reading a twenty-page product requirement document. (PRD)

The complexity and nature of the task, the client's policies, and the range of invited IT companies influence the content and scope of the Request For Proposals.

Based on our many years of experience, RFPs are usually created with the following content:

 

  1. Brief introduction of the project
  2. Company intro: history, overview of activities, presentation of project participants
  3. Project goals, expected business results, target group, competitors
  4. Project scope, requested services, deliverables, deadlines
  5. Technological constraints
  6. Project frameworks, schedule
  7. The schedule, steps and rules of the request for proposals
  8. Content and format of the offer expected from entrepreneurs

 

Introduction of the project

  • A short summary of the task with the following information, in a format similar to an executive summary:
  • Presentation of the business context, mentioning customer, industry, market.
  • What challenge or problem does the project respond to, what is its main goal?
  • What services does the customer expect an offer for?

 

Company intro

The company's history, mission, activities, products, target groups and customers are presented here.

How is the planned application development project related to the operation of the company? What processes does it affect in order to create value for the company?

Who will be the client-side specialists, business decision-makers, primary contact person, project manager participating in the project?

 

Introduction of the company

 

Project goals

  • What business need or problem is the project created for? What difficulty is this currently causing?
  • What objective and measurable results does the client expect as a result of the project? Increase in income, improve efficiency, or reduce costs?
  • How will the project help internal operations, customer service and sales?
  • Who are the competitors, what is our competitive advantage (USP) compared to them, what are they better at, what can we learn from them?

 

 

Scope of the project, deliverables, deadlines

This is the most important part of the request for proposals, as contractors prepare their hourly estimates and price offers based on this. All information can be important, let's describe everything in detail.

Visuality, the appearance of the application: what branding should the interfaces follow? Existing elements based on Brand guideline/design systems or new look@feel have to be designed. If the latter, what style and tone do you prefer, are there any inspiring examples?

UX/UI design - if it is possible to determine what processes and pages the application can have, let's make a list. Nowadays, responsive operation on mobile, tablet, and desktop interfaces is a must, but the target group may have special needs on which it is worth focusing. For example, in the case of a taxi ordering app, a desktop interface will certainly not be needed.

Content and functions - when formulating needs and functions, we can use the user's perspective. For what purpose and steps will the application be used typically? Where, what data do they provide, what interactions they will have?

Will there be users with multiple roles? For each, you need to think about what tasks they will have in the application.

How is content edited? What is the manually edited data, what content can be obtained automatically, connected to another system?

Let's also think about special, rarely occurring cases, as the system will have to handle those as well.

Other requested services during the project, such as technical and content search engine optimization (on-site, off-site SEO), copywriting, hosting, support, future expected maintenance tasks.

 

Technology constraints

In general, a company uses several IT systems or the company itself operates in an industry where standards and regulations have been established. This can determine to a certain extent what technology a new application can use.

 

Technology constraints

 

Such situations can also occur in a smaller company. If we just think of an existing ERP or CRM system and a new webshop we currently develop. The technological capabilities of the two existing systems determine how the webshop can synchronize data.

Choosing a technology can also be a constraint if the client's internal IT team specializes in a specific platform/ technology stack.

In this case, a solution with a similar technology may be the ideal choice for the new project as well.

Maintenance tasks following the project can also be defined here. In larger companies, there are policies for this and the contractor will usually have to cooperate with an internal team. For smaller companies, partial/full outsourcing is more typical.

 

Project frameworks, deadlines

By specifying the project's budget, we can help participants rethink and validate the scope.

If we don't want/can't give an exact amount, a range can also be a guideline. It helps to build trust while not distorting the competition between applicants.

This part can also include the definition of the milestones and deadlines of the project, i.e. which project step should be handed over to the client by when, with what deliverables, and according to compliance criteria.

The related commercial conditions, the amounts belonging to the phases, and the payment deadline can be defined at the same time, even just the penalties for late or incorrect delivery.

 

RFP steps and schedule

Steps and timing of the tender

 

If the typical client checks the price tag first, contractors do the same with the submission deadline and schedule.

A number of tasks must be completed before submitting the offer, and even a professional candidate may fail if it misses a minor task.

  • Date of sending the request for proposals - when the invited companies received the tender.
  • Submission of a question-and-answer round (Q&A), deadline for answers
  • Consultation date
  • Deadline for submitting an offer
  • Decision
  • Announcement of the winning applicant, conclusion of the contract
  • Planned start of project



Content and format of the offer

For the sake of easier comparability it is worthwhile to define a proposed, expected structure of the proposal.

The offer, broken down into chapters, also speeds up the evaluation and decision; The better prepared the offers are, the fewer subsequent consultations will be necessary before the final decision.

Possible content:

  • Bidder’s data: company data, contact details, brief introduction, services,
  • Professional offer: interpretation of the project, proposed content, tasks, especially deviations, alternatives, optional elements compared to the tender received.
  • Project plan, methodology: sub-tasks, schedule, deliverables per milestone, PM and communication tools used, as well as the proposed method of project management (e.g. agile, lean, waterfall)
  • Team: introduction of professionals participating in the project and their roles
  • References: references to previous experience, similar projects, case studies.
  • Quotation: time and cost estimate of the task itemized, per service.




Can we help you prepare a request for proposal? 

Contact us!

Or make an appointment for a free 30-minute consultation.

 






 

Ready to work together?

Just send us a short brief and we'll reply in 24 hours.
hello@skvad.com

Email copied