Contribution 29

From WikiContent

Revision as of 00:54, 18 May 2008 by DaveQuick (Talk | contribs)
Jump to: navigation, search

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

Personal tools