CIO’s and EA – Leadership Challenges in IT

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.

EA Value Contribution

What value does the EA function provide to the enterprise?  That question consistently ranks in the top ten list of most frequently asked EA questions.  The question, unfortunately, doesn’t lend itself to a simple answer.  It is more often a matter of value being in ”the eye of the beholder”.   In other words, the answer to the question depends on who is asking and what answer they expect to hear based on their personal and professional interpretation of the word “value”.

A systematic, multi-part approach to addressing the value question can lend clarity.  By classifying the various ways that EA groups contribute value, and identifying the stakeholder communities and how they align themselves with those classifications,  each organization can address the value question in terms that are meaningful to their particular stakeholder mix.  In our experience every organization always has multiple value expectations. 

The weighting among various value contributors differentiates one organization from the next.  The weightings will change as the EA function grows and evolves.  To begin to answer the value question, lets define three possible value contribution classes.  These are focused not on what an EA function is, but on what it does for the enterprise:

Project Support:  In some organizations, value is defined exclusively by an individual’s direct contribution to the completion of project-oriented tasks.  While one can argue as to what proportion of individual EA team member’s time is directly or indirectly linked to project tasks, and it will vary by role, skill set and EA maturity, in the aggregate every EA team interested in long-term survival must make their contribution to project completion visible.  After all, it is the rare organization that doesn’t perceive “getting things done” as the highest value component.  As EA teams evolve, contribution to project success will become less hands-on, design-oriented and become more “guidance” oriented as the EA team uses its collective insight into the future state and roadmaps to inform project activities.  In these cases, getting things done “right”, in consideration of both project and enterprise requirements, becomes the operative value contribution.

Strategic Direction: The “raison d’être” of an EA group is to understand the strategic direction of the organization and capture it into a future state representation that reflects the eventual achievement of that direction.  For leaders that believe in EA, their expectation is that the EA organization will invest resources in creation of go-forward standards, patterns, platforms, models and other representations.  After all, an EA team cannot effectively and efficiently perform their “support projects” value contribution if they don’t have a basis to use in providing guidance.  Therefore, creating useable and prescriptive future state guidance, and communicating those directions to the project and asset communities, is a key value contribution that must be included in the mix.

Portfolio Transformation:  It is a rare organization, indeed, that doesn’t suffer from the accumulation of past incremental additions to its asset portfolios (technology, solutions, information, etc.).  Each addition was, at the time, fully justified and sensible in the context of the problem they were trying to solve.  Only upon retrospective analysis does an organization discover the burden those portfolios place upon them in the form of cost, resources, or inflexibility.  Given the future state holistic perspective defined by an EA function, a significant value contribution of EA is to help guide portfolio transformations to shed excess or duplicate components and bring them into alignment with the go-forward wishes of the organization.

By analyzing how the EA function can contribute in each of these categories, and by thoroughly understanding the expectations of stakeholder communities in each, the EA team can strike a balance that will satisfy itself that it is doing the right things, and demonstrate it to leadership as well.

Poll Update – Project Staff and EA

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

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.