I’ve written about doing things in Shorter Cycles / Smaller Batches in the technology realm. This is a quick observation about how this has materialized in the transportation industry by looking at trains versus trucks.
My family went on a two-week camping trip, returning the end of last week. We drove over 3,200 miles – from Colorado through Utah, Nevada, California, Oregon, and then back again. On the big interstates we were often close to train tracks.
I didn’t keep count, but I saw on the order of 100 times the amount of semis hauling trailers than trains moving cargo. I see this as evidence that transportation operates more in smaller batches (semis with trailers) than larger batches (trains).
I just did 15 minutes of quick research and learned that most sites say that hauling freight via train for long distances is more energy efficient, and includes lower fuel costs. However, the operational inefficiencies of working in large batches means shipments arrive later and inventory sits longer. Imagine a long train unloading, and moving containers to staging areas, to be picked up later by a truck and taken to it’s final destination versus a semi driving from the warehouse directly to the final destination.
The only type of freight where trains rule is coal. And with coal, a long train loads all cars up at one location and takes all of it’s payload to one or very few destinations. So it is in essence a very large small batch operation.
Not surprisingly, working in Shorter Cycles and Smaller Batches is clearly preferred for transportation. How can your work be accomplished in smaller batches to provide results more quickly?
I wound up conducting an experiment on smaller batches with my step-son and his friend this weekend. We all experienced first-hand its value in getting a job done more quickly with higher quality.
The two of them were “hanging out” at our house on Saturday, as “playing” is not very cool for 10-year olds. I always try to encourage some outside time, even if it is cold, snowy, and windy. Today I decided that they could help me stack wood. We have a wood stack at the front of the house, and every once in a while I take some of those split logs and move them closer to the door of the house so when it’s late at night, I don’t have to trek so far to get more wood.
They started off with my step-son taking armfuls of logs and putting them on the deck (about halfway to where they ultimately needed to go). His friend then picked up those logs and moved them to the final spot. This is classic assembly line large batch thinking – where you do the job in steps. When they thought that was taking too long, they moved to three steps. First they took the logs from the big stack out front and threw them as far as they could into a snow bank, then they moved them to the deck, and then to the final stack near the door.
I stopped them after a little while and suggested they try taking armloads from the stack out front and moving that armload all the way to the stack by the door. Essentially working in smaller batches, and completing the whole job. After they did that for a while, we looked at the process. With smaller batches:
There was less picking up and putting down the logs, saving time
The wood didn’t get covered in snow in the process, and would thus be better for burning
The wood deck took less wear because all they did was walk on it and not stack wood on it
Not only was smaller batches less time intensive, it also resulted in higher quality / less defects. Even in stacking wood.
How do you shorten the cycle and reduce the batch size in large scale systems?
I was on a call with Gartner Research the other day, briefing them on the ILANTUS approach to delivering Identity and Access Management (IAM) solutions to our customers. During the briefing, we discussed our vision and ability to deliver value using shorter cycles / smaller batches. They explained that they are hearing the same thing from their customers – going away are the days of spending more money (multiples more) on product implementation consulting than you do on the product itself. Customers are demanding that they realize value more quickly and with less money. They want to see not only higher ROI (return on investment), but also quicker time to value.
They then asked “How are you doing this?” I explained that we are implementing shorter / smaller in short cycles, and had not yet figured it all out. So far, we have done the following:
1. ILANTUS developed IP has been created to lend itself to rapid deployment and quick delivery. So when we are implementing our products, this is relatively simple to do.
2. For implementations that include both ILANTUS products and large scale systems, we implement ILANTUS products first, or at least in a parallel track, so that value is delivered quickly.
3. For the larger legacy type packages that traditionally take a long time, we have shrunk the requirements-design-develop-test-production cycle by working in phases. For example, if there are 10 applications to integrate into the system, we break it up and go thru the entire cycle with 3 applications, then 3 more, then the remaining 4.
Where we are now is looking at how to increase the feedback loop in each of the steps in the requirements-design-develop-test-production cycle. I’ll discuss more about how we are doing that in another post.
Ultimately, what I believe we’ll need to do is to break out of the R-D-D-T-P cycle altogether.
It is my belief that everyone who serves customers will absolutely have to deliver value in shorter cycles / smaller batches or they will not be in business in the future. I’m not sure how long customers of today will be willing to wait for what they pay for, but there is no doubt the “delivery wait-time” is shrinking. Look at your own buying habits – food prepared quickly, next-day shipping, instant global feedback through social media…
Delivering value in shorter cycles / smaller batches is what’s required to deliver supreme customer service. The reason is you want to get customer feedback on what you are providing as quickly as possible. You can then make modifications to better please your customer. Only then can you deliver exactly what your customer wants, and in a shorter time period.
For some product and service providers, this is easy. If you are a restaurant, you get customer feedback immediately, before the customer even pays for the meal. In other circumstances, like what we face at ILANTUS Technologies, of implementing large security software packages that take many months to complete, it is not as easy to do. This post is the beginning of a series on how to implement smaller batches and shorter cycles in any system that does not immediately lend itself to getting feedback quickly from the customer, and specifically in the traditional large-scale systems integrator world (of which ILANTUS belongs).
For people familiar with trends in the technology world, what I’m saying is nothing new – it is the Agile Methodology, originated in software development. Part of the trick is that I don’t know exactly how to do such large scale work in shorter cycles. But I do know enough to know it is possible. And I know more now than when I started thinking about this earlier this year. One of the reasons for this blog series is to publicly present my ideas, before they are fully formed, and get feedback so I can continue to improve them – in other words, I’m going to practice what I preach. In fact, I’ve waited too long already.
As an example, in the traditional Systems Integrator process, it requires months (maybe years) of Requirements Gathering, Design, Development, and Test before we get something tangible to the customer that they can provide feedback on. How do we transform that process to get real feedback from our customer in a few weeks, and get continual feedback on tangible results every few weeks?
For those familiar with the SI model, you might say “but we give them a Requirements Document, and ask for their feedback.” To which I say, just how tangible are words on paper (and maybe some mock-up pictures)? It’s just not good enough anymore.
Even big companies are starting to realize this. ILANTUS is an IBM partner – now there’s a company that operates at large scale and is not known for agility (although they have made big advances in agility in recent years). This concept came up in a conversation with some folks in their Security Product Management group recently. They said even they are being asked by their customers to provide business value (real results) much more quickly than ever before.
Again, I believe that everyone who serves customers will absolutely have to deliver value in shorter cycles / smaller batches or they will not be in business for long. I look forward to exploring how this can be done in large scale systems.
I’ve written about doing things in Shorter Cycles / Smaller Batches in the technology realm. This is a quick observation about how this has materialized in the transportation industry by looking at trains versus trucks.