KC Lemson

By KC Lemson [MS]

Blogs

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

  • Comments 5
  • Likes
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
  • Or maybe i'm not the only one who's risking money on it ? :)

  • 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".

  • Please. You can tell me. I won't tell anyone

  • OK you're all a bunch of wise guys! :-)

  • 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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment