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.