Contribution 29 - Revision history

Rmonson: /* Scope is the enemy of success */

Rmonson — Sun, 13 Jul 2008 07:32:38 GMT

Scope is the enemy of success

←Older revision		Revision as of 07:32, 13 July 2008
Line 25:		Line 25:


-	By [[Dave Quick??]]	+	By [[Dave Quick]]

	[1] See "The Mythical Man-Month" by Fred Brooks		[1] See "The Mythical Man-Month" by Fred Brooks

DaveQuick: /* Scope is the enemy of success */

DaveQuick — Mon, 07 Jul 2008 23:02:38 GMT

Scope is the enemy of success

←Older revision		Revision as of 23:02, 7 July 2008
Line 32:		Line 32:


-	(Edited RMH 5/28/2008)	+	(Edited RMH 5/28/2008)(updated DAQ 7/7/2008)

	This work is licensed under a		This work is licensed under a

DaveQuick: /* Scope is the enemy of success */

DaveQuick — Mon, 07 Jul 2008 23:01:40 GMT

Scope is the enemy of success

←Older revision		Revision as of 23:01, 7 July 2008
Line 1:		Line 1:
	== Scope is the enemy of success ==		== Scope is the enemy of success ==
-	Scope refers to a project's size. How much time, effort, and resources ~~will it take to accomplish~~? ~~How much~~ functionality ~~will it deliver and to~~ what level of quality? How difficult ~~are the features~~ to deliver? How much risk ~~is involved~~? What constraints ~~affect the project~~? The answers define a project's scope.	+	Scope refers to a project's size. How much time, effort, and resources? What functionality at what level of quality? How difficult to deliver? How much risk? What constraints exist? The answers define a project's scope.

-	~~Big, complicated projects are a challenge and software~~ architects love a challenge~~. The rewards for success on~~ big, complicated projects can ~~motivate~~ people to ~~the point of obsession. In fact, many projects~~ artificially expand ~~their~~ scope to increase ~~their~~ apparent importance.	+	Software architects love the challenge of big, complicated projects. The potential rewards can even tempt people to artificially expand a project’s scope to increase its apparent importance.

-	Expanding scope is the enemy of success because ~~it increases~~ the probability of failure ~~more quickly~~ than expected. Doubling a project’s scope often increases its probability of failure by an order of magnitude~~. Existing constraints may even make success impossible~~.	+	Expanding scope is the enemy of success because the probability of failure grows faster than expected. Doubling a project’s scope often increases its probability of failure by an order of magnitude.

-	Why does it work this way? ~~Let's consider~~ some examples:	+	Why does it work this way? Consider some examples:

		+	o Intuition tells us to double our time or resources to do twice as much work. History[1] says impacts are not as linear as intuition suggests. For example, a four person team will expend more than twice the communication effort as a team of two.

-	o ~~Intuition tells us we need~~ to ~~double our time or people to do twice as much work. History[1] says impacts are not as linear as intuition suggests. To cite just one example, four people will expend considerably more~~ than ~~twice the effort on communications as a two person project.~~	+	o Estimation is far from an exact science. Who hasn’t seen features that were much harder to implement than expected?

-	~~o Estimation is far from an exact science~~. ~~It may~~ be ~~trivial~~ to ~~add one feature~~, ~~while another needs more time and resources than all of the previous features combined~~. ~~Who hasn’t seen features that were much harder~~ to ~~implement than expected~~?	+	Of course, some projects aren’t worth doing without some built-in size and complexity. While a text editor without the ability to enter text might be easy to build, it wouldn’t be a text editor. So, what strategies can help to reduce or manage scope in real-world projects?

-	o ~~Agile advocates[2] exhort us to build "~~The ~~simplest thing that could possibly work"~~. ~~Scope reduction is one~~ of ~~the most effective strategies an architect can apply~~ to ~~improve~~ the ~~odds of success~~.	+	o Understand the real needs – The capabilities a project must deliver are a set of requirements. Requirements define functionality or qualities of functionality. Question any requirements not explained in terms of measurable value to the customer. If it has no effect on the company’s bottom line, why is it a requirement?

		+	o Divide and conquer – Look for opportunities to divide up the work into smaller independent chunks. It is easier to manage several small independent projects than one large project with interdependent parts.

