Many years ago, when I was a partner with Ernst & Young, John Cross, the CIO of BP (a very highly regarded company at that time) approached me wanting to benchmark the way E&Y managed its engagements.  My first reaction was incredulity.  I knew we were good at engagement management – after all, it was what we did for a living!  But it was not immediately clear why this would be of interest to BP.  John explained,

You respond to RFP’s and prospect requests virtually overnight.  You assemble a consulting team with the right mix of competencies in a day or so, and you get them on the ground at the client site, with their own consulting workbenches and tools, ready to be productive in about 48 hours.  You do all this while developing new people, managing engagement economics, running a robust quality assurance process, and keeping up with emerging technologies.  If my IT organization could do those things half as well as E&Y does them, we’d be in great shape!”

What You Can Learn From Consulting Businesses

Now I got it, and realized why John had been so successful at BP, leading the transformation of IT first at BP Exploration, and then globally across BP’s business units.  What we found through the benchmarking exercise (BP was part of a 3-year longitudinal study of global IT transformations that I was leading at the time) was that one of the trickier and more subtle aspects of the E&Y ‘magic’ was the deeply ingrained Matrix Management approach.  Individual contributors reported to both their discipline leader, and the leader of the project to which they were assigned.  Both bosses were part of regular performance reviews, with the project leader’s input carrying significant weight.  Over the course of a year, you might work on a half-dozen or more project, and work in a couple of disciplines, so you were getting performance feedback from 8 or more people.

Other Factors for Matrix Management Success

If you need the flexibility and agility that Matrix Management can bring, and the characteristics of a good consulting organization that I described above, there are several ‘conditions for success’ I’d like to point out:

1. Clarity of Roles and Responsibilities, and “Organizational Clarity” as Patrick Lencioni refers to it in his great book, Four Obsessions of an Extraordinary Executive.
2. A clear distinction between ‘role’ and ‘job’ – people may have one job, but fill many roles depending upon their competencies and the need at hand.
3. A robust Performance Management System – where performance feedback is taken very seriously, performed consistently, and has a direct impact on rewards, recognition, career path and promotions.  Both the individual performer and managers must take Performance Management seriously.
4. An organizational environment where ‘power and success’ are not denoted by one’s number of direct reports, but by one’s contributions to the success of the organization.
5. Strong Project Managers.  A ‘project’ is the ultimate temporal unit of management – if the project management process is broken, or project managers not fully competent, Matrix Management will suffer and confusion will rein.

I am indebted (as ever!) to my colleague Roy Youngman for his contributions to this post.

Image courtesy of Life in a Matrix

IT Portfolio Management Matters!

I’m delighted that my old post on this topic (about 16 months ago) keeps attracting readers – portfolio management is one of the most important keys to business value realization from IT.  It is also often poorly implemented.  In fact, quite often, the term “portfolio management” is used without any justification in reality.

Modern Portfolio Theory

IT portfolio management is rooted in Modern Portfolio Theory.  Defined by Wikipedia, Modern Portfolio Theory:

proposes how rational investors will use diversification to optimize their portfolios…

When applied to IT, Portfolio Management proposes how the organization (assuming it is acting in a rational way towards its investments) uses diversification to optimize its IT investments.  In this case, optimization may include balancing:

• Short term and long term investments.
• Low risk, low return against high risk, potentially higher return initiatives.
• Common and shared (i.e., IT infrastructure) against business unit specific investments.
• Investments by major business process.
• Creating new capability versus maintaining existing capability.
• Investing in IT process and capabilities (i.e., improving the “business of IT”) versus investing in IT capability for the business.

IT portfolio management is the primary means to elevate IT decision making and investment prioritization to a business issue.

In this context, IT portfolio management implies a top down decision making framework.  It implies that:

