Project v Product

By | February 9, 2015

After reading James’ last post, Responding to Change – A Decorator’s Story, I began thinking a bit more in general about how people consider software development. In a lot of places where I have worked, software has always been delivered in projects.

These projects, even ones that have been called ‘Agile projects’, have usually solely been focussed on achieving the end goal. Even in the scenario where an earlier version of the software was already in production and could easily be enhanced incrementally, the project or traditional mindset has often meant that little consideration was given to delivering value early and often, which inevitably meant all the requirements were released at the end with a wonderful ‘big bang’. This is similar to a situation that I am currently facing.


No more big bangs

Projects, by their nature, are finite in their duration. Generally, at the start of a project a team is formed and is often then disbanded when the project is deemed to be complete, meaning that most of the knowledge behind the software is lost. The maintenance of the product is at that point handed over to an ‘application support’ team elsewhere in the organisation.

While in some scenarios it may be appropriate for software to be developed as part of a project, a better approach in many situations is to form teams that are dedicated to developing, maintaining and supporting the product for the duration of the product’s existence.

Due to the fact that there is no end date or deterministic plans to focus on, like there are for traditional projects, teams can focus on working on and releasing the highest priority, most valuable features to production as soon as they are ready. Regular releases not only mean earlier return on investment for the business, but customers also see that the software is evolving and keeps them interested in using the product. This fast feedback from customer usage also helps to shape the direction in which the product goes.

My challenge at the moment is to get teams thinking in terms of product and delivering early and often, not about projects where everything is delivered at the end.

I’ll keep you posted on how I get on.

Image by flaivoloka


On a side note, I managed to finish the book I was reading as mentioned in my post ‘My new year’s evolution‘. On to the next one.

One thought on “Project v Product

  1. allan kelly

    Welcome to the world of #NoProjects

    Good to see more people realising projects don’t make sense.


Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.