10

Assuming that your team does a great job building its estimates and using a probabilistic approach versus a deterministic approach, and finds that the scope of work will take between 12 to 18 months to complete with their most likely estimate around 14 months, is it better to target closer to the 18 months to build in some degree of assurance of meeting it or would it be better to target closer to 14 or even 13 months...and why? What are the pros and cons to either the seller or buyer?

This is not one of those questions that has a ready answer and probably violates the rules, but I think it is an interesting and relevant topic to PM worth some debate and argument, so I'm asking it anyways. :)

Addendum: Notwithstanding an initial risk evaluation, is there value in "forcing" a more optimistic target than what one might find comfortable? Can this be a productive and healthy challenge for the team? Can this be an effective way to control Parkinson's Law and Student Syndrome?

Improve this question
2
  • David, are there management reserves built into the estimate? Have you worked with this team before to deliver this type of project?
    – Mark Phillips
    Commented May 20, 2012 at 19:29
  • Assume no mgmt reserve yet. The second question assume semi new team, ie, some same, some new.
    – David Espina
    Commented May 21, 2012 at 10:32

4 Answers 4

Reset to default
4

I would use the 14 month Most Likely estimate, for a few reasons.

Anything less puts undue (and unnecessary) pressure on the team. The team gave you the estimates and showed what was 'most likely. Asking for more is essentially saying "we appreciate your input and thoughts, but do it faster".

Shrinking the schedule to the Optimistic is ignoring any risks. The Optimistic estimates are "perfect world', and we rarely (never) see that.

Conversely, using the Pessimistic is saying the opposite - that ALL of the risks identified will happen. This isn't realistic, And is also de-motivating. It tells your team that while you appreciate their estimates, you have no real confidence in their abilities to come through as promised. You're expecting the project to go south.

So in this instance, I would use the Most Likely, and inform the Owner of the possibility of the Pessimistic, but that your risk management will counter for that.

Improve this answer
2
  • Trevor, would you move up or down based on your initial risk evaluation?
    – David Espina
    Commented May 19, 2012 at 10:42
  • David, it would depend on the results of the risk evaluation and the likelihood of the risks. Most likely it would extend it, as risks rarely shorten duration, and since we're already starting from Most Likely, I would target either that, or that with some contingency for +50% risks.
    – Trevor K. Nelson
    Commented May 19, 2012 at 15:31
2

I would probably use either the most likely estimate (14 months) or a weighted average (e.g. PERT = 14.33) as the target with the difference between that and the worst case as project buffer (if in a critical chain environment) or split among tasks as contingency reserves (if in a critical path environment). My logic is that:

  • People have the best of intentions and are usually optimistic in their estimates. Unless you have a lot of supporting data the 14 months is probably a low-ball of the most likely case.
  • Using less than the most likely estimate as a target could demotivate the team ("we told them what we could do but they aren't listening...") unless they buy into the critical chain environment where target delivery dates assume a 50% likelihood of being met.
  • Fate has evil intentions that conspire against the project so it is better to make everyone aware of the worst case early so that managing expectations later is easier. Inclusion of buffers/reserves gives you date ranges for completion to help with this.
  • Inclusion of buffers/reserves to get date ranges also fits in better with your assumed probabilistic estimation.
Improve this answer
5
  • Doesn't the inclusion of the 12 month estimate seem to indicate that this is the Optimistic, and the 14 month represents the Optimistic plus buffers? So using the 18 month, you're adding buffer to buffer. Critical Chain assumes estimates are done deterministic (w/buffers included), not probabilistic.
    – Trevor K. Nelson
    Commented May 18, 2012 at 21:42
  • Same question as to Trevor, would you move up or down from the formula result based on your initial risk evaluation?
    – David Espina
    Commented May 19, 2012 at 10:44
  • @Trevor K. Nelson, my understanding of critical chain is that you set target dates that are 50% likely to be met. Depending on the probabilistic model used in the scenario the 12 months may or may not represent that (e.g. risk averse organization gives 12 months = optimistic target = 67% likely to be met, 14 months = 90% likely to be met, 18 months = 99% likely to be met).
    – Doug B
    Commented May 22, 2012 at 20:47
  • @David Espina, absolutely I would evaluate based on the risk evaluation - with input from the team(s) doing the work and dealing with the risks - and assign any added time to a risk budget in the same way that you would allocate $$ to deal with risk.
    – Doug B
    Commented May 22, 2012 at 20:50
  • @Doug B - CCPM works on the theory that estimates provided will already have an 'inherent buffer' already built in (to 90% conf.) Tasks are then cut to 50% w/the remainder set as buffer at the end of the project. In this way, even the ML should have a 90% confidence level, with significant buffer built in. That's why, when using a CCPM approach, adding the addt'l 4 mos. would be adding buffer to buffer.
    – Trevor K. Nelson
    Commented May 22, 2012 at 21:40
