<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="FeedCreator 1.7.3" -->
<rss version="2.0">
	<channel>
		<title>Coping with Project Scope; Eight Real-World Strategies</title>
		<description>Comments for Coping with Project Scope; Eight Real-World Strategies at http://www.projecttimes.com , comment 1 to 1 out of 1 comments</description>
		<link>http://www.projecttimes.com</link>
		<lastBuildDate>Sat, 31 Jul 2010 02:36:06 +0100</lastBuildDate>
        <generator>FeedCreator 1.7.3</generator>
		<item>
			<title>...</title>
			<link>http://www.projecttimes.com/scope-management/coping-with-project-scope-eight-real-world-strategies.html#comment-348</link>
			<description>Some good ideas but missing the two key aspects of scope which most prevent creep.  First, scope cannot help but creep when it is defined in the typical manner as objectives, because nobody actually knows what they’ll get.  Scope creeps much less when defined more appropriately as top-level REAL business requirements deliverable _whats_ that provide value when delivered by the product/system/software _how_.  It’s the _awareness_ of the REAL business requirements that mainly changes, not the requirements themselves.

Second, there are two different scopes; and much of creep occurs because of confusing them.  The scope of the requirements is determined by what is needed to provide REAL value and is not a function of available time and resources.  In my book, Discovering REAL Business Requirements for Software Project Success, related seminars, and requirements and REAL ROI™ consulting, I describe how to use the powerful Problem Pyramid™ to define the requirements scope so it doesn’t creep so much and becomes a reliable basis for negotiating the scope of implementation projects which the organization is willing and able to undertake. 
 - RobinGoldsmith</description>
			<pubDate>Sun, 15 Nov 2009 03:51:07 +0100</pubDate>
		</item>
	</channel>
</rss>
