Menu
Menu
Oh, the Perils of the OCIO

Oh, the Perils of the OCIO

The right way to deploy an Office of the CIO structure.

There is a certain level of guilt associated with reading business publications. The topics usually aren’t too much of a surprise, and the information, while occasionally insightful, inspires more self-reproach than action. The articles tend to focus on what I call the “important but not urgent” subjects, including strategy, metrics, governance, communications, portfolio and project management, architecture and standards, financial and human resource management, security and privacy, and disaster recovery.

Because efforts in these areas don’t deliver immediate performance improvements and require allocation of scarce management and analytical resources, it’s all too easy to let these items slide. In response, CIOs often abdicate these responsibilities rather than appropriately delegate.

One type of abdication happens when you keep the work on your desk in the vain hope that available hours will magically appear on your calendar. A second type of abdication is more insidious. It occurs while chartering and managing the Office of the CIO (OCIO) organizations. Watch out for two common mistakes.

The first mistake is to hold the OCIO function responsible for outcomes out of its direct control, such as improved project delivery, value realization and compliance to standards. Only line IT organizations (that is, the technology delivery and services organizations) directly control the three P’s of accountability — the people, the process and the P&L. Only they can be held accountable for the results of the OCIO initiatives.

It’s inappropriate for CIOs to funnel all IT staff work into Office of the CIO organizations, in a misguided attempt to help the line IT organizations maintain focus on completing projects and delivering services. Without intense involvement from the line organizations, much of the work of the OCIO staff will be wasted. For living, breathing, frustrating examples, consider the performance of the typical project management office or architecture functions (enough said).

The second mistake CIOs often make is to keep piling work onto Office of the CIO staffers with little regard for their capacity or that of the line IT organizations they serve. You know you’re in this situation if your OCIO is managing transactions rather than ideas. Great staff work requires time to think, which does not occur when people’s calendars are full of meetings and report preparation.

The sad reality is that there are never enough resources to complete staff work because there is a never-ending succession of great ideas; staff work creates even more staff work. OCIO staff functions create work for the line organizations that, in turn, produce stuff that has to be reviewed, approved and reported on by the staff organizations.

To make headway on your “important but not urgent” list (and alleviate your guilt), you need to:

1. Focus on the IT outcomes you’ll actively manage.

2. Maintain lean OCIO staff organizations, and hold them accountable for defining the necessary policies and processes — translating data into insights and alerting the line leaders and you (in that order) so that there are few surprises along the way.

3. Hold the line IT organizations accountable for outcomes related to the staff work.

4. Rotate your OCIO staff employees back into line roles after two to three years so that their designs, relationships and insights are based in reality — not the latest conference.

For example, if one of your important outcomes is a more focused, higher-value IT agenda, then strategy-making should be on your radar screen. Designate a staffer to define real-world strategy-making objectives, processes, templates and time line; ride herd over the progress and quality; and consolidate the results. At the same time, ensure that the line organizations do the heavy lifting of the strategy-making process — namely, executing the process and completing the templates, according to the time line defined by your Office of the CIO.

Support your OCIO staff organizations by reviewing their results with the leaders of the line IT organizations and bringing them back into the fold, if necessary. Because the line organizations report to the CIO rather than the OCIO, they will be motivated to do quality staff work for the OCIO only if the CIO talks to them about it.

This column is in response to a reader who asked what I think about the Office of the CIO concept. My advice is that if you want to make progress on your “important but not urgent list”, then pick your battles, slim down your staff organizations, and stay involved. Once the new processes are baked in to your IT organization, you can reduce staff involvement even further and move on to the next priorities on the never-ending list.

Reader Q&A

Susan Cramm answers questions on “Oh, the Perils of the OCIO”

Q: The notion of an Office of the CIO may be appealing, but it addresses the symptom rather than the cause. The root problem is functional consolidation of “computer people”. If the OCIO concept is effective, then why don’t insurance companies have a CMO (chief mathematics officer) to which actuarial, finance and accounting people report?

A: You do see chief mathematics officers — they are called CFOs. Most companies centralize staff functions within the organizations of the CFO, CAO or COO (including functions such as accounting, finance, strategy, risk management, human resources and facilities) rather than letting each line organization duplicate these functions in their entirety. There are two reasons for doing this — fiduciary and efficiency. However, in separating these staff functions, there is always the risk that line organizations’ accountability and authority become muddled and diluted. It is the responsibility of those running these organizations to recognize the line as their customers, to ensure that ultimate accountability remains with those who can truly influence results.

Q: My 11 years of experience as a field services manager and director tell me that the number-one thing that IT folks (techs) do worst is administrative tasks, while the number-one request from customers is for “administrivia” — report on this, quantify that, quote this, find the root cause on that . . . Given budgets, this makes me want to retain dedicated IT administrative staffers to handle reporting and field client requests for data and information.

A: Your comments get to the heart of the OCIO dilemma. It’s a great idea to provide staff support to line organizations in order for them to fulfil their obligations. In your case, it may make sense to conduct root-cause analysis on behalf of the technologist. However, it does not make sense to hold the staff organization responsible for remediation of the issue. Only those doing the work can be held accountable for the outcomes of the OCIO and administrative support functions.

Q: What is a typical project management office (PMO)? Is there value to the PMO, and if so, what?

A: I can’t imagine running an IT organization without some type of PMO, at a minimum as a mechanism for the CIO to see a consolidated view of project status and financials. Regardless of the form of the PMO — from centralized management of large enterprise projects to decentralized project management with centralized portfolio management, monitoring, reporting, standards and training — the mistake most often made is to hold the PMO, rather than the IT leaders, directly accountable for project success and the utilization of standard practices. (See "Why You Need a Project Management Office”, CIO August 2003 for more information on PMOs. – ED)

Susan Cramm is president of Valuedance, a California-based executive coaching firm

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.
Show Comments

Market Place

Computerworld
ARN
Techworld
CMO