How to Write an RFP That Potential Contractors Will Love

This article is intended for you, dear clients, both current and future. Whether you’re looking to build a new application, enhance an existing system, or integrate complex technologies, crafting an RFP that developers will love involves more than just listing technical specifications. It’s about creating a document that not only conveys your project’s vision but also fosters collaboration, innovation, and a mutual understanding of expectations. In this guide, I will explore key strategies to help you write an RFP that attracts high-quality proposals and sets the stage for a successful partnership with your development team.

A Request for Proposal (RFP) is a critical document that organizations use to solicit bids from potential suppliers or service providers for a specific project, product, or service.Well, the name might vary, but the idea is the same: communicating to get a proposal, which includes an estimate. If you work in software development as a manager, you have likely dealt with RFPs, whether on the supplier’s side or the client’s side. Your role involves ensuring that proposals either meet the detailed requirements set forth by your organization or that your responses adequately address the client’s needs and highlight your company’s capabilities.

Having worked on numerous software development projects over 23 years, I’ve encountered hundreds of RFPs of varying quality. This article will help you understand the RFP process in the realm of software development from the developers’ perspective. By gaining insights into how developers interpret and respond to RFPs, you will be better equipped to communicate effectively and align expectations, leading to more successful collaborations and project outcomes.

I structured the recommendations as follows:

• Goals
• Context, Vision and High-Level Scope
• Deliverables
• High-level Tasks (or Work Packages)
• Requirements
• Constraints
• Priorities
• Ways of Working
• Shared Resources and Processes
• Estimates
• Assumptions
• Effort Estimation Techniques
• Estimating Separate Features or Requirements

The RFP itself should provide pre-defined forms to complete and tables for pricing. This makes the evaluation of responses easier later on. But below I will focus on things about the implementation project which is requested by the RFP rather than the RFP process itself. 

 

Goals

Essentially, this is an answer to the question, “Why do we need all this?”

The brain strongly dislikes formulating goals because it smacks of abstract philosophy and seems irrelevant. However, answering the question “Why do we need all this?” is extremely useful.

Every decision is a compromise. It brings benefits in one area but creates additional complexities elsewhere. A good decision brings more benefits than it creates difficulties. Therefore, it’s important not only to formulate a goal but also to ask yourself whether the result was beneficial

There is a good rule of thumb: The goal of any activity lies outside the scope of that activity. The actual goal of developing a website goes beyond the mere technical task of building web pages. For instance, the true objective might be to enhance customer engagement, provide a seamless user experience, or build brand visibility. The ultimate goal of a new B2B system might be to streamline business operations, reduce operational costs, and improve overall efficiency. By automating order processing, the company aims to reduce manual labor, minimize errors, and accelerate the order fulfillment process, which leads to cost savings and higher customer satisfaction. By creating a robust e-commerce platform, the business aims to attract a wider audience, offer a seamless shopping experience, and ultimately boost online sales.

If you really want to do it well, such a goal should be SMART — Specific, Measurable, Attainable, Relevant, and Time-Bound. But for a developer, this might be a bit excessive. Developers just need to understand the goal, the answer to the question, “Why do we need all this?” However, if there are numbers and specifics, it is certainly a bonus.

Bad Goal Example: “We want a new website.”. This goal is vague and lacks specifics. It doesn’t provide any information about why the new website is needed or what it aims to achieve.

Good Goal Example: “We want to increase customer engagement by 30% within the next 6 months. For that, we aim to develop a new website. The website should provide a seamless user experience, improve brand visibility, and support e-commerce functionality to boost online sales by 20%.”

I wrote many sentences here, but in your RFP, this section might consist of just one.​

 

Context, Vision and High-Level Scope

Let’s be clear: if an RFP describes a specific request on what to implement, then someone has already devised a solution, and now the client is looking for the heads and hands to implement it according to the task description. If there is no solution yet, then the search and discovery of the solution itself is the sought-after result.​ There is no middle ground. Either you don’t know how to do it and want to find out, or you know and want someone to execute it. In the vast majority of cases, RFPs represent the latter.​

It is important to provide a high-level overview of the future software system, describe the system’s purpose, objectives, and primary features. Such a document could serve as a communication tool between stakeholders to ensure everyone has a shared understanding of the system’s goals, and it is a great starting point for the next step, tasks.

It’s very convenient if

• changes are presented as AS IS and TO BE.
• there are charts and diagrams.
• there are references of how it was implemented somewhere.
• there is a process that defines how to ask scope/vision related questions 

 

Deliverables

Deliverables are the quantifiable goods or services that need to be provided at various steps of a project as well as at the end of a project. Deliverables include documents, plans, specifications, UI prototypes, functional proof-of-concepts, wireframes and mockups, demoable systems, launched systems, documentation, test plans and cases, user manuals, deployment scripts, training materials, and so forth.

There might be a potential misunderstanding about deliverables that need to be addressed. For instance, if you expect the development team to conduct a knowledge transfer to the client’s development team upon project completion, what constitutes a deliverable in this case? At the very least, documentation. Possibly, a training session. But is a trained client team a deliverable? This is a complex issue, as it requires the client’s team’s motivation and engagement, and probably involvement in staffing processes.

Many problems arise when the client and the contractor are not on the same page regarding the expected deliverables.

 

High-Level Tasks (or Work Packages)

Tasks are what need to be done to produce the deliverables and achieve the goals and scope from the previous section. These are specific actions whose results bring the company closer to the goal. This section is very important because, in its absence, tasks have to be inferred from various hints and suggestions in the document. Usually, tasks are listed as “Create…”, “Develop…”, “Train…”.

Ideally, this list should eventually become a checklist for project progress at the high level. More importantly, at the evaluation stage, it is the tasks that reasonably reflect the costs and required time. This cannot be said for requirements and constraints.

It is understood that a specific service provider with experience in the field may have its own perspective on breaking down a project into tasks, which may differ from yours. The more high-level the tasks, the less likely these differences will be critical. Nevertheless, it is crucial to have some (even high-level) plan, and it is important to share how flexible you are in modifying this approach.

 

Requirements

If your requirements are unclear, the chances of successfully completing your project are slim. Collecting comprehensive and precise requirements is crucial in every industry, whether following Agile or Waterfall methodologies. The key aspect of requirements is that they are always hierarchical and interconnected in any large system. The best approach is to start with business requirements. These address the question of “what needs to be achieved” without touching on the “how.” The best way to articulate requirements clearly is to frame them from the perspective of an actor, such as a system user.

Technically, software requirements can be organized as functional and non-functional, but at this phrase these nuances are not really important if they are formulated and structured well.  

As for the format, I personally don’t like having the list of requirements as an Excel spreadsheet. Despite certain conveniences (easy filtering), this format leans towards the exclusive use of plain text (and very short), which is generally appropriate and often preferable, but in those rare cases when a diagram or table would replace a thousand words, we still get text, and a very short one at that. Such limitations, in a sense, define the quality of the content.

 

Constraints

Constraints, in essence, are special kinds of requirements. They represent the limitations or boundaries within which the system must operate. There are at least two types of constraints: internal and external. Internal constraints arise from previous design decisions within the project, eventually limiting the designer’s flexibility in other areas. External constraints stem from outside factors, resulting from concerns such as cost, reliability, security, maintainability, and safety.

Internal constraints may have a long chain of dependencies and complex reasoning based on previous experience of the team, their own understanding of what works and what doesn’t. For example, constraints may state that ContentStack should be used as a CMS, SAP Commerce Cloud as an e-commerce platform, and Coveo as the search service.

There is a thin line between requirements and constraints. For example, a performance requirement might be considered a constraint. The confusion arises because neither performance requirements nor constraints are functional requirements and thus can be referred to as non-functional.

It is very useful to understand how rigid certain constraints are. For example, if an organization is already heavily using AWS, adding complexity by involving Microsoft Azure without substantial reasons is probably not the best idea. However, in some cases, proposing the use of Azure can be rationalized, and it is very beneficial to understand if there is any flexibility in this matter and to what extent. This applies to all constraints.

 

Priorities

It would be helpful to see which requirements and tasks are of greater importance and which are of lesser importance, as well as to distinguish between what is urgent and what is not. This is often achieved by marking tasks and requirements as MVP (Minimal Viable Product, a product with enough features to attract early-adopter customers and validate a product idea).

 

Way of Working

Projects often require collaboration between the existing team and the developers from the company responding to the RFP.​

