Product and Project Software Configuration Management (SCM)

In this article, the authors discuss how software configuration fits into products and projects, beyond managing and controlling source code and other developer assets. They look at the differences between internal and external products and where project fit into the equation.

Products and Projects 

Before we venture into any SCM discussions, we first must classify them. The lean development mailing list had a pertinent discussion 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. Additionally, on-going change after the end of a project is generally regarded as bad. Alan Shalloway contributed: Lean extends some othe Agile methods (e.g., Scrum, XP) that 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
We also 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 generally have a harder time justifying their existence/value to the business and their impact on the bottom-line, which may as well equate 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 the one or two projects that they will be around for. It is easier to come in and put something together fast and get a group up and running. The poor folks who are stuck with the internal support and maintenance, if the outcome is ill-structured, un-factored, poor quality code, are the ones that the company may end up spending a lot more money for in the long-run.

Just because we are picking on consultants here, doesn't mean that organizations doing it all themselves don't suffer from similar problems. We have seen short-term project thinking within a large program of internal development.  The teams came together, delivered the projects and then were disbanded (due to internal charging models) without paying much attention to the long-term maintenance requirements.


About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at or visit and follow his blog at

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!