Let's all join hands: How software intensive businesses make money

17 Oct Let's all join hands: How software intensive businesses make money

My father was a lawyer in Houston, Texas. Many of his clients were successful small business owners and investors. When Enron imploded, he asked one of them, “How much money did you lose?” “None,” the client replied. “I never bought any Enron stock. I never could understand what they did to make money.”
Software-Intensive Businesses (SIBs) spend money to create and operate differentiating software applications for the same reason that any business does anything — to make money. But complexity, layered on top of mistaken beliefs, easily gets in the way.
In That Sinking Software Feeling, I explained how SIBs lose business momentum due to unsustainable software development practices.
In Software is Different, I used the IT Pyramid to show how different elements of IT deliver value in different ways, and how management approaches for both IT and business must reflect that.
In this article, we’ll explore how SIBs make money, some of the things that can go wrong, and what to do about them.
The software value circle for a SIB

Like the Pyramid, I’ve been drawing this diagram on napkins and whiteboards for about five years. It’s called the Software Value Circle.
Software companies would also have benefits (revenue) from software license sales and related services.
The background is the organizational context. Business people are on the right, software people on the left, executives at the top, and employees at the bottom. The executives are primarily concerned about the costs and benefits of the software, and all other business assets.
Software developers and users (employees, and customers and partners) focus on the features the software has (and doesn’t have). Does it do what I need? Is it easy to use?
On the software side, people acquire and create software and keep it running. Their pay, along with third-party software licensing, infrastructure costs, and maybe some user training, drive the total cost of ownership (TCO) of the software.
On the business side, people use the software to conduct activities that satisfy auditors and regulators, reduce operating costs, increase revenue, and support decisions about how the business ought to change. These activities drive the benefit side of the equation.
That takes us back to the executives, who oversee the SIB’s assets, including software. Software costs money, but if it delivers the right features, and people use them effectively, the software makes (or saves) more money than it costs.
That’s how SIBs use differentiating applications to make money.
What goes wrong?
Some potential problems are easy to see, just by looking at the Value Circle. Others are more subtle.
Wrong features and projects
There are always more ideas than resources. So someone, somewhere, somehow, decides What’s In and What’s Out. The wrong features increase the total cost and complexity of the software and make it harder to use.
If people who don’t care or know about cost and benefit are selecting features, that’s a governance problem. If the predicted costs and benefits used to select features are seriously in error, that’s an estimation problem.
Governance problems are hard to fix because they involve power and politics. Someone is benefiting from the present system of selecting features, even if the whole business isn’t.
Estimation problems are hard to fix because, as Yogi Berra says, “Prediction is hard, especially about the future.” Everyone can get better, but no one can get good enough to make cost estimation errors a non-issue. Benefit estimation gets even less attention, and errors can have an even greater impact on a SIB.
Good governance involves both business and software people working together, continuously. Once you’ve made the easy improvements to your estimation, use an iterative-delivery process to get the 80/20 rule working for you. That will minimize the impact of estimation errors on software value.
Right features, but no realized benefit
If a feature doesn’t work properly, is too slow, or is merely frustrating, people won’t use it. People may need to be trained to use complex features effectively. Unused features are a waste of money.
A feature can be used and still not realize benefits. If a process has been made more efficient, but the people haven’t been given other tasks, the result is a paper savings, but not an actual one.
Continuous quality practices, training developers in usability, and using iterative delivery to get user feedback and refine features, will largely eliminate features that don’t work. Involving business process owners in feature selection and software design, and making them as responsible for the benefit side as developers are for the cost side, will help bridge the last two feet between screen and user needed to realize benefits.
Delivering the right features in an unsustainable manner
This was addressed in That Sinking Software Feeling. Mistaken beliefs lead to misguided practices, resulting in technical debt. Existing features cost more to maintain and new ones become more costly to create or acquire. Eventually, the software becomes a liability.
Beyond us and them
It’s easy to lose sight of the real goal. A SIB’s software efforts must deliver actual benefits that exceed actual costs.
An on-time, on-budget project is a business failure if the benefits are insufficient. Conversely, a project that exceeded initial cost estimates but delivered extraordinary benefits should rightly be judged a success. (Such projects aren’t out of control, by the way. They are truly well managed).
Collaboration between business and technology people, from executives to employees, enables success. Business people are better able to estimate benefits, assess doneness of features, and to lead the process and organizational changes to realize them. Software people are better able to estimate costs, present options and tradeoffs (and of course make software).
Business and technical people must join hands around feature implementation and details at the employee level, and around feature portfolio management at the executive level. The Software Value Circle shows why.