Two years ago, Electronic Arts, the second-largest U.S. video game company, ran on promises. … Several of EA’s biggest 2013 releases, including entries in its SimCity and Battlefield franchises, were so bug-ridden on release that they crashed game servers and were essentially unplayable for days or weeks before they were fixed. … Last year, the company tried something new — delaying games. … [P]ushed back its next PGA Tour game, the first in years that don’t include Tiger Woods, from March until sometime between April 1 and June 30. EA Tries Selling Video Games That Work, Bloomberg Businessweek, March 16, 2015.

Our best selling product was our buggiest. We had gotten to the market before our competitor and so while things didn’t work so well, they worked well enough and people were buying our products. Woo Hoo! Success!

After that, since our future products were based upon our current product which was software intensive, they were buggy also. Our competitors finally got products out to the market and while they were not perfect, they worked a lot better than ours did. For the next few years we could hardly sell anything as it took us forever to get them into working form while our competitors built on their much more solid foundations and could get new and upgraded products out to the market quicker.

The CEO asked me why was it that our competitors could get out a product faster than we could? His solution was that we needed to go faster, deliver products faster and in a shorter period of time. I had showed him that it was taking us on average 18 months to deliver a new product but we were constantly promising everything from 12 months to 15 months. The difference between our promises and when we delivered averaged three to four months late with none being on time, not even close. Customers could not plan product introductions, training, marketing and roll-outs because they could not believe any date we gave them.

So was the solution, as EA did, to delay our products? No, that didn’t work for us. Picking a date and then later delaying it for three to four months pretty much insured we had a low quality product, which while the product often looked good, it did not perform well. Rushing to get something done by a date and then “fixing” it by pushing out the date did not produce a quality product, we learned. We had lots of experience doing that. Delay is what normally happened because our customers would refuse to take our product.

For the reason why see In Project Management 9+3 Is Not Equal To 12

How did we fix it? Simple. We started on our next product three months earlier than we would have normally started on it. The product team was shocked at the notion that when they proposed a new product, they were already three months late. I recall folks demanding “What is the rush? We have plenty of time!” as I pushed for them to get going. They didn’t realize that the major problems had always originated at the beginning of the project. Everyone just knew that things only went wrong at the end of the project.

For more on getting schedules right see Getting The Schedule Right Is Hard But Not For The Obvious Reasons

What happened? Well, the project was just as crazy and crisis ridden as any of our previous projects. The difference was when we had finished and the customer had accepted our product, it was still on time and our quality had improved — improved dramatically. Our business manager, one of my biggest resistors to change, quipped “Bruce, this stuff really works!”

Once we got our project management and product quality under control then we were set up to improve our speed to market. Actually, it happened naturally without us needing to specifically push for speed improvements.

For how this works see High Quality Gives High Productivity At No Extra Cost

Delaying a project is rarely the long term solution to an organization that is regularly delivering poor quality products. Inevitably the real fix is earlier on in our project’s lifecycle and may even seem counter intuitive to many people. Too many of us only react when something goes wrong, which is often most visible at the end of a project and too late to fix except by costly delays and product repairs.

See also Lessons Learned From The Failed Oregon Healthcare Website

What are you doing to improve your on time with good quality product delivery performance?