The Software Project Model is Broken

Yes, I went with a provocative headline to grab your attention.  It must have worked because you are reading this.  So don’t stop now - let me put some ideas forth to stimulate discussion and thinking. 

First of all, I’m not the only person who thinks that this headline has some merit.  My friend Chris Sheridan posted on this topic last year.  Other very smart people have also published pieces declaring the project model dead.  There is a “#NoProjects” hashtag on Twitter.  (Because you need a hashtag for a movement like this)  So I’m definitely not alone and completely off the ranch with this thought. 

There are two fundamental issues that we are seeing with the concept of “software projects”, especially as they exist in today’s world of agile software development.  Perhaps the concept of a “project” fits far better with a waterfall approach, but as our industry transitions to agile development, the concept of a project starts to confuse the situation.

First and foremost, software – and especially custom software – is often not thought of as a long-term investment in a capability or service.  It’s most often viewed as a large one-time expense to the business, because it’s typically fairly expensive to pay for during initial development of the product.  (Note: I’m ignoring the financial perspective of this via a cap-ex model.)

Secondly, projects (of any type) by their very nature are defined to have a beginning and an end, and are temporary.  Even the Project Management Institute defines projects this way.  So why are these two concepts causing issues?  Let’s explore…

Why do we use software in business?  There are several subtly different reasons, but at the end of the day, it is either to enhance productivity and drive down costs, or to provide a service or capability to customers to generate revenue.  And to be competitive today, companies need to provide a continuous flow of new value to customers.     

We already know that software is not a one-time investment…it’s like a pet.  Yes, you pick it up from the shelter, get a leash, get some food, pay for a vaccination, buy a bed and some toys, and quickly you are out $500…and then you buy food every week for the next 12 years…pay thousands in vet bills…buy hundreds of dollars of toys…pay hundreds in boarding fees over the lifetime of the pet.  So while you think you have a high initial investment, you actually end up paying far more over the lifetime of the pet than you did when you got home with them.  It’s very much the same with software.  While the initial investment to get that first product out the door seems high, it is going to be less than the ongoing investment.  Yet we focus on the cost of “the project” – that initial investment, and we often ignore the larger lifetime cost.  Companies also tend to ignore the competitive nature that innovative software solutions bring.  As I wrote earlier, to be competitive, companies need to continually invest in their solution to bring new features and capabilities to the market.  Projects with end dates don’t work well with the need to continuously provide value to customers.

This slides into the second issue: the end of a software product comes when the true end of its lifespan has arrived.  The end of a piece of software is not when the “project” is over – it is when that software is fully retired from service.  When it’s uninstalled from servers, removed from desktops and devices, and deleted from app catalogs.  Until then, it’s costing you money to run and maintain.  The end of a software “project” is when you want to stop investing in it – not when you reach some arbitrary or estimated date.          

So what are companies doing to re-think “projects”?  Companies doing innovative work in a continuous flow model have re-thought the concept of “projects” to an “investment streams” model.  We are seeing great success with organizations who have re-aligned their delivery teams by portfolio/product areas, which map to business investment streams. If there is a new capability or product your company wishes to invest in, it is smart to think about the level of investment that you are going to put into the capability over the life of it, from the first day to the last. After all, if it’s a great product, your users are going to be demanding additional capabilities – so don’t be stuck in a project mindset!