Please login or join to subscribe to this thread
My recommendation is forget about ROM, Hard or other things. All you need to know about estimations is inside the Barry Bohem´s Cone of Uncertainty. The cone was included inside PMI´s estimation standards after lot of people like myself pushed a lot..jejejeje. Take a closer look to it. On the other side, while you can visualize it inside the cone, remember you never will get 100% accurancy by definition of estimation term and you can find about that in the theory that is the basement of estimation: mathematical theory of errors.
First of all thank you for your time, I certainly appreciated , But how does the cone help you produce numbers for the leadership team? The cone can work for software gigs perhaps, but for cascade projects? where some of the costs are already known, perhaps the cone may not work, or am i confusing?.
The fact is that I dont want to produce a ROM then they agreed, then i will show them an estimate with better numbers and at the end of the project they will tell me, oh wow the cost was higher or lower? you know what i mean?
Developing an estimate with high fidelity can cost a lot of time and money. Sometimes you need a rough estimate to determine whether or not there is even a business case to develop a much more precise estimate. Otherwise you are just developing a high precision estimate of why there is no business case to launch the project.
I avoid ROMs. I can't say I never give them anymore. To Cesar's point, sometimes leadership pushes for an estimate when you don't have enough information to provide anything definitive. In these circumstances, I explain the knowns and unknowns and commit to those things that I can. For example, at the beginning of Planning & Design, I am comfortable estimating how long Planning & Design will take, with a margin of error. I am not comfortable estimating how long it will take to deliver a solution when it has not even been defined, yet.
Once the solution is defined and tasks identified, assigned, and estimated, I can give a more confident estimate.
Keep in mind, it is rare that people get into leadership positions by being stupid. Good leaders are are going to push you to deliver. They're going to challenge you to excel. And they understand how estimating works. They're looking for someone to take accountability, not make excuses. They may not always do a great job of it; they're people, just like the rest of us.
In many cases, it is difficult to give a an accurate estimate at the outset of the project especially when there is no information available.
In Construction, we use ROM's to give a high level indication (Ball Park) for the budget. For example, if a client asks:
How much do you think it would cost to build X-Building ? We go back to our data base, see what was the cost per Square Foot for building a similar building and advise the client accordingly. This estimate provided to very + or - 35% as more in know, requirements are clear, and design drawings are underway.
In summary, yes, we do make ROM's estimates then this is followed by Class D estimates, Class C, B, and the most refined and accurate one which is Class A which will be used in the contract with the client.
Hope this makes sense.
Interesting your question
Thanks for sharing
I suggest you read:
Very interesting, let me read more abut the cone perhaps i am not seeing the entire picture. Thanks again
, I agree with you, then we could treat the ROM as a (ballpark) figure to then come up with an estimate.
Which then for analytics perspective we can then attach the ROM to an estimate and attach both (ROM and Estimate) to the project, to get more data in, that could be eventually be used for another similar project. What we are trying to do is to be more accurate with the prediction of any given project. Hence the whole question Thanks Keith for your time
The "time to take to complete a project" is yet another good point to estimate, and perhaps the most difficult one, as things tend to change during a project, logistics, resources, budget, etc.
Thanks for your input Aaron
Please login or join to reply