Contribution 29

From WikiContent

(Difference between revisions)
Jump to: navigation, search
m
Current revision (07:32, 13 July 2008) (edit) (undo)
(Scope is the enemy of success)
 
(3 intermediate revisions not shown.)
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? What functionality at what level of quality? How difficult to deliver? How much risk? What constraints exist? 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.
+
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.
-
+
-
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.
+
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.
-
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?
+
Why does it work this way? Consider some examples:
-
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 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.
-
+
-
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 Estimation is far from an exact science. Who hasn’t seen features that were much harder to implement than expected?
-
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.
+
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 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 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?
-
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.
+
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.
 +
 
 +
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.
 +
 
 +
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.
 +
 
 +
 
 +
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)(updated DAQ 7/7/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

Current revision

Scope is the enemy of success

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.

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 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? 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 Estimation is far from an exact science. 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 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.

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.

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.


By Dave Quick

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

[2] See "eXtreme Programming eXplained" by Kent Beck


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

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools