Re: Practice: Pay-Per-Use

Recently our team was asked "If we could measure one thing and one 
thing only and report it back to the company what would it be?"

Currently I am on an ECommerce team providing internal systems for 
managing and processing orders.

Many ideas were submitted. Mine got no attention in our meeting were 
we went over the suggestions.

The other suggestions went like this:
Hours the servers have been up without a problem.
Number of new features delivered on time.
Number of orders successfully processed.
... and a few more on similar lines...

My suggestion was measure how much money or systems earned or saved. 
I suggested that this would not be an easy thing to measure (but it 
was fair because they don't ask me to write easy code) but would give 
a number that is meaningful to people where decisions are made 
concerning staffing, equipment, budgets, etc.

Many of our systems save money because we have replaced services that 
were outsourced to "large" companies which charged plenty of money. 
Many of our systems are a piece of earning money in that we give 
marketing special flexibility in the ability to make product 
offerings.

I don't know why my suggestion didn't make it to the meeting for 
discussion. My paranoid side says, "no one liked it". I don't know 
the real reason. I should ask.

Geoff

--- In xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx, "Kent 
Beck" 
<kentb@xxxx> wrote:
> With pay-per-use systems, you charge for every time the system is 
used.
> Money is the ultimate feedback. Not only is it concrete, you can 
also spend
> it. Connecting money flow directly to software development provides
> accurate, timely information with which to drive improvement.
>   Lots of software is already pay-per-use. Telephone switches, 
electronic
> stock exchanges, and airline reservation systems all charge you a 
fee per
> transaction. While pay-per-use has business advantages and 
disadvantages,
> the information it generates can help improve software development.
>   The ultimate form of pay-per-use I've seen was in a messaging 
product.
> Users were charged per message. Each story in development was 
deliberately
> selected to encourage more messages. Support for a new handset, for
> instance, came with both a cost estimate and a revenue estimate. 
The team
> analyzed the usage of the system to provide feedback for the 
accuracy of the
> revenue estimates. The team used this information to optimize both 
cost and
> profitability.
>   Today's typical arrangement requires the customer to pay for each 
release
> of the software. Pay-per-release opposes the supplier's interests 
and the
> customer's interests. The supplier is selfishly motivated to have 
lots of
> releases, each containing the least possible functionality 
necessary to get
> the customers to pay. The customer wants fewer releases (because of 
the pain
> of upgrading), each containing lots of features. The tension 
between the two
> sets of interests reduces communication and feedback.
>   Even if you can't implement pay-per-use, you might be able to go 
to a
> subscription model, in which software is purchased monthly or 
quarterly.
> With the subscription model, the team at least has the retention 
rates (the
> number of customers that continue to subscribe) as a source of 
information
> about how the team is doing. An even smaller change of business 
model is to
> weight contracts more toward support fees and less toward up-front 
revenue.
>   One objection to pay-per-use is that customers want predictable 
costs. If
> the price advantage of pay-per-use is large enough, customers may 
not mind.
> A team using the information provided by pay-per-use should be able 
to do a
> much better job than a team relying for feedback only on license 
revenues.