Requests for Proposals
as a First Step to
Successful Project Management:
A Detailed Analysis of Three RFPs
Matthew A. Poland
PA 755
December 19, 2011
Introduction
Requests for Proposals, or RFPs, are an integral beginning to project management for the complex
information and communications technology (ICT) needs of a public non-profit agency. Well-written
RFPs thoroughly describe what services or products an agency needs from an outside party, technical
details of existing systems, how the bidding process will work and contractual guidelines as well as other
details a company would need to know in submitting a proposal. A well-written RFP is a good start to a
successful partnership with a vendor and customer agency and will help with ensuring sound
management of the project from start to finish. Here, three different RFPs that request implementation
of specific software solutions are analyzed in detail through objective criteria. First, strengths and
weaknesses of each are detailed along with the implications for project implementation and
management of the proposed projects. A cross-comparison of the three RFPs is also presented. Finally,
recommendations are made for improving each RFP.
Criteria for Analysis
Essentially, if an RFP is not well-written, it will run the risk of not getting the agency what it needs and
potentially also squander the time and resources of outside parties submitting proposals. “If it (an RFP)
is not done correctly, it can produce no bids or bids that are a waste of your time.” (Reh, n.d.).
Therefore, it is important to know what you need, what your current structure and resources are and
how the solution might look as well as be able to convey this information clearly to outside parties. To
establish an objective set of criteria to analyze each RFP, the basic components that will be expected are
borrowed from Garton & McCulloch (2006, p. 40): 1) Executive Summary, 2) Description of Problem and
Proposed Solution, 3) Key Business and Technical Requirements, 4) Project Phases and Milestones
(Schedule), 5) Quality Assurance Requirements, 6) Budget, 7) Proposal Template (or outline). In addition
to assessing the presence and quality of each of these sections, additional criteria will include whether
or not the proposal invites collaborative problem solving as suggested by Gamble (2004) and
information on how proposals will be evaluated (Reh, n.d.).
1
RFP Analysis #1 – City and County of San Francisco
The first RFP to be analyzed was issued by the City and County of San Francisco’s (CCSF) Department of
Public Works (DPW) for “Web-Based Utility Project Coordination Software” (CCSF, 2011). This RFP seeks
to acquire a software solution to track utility projects throughout the city, using GIS, making it accessible
by multiple City departments as well as the public. The proposed solution will be able to ensure that
there are not construction conflicts, ensure joint construction opportunities are maximized and use
public right-of-way (PROW) event tracking (CCSF, 2011).
Strengths In this RFP, the Introduction section serves as the executive summary; although eight pages
long, it clearly outlines the scope of the proposals sought. The needs for utility project management
software are described and the specific goals to be met by a solution are described. The business and
technical requirements are also very specific as the RFP contains several appendices that cover software
requirements, DPW report requirements, emails that need to be generated from the system to staff,
and data exchange requirements (CCSF, 2011). The RFP contains diagrams for how utility projects
within the DPW are planned and carried out, the language used, etc., making an understanding of the
department’s needs easier to grasp.
The RFP also makes the evaluation process for proposals very clear with a simple scoring system based
on seven weighted categories – Functionality, Support, Integration, Compatibility, Implementation /
Staffing, Prior Experience and Corporate History / Stability (CCSF, 2011). The timeline of the RFP process
is well-articulated and a detailed outline of what a proposal should include is provided.
Weaknesses The first issue is that the problem DPW is looking to solve is not quite described, only the
solution sought. It simply mentions that they are looking for an “enhanced” system over the one they
have currently, which may make it difficult for a potential vendor to provide the best solution. Another
issue is that the project timeline is oversimplified and milestones or phases of implementation are not
identified. CCSF only notes that they expect the system to be fully operational within three months
after the contract begins, then 30 days of training and all agencies using the software within 60 days
2
(CCSF, 2011). It does not offer a clear path for how the software will be implemented. Other missing
pieces include a budget (although it asks for a “fee proposal” separate from the project proposal) and
what quality assurance the project implementation should include. Finally, the RFP seems to only invite
solutions that are on paper and not collaborative in nature.
Implications for Project Implementation and Management First of all, despite the level of detail
offered in the RFP, a vendor may not have a full understanding of the needs without some discussion
after the proposal is made. This may lead to the wrong vendor being selected who writes the best first
proposal on paper and is just a great salesperson that can’t actually deliver – a possible outcome from
Lomanism (Stowers, 2011). Additionally, the lack of a detailed project timeline may lead to a project
that is rushed in order to meet the unexplained deadlines. Lastly, not having a budget in the RFP makes
providing estimates difficult and the proposals made could be way off the mark. Since a fairly tight
timeline is expected, this may require a lot of resources spent in a small amount of time. The
combination of no project timeline and no budget would make planning very difficult. However, the
clear outline for a proposal and plethora of technical detail balances this a bit and makes it more likely
to lead to a thorough project proposal, which is key to successful project management (Garton &
McCulloch, 2006). Recommendations for improvement to this RFP are reviewed later in this paper,
following discussion of the other two RFPs.
RFP Analysis #2 – Kirkland Police Department et al.
The second analysis for this paper was conducted on an RFP issued jointly by the police departments of
Kirkland, Bothell, Medina, Lake Forest, Clyde Hill and Bellevue – all neighboring cities in King County,
WA. The RFP is seeking proposals for public safety software that will be used jointly by all six cities and
will primarily provide computer-aided dispatch (CAD), mobile reporting and records management for
the six police departments who already share certain public safety services (City of Kirkland et al., 2002).
Additional requirements and current software of the respective cities are covered in the RFP and the
3
authors note that a single vendor is desired to meet all of the needs although they acknowledge that
this outcome may not be feasible (City of Kirkland et al., 2002).
Strengths The Cities in this RFP provide a very detailed picture of what they are looking for. They have
an executive summary, more or less, which describes the overall project and the RFP does clearly outline
the problems each city has with their current system(s). The background on each city provides a lot of
information on what each city’s needs are for the proposed solution. In addition, the priority items for
the overall system are articulated. This RFP is also very lucid on what is seen as the proposed solution in
an overarching public safety system; albeit lacking detail on how the systems will be interconnected.
The business and technical requirements are listed in detail, including sections on the General System
Requirements, CAD, Connectivity to ACCESS (system for accessing state and national crime databases),
Police Records Management System, Field Report Writing, Crime Analysis and several other areas. They
note that proposed solutions can include a system for Fire Records, but that the Cities will most likely
continue to use the existing system (City of Kirkland et al., 2002). A potential vendor would most likely
feel well informed on the requirements from reading this RFP.
The RFP also clearly identifies the project phases and the criteria that will be used to select a vendor.
Instead of a scoring system, such as used by CCSF (2011), they provide a list of selection criteria
including the priorities in the solution for the Cities. Overall, the RFP is very complete, also including a
very detailed proposal template (not just an outline) with a large number of questions to be answered
by the proposer.
Weaknesses While this RFP seems very complete overall, the City of Kirkland et al. (2002) RFP does not
specify what quality assurance they will require for the project. This could make it difficult for a vendor
to plan for how to budget for ensuring quality in the technical implementation. In addition, there is no
overall budget guidelines in this RFP – instead the RFP indicates that costs need to be included in the
proposal but the budget will be negotiated once potential vendors are identified. Without budget
guidelines, proposers may not be able to provide reasonable cost estimates.
4
Implications for Project Implementation and Management While overall this is a well written and
thorough RFP, it appears to be an extremely complex project; multiple cities with a swath of different
systems at varying levels of complexity are requesting a system to unite them all. McNabb (2007)
documents many examples of failed IT projects for a number of reasons, one of them being complexity.
With six different municipalities, six different governance structures and all with their own (mostly)
independent IT systems, this project seems to have a high likelihood of failure.
On the other hand, this RFP seems to have some room for collaborative problem solving. The Cities ask
for demonstrations and discussions from two or more vendors as part of the RFP process. This could
lead to better solutions than if the Cities were simply to make decisions from solutions presented on
paper alone. Again, recommendations for improving this and the other two RFPs will be presented at
the end.
RFP Analysis #3 – Total Action Against Poverty (TAP)
This RFP is seeking client management software for Total Action Against Poverty (TAP), a community
action agency with a number of social services provided in Virginia. Among other things, TAP wishes the
new software to determine client eligibility, store intake information, track clients, assist with case
management and generate various reports (TAP, 2006). This would be an upgrade from their current
system based in Access.
Strengths Although relatively few, this RFP has some strengths. The RFP lists the business needs for the
client management software and requirements that need to be met. There is a very clear description of
the various services provided by TAP and the ways the software will be used. In addition, the RFP has
the criteria by which the proposals will be judged and an outline for items that should be included in the
proposal. Finally, it has a schedule for the RFP process and very simple project timeline. These are all
things that help a potential proposer get an understanding of the needs.
Weaknesses Unfortunately, the weaknesses of this RFP far outweigh the strengths. It is lacking in
almost all of the critical RFP criteria set forth in the beginning of this paper including an executive
5
summary, problem and proposed solution, project phases, budget and quality assurance requirements.
While the business requirements are spelled out, any technical detail is grossly lacking. Even the
business requirements seem to just be a vague and disorganized list of what will be tracked or inputted
to the system, almost in a raw, brainstormed fashion. The reporting is the only thing described as what
the system is expected to produce.
Implications for Project Implementation and Management Obviously, the long list of weaknesses
would make for a tenuous project without further discussion and guidance on the project. This does
appear to be a relatively simple project though and a company providing standard client management
software may not need more detail than what is already provided. Furthermore, the RFP does call for
product demonstrations, which could lend itself to discussion and perhaps collaborative problemsolving. On its own, however, this RFP is not well-aligned with a successful proposal and project.
Cross-Comparison of all Three RFPs
While the strongest RFP based on the criteria set forth was written by the City of Kirkland et al. (2002),
the CCSF RFP (2011) was also strong and the TAP RFP was a distant 3rd. The CCSF RFP did not contain
evidence that the City planned to collaboratively solve the problem as suggested by Gamble (2004)
while the City of Kirkland did. An advantage the CCSF proposal had over the City of Kirkland was a much
more straightforward scoring system for proposals; ensuring fairness of the process is an important
aspect for government agencies in particular. In comparison to the other two, the TAP RFP lacked a lot
of detail and information about the problem and proposed solution. However, both the CCSF and TAP
RFPs seemed to have a higher likelihood of resulting in a successful project than the City of Kirkland RFP.
The length of the RFP proved to be an indicator of its strength – both the CCSF and City of Kirkland RFPs
were over 40 pages while the TAP RFP was a sparsely used 12 pages. Some of these pages in the longer
RFPs were used to discuss contractual requirements for the government agencies, which would not be
relevant to the TAP organization. Overall though, it seems that in order to provide enough detail to
solicit successful proposals, a certain volume of information about the scope of the project is needed in
6
the RFP. While the longer RFPs likely make writing proposals more difficult and time-consuming for
vendors, the RFP process and issuing entity most likely benefits as a result.
One critical element that was missing from all three RFPs was a budget. While they all asked for vendors
to submit cost estimates, there was no concept of available budget given in the RFPs, which could lead
to proposals that are way off the mark financially. While the CCSF RFP made it clear that the cost
estimate was considered separately from the proposal itself, the other two gave no indication how the
cost estimate would play into the initial decision making. They only mention that the costs will be
negotiated with the vendors with the best proposals.
Recommendations for Improvement
City and County of San Francisco – The Department of Public Works would likely find a better solution
for its needs if more about the problem was described in the RFP and more of a collaborative problemsolving process was offered. Perhaps if the top three scoring proposals were invited to present and
discuss their solution, it would enhance the RFP process and lead to a smoother project implementation
phase. In addition, if an estimated budget was provided by CCSF, it would give vendors an idea of how
to budget their costs in their proposals, saving time and energy for both sides. Finally, the RFP contains
little about the planned phases of the project and more detail on this would help vendors better
understand the constructs under which they would be working.
City of Kirkland et al. – This RFP could benefit from several changes – primarily a simplification of the
project itself. Six cities with different needs and structure looking for a joint system to be installed in
every location simultaneously makes for a massive project scope and is bound for failure. Instead, one
of the bigger cities such as Kirkland or Bellevue should implement the system first and add each city one
at a time, in phases. This way, the project can be broken into logical and achievable steps. With six
cities dictating the requirements of one project, “requirements creep” – constantly changing demands
of the project, is bound to sink the entire ship. In addition, more detail on quality assurance and a
budget should be included in order to help proposers make accurate cost estimates.
7
Total Action Against Poverty – TAP’s RFP seems to be missing a lot of detail and could benefit from not
only a more complete description of their technical needs, but also better organization of the business
needs. A project timeline or description of the phases would make the schedule more clear as well. Like
the others, it also needs to give an idea of the budget involved.
All – An easy way to not only manage proposals, but also to provide a template for their content and
organization is to use an online portal for submission of proposals such as Total Grant Solution
(Tekmeca, 2011). This site and others like it allow agencies to provide the template for an RFP, require
answers for certain questions/sections and have built-in cost calculators for budgeting. It can make the
RFP process more efficient and transparent.
Conclusions
Because two of the RFPs analyzed here were from public agencies and the other from a non-profit, they
may not be directly comparable. However, some common key elements to RFPs were missing from all
of them such as budgets and project phases. In addition, TAP’s RFP suffered from an overall lack of
detail, which is not conducive to project management despite the seemingly simple nature of the
project. Even the more detailed public agency RFPs stand to benefit from improved RFP processes and
simplified project scope. Whether from a non-profit, for-profit or public agency, a well-written RFP is
the first step in successful project management in partnership with an outside vendor.
8
References:
City and County of San Francisco. (2011). Request for Proposals For a Web-Based Utility Project
Coordination Software. Retrieved December 16, 2011 from
http://bsm.sfdpw.org/ebd/5yearplanrfp/RFP5YearPlan3-31-11.pdf
City of Kirkland, et al. (2002). Request for Proposal for the Purchase of Comprehensive Public Safety
Software Including Computer-Aided Dispatch, Mobile Reporting, Records Management and Related
Modules. Retrieved December 16, 2011 from https://ilearn.sfsu.edu/course/view.php?id=3007
Garton , C. & McCulloch, E. (2006). Fundamentals of Technology Project Management. Lewisville: MC
Press.
McNabb, D.E. (2007). Knowledge Management in the Public Sector: A Blueprint for Innovation in
Government. New York: M.E. Sharpe, Inc.
Gamble, R.H. (2004). Outsourcing Essential: Perfecting the RFP. Retrieved December 17, 2011 from
http://www.outsourcing.com/content.asp?page=01b/other/oe/q204/perfecting.html&nonav=true
Reh, F. J. (n.d.). How to Write an RFP. Retrieved December 17, 2011 from
http://management.about.com/od/money/ht/WriteRFP.htm
Stowers, G. (2011). Introduction to Project Management. (PowerPoint presentation). San Francisco State
University: San Francisco, CA.
Total Action Against Poverty. (2006). Total Action Against Poverty Request for Proposals Client
Management Software. Retrieved December 16, 2011 from
https://ilearn.sfsu.edu/course/view.php?id=3007
Tekmeca, Inc. (2010). Total Grant Solution. Retrieved December 17, 2011 from
http://www.totalgrantsolution.org/
9