Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

Update: Fixed a typo and a calculation error.

Josh Holmes has a great post on Return on Investment (ROI). And by “great”, I mean great even by Josh’s usual standards. He worked hard on this one. I was privileged to review three drafts before he published it; and by draft two, I was saying, “Josh, this one’s a winner. I’m going to reference this one a lot.” So stop reading me, and go read what Josh has to say. I’ll be waiting here when you get back.

OK, you’ve read it. Pretty scary, huh? But the scariest part to me is that even though Josh is right, he shouldn’t be. To quote Paul Simon, these are the days of miracle and wonder. To be specific, these are the days of software. I’m not saying this is some grand new revelation; but businesses and software people forget just how much software changes the world. Today, whatever your business may be, you may find that deep under the hood, you’re selling software. Oh, not everybody, by any means. Pastry chefs are still selling pastries, day care workers are still selling child care, and airlines are still selling transportation. But a lot of people who once sold simple goods and services are now selling software, whether they realize it or not.

Let me draw some examples from projects where I’ve worked.

 

Material Handling

I’ve worked on a number of different material handling projects for a couple of leading companies in the field. This is a long-standing, well-established industry, concerned with moving packages and baggage and loads from one place to another with minimal human effort. If you’re not in the industry, you’ll likely think of it as “conveyor belts”; but there’s a lot more to it. There are conveyor belts, yes, but also…

  • Rollers
  • Sorters
  • Packers
  • Stackers
  • Scanners
  • Lifters
  • Diverters
  • Carts

And lots, lots more. But yes, it all starts with the simple conveyor belts and rollers that move a box from Point A to Point B.

Except nobody wants those any more. Oh, not nobody, but not enough customers to sustain the industry. Rollers and conveyors from Point A to Point B are a simple, long-solved problem.

No, what customers want today is a system to take a box from Point A to Point Wherever The Label (Or RFID Tag) On The Box Tells Us To Send It. Point A to Point B requires some human to look at the box, decide where it’s going, and put it on the right conveyor. What the customers want is for the computer to “just know” where this box is going.

And it’s more than that: they don’t want the box to have a label that says “Send this to Shipping Dock A”. No, they want it to have a label that says, “This box contains Order #1232. Send it to the right destination.” And sometimes they even want the computer to look at the box and say, “Well, this box contains 50 copies of The Dark Knight, and Tucson needs those; but the truck to Tucson is full, and Orlando needs 70 copies, so we’ll send them there instead, and then reduce Orlando’s outstanding count by 20. The truck for Orlando is at Shipping Dock C, so send this box there. Reschedule Tucson’s fulfillment for their next truck.” In other words, what customers want is not a material handling system, but rather a decision system that controls material handling.

And if your customers want a decision system, that means you’re selling software.

This is news to most of the material handling industry. After all, the hardware to move all those boxes around might range in the millions of dollars, often tens of millions or more. It may occupy literally acres of space. Parts of it may weigh in the tons. Compared to that, the software seems like such an insubstantial, insignificant thing. Even the cost is insignificant, though you can bet the project managers will complain that the cost is too much.

But that’s because – as Josh points out – they see the software as a cost center. It’s not. It’s a profit center. Without that software, those acres of steel and motors and conveyors won’t move those boxes anywhere. Worse, with bad software, they’ll move the boxes to the wrong places. And so without quality software, customers aren’t going to pay for the material handling systems.

Does that mean you’re only selling software? Nope. No line of code ever moved a single box by itself. The code has value because of the sorters and diverters, and the sorters and diverters have value because of the code.

But the difference is this: the material handling project managers know that the sorters and diverters and other equipment are profit centers. They know they’re selling those. But all too often, software is charged as an overhead or a cost center, not a profit center. So rather than try to sell more and better software, they try to skimp on the software costs, cutting schedules and budgets. And as McConnell has documented, the result is usually longer schedules, higher costs, and lower quality.

The software managers in the material handling world need to read Josh’s post, understand it, think about it, and think how they can express the value of their work. A representative material handling system might cost the customer $20 million. If the software to run that system costs $500,000 to build, then cost-center accounting sees that as $500,000 of lost profit. Management will wonder why it cost so much, and wonder how they can cut those costs. What may follow is pressure and effort to cut costs in ways that make software development take longer and cost more.