-	~~Of course, some projects aren’t worth doing without some built-in size and complexity~~. ~~You could reduce~~ the ~~scope of a word processing software project by removing~~ the ~~ability to enter text, but it wouldn’t be a word-processor~~. ~~So, what strategies can help to reduce or manage scope in real-world projects?~~	+	o Prioritize – The world of business changes rapidly. Large projects’ requirements change many times before they’re completed. Important requirements usually remain important as the business changes while others change or even evaporate. Prioritization lets you deliver the most important requirements first.

		+	o Deliver results as soon as possible – Few people know what they want before they have it. A famous cartoon shows the evolution of a project to build a child’s swing based on what the customer said and what various roles in the project understood. The complicated result only faintly resembles a swing. The last panel, titled “What would have worked”, shows a simple swing using an old tire. When the customer has something to try, the solution may be simpler than expected. Building the most important things first gets you the most important feedback early, when you need it most.

-	~~o Understand the real needs – We usually define the capabilities a~~ project ~~must deliver as~~ a ~~set of requirements~~. ~~Requirements define functionality or some qualities~~ of ~~functionality. Question any requirements not explained in terms of measurable value~~ to the ~~customer~~. ~~If it has no effect on the company’s bottom line, why is it a requirement?~~	+	Agile advocates[2] exhort us to build "The simplest thing that could possibly work". Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Scope reduction is one of the most effective strategies an architect can apply to improve the odds of success.

-	o Divide and conquer – When scope reduction is not possible, look for opportunities to divide up the work into smaller independent chunks. It is easier to manage several small independent projects than one large project where every part is interdependent.
-
-	o Prioritize – The world of business changes rapidly. Any large project’s requirements will change many times before it’s completed. Important requirements are likely to remain important as the business changes, while less important requirements often change or even evaporate. You can deliver the most important requirements first if they are prioritized by the value they deliver.
-
-	o Deliver results as soon as possible – Humans are terrible at knowing what they want before they have it. A famous cartoon shows the evolution of a project to build a child’s swing based on what the customer said and what various roles in the project understood. The result is a deliverable that only faintly resembles a swing. The last panel is usually titled “What would have worked” and shows a simple swing made from an old tire. Once the customer has something to try, the solution may be simpler than anyone thought. By building the most important things first, you can get the most important feedback early in the project when you need it most.
-
-
-	Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Experienced architects constantly look for scope reduction opportunities.

	By [[Dave Quick??]]		By [[Dave Quick??]]

Rmonson at 12:57, 28 May 2008

Rmonson — Wed, 28 May 2008 12:57:07 GMT

←Older revision		Revision as of 12:57, 28 May 2008
Line 1:		Line 1:
	== Scope is the enemy of success ==		== Scope is the enemy of success ==
-
	Scope refers to a project's size. How much time, effort, and resources will it take to accomplish? How much functionality will it deliver and to what level of quality? How difficult are the features to deliver? How much risk is involved? What constraints affect the project? The answers define a project's scope.		Scope refers to a project's size. How much time, effort, and resources will it take to accomplish? How much functionality will it deliver and to what level of quality? How difficult are the features to deliver? How much risk is involved? What constraints affect the project? The answers define a project's scope.
-		+
	Big, complicated projects are a challenge and software architects love a challenge. The rewards for success on big, complicated projects can motivate people to the point of obsession. In fact, many projects artificially expand their scope to increase their apparent importance.		Big, complicated projects are a challenge and software architects love a challenge. The rewards for success on big, complicated projects can motivate people to the point of obsession. In fact, many projects artificially expand their scope to increase their apparent importance.
-		+
	Expanding scope is the enemy of success because it increases the probability of failure more quickly than expected. Doubling a project’s scope often increases its probability of failure by an order of magnitude. Existing constraints may even make success impossible.		Expanding scope is the enemy of success because it increases the probability of failure more quickly than expected. Doubling a project’s scope often increases its probability of failure by an order of magnitude. Existing constraints may even make success impossible.
-		+
	Why does it work this way? Let's consider some examples:		Why does it work this way? Let's consider some examples:
		+

	o Intuition tells us we need to double our time or people to do twice as much work. History[1] says impacts are not as linear as intuition suggests. To cite just one example, four people will expend considerably more than twice the effort on communications as a two person project.		o Intuition tells us we need to double our time or people to do twice as much work. History[1] says impacts are not as linear as intuition suggests. To cite just one example, four people will expend considerably more than twice the effort on communications as a two person project.
Line 13:		Line 13:
	o Estimation is far from an exact science. It may be trivial to add one feature, while another needs more time and resources than all of the previous features combined. Who hasn’t seen features that were much harder to implement than expected?		o Estimation is far from an exact science. It may be trivial to add one feature, while another needs more time and resources than all of the previous features combined. Who hasn’t seen features that were much harder to implement than expected?