2

Interesting question...

It seems to me that this can best be answered if you know your customer well, and have a clear understanding of the customer's expectations.

If the customer expects you to meet your deadlines and will not accept any deviation, then go for the long end of the range... maybe not the full 18 months (as this does assume that all risks will arise), but perhaps somewhere between 14 and 18 months.

If, on the other hand, your customer understands that the estimate is just that, and is prepared to accept time and cost variations if risks come to fruition, then go with the shorter end of the spectrum.

Whichever way you decide, make sure that the team understands the basis of the figures provided to your customer, and don't allow motivation to slip because either "We have plenty time" or "It doesn't matter if we slip - the customer expects that".

Improve this answer
1
  • +1 for knowing the customer. There are unsophisticated ones out there. If you target 13 and come in at 14, they're mad. If you target 17 and come in at 16, they're happy...despite they paid for two extra months of labor.
    – David Espina
    Commented May 19, 2012 at 10:42
0

I would use the lead time distribution approach from Kanban and see how the team's estimate correlates with the actual data. We have something similar here: https://pm.stackexchange.com/a/5245/468.

Therefore, I would go with the 18 months, because this is a better estimate than the 14 months according to that answer. The 4 month difference is not a buffer here. I see it as a guarantee of delivery on time.

Additionally, I did an experiment a while back. We had an estimation like this 14 months and we stated that we can do better so we committed to 13 months and used a -1 approach on each requirement we had to deliver. Unfortunately, this kind of "improvement" had no effect on our way of working at all and made it even worse. It turned out that the original number - the 14 months - was the best we could do.

Improve this answer
5
  • Zsolt - curious about the thinking behind adding 4 mos. and calling it a 'guarantee'or 'better estimate'. Why not say 18 mos., but 'guarantee' it in 24? Not trying to offend, but it seems like you're willing to drag it out (on the client's money). What am I missing?
    – Trevor K. Nelson
    Commented May 21, 2012 at 15:09
  • Trevor, so far, when I went with an optimistic estimation the project failed, because the developers wanted to prove that they can do it and no matter what we did or improved, we never managed to deliver on time. After introducing the lead time distribution based estimation, we managed to deliver on time, because our numbers were based on actual data and not on wishful thinking. So if there isn't any data which supports the 14 months, I'll go with the 18 months.
    – Zsolt
    Commented May 21, 2012 at 15:50
  • The idea behind this scenario is that there is data behind the 14 months. Most likely would mean there would be reasonableness, either because of history or whatever, that 14 months is not wishful thinking and that projects of similar nature will finish in that time.
    – David Espina
    Commented May 21, 2012 at 18:07
  • Zsolt - thanks, that's what I was missing. Coming from a const. background, we're always working from actual data, so our Most Likely is grounded in achievable estimates. It sounds then like, where we're working from ML towards O, you would be working from P towards ML?
    – Trevor K. Nelson
    Commented May 21, 2012 at 20:16
  • David, thanks for the clarification. Knowing this detail, I'm good with the 14 months. Trevor, yes that's my current approach. If the ML won't change after several projects I would stop for a moment and check why, because the team is supposed to speed up, but still operates on an old speed. Hopefully, it is not because of the Parkinson's Law: "The amount of time which one has to perform a task is the amount of time it will take to complete the task."
    – Zsolt
    Commented May 21, 2012 at 20:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.