Working for the IT function of Toyota Motor Europe puts us in a unique position these days. We work for the company that invented the Toyota Production System, leading the way to many of the concepts that have proven successful in our own and in other industries alike. We have experienced and continue to experience these concepts and their practical implementation first-hand from those who have developed the company towards such incredible success. But these concepts have also been further developed outside Toyota, first under the name ‘lean’, and now in the IT field in many different ways (Lean IT, Agile, Kanban, etc.).
So we can be proud about our approach and do nothing else or different within IT… (And our IT will gradually fall behind as other companies implement those principles more and more effectively). Or, we can study and understand what has happened outside Toyota in order to improve our IT further… and ideally, lead an implementation within Toyota that would be even more successful and would feed back into the community around and well outside of Toyota. Rather than being complacent, this is the challenging road we have chosen to follow. But would you have expected anything less from Toyota?
People may be surprised to know we still have quite a lot of projects following a traditional waterfall approach. This is because they are happening in environments where this approach is perfectly suitable, even today. One example is the roll out of a global standardized production system with a limited number of local adaptations. In some cases, this waterfall approach has been kaizen-ed to more simultaneous engineering in order to reduce the lead time to delivery, as we did recently for a system handling a workflow on improvement requests involving R&D and Purchasing.
In other contexts, we also apply a form of agile methodology, as in applications for Marketing, After Sales, or Supply Chain. The guiding principle here is not to create a unique and standardized methodology and make it mandatory for all without them understanding the reasons why we have done this, but rather to make sure we:
- Work only on projects that actually add value to the customer, in other words: “do the right things.” Of course, in order to choose the right projects, we use the tools our company has developed: visualizing with standardized A3 forms, applying nemawashi to obtain consensus, etc.
- Use the most appropriate method to run a project in order to respect cost/quality/due date, and deliver the expected benefits to the customers. “Do things right.”
- Pass a number of clear gateways before launching a project. For example, applying a basic agile methodology on a given area without a budgetary envelope granted at the start may result in very satisfied customers in one given area of the business, but also a situation wherein the company is not spending money in an area that would yield much higher benefits.
Whatever methodology we use to deliver the project, we always visualize the situation for each project and operation. What is the point of an agile project team that delivers the latest request of a customer, but doesn’t realize where their delivery is situated in the bigger picture of a function or within the whole company?
So, what does this all mean for you if you are responsible for IT or working in IT at a different company?
Well, you should be aware of the tremendous amount of activity going on in this community, learn from the experiences and pitfalls of others (we are having ours every day!), and read plenty of books on the subject. In summary, educate yourself on the subject, since so many stories of dramatic or step-by-step improvements do exist out there. Then, soon after, experiment yourself. This is the basis of TPS. Make sure you also get enthusiastic people on board, and take the support of experienced external coaches if you need this to get started. Create a culture within your company where the principles of lean become embedded in everything you do.
This is not a process that happens top-down only. If you are senior management in IT, you must nurture the talent of those people who want this to happen in your organization and who show the energy to bring it to fruition. They can be in any level in your organization, but typically they are at the ‘gemba’, they do the day-to-day of project operations and experience problems first-hand. Even if they don’t work by the book, you would be wise to support their activities. They may come up with better solutions than the ones that would occur to you or are available now. The teamwork and learning that result from working together with these individuals on such projects or operational improvements is worth so much more than the blind application of any technique learned from a book.
I wish you all a lot of perseverance and success to apply Lean in IT, a discipline I am continuing to learn and develop in myself and my team every day. Tell us, what are you learning about the field and how it’s changing?
