Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

I work for a private investing firm that is looking to move from a face to face business to online business. They want to create a large, scalable website that can handle thousands of accounts and hundreds of thousands of transactions. They want an upfront general estimate of what this would cost.

On investigating this it seems the general consensus is that it is impossible to accurately estimate this without knowing factors of scope, scheduling, and quality. They are not happy with this answer.

How can I put together an early cost estimate that is somewhat accurate, and back it up with data I didn't get by throwing a dart at a board and multiplying by $500,000?

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

Spikes, Assumptions, and Assessments

On investigating this it seems the general consensus is that it is impossible to accurately estimate this without knowing factors of scope, scheduling, and quality. They are not happy with this answer.

Stakeholders are rarely happy with the reality that poor-quality specifications lead to inaccurate estimates. There are a few potential solutions to this common issue:

  1. Bound your estimate with documented assumptions.

    As an example, you might base your estimates around other similar projects (or a collection of projects). Itemize your assumptions about scope, resource requirements, and quality of deliverables, and clearly state that your estimate is based on those assumptions holding true throughout the project life-cycle.

  2. Perform a paid assessment with a documentation deliverable.

    Make the first part of your engagement an assessment where you delve into the project's specifications and assumptions. For example, perhaps you could engage for two weeks to craft a more-accurate estimate of the total project based on the additional information you gather during the assessment.

  3. Spike a solution.

    In agile projects, one often uses a time-box to sketch out a prototype or explore a potential design. Crafting a wireframe or prototype will often give you enough insight into an epic to refine your estimate based on some real data, and provide additional detail about the project's underlying assumptions.

Confidence Intervals

You can mix and match estimation solutions, either with some of the examples listed above or with other methodologies. Regardless of how you proceed, though, the goal should be to provide a sufficient basis for assigning a confidence interval to your estimates that have some reasonable chance of success based on your documented assumptions.

Because the cone of uncertainty is so high at the start of a project like this, it is important to document your estimation methodology as well. That way, the means by which you arrived at your estimate are clear to both the stakeholders and the project team, often improving everyone's comfort level with the estimate itself.

share|improve this answer
add comment

This is a ROM, a rough order of magnitude. By definition, you have a plus or minus 50% and 30% respectively.

This has been done before. Find out where, learn the players, and pay for a top down ROM. Submit a range and firmly qualify that expected variance when it comes down to a more tactical estimate.

share|improve this answer
    
This is exactly the lead I needed, thanks! –  jokker Dec 9 '12 at 21:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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