<?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: How to Control Change Requests</title>
	<atom:link href="http://www.pmhut.com/how-to-control-change-requests/feed" rel="self" type="application/rss+xml" />
	<link>http://www.pmhut.com/how-to-control-change-requests</link>
	<description></description>
	<pubDate>Sat, 11 Feb 2012 16:53:35 +0000</pubDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: UX-admin</title>
		<link>http://www.pmhut.com/how-to-control-change-requests/comment-page-1#comment-13029</link>
		<dc:creator>UX-admin</dc:creator>
		<pubDate>Wed, 02 Dec 2009 16:27:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=4215#comment-13029</guid>
		<description>"The description of the benefits of the change may have to be coaxed from the requester but if they cannot articulate the benefit of the requested change after several leading questions, or they insist on turning the conversation to why their solution is better than the one originally planned, end the conversation; you’ve got the information you were seeking - there is no benefit."

I disagree with this statement, with vehemence!

I've often found myself in the situations where the other part was not capable of articulating WHY a certain decision was wrong, or WHY their decision was better, but that party knew it INSTINCTIVELY, and based on EXPERIENCE. They were just incapable of describing it.

And: it turns out the other party was correct. CONSISTENTLY.

I have also found myself in such situations, where I have been the party that instinctively knew a decision or a solution was BAD, but pressed for a factual or a logical explanation, I could not explain it well enough. And it turns out that as a subject matter expert, I had been correct, consistenly as well.

So your statement, as reasonable as it seems, is incorrect, and this can be proven empirically, and by experience to date; if you are managing your projects in this way, you are mismanaging by giving yourself and the stakeholders a false sense of security, under the pretense that you are being logical and factual.</description>
		<content:encoded><![CDATA[<p>&#8220;The description of the benefits of the change may have to be coaxed from the requester but if they cannot articulate the benefit of the requested change after several leading questions, or they insist on turning the conversation to why their solution is better than the one originally planned, end the conversation; you’ve got the information you were seeking - there is no benefit.&#8221;</p>
<p>I disagree with this statement, with vehemence!</p>
<p>I&#8217;ve often found myself in the situations where the other part was not capable of articulating WHY a certain decision was wrong, or WHY their decision was better, but that party knew it INSTINCTIVELY, and based on EXPERIENCE. They were just incapable of describing it.</p>
<p>And: it turns out the other party was correct. CONSISTENTLY.</p>
<p>I have also found myself in such situations, where I have been the party that instinctively knew a decision or a solution was BAD, but pressed for a factual or a logical explanation, I could not explain it well enough. And it turns out that as a subject matter expert, I had been correct, consistenly as well.</p>
<p>So your statement, as reasonable as it seems, is incorrect, and this can be proven empirically, and by experience to date; if you are managing your projects in this way, you are mismanaging by giving yourself and the stakeholders a false sense of security, under the pretense that you are being logical and factual.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Samer Zawaydeh</title>
		<link>http://www.pmhut.com/how-to-control-change-requests/comment-page-1#comment-12771</link>
		<dc:creator>Samer Zawaydeh</dc:creator>
		<pubDate>Sun, 29 Nov 2009 20:16:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=4215#comment-12771</guid>
		<description>Dear PM Hut,

Thank you for providing this information. This can be useful for several industries.

My remarks are as follows:

1. Change request are made throughout the duration of the project. This can be initiated by both sides due to the following
 a. Material Change
 b. Shop drawings.
 c. Availability of material is the local market.
 d. Change is specification.
 e. Change in functionality.
 f. Change in the Construction sequence.
 g. Deliverable Not meeting the expectations of the client.

2. The Contractor has to submit a technical and financial offer that the Engineer must review and recomment to the Client for approval.

3. Change request approval process should be outlined in the Conditions of Contract in order to minimize the disagreement during the Contract duration.

4. Engineer can recommend the payment on account for completed works in any Change Order even if the Change order is not fully approved by the Client.

5. Change orders are documented in each Interim Payment and in each Monthly report.

6. Retention amount is also held back against the completed change order value as per Conditions of Contract.

7. The Contractor has to submit a Maintenance Guaranttee for the complete value of the Contract including the Change orders.

8. Change orders can have negative or positive values.

With best Regards,

Samer</description>
		<content:encoded><![CDATA[<p>Dear PM Hut,</p>
<p>Thank you for providing this information. This can be useful for several industries.</p>
<p>My remarks are as follows:</p>
<p>1. Change request are made throughout the duration of the project. This can be initiated by both sides due to the following<br />
 a. Material Change<br />
 b. Shop drawings.<br />
 c. Availability of material is the local market.<br />
 d. Change is specification.<br />
 e. Change in functionality.<br />
 f. Change in the Construction sequence.<br />
 g. Deliverable Not meeting the expectations of the client.</p>
<p>2. The Contractor has to submit a technical and financial offer that the Engineer must review and recomment to the Client for approval.</p>
<p>3. Change request approval process should be outlined in the Conditions of Contract in order to minimize the disagreement during the Contract duration.</p>
<p>4. Engineer can recommend the payment on account for completed works in any Change Order even if the Change order is not fully approved by the Client.</p>
<p>5. Change orders are documented in each Interim Payment and in each Monthly report.</p>
<p>6. Retention amount is also held back against the completed change order value as per Conditions of Contract.</p>
<p>7. The Contractor has to submit a Maintenance Guaranttee for the complete value of the Contract including the Change orders.</p>
<p>8. Change orders can have negative or positive values.</p>
<p>With best Regards,</p>
<p>Samer</p>
]]></content:encoded>
	</item>
</channel>
</rss>

