Products vs Projects – On software development in the enterprise

When it comes to software, the pendulum is swinging back towards “build” in the build vs buy decision. Enterprise and government organisations alike that aren't software companies are building software. They’re traditional organisations that are great at their core business, but that core business isn't building software.

It makes sense for them to build - if you don't become a software-driven organisation, you'll eventually give up your advantage to a competitor, or you’ll not live up to the needs of the customers that you work for.

The Product Mindset

I want to cover the concept of products vs projects. Software development, generally, should be treated as building a product, not doing a project. In my experience, many traditional organisations are more familiar with treating IT initiatives as projects. This is a mindset, not a methodology. Agile is a methodology. Product vs project is a mindset. And it's critical to the long-term success of building a software product in your organisation.

Traditionally, a project is a temporary mechanism to achieve an agreed outcome. By definition, a project ends after the agreed outcomes are delivered or passed into operational mode. Usually the team disbands on completion. This approach works well for achieving fixed, easy to scope outcomes, with clear completion criteria – like an office move, network rollout or datacentre migration.

With digital products, there is often a project to initiate their creation, however after they are created, the digital product lives on. Digital products require constant adjustment to succeed in the long term. They’re never really done.

The Nature of Software

Building software is different. Building software is not like building a house. Once a house is done, it's done, and generally requires only minor maintenance.

Building software is more like building an F1 car – and then racing it. You need an engineering team to design and build it, but in order to continue to use it - to race it - you need an engineering team that will keep re-engineering it, and maintaining it, even after that initial construction. An F1 car will break if it's not maintained, and in order to keep winning races, it needs to keep improving. It needs continuous development. It needs continuous evolution. This is especially true for web-based, cloud-connected software.

If your software is in production, live, processing data, interacting with users, and connecting with third party APIs - you have a product. It's not a project that's been done, it's a product that will live on. If you're doing it right, it's a product that will improve the core of your business, and a key part of your software-driven enterprise.

Continual Improvement is Key

Minimal maintenance software might have worked occasionally in the past when software was simple. But software needs to keep changing. It needs to keep responding to the market that the business is in. It needs to keep winning the race that it was engineered for. And even if all this is deemed to be static - but is it ever? - the world of tech around your software will constantly change anyway. New devices, upgraded browsers, and changed APIs. The unmaintained software becomes useless, or worse, it can become a critical part of your business that holds you at ransom until it is rewritten. It becomes a part of your business that holds you back.

One of the hard parts of products vs projects in a traditional organisation is the annual budgeting cycle. But that's just a hurdle to overcome to get the result your company needs – and that’s a topic for another day.

- JK