Are you finishing a project or delivering a product?

Today I'd like to spend a bit of time talking about the difference between a project and a product. 

• A software project refers to the scope and timelines in which software is planned to be delivered
• A software product refers to the overall software package

While these two terms aren't mutually exclusive, after all you typically run a software project in order to deliver a software product. But the vast majority of people I've worked with are focused on one or the other. Given that choice, should we care more about the project or the product?

If you're thinking about the software with a project mindset, success is primarily measured by one concept: completing all desired functionality within time and budget. The obvious benefit to this approach is that having a 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.

But if you're looking primarily about your software product, 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, as you might imagine 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.