Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Fri, Feb 15, 2008 11:54 EST

|
Posted by: Laurie M. Orlov in Best Practices Topic: IT Organization ManagementBlog: Reinventing IT
Current Rating: |
The energy generated by How Do You Spot A Bad CIO should be redirected.
Let's do some thinking about how do firms let CIOs get so bad -- and how do you recognize a good one?
Much of the commentary dwelled on obvious signs of mismanagement within the IT organization – and these comments apparently were about CIOs who are still tolerated in their firms.
I would argue that the reason bad CIOs achieve such dubious status is that the business hasn’t noticed the failing CIO yet. But bad CIOs eventually reveal themselves: their sponsoring business organizations lose confidence in them. These business execs stop believing that the CIO understands what they need, that the IT organization can deliver projects effectively, and that information technology tools provide accurate information -- and therefore, business value -- to them. So they complain repeatedly to the CIO’s boss and other top execs until they reach a point where they can no longer tolerate the situation, and soon the CIO is fired or pushed toward the door.
Now why do they stop believing? I recently spent some time assessing an IT organization that was sizable compared to the size of the firm – the CIO had just resigned. The staff was squabbling inside IT and the business sponsors were enormously frustrated. During several years of sizable software development investment, the business execs had abdicated project monitoring to the CIO, and the CIO had not pressed hard to keep them engaged and enthusiastic. Staffers provided no status as to where their time was spent, IT technical issues regularly spilled into the business day, and shadow IT (sprinkled throughout the firm) became the prime source of enterprise analysis and decision-making. Everyone knew – IT was dysfunctional and a shakeup was inevitable.
This extreme misery and the other examples of bad CIO could have been spotted several years before things reached a boiling point. How? You can spot a good CIO, because he or she looks beyond IT insularity and:
- Communicates regularly and consistently with business constituents
- Invites project sponsors to monitor and view short-term deliverables (prototypes and pilots) from large projects -- to make sure things are on track
- Ensures that all involved in spending the firm’s IT dollar provide status about what they are doing – and shares this status in a forum open to IT and business
- Listens to and offers suggestions about solutions to business problems and new ways for the enterprise to use technology and information
- Never knowingly permits internal IT infrastructure issues impact daily operations
-
I like to simplify these issues whenever possible; I agree with Leonardo da Vinci's statement that Simplicity is the Ultimate Sophistication, too often we try to make things difficult. As usual, Ms. Orlov provides excellent insights & advice. I find the two most common mistakes that we CIOs make before taking a new job is:
1. we don't look at the culture to see if there is a good fit
2. wed don't clearly determine the degree to which IT offers a value proposition that is in line with our interests & philosophies,
3. we don't determine early in the process the degree to which we can clearly show how IT would increase shareholder value - and be able to demonstrate that early on - business issues, not technical ones.
More to it than that of course, but a few thoughts about what trips up many of us in the CIO role.
I have a good idea what IT organization Mrs. Orlov is referring to. I disagree with a few points. The comment "Staffers provided no status as to where their time was spent" is factually incorrect, weekly updates as well as as regular prioritization meetings were ongoing. Also the comment "shadow IT (sprinkled throughout the firm) became the prime source of enterprise analysis and decision-making." is not actuate as a tremendous amount of IT resources went into supporting these individuals as should be the case.
The "Assessment" involved spending 1 hour each with a range of IT and business members. The outcome was a set of conclusions that I would question the accuracy and completeness of.
I would argue that in the case of this company, there is quite a bit more than appears to the eye. The business was highly engaged with IT until the steering committee was dissolved by a newly participating business executive. The history of the oversight of the projects is a bit muddy as well. The business in question has a history of charging into projects without going through the process of gathering requirements or allocating enough time to plan adequately. There was also a tremendous amount of push back on any attempt to not over allocating projects to IT, the business constantly tried to put 10 lbs of (you know what) into a 5 lbs bag. This is the reason a few IT processes spilled over to impact the business.
In any case, most likely due to the findings in this quick assessment, a few senior members of IT are out of a job. I would suggest that more time be spend on an "IT Assessment" before providing a set of findings that do not tell the whole story and cost individuals their livelihood.
It's all a question of semantics, but I think IT-centricity shouldn't have its epicentre in the IT function, ie IT-centricity is a organisation-wide issue.
I believe IT-cetricity must stem from the boardroom. Treating all IT related problems including substandard CIOs as IT problems is more often than not a mistake. The problem lies somewhere in the recruitment, development and management spaces.
Somebody somewhere outside the IT function got one or more of these wrong.
It's all a question of semantics, but I think IT-centricity shouldn't have its epicentre in the IT function, ie IT-centricity is a organisation-wide issue.
I believe IT-centricity must stem from the boardroom. Treating all IT related problems including substandard CIOs as IT problems is more often than not a mistake. The problem lies somewhere in the recruitment, development and management spaces.
Somebody somewhere outside the IT function got one or more of these wrong.