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 : Development Management, Management, Product Management, Program Management, Software Development Lifecycle, Software Management