Quality drives speed

- When a you're up against a deadline, it can be very tempting to ignore a few defects here and there just to get the product into the hands of the customers, however the speed you gain has to be paid back later with interest. The team at Bull learned this lesson the hard way. The amount of pressure to provide subscribers with more flexible delivery options was tremendous. The customers were asking for deferred delivery options, alternate delivery locations, and subscription pauses, just to name a few, and as the requests mounted, so did the concern about customer turn. At Bull, as with any other service, it's significantly more expensive to find new customers than it is to keep the ones you already have. Providing these features now seems critically important. So teams at Bull dove in to quickly design, code, and release the requested features. Unfortunately release dates promised to the sales team were rapidly approaching. To meet these internal deadlines, tests were rushed and most of the defects discovered were pushed to be handled after launch. They worried that if they didn't take these shortcuts, the late delivery would ensure lost customers. There was a big celebration following the release. Despite the niggling concerns in the back of the team's mind, the features were out and perhaps now the pressure would settle down and things could get back to normal. After the first weekend of rest in ages, the team regrouped to decide how to tackle the deferred defects. It was tough as new work continued to come in and some of the stakeholders wanted to continue to push them aside. So the defects that seemed urgent last week were allocated just a small portion of the team's capacity. The rest of the team started new features and other projects that had been on the back log for a while. Now that flexible delivery options were out, stakeholders were getting antsy to see progress on other priorities that had taken a backseat. Over the next few weeks though, the Help Desk began sporadically receiving complaints about those new options. Customers wanting to delay delivery got stuck in the process and had to abandon their orders. Others were able to complete their orders but experienced frustrating bugs with the UI. As time went on the number of complaints went up. Their goal had set out to prevent irate customers with fast delivery. They ended up creating them due to poor quality. Looking at the data showed the percentage of support requests to users was three times higher than before. Leadership declared the problem a stop the line level issue. This was now everyone's top priority. Have you been in that kind of situation before? Unfortunately the situation at Bull is all too familiar. Perfection might be an unattainable goal, but providing an enjoyable user experience for your customers is not. Unless you're a monopoly, taking steps to ensure customer happiness is crucial to business survivability. The folks at Bull learned a costly lesson. In the end it was estimated that confidently delivering quality features in the initial release would have taken two more weeks. This translated to an additional cost of approximately $50,000 considering salary, opportunity cost and anticipated lifetime value of any customers who might cancel as a result of the delay. The actual cost to fix the problems caused by escaped defects ballooned to $500,000. That's 10 times the cost of doing it right. Bull incurred penalties for breached agreements when they had to set aside project work. The cost to fix the issues after launch was much higher than if they had done it right the first time. What would have taken two days to fix took two weeks because of the need to verify with each customer and to ensure no new work was built upon the buggy code. In the end Bull lost three times the number of customers due to substandard quality than they ever worried about losing by not having the features at all. They also learned that recovering from a poor reputation is significantly harder than explaining why a certain feature is lacking. Sacrificing quality is a shortsighted tactic to increase speed. In the long run it cost significantly more than you saved by cutting corners and steals valuable time from future efforts. Great software teams improve their overall speed by building quality in from the start.