Project Resource Estimates
Posted in Project Managment on October 23rd, 2010 by Rachael
Project resource estimates are extremely important as they allow developers to make “realistic commitments” to clients and management. Perhaps one of the most important resource estimates is cost. The main contributing factor in cost is effort, which in turn is comprised of the project size and developer productivity. Therefore to accurately estimate cost, one must first estimate the project size and developer productivity.
Estimating Size
There are two well-known types of software size measures; lines of code (LOC) and function points (Humphrey, 1989, p. 90). LOC can be difficult at first to estimate, however generally subsequent estimates become more accurate. This is due to the simplicity of LOC; as a metric it is easy to store, calculate and compare to other LOC estimates (Humphrey, 1989, p. 90).
LOC estimates are generally based on previous project experience. There is a range of publicly available software project metrics, so project managers with no prior project metrics of their own can obtain such data. The metrics can then be analyzed to estimate the program size.
LOC are widely used and can easily be counted, however they are language dependent and program complexity is not considered in the estimate. Function points are a standardized alternative size estimate that considers the complexity of the software. Inputs, outputs, inquiries, master files and interfaces are all multiplied by specific factors, and then added together to produce the number of function points (Humphrey, 1989, p. 91). Each function is then subjectively weighted by its judged complexity. While function points are standardized, their calculation is subjective and cannot be automated. Because of these difficulties, function points are not as widely used as LOC, however like LOC, available metrics can be analyzed to produce new estimates.
Estimating Productivity
There are many factors that can influence a developer’s productivity. Humphrey (1989) concluded from analyzing 500 of IBM’s System/370 projects that “productivity varies significantly with the degree of program modification”. DeMarco and Lister (1985) hypothesized that environmental factors, like having a private and quiet workspace, can also increase the productivity of developers.
As with LOC and function points, there is a lot of publicly available productivity data for organizations to use if they do not have access to their own such data. However, similar to size estimates, productivity estimates are much more accurate if they are based on the organizations’ own statistics (Humphrey, 1989). To me, this makes perfect sense. Environmental factors, program languages and the degree of program modification will vary between organizations, so of course the best data will be from within the organization.
Estimating Resources
There are many different methods used by organizations to estimate resources. One way to estimate effort in particular is by using the basic constructive cost model (COCOMO). Basic COCOMO is a simple model used to estimate the number of person-months required to develop a particular project (NASA, 2007). The model estimates cost based on the estimated size and type (organic, semi-detached or embedded) of the team.
One popular resource estimation method is the Wideband Delphi Technique (Humphrey, 1989). This technique involves a group of experts/stakeholders being debriefed on project requirements and estimation issues. Each participant then provides an independent estimate, which is shared and discussed with the rest of the group. All participants can revise their initial estimates, and re-share with the group. The cycle continues until the estimates are agreed on.
I believe the Wideband Delphi method is particularly powerful and rather easy to do. It doesn’t require much training; all that is needed is some teamwork skills and an understanding of estimation. Furthermore, a variety of estimation techniques can be used individually. For example, one participant could estimate effort using COCOMO; however this is not constrained to the rest of the group.
Estimation Error Variation
In a lecture I attended by Readshaw (2008), he explained that estimation at the beginning of a project is extremely unreliable. “You don’t know what you don’t know” he said in regard to long term projects. However he does concede that towards the end of projects, estimations become more accurate. This concept is captured in the cone of uncertainty, shown below (Construx, 2008).
Cone of Uncertainty
The cone of uncertainty describes the factor by which estimations can be incorrect at various stages of the project. The horizontal axis contains project milestones (note, in figure 3, the list is just an example), while the vertical axis describes the error variability. As shown above in figure 3, estimates made at the beginning of the project (initial concept in figure 3′s example) are likely to be 4 times over or under estimated.
So how can a project manager narrow this variability in estimation? I think that error variation can be minimized by using the Wideband Delphi estimation technique, simply because the technique forces a variety of opinions to be considered. Furthermore, Readshaw (2008) believes error in estimation can be reduced by forcing the development team to be realistic about their estimates. He also believes that estimation variability can be caused by not considering who is implementing the plan. “Not everyone operates at same level of productivity” he says, and goes on to say that the person estimating should factor in the experience of the team implementing the task in order to reduce estimation variability.
I think this is a very important point; estimations of resources are generally formed by multiplying the productivity rate by the project size, and since different programmers have different productivity rates, it makes sense to cater for those varying rates.
Readshaw (2008) expresses that an agile process can also help reduce error variation. Aoyama (1998) states that the agile approach “emphasizes rapid and flexible adaptation to changes of the process, product and environment”. Agile approaches basically deliver parts of the product incrementally. The power of the agile process is that developers would only plan for each increment at a time. Therefore developers wouldn’t make any long-term estimates. However, Construx (2008) believes that miniature cones will appear on each iteration of the project development cycle, and theoretically, error variation would still be the same.
So how is it that agile processes still manage to reduce error variation? Such processes are only concerned with short term estimates, and this prevents developers from “committing” to long term, unpredictable and risky tasks (Construx, 2008). This means all commitments are likely to be steady, and accurately estimated, thus reducing error variation.
References
Construx (2008). The Cone of Uncertainty. Retrieved 20 October 2010 from http://www.construx.com/Page.aspx?hid=1648.
DeMarco, T. & Lister, T. (1985, August 28-30). Programmer performance and the effects of the workplace. Paper presented at the Proceedings of the 8th International Conference on Software Engineering.
Humphrey, W., S. (1989). Managing the Software Process: Addison-Wesley.
NASA (2007). Basic COCOMO. Retrieved 20 October 2010, from http://cost.jsc.nasa.gov/COCOMO.html.
Readshaw, N. (2008). Planning and Tracking Software Projects. Presented at the CSSE3002 Guest Lecture, Brisbane.
