As I have discussed in my other articles on this blog, software project estimation is a term which occurs in conjunction with the team uncertainty and approximation. We have seen how presence of hidden and unknown factors blur an estimator’s vision from considering various hidden risks and elements for correct software estimation. The resultant chances are either underestimation or overestimation. Under-estimation would result in poor scoping resulting in scope creep at later stage. It might cause poor staffing of the project which would later cause the team to burn the midnight oil to complete the project before deadline – thereby causing team burnout, poor performance, low morale, and even attrition. Overestimating the project could have financial implications with the software company losing the project!
In many studies and systemic reviews it has been ascertained that poor scope definition, improper objective setting thereby causing inadequate resource allocation is the main cause of software project failures. This makes user requirements definition and estimating resource allocation to hold strategic significance. However we always have the uncertainty hovering over them.
I have always talked about this term in most of my articles in the context of software estimation. But the prime question before all of is: Till what extent as developers do we allow uncertainty to cloud the estimation process? How significant does the element of uncertainty remain to affect estimation? By estimating the significance of uncertainty in combination with hidden risks, known and ascertainable unknown variables, and client’s funding limitations and the software development company’s personal limitation with respect to project viability and financial feasibility, uncertainty can be handled to a great extent. Project managers need to do an assessment of these factors before starting the estimation process. As a development team, you should always remember to quantify uncertainty before dealing with estimation.
Metrics Contributing to Uncertainty
When I say, we need to grab the significance of uncertainty by actually quantifying it, it means that we have to identify all those factors which creates uncertainty in project estimation.
- Uncertainty surrounding user requirements analysis and management – proper management of requirements ensures that the system being developed is as per the user need and would enable him/her to solve its problem. It would ensure no scope creep or additional burden of work at later phases of development. This requires the estimator to decompose the software into lowest possible user stories and user actions for listing the accurate user requirements. I have always associated this as the most important uncertainty to deal with since this forms the seat of all estimation process.
- Uncertainty surrounding the scope of project, project development and progress at later stages as per schedule. Project progress can be measured through the rate of growth of project in the scheduled time and cost. Project managers need to factor in the incidence of a growth in original requirements and hence the coding associated with it.
- Uncertainty associated with project cost to determine effort cost, phase cost, enhancement, improvement and maintenance cost. This would ensure that project viability in terms of finance is handled from both the client and Development Company’s perspective.
- Uncertainty associated with effort estimation and hence deciding staffing and productivity matrix, ascertaining any additional effort with respect to improvement, increased requirements/functionalities, defect handling effort.
- Uncertainty leading to schedule delay or failure to meet deadline which would cause identifying the factors which would cause such failures and the effects.
Here as you might be noting, that we are trying to nail down uncertainty by trying to cover one or more factors which would cause the project to either overshoot with respect to time or cost or both. Essentially all the factors leading to uncertainty are interlinked in some form or other.
Uncertainty leads to another element called RISK. As per the Software Engineering Institute, a Conditions, Transition, Consequence (CTC) has been defined. It says, for risk to exist
- There should be presence of one or more subject
- Presence of one or combined events with a non-zero probability of happening
- A cause and effect relationship governing final outcome, and
- The situation must be deemed unwelcome in consideration with the anticipation of involved subject causing significant harm to them
Broadly speaking, a software project can be deemed as risky if the key objectives of the project in terms of functional and non functional requirements, scope, time or cost are not met with respect to estimated variables.
Dealing with Risk
I would put down some pointers that essentially handles risk in a software project estimation process.
Project objectives – Project objectives should be well developed and shared amongst all so that no point is missed out. It should be comprehensible to all involved stakeholders and quantifiable.
Ensuring that allocation of resources is not just optimal but also not wasteful. Channelization and management of resources is another primary risk averting step.
Risk management should be standardized and clear by improving requirements, development and management process. Requirements should be expressed in various implementation types. This means any user action which would trigger the system needs to be included. A well formulated requirements document is the primary step to reduce risk factor and improve software estimation.
The software estimation process is another area which enables handling risk to a great extent. The process should be methodical and standardized in nature. It should be capable of producing quick estimates to save the most precious resource – time. The software estimation process should be capable of assigning complexity factor to the estimation process so that the effort and hence cost can be increased or decreased as per the scale and nature of project. Allowing the effective reuse factors in the estimation process would prevent overestimation and thus prevent jacking up overall cost. Using a software estimation tool could be more useful as they come up with built-in criteria and tools to apply the needed changes for immediate results.
We at Intelekit specialize in software estimation for software projects catering to multiple industries and variable budget range. We deploy our estimation software Quick FPA to provide the closest and risk free estimates.
For greater information on the process or tool register and receive an invite!
Gluch, David P.
A construct for describing software development risks. Technical Report CMU/SEI-94-TR-14.
Software Engineering Institute, Carnegie Mellon University, 1994.
“Risks, requirements and estimation of a software project.” ESCOM-SCOPE 99. Herstmonceux Castle, East Sussex, 1999. 2,4.