Reader Feedback: Tip Helped reduce the number of key IT controls for Sarbanes-Oxley

Thanks for Two Timely Articles

I want to compliment you on the quality and content of recent magazines. In particular, the July 1 article by Ben Worthen, “How to Dig Out from Under Sarbanes-Oxley,” and the July 15 “Wake-Up Call” by Alice Dragoon were two of the best, most timely pieces of information I have received in my 15 years as a CIO.

As a result of Worthen’s article, we were able to have a conversation with our auditors and reduce the number of key IT controls for Sarbanes-Oxley from 89 to 66—the other 23 just weren’t directly relevant to our company’s financial controls [or the] integrity of our financial reporting.

Dragoon’s article crystallized many of the concepts we have been wrestling with for our call centers, and we plan to use many of the recommendations for transforming our call centers to a source of competitive advantage in our new IT strategy, which will be published in October.

I just can’t tell you how strongly I appreciate both writers’ work and the direct impact it has had on how I help manage our business.

Leslie H. Duncan

VP & CIO

Atmos Energy

Unpredictability in Requirements: Nature of the Beast

To argue the difference between missed requirements versus changing requirements is futile [“No Crystal Ball for IT,” July 15]. From a customer vantage point, it’s unimportant and just serves as semantics to widen the gap between IT and its customer base.

IT and software engineering deal with a lot of unpredictability. It’s not a bad thing. It just is. Regardless of how mature and formal the software engineering process is, developing software is closer on the predictability scale to “waging a war” than it is to “paving a road.” Too many unknowns, changing or missed requirements, changing technology, unproven architectures and tools, unpredictable staffing market, a fickle customer base—the list goes on.

The automotive industry has it right. It comes up with a concept car first, then takes the time to make it consumer-ready. We often, in creating software, do not take this two-step approach. We can’t afford not to. So we keep turning up concept projects, tweaking them as we go to make them more palatable to the consumers.

There is no magic bullet here. The use of software engineering best practices is necessary but not sufficient. The question we have to ask ourselves is the following: Are we willing to pay the price tag for what it would cost to develop robust, industrial-strength software, or are we plagued forever to produce toy products?

Moez Chaabouni

CIO

Hondros College

As business leaders, it is up to us to define the business before any attempt is made to define the requirements for the various IT projects we manage.

We must think outside the shipping box that the system was delivered in. We must begin thinking about our needs as we start to do the strategic planning cycles. We must incorporate our business process design when we shape the business models and consider the tactical plans for deploying the business activities. We must deliberately plan for how the business processes become actualized in policies, procedures, training manuals, employee instructions, customer information and even the design of the service or product offerings themselves. Once we have designed (or redesigned, as the case may be) the business processes, we have the structure of what is needed as inputs to the system planning.

On the issue of financing, I couldn’t agree more with the article. There are many examples of project costs seeming to spiral out of control. The International Space Station is a good example. Many reports suggest that we should abandon the whole thing because costs have risen far beyond the original few billion it was supposed to cost. This problem was due to scope changes that were not anticipated. Can we really blame the project? Surely we simply failed to correctly define the scope of the project. We failed to manage inputs, outputs, processes, quality and product characteristics. A large fraction of IT projects are considered failures. Of those that succeed, many run well beyond the original investment threshold and do not live up to their ROI claims.

Kent Hopkins

CIO