-	o In the early days of affordable internet connections a consulting customer wanted to deliver real-time training video feeds to its franchise dealers. A Senior Vice President had forced his independent dealers to buy an expensive, proprietary, low speed networking system only two years earlier. Using the proprietary network was an iron-clad constraint of the new project which led to its failure and significantly damaged the company’s relationship with its dealers.	+	o Agile advocates[2] exhort us to build "The simplest thing that could possibly work". Scope reduction is one of the most effective strategies an architect can apply to improve the odds of success.
-		+
-	Agile advocates[2] exhort us to build "The simplest thing that could possibly work". Scope reduction is one of the most effective strategies an architect can apply to improve the odds of success.	+
-		+
	Of course, some projects aren’t worth doing without some built-in size and complexity. You could reduce the scope of a word processing software project by removing the ability to enter text, but it wouldn’t be a word-processor. So, what strategies can help to reduce or manage scope in real-world projects?		Of course, some projects aren’t worth doing without some built-in size and complexity. You could reduce the scope of a word processing software project by removing the ability to enter text, but it wouldn’t be a word-processor. So, what strategies can help to reduce or manage scope in real-world projects?
-		+
		+
	o Understand the real needs – We usually define the capabilities a project must deliver as a set of requirements. Requirements define functionality or some qualities of functionality. Question any requirements not explained in terms of measurable value to the customer. If it has no effect on the company’s bottom line, why is it a requirement?		o Understand the real needs – We usually define the capabilities a project must deliver as a set of requirements. Requirements define functionality or some qualities of functionality. Question any requirements not explained in terms of measurable value to the customer. If it has no effect on the company’s bottom line, why is it a requirement?

Line 26:		Line 26:

	o Deliver results as soon as possible – Humans are terrible at knowing what they want before they have it. A famous cartoon shows the evolution of a project to build a child’s swing based on what the customer said and what various roles in the project understood. The result is a deliverable that only faintly resembles a swing. The last panel is usually titled “What would have worked” and shows a simple swing made from an old tire. Once the customer has something to try, the solution may be simpler than anyone thought. By building the most important things first, you can get the most important feedback early in the project when you need it most.		o Deliver results as soon as possible – Humans are terrible at knowing what they want before they have it. A famous cartoon shows the evolution of a project to build a child’s swing based on what the customer said and what various roles in the project understood. The result is a deliverable that only faintly resembles a swing. The last panel is usually titled “What would have worked” and shows a simple swing made from an old tire. Once the customer has something to try, the solution may be simpler than anyone thought. By building the most important things first, you can get the most important feedback early in the project when you need it most.
		+

	Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Experienced architects constantly look for scope reduction opportunities.		Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Experienced architects constantly look for scope reduction opportunities.

	By [[Dave Quick??]]		By [[Dave Quick??]]
		+
	[1] See "The Mythical Man-Month" by Fred Brooks		[1] See "The Mythical Man-Month" by Fred Brooks
		+
	[2] See "eXtreme Programming eXplained" by Kent Beck		[2] See "eXtreme Programming eXplained" by Kent Beck
		+
		+
		+	(Edited RMH 5/28/2008)
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+
		+	Back to [[97 Things Every Software Architect Should Know]] home page

Jeremyanywhere at 11:58, 18 May 2008

Jeremyanywhere — Sun, 18 May 2008 11:58:42 GMT

←Older revision		Revision as of 11:58, 18 May 2008
Line 1:		Line 1:
-	Scope is the enemy of success	+	== Scope is the enemy of success ==

	Scope refers to a project's size. How much time, effort, and resources will it take to accomplish? How much functionality will it deliver and to what level of quality? How difficult are the features to deliver? How much risk is involved? What constraints affect the project? The answers define a project's scope.		Scope refers to a project's size. How much time, effort, and resources will it take to accomplish? How much functionality will it deliver and to what level of quality? How difficult are the features to deliver? How much risk is involved? What constraints affect the project? The answers define a project's scope.
Line 29:		Line 29:
	Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Experienced architects constantly look for scope reduction opportunities.		Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Experienced architects constantly look for scope reduction opportunities.

		+	By [[Dave Quick??]]
	[1] See "The Mythical Man-Month" by Fred Brooks		[1] See "The Mythical Man-Month" by Fred Brooks
	[2] See "eXtreme Programming eXplained" by Kent Beck		[2] See "eXtreme Programming eXplained" by Kent Beck

DaveQuick: Scope is the enemy of success

DaveQuick — Sun, 18 May 2008 03:12:00 GMT

Scope is the enemy of success

←Older revision		Revision as of 03:12, 18 May 2008
Line 1:		Line 1:
		+	Scope is the enemy of success
		+
	Scope refers to a project's size. How much time, effort, and resources will it take to accomplish? How much functionality will it deliver and to what level of quality? How difficult are the features to deliver? How much risk is involved? What constraints affect the project? The answers define a project's scope.		Scope refers to a project's size. How much time, effort, and resources will it take to accomplish? How much functionality will it deliver and to what level of quality? How difficult are the features to deliver? How much risk is involved? What constraints affect the project? The answers define a project's scope.

