Measuring Cycle Time - and why it's important

In this article I explore what cycle time is and why it's a useful measure to point to opportunities to improve.

Measuring Cycle Time - and why it's important

Today, I’m going to make the case for the measure of "cycle time" as being one of the most powerful measures to study in your workplace.
 
Cycle time is simply the measure of time (usually days) between two events, or stages, or activities.
 
I tend to focus on the first event and the last event, such as starting work on something and then that work being done. But you could measure the elapsed time (cycle time) from coming up with an idea to it being implemented, or from customer order to cash in the bank, or any of the steps in between.
 
Within a cycle time, could also be smaller cycle times to measures. At the heart of it you're measuring how long things take to move from one place to the other.

For example, let’s say your company starts work on a new product feature. The work involved could cross (and likely will), many teams. You could measure the cycle time of the work from coming up with the idea to it being implemented, or even the cycle time betweem departments as work is passed around, or even between distinct phases of the delivery (like design, build, deploy, maintain).

 
It’s a measure I always use. I see cycle time as giving my insights into the health of the process.

But what is a good cycle time?

At first, there is no good or bad cycle time - it just is. I think a lot of people have a time in their mind and when they measure the actual cycle time of a process, they are disappointed.

But there is not hard and fast rule. It will vary per company, per process and of course, because there are different people, goals, missions and constraints in all work.

Therefore, I take a measure and accept it as it is.

Then, the goal if needed, is to look at ways to improve that cycle time never setting a target cycle time to move towards. A target will artificially create a ceiling.

Let's say we measure how long it takes to design a new software feature, build it, test it and deploy it. When we measure this we may get an average cycle time of 15 days.

Whether 15 days is good or bad, is relevant to your business and your goals - but the chances are it could be improved - but try not to use targets.

You may set a target of 10 days but that could create a ceiling that means people stop improving the process when it gets to 10 days. It will also likely fluctuate depending on the work itself. One week it may be 10 days, then 12, then 9.

The ultimate first goal is to look for ways to make the cycle time better - rather than aim for a number which may create a ceiling or, in some cases, force people to cheat to meet the number.

A large variation in cycle time suggests there is a problem to dig into. It could be that work is not broken down in a consistent way, or there are huge varieties in the work that mean you need to work out how to cater for this variety. Ideally you're after a stable number with a little fluctuation. This would suggest that your system is stable - and variety of work is catered for within your process.

Over time the cycle time will get shorter if you're making improvements, but there will come a time when it's no longer worth investing time, money, energy and attention in improvements in this process, versus another which could do with some love.

Work may just take as long as it takes - and therefore there is little value in more energy trying to make the cycle time number shorter.

There is no right or wrong - it is what it is - but it likely could be improved.

Use it for anything - as long as you care about what it shows

Cycle time can be used anywhere and for anything.
 
I applied the concept of cycle time when recruiting. I measured the time it took from first contact by the candidate to an offer or rejection. We spotted plenty of areas to remove delays, waste, and gaps. I wrote about it in my book Join Our Company.
 
And that’s a key point - it gives you a clue where to look. Cycle time alone will not solve your problems, but it can highlight where your delays, gaps and slowdowns are. To improve something though, you need to care.
 
Cycle time is not something to compare to other teams or other work either. Everyone’s work (and processes, goals and people) is different, so it pays to use it simply as a form of study.
 
It doesn’t matter what the cycle time is when you first measure. You may apply subjective thinking about wanting it to be a better number other than it is - but it is what it is.
 
The goal is to improve the cycle time. What can you do to make it shorter, or flow smoother?
 
There comes a point of diminishing returns though.

For example, as I write about in Join Our Company, we measured the cycle time from first contact with a potential candidate (application, or direct contact), to when we accepted or rejected that candidate. The initial outcome was a cycle time of over a 30 days (a month).

Through lots of hard work, we got the cycle time down to an average of two weeks. No matter what we did it was hard to get the average down to less than this.

For example, there is nothing we can do when the ball is in the candidate’s court (i.e. awaiting confirmation of an interview, accepting an offer). There are only so far certain processes can be pushed and improved. However, without measuring cycle time to start with, we would have no solid insights or evidence as to whether our improvements were actually improving anything.
 
Cycle time is one of my 5 key measures of business agility:

1. Business Results - the ultimate measure of business agility (typically a financial goal or target)
2. Cycle Time - how long things take to move through the processes
3. Throughput - how much work is done
4. Failure Demand - how much work are we doing because we didn’t get it right, or do it at all
5. Work in Process - how much work are we taking on right now
 
Cycle time can be applied to anything with the goal of shortening the duration from beginning to end.
 
Sadly, I even apply this in my own life. I measure how long it takes to make a video from starting the shoot to uploading to YouTube. I measure how long it takes to create these newsletters. I measure how long it takes to write a book.
 
All with the aim of looking for opportunities to optimise the process.
 
So, if you’re looking for ways to make your business better - staple yourself to work (metaphorically not physically) and measure the journey that work goes on. Map it out, add your timings, make it visible, then gather talented people to make it better.
 
Cycle time a powerful measure for sure but be careful that you don’t try to rush good work. It can be tempting to optimise too far - but work sometimes takes as long as it takes.