Core risk in software projects: incorrectly determined time and work effort

One of the main risks in software projects is incorrect estimates of time and effort. No wonder Tom DeMarco and Timothy Lister list this as the first point in their 5 core risks in the book "Bear Tango - Managing Risk on Software Projects". But why are so many projects wrongly estimated?

Several reasons contribute to this:

1. When identifying the necessary activities in the work breakdown structure, it is more likely that work steps are forgotten that later turn out to be necessary than that work is taken into account that later turns out to be unnecessary.
2. Initial estimates are made at a very early stage with little well-founded knowledge and requirements of low quality and are not updated afterwards despite new findings.
3. Estimates are only made by individuals, are made "from the gut" and are not questioned in a sufficiently well-founded manner.
4. Especially in projects with a lot of management attention, the high expectations of the stakeholders can influence the estimation procedure towards wishful thinking. This is especially the case if the estimation process is not well conducted and documented, making it difficult to understand.
5. The selection of the finally chosen estimate from the confidence interval of possible outcomes is done unsystematically or with a tendency towards optimism.
6. There is no established feedback loop with sufficiently detailed resolution to calibrate and thus improve the estimation procedure for the future on the basis of real empirical values in the sense of continuous improvement management.

In view of the many influencing factors, the holistic solution is not trivial. Even with sophisticated estimation methods such as COCOMO II, the problem remains, for example, that the necessary scope is simply underestimated before the algorithm is set in motion. Thus, the estimation error can simply shift to another process step. In addition, the complexity of the procedure also increases the need for training.

In view of the challenge, is it worth dealing with the topic at all? Yes, absolutely. Using empirical methods, DeMarco and Lister were able to isolate this risk to such an extent that in any given average project this risk alone is likely to result in a project delay of over 30% compared to the original planning. The data show an imbalance towards smaller projects. For larger projects, the deviations are generally smaller. This is probably due to the fact that a more systematic estimation approach is chosen in view of the magnitude and that longer projects are more likely to offer the opportunity for a readjustment of the planning. However, in absolute terms, a deviation of less percent in a much larger volume is no less serious than a large deviation in many small projects.

Application of a scientific approach

Many detailed improvements for better estimates are obvious and well known. Nevertheless, many teams find it difficult to implement them. However, since the quality of the estimation process can be quantified very well, a scientific approach lends itself:

1. Work with confidence intervals and refine existing estimates based on new findings.
2. Determine the quality of the estimates and integrate corresponding key performance indicators (KPI) into the processes.
3. Train and calibrate your team to make them better estimators. Establish feedback loops to do this.

Finally a tool for more precise estimates

With the Quantum::Estimation app, the estimation process can now be supported in a more informed way directly in Jira. By using advanced methods such as PERT and interval estimation, uncertainties can be localised and dealt with, and confidence in the estimation can be increased step by step.

The app is suitable for agile/lean teams or for distributed teams that work together remotely. Who should or already did what and when can be individually controlled and monitored.

Everything solved?

According to the well-known motto"A fool with a tool is still a fool."It should be noted that buying an app for Jira is a single piece of the puzzle, albeit a very helpful one. However, full success can only be achieved if the implementation in the process is holistic and sustainable. Accompanying measures such as training and the refinement of quality management in the area of estimates with expedient feedback loops, which do not only allow poorly localisable blanket observations, are correspondingly important.

--

linkyard and the app manufacturer Data Rocks have a well-established, trusting and intensive collaboration in a large number of joint projects. Accordingly, we are able to tackle even complex challenges together.

‍