Thinking, Doing and Redoing

I've been working on software development projects and standards projects for decades.  One of the things I've learned as a developer about these projects is that you aren't done until you've shipped.

For software; code complete isn't shipped, sent to QA isn't shipped, and finishing Beta isn't shipped.  Shipped means that the CD is in the customer's hands.

For standards, sent out for ballot isn't shipped, passing ballot isn't shipped, and negatives reconciled isn't shipped.  It's only when the final text is in the customer's hands that you've hit shipped.

A typical project (regardless of domain) spends its time something like this:

⅓ Thinking
⅓ Doing
⅓ Redoing

It's the redoing part that's really hard.  That's where the feedback that you get from QA or from customers, or from a ballot has to go back into the product.

There's very little you can do to make redoing take less time as an overall fraction of your project time.  You can move feedback earlier into the project (as iterative approaches do), but what that winds up reducing not just "redoing", but also "doing" and even "thinking".

So, if you are in the middle of a ballot process, try not to think of yourself as being nearly done.  You are just at the halfway point.  When the ballot is over, and you start implementing the feedback, you'll be about ⅔ done.  When you've made all the changes from ballot feedback, then you are "nearly done", but remember, it isn't until the specification is in customer's hands that you've reached complete.

One other thing:  A standard isn't really done until its been implemented, and is in your customer's customer's hands.  That's a whole 'nother project (or a bunch of separate projects running in parallel), so when you've put it into your customer's hands without a pilot, you're only about halfway done.

-- Keith