<?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: Why Prince2&#8217;s Quality Management Process is Flawed</title>
	<atom:link href="http://www.orgtopia.com/2009/12/04/why-prince2s-quality-process-is-flawed/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.orgtopia.com/2009/12/04/why-prince2s-quality-process-is-flawed/</link>
	<description>Management &#38; Leadership Blog</description>
	<lastBuildDate>Tue, 22 Jun 2010 19:37:13 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: David Hinde</title>
		<link>http://www.orgtopia.com/2009/12/04/why-prince2s-quality-process-is-flawed/comment-page-1/#comment-282</link>
		<dc:creator>David Hinde</dc:creator>
		<pubDate>Tue, 02 Feb 2010 08:55:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.orgtopia.com/?p=490#comment-282</guid>
		<description>Hi Chris &amp; Adamantious,

Thanks for taking the time to leave some comments. I think you both make good points.
With Chris&#039;s point - I agree.  Getting away from defining a solution is the key to getting requirements. I think this gets more difficult in ground-breaking projects as we use old ideas and ways of doing things as a reference to asking for what we want. E.g. if I&#039;d never heard of an internal combustion engine I would be more focused on what horses can do for me!
With Adamantious&#039;s point - I sort of agree! I think the problem can be assuming that the project is not of a ground breaking nature and setting specific requirements in terms of quality gates or acceptance criteria. But then this constrains the direction to some extent - what happens if a very innovative solution comes along that doesn&#039;t fit the quality gate?
I think both your comments have inspired me to look at this subject in a deeper way - I&#039;ll write another blog post soon about requirements capture and will look forward to more feedback from you guys on it
Kind regards
David</description>
		<content:encoded><![CDATA[<p>Hi Chris &amp; Adamantious,</p>
<p>Thanks for taking the time to leave some comments. I think you both make good points.<br />
With Chris&#8217;s point &#8211; I agree.  Getting away from defining a solution is the key to getting requirements. I think this gets more difficult in ground-breaking projects as we use old ideas and ways of doing things as a reference to asking for what we want. E.g. if I&#8217;d never heard of an internal combustion engine I would be more focused on what horses can do for me!<br />
With Adamantious&#8217;s point &#8211; I sort of agree! I think the problem can be assuming that the project is not of a ground breaking nature and setting specific requirements in terms of quality gates or acceptance criteria. But then this constrains the direction to some extent &#8211; what happens if a very innovative solution comes along that doesn&#8217;t fit the quality gate?<br />
I think both your comments have inspired me to look at this subject in a deeper way &#8211; I&#8217;ll write another blog post soon about requirements capture and will look forward to more feedback from you guys on it<br />
Kind regards<br />
David</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adamantios Milas</title>
		<link>http://www.orgtopia.com/2009/12/04/why-prince2s-quality-process-is-flawed/comment-page-1/#comment-281</link>
		<dc:creator>Adamantios Milas</dc:creator>
		<pubDate>Mon, 01 Feb 2010 18:51:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.orgtopia.com/?p=490#comment-281</guid>
		<description>David,
the point you make about quality and it&#039;s definition in relation to projects needs a little bit more elaboration.
If we are talking about a new product like iPhone or Ford model T then yes you are right. But if the project is about changing an existing business or product then customer is the one who describes and puts the quality gates or acceptance criteria. He, by deciding to move on with the project knows what are the requirements and the expectations of the change.</description>
		<content:encoded><![CDATA[<p>David,<br />
the point you make about quality and it&#8217;s definition in relation to projects needs a little bit more elaboration.<br />
If we are talking about a new product like iPhone or Ford model T then yes you are right. But if the project is about changing an existing business or product then customer is the one who describes and puts the quality gates or acceptance criteria. He, by deciding to move on with the project knows what are the requirements and the expectations of the change.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Collins</title>
		<link>http://www.orgtopia.com/2009/12/04/why-prince2s-quality-process-is-flawed/comment-page-1/#comment-276</link>
		<dc:creator>Chris Collins</dc:creator>
		<pubDate>Fri, 11 Dec 2009 14:45:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.orgtopia.com/?p=490#comment-276</guid>
		<description>David,
The comment by Henry Ford about why he didn&#039;t consult with users completely missed the point.  Instead of asking what users wanted he should have been asking &quot;What problems do you have?&quot; to which they would probably have replied &quot;It takes too long to get from A to B&quot;.  By letting users choose too much of the solution by-passes the analysts specialist knowledge, and also negates any intuitive ideas the analyst may have.

Therefore I believe that the acceptance criteria should be related to resolving the problem, not necessarily fitting in with a set of criteria that may limit the solution.</description>
		<content:encoded><![CDATA[<p>David,<br />
The comment by Henry Ford about why he didn&#8217;t consult with users completely missed the point.  Instead of asking what users wanted he should have been asking &#8220;What problems do you have?&#8221; to which they would probably have replied &#8220;It takes too long to get from A to B&#8221;.  By letting users choose too much of the solution by-passes the analysts specialist knowledge, and also negates any intuitive ideas the analyst may have.</p>
<p>Therefore I believe that the acceptance criteria should be related to resolving the problem, not necessarily fitting in with a set of criteria that may limit the solution.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
