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

Written by LUMINIS. Posted in Process Management Blog

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 posts: Wipro’s Tryst with Lean (Toyota Production System) and Lessons from Wipro’s Tryst with Lean (TPS), Part-1 of 3

3.  Specify how workers should communicate with one another.

It is about structured communications.  Since multiple people are involved in a process, effective communication becomes imperative—especially because teams may have members all over the world.  A lean system can promote good communication by articulating the ways in which it should be carried out. 

Lesson 3 Strengthen The Communication Structures

Here's how:

One tool Wipro adopted to aid communications was the Design Structure Matrix’.  In a DSM, a project's tasks are listed along the rows and columns of a matrix, and the team marks whether each item is related to the others, designating each relationship as either a direct dependency or a feedback loop.  This Matrix can then create a recommended order for the tasks, and Wipro used a simplified spreadsheet version that any team could understand.  With one push of a button, the program ranked the tasks and identified which team members needed to interact about each one and when.

One of Wipro's lean projects illustrates the challenge and benefit of unambiguous communication within a team.  The team in question had implemented a system of regularly scheduled reviews in which more-experienced members evaluated software code written by their less-experienced colleagues.  The reviewer for each junior member was different each time.  Unfortunately, the senior reviewers used different standards and communicated assessments differently.  What was good code writing to one might be an error to another.  Even when reviewers agreed on what constituted an error, they often called it different things.  The lack of common standards and communication hurt junior employees' morale.  One of the reviewers spotted the problem and called the team together to discuss it.  The group recognized that it had an opportunity to standardize communications as well as the primary work.  Some of the senior members put together a fist of common errors and their definitions, for all the reviewers to use.  The exercise led the team to realize that many mistakes they had considered to be fuzzy errors-issues involving such things as how variables were defined and how explanations were embedded into code—were actually quite concrete.  And once these things were spelled out, the errors could be systematically fixed.  The team's language soon became so precise that even a machine could understand it:  The code-writing program could automatically evaluate whether members had followed the guidelines and would raise a red flag if they had not.  In the end the team found itself spending less time fighting over what was an error and more time working on preventing errors in the first place.  The incidence of errors dropped dramatically as a result.

4.  Use the scientific method to solve problems as soon as possible*

The people who created the problem should fix it*

It is about addressing problems quickly and ‘directly’.   One of the fundamental goals of the Toyota Production System is to turn an operation into a ‘problem-solving engine’.  The core of that engine is the scientific method.  But there's much more to it than that. 

Lesson 4 Turn Operations into a problem solving engine

Here’s how to adapt the scientific method in a knowledge setting:

structured communicationIn an era when team members are often spread throughout the world, the lean idea that everyone trying to solve a problem should be able to see it firsthand might seem unfeasible.  But modern technology makes it eminently possible.  For example, some members of one Wipro team were responsible for testing software at a U.S. customer's site;  other members, based in India, were responsible for fixing any bugs that emerged.  In this case the team members weren't just in different locations—they were in different time zones.  One group was typically sleeping while the other worked.

Sometimes the engineers in India couldn't replicate the errors that their colleagues in the U.S. had found and therefore couldn't fix them.  Ultimately, the team decided to have the U.S. group use web-video tools to record the steps they took and the system configurations that had produced an error;  this made it much easier for the engineers in India to identify the causes and fix the problem.

By using the scientific method and having whoever caused an error fix it where and when it occurred, a knowledge organization can build a problem-solving engine that drives continual improvement.


RK

 

This article is written & published by Rajneesh Kumar, General Manager at Luminis Consulting Services Pvt Ltd, India. He can be reached at Email:  and/or Linkedin: https://in.linkedin.com/in/rajneeshkumar1 


Print

x

Blog Subscription Image

 

 

 

 

I want to subscribe to following blogs: *

IT & Networking Blog
Process Improvement Blog
Leadership Management Blog
Education Training Blog