He was the managing director for a strategic business unit that was part of an international enterprise. I first met him when he was looking for an IT project manager.
I found out, though, that the IT system development project he wanted me to manage had been under way for three years and that it was one year late. Worse, it had been reported to be 99% complete each month for the past seven months. The individually contracted junior programmers responsible for the software were nowhere to be found. Instead of the industry standard of three seconds or less per transaction, the response time for the system's online functions averaged about four minutes.
I declined the job offer in a letter in which I suggested that systems being built to improve the productivity of his business unit needed their basic requirements established upfront. I went so far as to say that all such IT systems needed to be developed using something called a "systems development methodology," or SDM. I also sent him a couple of books that explained that SDMs were IT best practices.
Three years went by, and suddenly he wanted to see me again. I found him in a new office, occupying a corner of the corporate building 50 floors above Manhattan. He was now the COO of the entire enterprise, reporting to the CEO and chairman.
He started off by filling me in on what had happened after I had said thanks but no thanks. "We did what you suggested in your letter. It cost us a lot to do it, but the darned thing has been running just fine since we redeveloped it using that 'best practices' thing."
He went on, "My responsibilities have changed, and guess what. IT development projects like the one you know about are everywhere I look." He showed me a list of them.
That was why he had called me in. "Here's the deal," he said, getting to his point, "I've created a new IT management position. No one knows exactly what it means yet, but I've clearly indicated enterprisewide that I'll no longer fund unproductive business unit IT projects unless my new senior director of systems assurance approves them."
Now, I'm somebody who really likes to build things, and here was an opportunity with an interesting twist: to have some influence over building things properly. I had a few concerns about the staying power of such influence, however.
"I know," he said. "You'll be needing these." He handed me an envelope full of his business cards. "I need the word to get out that I will be happy to personally engage anyone that wants to build a system that doesn't do what is needed, is late or is over budget."
With that kind of air cover from the COO, things began to happen. Still, it took about a year for the best practice systems development approach to be fully adopted. IT folks both at corporate and in the business units were required to attend training in how to apply a standard SDM approach to IT development.
While some parts of some IT development projects had to be completely redone, none of them were declared failures and scrapped. The whole idea was to build on what was already in place whenever possible. The process of "cross-walking" an existing IT development project to the standard SDM approach continued to improve and, at some level, it always worked. IT projects were now usually completed on time, as specified and at the agreed cost. An IT fairy tale, with everyone living happily ever after? Not really. Something was still missing.
Even though we were doing everything right, we still wound up with all or partial "white elephant" systems. They either were awkward to use, had features that were no longer needed by the business that funded them, or both.
The results weren't disastrous. Changes could usually be made to those white elephant systems to make them more usable. But clearly this was not the best use of one's IT investment dollar, either.
Why did this happen? Well, I was too busy cross-walking things to see what was right there before my eyes from the beginning. It was too obvious. We were using system requirements that had been established up to two years before a system was implemented. Despite the passage of so much time, we had done nothing to account for changes in the business that occurred in the meantime.
But aren't SDM approaches built to accommodate changes throughout the development process? Yes, certainly. But under normal conditions and by itself, no SDM, no matter how rigorously followed, can automatically accommodate the sudden acquisition of a new subsidiary with a different business model into the capabilities of a system under development. Ditto the divestiture of an existing company, a suddenly imposed major regulation or a fundamental shift in a business's targeted client segment, client acquisition or retention cycle.
Ultimately, the answer was to adopt a higher-order IT best practice. Individual IT development projects would no longer be thought of as stand-alone "IT transactions." Under a new framework, each IT development effort would be considered an integral and connected part of improving the enterprise's strategic performance through IT. That is, every project would be conceived as a way to avoid cost, improve service and increase revenue at every level. Proposed changes to business or enterprise strategies would now involve something called an "IT impact assessment," which considers not only existing IT operational issues, but IT system development effort issues under way at the time as well. The result? No more white elephants.
Of course, these days (when anything can be Googled), if you were to ask me about IT best practices and where they'd be most usefully applied, I'd start by suggesting something called Capability Maturity Model Integration (CMMI) as a proven framework for predictable system development outcomes and a way to continuously improve IT development productivity and IT strategic alignment. As for IT operational issues, there is the Information Technology Infrastructure Library (ITIL). ITIL is a useful framework for those in IT operational roles to consider their contributions as part of what their clients experience, with ever more emphasis on process results instead of precise organizational assignments. And these can be built upon, if desired, with the ISO 9000 framework for quality management systems from the international standards organization known as ISO ("Say what you do, do what you say, prove it, and improve it"). I've even seen new methods emerge in the last few years that combine all of those approaches into the Malcolm Baldrige National Quality Award structure.
Wonderful.
Something you may find useful to keep in mind is the fact that every IT best practice embodies the basic principle to continuously improve strategic business performance through the effective use of IT. The upshot of this should be no surprise to you: Stockholders always consider investing in and managing IT around this principle to be smart leadership.
So what?
Well, if you're in IT management and you haven't yet looked into IT best practices, you may wish to consider how one or more of them might apply to your situation. All IT best practices contain wonderful guidance to show and communicate their value in business terms. Once you're past the awareness and trial steps, you'll wonder, as I did, "Why didn't I do this sooner?"
There's no such thing as job security in IT, of course, but you might consider whether your company's general management wouldn't like to see their IT investments working toward better strategic business performance.
Oh, if you happen to be in general management and you're wondering how to make strategic business sense out of what your folks in IT are doing, perhaps it's time for you to introduce a joint "IT best practices initiative" directed at achieving that very outcome.
Your stockholders are expecting you to do that anyway.
Al Kuebler was CIO for the 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 general management and IT consultant and graduate school lecturer at NYU, De Paul and UCLA. He can be reached at tyvol@mac.com.
