I normally don't like to be critical about articles, but in my own opinion, this article looks like it is describing a shotgun approach to estimating a project - break the project into miniscule, ridiculous pieces and then over estimate everything. If the example given were to come across my desk as a project bid, it would be dismissed in five minutes.
There are several factors that seem to have been left out, or at lease glossed over, in your article. The biggest one deals with the risk assessment and handling critical risk factors.
You state that a high risk is where all stakeholders have an interest, and low risk is where few do. I have to disagree there, risk isn't based on who's looking at it, risk is based on complexity, availability and ability to complete a particular area, feature or task. For instance, a client may require that a particular report be placed in the system, obviously, since this is a requirement, the development firm also looks at this a necessary item, and the subcontractor that is hired to write it sees that this is an important item. Ok, by your analysis, this is a high risk item ... not so, becuase everyone (including the client) knows that writing a report is a simple matter, as they have already prototyped it to give an example. The development firm knows that the technology involved is already there, and finally the report sub contractor has done this many times and knows the tools that are needed are there. This really is a very low risk item.
A more realistic example of risk would be something along the lines of logging into a legacy mainframe system and pulling data some amount of data. The customer does it every day, they assumne it can all be done, but don't look at it as a high priority because its not in the package of results they want their new system to spit out. The developement firm sees this as a bit more of an involved item because they are not completely familiar with the old system. Now, the risk according to the article, would be medium or low, only the development firm really sees this as a risk factor. However, the development firm does not know with the proper interfaces are in place to allow the new system to access the old data, or for that matter, if the technology exists. Also, will new program modules need to be written on the old system to quickly get data out, and is the system so old that there are few to no progammers capable of writing those modules. The development firm also knows that if this data doesn't get pulled, then the end deliverable reports are going to be missing some critical information that will need to be retrieved some other way. So, now we have identified a potential project-stopping risk factor. This is an extremely high risk, and as another commentor stated, should be one of the first items researched and tackled in any development project - "rush to failure" I believe is the term sometimes used, minimize the project impact by determining failure and alternatives early.
Now, when you take into account the descriptiong of risk factor I have put forth, then factor in the risk description in the article (which, by the way is more aptly named 'perceived risk', slightly different) you have metric for the project estimate that helps to gauge portential failure and assist is client expectation management.
I've gone on about this enough, but a few of the other things that you failed to mention is that risk factors are always changing and need to be updated, for instance with the legacy system, once it is determined that the interface technology exists, and the data can be retrieved without additional programming (or additional programming and a subcontractor is found), then that risk factor obviously decreases -- and when that particular project area is complete, the risk is removed. Also, estimators should be familiar with development staff and capabilities, grossly over estimated project often come from estimators, business analysts and sales people who have no contact with the developers and have no clue as to what may already be in their own library arsenal.
yep this is a shotgun view of estimation. it could be read along with another one of my articles at the following address, http://www.codeproject.com/gen/design/Estimation.asp
(not that it is a better one either).
could you suggest some web sites where more info on estimation (and risk) can be found for the non-initiated.
i havent gotten too much into risk as i have a limited knowledge of the subject. i mentioned it only because it is an important factor that affects the cost of the project. risk estimation based upon specific modules/issues, done with a full fledged design is always a better option. my aim was to work out an estimate even without getting into the design.
BTW just fyi of all the readers, (so far) all the articles i have written here (so far) are not based upon info from other articles/websites/books. They are only my own views on the subject (refer sub title) based upon my limited experience.
Thanks for the feedback,
an idea can change the world
Last Visit: 31-Dec-99 19:00 Last Update: 21-Apr-15 9:41