How should I handle project cost (in time) to a client without committing too much work?



  • 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.



  • 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.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2