Most of you may already know what TQM is and what its strengths are. But for those of you who don't and who always wonder, like me, how TQM can be applied in Software, I put-together this blog.
I always wondered what TQM (Total Quality Management) is and why we don't use it to imporve quality of Products and Services in Software. In Winter 2006, I took a course in Operations Management, as part of my MBA at
Leavey School of Busineess, and got some answers. I hope this blog will help you in getting a deeper understanding of TQM and its role in Software Industry.
TQM Principle: Intrinsic Quality Control. Improve quality of processes to improve quality of process outcome, i.e. the productTQM Origin and Background: In mid 1940s,
Dr. W. Edward Deming picked up some of the ideas from
Walter Shewhart (who discovered that quality can be measured, and that there are measures of variability) and developed what is known as TQM. In 1940s, Dr. Deming was working as an advisor in sampling at the Bureau of Census and later became a statistics professor at the New York University Business School. At that time, he had little success convincing American businesses to adopt TQM, but his management methods did gain a huge success in Japan.
While the Japanese were concentrating on producing quality products, businesses in the United States were more concerned with producing large quantities of products. Their emphasis on quantity at the expense of quality let the Japanese, with their inexpensive, high quality products, gain a substantial foothold in American markets.
In the 1970s and 1980s, many American companies, including Ford, IBM, and Xerox, began adopting Dr Deming’s principles of TQM. This gradually led to their regaining some of the markets previously lost to the Japanese.
TQM Definition: "TQM means that the organization's culture is defined by the constant attainment of satisfaction through an integrated system of tools, techniques, and training. Total Quality Management is a management style based upon producing quality service as defined by the customer. TQM is defined as a quality-centered, customer-focused, fact-based, team-driven, senior-management-led process to achieve an organization’s strategic imperative through
continuous process improvement."- T = Total = everyone in the organization
- Q = Quality = customer satisfaction
- M = Management = people and processes
TQM Benefits: TQM has few short-term advantages. Most of its benefits are long-term and come into effect only after it is running smoothly for some time. In large organizations, it may take several years before long-term benefits are realized. Long-term benefits that may be expected from TQM are higher productivity, increased morale, reduced costs, and greater customer commitment. These benefits may lead to greater public support and improvement of an organization’s public image.
TQM & Software Industry:
Q. Can TQM be applied to Software Industry?TQM was originated in the manifacturing sector but it has been successfuly adopted by almost every type of organization imaginable - for example - hotel management, highway maintenance, churches, schools & universities.
If you look closely at Software development, it is no different from any other industry. We develop software using processes. We know our processes are not perfect. What can we do to improve quality and bring more discpline into our processes? TQM has the answer.
Remember, we can't test quality into our software, we design in it. And the only way we can design quality in is by continuously monitoring and improving our processes.
Since TQM requires extensive statistical analysis to study processes and improve quality, we need be able to define a variable (or set of variables) to monitor a certain process. We should be able to then make a corrective action whenever we find that the process is going
out-of-control. But, how do we know if the process is going out-of-control? Note: A process
in-control means it's repeatable.
Q. How do we know if the process is going out-of-control?
Use Control-Charts. They are also known as XBAR and R-Charts. It's hard to explain without a diagram, but I'll try to explain. You measure a process variable and define the target mean i.e. it's acceptable average value. Note: To be able to begin monotoring a process, it must be in-control. Then define the Upper Control Limit (UCL) and Lower Control Limit (LCL). Use XBAR Charts to track if the process is going out-of-control. This
URL provides more insight into how to define UCL and LCL. Note: if the LCL drops below some practical value, then choose zero.
Dilbert Syndrome: "When we treat symptoms, we get a step closer to Dilbert Syndrome. Making a wild guess at what went wrong and act on it to adopt a new unproven process."
PDCA Cycle: Plan-Do-Check-Act is also known as Shewhart Cycle. Instead of following a Dilbert Cycle, where one only react to changes, PDCA shows a more sophisticated way to welcome change. Look at the problem in detail and check what's wrong (Plan). Then try improvement in small steps (Do). Gather data and analyze results (Check). In the end, make a decision (Act) and repeat the cycle for next problem. It's common sense, isn't it? But we still find managers suffering from Dilbert Syndrome almost everyday!
Summary- We can't test quality into our software, we design in it
- A chain is as strong as its weakest link. We must find and fix the bottlenecks first.
- Processes needs to be continually improved
- Don't treat symptoms. Don't follow Dilbert Model
- The People who do the work generally knows best how to improve it
- Use quantitative methods to support decisions, whenever possible
- Plan a flight, and fly the plan
*Links and References*- Operations Management, OMIS 357 Class - Leavey School of Business
- Software Practicum, CS 2335 Class - Georgia Institute of Technology
- XBAR and R-Charts
