On Goals

Summary: Schedules are vitally important. But they are not always the most important thing.

I was seriously pissed off.

The project was late. Very late. Engineering is an overhead expense, and the late project meant we were burning through cash when we should have been selling the product and generating revenue.

There were good reasons for the schedule slippages. Some of the parts were quite new and had bugs. A new toolchain for the FPGAs crashed frequently and sometimes miscompiled. The firmware was big and complex. The engineers were working very hard. But promises they made went unfulfilled, and my promises to customers were becoming more aspirational than accurate.

We needed to get the product to market. Ship it. Ship it. That's all I could think about. But there was nothing to ship.

What could be more important than shipping?

This was to be the flagship product to keep the company going for at least the following five years. But we had to get it out the door for it to be of any value for us.

What could be more important than shipping?

#1 - High quality. But what does that really mean? If you can't measure it the phrase "high quality" means nothing. Saying "no bugs" is meaningless, as the old saw is true: you can prove the presence of bugs, but not their absence. So the metric became "passes all tests in our test systems."

#2 - The system met certain technical specs required by the market.

#3 - There would be at least 50% spare room in the FPGAs and flash memory. Being a new generation of product, we knew that more features would be added over time. If the initial release left little room for change the product would eventually need an expensive redesign.

#4 - Meeting a certain ship date.

#5 - Keep the cost of goods to under a particular number.

So here's the odd part: the schedule was, in the grand scheme of things, much less important to the success of the product than three out of five other parameters. Getting it out on time but missing those other three items meant we failed.

I printed out this list and posted it over the lead engineer's desk, so she knew what was really important to the company.

In the end we did miss the deadline, but the product worked well and was a market success. It made us a lot of money.

Every project has a different set of priorities. Miss a Mars launch window by a day and you have to wait 20 months for the next window. But management often, and sometimes for good reasons, sees only the schedule as the vital factor. Mick Jagger had it right when he sang "you can't always get what you want." Tradeoffs have to be made. Is shipping on-time really the most important thing? If it is, something else has to give; perhaps the feature set will have to be reduced.

It's easier for smaller businesses to do this sort of soul-searching than a big company where decisions are made far removed from the engineering team and often from the customers. At the executive level managers are thinking about the expensive ad campaign that is waiting for the product to be finished, the minute-to-minute stock price and other factors that are indeed important.

And schedules are important. One problem I have with some in the agile community is a "it'll be done when it's done" attitude. While that reflects a truth about engineering, it neglects business realities.

But there are tradeoffs, and you can't always get what you want.

Published October 12, 2015