eyetoit

Infrastructure Complexity

Swapnil Shah has an "opinion" piece in Computerworld this week on the challenges of complexity in corporate computing infrastructures, "Defying the IT 'Butterfly Effect.'" I put the scare quotes around "opinion" because in all fairness, Shah is the CEO of mValent, a company that, not surprisingly, has tools for managing complex corporate computing infrastructures (imagine that!).

However, Shah's economic interest in solving the problem doesn't diminish the truth of much that he writes, and it is good food for thought when thinking about the real cost of excessively complex architectures. And while Shah focuses on the value of tools from vendors such as mValent for solving some of the problems this complexity creates, it is also worth considering the long-term savings that can result from rationalizing a complex architecture, as I wrote about some weeks ago in "ROI and IT Architecture"

The CFO of IT (versus an IT Controller)

Computerworld has a number of interesting articles on an increasingly popular role, "The CFO of IT," leading with "The Number Crunchers" and a too-short sidebar interview with the University of Miami's former IT finance guy.

Setting aside the fact that I really dislike grand titles, I'm not sure exactly how much I like the concept of the role that such a title implies, although certainly I think a lack of finance-minded folk in IT is a problem. I think the main issue I have with the concept is what exactly the function entails, and why companies may seek the role. For example, the CFO of AIG's IT group (which in AIG's case is admittedly a separate entity) defines his role as: ""to determine and explain to senior management what AIG is spending on IT and to provide reasonable assurance that expectations are being met."

Is this an important function? Yes. My question is: why wouldn't this be part of the CIO's job?

Of Scorecards and Dashboards

Someone recently asked me to explain the difference between scorecards and dashboards, as this person seemed to hear them used almost interchangeably at his company regarding a portal initiative. Using the rule of thumb that for every person who asks a question there are at least ten more that also want an answer, I figured a quick discussion here might be in line. I will also provide some comments about what the role of each is, suggestions for each type of system, and which might be more relevant to your business (or business unit).

The names of each are actually very well-chosen with respect to their real-world analogs. A scorecard is usually part of a broader corporate methodology or management discipline and is a report card of how a given person, business unit or entity performed with respect to certain goals over a given time period. A dashboard is a set of indicators about the state of a process, piece of equipment, or business metric such as cash on hand or YTD sales at a specific point in time.

An example should make this very clear.

Should You Kill That Project?

If you sponsor enough IT projects, it is likely you will most likely be faced with the decision of whether or not to kill a project. The decision is almost invariably a difficult one, with a desire to see the solution achieved vying with a realistic assessment of the project actually achieving the desired outcome. Emotional factors such as corporate face-saving and an the irrational value typically assigned to sunk costs complicate the intellectually challenging task of accurately predicting the final cost and final success of the project. In this installment, I hope to provide sponsors with some thoughts about making that difficult decision as to whether or not a project should be terminated.

Also, be aware that all of these points will also have merit in keeping an eye on projects to see if they are on track or starting to tempt fate. Many projects that ultimately need to be killed either shouldn't have even started or could have been saved had people caught the warning signs earlier.

One of the first things to realize is that, unfortunately, IT project failures are not uncommon. If you are in a large organization, it is a virtual certainty that projects have failed, even if those projects were not killed outright, or labelled as failures, Many projects actually seem to take former Senator George Aitken's advice about Vietnam, namely to "declare victory and go home." The point is: do not make the mistake of thinking that the project failure is truly unique, do not let the fear of being "the only one" to have a failed project prevent making the right decision.