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.
2 thoughts on “Shorter Cycles / Smaller Batches In Large Scale Systems”
How are you going to do that in my job?
I guess it takes on a whole new twist when you look at it in the healthcare field and you are dealing with people’s lives. I’m no expert there, but maybe one example of this is trying out one med at a time, and measuring the effects, rather than putting someone on three or four straight out. Again, if there’s a life threatening situation and you know the three meds and the procedures required, you have to do all at once. The Shorter Cycles process would relate more to situations where there is less certainty in what the treatment should be. Since you are the expert in this field – what do you think?