4

We need to create some solution with a new technology, in which no member of my team has any experience.

The higher management demends the tentative dates of the working solution.

After a week of investigation, my team still can't give even a rough estimation of time. We made the list of possible problems, but all of them demands their own investigation. Furthermore, according my experience, I am sure, that we have only half of the future problems (in a best case) in this list. During implementation we will meet a lot of issues, that we can't predict today because of our current poor knowledge of the used technology.

Of course, I understand that the final date like “when it's done” is unacceptable for the higher management.

So, how should we estimate such non-estimability projects?

I understand that this question sounds a little bit stupid, but I'm sure, that all of us have this kind of problem (especially in the Software Development area).

Maybe we should:

  • Try to guess the time (make a guesstimation) and multiply it by two (just in case). Than pray that we can finish in this period.

  • Ask for more time for the investigation. But, of course, the higher management will not like this. And the whole time of the investigation will be unknown also.

  • Don't take this project at all, defer because we do not have enough knowledge in the demanded technology (not the best choice for image of our department).

  • Other variants?

  • Who is making you use this new technology? Do you not have the option of using a technology your team is familiar with? – Ashok Ramachandran Oct 5 '15 at 1:24
1

So it sounds like you are not having an issue with HOW to estimate this but that you have little confidence in the result of the estimate. In fact, since you do not have reliable and valid inputs into the estimating process, it is very unlikely you will have reliable and valid outputs from the estimating process.

I would suggest that arriving at a credible estimate is not possible so trying is futile and a waste of resources.

Since you have a ton of uncertainty in your estimate, and therefore the planning values you choose to publish and work towards, you need to escalate this high degree of uncertainty as part of your risk process. You need to report this high degree of risk at each and every opportunity you have to your leadership and not care how they feel about it. Your job is not to make the feel happy but to report as truthfully, accurately, and transparently as possible.

So go through the motions--break the work down as far as possible, use your SMEs/workers to guesstimate their best-, worst-, and most likely case, choose your most pessimistic planning values within the estimate that you can get away with--and then report as loudly as you can that the business has significant degree of risk, in both directions, and that you will track progress as you move a long and will report variances against your planning values on a set, strict basis. Recommend additional values for contingency, both money and time, in the event your planning values prove too optimistic.

Management will not like this, but here again it's not your job to make them happy. If they choose to abandon this work because of the uncertainty, that is likely a great business decision. If they choose to continue, then they will be prepared.

1

I agree with David...Also, In such cases, we give likely estimates BUT we REQUEST for the OPTION of revisiting estimates after the design&Proof Of Concept Phase. At that time, we are in a better position to provide the correct estimates.

0

What happens if your estimate is wrong? It probability would be some combination of inconvenient and embarrassing. I think you know that the first option, just to guess, is pretty irresponsible.

Ask for more time for the investigation. But, of course, the higher management will not like this. And the whole time of the investigation will be unknown also. - This is the most correct of your suggestions. You can even limit the investigation time into a timebox and then, after gaining some insight hopefully, reassess.

However, it may be better to look into why your project defines estimates. Are the requirements poorly defined? Is it of unclear scope? Is it just too big?

I suspect it may be the latter, because overdoing upfront planning is a pretty common problem in software. Is there some other smaller deliverable which you can estimate? As you’re finding, looking into the future is hard and unreliable, perhaps the customer feels the same. Probably everyone would be happier if you planned and delivered in a more iterative and flexible manner.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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