RSSRelax, it’s not your fault
It's your CEO's fault! But then, you already knew that, right?
Of course, in some senses, everything that happens in the business is the CEO's fault, or fortune, as the case may be. The CEO is ultimately responsible for everything downhill from their desk working properly (or at least, they were, before the CEO payscale revolution, where accountability seemed to go out the window and compensation flow all out of proportion to the success of the business; maybe I am just being old-fashioned here), so if IT is messed up, ultimately it's at the CEO's feet.
Apparently this is a sort of revelation in the industry, sparked by some comments by Mark Hurd noted in InfoWorld, and lately expanded on by Michael Krigsman at IT Project Failures.
Hurd simply suggested that in cases where he personally was coming across bloated, inefficient IT department, it was due not to bad IT, but a bad CEO. As noted above, I don't see how you don't make this association, but it provides some insight on how off-track the whole business/IT relationship had become before we all came to our senses and started talking about business/IT alignment, as if it wasn't something that should have been obvious from first principles. Krigsman expands on this, discussing the matter with a number of CIOs who basically say "Duh." For most CIOs, this isn't news; you're the ones that have been rolling your eyes in meetings and watching the CEO take a nap as you raised issue after issue, only to find him breathing down your neck the instant something you predicted actually goes wrong. It's no surprise that things have become dysfunctional in environments where these basic responsibilities of business leadership have been abrogated to such an extent.
This isn't to let the CIO entirely off the hook, either, however. CIOs have done much to develop an unnecessary mystique of IT operations, creating separate fifedoms within the organization, obscuring and obfuscating their functions and at times leading the organization in a direction that had more to do with personal preference than business priorities. CEOs became understandably confused and frustrated at such antics and their own inability to penetrate the fog of techno-babble. Of course, they should have gone CIO shopping at that point to fix the issue, but probably didn't trust their own judgement to replace the problems, perhaps correctly.
Either way, it's going to take outreach from both to fix the issue. The CIO has to be more accessible, more business-oriented, and the CEO has to take more interest in, and be more open to, IT capabilities, concerns, and issues.
Great Blog Scott. I agree with your point that the CEO is to blame. It is a point I have made repeatedly in my book http://www.stopblamingthesoftware.com/ and my blogs http://itpsb.blogspot.com/, so it is interesting to read that other people have also seen the light. However I don’t totally agree with your supporting argument.
It is easy to simply state that the CEO is the root cause for failed IT projects, but organizations need to know exactly how and why CEO’s contribute to these failures and how they can resolve it. Simply put, we need the CEO to be strategic prior to project commencement, not hands on during, or breathing down the neck of a CIO or Project Manger trying to implement the project. Generally speaking, CEO’s do not specifically need to “take more interest in, and be more open to, IT capabilities, concerns, and issues”, unless these are business issues that will influence the delivery or outcomes of the project.
However, what is required by the CEO *before* the project commences is their involvement, commitment and accountability for driving the strategic pre-implementation process of salient business and project decisions that determine the project planning strategy before the critical investment decision is made and certainly before the project commences (It is too easy to simply write a check if you are not accountable for outcomes of your decisions).
This process puts the CEO back in the drivers seat for the IT project, rather than them having to be heavily reliant on CIO’s, third party consultants or vendors (who may have their own agenda) for information and guidance. The strategic pre-implementation process enables visibility of the organizations business requirements and risks. It also fosters collaboration and accountability between the CEO and other C-level executives (if done correctly) at the projects outset for critical decisions which will later cascade in to the projects execution.
When CEO’s abdicate control of this process, or do not have a rigorous process in place in the first place, this is when the wheels begin to fall of the project, even before it has commenced. Their involvement at a later date when projects begin to go off the rails is often far too late. But because they weren’t accountable in the first place for their strategic decisions and planning, there is no impact on them when the project fails!
Kind regards
Sarah Runge
Hi Sarah,
Thanks for your response.
I’m not sure it’s as complicated as you are making it; most of your prescription seems to simply be MBA best practices, as applicable to any function within the company as to IT particularly. Similarly, I don’t think it’s much of a mystery, to CIOs at least, that they are given impossible or conflicting marching orders and then left to cope as best they are able until the project implodes and the board and CEO come storming back onto the scene. At least in organizations I am familiar with, this point has been made repeatedly and vociferously with little impact… the CEO may hear that it’s a problem, but without more familiarity with *why* it’s a problem, they disregard the complaints.
I continue to maintain that a greater interest by the CEO is required in technology capabilities, concerns, and issues, for two reasons. First, without that, the onus continues to rest with the CIO to achieve the impossible using whatever magic the CEO will continue to assume the technology is capable of, or to expend a great deal of energy justifying refusals or alternatives. Second, I think we’re at a point where technology investments are sufficiently intertwined with strategic advantage that it’s fatal for the CEO to not have more familiarity with them. Your point about the CEO not needing to take that interest “unless these are business issues that will influence the delivery or outcomes of the project” seems moot to me; technology issues *are* business issues, just like accounting issues or HR issues. As our pals over at Forrester have been telling us lately, it’s not *information* technology anymore, it’s *business* technology. Further, I don’t see how you can assert that this makes the CEO any less dependent on the CIO or consultants/vendors; if they don’t understand the technology, then they are just at much at the mercy of those who do or purport to, whether it’s in an earlier stage of planning or not.
This may simply be a philosophical difference we have; I’ll check out your blog to learn more about your stance. From this limited description, though, it seems to me it is basically a traditional effort to get stakeholders together and plan the heck out of a project before it launches. My view is that this just doesn’t work with technology projects, for a wide variety of reasons; they are too mutable to set and forget, and ongoing and coherent involvement is a must for success. I like more fluid, agile management approaches, which don’t really gel with what you suggest. But I certainly do agree wholeheartedly with your last paragraph, which may indicate that is really the heart of the matter for both of us.
Cheers,
Scott