Estimating effort in software project estimation has been quite challenging. Many project managers relate the art of accurate effort estimation to prior experience in understanding what all needs to be included in the term ‘effort’. Effort estimation requires the understanding and ability to apply a uniform measurable unit to the variable (adjustable) factor – skill level- to arrive at actual effort estimates.
The inputs of project requirements are converted to some basic unit such as person day, person month. As I mentioned above the issue of uniformity arises as every resource varies in productivity and skill level. Besides various other factors such as technical knowledge, tools used and procedural factors affect project estimation. Various variables and limitations affect effort estimation in a non linear fashion. (1)
A lot of work has been in progress to evolve algorithmic techniques for effort prediction in the software estimation process. The purpose has been to lend greater accuracy to effort estimation prediction. If using function points for effort estimation, the general algorithmic formula for this is:
Where E =effort; S= Function points; a=productivity parameter; b=economies of scale/diseconomies of scale element (2)
This and many other models and techniques for effort estimation include the productivity parameter and staff skill level. These are both important aspects of effort estimation for the software project.
Algorithm models are aimed to provide a mathematical equation for software estimation based on research and past information such as cost factors, language of coding, risk parameters, skill assessment etc. Various models were developed out of it- such as COCOMO, Putnam model and Function Point based analysis. The benefit of an algorithmic model was that it allowed generating repeatable estimations simplifying modification of input data and customized formulas and it supported various types of estimation and sensitivity analysis, computed as per past experience.
Function Point Analysis
Function Point Analysis, a type of algorithmic model, measures the size and complexity of a software project based on functions points which the software is made up of. The benefit of FPA is that function points can estimate user stories or requirements analysis thus giving a rough idea of the project cost at the early development phase. Function points are independent of the language, tool and variability in implementation. Since function points are based on user stories, even a non technical person can understand function points measurement. Apart from this, function point data allows a project manager to monitor resource productivity and enable cost estimation of the project. (3)
Function point helps demonstrate the effect of minor variations in requirements on the project and enables quality assessment.
Productivity Pointers in Function Point Analysis
Measure Productivity of Programmers Meaningfully
Function Point analysis measures productivity in terms of function point per person per day and is more meaningful as it does not consider variability in programming language or programming style. By being able to measure realistic productivity and the cost, effective productivity levels within a desired time and cost range can be computed. If in an organization, the skill level and effort level mix represent a particular productivity standard, and a particular feature composed of certain number of function points must have a desired productivity level to fit specific time duration, adjustments can be made accordingly. So if time factor has to remain constant, depending on the productivity level of the various resources, allocation can be done by the project manager. As I mentioned earlier, project managers can use function points to monitor and capture productivity of associated resources (function point per person per-month), Function Point analysis can enable adjustment and re-allocation of resources to match and suit time and cost estimates of the project.
Skill Enhancement Time Should be Incorporated into the Estimation Process
I have come across organizations in the software industry whose focus is on techniques to improve skill level in their resources through various engineering tools, coding languages, reusable code libraries and techniques which foster smart work. These and many related methodologies aim to increase skill level and productivity of various categories of resources – analysts, programmers, engineers, testers etc. Any new introduction of knowledge or skill type for productivity enhancement of the resource will always take time as any new learning follows a typical learning curve. While estimating effort for a particular project, the learning period where the resource gains familiarity and maturity with the particular knowledge/skill type should be accounted for in time estimates.
A resource is trained if he/she spends just 5 percent of his/her time in learning; before that a normal learning curve would cause the resource to spend around 32 percent of the time to actually reach a state of being ‘trained’. This would leave around 68 percent of the time to be productive. This time period should be accounted for to calculate time estimates for getting a more realistic and achievable time estimate. (4)
Baseline Effort to be More Realistic
Besides these, baseline effort for effort estimation should not be based on what an expert estimator is able to achieve with his or her level of productivity and efficiency. The baseline effort should be more realistic and should relate to average productivity (good skill and good effort level). The average productive resource would take more time than an expert and have cost implications. However the cost of hiring the average resource would be low. At this point, the project manger needs to even out the two costs and calculate the best possible baseline effort.
It is a very challenging and laborious task to count function points to assess the complexity and size of a software project manually. By miscalculating function points, the error can severely disrupt estimation accuracy. Expertise and technical knowhow governing accuracy is by counting the function points accurately. To simplify manual labour, various organizations have currently launched automatic software estimation tools in the market based on Function Point analysis which help to automate function point analysis. Quick FPA (by Intelekit) is one such software development project estimating tool in US software development industry market.
Frank Tsui, Orlando Karam, Barbara Bernal.
“Project Effort Estimation.” Frank Tsui, Orlando Karam, Barbara Bernal.Essentials of Software Engineering. Jones & Bartlett Publishers 2013. 275-276. 
Shepperd, Martin and Chris Schofield.
“Estimating Software Project Effort Using Analogies.” IEEE TRANSACTIONS ON SOFTWARE ENGINEERING (1997): 737. 
“The Comparison of the Software Cost Estimating Methods .”DCU School of Computing. 15 December 201 <http://www.computing.dcu.ie/~renaat/ca421/LWu1.html>. 
“ESTIMATING SOFTWARE DEVELOPMENT PROJECTS.”HPMD LLC., 15 December 2015 <http://www.hpmd.com/hpmd/wquotes.nsf/85256253006987038525612b00479a1b/51807391198b1645852562530062ac18!OpenDocument>.