Illustration of person jumping over

Anyone can write a project proposal. But writing a winning proposal can be fraught with peril; a poorly composed proposal can cause confusion, misunderstandings, and ultimately an unsatisfied client. This could potentially leave a company in a worse position than if they had never bid at all.

Developing a good project proposal is also hard work. It requires time management skills and building a strong team that can expertly complete the work. The project team needs to understand and communicate clearly how they can support the client in achieving their goals. Preparing a good, strong proposal can:

  •  Minimize ambiguity at the onset of a project;

  • Ensure your team’s strengths align with the needs of the client; and

  • Help lead to a successful outcome and relationship with the client.

At CS, we want to help set our clients up for success and be good collaborators to the teaming partners we work with. We have extensive experience writing proposals for transportation software; here are a few of the “gotchas” we’ve learned to look out for through our years of work, both in terms of red flags in RFPs and mistakes that can be made in writing proposals. We’re also exploring alternatives to the classic large, monolithic proposal process and have some thoughts about our successes so far.

We hope sharing these lessons will provide our partners with best practices to harvest from and our clients with insights into how we think about their success before a project even starts.

Share the Vision

It’s easy to end up with a lackluster proposal. You may thoroughly cover the scope and emphasize what a perfect match your background is, but if you have no overall vision, or worse, your vision clashes with that of the client, then your proposal is going to get cast aside. Similarly, if you focus heavily on the technology to be used, but lose sight of the end goal, the client might just lose sight of your proposal. It’s helpful to have a clear statement of the desired accomplishments for the project somewhere prominent. Ideally this statement is derived from the RFP; it's a potential red flag on the RFP if you can’t find such a statement somewhere in it. 

From a similar perspective, it's easy when you’re on the outside looking in to make assumptions that don't match the realities of the client's needs. Any sort of view into the client can be helpful, whether through already established relationships or with due diligence in researching published information such as board meeting notes or agency websites. It’s critical that the work being proposed meets the client’s needs, goals, and mission. 

Find A Champion of the People 

Ideally, as part of the proposal process, you can identify a champion for the project. That is, someone at the client agency who has demonstrated a keen interest in the project, is willing and able to shepherd the project, and who has a clear vision of the end goal. However, don't forget that there are always multiple stakeholders for any project. A strong project champion will not only communicate their perspective but provide a shared vision from all the stakeholders.  

Focus on Diversity, Equity, Inclusion

Cambridge Systematics has a strong Diversity, Equity, and Inclusion focus, which we try to bring to our proposals. Many RFPs include Disadvantaged Business Enterprise (DBE)/Small Business Enterprise (SBE) requirements, but even if not mandated, we try to build supportive options into our proposals because greater diversity and a representative team can help lead to a better client outcome. One approach for including diversity in the proposal is to make sure to capture the important tasks that DBEs are contributing to, whether that be project management, software development and QA/QC, data collection, training, stakeholder engagement, or creation of promotional materials.

Read Carefully and Ask Questions

Sometimes RFPs can have contradictory language; read the requirements carefully. For example, if the scope summary emphasizes the need to use cutting edge technology, but the details emphasize the need for the technology to have been proven over an extended period. Similarly, the requirement for 10 years of experience for a technology that's only 5 years old, or the use of COTS software for a purpose that will clearly require a lot of customization. In this case, it's helpful to formally submit questions during the Q&A period to get clarification.

Proceed With Caution: No Exceptions

Be cautious of RFPs that don't allow consultants to take exceptions to contract terms, or worse, don’t allow them to even object. Traditional contract terms found in timeworn transportation agency boiler plate agreements are sometimes geared toward infrastructure projects, which historically are not appropriate for modern software procurements. This invariably increases the cost of the bid to protect against contract terms such as excessive liability or disallowing the use of open-source software. Further, if the terms disallow adding subcontractors, this prevents supporting greater diversity.

RFPs with many, many (100s of) requirements can preclude reasonable discovery and design phases. Often these requirements are either so specific that there is little choice but to adopt a waterfall approach, or they're so vague that it's hard to really be clear on what the client wants. Sometimes an RFP has both. The one time a large number of requirements might be a good sign is if the RFP came out of a precursor project focused on discovery and requirements gathering. 

There is Another Way: Provide Consultation and Be a Strategic Partner

We’ve been exploring alternatives to these large, monolithic proposals. Often clients can have a very general vision of the end game, but with few details on how to get from here to there. One approach is to suggest creating two procurements. The first RFP would be for discovery, requirements gathering, and possibly some initial design work. That then feeds into a follow-on RFP that’s more focused and achievable (but possibly still with 100s of requirements). 

Another approach is to engage around some prototype tool for a relatively short time. This is sort of a “try before you buy” or “pilot” concept. It leads to smaller RFPs or alternative proposal mechanisms and quicker turnaround times. However, given the focus around a specific tool, this approach has limited applicability, primarily to very technical projects, but allows for a creative approach with a smaller initial investment. CS has had significant success in converting pilot projects into more substantial work.

Learn More

Our goal at CS is to provide easy-to-use software platforms, practical solutions and quality services that help solve transportation’s most critical challenges. If you’d like to learn more about working with CS to solve your challenges, please contact Reagan Lynn at

About the Author

Scott Meeks has more than 30 years of software experience and has served as Architect, Technical Lead, and Principal Engineer on a wide variety of software projects for transportation agencies.