What would a lean transformation mean for the IT Department? What benefits would it create for the company?

Dear Gemba Coach,

We’ve asked our IT department to be involved in kaizen events several times, but it is always very slow to deliver what is asked.  What would a lean transformation mean for this department? What benefits would it create for the company?

To be honest, my experience in lean IT is limited and there are many folks who’d have better answers – for instance, if you’re interested, the Lean Global Network organizes a Lean IT Summit in Paris at the end of November. Nonetheless, what you say sounds awfully familiar. In years of studying lean turnarounds, I’ve seen lean efforts run afoul of IT departments in two main ways. First, in leaning value-production processes line managers and their teams often need to change the supporting IT processes, and this turns out the be quite a challenge. Secondly, and with greater overall impact, many products now have a software component either in the product itself or its integration, and improving the product’s quality has software impacts, which involves the IT department software design’s side.

The three main ways I’ve seen lean efforts require IT support are, obviously, the MRP, and especially the handling of the product options in the system; secondly, changes to the procurement system; and thirdly the quality reporting system. Moving from work orders generated by the system to pull has a huge IT impact, not surprisingly. The focus shifts from running the plant with the MRP (by telling each production cell what to produce when in real time) to using the MRP to create a level plan at the pacemaker process and then pulling production with kanban cards.

It’s surprising, but I have to say I’ve never seen a case of IT involvement in that change. Line managers grumble and complain, but in the end, find it easier to just do it, and somehow cope with the system as it is rather than go through the hassle of explaining the changes to the IT chaps and then waiting eighteen months for a new system that probably won’t do what was needed. Bear in mind that production and logistics staff are often learning as they go as well so their requirements for IT keep changing as their understanding improves and become increasingly puzzling. It’s hard to blame the IT managers for shrugging their shoulders and letting the dust settle before they try to seriously get their minds around the issue.

Yes, in some cases this creates unnecessary work and duplication of effort – particularly when the product has many variants and many steps, in which case the product/process matrix can be a real headache – I recently saw a German team spread huge sheets on the floor just to make sense of it. What tends to happen is that logistics people first start calculating by hand, then on a spreadsheet, then automate the spreadsheet – and at some point, this gets fed back into the MRP system, but more often not and somehow things get along fine. The unexpected benefit of not being to solve leveling problems through the system is that it forces operational teams to take control of their processes back from the systems and ask themselves deeper questions no one has asked in a long time. Once it’s set in the software, the process is usually both inflexible and hard to change, so doing it all by hand is not necessarily a bad thing.

This is trickier in the case of procurement where you have to work with the MRP – there is simply no other way. But here again, I’ve seen procurement departments extract high runners by hand on excel sheets and start sending hand-drawn leveled plans to their main suppliers for the high running parts independently of the system. As a supplier what you then get is an overall idea of what the customer company’s production plan is (which, for many reasons it won’t achieve perfectly) and then the usual variation-ridden call off from the system. Over time, though, as production learns to level and stick to the plan, the variation is reduced, the call-offs are closer to the plan, and somehow the issue disappears. Yes, the lean ideal is to switch to a lead-time based MRP system but I have never personally seen one outside of Toyota.

Software’s Hard Problems

Other than scheduling and supply chain, the other IT topic critical to any lean effort is the quality feedback system: how field quality, warranty results, customer incidents, final inspection ppm, in-process ppm, supplier ppm, etc. are recorded and displayed. In many cases, the system simply isn’t there. In others, it expresses quality issues in cost terms (the dreaded “cost of non-quality”) and reports it as such. Building a robust quality reporting system is a key part of any lean effort and can’t be done without IT.

My own preferred solution is a web-based system that can be consulted easily by anyone. Such systems can usually be developed out of the IT mainstream, and so again, lean transformation doesn’t collide directly with IT. At the end of the day, lean transformation in the IT department would probably help tremendously (well, maybe), but I’ve not – so far – have had occasion to find out. On the other hand, IT is rarely a direct step in producing value so, perhaps, we should not worry too much about it.

Software, on the other hand is often a key part of many products as they increasingly carry electronics-dependent functionalities. Software delivers value. Unfortunately, software is also the source of much waste. The three main issues I’ve encountered with software delivery have been:

1. Product robustness – the moment electronics are involved, many of the products failure modes are linked to software glitches. Whilst it doesn’t matter that much for word processing or web pages, having to turn off the device and switch it on again to work around a bug can be seriously annoying and occasionally dangerous. Toyota’s main PR vulnerability is now linked to the software in its cars, from the braking system to unintended acceleration and so on.
2. Product performance – many product functionalities now completely rely on software, and software is both rigid in terms of coded application and fast moving in terms of innovations, which creates massive headaches for the product development engineers. On the one hand, they need to deal with the legacy, and on the other, they need to keep up with innovative code. As a result, software projects can be complex and confusing in terms of both goals and execution.
3. Release delays – software project delays are thought to be inevitable in software applications, but can badly impact product SOP and launch when the software drives a specific feature, particularly in complex products.

There are two lean techniques I’ve seen successfully applied to software development. The first is automated testing and the second is kanban. Automated testing is about using separate software to  continually run tests on the software as it is being developed rather than batch all testing at the end of development. This is the equivalent of an andon system for software development. A separate program runs the program being tested, feeding inputs and checking outputs against expected results. Automated testing is hard to introduce in the development department: developers have to be trained, management has to insist they take the time to do it, and legacy code is always an intractable issue, but the benefits are considerable both in terms of product robustness, and time and money savings. A further benefit is that engineers improve their coding skills as they  by writing  test programs before  developing the product code.  This  can be an entry point for setting coding standards – although I have yet to see a company succeeding on that front.

The second lean practice for IT is kanban – yes, kanban. In a software factory, kanban is actually quite simple and brutal. You set up a board with five columns:

Then you create on a number of lines corresponding to how many projects you believe your team can develop in parallel. As Karen Martin points out in her insightful book The Outstanding Organization “switchtasking” from one task to the next takes an average of 25% to 50% longer. Worse, without the discipline of finishing ongoing projects before starting new ones, it’s easy to completely boggle the process at one stage and work very hard without ever delivering.

Should you be interested, much about kanban in IT settings can be learned in David Anderson’s seminal book Kanban. From personal experience, I insist on adding a further column after the customer’s sign-off of the project: are we sure the software is doing what the customer wanted it to do. At this stage, the customer has agreed that the software is up to specs – no worries. But we’ve discovered on the gemba that this doesn’t mean the customer is happy with it. Particularly when you’re trying to integrate mechanical and electronic components, lots of tricky things happen, and very often the engineers are unclear in their demands on the development team. As long as the software team sticks to “delivering the specs” works gets done, but everybody is frustrated: product engineers are never happy, coders feel underappreciated. The key is to realize how different the coding and designing worlds are and focus special efforts on understanding each other. The “validated learning” (not to use the Toyota-ese term “hansei”) is about making a genuine effort to find out if the software actually satisfies the engineer, rather than simply make do.

Could your IT department benefit from lean thinking? Certainly. I remember coming across an HBR article last year (Why your IT project may be riskier than you think) listing companies that went into bankruptcy because of failed IT projects the paper described as “black swans”:  world changing events that are rare and unpredictable but, with hindsight, not so unlikely. From any one’s experience of IT, lean should help – but I’m not sure that’s the priority compared to leaning the main value flow. After all, IT remains a support activity, and one of the tricks of lean is to go all in “must do, can’t fail” in Karen Martin’s terms, and get right customer value activities before worrying about the rest. Rather than go for lean transformation, I’d focus on key practices such as:1) working harder at understanding what customers need rather than what they ask for, 2) systematizing automated testing and 3) using kanban to level and manage development projects. It might sound like a humble scope but I truly believe that core practices can leverage large benefits if management sees the scope for improvement opened up by kaizen.