Share via

What's the real RTM date? C'mon, you can tell me...

  • Article

With Exchange 2003 SP2 around the corner (check out the CTP!),
the emails have started coming: "When will you ship? I mean the real ship date." Release managers get a ton of them, they are often sent
to the internal product's distribution lists, and if you happen to work on a product team and send a mail
to another DL about a completely unrelated topic, if someone looks you
up and realizes where you work and your product is in the spotlight, you might get a direct mail asking you
about it.

They usually are a little more detailed than "When's RTM?". Some variations:

  • "My customer [insert big
    name] has [insert important reason] and thus they really need to know
    the exact ship date of [product]."
  • "I see that the public web site says [date that is probably a little vague, like "Q1"]. What is the specific date?"
  • "I realize that dates may change, but my customer really needs to know the exact date so they can plan for their deployment."

Here's the problem: We learned a long
time ago that when you tell a customer a specific date, and the date
changes, the customer gets upset. Understandably. And it is the nature of the software
development beast that you often don't make the
exact ship date you'd planned on 18, 12 or even 6 months previous. So
we've just stopped publishing those dates.

We always have a target date
ourselves, we need it in order to have something to aim for as well as
to work backwards and figure out the
rest of the schedule ("OK if I need 3 weeks uptime at five nines in
MSIT before we can ship, and
let's say I have to reset it twice, plus I have to pass the uptime
release criteria at our TAP customers, and before that I need X weeks
for coding and Y weeks for fixing bugs with an estimated incoming rate
of Q and fix rate of R except during December when the fixrate will be
0, and Z weeks for performance and scalability testing...").

Schedules are wicked complex things. We get laughed at a lot for not
meeting them, and I don't mean to say that we never deserve the
laughter, but I also want to emphasize how incredibly difficult it is
to create a realistic schedule for a product that a team of dozens,
hundreds or even thousands of people work on and make it actually stick.

And so, we just don't give specific dates if it can be avoided. And in my view, you don't want us
to give specific dates either, because you'd just be mad at us if we
gave a specific date and then changed it later. So we do the best we
can, which is hand out dates that get more and more specific as we get
closer (from "By EOY 2005" to "CY 2005" to "1H CY 2005" to "Q1 CY 2005"
and only turning to "February 2005" maybe a month or two in advance),
and try to be polite when we get request after request asking us for
"the real date".

So please, don't get upset when you ask "I see that the web site says
Q1, but when's the real date?" and you get "Q1" or "When it's ready" in
response. Be thankful that we are going to wait until it's high-quality and ready to ship rather than release it due to external pressures.

Comments

  • Anonymous
    August 26, 2005
    Or maybe i'm not the only one who's risking money on it ? :)
  • Anonymous
    August 26, 2005
    Why not give them a date? If you say, Q1, and they ask for something more specific, tell them "March 31". If you get done before then, you "shipped early".
  • Anonymous
    August 26, 2005
    Please. You can tell me. I won't tell anyone
  • Anonymous
    August 26, 2005
    OK you're all a bunch of wise guys! :-)
  • Anonymous
    August 26, 2005
    Craig: I could turn that around. If I tell you Q1, why not just assume March 31 until you hear otherwise?

    Worst case, if we do have to change the date, going from Q1 to Q2 is a lot better than telling people "march 31st" and then telling them "Actually no - June 30th". The more specific the date is, the more expectations people tie onto the date, regardless of how far in advance it is.