28.04.21

How Are Lead Times Calculated And Why Do They Matter?

What is a lead time?

“A lead time is the latency between the initiation and completion of a process.”

In real terms, this is the amount of time between placing an order and having it delivered. For example, an Amazon Prime package with next day delivery would have a lead time of one day; a second class stamp, however, has a lead time of around three to five days.

What does a lead time include?

Many things are factored into a lead time, and these greatly depend on the type of service or product that is being delivered. Within software, the following factors should always be considered when providing an accurate lead time.

Research of domain specific needs/requirements.
This involves ensuring that the developers and consultants completely understand the context that a piece of software will be used in. If this is not factored in, delays and many changes will inevitably arise as development is undertaken.

Time to develop a system in days.
A development team will understand how long most features within a system will take to develop. This however is not a concrete figure as external development obstacles may present themselves further down the line and a lead time estimate will have to take this in to account.

Number of developers allocated to the project.
The number of developers will of course affect how long something takes to develop. However, the ratio between developers and lead time is not linear, for example, two developers won’t necessarily complete 6 days’ worth of work in 3 day, so bearing this in mind helps to calculate if a lead time is realistic.

Non-working hours.
Bank holidays, weekends and staff leave although seemingly obvious can easily be overlooked and need to be accounted for. A month of development can easily be turned into two months when accounting for now-working hours, potentially leaving a project unexpectedly overdue if not taken care of.

Fitting around existing work schedules.
However much we like to focus our energy on a single project at a time, this is very rarely achievable. Consideration for the timescales of other ongoing projects, as well as potentially new projects, is vital to ensure that development resources are managed correctly.

Testing requirements.
Testing is the area of a project that is often misunderstood. The correct use of testing time within a project’s development lifecycle should not solely be to minimise the issues with the current software iteration. Testing should also encompass: the fortifying of a system from malicious attacks; code analysis; performance optimisation; and a whole host of other vital tasks to minimise future issues.

Contingency.
Regardless of how much time, effort and knowledge is put into constructing a lead time, stuff happens. This cannot be avoided, therefore accounting for these unforeseen issues in a lead times is always a good idea. You should not be put off by a provider adding contingency into their lead time, it shows a level of transparency that will hopefully continue through the project.

What makes a lead time achievable?

While a lead time can never be a concrete figure, considering all of the above will allow you to rest easy knowing that you aren’t flying by the seat of your pants. A final point to consider is integrity: a software provider should be as open as possible when discussing how they formulate their lead time and explain how they will deliver your project. After all, it is your business.