We confuse ‘how far’ and ‘how long’ when we ask the distance or time between cities. We make the same mistake when estimating software projects. We ask ‘how long’ instead of ‘how far’. These are two very different, but related questions.
Through the many software development best-practice appraisals Demix conducted, we have ascertained that most low-maturity software development organisations estimate ‘how long’ software development tasks will take, without any meaningful estimation or understanding of ‘how far’ they need to travel. This causes major problems with underestimation, which in turn results in budget and schedule overruns. Underestimation is further exacerbated when the business dictates ‘how long’ it should take. Yes, it is perfectly acceptable and logical for business to place an expectation on how long it should take. The main problem is that most low-maturity software organisations are unable to know if they can fulfil the expectations of business.
There is also a relationship between duration, effort and resource availability. However, let us first focus on the duration estimate. Why is duration in itself not a good sizing measure? If I say, I travelled for one hour, how far did I travel? Maybe 2km on foot, maybe 60km or even 120km by car, or maybe 500km to 800km by passenger airliner.
It is actually better practice to derive duration (how long) if I know how far (distance) I need to travel, and incorporate factors that influence speed, such as method of travel like on foot (2km/h), by motorcar (60km/h) or by passenger airliner (500km/h). We can then determine how long I am going to travel. Along the way, it is good to understand and measure both distance (how far) and time (how long), so I can determine progress. Progress is important since it gives me data to understand my vehicle performance. It provides data to adjust my expected duration (how long still) after a certain distance (how far by now) was travelled. If I know my vehicle’s performance and capability (speed), and I know how far, I can reasonably tell business if we are able and capable to deliver within their expected timeframe (how long).
This analogy is to a large extent applicable to software development. The challenge is that the distance measure in software development is a difficult one, since it is influenced by many factors. It is difficult to do, but mature organisations succeed in getting it right. It is never perfect, but provides meaningful estimation capability.
Some distance (software size) measures are function point analysis, number of use cases, lines of code and number of test cases. Each of these software distance measures have its pros and cons, and may only be useful or applicable at specific stages of the software development life cycle, but they provide a valuable distance measure. They are not as simple and straightforward as the kilometre distance measure, but these types of size measures are the key to truly understand vehicle delivery performance capability (speed) and to estimate software development projects accurately.
Distance measures (software size measures) or ‘how far’ measures are key to accurate progress measurement, to know ‘how far’ still, as well as accurate re-estimation of ‘how long’ still, something akin to a GPS that can provide you with an estimated time of arrival.. It is fundamental to developing mature, better and capable software processes, which are the better delivery vehicles with better performance capability. It provides a method for initially estimating and managing project performance. It is important for developing organisational performance measures associated with standardised processes. It is key at higher maturity to characterise process and sub- process performance quantitatively with a centre point and dispersion measure that enable predictive measurements. And finally it is key at high maturity levels to enable the organisation to make measurable optimisations in development processes that support business goals. It provides measures for understanding cost (for example $/ function point), defect density (for example defects / function point), productivity (for example function point/staff month) and speed (for example function point/elapse days). It helps us to know which vehicle (people, process and technology) provides better performance. Furthermore, it provides baselines for measuring improvement and comparing projects and processes.
You need to know ‘how far’ you need to travel and what your method of travel is going to be to accurately know ‘how long’ it will take.
For more assistance on understating your organisation’s project estimation capability, your project management offices (PMO) capability, or software development capability, please visit us at www.demix.org