ROBIN HAVENS
PA 755: Information and Knowledge Management
IT RFP Project
12/16/2011
1
Introduction
There are many key factors that must come together in order to craft a high-quality public sector technology
request for proposal (RFP) document. In this project I will lay out my criteria for designing an effective
technology RFP and will use these criteria to critique four technology RFPs. First, I will describe each RFP
briefly. I will then describe my criteria, using a points-based approach for each section. Then I will assess each
RFP using the criteria and award points to the RFPs based on the criteria. Finally, I will make several global
recommendations for RFP writing best practices.
Descriptions of Selected RFPs
RFP #1: A Client Management Software System for Total Action Against Poverty (TAP)
TAP requested proposals for a client management software system to serve a human services agency
that has 35 programs, including programs focused on housing, domestic violence, employment and education
(Total Action Against Poverty, 2006). With more than 25,000 citizens living in poverty in this district, TAP
has a wide client base. The period of time from RFP release to implementation period was seven months.
RFP #2: Wireless Internet Services Onboard for Golden Gate Transit Buses
The Golden Gate Bus District (GGBD) requested proposals to install, operate and maintain internet
services (Wi-Fi) onboard 155 Golden Gate of their transit buses (Golden Gate Bridge, Highway and
Transportation District, 2010). The district requested that the operation and maintenance costs be supported by
the vendor through innovative solutions, such as advertising or user fees. The period of time from RFP release
to implementation period was nine months.
RFP #3: Employee Scheduling System for the City of Kent, Washington
The Kent Fire and Police Departments requested a proposal for new employee scheduling software
(City of Kent, Washington, 2008). The request included implementation, configuration, testing and training, as
well as ongoing maintenance and support. The system needed to be compatible with a legacy server and the
total RFP release to full implementation time was five months. Kent has 86,000 residents and 375 employees.
RFP #4: Permit and Tracking System for the City and County of San Francisco
The San Francisco City and County (CCSF) Departments of Building Inspection and Planning
requested a Commercial off the Shelf (COTS) software solution for seamlessly tracking permits and projects
2
(City and County of San Francisco, 2011). They requested that this initial, integrated solution be based on
open system architecture that could be expanded to other City departments, if successful. This system would
need to handle 66,000 permits per year and serve a staff of almost 400. The agencies were looking for full
implementation in 24 months.
My Criteria
Organization: RFP includes: 1) relevant sections (executive summary, table of contents, introduction,
background/context, statement of need, scope of project, project description and objectives, requirements of
the project/how the work should be conducted, quality assurance requirements/processes, assumptions, request
for vendor capacity and references, budget format, project schedule, evaluation criteria, liability information,
contact information) (White, 2007; Garton, 2008; Dominick, 2004), 2) relevant diagrams and examples when
necessary, 3) clear instructions (there are no misleading or illogical statements) (Gamble, 2004) 4) language
that is not overly-technical and avoids jargon, and 5) is well written and consistent with no grammatical errors
(Garton, 2008) – 10 Points
Equity, transparency, and accountability: The RFP 1) reduces the chances for work to be awarded
based on favoritism or prior/unethical relationships between the agency and vendor (White, 2007), 3)
encourages subcontracting with disadvantaged business enterprises (DBEs,) 4) has sufficient evaluation of the
vendor capacity (Garton, 2008; Gamble, 2004) – vendors that are unable to carry out the work are avoided, 5)
addresses accessibility requirements (Students of San Francisco State University Fall 2011 PA755 class,
2011)and 6) the deadlines could be reasonably met by both small and large vendors. -10 Points
Needs: The agency has clearly 1) done a strategic analysis to assess its needs and has identified a clear
problem to be addressed by the technology (White, 2007; Gamble, 2004), 2) requested a clear scope of
services, 3) has made it clear that the agency took end-user needs into account (Students of San Francisco
State University Fall 2011 PA755 class, 2011), 4) specified the flexibility that will be accepted from vendors,
and 5) held a bidders conference to further clarify proposal needs (White, 2007). – 10 Points
Technology: It is clear that 1) the RFP was written with substantial technological expertise (Reh,
2011; White, 2007), 2) the speed at which technology will go out of date is taken into account - the schedule
(of RFP process) does not cover such a long time period that the technology will most likely be out of date by
3
implementation (Students of San Francisco State University Fall 2011 PA755 class, 2011), 3) any
technological requirements are laid out, 4) the agency avoids requiring new technology approaches that will be
substantially constrained by legacy software/hardware compatibility requirements (Garton, 2008). – 10 Points
Innovation: The RFP 1) takes advantage of technology innovations that are inherently outside the
ability or expertise of the public sector (White, 2007), 2) has guidelines that are not overly prescriptive and,
thus, avoids constraining the ability of the vendor/contractor to create their proposal freely, 3) encourages a
proposal that leverages private-sector tested innovations to offer added value to public sector end-users
(White, 2007; Students of San Francisco State University Fall 2011 PA755 class, 2011). – 10 Points
Criteria for selection: Selection process 1) is clear, (Reh, 2011) 2) spells out any relevant procurement
laws, 3) avoids focusing exclusively on cost concerns and provides more criteria sections that allow for project
efficacy and equity, 4) requests a clear project plan from vendors, as well as a detailed implementation
description (Reh, 2011). – 10 Points
Critiques of Selected RFPs
RFP #1: A Client Management Software System for Total Action Against Poverty (TAP)
The TAP RFP did several things well, but suffered greatly from lack of a clear problem statement and
a tendency to be too prescriptive. Some of the things that it did well were: 1) took end-users into account by
laying out their specific needs and describing the agency mission, 2) had input from technology experts which
was clear in the specific requirements of the technical section and 3) laid out a project schedule of only seven
months from RFP release to project completion which should not allow the technology to become out of date
before implementation.
The TAP RFP was missing several key sections and criteria. Organization: The organization was poor
and was missing seven of my 15 required relevant sections, most notably the statement of need/scope of
project, project description/objectives, basic assumptions and budget. The instructions for proposal format
were not aligned with the requirements and criteria and it would be confusing for a vendor to write a clear
proposal (score: 4.5/10). Equity, transparency, accountability: The RFP addressed these requirements poorly
with a flat requirement that the vendor must have been in business for at least five years. There was no
mention of equity in process selection (avoidance of favoritism) or statement about accessibility requirements.
4
The 30-day deadline between RFP release and deadline could favor big companies with large staffs to meet
this short deadline (score: 2/10.)
Needs: This area was unclear with no statement of need or problem, with no explanation of what was
wrong with the previous software (Microsoft Access) (score: 2/10.) Technology: The requirements laid out in
the RFP were very specific, but so much so as to be prescriptive. There was also a requirement to be
compatible with legacy software, but those specifications were not described well (score: 8/10.) Innovation:
This RFP left no room for leveraging private sector technology and suggested that the technology be based on
IBM, Oracle or Microsoft Access software (score: 2/10). Criteria: And, finally, the criteria for proposal
writing were laid out in an 11-point list which did not describe weighting (score: 4/10.)
The potential repercussions for this RFP could be 1) poorly written proposals because lack of a clear
need/project objective that could lead to implementation hurdles, 2) potential for big businesses that work
frequently for the city to get the contract because of a lack of equity checks and support of small or minorityowned businesses, 3) a less-than-innovation technology approach because of a prescriptive RFP that does not
leverage private sector technology gains and 4) extra agency staff time to clarify proposal criteria and
requirements. There is a lot of need in this RFP for vendors to “read between the lines” and guess what the
agency is really looking for in their software which could devastating repercussions to the implementation
phase. Overall score: 26.5/60 = 44%
RFP #2: Wireless Internet Services Onboard for Golden Gate Transit Busses
This was a generally proficient RFP with especially well-done Technology and Criteria for Selection
sections. Technology: The hand of technological expertise was clear – the technological requirements are
spelled out specifically and the nine month time frame from RFP release to completion of implementation
should not allow for technology to go substantially out of date. No compatibility with legacy software is
required (score: 9/10.) Criteria for Selection: The selection process for this RFP was clear with relevant laws
spelled out and a points-based criterion for selection described. The implementation plan requirements were
especially clear (score: 10/10.)
Several sections contained inadequate, confusing or incomplete information. Organization: Some
important sections were missing, like an executive summary, statement of need, and full project schedule (only
5
partially listed). The RFP was consistent with no grammatical errors, but most of the technical information was
in the body of the request, leading to overly technical language and jargon that made for a hard read (score:
6/10). Equity, transparency and accountability: Clear efforts were made to avoid favoritism (a whole section
was on conflicts of interest and protests), but I had concerns about equity and accountability. There is
allowance for the vendor to charge customers for WiFi service, with no cost limits or accessibility for lowincome users. Also, the language about advertising content censorship is vague, potentially leaving the district
open to liability. There were only 40 days between the RFP release and the deadline for submissions, which
could favor large companies (score: 7.5/10.) Needs: This was my biggest area of concern because there was no
clear description of the problem or the end-users needs. The problem was described in one sentence and there
was no evidence of a strategic analysis. The level of flexibility to meet the needs was also unclear (score:
5/10.) Innovation: When first reading this RFP it seemed innovative, but upon further examination it is overly
prescriptive. The document “encourages approaches that describe creative and innovative approaches (Golden
Gate Bridge, Highway and Transportation District, 2010, p. 11)”, but then prescribes the requirements for most
possible business model choices, leaving little room for innovation. It does clearly leverage private sector
technological innovations, but crushes them with bureaucracy (score: 7.5/10)
Although the RFP was generally well-written, there were several areas that could lead to stumbling
blocks during the implementation phase. The lack of a clearly stated reasoning for the project need could lead
to problems with end-user satisfaction since they were not consulted early on. In addition, disorganization in
the RFP structure could lead to poorly written proposals that need high levels of clarification from district
staff. And finally, the overly-prescriptive proposed business model could create little room for a profit margin
and, thus, potential vendor failure. Overall score: 45/60 = 75%
RFP #3: Employee Scheduling System for the City of Kent, Washington
This RFP did several things well, including organization, describing agency needs and the technology
required. Organization: It is well-organized with all relevant sections (except an executive summary), is clearly
written in easy to read language and includes all relevant supporting documents. There were attachments that
extensively described liability (score: 9.5/10.) Needs: The agency needs were supported by a clear strategic
assessment of technology challenges and a need to increase efficiency and communication around scheduling.
6
End users were clearly taken into account. There was no bidders’ conference (score: 9/10.) Technology:
Technological requirements were written with substantial expertise and the short time from RFP release to full
implementation (five months) would allow for little technology deterioration. Unfortunately, the RFP states
clearly on the first page that all software must be compatible with legacy software (Microsoft SQL Server
2000 or newer) (score: 8/10.)
Several sections are missing key information, including equity/transparency/accountability, the
weighting of selection criteria or any reference to innovation. Equity, transparency, accountability: There is
little to no language in this RFP that reduced chances that the work would be awarded based on favoritism.
There was no encouragement of using disadvantaged business enterprises and little criteria for checking
vendor capacity. The RFP did not address accessibility requirements and the deadline of three weeks after RFP
release seems unreasonably short for a 53-page document (could favor large vendors) (score: 2/10.)
Innovation: Although innovation is clearly not the goal of this RFP (not mentioned once), it also does not take
advantage of private sector technology advances. It is prescriptive and shows little evidence of creativity
(score: 2/10) Criteria for section: Criteria for selection were listed and the selection process was clear, but the
weighting of criteria was unclear. An experienced vendor would probably read between the lines to see that the
agency wants proposals that are low-cost, functional and stable, but the agency is not clear in this area (score:
5/10.)
There could be several serious repercussions for the short fallings of this RFP. Its prescriptive
approach that did not leverage private sector innovation gains could lead to a low-performance product. The
vague, unweighted criteria for selection could lead to confusion in the selection process and, hence, selection
of a vendor who might not be the best candidate. The lack of language around equity, transparency and/or
accountability could lead to contract favoritism, selection of a vendor without sufficient capacity and/or
disadvantaged businesses being left out of the process. These serious repercussions could be very damaging to
project implementation. Total score: 36/60 = 60%
RFP #4: Permit and Tracking System for the City and County of San Francisco (CCSF)
The RFP for a Permit Tracking system for CCSF Planning and Department of Building Inspection
(DBI) was a well-written and clear set of documents. Organization: The RFP contained all the relevant
7
sections, attachments and forms and had especially clear introduction/executive summary, scope of project and
quality assurance sections. It was direct without being over-technical and avoided jargon (score 10/10.) Needs:
It was very clear that the agency has done their homework to assess their needs. The agency described their indepth analysis and Action Plan which took end-users into account throughout the process. There was a
mandatory bidder’s conference and the problem to be solved by the vendor was laid out in thorough, yet
succinct, detail (score: 10/10.) Criteria: Criteria for selection of the successful vendor was laid out in a multistage, weighted process that made the importance of various criteria clear. The mixture of written and
performance-based assessment was innovative and would help assure a strong candidate (score: 10/10.)
Few sections of this RFP were missing any criteria, but the sheer weight of some requirements may be
a turn-off for some potential vendors. Equity, transparency and accountability: This RFP demonstrated
genuine concern for equity and fairness by taking many steps to avoid favoritism in the selection process and
insuring that workers on the project will receive equitable pay, health insurance and that discrimination will be
avoided at all costs. The only drawback was the weight of all the requirements – it was hard to imagine
vendors who would want to spend the extra time and effort to comply with all of the requirements (score:
8/10.) Technology: The technology requirements were clear and specifically laid out. The only standout for
improvement here was the very long time frame for project implementation – more than 24 months! It is not
hard to imagine technology going out of date in this long timeframe (score: 8/10.) Innovation: This RFP took
bold steps to encourage innovative solutions by asking for suggestions beyond the scope of the project, but
could have been more innovative in asking vendors to seek out solutions that leverage private sector
innovations (score: 9/10).
Although there were few potential repercussions during implementation of this project since it is wellwritten and covers most bases, a few were are: 1) some vendors may be scared off by the extra time required
up front and throughout the implementation to comply with the extensive equity and transparency
requirements, 2) the long time period between the RFP announcement and implementation (24+ months) could
lead to implementation of software that is close to out of date and 3) the software implementation could be less
innovative than similar private sector software because of its government-based approach. Generally, this
strong RFP has a high likelihood for implementation success: Overall Score: 55/60 = 92%
8
Recommendations for Improvements
RFP #1: A Client Management Software System for Total Action Against Poverty (TAP)
The TAP RFP could be improved through 1) adding a more clear description of need (add a strategic
analysis), 2) adding extra language around equity to support disadvantaged business enterprises, 3) leveraging
private sector innovations through a less prescriptive RFP and 4) clarifying criteria weighting so that vendors
can have a more clear idea of which parts of the proposal are most important.
RFP #2: Wireless Internet Services Onboard for Golden Gate Transit Busses
The Golden Gate Transit District RFP could be improved by 1) adding clear reasoning for the project
(how did they determine the need?), 2) working to better organize the various RFP sections and 3) backing
away from such a prescriptive business model. Perhaps the agency needs to consider supporting some of the
operational cost of supplying WiFi to its customers instead of putting all operational costs on the vendor. A
less prescriptive approach, coupled with negotiations, could lead to innovation gains.
RFP #3: Employee Scheduling System for the City of Kent, Washington
The City of Kent RFP could be improved by 1) adding more language aimed at avoiding contract
favoritism, 2) requesting more innovative approaches to hopefully solicit a higher-quality and creative vendor,
3) adding weighting to the criteria for selection, and 4) asking more questions that would help assess vendor
capacity. This RFP could generally use more innovation focus and more language around equity, transparency
and accountability.
RFP #4: Permit and Tracking System for the City and County of San Francisco
This RFP received the highest score of all four RFPs and is extensive in areas where several other
RFPs fell short. The language around equity, transparency and accountability is extremely thorough, but could
be consolidated, perhaps in a table, to make the requirements more clear t and easy to navigate to vendors. The
extensive time period (two years) between RFP release and competition of implementation would certainly
allow for software to become out of date, so shorting this time period to 18 months maximum would be
advised. This RFP seems most likely to have the fewest implementation challenges because it is thorough,
well-written and organized.
9
References
City and County of San Francisco. (2011, January 14). Request for Proposals for permit and Tracking System.
Request for Proposals for permit and Tracking System . San Francisco, California: City and County of San
Francisco.
City of Kent, Washington. (2008, October 15). City of Kent: Employee Scheduling System Request for
Proposal. Employee Scheduling System Request for Proposal . Kent, Washington: City of Kent,
Washington.
Dominick, C. (2004). Critical Ingredients for a Good RFP. Retrieved 2011, from nextlevelpurchasing.com:
http://www.nextlevelpurchasing.com/articles/request-for-proposal-rfp.html
Gamble, R. H. (2004). Outsouring Essentials. Retrieved December 13, 2011, from outsourcing.com:
http://www.outsourcing.com/content.asp?page=01b/other/oe/q204/perfecting.html&nonav=true
Garton, C. (2008). Fundamentals of Technology Project Management. Lewisville: MC Press.
Golden Gate Bridge, Highway and Transportation District. (2010, November 9). Request for Proposals:
Wireless Internet Service Onboard Golden Gate Transit Buses. Wireless Internet Service Onboard Golden
Gate Transit Buses . San Francisco, California: Golden Gate Bridge, Highway and Transportation District.
Reh, F. J. (2011). How To Write An RFP. Retrieved December 13, 2011, from About.com:
http://management.about.com/od/money/ht/WriteRFP.htm
Students of San Francisco State University Fall 2011 PA755 class. (2011). iLearn. Retrieved December 12,
2011, from iLearn.sfsu.edu: https://ilearn.sfsu.edu/mod/forum/view.php?id=64180
Total Action Against Poverty. (2006, November 20). Total Action Against Poverty Request for Proposald Client
Management Software. Total Action Against Poverty Request for Proposald Client Management Software
. Roanoke, Virginia: Total Action Against Poverty.
White, J. D. (2007). Managing Information in the Public Sector. Armonl: M.E.Sharpe.