#NoEstimates confusion

So you’re always late. Your friends ask when are you coming, and you always give way too optimistic answer. Or something else happens. In any case —  you’re always late. Simply put, there are two possible ways to handle the issue:

  1. Find a solution: You try to be better in estimating your arrival. You take into consideration that traffic affects your travel time. You remember that putting your clothes on takes longer in winter. You add marginals to your “arrival estimates”. This way you are better estimating your time consumption, and as a consequence, you’re more often on time.
  2. Change the problem: You change the setting so that either you don’t have to give an “arrival estimate” or it doesn’t matter that much if you’re late. For example, instead of meeting outside of restaurant before going in, you agree to meet in a bar nearby. So if you’re late, your friends can just have one more aperitif, no big deal. Maybe your dinner party starts with a flexible cocktail party period instead of punctual time. So we change the problem from “How to be on time?” to “How to change things so that my friends don’t need to rely on estimates so much?”

The way I see it , currently #NoEstimates is about option #2 — changing the business so that you lessen the need to estimate.  If you stay within #1, the solution space, I agree that #NoEstimates makes no sense. If someone asks “how long is it going to take?”, you need to estimate to answer, there is simply no way around it!

The key questions here are “How do I change my way of doing business so that I don’t need to ask ‘how much? when?’ so often, or if I do, it is for shorter period of time? How do I deliver value sooner? How do I validate my concept ASAP?”

One small addition: in real life, #1 and #2 are not mutually exclusive. You can, and should, usually do both.


5 thoughts on “#NoEstimates confusion

  1. Great post. Good insight into the difference between solving the problem and changing the problem (i.e. changing the context).

    But what you say is not entirely true. You write “If someone asks “how long is it going to take?”, you need to estimate to answer, there is simply no way around it!”. This is simply not true.

    In fact, since 2005 I have been answering that questions without estimating. You can find out more about how I did that in my videos on youtube. It is possible, it has been done, and I can explain how.

    This leads me to the second separation of concepts: Prediction of system throughput does *not* require estimation. It requires an understanding of the system you are studying. This is nothing new, of course, Deming has written about it in the 60’s, 70’s, 80’s and 90’s.
    Predicting system throughput is materially different from estimating (different problem to solve, different information used, different models builts, different output), and is – in many cases – much more accurate (as I show in my video).

    I would like to see you write also about this particular aspect 🙂 How to understand a system enough that you can predict its performance without understanding all the details (which is what estimation does: try to understand all the details).

    1. Vasco, I consider forecasting future performance using current performance under the “estimating” umbrella. You don’t need to explain how, I apply same kind of principles as we speak and I’ve watched at least one of your videos.

      1. Considering “understanding system performance” under estimation umbrella is like understanding Physics and trying to predict a football game. Maybe fun, but mostly painful.

        Estimation in project management is materially different from “understanding system performance”. If you consider them the same you are missing the opportunity to find much greater insights into how to improve your work.

        It is your call, of course. And many (unsuccessful) companies in the world have taken the same (mistaken) view of system performance vs analysis of system components.

        “The performance of the whole, cannot be explained by the analysis of the performance of the parts” – Ackoff

        1. Vasco, I’ve come into conclusion that in written text I don’t connect with you very well. This is very frustrating. “Under same umbrella” IS NOT considering as the same.

          I think you’ve misunderstood what I understand and what I don’t understand. But continuing this dialogue, even in longer form, for now, just doesn’t feel worth the effort. At least for now.

  2. In both cases, the dinner starts at the scheduled time, with a buffer in front, but the dinner is still “scheduled?”

    Unless the actual start of the dinner is itself not fixed around some agreed time, the buffer between your arrival and the actual start may not be enough.

    You’ve made this about you, rather than the participants in the dinner. That might be a good metaphor for the #NoEstimates participants. “It’s about me, not the other members of the dinner party.”

    If we’re going to forecast the arrival time of “me” – in this case I’ll use me and “me,” then putting a buffer, a pre-meeting in the bar, or any other “buffer” can protect the other’s from my inability to actually show up on time. This “schedule margin” can be from past performance – aleatory uncertainty. Or probabilistic events – epistemic uncertainty.

    When I travel with one of my colleagues, I always make sure his flight back to his home town is always before mine, so if he’s late leaving the site, checking in the car, or whatever, I have margin. He’s “always late.”

    Building those schedule margins into the schedule is mandated in our domain. We use Monte Carlo Simulation to determine how much schedule and where to place it. Same for cost and technical performance.

Leave a Reply to Vasco Duarte Cancel reply

Your email address will not be published. Required fields are marked *