More about winning the budget game

Dear Bob …

As usual, thanks for the great discussion (in “Playing stupid games to win … or at least to not lose,” Keep the Joint Running, 10/23/2006).

Per your comment: “In practical terms, this means agreeing to whatever cuts in your budget are proposed by the other side, making two points clear in the process: (1) the business will have to do without something as a result of the cut; and (2) you won’t be the one in the headlights — the standard governance process will be the mechanism through which the company decides exactly what the business will have to do without. That’s what it’s for.”

My concern is a repeat of the client/server era: If we don’t acquiesce to the line of business’ demands they may go out and build/buy it themselves circumventing the process and cost of governance. We have to work with the lines of business to ensure that they see the value in the added costs of governance (complying with standards, documentation, disaster recovery backups, keeping an eye out for audit gotchas, etc.)

And yes, you can use my name.

– Veronica Sanford

Dear Veronica …

Make that part of the discussion: If the budget process results in cuts to IT’s budget and the governance process allows each line of business to pay outsiders to do the work if IT lacks the budget to handle it, then the IT budget cut won’t result in less total corporate spending and will result in islands of automation that don’t fit into the company’s systems as a whole.

And … your job is to make the risk clear. If the company wants each line of business to contract externally, bypassing IT, that’s fine with you.

Another point I’d make to you is this: If the company’s governance process is so onerous that it’s easier to go outside, you should provide leadership to the company to improve the governance process.

If, instead, the problem is that the governance process sometimes results in results that are the right results but are inconvenient to various people in the business, then you should provide leadership to the company to clarify the level of authority associated with the governance process. If it’s just the first store for LOB directors to shop in, it probably isn’t worth the effort and should be abandoned in favor of a governance process that more accurately reflects how the company leadership wants decisions to happen.

There is a deeper challenge in the departments-go-shopping scenario that’s very difficult for IT to deal with, and that’s the cost of ongoing support. It takes two forms. The first is when the contracting department tires of supporting its application internally, and wants IT to take it over. That’s relatively easy to handle: Feed these requests through the governance process as well. It’s just another chunk of spending for value maintenance. IT should be delighted to take it on, so long as it gets the right budget increment to pay for it.

The second form is the cost of interface maintenance. Most systems developed independently by departments won’t have any automated interfaces. Re-keying data is king. But there are some where the department heads aren’t completely bone-headed, and recognize that integration with the existing IT environment, or at least some basic batch interfaces, are the right way to go. With all the best of intentions, IT will easily and frequently break these interfaces – not through malicious intent, but by accident. They aren’t part of the applications inventory; aren’t part of the standard regression testing suite; and aren’t accounted for in the change control process.

To solve this, work with the outside developers, informing them of the process through which they can register the interfaces they build with change control. If it costs more … explain the facts of life to whoever signed the contract, and make it clear that you don’t care either way. They have to make a business decision, and if their contractor isn’t willing to give away service for free … huh. Imagine that.

– Bob