But if the software managers can see their group as a profit center and can explain it as such to the executives, then the whole picture changes. When they understand that better software leads to more sales or easier sales, executives will want to invest in better software development tools and practices. Josh gives some good starting points toward that culture change. I would add these observations:

  • The ROI of software starts with Requirements. Yes, that has become a recurring theme for me. There are good reasons for that. With a foundation of well-defined requirements and a process for accommodating change, software managers can show exactly how much of the customer benefit is directly dependent upon the software. If the system has 100 required functions and 90 of them require custom software implementation, then 90% of the profit of the system is directly dependent upon the software. That 90% is also dependent upon properly functioning hardware as well, so you can’t claim all of that profit as your accomplishment. In the material handling world, I saw a team of nearly 100 assemblers, machinists, construction workers, engineers, and other hardware folks install a system controlled by software written by 10 developers. I think that’s a good rough approximation: software provides 10% of the value of the systems with which it works. (In office systems and other systems not involving device controls, I would say that ratio is more like 50%, maybe higher. This Tablet PC would be useless to me without Windows XP, Journal, OneNote, MS Office, and Visual Studio, which collectively cost more than the Tablet PC.) So in our hypothetical example, the system has a value of $20 million; software is involved in 90% of that value, or $18 million; and software accounts for 10% of the value of those components, or $1.8 million. If the profit margin of the system overall is 50%, then you can argue that the software contributed to $900,000 in profit. These are back-of-the-envelope calculations. A more accurate estimate would require time spent looking at the value of each individual requirement and the percentage of that value contributed by software. But in our hypothetical example, $500,000 of software development costs yielded $900,000 in profit, for an ROI of 80%.
  • Hammer home the destructive effects of schedule compression, as described by McConnell. Schedule compression beyond about 20% leads to longer, more expensive schedules with more errors and more dissatisfied customers. If the potential ROI is 80%, the actual ROI will be a lot lower if the schedule compression increases the schedule by 50% and the costs by even more. McConnell explains how this happens, and why it’s almost inevitable.
  • There is a way to cut schedules effectively and productively: develop a true software engineering culture and a culture of quality. There is a better way to build software and systems, but “code faster!” isn’t it. Train your teams to be better developers. Improve your requirements process. (No, I’m not done with that theme yet.) Emphasize defect reduction, not schedule reduction, because defect reduction is one of the most effective ways to reduce the schedule.
  • Invest for the long haul. Near the end of my first material handling job, the team worked on building a good, well-engineered, reusable and configurable platform that could address a wide range of customer needs. This platform didn’t directly address the needs of any existing customer, so it didn’t receive a lot of management support. Again, this was cost-center thinking: “Why are those programmers wasting money on code we don’t even need?” My second material handling job, nearly a decade later, was with a company which had faced those same issues, asked those same questions, and decided to invest in the software platform anyway. It had some infamous rough spots in its earliest implementations. But by the time I worked there, that baggage handling software was nearly a decade old, and it just worked. Oh, there was always some amount of custom coding for every project; but for the most part, if they knew how many airport docks and how many baggage inducts and baggage claims they had to support, they knew to a high precision how much the software costs would be. And most of those costs were configuration costs. I often said they had Moore’s Law on their side. Moore’s Law says that computing power/speed roughly doubles roughly every 18 months. That means that after a decade of life for that software, server power had increased roughly 128 times; but while airports get larger over time, they don’t grow 128 times in 10 years! The software architecture that was a good solution in 1997 was a great solution in 2007, without any significant upgrade to the software.
  • Don’t cling to the long haul. As much as I think the baggage handling company was smart to reuse a successful architecture, you must always consider the competitive advantages offered by new technologies. When the baggage handling company did have to make code changes, their reliance on old tools and technologies made every change more expensive. Periodically reassess the value of an existing investment vs. the potential gains of a new investment.

Vehicle Diagnostic Systems

My most recent contract was a project for building vehicle diagnostic systems. One part of the team built the tool that connected to the vehicle bus and communicated with vehicle systems; the other part built the tools that talked to that tool via Bluetooth and USB, and then interacted with the user and with online systems.

Now with a description like that, you might guess that the company knew they were selling software. And you would be right. Oh, it was a mixed hardware-software product, but they were much more clear on the importance of good software than I found in the material handling world.

