• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Is your software a project or a product?

One of the most common mistakes made by software development teams and others in thinking about software is the confusion between the concept of software as a project and the concept of software as a product.

When asked, most people would agree that software is a product, not a project. After all, the software will exist long after the project comes to an end so it is obviously something fundamentally different.

However, since most of the work we do on software is done by project teams, it is easy to fall into the habit of talking and thinking about the software in project terms. This can cause a variety of bad results, from confusion to outright project or product failure.

A project is a temporary endeavor that produces a unique result. Projects have start dates and end dates. Projects have life cycles. The words people use to describe the phases and artifacts of a project life cycle vary but all projects have some version of a project charter, an initial or start up phase, one or more intermediate phases, and a closing phase. A project has scope and constraints of time and resources. A successful project produces its intended result, a result that meets the needs and expectations of the project stakeholders within the time and resource constraints.

A product is the unique result of a project. A product also has a lifecycle. A product has scope, requirements, and constraints and we can measure product quality, in part, by assessing whether the product functions as intended.

We use many of the same words to describe projects and products: lifecycle, scope, constraints, quality, etc. For software development project teams the result is often confusion. Are we talking about project scope or product scope, project lifecycle or product lifecycle? It is a good idea to be clear about which you are talking about or working on.

The project and the product are obviously tightly linked and can’t realistically be considered completely in isolation. We should however avoid comingling and confusing the project and product lifecycle, scope, requirements, quality, etc.
No comments yet.

Leave a Reply

Your email address will not be published. Required fields are marked *