Product versus project

What I discovered by using these two contrasting approaches resulted in a profound shift in my thinking: When delivering software as a product, there was much more opportunity to focus on value because the product team was long-lived and was able to adopt an iterative/incremental approach to delivery. We, therefore, had multiple opportunities to deliver, enhance our strategy, and get things right.

However, with software delivery as a project, more often than not the software delivery team only had one opportunity to get it right. Successfully delivering a software project to meet expectations with only one shot just didn't happen that often.

Even when we did deliver, it was often as a result of a considerable effort on our part to get it across the line, including many lost evenings and weekends.

Subsequent revisions of the software were often handled as separate projects and likely by a different software team, often leading to a lack of continuity and knowledge sharing.

As a result, there was a distinct lack of trust between us—the software professionals and the people we were building software for. Unfortunately, "us" often became them and us with unmet expectations being so often the cause of the rift in the relationship.

We tried to solve this problem by making things more precise. Unfortunately, the version of precision the project mindset opted for had only three predictive aspects—scope, time, and budget. All three of these things are very difficult to quantify when tied to a software project where complexity, uncertainty, and sheer volume of work could and did amplify any errors in these calculations. 

However, the single most significant problem when you tie down all three of these factors, scope, time and budget, is that something colloquially known as the Iron Triangle forms. Refer to the following figure:

When you set scope, date, and budget like that, there is little room for maneuverability to deviate from the plan. To help mitigate risks, most will create buffers in their schedules. However, the rigid nature of the triangle means that if and when overruns start to eat more and more into the buffers, something else has to give. And what usually occurs when a software development team is under pressure to deliver? One or more of the following qualities of your software product will start to suffer: 

• Functionality: Whether it works as expected
• Reliability: How available it is
• Usability: How intuitive it is to use 
• Scalability: How performant it is
• Maintainability: How easy it is to change
• Portability: How easy it is to move to a different platform 

To understand why precision in predicting the outcome of a software project is so complicated we need to unpack things a little.