At this point, you will need to enter the whacky world of the three-letter acronym (TLA). You will find a whole host of TLAs in general use in the technology industry and a boatload more that are unique to individual companies. No matter where you work, you are going to have to learn a certain amount of techspeak (if you have not done so already). 

By Colleen Garton and Erika McCulloch

Editor's Note: This article is excerpted from chapter 3 of Fundamentals of Technology Project Management, by Colleen Garton and Erika McCulloch.

If you are working with outside companies, either as the client or as the vendor, you will experience their unique acronyms and technical (and sometimes not so technical) terms that are in common use. Initially, you will wonder what on earth everyone is talking about. You will gradually begin to understand this new language. Then one day you will hear yourself talking and realize that you have finally become proficient in the TLA dialect of the company for which you are working. Don’t be fooled into believing that everyone understands what all the TLAs mean. Some people are too embarrassed to ask, so they just pretend that they understand. Don’t be embarrassed about asking the meaning of terms used. If someone uses an acronym or a term you are not familiar with, ask them what it stands for or what it means. You may see a look of relief on more than one other face in the room when you get the answer. Some people just make up their own acronyms, and often they are the only person who understands their meaning. It is a rather amusing trick that engineers like to play on management. They make up a new TLA to confuse the other team members, and they wait to see how long it takes until someone asks what it means. Who said that engineers do not have a sense of humor?!

Companies who are looking either to outsource a project or to procure software/ hardware from an outside vendor generally use Request for Information (RFI), Request for Proposal (RFP), and Request for Quotation (RFQ) Documents. It is possible, though not very common, that some companies will also use these documents for internal projects.

As a project manager, you may never write an RFQ, RFI, or RFP. The chances are that at some point in your career, you will be involved in some capacity in responding to, or supplying information to someone else in your company who is responding to, an RFI or an RFP. For internal projects, the Project Proposal will be written based on the Project Concept; therefore, an RFI, RFP, and RFQ may not be required at all.

Even if you never have to write any of these documents, it is important that you understand what they are and the importance that they have to the initiation and approval of projects.

Request for Quote (RFQ)

An RFQ is used for requesting an exact quote for a specific service or an item of software or hardware.

RFQs are commonly used for ordering development equipment and tools. In smaller companies, or those that are decentralized, you may be required to complete and submit the RFQs yourself. Alternatively, your company may have a procurement department or an administrative assistant who will take care of requesting quotes on your behalf. In either case, you will need to supply the necessary information to whoever is submitting the request to ensure that the quote you receive is to the correct specification.

An RFQ is a much more straightforward request than an RFI or RFP. It is used to request a quote for a specific standard product or service. For example, you may need to purchase ten development systems for your project engineers for which you have a specific set of hardware and software requirements. The vendor, in this case, should easily be able to respond quickly with an exact quotation of the cost for each system. RFQs are used for getting quotations for off-the-shelf products such as consumer software products or desktop computer systems.

An RFQ template is included in the download file for this book.

Request for Information (RFI)

An RFI is used to garner information for a project before sending out an RFP. Some examples of the information requests you may see in an RFI appear below:

• Verify the assumption that the software can be designed to interface with the accounting system that your company
• Ascertain whether the software can be developed to run on multiple
• Find out whether the company has a UNIX®development environment.
• Find out whether their engineers have the necessary security clearance required for working on special government
• How large is the development team?
• Can X component interface directly with Y component?
• What is the cost of X part?
• What is the approximate time to develop X component?

The information gathered from the RFI can help the submitter whittle down the vendor list to a more manageable number before sending out the RFP. For example, the RFI may be sent out to twenty-five companies, and the RFP may go out to only ten of those companies. Alternatively, the RFI might be used to gather information as input into a Project Concept.

The RFI is also commonly used as a sanity check for budget, timelines, and technical requirements, which will enable the author to create a more realistic and comprehensive RFP.

An RFI template is included in the download file for this book.

Request for Proposal (RFP)

An RFP is a request sent out to a company (or companies) asking them to submit a proposal to develop a project as defined in the RFP.

The purpose of an RFP is to elicit high-quality and reasonable proposals. The proposals will be based on the information and requirements provided in the RFP, so it is imperative that this document contains accurate and detailed requirements.

In an ideal world, the RFP will serve as the foundation for building a successful and mutually beneficial working relationship between the client and the vendor(s). Projects can be challenging, problematic, and expensive, so it is important that these early communications between the companies are an effective model for future communications.

It is very important not to underestimate the difficulty in creating a written document that expresses clearly what it is that the company is trying to achieve. Bear in mind that the person receiving the RFP may have no previous knowledge of the requester’s company or products. Therefore, terminology needs to be explained and not left open to interpretation. The company sending out the RFP may not be clear on what exactly it is that they need, in which case the RFP may focus on the problem rather than on the desired solution. No matter whether the solution is predefined or not, the RFP must be clear, concise, and free of ambiguity. The “must have’s” must be clearly distinguishable from the “nice to have’s” and the “icing on the cake’s.” The focus should be on what needs to be achieved rather than how it needs to be achieved. If the how is critical to the project, it should be clearly stated (for example, if some or all areas of the project require that engineers have security clearance, if the solution must integrate seamlessly with existing systems, or if the solution must be written in a specific programming language). If a how is not critical to the success of the project but is desirable, it should be listed as a nice to have, leaving the door open for the vendor to propose alternative solutions.

The information contained in an RFP will vary depending on the type of project. In addition to a detailed description of the company, the project, the market space, the end user, the project goal, detailed project requirements, and the budget range, it should contain a high-level schedule of events. For example:

• March 1st Requests for Information (RFIs) sent out
• March 12th RFI Information due
• March 15th Short list of selected vendors
• March 23rd Request for Proposals (RFPs) sent to selected vendors
• April 20th RFP Proposals due
• April 23rd Project contract awarded to selected vendor
• April 24th Purchase order for project issued
• April 26th Project Charter meeting
• May 21st Marketing Requirements Document (MRD) due
• May 24th Kickoff Meeting
• May 27th Project Plan due
• June 4th Development begins
• September 6th Phase one complete
• October 4th Phase two complete
• December 15th Phase three complete
• January 20th Project end date

The RFP will contain information about the Project Concept and will ask for specific information that will constitute the proposal. The information requested will differ depending on the type and size of the project. The vendors must respond to the RFP with a proposal by the specified deadline to be considered for the project.

The most important thing to remember about RFPs is that they need to be realistic, as do the proposals submitted in response to them. You cannot expect to get a $100 million project developed for less than $500,000. Similarly, you cannot submit a proposal for $100 million for a project with a budget of only $500,000. Requirements and proposals need to be in line with the budget range. If your requirements are unrealistic, the vendors who receive the RFPs will not respond. This is why it is important to use an RFI to confirm and verify assumptions, facts, and figures before creating and sending out an RFP to multiple vendors.

Sometimes companies will pay vendors to write proposals for large projects. It can take a significant amount of time to respond to an RFP, and if many companies are bidding on the same project, the chances of winning the contract may be rather slim. The cost of responding to an RFP for a large project can be high. Hours or weeks of work may be required to complete it. These factors can discourage some vendors from submitting proposals, especially if they believe that the company is using the proposals only for comparison and already has a vendor of choice. To get around this problem, some companies will offer to pay a fee to help cover the costs of preparing the proposal.

The RFP will include, but is not limited to:

• An executive summary of the client’s company and market space
• A description of the problem and/or proposed solution
• Key business and technical requirements
• Proposed project phases and milestones
• Quality assurance requirements
• Budget
• Schedule of events
• Proposal template

An RFP template is included in the download file for this book.

What do you do if you are asked to respond to an RFP? Imagine that you receive an RFP from a client and are unsure why a particular requirement is required. The requirement does not make sense to you, which leads you to the assumption that perhaps the person who wrote the RFP did not really know what they were asking for. The company who sent you the RFP may not take inquiries from vendors, especially if they sent it out to many companies. If the RFP is not clear and you believe there is a better solution, offer it as a second alternative in the proposal that you submit. Do not automatically assume that the client is wrong and they do not need what they asked for. They may not have explained very clearly why a specific requirement is important, but that does not mean that you can ignore it. Respond to the requirements that they gave and offer alternatives where it seems appropriate. This way you are covering all your bases. If you fail to respond to the specific requirements, they may put your proposal aside, assuming that you are unable to meet the requirements. They are not likely to contact you to ask why you proposed a different solution if other vendors were able to offer solutions that met the specified requirements. You need to get the proposal right the first time as it may be the only opportunity you will get. A good-faith attempt to offer alternative solutions, especially ones that will save the client money, will be appreciated even if the alternatives turn out to not meet the requirements. The client will feel that you have their best interests at heart and that you are focused on the most cost-effective solution rather than on how to make as much money as you can. You are demonstrating integrity and a commitment to the potential client to read between the lines and to make the best possible recommendation that you can.

Next time - The Project Proposal Document. Want to learn more about project management best practices now?  Pick up your own copy of Fundamentals of Technology Project Management, by Colleen Garton and Erika McCulloch - available and on sale at the MC Press Bookstore today!

Colleen Garton

• Email
• Site

Colleen Garton is a highly respected and experienced writer, consultant, and speaker. She is the author of two management books: Fundamentals of Technology Project Management and Managing Without Walls. Recognized internationally as an expert on virtual and global management, Colleen is an experienced and in-demand public speaker for numerous events and conferences around the world. She is also author of the blog Working With or Without Walls.

 Colleen has extensive management and training experience in the United States and internationally, with more than two decades of practical experience in traditional and virtual management spanning multiple industries. She is the owner of the Garton Consulting Group. Before founding the Garton Consulting Group, Ms. Garton held senior management positions at some major U.S. corporations.

You can follow Colleen on Twitter at @ColleenGarton and on Facebook.

---

MC Press books written by Colleen Garton available now on the MC Press Bookstore.

		Fundamentals of Technology Project Management Master the specific project management issues that technology professionals must face. List Price $69.95 Now On Sale
		Managing Without Walls Optimize the effectiveness of your teams...no matter where they are. List Price $37.95 Now On Sale