Lean and waste in IT

  general

Whatever your position or level of seniority on a team, you should be empowered to find and reduce waste.

Waste can be as innocuous as an unneeded meeting or extra names CC’d on an e-mail, requiring them to read, process and file the e-mail. Or, waste can be as big as software purchased and not used, costly rework, over-design or overly-complex processes that encourage workarounds and don’t align with strategy.

I was fortunate to work with - and be coached by - the fantastic Nick and Naomi, who ran the “Lean team” in a major metro public hospital. They had their hands full, going to the source of problems (more on this another day) and working with departments to apply Lean principles to clinical & operational processes. I saw firsthand the considerable positive impact on outcomes for patients and staff their work produced.

Lean has obvious (and not-so-obvious) advantages in IT too, and works hand-in-hand with other systems I’ve used such as Agile (development), PRINCE2 (projects) and ITIL (service management). I worked as part of, eventually managing, a small IT team, and we incorporated Lean principles to better deliver value. One of the most impactful things we were able to do was reducing waste.

Identifying and cutting back waste is something that resonated personally with me from my years of playing & watching basketball. There’s a concept in basketball that preventing a basket being scored on defense, has the same value as scoring a basket. I see a similarity in that preventing wasted time & resources is equivalent to getting extra time & resources.

An eye-opener on my Lean journey was reading the book “Run Grow Transform” (see https://www.leanitstrategies.com/books). This book is a comprehensive and inspiring look at Lean and IT and I highly recommend it.

Nick and Naomi taught that waste can be present in any process, and people on the front line are the single best source of how to fix wasteful practices. They stressed the value of lo-fi solutions (post-it notes, whiteboards) until a fancier system is needed. They advocated gathering data, and digging deeper into the “whys” of a process.

One thing they didn’t explicitly mention, but I’ve seen played out time and again, is the positive momentum you and the team get from removing obvious wastes to better focus on tricker problems.

A couple of great recent web pages that gather lists of wastes are:

In no particular order, here’s some of the notable wastes from the lists above. Imagine what you could do with the time & resources your team would have, if they could reduce dealing with:

  • Inspection and correction activities required to catch and correct errors that should be prevented by building quality into the process
  • Software that’s purchased but never deployed
  • Delays from excessive review and approval steps
  • Knowledge loss: The cost of re-acquiring information that the team once knew.
  • Ineffective or repetitive meetings that add little value and don’t resolve lingering issues
  • Searching for information or materials that are difficult to find
  • Delays in receiving, transmitting, and storing information
  • Excessive automated exception notifications and alerts that cause distraction, but do not drive effective action or decision making
  • Frequent switching between incomplete jobs, also known as multi-tasking, thrashing, task switching
  • Mismanaging the backlog: The cost of duplicating work, expediting lower value user features, or delaying necessary bug fixes.
  • Producing and distributing reports that contain information which is not used
  • Unnecessary, unclear, incorrect, obsolete, or unused documentation
  • Waiting for a specialist who is currently working on another task or project (shared resource)
  • Rework: The cost of altering delivered work that should have been done correctly but was not.