DaveQuick at 00:54, 18 May 2008

DaveQuick — Sun, 18 May 2008 00:54:46 GMT

←Older revision		Revision as of 00:54, 18 May 2008
Line 27:		Line 27:
	Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Experienced architects constantly look for scope reduction opportunities.		Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Experienced architects constantly look for scope reduction opportunities.

-	1 See "The Mythical Man-Month" by Fred Brooks	+	[1] See "The Mythical Man-Month" by Fred Brooks
-	2 See "eXtreme Programming eXplained" by Kent Beck	+	[2] See "eXtreme Programming eXplained" by Kent Beck

DaveQuick at 00:51, 18 May 2008

DaveQuick — Sun, 18 May 2008 00:51:20 GMT

←Older revision		Revision as of 00:51, 18 May 2008
Line 6:		Line 6:

	Why does it work this way? Let's consider some examples:		Why does it work this way? Let's consider some examples:
		+
	o Intuition tells us we need to double our time or people to do twice as much work. History[1] says impacts are not as linear as intuition suggests. To cite just one example, four people will expend considerably more than twice the effort on communications as a two person project.		o Intuition tells us we need to double our time or people to do twice as much work. History[1] says impacts are not as linear as intuition suggests. To cite just one example, four people will expend considerably more than twice the effort on communications as a two person project.

DaveQuick: Scope is the enemy of success

DaveQuick — Sun, 18 May 2008 00:50:47 GMT

Scope is the enemy of success

New page

Scope refers to a project's size. How much time, effort, and resources will it take to accomplish? How much functionality will it deliver and to what level of quality? How difficult are the features to deliver? How much risk is involved? What constraints affect the project? The answers define a project's scope.

Big, complicated projects are a challenge and software architects love a challenge. The rewards for success on big, complicated projects can motivate people to the point of obsession. In fact, many projects artificially expand their scope to increase their apparent importance.

Expanding scope is the enemy of success because it increases the probability of failure more quickly than expected. Doubling a project’s scope often increases its probability of failure by an order of magnitude. Existing constraints may even make success impossible.

Why does it work this way? Let's consider some examples:
o Intuition tells us we need to double our time or people to do twice as much work. History[1] says impacts are not as linear as intuition suggests. To cite just one example, four people will expend considerably more than twice the effort on communications as a two person project.

o Estimation is far from an exact science. It may be trivial to add one feature, while another needs more time and resources than all of the previous features combined. Who hasn’t seen features that were much harder to implement than expected?

o In the early days of affordable internet connections a consulting customer wanted to deliver real-time training video feeds to its franchise dealers. A Senior Vice President had forced his independent dealers to buy an expensive, proprietary, low speed networking system only two years earlier. Using the proprietary network was an iron-clad constraint of the new project which led to its failure and significantly damaged the company’s relationship with its dealers.

Agile advocates[2] exhort us to build "The simplest thing that could possibly work". Scope reduction is one of the most effective strategies an architect can apply to improve the odds of success.

Of course, some projects aren’t worth doing without some built-in size and complexity. You could reduce the scope of a word processing software project by removing the ability to enter text, but it wouldn’t be a word-processor. So, what strategies can help to reduce or manage scope in real-world projects?

o Understand the real needs – We usually define the capabilities a project must deliver as a set of requirements. Requirements define functionality or some qualities of functionality. Question any requirements not explained in terms of measurable value to the customer. If it has no effect on the company’s bottom line, why is it a requirement?

o Divide and conquer – When scope reduction is not possible, look for opportunities to divide up the work into smaller independent chunks. It is easier to manage several small independent projects than one large project where every part is interdependent.

o Prioritize – The world of business changes rapidly. Any large project’s requirements will change many times before it’s completed. Important requirements are likely to remain important as the business changes, while less important requirements often change or even evaporate. You can deliver the most important requirements first if they are prioritized by the value they deliver.

o Deliver results as soon as possible – Humans are terrible at knowing what they want before they have it. A famous cartoon shows the evolution of a project to build a child’s swing based on what the customer said and what various roles in the project understood. The result is a deliverable that only faintly resembles a swing. The last panel is usually titled “What would have worked” and shows a simple swing made from an old tire. Once the customer has something to try, the solution may be simpler than anyone thought. By building the most important things first, you can get the most important feedback early in the project when you need it most.

Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Experienced architects constantly look for scope reduction opportunities.

1 See "The Mythical Man-Month" by Fred Brooks
2 See "eXtreme Programming eXplained" by Kent Beck