Project Estimation

sai0824 used Ask the Experts™
Hi Experts,
Please help me out regarding this
I have read that during Initiation phase (ie when requirements are not gathered yet and we have only the high level prelimenary scope statement ready) we do estimate using  either of following methods to get the ROM (Rough order of magnitude)

1) top down approach (Analogous)
2) top down approach (parametric)
3) WBS (Well we cant do this as we dont have requirements yet)

Now my question

Initiation phase :-
1) Analogous :  When we have similar projects done earlier which resemble the one which we are doing now then we can use.
Q) What if we dint do similar project ? Then how can we estimate

2) Parametric : All examples in internet show only estimation per unit. Its makes sense for a construction project. What about software project? How can this be done using concept of price per unit ?

3) I know how to use Use Cases and have read an article about use Case point estimation.
Can this be used in Execution phase of project management ?

4) During project does a project manager have to do various estimations at DIFFERENT stages of SDLC ?

I really am not sure about these points. Could you please let me know in detail.

I have come up with these questions as I havent found any answers after googling though.

Thanks in advance.

Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
1. If you any resources that have done a similar project then you can ask them for an estimate. For example, you could ask someone else that has expertise to provide a quote.  In our case, as prime contractor, we often provide ROM (and subsequent proposals) for work based on the quotes that we receive from potential sub-contractors who have more expertise than we do in a specific area.

2. Yes, this can often be applied to software projects, or at least to part of software projects.  If you have an repeating task, for example, if you have to create x number of user interfaces, or reports,  etc., you can estimate by trying to pick a reasonable number for one and then multiplying.  The more similar they are the better this works and you often have a situation where the subsequent tasks take less time which is often NOT reflected in the estimate.  For example, lets say you estimate 10 crystal reports at 10 hours each.  When you do the work, the first one takes 40 hours because you have some issues to work out. But then each subsequent one takes less time becuase you haev already worked through the issues so you save on that. It is a way to spread the risk while at the same time having a reasonable basis for your quote.

3.  This is a much more detailed technique and we don't use it for estimation. Its a great idea (I love doing analysis) but we are working in the real world and it isn't practical for us because it involves a lage amount of work and early on people's  ideas of what will make the project successful is often very divergent from what actually happens.  We have to come up with practical estimates *before* we are awarded the work so we can't put huge amounts of resources into creating an estimate.  By practical  I mean that the estimate has to be reasonable for the customer while at the same time creating the revenue to cover our expenses. The ability to create practical estimates on sketchy information is something that takes experience and we have experienced Engineers that are very good at it.  We do carefully limit the scope and deliverables when we provide an estimate and the process of working with the customer to negotiate scope and deliverables is one of the most valuable tools in coming up with a practical estimate.  We do use a simalr technique in the testing phase but at that point things are very stable, the effort is well-defined, and we know that it will not be wasted.

4. Absolutely, estimations are required at every stage of the project.  

If you have more questions, please feel free to ask, I am a hard-core programmer that (unfortunately) finds that now I have to spend most of my time estimating and doing proposals in order to make a living.  We don't use a lot of theory or fancy methodology but we have to put real dollars on the line every day. Many of our efforts are firm, fixed price so if we get it wrong we eat it. We have to satisfy the customer and make money doing it.  It gets scary sometimes.


Thanks a lot.. It was very informative.

Regarding point 4

4. Absolutely, estimations are required at every stage of the project.  
Q) Can you please let me know in each stage what can be used.

for eg :  Use case point estimate ---- I can use in SDLC Phase of  Analysis (ie when I have requirements clear)

Now lets say when I want to use three point estimate. Can I use it. If so why again when I have use case point estimate.

I heard it can be used too. ie 3 point. (When and in which case this can be used)

Q) lets say a customer comes to you and asks for Quotation.
Would that normally be a high level quotation or does he give full tasks for u to analayze the efforts?
What do u mean by Proposal.
Keeping in mind that my explanation is based on my own practical experience, not on academic methodologies,  or in other words, in real life the neat clean divisions that most methodologies imply don't actually exist.  It's great for discussion but the requirements are not actually clear at the end of analysis, hopefully they are at least tending in the right direction. OK, so that said and based on the 4 tools you mentioned in your question, (1.Analogous Analysis, 2.Parametric Analsysis, 3.WBS, Usage cases).

Using the SDLC stages from Wikipedia:

Analysis  - 1, 2
Design - 1,2,3,4
Implementation - 1,2
Testing - 1,2,4
Evaluation - 2

All very arguable.

So I googled 3-point estimate and unlike the other tools you mentioned, which we either actually use or I was at least able to relate to what we actually do, I don't think we do anything like that.  Not to say it isn't useful, I'm sure that there are some kinds of projects where that kind of mathematical rigor actually works. To give you an example, we actually use WBS in assigning and planning workflows and creating annual departmental budgets. But I've never seen anyone do a "3-point estimate", which just means that my exposure is limited, not to say that people are not using it.

1. Customer informally inquires about the feasibility of an effort.

2. A conversation ensues, what are you trying to accomplish? Have you already done any analysis? Do you have any ideas what the deliverables might look like? What issues are you trying to mitigate? WHat efficiencies are you trying to gain?

3. Armed with a very general idea of what the customer wants we verbally provide a ROM.   You could say that we do this using Analgous Analysis or you could say that we make it up or pull it out of thin air.  I know that might seem wrong, but in my experience that is what happens.

4. Is the customer still interested? Or we have to do a proposal. We create lists of things that we think will have to be accomplished (I hesitate to call them tasks because they are very high-level and not actually assigned to any one).  We create lists of what we think are the deliverables, we have verbal discussions with the potential customer to clarify (buit we don;t give them documents). We get quotes from sub-contractors (making clear to them that these quotes are for proposal purposes and thee work is not actually available yet). We make estimate of in house costs, pull all that guess work together and write it up into a  a proposal. The proposal says that this is what we think should be done, this is what the deliverables are, we provide supporting documentation, and we say how much it will cost and how that cost will be allocated, fixed-price, timae-and-material, etc.

5. If the customer actually agrees, a contract is signed, and then the fun really starts because we actually have to deliver what we promised.  Hoo Boy! That is when the stew hits the fan.   There is a saying something like "No plan ever survives the battle". That is so true. We have to make it come out right even though all sorts of unexpected things happen.  Some people say that better planning would solve that and I don't find it useful to argue with them.  So anyway,  we have to make the customer happy, and we have to cover our expenses, (and hopefully make a small profit), and we are not always sucessful. But we usually are.  

The most important thing to me is that the proposal is very specific with regards to the deliverables.  The customers recollection of what he is supposed to get is often very variable. It is very important  that the deliverables are explicit and specific in the contract in order to bring the project to a successful conclusion.  The customer will be happy if you give them a little more than what they were promised. But if nobody knows what was promised that is a recipe for disaster.
Learn SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

Item 4 should read: "Is the customer still interested? Then we have to do a proposal ...


excellent  thanks a million,

As per what  I understand . Trying to understand the flow

Customer sends a  RFP  request to a Company lets say. You as the estimator would send him back a Proposal document with all the estimates in it. If he is OK with it , then both the parties would sign an agreement? Am I right.

Now Would the Proposal have a  Cost Estimate and Delivery date mentioned? Fixed estimate or would it be a Rough order of magniture showing variable of  +-20 percent or something.

Normally during Project management processs during initiation phase Project manager gives this ROM right which is documented in Project charter, isnt it? Does the procedure vary in Bidding ?

Hope you got me. Can you please clear this.
In general this is correct.  Often times, the RFP is not formal, but if the request is coming from a large organization, and/or where competitive bidding is a requirement,  is would be a formal RFP.

If the proposal is fixed price, then it is not a cost estimate, it is a price. There are other types of contracts as well.  I am not in the finance area so I am not very knowledgeable about how that works - sorry.  I work more on the analysis, gathering requirements,  getting quotes, writing proposals - that kind of thing.  For example, even if I write most of the proposal I don't generally see the price, someone in the financial area does that.  

Hope that helps!
On that last comment I should clarify. A lot of estimation goes into creating the proposal. Sometimes supporting estimates are included in the proposal. But if the proposal is fixed price then the amount that the customer will pay is not an estimate. It is an actual price regardless of the accuracy of the underlying estimates.


Thanks Major. It was a great help.

Moreover I posted two more questions. May be you can help me out in that too.


Thanks again.
Thank you, good luck on your project! I'll look for the other questions.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial