Estimation of a software project is surrounded by uncertainty and risk. As a project manager you are dealing with various parameters which you are aware of but do not seem to appear. The greatest challenge is being able to figure out these parameters which you are not aware of but might show up unexpectedly affecting the most certain and best estimates in a negative manner. The best estimates can turn awry if foresight and past experienced are not applied in this dynamic environment of software project estimation.
Effort Estimation is Highly Dynamic
The problem of uncertainty and variability is most prominent when it comes to effort estimation. When we estimate effort for a project in person months or person days, we are actually dealing with the most dynamic and variable component – ‘person’. A project is composed of a number of activities each requiring different categories of skill and expertise. But the ‘degree’ of expertise/skill and the ‘intent/endeavour’ to display that skill is something which creates great disruption and dynamism in effort estimation.
Effort should not be estimated simply by the time tracking system used for billing as it would understate or overstate effort linearly. The real effort should be estimated by considering the ‘hours worked’ and not just the ‘hours billed’. Many times, when scheduled estimates go awry and the team has to work overtime, the overtime effort gets unaccounted. If in the future, the historical data of a project which has unreported overtime effort is applied for effort estimation for a new project, it would end up being underestimated. As a project manager you have to understand that realistic and accurate effort estimation is about ‘actual work hours’ which is a function of productivity.
Productivity Fluctuates Throughout the Project
As we have seen, irrespective of the industry or work category, the productivity and efficiency matrix of a resource is affected by the ‘skill level’ and the ‘endeavour’ of a particular resource. There is also the problem of variability in productivity as a resource might not be able to perform his or her task with similar levels of productivity throughout the duration of the project. The resource would most likely be at its peak level in the initial stages (first few weeks), and diminish to average level at later stages. This might happen due to several reasons such as getting associated with some other project task, organizational activities, sparing time for knowledge upgrade etc.
As a project manger you are faced with the task of measuring skill level and endeavour to account for productivity in effort estimation. Below is the list of factors which you should consider before carrying effort estimation for a software project.
Factors Affecting Productivity of Resource
As I mentioned above, productivity is a factor of skill level and endeavour put by a resource into a job. Explaining this further, skill level is governed by:
1. Technical Competency – this refers to the degree of technical knowledge required for the particular task. The technical quality of code which a resource would write would affect the quality and security of the software and determine technical skill of the programmer. When effort is estimated, factors such as the ability of the software to be equally functional across different platforms, devices and test environments should be taken into consideration. This would help the project manager to establish acceptable technical competency of a resource for a project based on its requirements.
2. Experience of Similar Project – past experience of working in a similar or related project. Past experience would determine how fast the particular resource will be able to learn and familiarize with the project in hand. A past experience would help him or her to break down the problem at hand most efficiently into subtasks and devise most optimum solution in the shortest time duration. The capability of resource should also consider his/ her experience in dealing with the degree of complexity and size of various projects in past. So a programmer lacking experience in a highly complex and large project would not suit as the time taken for grasping the complexity would lower his/her productivity.
Endeavour to complete the work is governed/affected by qualitative factors. These include the:
1. Intent to deliver work on time which is a factor of focus and motivation towards task completion in the prescribed schedule.
2. No project related activities which might include a resource getting involved in meetings not related to work, skill enhancement/knowledge build up session, and other administrative organizational activities.
The factors affecting productivity are interrelated and interact with each other in varying proportion to affect effort estimation. It is essential for an organization to design a productivity parameter for measuring productivity by designing a scale and calculating the optimal threshhold/average productivity. The project manager can use this to estimate effort and hence schedule.
Since complexity of a project also affects productivity, it is essential to incorporate the complexity factor into effort estimation. The size of the software project should have a well defined standard and relate to the effort. Using Function Point Analysis as a size measuring parameter is the most effective strategy. Function points can denote the size of the project and calibrate it to small, medium, or large. Depending on the experience of the organization and its team, the number of function points of a particular project can be used to specify size. Again, an average productivity in terms of function point/person month should be calibrated for different sizes (and programming language) of project to calculate a base effort.
Specifying different categories of Implementation platforms and platform technologies for a particular project and measuring all types of effort (design, development, build, review, installation etc) across each platform type and technology based on the productivity of the team would help the project manager to carry realistic effort estimation for a software project.
Quick FPA the software estimation tool which enables automatic effort estimation using function point analysis as the estimation technique in the quickest time possible. Register online at www.quickfpa.com to explore and understand effort estimation in the easiest and quickest format.