The system development project is often used as the area of interest or scope when talking about processes, documents, maturity etc. Some concrete examples are:

  • The CMMI maturity level 2 is achieved by defining a process for each project.
  • A configuration management plan is often suggested to be written per project.
  • Repositories for information items such as change requests and source code files are often set up per project.

I’m speculating a bit but I believe this project focus comes from the culture that also was the origin of process improvement: large, multi-year, military projects. Each project was almost like an enterprise in its own right. These projects by their nature also carried a high risk which is best managed in a project context. (See this earlier post.)

Many software projects today are only one in a series of projects throughout the life time of a product. Most commercial software go through cycles of improvement, sometimes in the form of “patches”, sometimes in the form of larger upgrades which come with new functionality.

With a large number of projects, presumably working on the same specs and code, enhancing and refactoring it, it often makes more sense to focus on the product instead of the project. Regarding the bullets above this would for instance mean:

  • It makes sense to early on in the product’s life cycle develop a standard development process for the product instead of inventing a process in each project. This would mean going for CMMI maturity level 3 early on.
  • The configuration management plan should be written for the product, not the project. It makes little sense to change the way the data is managed from project to project. This would in fact impede (re-)using the previous versions of the specs and the code as a starting point for the next project. And it would be really difficult to see how one could have different configuration management plans for parallel projects working on the same set of specs and code.
  • The repositories holding the specs and the code (e.g. the configuration management system) should of the reasons mentioned above be organized for the product so that e.g. branches would be possible to make for parallel projects.