And yet – while I mean no offense to a great team and some great people that I’m already missing – the organization didn’t approach this project as a software project. They approached it as a manufacturing project.

A typical mass production manufacturing effort boils down to finding and implementing tools and processes to do the same thing over and over, so that you can sell and serve as many customers as possible for as little cost as possible. The rules are different for custom manufacturing; but for mass production, profit lies in reducing the number and costs of the repetitive parts of the production process.

Let’s say you’re building mailboxes. A traditional home mail box consists of a base, a shell, an end cap, a door, a door pull, a door catch, a flag, a flag stop, two swivels for the door, a swivel for the flag, and 21 rivets:

Mailbox Parts

Mailbox

Every mailbox, according to this design, requires a person or machine to put the parts in place and insert the rivets and swivels. If every rivet and swivel can be inserted in one second and it takes ten seconds to align all the parts, then a single worker can assemble a single mailbox in roughly 34 seconds. If instead the shell, end cap, door catch, and base can be injection molded as a single piece complete with a flag stop and indents where the flag and door attach, and the door and pull can be injection molded as another single piece, then that same worker can assemble a single mailbox in roughly 3 seconds.

But that throughput assumes the worker has materials always ready to hand. Suddenly the process is limited not by the worker’s assembly rate, but by other factors: how quickly can you deliver parts to the worker, and how fast can the worker really work without slowing down due to fatigue? Those questions apply to the riveted design as well, but less so: no matter how fast you deliver the parts for the first design, the riveting is the bottleneck.

Once the parts availability becomes the bottleneck, the industrial process engineer changes focus: instead of trying to improve the design of the mailbox, the engineer must improve the design of the process that delivers parts to the worker. Or perhaps the engineer must design an improved assembly process, maybe improved machinery and tools, that will make less work per mailbox. The company makes money on each mailbox built, not on each step performed by the workers. Whatever your cost and effort is per mailbox, that’s a 1-for-1 cost: one unit of labor per one mailbox sold. If you can reduce that unit of labor, you can increase overall profitability and employ more mailbox workers.

So it’s common for industrial process engineers to invest a large amount of effort designing a more efficient manufacturing process. This effort can be seemingly large; but it’s is a one-time effort. Once it’s done well once, it’s done well for all of the mailboxes produced. So the cost of that process design is amortized over the tens or hundreds of thousands of mailboxes produced, and it reduces the overall cost of production for each mailbox.

This is Industrial Process 101; but here’s where the mistake comes in when you see software development as akin to manufacturing. Software development is like manufacturing, in a sense; but it’s like process design, not piece manufacturing!

The software equivalent of the worker assembling mailboxes over and over all day long is users applying the software over and over all day long. The value to the user (and the user’s organization) increases when the user can get more done with less work, and so get more tasks done in a single day. Just as the industrial process engineer creates value by improving the process and reducing the manufacturing cost, so too does the software team create value by improving the software and reducing the usage cost.

But this means that traditional manufacturing process improvement approaches can be aimed at the wrong targets when applied to software development. In manufacturing, it can be cost effective to spend more money on design process improvement to reduce the money spent on manufacturing; but when traditional manufacturing process improvement approaches are applied to software, often the goal is to spend less money on software development. Yet somehow, we expect those “improvements” to improve the quality of the finished product.

Now I’m not saying there’s no room to cut costs in software development. There are inefficient ways to design industrial processes: if your design team relearned basic facts every time they approached a new production line, or they ignored proven practices from other production lines, then they would waste a lot of time and money on lessons learned and relearned. The same is true for software engineering. Indeed, there’s an entire field of study, Lean Software Development, aimed at improving the development process in a similar fashion to the field of Lean Manufacturing.

But simply applying Lean Manufacturing practices to software development can be misleading – even counterproductive – because Lean Manufacturing aims (in part) to reduce the time required for repetitive processes; and in software development, there are no repetitive processes. Oh, that’s an exaggeration, of course, but it’s close enough to true. Industrial process engineers have repetitive processes, such as reading email, filing reports, printing blueprints, etc. In a similar fashion, software developers have repetitive processes, such as reading email, filing reports, compiling code, etc. But in both disciplines, the key work, the important and most time-consuming work, is brain work: thinking about the problems, proposing ideas, presenting ideas, reviewing ideas, revising ideas, etc. And this is work that virtually never repeats! It will repeat if you keep reinventing the wheel; but a good team should know standard patterns and solutions for common problems, so they can concentrate their efforts on the unique aspects of a new project. The truly repetitive processes – checking email, compiling code – are more amenable to fiscal solutions than process solutions. Buy your developers faster computers and better tools: it’s the closest equivalent to getting the mailbox worker a faster assembly tool.

