Delivering Perfection

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:

  1. The product is only as good as the plan for the product.
  2. The best teamwork is a healthy rivalry.
  3. The database is the software base.
  4. 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.

Advertisements

3 thoughts on “Delivering Perfection

  1. Dawn

    Nice article. I’m working on a specs document right now that is only for an implementation of an existing software package. When I’m done, I’ll bet it will be more than 50 pages. I never liked the timeframe I had as an analyst for writing specs. It was never enough time up front!

    Reply
  2. Martin

    At USD 1200 / LoC the Space Shuttle Software is also pretty pricey. Perfection isn’t too interesting in many contexts – a good price/performance ratio is.

    Reply
    1. Jeff

      According to W3, there were 72,358,646 unique visits to all tracked websites in June 2009. Of that, 85.12% were from a Windows Operating System. That means that there were roughly 61,591,679.50 global Windows users surfing the web in June.

      The Windows OS, while bundled with a PC’s purchase, actually does have a cost. Retail today of the Windows XP Home Edition (the cheapest of all versions available) is $187.99 and an upgrade is $77.99.

      So giving Microsoft the benefit of the doubt that they only charge each of the OEM’s $50 for their full version of Windows installed on a new PC, that nets Microsoft approximately: $3,079,583,975. (Compared with NASA’s $35M annual budget, this ONE TIME income for XP – since we’re not counting cumulative revenues from all versions of Windows – FAR exceeds the amount NASA spends for software that’s only been officially used 127 times.

      Overall, I think Microsoft could make software way less buggy for the amount of money they’re making on it. (Oh, I also didn’t count the cost of any maintenance dollars “earned”.)

      🙂

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s