Our business doesn't generally follow some of the more rigorous processes that larger companies embrace, and this has been a challenge for Ron. One area of friction is our process for justifying IT investments. While we set an IT budget every year based upon specific project assumptions, we leave a great deal of room for adjustment. I often approve work that isn't in the budget, if I think it's the right thing to do.
Ron, a stern advocate of fully quantified financial assessments for any investment, is taking issue with our more flexible approach. I have no issue with ensuring that we put more meat on some of the bones of our IT projects, but the five-page Excel worksheet model he prepared seems to intimidate all but the graduates of accounting programs.
Nonetheless, most of our company's departments have adopted Ron's model, at least in part because everyone likes to have the finance chief's support when seeking to spend money. However, I've noticed that every IT initiative that comes from the finance team doesn't seem to require a business case. Should we assume that, if finance suggested it, the case must be so darned obvious as to not require a rigorous assessment?
A Tempting Target
IT is one of the largest administrative costs at our company, and it makes for a tempting target when Ron is looking to trim the budget. Sometimes, I have to creatively camouflage certain IT projects--hide them in the bushes. Sales, marketing, and manufacturing also have to dust off the PowerPoints from time to time to withstand the additional financial scrutiny. Finance projects, however, are generally safe.
Ron, Sam (our CEO), and I recently discussed one of the major finance projects under way in our IT organization. We're working with one of our key financial suppliers to build linkages between our systems, and Ron is convinced that our supplier will reduce our fees once the new connections are in place. I have my doubts. The design is highly customized, requiring many specific rules programmed into the code. The annual maintenance costs may easily erode any savings from fee reductions, if they even materialize. It wouldn't surprise me if our fees increase, as the supplier adds a "convenience charge" to cover its system implementation costs.
In our meeting with Sam, Ron was pushing to expand the project's scope, and I was pushing back. I suggested to Ron that maybe a business case would help us resolve the impasse. His reply: "We can't afford not to do this. A business case won't change that."
Of course, I was tempted to point out Ron's "do as I say, not as I do" mentality. But getting in the face of the new exec is rarely an effective team-building strategy. Best to take a positive attitude and see the bright side: I do have a VP of finance who supports IT projects--even if they're mostly for the finance department.
With three major IT-driven finance projects on the go, so far I'm batting zero: three business cases requested, none received. I need suggestions on how to get the cops to abide by the law they established.
The author, the real-life CIO of a billion-dollar-plus company, shares his experiences under the pseudonym John McGreavy. Got a Secret CIO story of your own to share? Contact [email protected]. (Editor's Note: This ongoing series of Secret CIO columns is unrelated to an earlier series featuring Herbert W. Lovelace. You can access those archives at informationweek.com/secret-cio/lovelace.)