The process of estimating the effort required to build software has to be one of the most important processes in the field of Software Management and Process Improvement.
I have encountered two schools of thought on who should produce estimates.
The first is that an experienced person, trained in estimation techniques should do this using the people that understand the technology as references (typically analysts are used, and sometimes the developers themselves). In this view, the estimator acts relatively independently of the individuals that may receive the assignments, and the writers are handed the assignment with the associated time budget, after the fact.
The second is that an experienced person as described leads the people that will actually write the software through the process. In this view, each component of the estimate is only valid if the original estimator (the software developer who estimated) is going to get the assignment against which he/she produced the estimate.
Approach 1:
Merits include: specialisation of the estimator in the field, speed of estimation, de-coupling of the estimation (and therefore sales process) from the development group (useful under the pressure of a competitive bid scenario).
Demerits include: Lack of buy in from the individual that must ultimately deliver a component in a budget that was produced by someone else, the inability to profile individual software developer estimation ability by using stats, the possibility that a generalisation in the estimation process can produce a gross error that will result in a loss position (bad CPI) for the project.
Approach 2:
For the most part, the merits/demerits of this approach are the opposite of approach 1. More importantly, the major demerit of this approach is the complexity and cost associated with producing the estimate. It is feasible that estimation effort of this nature may include many valuable resource hours (the developers also require specialised training for estimation techniques) and that it may not converge to a sensible answer if not managed correctly. The major merit of this approach must be that it can be calibrated against individual estimation ability (providing one keeps stats of estimation versus performance of individuals), and as a result can produce quite accurate granular estimates.
From a Management perspective, I prefer the first, from a Business perspective, both have their good points, and from a Process Improvement perspective the second is attractive, because it can be calibrated.
I prefer to come up with the initial WBS and assign task estimates, then review them with the involved developers. Because I tend to work on projects involving the same technologies over and over, I can usually sniff out an estimate that is too high or too low. That way, it takes less developer time because I've at least made a guess, but at the same time, they buy in.
I'm sure that it depends in part on the size and maturity level of the organization. In the young organizations I've worked in, there's neither the budget for an estimator, nor enough uniformity of skillsets and experience for any one person to create a total estimate. Saving Changes...
Linda Yee Man ChengAssociate| Morgan Stanley Asia LimitedCauseway Bay, Hong Kong
But how do you do estimates for projects types with technologies never used before (at least for the organization) -- e.g. when working in a software company producing shrink wrapped enterprised software products? Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Whether shrinkwrap or one-off the estimating process is essentially the same. First you need to benchmark the talent level of the development team in terms of what they can produce given various levels of complexity. Next you need to identify every component of the application and rate each component in terms of its complexity. By each component I mean every screen, report and periodic process. With this in hand you will need to do some preleminary resource allocations of people to components so that you can apply thier productivity metrics to those components. Be sure to estimate all aspects of each component (design, coding, unit testing, regression testing, documentation, training and implementation. If you want to use a MACRO apporach you can cluster components in terms of complexities and use a talent metric that most represents the teams production capablity.
As far as building the talent / production metrics you will need to have the team build a few components of various complexities. Standards and Methods will go along way toward reducing the variation you find among the results achieved. Also, the tool sets will impact you too. Finally, the more work done at the data dictionary and view levels the less coding will be needed. If you are developing using objects and VB I suggest you agree on standard controls too. Commercial apps need to be very consistant in look, feel and construction. Good Luck Saving Changes...
When estimating, in addition to considering the tasks Michael Wood mentioned (design, coding, unit testing, regression testing, documentation, training and implementation), also consider the amount of time spent on other activities, including code reviews, helping other developers, support (whether supporting customers or supporting a Support organization), attending meetings, and even vacation/sick/personal time. Also, don't forget education time--the time it takes to learn new technologies). And while you're creating your list of components that must be built, don't forget the time needed to create tools that will aid in the development and processes, such as build tools (e.g., makefiles) or test harnesses.
I've found that it's critical to get each developer to buy into the estimates for his/her own tasks. Without that buy-in, developers start the project with skepticism. With buy-in, developers will often do whatever it takes to meet deadlines, in part because they perceive the deadlines as *their* deadlines.
The estimate can only be improved by involving the PM and the developer, so the approach we use is top-down, bottom-up. The PM develops the high-level plan and the developer modifies and validates those numbers with the detail determined by the quality of requirements, skill level of the respective developer(s), the complexity of the code, and availability of screen templates and standard code structures. Equally important is the Risk Management Plan for development. This is inevitably what makes any development project successful in terms of schedule, cost and quality. Saving Changes...
One of the issues related to estimation, as several folks in this topic have mentioned, is that of "buy-in" of those doing the work. One of the unnecessary delayers and adders of resistance to estimation is the too common practice of looking for one number, or of turning a range of numbers into some sort of average that is seen as a commitment.
Rather than beat everyone over the head about such numbers, the practice of utilizing a 2-point range estimate helps to assure the deliverers that their concerns about uncertainty are covered in the overall project promise. It also, combined with an appropriate "relay-race" mode of work assures project ownership that the project will be delivered without wasteful Parkinson's Law impact and without compromising quality for artificial, meaningless interim due dates.
That said, the PM is not the person to develop estimates alone. They must be captured from the people who will do the work or an experienced representative. Saving Changes...
Linda Cheng wrote: But how do you do estimates for projects types with technologies never used before.
It depends on what you are using them for: If they (the estimates) are going to be used in a competitive bid, then you are asking for trouble, as people miss the finer issues when they don?t have thorough knowledge of the technology in question and this can cause major set-backs.
When a company embarks on a project using new technologies (software, tools and process), it should probably be approached as an R&D project. The most important thing to get from such a project is experience ? later to be used for making sensible estimates.
If you don?t have the resource (money) to gain experience in the technology, then you will most likely have a rough trip, and rely on heroics to get you through (on the PM and developer sides).
The important thing here is that the clients will have been sold a bill of goods and this will be accompanied by an expectation of delivery ? set the expectation right at the beginning (that the technology is new and point out the risks) and you will find that the process is manageable ? even if the client has to exercise the choice to walk away from the project ? give them this option (to cut their losses).
You should also ask the question: How is this product going to be supported in the future. Remember that the expenses don?t end when the product is delivered. Your company may decide that this new technology is not right for them, and the client will suddenly find that they have a support issue.
There is much, much more to be said for the Risks of estimating in an area where you have little experience ? none of it is good. Saving Changes...
