<?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 for MISNOMERIC</title>
	<atom:link href="http://rajnishdureja.designmaze.com/?feed=comments-rss2" rel="self" type="application/rss+xml" />
	<link>http://rajnishdureja.designmaze.com</link>
	<description>Look, Think and Act!</description>
	<pubDate>Sun, 05 Sep 2010 10:33:49 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Avoiding Over-Runs in Projects: Manage the Requirements Phase! by Gaurav Gautama</title>
		<link>http://rajnishdureja.designmaze.com/?p=10&#038;cpage=1#comment-3</link>
		<dc:creator>Gaurav Gautama</dc:creator>
		<pubDate>Mon, 26 Nov 2007 13:48:20 +0000</pubDate>
		<guid isPermaLink="false">http://designmaze.com/wordpress/?p=10#comment-3</guid>
		<description>If I understand 'Expectations' as what customer 'expects' and this has been made explicit by the customer - then, it should be treated like any other 'Necessary' requirements.

And the real challenge of requirements phase is to ensure that requirements are siphoned through discussion and consensus into either 'We-are-doing-this' and 'We-are-not-doing' this. The end result of which is clarity of expectation - leaving this ambiguous is typically at the root of this situation of 'are-we?' or 'are-we-not?'

Expectation, in summary, is what the customer knows and has agreed to receive. 

So what happened to the good old 'Customer Delight'? Delight happens when 'expectations' are exceeded - how do we exceed (or even barely meet) expectations if we do not know the expectations are (not what we think they are - but what customer really has)? I think, the secret is on setting unambiguous mutually acceptable expectations, and with our awareness of what the customer really wanted to start with, try and offer the same and more (no obligations - whatsoever). Therefore, I believe in a singular 'expectation'/'desire'/'necessary'. And a sincere effort to deliver over and above this.</description>
		<content:encoded><![CDATA[<p>If I understand &#8216;Expectations&#8217; as what customer &#8216;expects&#8217; and this has been made explicit by the customer - then, it should be treated like any other &#8216;Necessary&#8217; requirements.</p>
<p>And the real challenge of requirements phase is to ensure that requirements are siphoned through discussion and consensus into either &#8216;We-are-doing-this&#8217; and &#8216;We-are-not-doing&#8217; this. The end result of which is clarity of expectation - leaving this ambiguous is typically at the root of this situation of &#8216;are-we?&#8217; or &#8216;are-we-not?&#8217;</p>
<p>Expectation, in summary, is what the customer knows and has agreed to receive. </p>
<p>So what happened to the good old &#8216;Customer Delight&#8217;? Delight happens when &#8216;expectations&#8217; are exceeded - how do we exceed (or even barely meet) expectations if we do not know the expectations are (not what we think they are - but what customer really has)? I think, the secret is on setting unambiguous mutually acceptable expectations, and with our awareness of what the customer really wanted to start with, try and offer the same and more (no obligations - whatsoever). Therefore, I believe in a singular &#8216;expectation&#8217;/'desire&#8217;/'necessary&#8217;. And a sincere effort to deliver over and above this.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