• Senior executives have debated, considered and reached consensus about their IT investment portfolio strategy.
• This, in turn, implies that senior executives have considered and agreed to a business-IT strategy.
• They have wrestled with the thorny questions about “level of optimization” of IT investments – whether this should be a business unit or function (implying a conglomerate or holding company model) or the enterprise (implying a more integrated business model.
• If they balance by business process, that the major business processes have been defined, and their importance to business strategy execution determined.
• They are able to monitor the gaps between their actual IT investments by portfolio category, against their target, or “model” portfolio, and can make adjustments as necessary.

Not a Collection of Projects

From time to time, I see consulting clients attempting to implement portfolio management from a collection of projects.  Sometimes, this activity includes taking a huge list of several hundred (in one recent case, nearly a thousand!) to the business so they can “prioritize the portfolio.”  This bottom-up approach is always doomed to failure.  It is often the result of several years of “order taking” behavior by the IT organization, and is, in fact, the order taking equivalent,  elevated to a different level.  It effectively says:

We’ve taken orders from you for years, and now we have this huge list of projects.  So, please take a look at them, and help us prioritize them, because we can’t do them all!”

This cannot work, and ultimately, reinforces order taking behavior, and the sense that IT does know know what it’s doing, and does not deserve the trust of its business partners.

A Question of Business-IT Maturity

I’ve written extensively about Business-IT Maturity and its relationship to business value. (For a more comprehensive treatment, use this search.)  At very low maturity, by definition, the business executives will not have the wherewithal to engage in and answer the questions exemplified in the bullet points above, so implementing portfolio management is going to be virtually impossible.  But, to get to higher maturity, these questions have to be understood, discussed and decided upon, so the IT leadership is best served educating the business till it is ready to engage meaningfully in these questions.  At that point, they will be ready for IT portfolio management.  Until then, be careful not to call bottom up collections of projects, “portfolios.”  If you do, when you are finally ready to introduce portfolio management, the language, and the business discipline it connotes, will have been polluted.

An the Link Back To Programs?

Finally, linking back to the start of this post, and the readers question, “Programs” become the most meaningful intermediary between “projects” and the “enterprise IT portfolio” – a manageable and meaningful “unit of value-producing work” that business executives can get their heads around.

Photo courtesy of the Building and Fire Research Laboratory.

Among the challenges this CIO faces are a number of Shadow IT groups – small groups of people doing IT work around the company, but outside of the IT budget, governance, accountability or responsibilities of the “official, sanctioned” IT organization.  BTW, when I come across Shadow IT groups that are known/recognized, I always wonder about other Shadow IT groups that might be lurking so deep in the shadows that they are all but invisible.

Shadow IT groups are often a symptom of unmet (or poorly met) demand.  As such, they are prevalent in low business-IT maturity environments (i.e., demand appetite exceeds supply capability, so demand creates its own supply).  Paradoxically, they are also prevalent in very high business-IT maturity environments, although we would probably never refer to them as “Shadow IT.”  More likely we’d think of them as “power users,” or “embedded IT capability” and we’d encourage and celebrate such indicators of high maturity.  So, rule 1 – it’s important to know why you have Shadow IT.  If it’s a result of low maturity, I strongly believe Shadow IT needs to be integrated into the formal, sanctioned, budgeted IT operating model.  If, on the other hand, Shadow IT is a result of high maturity, then the right infrastructure for them needs to be provided, and they should be prodded and encouraged.

Why do I think Shadow IT in low maturity environments should be eliminated?  First and foremost, because they are a symptom of low maturity.  If you are going to eliminate them, you have to commit to (and act upon) improving the state of IT capabilities.  This is, of course, a good thing.  Additionally, Shadow IT groups are often unwitting impediments to improving IT capability.  If as CIO I don’t have the entire budget, then IT spend is sub-optimized.  If as CIO I don’t have control of IT standards, processes and practices, then it is that much harder for me to improve IT capability.  It’s not that some IT capability should not be embedded in the business – it absolutely should.  But exactly what to embed, when and how to embed it are important questions that need to be thought through and the IT operating model properly “designed” (at least at lower maturity levels).  Designing an IT operating model to be something akin to Swiss Cheese, where you have to design around the holes is not efficient, and is not a good basis upon which to drive an IT transformation.

Finally, there’s a “tough love” aspect to tackling Shadow IT groups.  When I was a kid growing up in London, UK, I went to a school where uniforms were de rigeur, complete with school caps!  (Long before AC/DC’s Angus Young showed us how cool they can be!)  I was caught once too often without my school cap and was sent to the Vice Headmaster’s office for a dressing down.  Fortunately for me, he was a wonderful man with a sense of humor, a Royal Airforce mustache and manner, and a vintage Rolls-Royce to boot!  He gave me one of life’s great lessons – that it was not about wearing a school cap, per se, it was about setting and living within defined boundaries, so rebellious chaps like me could push against them without doing real harm.  It’s like a parent disciplining their children – if the discipline is absent, the child will feel unloved.  (Of course, too much discipline is even worse!)  Anyway, when the CIO (with appropriate air cover from the CEO and executive team) announces that all IT will be managed under a single IT budget, and all IT-related resources report to the CIO’s organization, this sends a message to the firm – we are raising the bar on IT!  People may not like it, but they will like the fact that someone is getting serious about improving the performance of the IT function.  I’ve often seen situations where the predictions of “Oh, this will create a real stink and lots of resistance!” was far from what actually happened.  Instead, people said, “About time – please take this group back into IT – its where they belong, and where they will have the best growth and career opportunities!”

So, if you have a Shadow IT problem, don’t be a wimp!  Tackle it head on as an integral part of your IT transformation plan.  Be ready for the noise and resistance, but don’t let it derail you!

The purpose of the survey was to provide an assessment of business-IT capability in a corporation or business unit. We asked that the survey be completed by an executive familiar with the business strategy for technology use, the roles and work of the IT organization, and the relationship between IT and the rest of the business.  The survey consisted of 50 sets of statements, grouped into 10 categories of 5 sets each. Each set had three statements, and respondents were asked to choose the statement (corresponding to capability level 1, 2 or 3) that most closely matched the current state of capability or focus in the business and its IT organization. If the capability is in transition, or split between two of the choices, the respondent could choose 1.5 or 2.5.

The average of results was interesting, with delivering business solutions and managing enterprise architecture showing as the lowest maturity, and the highest maturity in overall focus and overarching goals (indicated perhaps that the spirit is willing but the body is weak?)  More interesting than the averages, however, are the individual company results.  I know several of the companies that participated in the research quite well, and was pleased at how well the survey instrument results reflected the business-IT maturity realities at those companies.  The really big surprise for me, however, was the fact that the gap between the lower maturity and higher maturity environments is so wide, and my sense (based upon my consulting activities) is that the gap between the high and low maturity organizations is widening quickly.

My hypothesis about this is that once an IT organization embarks on an IT transformation (sometimes they call it that, other times the “t” word is avoided and replaced by some sort of euphemism), they keep transforming, at least to some degree – i.e., they gradually master organization change and continuous improvement, and are able to continue evolving as the business matures and as information technology evolves.  Those organizations that never embark on a transformation program become almost literally frozen in time – a sea of legacy systems, legacy skills, and a hodgepodge of ancient practices – none of them consistently followed.

Of course, in these neolithic organizations it is not just IT that is stuck in the dark ages – it is business leadership who’s mental models about IT are stuck in the same dark place – i.e., low business demand maturity begets low IT supply maturity.  As had been said before, “businesses get the IT they deserve.”  Some companies survive like this for quite a while – there are attributes of their business model that insulate them from the march of technology.  Obscene margins and a rarefied competitive environment in businesses that are not information intensive are such attributes.  However, I am convinced that in the current day and age, every business is quickly becoming information intensive, all margins are threatened, and new forms of competition are ready to strike.  The global forces, changing demographics and shifting economic and environmental environment will drive companies out of business if they aren’t able to cost-effectively leverage IT.

The other side of this coin is that low IT supply maturity dampens and constrains business demand maturity.  I firmly believe that IT leadership must have and use the competencies to be “working the crowd” of business leadership, demonstrating improvement in IT supply, and enlightening business leadership to foster higher IT literacy.  They have to take the lead in turning the vicious cycle of low supply capability limiting business demand, and low business demand constraining IT supply into a virtuous cycle where IT supply increases business demand maturity which in turn leads to increasing supply maturity.

John Hagel and John Seely Brown in their landmark paper, “From Push to Pull- Emerging Models for Mobilizing Resources” contend “The edge is where the action is – in terms of innovation and value creation. Companies, workgroups and individuals that master the edge will build a more sustainable core.”   This analogy of “core” and “edge” has influenced the recently completed (though still in the final stages of documentation) research on Reaching Level 3 Business-IT Maturity.

Many IT leaders when talking about the “core” are referring to the “legacy” systems and their drag on resources and forward motion.  They are typically referring mostly to the computer systems and infrastructures they have built over the years and have to maintain.  But in reality, the core goes much deeper than the systems and technologies.  Business processes – especially when you include the unautomated practices and workflows that interact with the automated ones, are hard to change.  The mindsets that dominate “core” thinking and “edge” thinking are radically different.  I’ve noted before that quality guru Joseph Juran distinguished between “preventing bad change” (keeping processes under statistical control” and “creating good change” (innovating processes and products, or creating “breakthrough” performance as Juran put it) and the different management approaches and structures each requires.  Most IT leaders have focused for years on management approaches more consistent with preventing bad change than creating good change.  This has created a mindset that abhors risk taking. 

So, back to edginess.  People can be edgy – those with strong opinions that often feel at first like they come out of left field.  I worked for a boss once that included in our evaluation criteria, “uses appropriate edge!”  This led to a great deal of dialog (all enlightening) and sometimes, real-time coaching when a consultant used appropriate versus inappropriate edge.  In that context, edge was taking a strong point of view that we believed in, even if it felt at the time that client did not share that point of view.  This, of course, is fundamental to good consulting.  Clients don’t hire consultants to blindly agree with all their positions and plans!  There is often invaluable information in edgy people – be they employees, consultants, customers or business partners.  Sometimes, of course, they are wrong, or their timing is off – but there’s still useful information in “hearing” them.  I had a CIO client once that had one of these “edgy” people (let’s call him Fred), and he just did not know how best to leverage him.  We were trying to help his organization become more innovative at the time.  Everyone I spoke to suggested we talk to Fred, and bring him into a workshop we were planning.  When I suggested this to the CIO, he said, “No – Fred’s too disruptive!”  The funny thing is, the CIO really wanted to increase the innovativeness of his organization – and yet his own instincts resisted the some of the very same attributes he wanted to see.  He had risen to CIO by being a great manager, running a very disciplined and effective shop.  He had the vision to know he needed to moved the shop beyond that (beyond Level 2 to Level 3, in the nomenclature of our Business-IT Maturity Model) but was inhibited by his own instincts.  It’s a case of, “I’ve found the enemy – and it’s me,” or “Be careful what you wish for!”  I think Fred left the organization soon after that – and I believe it was an unfortunate loss.

Technology can be edgy – by which we mostly mean “on the leading edge.”  Many IT shops have a well-worn principle that states, “We will be a fast follower of emerging technologies, but chose not to be at the cutting edge.”  I won’t comment here on the pros and cons, and even validity of such a principle, but clearly such shops have made an explicit decision (at least, in principle) not to be edgy in terms of technologies.  What will it mean to such an organization when they want to move to Level 3 – to become more innovative?

Humor can be edgy.  The late George Carlin was certainly edgy!  And therein lies the rub.  When are you “at the edge” and when are you “over the edge?”  The answer of course is relative to the observing party, but being edgy, with anything, introduces risk.  Risk that must be balanced against trust, and much has been written about the nature of trust and its role in the move towards Enterprise 2.0. This issue of the edginess of humor and how and where to draw the line came up in our collaboration with Second City (comedy and improv) who are working with us on the Chicago Executive Perspective event in September.  How should we define the boundaries?

I will continue with this “edgy” theme in upcoming posts.

BTW, sometimes I get questions about the photos or illustrations I select for a post.  For those not in the know, the photo here is of the guitarist/backup singer from the successful Irish band U2.  He goes by the name of The Edge.