Increase the success rate of your software projects by changing your reward system

By Adriana Beal – Jan 2015

Imagine pouring money into building a new software feature or buying a new tool, only to see it ignored by the intended audience. A few recent examples I’ve witnessed:

  • A powerful project management tool chosen by executives based on its ability to provide aggregated project data to help manage overall priorities was quickly abandoned when project managers found the application hard to use.
  • A new mobile app designed to solve a real problem failed to attract buyers.
  • Changes in how a software-as-a-service solution behaved and looked, made to improve the user experience, triggered angry reactions from customers who were happy with the status quo and demanded a rollback.

idea-screening Situations like these are more common than organizations like to admit. Even devotees of agile methods often suffer from the problem, patting themselves on the back when a new release is delivered on time, on budget and with the planned quality, only to realize that they’ve committed the biggest waste of all: building software that the intended audience refuse to use.

After spending 15 years as a consultant helping organizations of all sizes build better software, I’ve come to the conclusion that the easiest way to eliminate this problem is to change the reward system.

We all know that human beings adjust behavior based on the metrics they’re held against. If your company only rewards people who come up with new ideas, or ship software on time, can you trust they will do the right thing, and seek disconfirming information before starting a new project?  For a better success rate, it’s crucial to reward also the people willing to do the hard work that doesn’t come with any guarantees, and doesn’t necessarily ship anything, but offer the highest return on investment:

  • identify solutions that are truly appreciated as value by the people who will use them;
  • analyze the merit of proposed ideas, and reject the ones that can’t produce real value;
  • refuse to add new features to a product just because a competitor has them, and work instead on the aspects that can make a product remarkable, even if it means making it easier to use, or its advanced features easier to access, without adding a single feature.

Currently, not enough of the software process is devoted to understanding the customer/user context and the causalities that drive user adoption. What Peter Drucker used to say remains 100% true: it is foolish for a seller to spend money, time, and effort developing quality as he sees it, for the buyer may not see it that way at all.

If more companies start to reward the behavior that leads to saying no to ideas that don’t match the customer’s definition of value, we should finally start seeing more software projects producing the change the business is seeking.