Do you think that your life as an IT manager is stressful and intense? Try applying for a Malcolm Baldrige National Quality Award (NQA) and you'll know what real stress and intensity are.
That's a serious suggestion, though: Try applying for one. But only if you've done all the groundwork to really prepare you for the scrutiny you'll receive. It's doing the groundwork, and getting your organization aligned with the quality precepts on which the NQA is judged, that makes the entire process worthwhile. I guarantee that it will benefit your organization in profound ways.
My initial experience with the NQA was a bit unusual, but I think it does nonetheless demonstrate that IT quality initiatives have real payback.
I'd long been a CIO for various enterprises and institutions. Although IT service quality had always been a concern throughout my IT management career, I'd been unable to establish a definition of it that I was happy with. Sure, I had some general guidelines for overall results. For example, I summed up optimal network performance as "always available, with no single point of failure." For computer services: "always available, response times of two seconds or less." For application development: "on time, as specified and at the agreed cost."
As for more in-depth quality measures, well, the works of Deming and Crosby were enlightening, but their principles were meant for the reduction of defects in products. Cross-walking them to the reduction of IT service failures usually left me with more questions than answers.
Then I joined a start-up business, and all that changed. The CEO made it clear that he had something very different in mind for his new company and his CIO. His company would be organized, built and operated around the NQA performance measures. As for his CIO, efficient IT service delivery would be required. More importantly, though, I would have the responsibility of ensuring that every business function in the firm had the information it needed to make ever better decisions for the customer, and to make them ever quicker.
While I was still interviewing, the CEO asked me if I'd ever done this kind of thing before. No, I told him. "Do you know how to do it?" "Not yet." I must have sounded ready and willing to learn, because he hired me.
But what had I gotten myself into? I was used to being responsible for the delivery of IT services, but now I would be judged on how well the business performed using the information that my function provided. That information had to be effective in terms of improving the strategic performance of the business.
What made the job irresistible to me was the chance to come into a company with no installed base. I would be building the IT function from the ground up. What IT manager wouldn't jump at a chance like that? On the other hand, I would have to make the IT function truly and measurably effective upon business launch.
Step by Step
The effects of the CEO's directive to me were felt immediately as my application systems development professionals and I started to set up shop. Given my very clear mandate to assist the business in achieving its strategic goals, we couldn't just say, "We need this, this and this. Authorize our purchases, please." Instead, we met with each business component to establish their information needs. Then we created a diagram of the overall flow of essential information for the entire business and each component within it. After this, we revised and verified our findings with each business component. Next, I presented the flow diagram to the senior executive committee. With interim approval from the SEC, the next step was to work together with each business component in preparing one-page business cases for the IT investments that would be needed to meet the flow requirements. Finally, each of those was presented to the SEC, which then approved and prioritized them in keeping with the pace allowed for IT investment.
Upon completion of that process, we were ready to start the IT infrastructure and systems development. While that work was quite typical for getting a business off the ground, there was something about it that was very different for me. Because of all the back-and-forth with the business units that had preceded this phase, I knew precisely, for the first time in my career, how the business made its profit and in what ways the IT function's performance was a factor in generating client satisfaction, growth and profitability.
For example, the marketing function needed timely intelligence on client prospects and competition. It needed the ability to make projections based upon different decision sets so that it could introduce timely and profitable product variations. It needed to gather early specifics of trends and the always-changing customer satisfiers regarding our products, to ensure that if they changed, we could change quickly in response.
And the operations function needed data on incoming client calls so that they could be routed to the service agent who was most familiar with the client or who spoke the appropriate language. The call would also populate the service agent's display with the latest information on the client. Calls would be handled quickly and efficiently because all the relevant information the agent needed would be on-screen as the call was answered.
The Quality Factor
Under the program envisioned by the CEO, all of that was just the beginning when it came to quality. We had a quality oversight group that reported to the CEO, and it got around to us just as the IT function was about to go into its operational readiness phase. Marketing research had led this group to develop nine categories of customer satisfaction and about thirty secondary satisfiers, and it was now visiting the various business components to determine the things the business units did that affected those satisfiers. When something was identified as having a positive effect on the satisfiers, it became a quality metric, closely associated with ensuring that satisfaction levels were achieved or exceeded. The IT function ended up with sixty-five quality metrics that we assiduously monitored from that point on. Over half of these metrics addressed IT delivery, and the rest had to do with IT's effective performance in support of business components.
The NQA criteria even extended to team performance measures and compensation, and this was very important in making the whole structure work. Throughout the company, regardless of management level, base salary was augmented by a quality bonus that was based solely on the percentage of quality measures hit or exceeded on a daily basis. Believe me, it was a pleasure to see how this incentive led to everyone helping each other. When a metric was missed, we jointly tried and determine the root cause.
Continuous improvement was also baked in. When a metric was attained two months in a row, its performance requirement was increased, either by reducing its cycle time or adding more to be accomplished in the same cycle time.
Three Years Later
The senior examiner leading the NQA review team during a site visit to our firm took me aside and told me that he and his staff would need to know a few things: "Since the inception of your business, how many customers have you gained? How many customers have you lost? And what have you done about these facts in each case?" Then he added, "Of course, we'll need to see the detailed evidence for each of your responses."
I did in fact know the answers to these questions. Not because of any special effort on my part, but because it was built in to our processes from the beginning.
Thanks primarily to our CEO's foresight, we were awarded the Malcolm Baldrige NQA in the Service category that year. And the company reached profitability two years earlier than was expected in the business plan. It's hard for me to think that those two facts have nothing to do with each other.
I know that this instance was extraordinary in that the IT function was built from scratch with a moderate but still exceptional IT investment pace. That just makes everything easier; as the old joke goes: "God may have created the world in seven days, but he didn't have an installed base." But I've seen many similar best practice approaches implemented very effectively and with exceptional results, regardless of the scale, nature or age of the installed base.
If you were to ask me whether a business case can be made for IT quality initiatives around avoiding cost, improving service and increasing revenue, I would have to say that the evidence is compelling.
Al Kuebler was CIO for AT&T Universal Card, Los Angeles County, Alcatel and McGraw-Hill and director of process engineering at Citicorp. He also directed the consulting activity for CSC Europe. He is now a consultant on general management and IT issues. He is the author of the book Technical Impact: Making Your Information Technology Effective, and Keeping It That Way, from which this article was adapted. He can be reached at ak@technicalimpact.com.