1

currently we have a client that have a series of requirements (very broad and general) for an app. I as the PM was asked by my boss to estimate how much hours of work were required to make that app. Now, given the requirements I can see this taking between two and two and a half months, but since this estimated hours are going to be use to charge the client I need to go into details to give a proper estimation.

The problem is that my boss want this ASAP, 1-2 two days (big surprise), but of course I'll need to review this carefully with my team in order to give a proper estimate, and there is always the posibility that the client don't like the proposal and declines the offer, therefore we will lose a lot of time. My question is how should I balance the time invested to make an estimation? How much minimun time should I invest? Should I talk to my boss and explained to him why I need more time? Or should I give my glanced estimations of two and a half months?

I write down the requirements and transform them into user stories, etc, but since we need to work with a third party we do not know for sure how their system (ERP) works, that is the reason why I believe that a lot of unforeseen problems my arise.

4

Hard question; I'm skeptical that there is a truly good answer to the question. There are some approaches/opportunities

  • Build in the confidence interval. "If I understand your requirements correctly, I'd estimate that it is 80% likely we'd be done in 4-10 weeks, with the most likely value being 9 weeks."

  • Build in the rolling plan, "Based on what you've shared, I estimate we'll finish the job in 9 weeks. First week is a deep dive into the requirements to make sure that we have the same assumptions - after that I'll update the estimate and share the revised suspense with you."

  • Build in the risk, "This is a rough order of magnitude estimate based on 1 day of reviewing the high level requirements; similar project have been completed in 3-12 weeks, we'll be able to improve the fidelity of that estimate once my technical team and your test team have validated the requirements.

  • Build in the opportunity, "Based on reviewing the requirements for 1 day, I'd offer a rough order estimate of 4-12 weeks, which is the same estimate that any honest vendor is going to offer you at this point. Our bid is based on the assumption that the estimate will be revised after each of the milestones in this chart. This chart shows how the schedule risk will decline after each milestone. I'll make sure to update you at least weekly so that you'll always know the estimated completion date.

Of course, you can combine any/all of the above.

I want to try to reinforce something that @DavidEspina said in comments; not sure I can say it any more clearly than he did

Because of the uncertainty and time to figure it out, add the fat and at the risk of losing the contract. @DavidEspina

There are different strategies to try to win the contract. Anyone can try for low bid, but it is risky in both the short and long term. All of the above are based on the strategy of being the best candidate - the safest candidate. Escalating risk and presenting it to the customer ought to convince them that you are actively managing the project, and are more likely to turn in a project of acceptable quality on an expected schedule and an expected cost.

| improve this answer | |
  • +1 for great answer. Strong emphasis on the risk bullet. Because of the uncertainty and time to figure it out, add the fat and at the risk of losing the contract. – David Espina Feb 3 at 19:09
3

This is a tough question, and I've been in your position.

Every single time, I was wrong in my estimation.

There was some gotcha, or something I didn't know, or some event that caused us to be wrong -- terribly wrong in our estimation.

It's not difficult to estimate small things; but it's impossible to estimate accurately even medium sized things; and the problem with estimates is that they aren't cumulative: You can't just add estimates of tasks together to get an end result, there's some fuzziness on each end that causes that to fail every time.

(Thinking about it, it makes sense, even in your personal projects or chores at home do you finish the dishes and immediately are able to start making dinner without resetting and mentally preparing for that task?)

If I could do it again, I'd likely sit down with my manager and be pretty upfront that we're going to be way wrong on delivering an accurate estimate for an entire project; but if we can narrow it down to the most important part the customer wants first; we can estimate towards that, and work out with the customer that we don't know how long the whole thing will take; but we have a pretty good idea that this first slice (typically a vertical usable slice by the customer) will be available by X date, plus or minus <timeperiod>.

| improve this answer | |

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.