Analyzing Relevant Effort Drivers for Effort Estimation in a Software Project

FREE_submitting-winning-proposal-upwork_M-940x400Estimation of software projects is the first step for any software development firm. You have to conduct four basic steps before arriving at an estimate for your client. These four steps include:

1. To estimate the size of the project either in lines of code or function points.
2. To estimate the effort in man hours or man months.
3. Estimate the time of delivery –duration of the project and,
4. The total cost of the project – this is a direct function of the above three steps.

Generally, in most of any my articles I have been speaking about various factors and methodologies which would help estimation process per se. I will try and deal with effort drivers today which further help you in precise effort estimation for your software projects.

Effort Estimation Follows Scope Estimation

Software coding is in fact a small part of the entire process. Estimating the effort for coding is not enough and there are several tasks and activities which you need to note and list for effort estimation of overall development process. If you already have a well defined software development recording process in place, it is not a difficult task to chart effort for design, coding and testing activities. You need to record and calculate effort for project management activities, documentation, developing and testing prototypes, designing the deliverables, quality analysis, reviewing and debugging to name a few. The effort estimation would involve identifying the various effort drivers and estimate effort for each one of them to sum them up and arrive at final effort estimates.

Once you have estimated the size/scope, effort estimation can be done either through historical data of your past projects – what size project took how much effort or through extensive modeling techniques. Again historical estimates for future estimation holds true only if your development team is going to follow a similar development methodology as you used for a historical project – which means exactly similar development lifecycle, similar development tools and consistent team members with exactly similar skill and experience level. [1]

This however is not always true, as with changing technology we introduce new tools and techniques, the development lifecycle also varies with new requirements introduced (change in customer needs and demands), and even the team experience and skill level varies (new members join who may have different learning curve).

Certain organizations also rely on extensive modeling techniques with well established industry data to arrive at effort estimates. But these models are highly complicated and require additional technical expertise. You would need to study and develop the technical understanding of implementing these models for your project to arrive at effort estimate – which would require time. Additionally, not everybody would be able to do the estimation. You would need to employ a technical estimator specifically for implementing the models for your project – a cost to bear!

You might ask me – How can I estimate effort in a simplified manner? Is there a technique where estimating effort for a project is not time consuming and where any team member can be involved to carry effort estimation? The answer is YES!!

Effort Drivers

The primary task is to identify the ‘relevant factors’ which estimate effort for the software project. It is a general belief by software practitioners that considering too many factors /effort drivers help in creating the most accurate effort estimates. However, the truth is that few specific effort drivers have a significant effect on software development productivity and hence the effort. You should focus on these relevant effort drivers. Note that collecting irrelevant factors result in misleading estimation processes and may even bear a cost (collection, maintenance and analysis of redundant information). As I stated earlier, one size does not fit all, in estimation. Hence a typical model or relying on historical project data for present estimation is not justifiable. You have to ensure that the overall circumstantial factors and effort drivers which you are applying are suitable to your estimation environment. [2]

Takeaway – instead of relying on a fixed effort estimation model, devise your own effort model; consider relevant effort drivers which apply correctly in your present project situation.

You have to consider

1. Potential effort factors which are beyond measurable at the present moment (but would appear later).
2. Chosen effort drivers should be free of subjectivity and dependency on the estimator’s personal capabilities. It should be truly realistic and free from personal bias.

Takeaway – A combination of expert opinion and measurable data techniques should be used to identify relevant effort drivers for your project in the current project environment. Here contextual factors and suitable environments can be duly applied.

The major effort divers have been divided into certain categories which include: [3]

1. Personnel effort drivers which relate to productivity quotient and measure the skill, experience and competency of involved team members in various roles – analysts, designers, project lead, testers, maintainers, subcontractors. This would involve the project stakeholders such as product users and customers too.
2. Process effort drivers measure the effort related to various tools and technologies for the development process. For instance, if the project needs to be coded in Java, you need to measure the effort estimate for Java platform, measure effort for version control (if it is done), measure effort for the chosen device types and browser resolution, particular test environments, tool quality and usage, effort for integration with third party tools/external software, extent of customer participation etc.
3. Product factors would measure effort related to development of the particular product/software – the requirement analysis effort, design effort, coding effort, effort for prototyping, effort for documentation and analysis.
4. Project factors would relate to effort drivers associated with project management activities, resource management/allocation, time tracking, handling organizational bottlenecks (top management/client issues concerning project execution), work environment etc.

Take away: You have to study these factors in detail and apply relevant effort drivers from each of these broad categories fitting your project as per resource skill and efficiency, chosen implementation types, technology platform, coding environment/technique, testing environment, external tool/technology integration, product functionality, user involvement and project management activities.

Choosing Relevant Project Effort Drivers

Choosing the relevancy of an effort driver should be based on its effect on the overall development productivity and the project success and the extent of a circumstance which the particular effort driver affects. Relevant effort drivers are unbiased and unaffected by influence of project personnel – in short they are non manipulative and non changeable. Data associated with relevant effort drivers are easy to collect, open to analysis any time, and have clear depiction of the extent of measurement error. The software developers should not be able to control or influence the value of a relevant effort driver.

By weighing and analyzing the qualitative and quantitative attributes of the multitude of effort drivers, you can choose and weigh the relevant effort drives for your software project for carrying effort estimation.


Adam Trendowicz, Ross Jeffery.

“Selecting Relevant Factors Influencing Effort.” Adam Trendowicz, Ross Jeffery. Software Project Effort Estimation: Foundations and Best Practice Guidelines for Success. Springer, 2014. 68-71. [2,3]

Peters, Kathleen.

“Software Project Estimation.” 2007.University of Washington Computer Science & Engineering. 05 January 2016 <>.[1]