And I’m going to repeat myself yet again: the most productive way to reduce the cost of software development is to improve your requirements process, followed closely by creating a true software engineering culture and a culture of quality. Those are goals of Lean Software Development and are consistent with Lean Manufacturing. Interestingly enough, they involve creating quasi-repetitive processes: standard processes for doing standard categories of work, while recognizing that ideally no work should ever be repeated. A standard way of testing code, a standard way of reviewing code, a standard way of communicating designs: these can add value if done right. However, they can also become straitjackets that prevent a team from solving a problem. I have a lot more to say on the value of quasi-standard quasi-repetitive processes; but that’s starting to veer pretty far from our topic today.

And that topic, you’ll recall, is ROI. It’s easy to figure the ROI of industrial process engineering:

ROI = (New net profit per part – Old net profit per part) * Number of parts produced / (Cost to design the new process + Initial cost to implement the new process) – 100%

This gets slightly more complex when you factor in time: Number of parts produced in how much time? In early usage, you’ll almost always see a negative return, because (as Josh mentions) there is a certain length of time it takes to recoup the initial investment. Businesses will usually set a time horizon in which to estimate ROI: 1 year, 3 years, maybe longer.

A similar calculation applies to the ROI for better software:

ROI = (New net value of work per user – Old net value of work per user) * Number of users / (Cost to develop the new software + Initial cost to deploy the new software) – 100%

But there’s a complication here. In the typical industrial situation, the same company is both designing the new process and manufacturing the parts. The ROI value is more clear-cut that way, because what matters most is the overall bottom line for the company. The same is true for in-house software development; but when you’re selling custom or shrinkwrap software to external customers, the value of the work and the deployment cost are measured by the customer, while the cost to develop the software are measured by your company. That’s a complication, but more of a deal negotiation concern than an ROI concern. The calculation in this case turns into two calculations:

Customer’s ROI = (New net value of work per user – Old net value of work per user) * Number of users / (Cost to purchase the new software + Initial cost to deploy the new software) – 100%

Your ROI = Cost paid by Customer / (Cost to develop the new software + Initial cost to deliver the new software) – 100%

The Customer’s ROI, along with many other factors, will determine what cost they’re willing to pay; and then that value will determine your ROI. You can make educated guesses of what they’re willing to pay, and then use those in estimating your ROI. And remember: just as with industrial process engineering, the initial return will almost always be negative. You have to prepare your arguments for that moment, when it seems like the system cost a lot and is too difficult to use. Is it really too difficult? Or is it just new and unfamiliar? Unless you’re very good at defining and communicating your requirements, users will always see “new” as “difficult”, and then cling to old and familiar; and in the process, they forget that the old was once new and unfamiliar, too. That’s why these ROI calculations include a deployment cost: that’s not just a cost for physically shipping and installing the code, but also for training the users and answering their questions and correcting their early mistakes. And lest we forget: finding and correcting our early bugs, and deploying corrections for those as well.

Conclusion (For Now)

Well, this has gone a lot further afield and gotten a lot wordier than I originally expected. (Regular readers are probably less surprised than I am.) I could go further, discussing ROI for training, ROI for technology upgrades, ROI for requirements analysis, ROI for architecture, ROI for community involvement, and ROI for employee retention. But each of those is a lengthy essay in its own right, and I’ll need some research before I’m ready to tackle some of those.

But I hope I’ve added some personal experience to Josh’s excellent post. Many projects can be technological successes, yet be seen as costly, not as a valuable investment. The difference: do we calculate and demonstrate an ROI? Or do we let stakeholders see only the cost of the software, without seeing the full return on the software?

Posted on Tuesday, February 24, 2009 3:33 PM It's all about communication. , Requirements Patterns and Antipatterns , Development Processes , Code is not Enough | Back to top


Comments on this post: You're Selling Software

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Martin L. Shoemaker | Powered by: GeeksWithBlogs.net