Monday, June 12, 2006

What is More Important? Time or Quality?

I came across a post that raised a few very good questions about the software business, so I thought I would respond.

  • How partial can the initial result be and still matter?
  • Partial in features or partial in quality?
  • Is a later corrective delivery a separate, on-time delivery, or a completion of the initial delivery, thereby making it late?

The underlying question here is how do you make the decision when you can't deliver on scope, quality, and timeline, how do you choose what to sacrifice? The original author makes a good analogy:

If you're running for a plane and lose a shoe. Better to make the plane and buy new shoes at the other end, right?

And of course, the counter point:

What happens when the client you were going to visit by plane is on the plane, sitting next to you?

To be consistent with the focus of this blog, I think there are a few rules that apply here to software development teams:

  1. Know your users. What will your users accept? If this is a critical, life or death piece of software, quality probably can't suffer but timelines are allowed to move. If it is an business process automation application, then maybe quality can slip since the ship date is critical.
  2. Use your Product Manager. I made a previous post about the value of product management (link), and this is another benefit. Usually, product management owns the customer base and profit / loss accountability. (In your organization, this could be sales, marketing, or a business unit GM. In those cases, target them with this advice). At the end of the day, your team is not held accountable for P & L. Your team is responsible for fulfilling requirements provided by product management. You are not directly tied to the customer or the sales cycle (yes, I know this is slightly different in small companies, but realize that the roles are there, you are just wearing different hats). Let the product manager determine which aspect of the project to sacrifice.
  3. Use your best judgment. In the event that you are left to make the decision, go with your experience. If you were the user, what would you prefer? Could you postpone a feature? Could you delay part of the product? Someone has to make a choice, you just need to accept that no choice is going to be popular. Everyone will want all features with all quality on time. Your job is to get past the emotion, and recognize that it just isn't going to happen this time, so it's time to make a mature, rational decision about how to proceed. The inevitable "how did we get here" question will certainly come up, so you need to be prepared for it. Remember, history is a great instructor for the future, but it can't be changed regardless of how much you talk about it.

These are decisions that come across my desk all the time. As a general rule, I try to stick to rules #1 and 2, but in the event I need to decide, I do so. Trust me on this one, indecision is far more costly than the wrong decision. I've made a bunch of decisions about projects and scope. Some were right, some were wrong, and some were very, very wrong. Bad decisions happen, the trick is to manage past them, not to let them define you.

The full post can be found here: Link.

Technorati : , , , , ,

1 comment:

Tom Harris said...

(Running 2 identical blogs? I got a trackback from here too so posting response here too. Let us know which blog you're continuing with ...)

Well I’m glad and humbled to find a real program manager reading my talk about quality. As the writer of the On Time Delivery post, though, I’d like to stress a different aspect than the one you addressed.

You suggested that “The underlying question here is how do you make the decision when you can’t deliver on scope, quality, and timeline, how do you choose what to sacrifice?”

I read some of your journal entry and saw the part about the “bug bash”. While 500-item bug lists are not uncommon, I wonder, in those situations, whether perhaps quality has already been sacrificed.

I believe that when you look from the developers’ side of things (those people who work for you), you can find that you don’t have to sacrifice quality in order to maintain scope and timeline. Rather, that better quality from the beginning will result in more features delivered on time.

It’s also more enjoyable for them than “eat[ing] meals in the office”. And probably more fun for you than “red-eye” on Thursday morning.

I feel you also left a number of questions unanswered. Some from my original posting (you quoted them; I’d be interested in your response). Others raised by what you wrote.

For example, why can quality “slip” in a business process automation application? Will SOX, for example, allow such a “slip”?

Or why would you “Let the product manager determine which aspect of the project to sacrifice,” especially if one of the options you’ve opened for him or her is to sacrifice the quality that’s got your name on it?