(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Thursday, August 23, 2007
  How many products make up a project?

Software applications are often defined in advance as masses of features, loosely organized into modules and components. One of the things I do as a matter of course when starting a project is to count the number of products. A “product” is a piece of software that stands alone and delivers value. In the context of a big project, products are parts of the project that could, all by themselves, be projects.

For example, I was once working with a company that wanted to move their customer service operations from an old proprietary minicomputer system to a web system with an equally proprietary but much more current database back-end. They also wanted “workflow” while we were at it.
This is not about maximizing programmer productivity. In fact, it has nothing to do with programmers. It’s about a very scarce resource: management attention.

I pointed out that the web “port” was a product, and so was the workflow. You could build a workflow system that worked alongside the legacy software, and it would deliver business value. Or you could port the legacy application, and again deliver business value. So this project was really two separate products.

The value of drawing this distinction lies in understanding that the capacity of a team to effectively develop simultaneous products is nearly always one. That’s right, no matter what the size, teams are most effective when they work on one product at a time. And by teams, I mean the full team, including stake-holders, business analysts, everyone, not just the programmers.

When you work on one product, you have a clear vision, priorities are straightforward, you know when you’re “done”… It all works smoothly. When you work on two or more products simultaneously, all this falls apart in a hurry.

This is not about maximizing programmer productivity. In fact, it has nothing to do with programmers. It’s about a very scarce resource: management attention. Whether you are building a commercial application for an ISV or a client project for a government ministry, there is a very limited ability of the stake-holders to digest the project’s progress and contribute with feedback and priorities.

Developing multiple products simultaneously hits the stake-holders hard, forcing them to try to manage the relationships between them in their head, understand the impact of changes from one product onto another, and juggle twice as many documents and meetings.

The results are invariably poor.

So what to do? The answer is surprisingly easy. Divide large projects up into their natural products, then develop the products serially. Work out which product can be developed first, and then start with it, religiously rejecting attempts to extend it horizontally with features from the other products.

When it is done and delivering value, build on it by adding another product. Repeat until done.

As mentioned, this has nothing to do with programmers. It’s about maximizing the business’s benefit. This is the theory behind incremental delivery practices such as SCRUM, implemented at a coarse level.

And that project I mentioned? They ported the application, and in the process discovered many ways to extend it to add much more value than the workflow would have provided.

Comments on “How many products make up a project?:

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /