UPI Study › Courses › Project Management › Free lessons › Lesson 6.2 Free with a free account
Preparing a Request for Proposal: Process and Requirements
Project Management · Chapter 6: Developing and Evaluating Project ProposalsSection 6.2 · lesson 38 of 739 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Project Management.
Lesson complete
Earn the 3 college credits for Project Management
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Federal Contract Proposals: Frameworks and Guidelines →← Anatomy of a Project Proposal: Key Elements and GoalsNext lesson: Federal Contract Proposals: Frameworks and Guidelines →
In this lesson
Choosing and writing a fair, clear request for proposal.
- Choose between a request for information, request for quotation, and request for proposal
- Describe the components of an RFP and the steps from release to award
- Write specific, measurable, traceable requirements sorted into mandatory and desirable
- Identify ambiguity, hidden bias, unrealistic timelines, and conflicting requirements in a draft RFP
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,261 words). Read along, or search it.
Opening Question
Copying One System's Feature List
Lucia is the procurement lead at Linden Bay Recreation Department. She's preparing a request for a new facility booking system. Theo, the aquatics manager, saw a demonstration of one system and loved it. He asks her to write the requirements to match that system's features, right down to its calendar view. It would save everyone time, he says. Should she? Answering that means looking at the request from the buyer's side.
Purpose
Learn, Secure, and Record
Procurement is getting goods or services from an outside party. A buyer issues a solicitation, a formal invitation to respond, for three reasons. To learn: what's possible, who can supply it, and how others solved the same problem. To secure: a defined product or service, at a fair price, from a supplier chosen in a process others can see was fair. And to record. Writing the need down forces the buyer to say what it wants, and the document becomes the reference for judging offers, and later for the agreement.
Three Documents
RFI, RFQ, and RFP
Three documents serve those purposes. A request for information, an RFI, asks suppliers to describe what they could offer, with no price and no commitment. It's for learning, and nobody wins it. Because a respondent could steer the later requirement, the buyer treats all respondents alike, and doesn't copy one supplier's wording. A request for quotation, an RFQ, asks for a price on a clearly specified item. Every supplier would deliver essentially the same thing, so the lowest price that meets the specification usually wins. A request for proposal, an RFP, asks for an approach, a team and a price, and says offers will be judged on more than price. It's used when the way the work is done matters.
Choosing a Document
Three Questions Asked in Order
To choose, ask three questions in order. Does the buyer know what it needs well enough to describe it? If not, use an RFI. If it does, would every capable supplier deliver essentially the same thing, so the comparison is mostly price? Then an RFQ. If the need is known, but suppliers could meet it in different ways that matter, use an RFP. Twelve identical chairs to a model specification: an RFQ. A town that wants easier pothole reporting, but doesn't know whether an app or a phone line would work best: an RFI. The same town, once it has decided on a reporting system with stated features, wanting suppliers to propose how to build and run it: an RFP. The test in borderline cases is simple. Will the buyer compare more than price?
Quick Check
A Hospital Exploring Scheduling Tools
Quick check. A hospital wants to know what kinds of staff-scheduling tools exist, but it hasn't decided whether to buy any. Which document fits? Pause, and decide. An RFI. The hospital can't describe its need yet, so it needs to learn before it asks anyone for a price or a plan. An RFQ needs a fixed specification, and an RFP needs a known need. It has neither yet.
RFP Components
Statement of Work Versus Requirements
An RFP has a set of components. The background says who the buyer is and why it's asking. The statement of work describes the work: tasks, outputs, standards, place and period. The requirements are the conditions the solution or bidder must meet. The instructions set the rules: format, page limits, how to submit, how to ask questions, and the deadline. The evaluation criteria say what will be judged, and how much each matters. The timeline lists key dates to the award, and the terms describe the expected agreement. They must agree. If the criteria reward something the instructions never ask bidders to describe, nobody can score on it. Don't confuse the statement of work with the requirements. The contractor will run an online booking service for the season: that's work. It must show availability for a chosen facility: that's a requirement.
RFP Process
Equal Information Through Addenda
Then the process. The team drafts, and people who didn't draft it review it. The RFP is released to every potential bidder at once. A question period follows. An addendum is a numbered written change or clarification, sent to every bidder, which becomes part of the solicitation. Then the response deadline, evaluation, and the award. At its center is one rule: every bidder gets the same information. Answer every question for all bidders, without naming who asked, and issue an addendum whenever the requirement changes. Test the timeline. Release at week 4 and a deadline at week 9 gives bidders 5 weeks. An addendum at week 7 leaves 2. If that addendum slipped to week 8.5, only half a week would remain, and a careful buyer would extend the deadline.
Writing Requirements
Specific, Measurable, Traceable, Mandatory, Desirable
A good requirement is specific, measurable and traceable. The system must be fast is none of those. The system must show a facility's availability within 3 seconds, with 50 users connected. That's specific and measurable. The figures are illustrative. Sort requirements into two kinds. Mandatory, or must-have: miss it and the response is out. Desirable, or nice-to-have: it adds value, but missing it removes nobody. Handle many users becomes: support 50 staff and 200 members signed in at once. That's 250 simultaneous users to demonstrate. Reports must be good becomes a weekly facility-use report, traced to the statement of work. And a lot of experience becomes desirable: describe two similar systems you've operated. A requirement that traces to nothing should be questioned. That's where preferences and bias most often get in.
Common Defects
Ambiguity, Bias, Timelines, and Conflicts
Four defects recur. Ambiguity: wording two reasonable readers would read differently. Modern and user-friendly has no test. Hidden bias: wording that favors one supplier without saying so. The system must include the GridView calendar names one product's feature. Describe the function instead. An unrealistic timeline: proposals due 6 days after release, or a system live 4 weeks after award. Conflicting requirements: data must stay on the department's own servers, while the system is a hosted service run by the supplier. Both can't be true. A reviewer outside the drafting team finds them by reading. Restate each requirement, ask what the work needs, work the timeline backward, and compare requirements with each other.
Quick Check
Live by June First, Tested All June
Quick check. A draft says the system must be live by June first. Elsewhere, it says acceptance testing must run through all of June. Which defect is that? Pause, and decide. Conflicting requirements. A system can't be live on June first while it's still being tested all month, so bidders can't satisfy both. Each statement is clear on its own, so it isn't ambiguity, and neither one favors a supplier.
Back to Lucia
Turning Preferences Into Outcomes
Back to Lucia and Theo. She decides not to copy the feature list. Requirements shaped around one product would shut other suppliers out, or score them down for differences that don't matter. Competition narrows, and a better or cheaper approach is lost. An excluded supplier could fairly complain the result was decided in advance. So she asks Theo what he valued in the demonstration, and turns each answer into an outcome. Staff should be able to move a booking between facilities in no more than two steps, as a desirable item. She also asks everyone who saw a demonstration to say so in writing, before reviewing the draft. It costs about two extra weeks, with the pool season coming. Theo's favorite can still win, on its merits, and the result is easier to defend to the public body funding it.
Key Takeaways
Documents, Fairness, and Good Requirements
To recap. An RFI learns, an RFQ prices a clear specification, and an RFP compares approaches, not just prices. An RFP's components must agree with one another. Every bidder gets the same information, through addenda. And requirements are specific, measurable and traceable, sorted into must and should, and reviewed for bias by an outsider.
About Project Management at UPI Study
Project Management (Business 230) is a self-paced online course of 73 video lessons in 12 chapters, from starting and defining a project to planning, budgets, scheduling tools, proposals, contracts, execution, monitoring, closure, teams and certification. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Business courses Every course with PRO →
Why take it here
Why students take Project Management with UPI Study
Where the credit goes
Universities that work with NCCRS
Project Management carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Preparing a Request for Proposal: Process and Requirements
When should a buyer use an RFI, an RFQ, or an RFP?
What is the difference between a statement of work and requirements in an RFP?
How do you write good requirements for a request for proposal?
What is an addendum in the RFP process?
About the Project Management course
How many college credits is Project Management?
How much does Project Management cost and what is included?
Which universities accept UPI Study credits?
How long does Project Management take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Project Management.
73 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →