80% of what?

I’m a big believer in the 80-20 Rule. If you haven’t heard of this, it’s the idea that almost everything you do yields 80% of the benefit with the first 20% of effort. Similarly, you’ll find that 80% of your sales come from a 20% subset of your offerings. Stuff like that.

Sure, it’s a back-of-envelope rule of thumb sort of deal, but still a useful planning concept. (I love heuristics.)

On Monday, I blogged to the effect that non-software startup companies be satisfied with commercial off-the-shelf software that satisfies 80% of the functionality they require… because that’s so much cheaper than embarking on a new project when you are already hard up for cash.

I underexplained that a little in my Tweet that post, and my man Josh Walsh caught me at it. Josh argued with my 140-character summary. He pointed out that it’s often better to push out 20% of the work effort on a project quickly, so you get that 80% of value right away and the customer gets enough tangible benefit to be able to give really good feedback as you develop the rest.

I think Josh is totally on to something there. Let me amplify my point: If you’re a self-funded startup, you can probably get 80% of the expected benefit of a software installation with the first 20% of expenditure. If you want 100% benefit, it’s likely to cost five times as much as getting that 80%. And it’s likely that it’s just not worth it to you at this early stage.

What’s wrong with this analysis

I’m tossing around 80% this and 20% that like they mean something. When you’re making bricks or rocket fuel, it’s easy to measure percentages of completion, but what does it mean to say a software project delivers 80% or 22.73% of the desired functionality? What is 20% or 93.21% of the effort?

I propose that we talk about the desired functionality in terms of Return On Investment (ROI). You probably can’t do this very precisely unless your business already has a lot of structure, but try in general terms to list the features and functionality you might want to include in a proposed software project. List only the “payload” features–those that directly solve problems and deliver value (i.e., income or profit) to your business.

Say what?

For example, if you’re thinking of an online dispatching system for your bike messenger service, your list might look like this. (I’m just making it up. I’ve never done this.)

• Dispatcher work station can log pickups and dropoffs
• Dispatcher work station can calculate delivery charges
• Dispatcher work station can create invoice records
• Dispatcher work station can Google-map a route
• Dispatcher work station can send SMS to messengers
• Dispatcher work station can send batches of pickup and dropoff notices to messengers via SMS
• Messengers can report delivery status via SMS
• Messengers automatically relay GPS data to server
• Customers can make delivery request online
• Customers can check delivery status online
• Customers can check invoices online
• Customers can pay invoices online
• Customers can view messenger’s GPS location in real time.

(Yes, Agile people, I am sneaking in the “user stories” concept. Shhhh.)

Obviously some of these features are incredibly useful, and some are kind of silly. Most are in between. But you could go over that list and assign a dollar value to each item. Ask yourself, “If I could have this thing magically taken care of, how much money would I be willing to part with for it?” So you might think the invoicing feature is worth $1000 (over a relatively short-term payback horizon) in the time it saves your billing staff, but allowing customers to use your website to request a pickup and delivery is worth $10,000 because you hope it will build revenue. (Better still if you have customers who have already told you they want the online ordering and will use it.)

The funny thing

The funny thing about a lot of business software development is that the incredibly vital features are often really easy to implement, and the ones nobody cares about are a real pain. Sometimes what my clients consider “vital” is surprising too.

A really long time ago, I made a specialized mailing list application for a local nonprofit organization. It was set up to help housing code inspectors keep track of walking the neighborhood, so it had nifty features like address parsing (turning something weirdly formatted like “Archwood 2804” into street => Archwood, designation => AV, number => 2804, unit => null, zip => 44109) and a way of printing walk lists that went in ascending order of odd numbers then descending order of even numbers so an inspector can easily go up and down a street with minimum backtracking.

This was in the bad old days of Clipper Summer ’87. It was really difficult to make all this stuff work. Did they love the address functionality? Kind of. What did they find really awesome?

The startup logo, which was made of ASCII and DOS block and line-drawing characters, was a profile view of a cat. The cat’s eye changed from a lower-case “o” to a hyphen, then paused and turned back into an “o,” giving the effect of a wink.

People couldn’t get enough of the winking cat. They actually started and stopped the software just to see the wink. If we’d valued each feature individually, they would have loaded it all up on the cat I’m afraid.

So there’s a limit

Had I put 80% of the time on that project into making the cat wink, that would have been ridiculous. But in a very real sense I want the customer to define the attractiveness or worth of features.

Some Agile development shops play a game with their customers: they write down desired features, one per index card, and the developers stick each card with the amount of work they think each card will take to complete. The amount can be in days, hours, bananas, or whatever you like, but it always indicates an amount of time/money.

The customer and the development shop already know how many days, hours, or bananas they have available in the near term. So all the customer has to do is arrange the cards, top to bottom, in the order of preference and priority of those features. If you go down the deck counting up work units, and stop when you’ve reached the limit of resources, you’ll have a pretty good idea of how much will get done in the short time horizon. (Yes, I’m talking about “sprints.” Shhhh.)

Really? Would that client long ago have put the winking cat at the top if it would take 80% of project costs? Of course not. But for the 1% or less that it ended up taking, they sure got a lot out of it.

The money connection

So if you’re the customer in a software development project, take some time–as much as you need!–to figure your ROI on every feature you’re requesting from your development team. That can guide your selection of “cards” (even if you’re not on a card system) and your ordering of them (even if you don’t have anything like “sprints”).

Now here’s my question for executives and operations people: How do you figure ROI on a software project? Okay, it’s two questions: How also do you figure ROI for a feature of a software project? Let’s talk about it. The comments are yours!