The Date Question

A common question heard in companies that produce software, either for in-house use or for sale, is “When will this software be done?” I’ve observed this question being asked when it was not yet decided what the software was to include, nor who was to build it. It’s clear that we have little on which to base an estimate, given this state of affairs. Nevertheless, in many organizations, people will start to anticipate what it will include and who will be available to build it in order to give an answer to this question.

Not everyone is so compliant, though. Some people will say that not only can you not estimate the construction with so little information, but you don’t need to estimate it. They’ll say it’s enough if you can build it in little increments of functionality, and stop when it does enough. I’ll grant them that this is a fine strategy for building software, but It doesn’t give an answer the question.

Should you give an answer to the question? Often people worry that their estimate will be treated as a commitment, and they’ll be found at fault if the date is not met. Too often this is the case. In such an environment, refusing to give an estimate will likely not enhance your reputation, either.

Assuming that the question is actually asking for an estimate, telling the questioner that they don’t need an answer seems a bit presumptuous and disrespectful. Who are we to decide that their question is of no value? It seems to have value to them. Maybe it would be better for us to learn why it has value to them.

With two options, we find ourselves between a rock and a hard place. We either make a lot of assumptions and do a lot of work for a date that may have little value, or we take an opposing stance to the expressed needs of the questioner. But what really are those needs?

If I’m feeling comfortably safe, I might answer the the Date Question with “42.”

“42? What kind of date is that? What do you mean?”

“What do you mean by ‘when will the software be done?’ What will you do with the answer?”

When we ask the Date Question, “When will this software be done?,” we have more in mind than a simple date. Perhaps we thought it should be done by now, and we’re expressing our impatience. Perhaps we’re getting ready to start, and we want to put time pressure on the development team so they’ll work as fast as they can. Neither of these thoughts have much to do with an estimate, though the request may be formatted as if it were asking for one.

We might, however, be trying to make a decision. Perhaps we want to know if we’ll have a viable product by the Christmas season, or in time for an industry conference. Do we have time to undertake this project? Or perhaps we want a rough idea of how much the project will cost, multiplying the duration by the cost of the development team. If we compare this cost with the expected value of the developed software, is the project worth the investment? Maybe we need to produce packaging, or training courses, in parallel. When will these things will be needed? There are many perfectly valid reasons for estimating the end date of the project.

Post to Twitter Post to Plurk Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to MySpace Post to Ping.fm Post to Reddit Post to StumbleUpon

Comments (11) to “The Date Question”

  1. I appreciate your being respectful of people that have a legitimate need for a credible guess at when a product will be ready. I don’t understand the context of those who assert that the question is too stupid to warrant an answer and suspect that they would be offended if told that by an mechanic whom they asked, “When will my car be ready?”

  2. If someone asks the question, there is only one answer: that you provide incremental delivery – and actually do that thing. Every successful project I’ve seen has delivered on smaller components of function and expanded it with successful implementations. A development project is one of discovery – for users, for developers and for managers: nobody is exempt from discovering truths about their “systems” that they didn’t know about (including developers).

  3. Nice article, get gets me to thinking there could be a sharing of information before the date question was asked – so why doesn’t this sharing of mental models happen? In my experience it is the arrogance of management that diminishes the sharing of these important reasons for the WHY behind the date question. By arrogance I mean the attitude that management asks for information, but don’t share info, they are not to be questioned.

    Does the reason we are asking for a date change the date? No, so why does that info needed to be shared?

    I don’t defend this mind set, just sharing a perspective.

    So how would we influence management to share?

  4. David, you’re assuming it’s management asking internal staff. That’s only one of many possible situations.

    Anyway, it’s a good point, and one that I will eventually discuss. This post is a part of a larger work-in-progress.

  5. Payson,

    Your mechanic example is fantastic. Why would we flip out? Because we would have no confidence that the mechanic was a professional.

    I am to the point that software development professionals who find it impossible to remotely estimate things tend to be amateurs at best.

    I am not advocating that everything be estimated. I am not stating that professionals have some uncanny ability to nail precisely how long things take. Just that an immediate “estimating is impossible” response is a sure sign to find someone else to do the work.

  6. I feel that the following statement is the most important:
    “Assuming that the question is actually asking for an estimate, telling the questioner that they don’t need an answer seems a bit presumptuous and disrespectful. Who are we to decide that their question is of no value? It seems to have value to them. Maybe it would be better for us to learn why it has value to them.”

    Unfortunately sometimes people would not be able to explain this either because they do not want to discuss this or because they do not know themself.

    And your main challenge is to figure it out yourself without their explicit explanations. :(

  7. Well said, George. To the list of things that may need to be happening in parallel, we can add marketing campaigns, sales and support training, and of course the development of interdependent functionality in other elements of a large program. Where we are trying to support our clients and employers in a change of process and culture, “can’t be done” is a weak response. As Stephen Covey said, seek first to understand.

  8. As professionals, we need to be able to answer these questions, and these relate to the function/date/cost triangle. We need to understand the stakeholders’ requirements in each area to provide a sensible answer (but I already assumed that we’d know those constraints by the time the project starts).

    It also depends on external factors. In the mobile industry, the software is critically targeted towards the release date because so many other stakeholders have an interest in your answer, and the date could well be a given – in which case, functionality will be sacrificed. In fact, what is compromised is testing, and that impacts reliability over the long term – your product is flawed even though it is delivered on time and maybe within cost.

  9. What’s the date isn’t the question I’m usually asked, we have set install dates. “What will I get” on that date is the one I’m asked more often. Any advice?

  10. Rich, it’s a similar situation. There is still a decision behind the question. What is that decision? Is it a go/no-go for the project? Is it what features to advertise?

  11. Rich,

    You have to commit some time. In fact, the whole project is one of commitment and depends on all sorts of factors outside of your control. Now, you could mention all of those factors (machine time, support, etc) but all you can do on day one is to give a broad and necessarily vague description of the project aims. The real clue to deliverables lies in the subsequent discussion where what’s important to the customs is revealed. But by now you have a spec and some sort of commitment (don’t you?) so that you can tailor the user’s requirements to the resources available.

    The IT industry is fifty years old. We’ve learned lessons in how to do this stuff. If your mentors can’t give you guidelines in how to respond to such questions, you’re working in the wrong place. Computing is hard. After fifty years I still can’t give a precise estimate because of the external factors (and budget limitations) because life’s like that. After fifty years I can only give hugely inflated estimates if they want certainty, and then surprise them (or not) at the end of the project.

    I will say I have rarely given inflated estimates except once: The customer received excellent service – but didn’t appreciate it, and we lost the follow-on.

Post a Comment
*Required
*Required (Never published)