The existing team may have many complex, informal constraints that need to be considered when evaluating the project. Many of these have developed over the years. Therefore, projects are often assessed with the assumption that the contractor will work largely independently, with a finite number of interactions according to an agreed-upon procedure. This could include weekly calls and demos in the case of iterative development or specific stages for the delivery and acceptance of work in the case of the Waterfall model.

Taking such situations into account is quite complex, and it’s crucial to grasp their scope.

 

Shared Resources and Processes

A particular situation arises when the project involves modifying existing code that is simultaneously being worked on by another team. Additionally, processes integrated into the project plan may “live their own lives” and change without the contractor’s control.​

Accounting for such situations is very challenging, and at the very least, it is important to understand their scale.​

 

Estimates

Estimating the effort of software projects is a game of predicting the future with incomplete information. However, this prediction is needed for software tasks since it is key to making decisions. These estimates help guide customers, often within your own organization, in their planning. Customers usually want a rough idea of how long tasks will take, and as engineers, we reluctantly go along with this practice despite not liking it. We estimate because it’s easier to sell a solution with a fixed timeline, even though the reality is the customer will get whatever we can complete within the time given. This estimate becomes our promise to deliver software by a specific, often random, deadline.

Unfortunately, we commit to such deadlines, knowing there’s a good chance we won’t meet them and will face the consequences. Such consequences include losing credibility with the client, team friction (especially when management over-promises), low morale (especially when we have to work long hours to meet deadlines), poor quality software from rushed development and skipped quality checks, project failure due to consistently bad estimates, leading to a total loss of customer trust.

The first and main problem is that during the estimation phase, it’s often unclear who will be on the project team. At best, we know who the architect or project/delivery manager will be. However, the team composition is crucial and can significantly impact the project’s outcome.

The key contributors to poor quality of estimation are:

• Ambiguously defined tasks can lead to confusion and inefficiency in implementation.
• Tasks that generate new ones within the same sprint are common with research tasks, often resulting in solutions that need to be built in the same timeframe.
• Estimates for unfamiliar technologies can mislead developers, who may inaccurately gauge the time required based on experience with different platforms.
• Context-switching, where developers handle unrelated tasks, forces them to repeatedly adjust, reducing efficiency.
• In-sprint dependencies can block progress when precursor tasks are incomplete, especially if they involve multiple contributors.
• Research tasks without clear, tangible outcomes can lead to significant time wastage if not properly constrained.
• Peer pressure in high-stress environments can force developers to work faster than feasible, typically due to stronger personalities exerting influence.
• Poor morale from sustained pressure slows team performance.
• External pressure from management to alter time estimates due to political or financial agendas can further disrupt workflow.​

 

Assumptions

Uncertainty is inevitable. Sometimes, the gaps are significant and the stakes are high, but even then, business needs might compel us to make an estimate. Yet, there’s merit in not burdening with the need to specify every detail before an estimate can be made. For instance, if a client requests “a wheel,” familiarity with industry standards can streamline the process, reducing unnecessary back-and-forth communication and saving time. In situations where you need to bridge information gaps, it is important to make assumptions. If a service provider finds it important, it will define what “a wheel” entails within the context of their estimate, including what it covers and what it doesn’t. Assumptions accompany the effort estimation, serving as essential context. It is crucial to document them transparently, not buried in an obscure spreadsheet comment.

 

Effort Estimation Technique

There are various effort estimation techniques, including WBS (Work Breakdown Structure), top-down, bottom-up, analogous, three-point, PERT, and parametric approaches.

However, in practice, two main techniques are typically used: analogous and WBS.

The analogous estimation technique relies on past experiences and historical data from projects with similar characteristics. Project managers can make informed estimations for the current project by extrapolating the effort required for comparable projects.

The WBS-based estimation technique involves creating a plan that breaks down the entire project into smaller, more manageable components or tasks. Each task is then estimated individually, and these estimates are aggregated to determine the total effort required for the project. This technique provides a detailed and structured approach to effort estimation, allowing project managers to identify potential risks and dependencies early in the planning process.

Note that there is no technique involving breaking down the future product into features or requirements and estimating them one by one, then summing up to get the final estimate. For some unknown reason, this has become a very popular practice for estimating projects. One side pretends to provide accurate estimates, while the other side pretends to believe them.​

Team

The team composition depends on the type of the project. 

The ideal scenario is when all future team members are involved in the evaluation process and will also participate in the project implementation. The worst-case scenario is when none of those involved in the evaluation will be part of the project. Reality lies somewhere in between. In general, the fact that the core of the team can be formed during the evaluation stage and has participated in the development should, in theory, be a significant factor for the client.

Estimating Separate Features or Requirements

Real projects deal with packages of work rather than individual requirements. The process of composing and decomposing requirements into work packages is creative and sometimes complex. If you ask developers to estimate requirements rather than work packages, most will estimate based on a rough total divided among the requirements. I constantly see such requests and understand why this happens. Having figures for individual requirements is convenient when collecting various proposals from different service providers. In the case of significant discrepancies, it’s clear which topics to discuss first in a meeting.

Clarity/Complexity/Size per requirement

So, here’s the issue: with a long list of requirements, the labor costs can almost never be isolated and linked to specific requirements. If this is done, it’s only because the RFP leaves no other choice.

Here is my approach:

1. First, I evaluate the project through work packages, planning, and team, simply considering the requirements, resulting in the project’s costs and duration.

The techniques used are WBS and/or analogous. I chose a model based on past experience. This model incorporates a typical team structure and a standardized workflow that we have successfully employed in similar projects. The team usually consists of roles such as project manager, software architects, developers, QA engineers, and business analysts, ensuring comprehensive coverage of all project aspects. The workflow is designed to facilitate collaboration, streamline processes, and ensure timely delivery, drawing from Agile or Waterfall methodologies as appropriate for the project’s needs. By leveraging this well-established framework, it helps to provide realistic estimates, mitigate risks, and enhance the predictability of project outcomes.

Essentially, we develop a model team and estimate when each team member will start working, how much time they will spend on the project, and the sequence in which the results will be achieved. This gives us confidence that, with such a team and assumptions, the project can be completed within the given timeframe. Ultimately, this results in person-hours, which can then be translated into the project’s cost.​⬤

2. Then I rate (L/H/M and color-code for convenience) the requirements. I use three columns, Clarity, Complexity and Size.

2.1. I rate each requirement on a “Clarity” scale. “Clarity” assesses the ease of understanding the requirement based on the provided formulation. High clarity indicates the requirement is straightforward and well-documented or it is something standard. Low clarity means the requirement was not understood fully. Low/High/Med.

2.2. Next, I rate each requirement on a “Complexity” scale. “Complexity” measures the subjective difficulty of the requirement. High complexity means the requirement is intricate and challenging based on our past experience with similar topics. Low/High/Med.

2.3. Then, I rate each requirement on a “Size” scale. “Size” estimates the effort or time needed to work with the module. High size means it’s time-consuming to work with. Low size means it’s more manageable and requires less effort. Low/High/Med.

3. Finally, I distribute the obtained person-days (or/and cost) across all requirements, considering the “weight” of each requirement as determined by Clarity, Complexity, and Size. The lower the Clarity, and the higher the Complexity and Size, the more person-days are allocated to that requirement. If the clarity index is low for many important/urgent requirements, and crucial details are lacking, it’s better to either suggest a product discovery phase to gather the necessary data before committing to an estimate or propose to move forward with a purely agile approach, where planning is carried out on a sprint-by-sprint basis, adjusting for sprint velocity.

 

Conclusion

As you can see, these figures next to features or requirements are merely a formality to fit the required format, while the actual estimation is done through different means. Whether using WBS (Work Breakdown Structure) or leveraging experience from similar projects, we rely on established models and labor cost calculations to provide accurate estimates.

In the end, crafting a clear and detailed RFP is key to the success of any software development project. When you lay out your goals, deliverables, tasks, requirements, constraints, and priorities clearly, you pave the way for effective communication and collaboration with your development team. Using the right estimation techniques and having a shared understanding of the project’s scope and objectives lead to realistic timelines, better quality outcomes, and a successful project.

By looking at the RFP process from the developers’ perspective, you can better understand their challenges and workflows. This mutual understanding and respect create smoother project execution and happier teams on both sides. So, next time you’re putting together an RFP, remember: clear communication and detailed planning are your best allies for a successful partnership and project.