In thousands of meetings over the years, I’ve been privvy to a very common conversation. It’s a discussion of deliverables – what is needed, what is wanted, how much money is available to pay for the needs/wants, who can create the best solution, etcetera. Regardless of the actual nature of the deliverable, the basics are always the same: We want what we want, when we want it, at the least total cost. The end result, however, varies widely on a huge number of factors. One of them is the quality of the “spec” – the document describing what’s being created; and another is the quality of the group performing the work.
The deliverable is never perfect. At some point in the process, either the vendor makes errors or the buyer doesn’t adequately describe what they want (or consider all of the various contingencies). The net result is payment for something that doesn’t do what you hoped it would do – or going over budget for the fix. So how do you deliver perfection?
Well, the folks who write the software that runs NASA’s Space Shuttle have it about right. It’s a four-part process that keeps their code running virtually bug free for the last 20 years, and like the Five Fundamental Skills for Effective Negotiation, it’s not (pardon the pun) rocket science:
- The product is only as good as the plan for the product.
- The best teamwork is a healthy rivalry.
- The database is the software base.
- Don’t just fix mistakes – fix whatever permitted the mistake in the first place.
This is a fascinating story about a group of 260 people working normal hours and achieving extraordinary results (the last 11 versions of the software have only had a total of 17 errors). Equaly important from a stats perspective are the specs. For the current application (420,000 lines of code – for comparison’s sake: WindowsXP has 40,000,000 and MacOSX has 86,000,000), the current spec is 40,000 pages long.
Now, granted, many of the projects your teams are working on aren’t operating systems. But how many of you have seen a spec document that’s even more than 100 pages? How about 50? Very few. In fact, I am used to seeing spec documents of less than 5 pages – 10 at most. It’s no wonder that there are errors.
I also don’t believe that many of us will be effective in getting our development teams to change, either. But if they only got a little better, the cost savings would be immense. So share the article with them from a human interest perspective (ie: don’t push an agenda). The worst that happens is you start a dialog.