Product and Project Software Configuration Management (SCM)

Products and Projects - before we get into any SCM discussions, we need to classify these beasts. What are their distinguishing marks?! The Lean Development Mailing List had a pertinent discussion</a> on this. Mary Poppendieck commented:"Products are development efforts that are (usually) funded incrementally. They start with a concept and end with a product launch. Along the way, they are funded incrementally as they progress through stages such as feasibility, test market, commercialization, etc. [...] Products are also expected to have a long and useful life over which timeframe they are generally expected to undergo constant improvement."

Projects, on the other hand, due to their contract origins, tend to be fully funded at the beginning of the project. This front-end loaded funding tends to drive the people providing the funds to ask for scope and schedule plans, which are then treated as commitments - after all - the funds are committed, so they want to know what they will get for the money. In addition, on-going change after the "end" of a project is generally regarded as bad.

Alan Shalloway contributed:

Lean extends some other agile methods (e.g., Scrum, XP) which are project centric. Products are about something the company offers to its customers (internal for IT products) while projects are about building the product. Thus good products will grow, mature and continue to add value to the customer in different ways and may spawn multiple projects.

Many companies have more waste in their project selection process than in their project building process. They will spend 1 - 2 years deciding whether to approve a project. Once they have selected a project to build, Scrum and XP can be put into place. However, what they really could use to help them is the understanding of waste that Lean provides. Waste includes delay, task-switching, hand- offs and other things which don't show up on an accountants balance sheet. Value stream maps are incredibly useful tools in this area.

Internal vs. External
Then we have the difference between internal and external products:

External products (or systems or applications) are things that we sell in order to generate revenue. The more customers we have to support (even on different versions/platforms), the more revenue we generate in return.

Internal products (or systems or applications) are pure operating cost and do not directly generate revenue. The more customers we have to support (especially on different versions/platforms) the more it costs us to spend time, money and effort on activities that are not revenue generating. The people and time we spend on them means less money spent on revenue-generating activities. We only do it because we think we are getting productivity and/or cost-savings (e.g., over not having the tool/applications) in return, and we still want to minimize it.

Internal apps also generally have a harder time justifying their existence/value to the business and their impact on the bottom-line (which might well be similar to justifying "CM" :-)

Also, there is a HUGE difference between delivering to customers who don't live in your own backyard and aren't part of the same organizational culture and politics. There are typically extra layers of "customer care/service" between development engineers and direct customers/users, and the internal customers also have a lot more visibility and transparency and "closeness" into what is going on.

Even more interesting is the notion of "consultants" who are hired strictly for the duration of a project (regardless of if it is internal or external) and how much that motivates and rewards them to think and act in the best interests of the "product" and not just of