CIO’s and EA – Leadership Challenges in IT

February 28, 2010

We ask a lot of our CIOs.  Just follow the myriad magazine articles and research pieces targeting CIOs to read of the breadth and depth of expectations heaped upon a single role.   The industry experts who define what CIOs “should be” suggest that they must be technology visionaries and innovators, business transformation change agents, vendor relationship negotiators, savvy business managers and human capital performance motivators, cost-cutters, quality experts, portfolio managers, talent scouts, have operations and service management knowledge, be technology, process and solutions aware, passionate leaders and experts on the company’s industry, etc.  The list goes on.  Actually, I agree with all of these traits and more – they are all required.   It’s a tough job and can’t easily be characterized into a simple role description.    

As a case in point, I have been following Bob Evans’ column in Information Week of late.  I enjoy his perspectives.  His most recent column, “Do CIOs Still Matter” , struck a chord in me.  He listed ten ideas to get started redefining a CIOs roles and boundaries.  Many of his points spoke to things that we have been coaching our Enterprise Architecture clients on for years.  In particular, he commented that today’s CIOs “spend too much time on the tech side of IT and should instead be more involved in technology-enabled business growth and customer intimacy”.  Other points included “lead the charge in seeing the future”, “drive transformation” and my favorite, “be a business-model buster”.

So, what is the CIO to do?  How can a CIO be tactical and strategic, responsive yet not reactionary, thoughtful and systematic yet not slow and obstructionist, operational and also transformational, cost-sensitive while investment and growth oriented?  The simple answer is that in all but the most extraordinary individuals, it isn’t possible, or it is at least unlikely that all of the required personality traits and knowledge can co-exist.  The best approach to being broad and deep enough is to surround him/herself with a strong team, with each member focused on different aspects of the role.   The best CIOs are already doing this, realizing that the CIO role isn’t intended to be a single super-human (though many white papers seem to suggest that and some CIOs try to become one) but is instead an aggregation of the skills and talents of a group. Traditionally, that group is called the “Office of the CIO”.

Many CIO’s already recognize that they can’t personally be everything to everyone and that they must have a great staff.  Most CIOs put a director in charge of the data center with a focus on operational efficiency and meeting service levels.  One or more directors are usually focused on solutions development and delivery.  The better organizations have a PMO in place to shepherd the project portfolio, though most PMO’s are low maturity engaging in mainly project tracking and reporting.  More on that in a future article.  What is missing in most CIO Offices is a person responsible for the big picture future state business context, the holistic cross enterprise perspective, the long view of the health and utility of the asset portfolio, and to address larger concerns like complexity management, portfolio optimization, integration, and the integrity of the information, technology and business architecture assets.  These activities and perspectives are embodied in the role Tim and I have prescribed to the “enterprise” architect since we began in this discipline in the 1990’s.    

While empowering a diverse IT leadership team is necessary, successful CIOs also understand that the buck stops with them, so they need to be able to make sound decisions when the rest of their staff doesn’t.  One powerful way to be sure the staff can address all the perspectives above, including the longer term, holistic enterprise view, is to elevate the Chief Architect to be a full member of the Office of the CIO.  If you have an EA function, but it is doing only the subset of enterprise architecture that we describe as “IT” architecture ( which usually means they reside several levels down in your organization)  then augment their skills and personnel and have them engage in the strategic and business-oriented discussions described above.  You will find them to be a valuable addition to your core team.

Stay tuned, we will be writing a lot more on the placement of EA in the Office of the CIO, the complimentary roles that exist in the Office, the dynamics, politics and culture of the team at that level, and the processes, perspectives, and leadership skills required for that team to support the breadth and depth of activities expected of the modern CIO.

Poll Update – Project Staff and EA

September 30, 2009

We’d like to thank everyone for responding to our poll from Overcoming the Tensions Between Project Staff and EA Groups.  The poll is now closed and here are the findings:

We have a lot of work to do on our relationships!  Fully 71% responded that the relationship doesn’t exist or that there is room for improvement.  There is some good news though – 57% at least HAVE some sort of relationship that needs improving and 29% consider the state of their relationship to be “healthy”.

Here is an excerpt from an offline comment that I found particularly relevent and insightful:  

“I’d say you are spot on with your observations and I think you need to let both groups know that an enterprise architect is fundamentally a differently-skilled person than a project manager.  As you point out, an EA is concerned with the future, the long-term strategy and the big picture.  A project manager is concerned with the here-and-now, budgets, resources, details and “the little picture”.  An EA must be aware of all projects in the organization, and makes decisions regarding how one project can easily affect another – and maybe not in a good way.  Project managers are under huge pressure to manage the scope to the budget and the timelines, while EAs are not. 

My point is that an EA thinks dramatically different than a PM.  Both the EA and the PM need to understand and recognize this and build on the differences and not let those differences destroy the relationship, and certainly to not jeopardize either a project’s goals nor the enterprise IT strategy.”

Well said. The writer asked to let both groups know; consider it done!

Thanks to all again that had interest in this topic.  Comments are open if you have any additional ideas.

Overcoming the Tensions between Project Staff and EA Groups

July 31, 2009

A few months back, at the recent EA Symposium in Toronto, I gave a presentation on the tensions that exist between project staff, particularly project managers, and the EA Team.  The audience was primarily of the architect persuasion.  The session was well received in spite of the fact that I was fairly tough on them, challenging them to take responsibility to make sure their relationships with their project communities were healthy and productive.   The core message of the session, as well as the overall conference, was about balance – how to live up to the larger role of an enterprise architect in addressing holistic, enterprise-wide, strategic opportunities while also ensuring that today’s challenges and initiatives are supported through their work.  

I touched on future state EA content creation, governance, and their coach/assist role.  The latter requires rolling up their sleeves and engaging directly with project teams.  Recommendations included warnings to not reside in an ivory tower, and advice to actively engage with project and asset communities, to encourage contribution, to communicate and be transparent in their work, and to not act as the architecture police.   While these messages aren’t a surprise to those of you who have worked with us, the audience seemed to appreciate hearing them, resulting in 40 minutes of group discussion. 

What I enjoyed the most about this discussion was the enthusiasm of the audience.  As a fairly typical conference audience, the group was very diverse in experience, representing private and public sectors, large and small organizations, and veterans of EA work (both successful and wounded) plus newbies and wanna-be’s.  Many described themselves as being in situations not of their making – stuck being reactive vs.  proactive, no time to look forward because they were full time project engineering support resources, they felt they did solid forward-looking strategy but nobody cared, project needs always trumped longer-term objectives, no leadership support, etc.  The better news is that, after some discussion, most saw that applying the techniques we discussed could help them be more balanced, improve their situations, and earn the right to be more influential and better leaders. 

Coming full circle to the main topic, at the end of the discussion I held an informal poll to find out how many of them thought the relationship between their EA group and their project counterparts was “healthy” vs. “room for improvement” vs. “non-existent”.   Despite the fact that the diversity of the audience makes it impossible to draw any statistical conclusion from their answers, and that each likely interpreted the choices differently, the responses were overwhelmingly “healthy” and “room for improvement” with almost no “non-existent”.   So for this group, they generally thought they are doing “OK”. 

Being a scientist and an analyst by nature and training, I wanted to get an alternative perspective so I sought to gather data in a different venue.  A few weeks ago I presented at the Project World conference in Baltimore, and chose to do a round-table discussion on the same topic.  My audience at that occasion was completely different, primarily project managers and business analysts.   Not surprisingly, it was a very different discussion.  Once we level-set on roles and responsibilities of architecture and the varations from organization to organization it turned into a good discussion.  I believe I left them better informed about the nature of the relationship between themselves and the EA community.

At the conclusion, I asked them the same question I asked the EA Symposium audience.  Not surprisingly, I got the opposite result.  They skewed heavily to the “room for improvement” and “non-existent” side when describing the relationship.  The good news is that they admitted that it wasn’t entirely the fault of their EA teams, and as much a result of the pressures they were under to “eliminate distractions and just get their project done”.  Most suggested that they now had a better appreciation for the role of EA and would be more open to listening upon their return.  The bad news was that they also said that their EA groups had to do a better job communicating and engaging as well.

So, my advice to the Enterprise Architects out there: Even if you think you are doing well managing the relationship with your project community, you are probably not doing as well as you think you are, at least from their perspective.  Take some steps to health-test that relationship, either formally or informally, and put an improvement plan in place.  Give us a call – we can help.

Finally, to feed my scientific need for more data, please reply to this thoroughly un-scientific poll.  If I get any meaningful data and reach any conclusions, I will let you know in a future post.


Get every new post delivered to your Inbox.