No Results Found

The page you requested could not be found. Try refining your search, or use the navigation above to locate the post.

When I started what eventually became MetaComet systems back in 1998, I wrote most of the code for the Royalty Tracker(r) System myself. While I would always test my work, it is a well known heuristic that software engineers make the worst quality control people. They have subconscious biases which prevent them from hitting the problems.

I continued to develop code up until early 2007. By this point we had grown to a 7 person company with several software engineers and some of the most respected media companies as customers. And while we had implemented some formal testing practices, we did not have a dedicated quality control program.

We were having severe customer service issues, and spending inordinate amounts of time fixing problems caused by our software – sometimes months at a time. We were dedicated to our customers, and were responsive and understanding, but as one customer put it, every time we fixed something, it felt like we had broken something else. Customers didn’t care that we fixed their problems quickly. They rightly demanded that they not have these problems in the first place.

The result was two negative business impacts. First, we had strained (though respectful) relationships with our customers. The result of this was lost business opportunities with those customers. We would always come up with ideas for improving their operations even more, and they would always tell us, first get your software stabilized. This in turn put extra pressure on our outside sales efforts. While a good portion of our revenue came from our existing customers, it was not nearly what it could be. And we lost valuable reference opportunities.

The second business impact was cost. We could not charge our customers for problems caused by our mistakes. We also frequently found ourselves throwing in freebies to help assuage our customers. So instead of generating revenue, our engineers and analysts were focused on fixing problems. In quality parlance, we had drowned ourselves in “technical debt” – getting money today, but needing to pay for it tomorrow.

In mid 2007, I began investigating quality control measures. We studied Six Sigma concepts and spoke with several quality consultants. From these learnings, we implemented several controls into our engineering processes. We hired dedicated quality control staff, and soon we did not allow any software to go out the door without passing QA.

We saw results almost immediately. We spend less and less time fixing our mistakes, and more time serving our customers. Our customers were decreasing their support calls, and we started making a big dent in our support backlog.

Today, nearly two years later, our customer relationships are great. We have eliminated our support backlog, and rather than spend our time fixing problems, we invest in R&D. For a couple of our customers, the tensions reached a point that will take even more time to totally turn around, but even those customers acknowledge the great strides we have made.

We were able to survive this quality issue because, quite frankly, our entire industry suffered from the same problem. You never heard of royalty system implementations that didn’t suffer from tremendous quality issues. One major publisher had to report a Sarbannes-Oxley “material weakness” in their royalty reporting. Another went 100% over budget and still don’t have a reliable system. Others spent years and lots of money before eventually abandoning their projects.

So the final reason why quality makes great business sense? Beacuse it is now a competitive advantage. As one customer once told me, our goal can’t be to “suck less” than our competitors. We have to aim to be great. And thanks to feedback like hers, we are great!

Request A Demo

"*" indicates required fields

Hidden
Hidden
Hidden
This field is for validation purposes and should be left unchanged.