The difference between a "project" and "product" in software development

What is the difference between delivering software products and completing software projects?  Both delivering a software product and completing a software project have the same end product in mind – creating working software.  However, the approaches are significantly different.

A software project’s success is primarily measured by one concept: completing all desired functionality within time and budget.  The obvious benefit to a project-based mentality is that having a (reasonably) fixed cost and duration it makes it easier to budget money and resources for future projects.  However, as I wrote in a previous post, time and budget measurements should be secondary considerations to the actual business value delivered.  If the project mentality is taken too far, it can lead to a deliberate attempt to limit needed functionality if it is determined after scope is laid out.

A software product’s success is primarily determined by the goals of the software itself.  If, and only if, the software does what it was intended to, it was a success.  The benefit to this mentality is that the core mindset becomes delivering software that exceeds expectations.  Scope creep no longer becomes an issue – if functionality that is needed is found after the scoping process, the project is re-scoped.  The development team and business stakeholders can re-evaluate priorities based on business needs and current budget without needing to concern themselves with a pre-determined budget.  A drawback is that product-based teams tend to increase scope as time goes on, which makes budgeting and resource planning more difficult.  It is also more difficult to determine success criteria in a software product environment, since this will vary from project to project.

While there are definitely benefits to a project-based approach, I would like to see more of a product-based mentality among technology teams.  We as technologists need to be more concerned with the software functionality as a whole; not in the sense of “does it do what we were asked to build” but “does it do what it’s supposed to do from a business point of view”.  Of course, time and budget are important, otherwise the methods for determining which projects to pursue start losing their relevancy.  But a greater product-based approach would help bridge the gulf between business and IT.