Quality and Innovation

On Friday, November 14th, John Markoff published a story in the New York Times announcing the new Google Voice Search technology for the iPhone. Here’s how he set expectations about the features and release date for this admittedly exciting new tool:

Users of the free application, which Apple is expected to make available as soon as Friday through its iTunes store, can place the phone to their ear and ask virtually any question, like “Where’s the nearest Starbucks?” or “How tall is Mount Everest?” The sound is converted to a digital file and sent to Google’s servers, which try to determine the words spoken and pass them along to the Google search engine.

The search results, which may be displayed in just seconds on a fast wireless network, will at times include local information, taking advantage of iPhone features that let it determine its location.

This provides an excellent example of three points: 1) how NOT to set expectations with your user community, 2) being sensitive to REAL and UNREAL deadlines, and 3) recognizing that sometimes other people (e.g. the media) help set customer expectations for you – especially when your product or technology is popular.

#1: Ever seen that Far Side comic called “What Dogs Hear”? That’s the one where the man is talking to his dog, but all the dog hears is “blah blah blah GINGER blah blah.” When Markoff notes that Google Voice Search would be available “as soon as Friday”, what customers hear is “blah blah blah GOOGLE VOICE SEARCH blah blah blah WILL BE AVAILABLE FRIDAY blah blah”. It doesn’t surprise me that complaints are flying, now that it’s Saturday:

Well, it’s Saturday morning, and as of this writing, the update is nowhere to be found. The bloggers are starting to go meta, writing stories like Harry McCracken’s “How Long Does Google Baby the iPhone?“

#2 Regardless of when Google’s official release date for Google Voice Search is/was, once it was published in the New York Times, the release date was officially Friday, November 14th. And that’s when the REAL deadline was established, because the customer expectations were (purposefully or inadvertently) set!

#3 Google might say “hey, we didn’t actually give the New York Times a release date, they just asked us when the soonest might be that we’d release the product, and we told them what we thought was our best answer.” Lesson: if anyone asks you when’s the soonest your product will be available, they are basically drooling over the new gadgets or functionality you’re getting ready to provide. Think about how many days or weeks you expect the product will still be in development, and then multiply it by three. Or ten. I admire Google, which is why I’m content to use them as an example here – they have a ton of equity with their user base, but their release dates will still be under the microscope and so managing expectations (especially through the media) is even more critical.

(Image Credit: Doug Buckley of http://hyperactive.to)

Your team is busily working to meet a deadline for an upcoming project, and you’re wondering whether you’re going to be able to pull it together. Everyone is getting nervous, drinking a lot of coffee and Mountain Dew, and staying at the office until the wee hours of the morning. But have you or your project manager stopped to think about whether you are working towards a “real” deadline, or spinning your wheels to meet one that is “not real”?

When real deadlines are not met, there will be negative consequences (e.g. product failures, loss of revenue, loss of goodwill, loss of credibility). Deadlines that are “not real” may have consequences internal to your organization (e.g. loss of goodwill with your boss, delay in providing materials to other employees in your company) but typically can be shifted with less impact.

So why do project managers even set deadlines that are “not real”? Sometimes, internally-focused milestones are required to keep a team aligned, and to provide feedback to assess how well the team is progressing towards externally-focused deadlines. More often, the reasons for originally setting a real deadline have shifted, and the original scenario no longer applies – but no one has stopped to reflect on the fact that the previously set deadline has shifted from being a real one, to one that is not real.

Here are some examples of cases where the deadlines are “real”:

• “Life or Death”/”Health or Wellness” situation. If you or someone else will die, or otherwise experience a degradation in their health or sanity or well-being as the result of your actions or inactions, then your deadline is real.
• Time-sensitive systems. This is a special case of the “life or death” situation. If your products or processes will stop working unless you deliver a fix by a certain time, then the deadline is real. Y2K was an example of this kind of deadline (regardless of whether the potential impacts were enough to incapacitate software).
• Cash flow requirements. If you or your company will run out of money unless you meet your deadline, then you are facing a very real deadline.
• Previously set external expectations. If you promised a customer that you would deliver their final project on December 5th, the deadline is real. Not meeting the deadline will result in a loss of revenue, credibility, goodwill, and potentially future business as well. Aggressively setting expectations and striving for transparency are two tactics that can help make “real” deadlines like this a little more malleable.
• Inflexible resource allocations. If you only have access to a team member for a limited time before their visa expires, or if you only have enough money to employ contractors for three months, then getting done what you need to get done in a limited time forms a real deadline.
• Biological constraints. Oftentimes a woman’s “biological clock” must be considered for deadlines that involve producing new children, but there are other biological constraints that may impact deadlines as well. For example, if today is Saturday and you have a major deliverable due on Wednesday, you could choose to stay awake 24/7 to get it done but you would probably not be successful. Your biological need for sleep (and possibly food as well) would thwart your project plans.
• Inflexible policy. If your company has a policy that you are required to follow, and it impacts your projects or milestones, it is very likely that you are facing a real deadline (but you might want to ask the “owner” of the policy you are being impacted by, to confirm). As a more extreme example, if a curfew has been imposed in your area, you will need to finish what you’re doing before a certain time of night.
• Meeting laws and regulations. On April 25, 2002, the Sarbanes-Oxley bill was passed, increasing the stringency of requirements for financial reporting. Companies were required to take steps to comply immediately, and had a limited amount of time to prove their compliance (or else there would be financial and legal consequences). When deadlines are externally imposed, and not meeting them can cause lawsuits and fines, they are real.
• Shifting sentiment/public opinion/seasonality. If you need to deliver a product that’s meant for use in the summer, and the ice has started to melt and people are headed to the beach, then your deadline is probably very real. If you need to capture “buzz” or other trends in popular culture, and you risk selling less product or increasing your market reach if you don’t finish your work on time, you are facing a real deadline.

How can you tell if a deadline is real? Look for the root cause of the deadline, for example, by asking “5 Whys”. One you know why a milestone or a deadline has been established, you will be better able to find ways to iron out issues that arise when your work is delayed. Furthermore, you will more easily recognize where to focus your team’s effort to prevent negative consequences.

[Note: Some people prefer to call these “hard” and “soft” or “firm” and “not firm” deadlines, but I like the angst that comes along with calling them “real” and “unreal” even though it requires a little bit of hyperbole. Note 2: These elements were brainstormed with Ron DuPlain.]