Information Technology Management with a Purpose

Sep 21 2013   7:35AM GMT

The Quality Conundrum

S R Balasubramanian Profile: S R Balasubramanian

I have been in several companies as CIO during my tenure but the ones which had extensive Quality (TQM) related programs were a little difficult ones to handle. Not that I disliked the quality movement, for I myself was part of the core group in a couple of companies, spreading quality awareness and monitoring progress of projects. I would not even say that this interfered directly with my department’s working but being company-wide programs we were asked to fall in line with the activities.

Quality circles formed seemed very effective on the shop floor, in quality control, field service etc. but running them in administrative departments like ours was always a challenge. We had to pick up some innocuous projects and were frowned upon when presented. A few indoctrinated individuals, intoxicated with the quality approach, would preach their methods to us asking us to make the pareto-chart, fish bone diagram etc. for every presentation ignoring the beautiful and meaningful graphs drawn and statistics made out by our staff. This was really a dampener.

A further prescription pushed on us was that of process orientation, one which says that if your process is right good results will automatically follow. Nobody can dispute the concept, however a single minded push (of this idea) creates an imbalance in our minds. For example I had an sweet little memento on my table given by our technology vendor, which read “Think…results”. A big objection was raised by the overzealous quality followers saying that as a department we were deviating from the quality ethos which says think process and not results. I took pains to explain to him that in a different context it means our actions should culminate in our getting clear business benefits. Similar were other run-ins which acted as hurdles for us to overcome.

Let me also cite example of my experience of engagement with a client for whom I was an advisor. The company is in the business of manufacturing and is in the engineering sector. The CEO of the company had engaged me to guide the company in making IT more effective. The company has a strong orientation towards quality processes and the head for IT & ERP happened to be one who was earlier engaged in planning and quality processes. The IT set up and ERP implementation were very well handled and all processes were running smoothly. Documentation was maintained, regular presentations were made to the management committee, review audits were conducted for various units, several cross functional teams were constituted to solve various problems etc. All seemed perfect and therefore any observer would wonder what more needs to be done.

There was the catch. If everything were so hunky dory, why would the CEO feel the need to hire an external consultant to get more out of IT. I remembered what the CEO said, ‘we do not get much out of IT and I want it to be more effective’. Now as I studied the whole set up in detail, the problem seemed to get clearer and way to overcome them got crystallized. The whole IT program was being run as a quality project. The entire emphasis was on process and the focus was on getting each step right and in doing so they lost sight of the intended results. For example when I pointed out that the MRP results were not being followed completely and considerable manual intervention was required in raising purchase orders on suppliers, the department promptly constituted a cross functional team (CFT) to discuss and work out a solution. As the CFT progressed, small solutions emerged to narrow the error gap and after a few sittings they decided to declare the CFT as a success and to close the exercise. I raised my objection saying that the problem was not yet solved and that the objective of zero error was not achieved. It was argued that the process was right and that gaps would be addressed over time. The team was then reorganized to start another CFT. Similar orientation was observed in the implementation of other systems and even if the systems failed, the team took refuge in the fact that all correct processes were observed. Again the focus was not the end result but the processes. It was difficult to cut through organization culture and make things work. They say excess of everything is bad and therefore excess quality orientation is also counter-productive.

Does that mean Quality approach is not right for IT. Well, no. The philosophy and methods are dot on but the trouble arises when people follow the approach in letter but not in spirit. We have to follow standard and formal processes but keep an eye on our targets and goals. In so far that we maintain our balance things work beautifully and we get the desired results.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: