Lessons from Wipro’s Tryst with Lean (TPS), Part-1 of 3

The following section is devoted to the lessons that can be derived from the success of Lean principles at Wipro and applied in any of Knowledge industry–be it telecom, insurance or legal services etc.  It’s an extension of my previous post: Wipro’s Tryst with Lean (Toyota Production System)

1.  Continually rooting out waste should be an integral part of every Knowledge Worker’s job.

There are “Seven Wastes (MUDAs)” that everyone in any set of operations should strive to eliminate–over-production, unnecessary transportation, inventory, and worker motion, defects, over-processing, and waiting.  These 7-wastes are quite well known in the world of manufacturing.   But, typical knowledge work sites are also loaded with these wastes.  Indeed, knowledge work includes many routine activities that don’t involve judgment or expertise and can eat up huge amounts of time, such as printing documents, requesting information needed to make a decision, and setting up meetings, to name just a few.

The key is to get everyone in the organization to systematically make waste visible and do something about it.

Here’s how to enlist people in your cause:

  • Teach everyone to ask the 5-Why’s.  5-Why’s is a process of continually asking questions until you get to the root cause of every activity performed.  Why am I attending this meeting?  Why am I filling out this report?  Why am I standing at the printer?
  • Encourage everyone to look for small forms of waste, not just big ones.  Most successful companies have already eliminated large, obvious forms of waste, but the floors of knowledge operations are typically littered with nickels that no one has bothered to pick up.  Think about your own workplace.  How many e-mails clutter your in-box because someone cc’d you unnecessarily?  How long did you have to wait to start a regularly scheduled meeting because attendees slowly trickled in? How many reports are created that nobody reads?  Why have your people to wait standing around the printing machine?  The Value-stream mapping is great technique as it can highlight several more forms of waste.  You must track each step it takes and ask, “Why did we do that?”  This allows you to create a prioritized list of elements that can be eliminated.
  • Periodically review the structure and content of every job.  Many knowledge jobs are unstructured and broad.  They tend to expand gradually as one activity after another is added.  People can end up with too much on their plates and too much time devoted to low-value tasks.  Managers should regularly assess their employees’ tasks, including how much time is spent on each.  You may well found that task creep, inadequate prioritization of assignments, and a lack of understanding of what made up a full workload had created a situation in which your people typically had twice as much work as they could realistically perform.  This may be causing significant bottlenecks, excessive switching between tasks, missed deadlines, and employee burnout.  You may have to make hard choices.  However, employees’ productivity and satisfaction would certainly increase.

2.  Strive to make tacit knowledge ‘explicit’.

It is about the practice of writing down exactly how to perform a task—clearly defining the substance, order, timing, and desired result.  This practice has delivered significant value to manufacturers.  It allows you to compare the actual and expected outputs, and take the corrective actions subsequently.

Don’t think that this approach may not be relevant to your knowledge operations.  Many of the processes in knowledge operations are worked out inside an employee’s head; they may be invisible to others and hard to articulate into concrete, replicable steps.  For an example, an investment banker, may not be able to easily explain how he persuaded someone to accept a deal.

Yes, it is correct that the work in a knowledge operation may change rapidly, and on any given day people may do a mix of tasks—some that require judgment or intuition, and some that could be reduced to a protocol because the problem and the best ways to address it, are well understood.  Precisely because people typically perform both kinds of work, don’t assume that many tasks that could be standardized, can’t be.

Despite the challenges, a surprisingly large amount of knowledge work can be specified.  And once it has been, it can be continually improved.   The key is to challenge the assumption that all knowledge is inherently tacit.

  • Look for repeatable parts of the process and codify them.  Almost all areas of knowledge work have more commonality than meets the naked eye.  At Wipro, teams found it difficult to specify the overall code-writing process, because it often involved one-time novel solutions.  But when they reframed the question to ask “What do we do repeatedly?”, they realized that many aspects of the process, including peer review, daily-builds (integrating all the pieces of code written that day into the program), testing, and customer reviews all occurred frequently within a project and across projects and could be standardized.
  • Don’t try to specify everything initially, if ever.  Some tasks occur so rarely that the investment needed to specify them is not worthwhile.  And sometimes a problem is so poorly understood that an expert must advise about how best to address it.  However, even in these instances parts of the process can be specified.
  • Use data to get buy-in.  A major benefit of specifying repeatable processes is that knowledge workers are then freed up to focus on the parts of the job where they can create the most value.  But many highly trained professionals don’t believe that their work can be made explicit.  For example, although specifying work can improve outcomes in medicine, doctors often vigorously resist, arguing that their judgment and expertise cannot be reduced to a set of rules.

Because successful specification of work often depends on workers’ involvement, overcoming such resistance is crucial.  Proving the effectiveness of the process is the key to overcoming such resistance.   Wipro recognized this early on and began tracking where and how the specification of tasks was boosting performance.  It quickly saw that specification was particularly beneficial to projects running behind schedule.  Managers were then able to use the data on these projects’ improvements to win over other parts of the organization.

  • Keep studying the work that has been designated as tacit.  Even if work isn’t specified today, that doesn’t mean that it can’t be tomorrow.   What is currently an uncommon event may happen frequently in the future.  And the understanding of complicated problems can grow over time.

With thanks,

Rajneesh Kumar
Mobile: +91 98106-63271
Join my network of Leaders, Managers, Sales Professionals, Educationists, Trainers, CLO, Management Consultants, Six Sigma Professionals, Marketing Professionals, etc at: http://in.linkedin.com/in/rajneeshkumar1

Related Articles:

  1. Wipro’s Tryst with Lean (Toyota Production System)
  2. Lessons from Wipro’s Tryst with Lean (TPS), Part-2 of 3
  3. Lessons from Wipro’s Tryst with Lean (TPS), Part-3 of 3
  4. When Jack Welch set out GE’s Quality Vision 2000
  5. A 30,000-Feet Perspective Of Six Sigma
  6. GE’s Early Days With Six Sigma

About Rajneessh Kumar

A Marketing Professional with 16+ years of working experience
This entry was posted in Six Sigma and tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

One Response to Lessons from Wipro’s Tryst with Lean (TPS), Part-1 of 3

  1. Example of ‘Tacit Knowledge’:

    An investment banker, for instance, may not be able to easily explain how he persuaded someone to accept a deal.

    Examples of Converting ‘Tacit’ knowledge into ‘Explicit’ Knowledge:

    1. One manufacturing company had an experienced scheduler who assigned the work throughout the factory. The company’s leaders, wanting to improve the scheduling process, asked a senior manager to interview him. Initially he answered the manager’s questions with vague generalities. But when the manager persisted, asking him to explain why he made one decision rather than another, he began giving concrete, detailed answers. The manager gradually uncovered the implicit rules the scheduler was using. The company then adjusted the rules, and performance climbed.

    2. A Japanese bank that wanted to grow its home mortgage business found that hiring expert credit analysts to support the desired growth would be costly and difficult. But managers recognized that by carefully studying past lending decisions, they could derive the rules used to make them and embed those rules in an IT system. The system didn’t completely eliminate the need for experts, who had to make judgment calls in cases that were unusually complex or involved special factors. However, the vast majority of cases could be handled automatically, allowing the company to rapidly and safely grow its mortgage business.

    3. Intermountain Healthcare, a company operating in Utah and Idaho, excels at regularly improving protocols for treating diseases. One approach it employs is allowing physicians to override protocols in ambiguous situations. It collects and analyzes the data from overrides and uses the knowledge from successful ones to improve the protocol. If an override produces bad results, the company uses the data to persuade doctors to stick with the routine more often. Intermountain has even created a unit to test clinicians’ ideas and hunches. One test led to better criteria for transferring patients from wards to intensive care.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s