<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: You say toMAYto, I say toMAH to?</title>
	<atom:link href="http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/</link>
	<description>Jon and B.J.&#039;s Proposal Blog</description>
	<lastBuildDate>Tue, 17 Jan 2012 20:30:46 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jon</title>
		<link>http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/comment-page-1/#comment-512</link>
		<dc:creator>Jon</dc:creator>
		<pubDate>Tue, 14 Aug 2007 12:53:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/#comment-512</guid>
		<description>Connie - oh, how I understand the shortcomings of client RFPs: I spend a fair amount of time working with procurement folks helping them to reconsider the way in which they engage with their bidders, in terms both of the quality of the RFPs and their overall process. It&#039;s amazing to watch the light bulbs switch on above their heads when they realise some of the oh-so-common errors they make, which result in them receiving poorer solutions and proposals from the supply market than is necessary.

In my experience, the scenario of &quot;repeated questions&quot; tends (often) to result from the buyer&#039;s RFP being a collation of separate sections, each authored by separate stakeholder areas. Each area of expertise throws in their own list of issues, in relation to the areas of the solution that they would evaluate and - ultimately - own. And the same core concerns may well come up more than once for different groups. So while the words of the question are the same, it&#039;s not necessarily the case that it&#039;s precisely the &quot;same question&quot; being asked in terms of the information that they hope to get back. 

As an example: &quot;Describe your Quality Assurance procedures&quot; in the opening section may beg an answer discussing your overall approach and certifications. The same question in the section on &quot;Technical Solution&quot; cries out for an answer with examples showing QA in action for the bidder&#039;s products/services. The third time it appears under &quot;Services&quot;, the answer needs a flavour of quality assurance as it applies to taking and handling calls, support processes etc.

It then becomes a fine line for the proposal team to determine how much to cross-reference between answers (especially if the document is being physically split up for evaluation).

It also amazes me how few procurement teams have a decent process in place for RFP development. After all, their challenges - presenting an opportunity to bidders, collating information from different internal stakeholders, trying to present this in a coherent and professional document, working to often tight timescales - is not dissimilar to those that we proposal folks face process-wise in responding.</description>
		<content:encoded><![CDATA[<p>Connie &#8211; oh, how I understand the shortcomings of client RFPs: I spend a fair amount of time working with procurement folks helping them to reconsider the way in which they engage with their bidders, in terms both of the quality of the RFPs and their overall process. It&#8217;s amazing to watch the light bulbs switch on above their heads when they realise some of the oh-so-common errors they make, which result in them receiving poorer solutions and proposals from the supply market than is necessary.</p>
<p>In my experience, the scenario of &#8220;repeated questions&#8221; tends (often) to result from the buyer&#8217;s RFP being a collation of separate sections, each authored by separate stakeholder areas. Each area of expertise throws in their own list of issues, in relation to the areas of the solution that they would evaluate and &#8211; ultimately &#8211; own. And the same core concerns may well come up more than once for different groups. So while the words of the question are the same, it&#8217;s not necessarily the case that it&#8217;s precisely the &#8220;same question&#8221; being asked in terms of the information that they hope to get back. </p>
<p>As an example: &#8220;Describe your Quality Assurance procedures&#8221; in the opening section may beg an answer discussing your overall approach and certifications. The same question in the section on &#8220;Technical Solution&#8221; cries out for an answer with examples showing QA in action for the bidder&#8217;s products/services. The third time it appears under &#8220;Services&#8221;, the answer needs a flavour of quality assurance as it applies to taking and handling calls, support processes etc.</p>
<p>It then becomes a fine line for the proposal team to determine how much to cross-reference between answers (especially if the document is being physically split up for evaluation).</p>
<p>It also amazes me how few procurement teams have a decent process in place for RFP development. After all, their challenges &#8211; presenting an opportunity to bidders, collating information from different internal stakeholders, trying to present this in a coherent and professional document, working to often tight timescales &#8211; is not dissimilar to those that we proposal folks face process-wise in responding.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jen</title>
		<link>http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/comment-page-1/#comment-510</link>
		<dc:creator>Jen</dc:creator>
		<pubDate>Tue, 14 Aug 2007 09:08:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/#comment-510</guid>
		<description>If we were not sure what the client preferred, then I think a good guide can be stolen from New Media best practice (web writing) - write one to ten in words, then 11 onwards in numbers. 

However, ultimately I would suggest offering the client thirty (30) instead. This may swing the deal.</description>
		<content:encoded><![CDATA[<p>If we were not sure what the client preferred, then I think a good guide can be stolen from New Media best practice (web writing) &#8211; write one to ten in words, then 11 onwards in numbers. </p>
<p>However, ultimately I would suggest offering the client thirty (30) instead. This may swing the deal.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lesa C</title>
		<link>http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/comment-page-1/#comment-509</link>
		<dc:creator>Lesa C</dc:creator>
		<pubDate>Tue, 14 Aug 2007 00:40:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/#comment-509</guid>
		<description>I agree with Jon that it&#039;s probably a hold-over from too much stuffy contract language only a lawyer could appreciate. There&#039;s no real need to say it twice, once grammatically and again numerically.

2 more cents!  : )</description>
		<content:encoded><![CDATA[<p>I agree with Jon that it&#8217;s probably a hold-over from too much stuffy contract language only a lawyer could appreciate. There&#8217;s no real need to say it twice, once grammatically and again numerically.</p>
<p>2 more cents!  : )</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Connie Sanford</title>
		<link>http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/comment-page-1/#comment-503</link>
		<dc:creator>Connie Sanford</dc:creator>
		<pubDate>Fri, 10 Aug 2007 17:23:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.theproposalguys.com/2007/08/09/you-say-tomayto-i-say-tomah-to/#comment-503</guid>
		<description>Jon, I must disagree with your assertion that there are no clients stupid enough.  Those &#039;stupid&#039; clients are the same ones that ask the same question 2, 3 or 4 times in a questionnaire.  We don&#039;t draw their attention to their mistake, we just answer the question again and move on.  For small things like that, it&#039;s best not to rock the boat.   The person who wrote the RFP may judge my proposal as flawed if my choices do not match the RFP.  

That&#039;s my two (2) cents worth! :)</description>
		<content:encoded><![CDATA[<p>Jon, I must disagree with your assertion that there are no clients stupid enough.  Those &#8217;stupid&#8217; clients are the same ones that ask the same question 2, 3 or 4 times in a questionnaire.  We don&#8217;t draw their attention to their mistake, we just answer the question again and move on.  For small things like that, it&#8217;s best not to rock the boat.   The person who wrote the RFP may judge my proposal as flawed if my choices do not match the RFP.  </p>
<p>That&#8217;s my two (2) cents worth! :)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

