It might just be time to rethink what’s success in software development. As the world is rethinking so many things and virtual worlds becomen more real, is it time to rethink our attitudes and metrics for success.

Success

Project success: The project is completed on-time and on-budget, with all features and functions as initially specified.

Standish Group’s Chaos report.

Is that really the definition of success we want? Is delivered exactly to spec the real goal? Do users and customers pay for just meeting spec?

What is success?

Certainly in the past it was the case, technology was used to simulate (imitate) real world processes. So we tried to specify every aspect of what we saw in the real world process because the nerds that did the programming didn’t understand the process they were trying to simulate. Hence, we needed to be very specific about what we wanted. The only problem is it never worked. It virtually impossible to create specifications that are detailed enough to ensure that the software system has the required fidelity to the real world process. In addition, there’s things that work well in a real word environment that don’t work well in a virtual simulation. It’s as consistent as a sunrise that we’re going to discover new things as soon as real users interact with the software. There will be features that are missing, things that just don’t work right from a user’s perspective and new features that no one envisioned, as soon as user’s interact with the simulated virtual environment. User acceptance testing is always a surprise, and the bigger the project, the bigger the surprises.

The other aspect that doesn’t quite fit is that virtual environments don’t just simulate real world processes anymore. There is no real world equivalent to Facebook, Twitter, SnapChat. These are entirely virtual worlds. Maybe there are loose metaphors to postal mail or calls but, they are absolutely not derived from specifications drawn from these real world processes. So, defining success by meeting spec, may be completely irrelevant in these cases. Just maybe it’s time for a new metric for success.

Meeting spec

What really counts now is not meeting spec but, meeting customer’s needs, aspirations and desires. Virtual worlds have become more than imitations of real life, we need to refocus on how users and customers win with what we make. The excuse that we “met spec” when our work fails to return value and delight users, will not longer cut it. If you’re not working to delight users, they can easily by a SaaS solution that will be faster to implement and cheaper that your custom built solution that just “met spec”. I know this is a bit harsh but, it’s that important and I feel that strongly.

Success metrics

Measuring meeting spec is not the best way to judge our work. We need to shift our point of view, letting the finish line be meeting spec is a little short sighted. We need to figure out how our users and customers win with what we create. That defines a finish line much further down the road than just meeting spec. It makes developers vulnerable, because they’re going to be judged by the value of their work. It requires insight, engagement and care. When we work at this level both technical intelligence and emotional intelligence count. It’s time to start measuring success differently.

Here’s a few suggestions for success metrics:

  • How frequently is a new feature used
  • Does the feature, directly or indirectly, generate revenue
  • How often is the feature sighted in customer feedback

These types of measure require engagement with customers and users, not just lifeless spec documents.

What are your customer focused success metrics?