Related White Paper

Project Management Network Diagram: A Tool for Understanding the PM Life Cycle

I think there’s continual turmoil in most IT industry workers regarding the inevitable friction between the way things are, and the way they could be.

All of us who love technology are passionate about the potential we see around new and existing technologies. 

But most of us work in a world where little of that promise seems to be ever realized, or takes too long to bring vision to reality.

Which brings up the central question stated above – how does IT drive change?

I’m not an expert on the subject, but I’m a knowledgeable observer. 

I have the privilege of meeting with literally hundreds of IT thinkers, and I’ve been able to piece together elements that seem to work.

I wouldn’t call it a recipe, more of a list of ingredients that are common themes that I’ve seen in IT organizations that have been successful in driving change.

The Frustration Factor

A certain level of frustration among IT workers and leadership is pretty pervasive, as near as I can tell. 

They get how the technology can be used to transform the business.  They get how the societal context of technology use is changing.  They see how existing solutions could be deployed to gain real benefit.

But everywhere they turn, there seems to be another mountain to climb.

Budgeting and funding models that only allow incremental improvements, rather than transformational changes.

Very few business leaders that are reluctant to lead orchestrated synergy between business and IT.

Lack of forums and coordination mechanisms that help larger and more coordinated outcomes.

Business people who aren’t up-to-date on what technology could do for their business.

Stove-pipe mentalities.  Lack of context.  No sense of urgency.  People who don't get it.

And so on.

But I do meet people who have cracked the code in different ways. 

No one seems to have it all sorted out (remember, that’s why they call it work).  And they’re making substantive progress on many issues.

So what are some common themes?

Can You Describe The Business Context of IT?

As you might know, I do a fair number of customer briefings.  And at some of those, the lead delegate starts with an overview of their business and how IT relates. 

And at some of those, they just nail it.

They paint a concise landscape of how their business is changing, and how IT has to enable this change.

They talk about what they do well, and very openly about what they need to do better.

They can state the outcomes for the business if they do well, and the consequences if they do not.

They see themselves as part of the business, rather than supporting the business.

And they don’t need a whole lot of powerpoint and buzzwords to get to the key points.

In the space of 15 minutes, I get a full understanding of what they need to do.

I feel energized and motivated to help.  I can only think that other business people would feel the same way.

Not to be negative, but many people seems to re-hash the same old "cost-reduction, improve service levels, become more responsive to the business" concepts that we’ve all heard for many years.

The good ones can precisely frame and link these to specific business challenges that are visceral and actionable.

Recipe Ingredient #1:  Make sure your IT leaders have a 15-minute business pitch that does the above.  Make sure they can deliver it.  And make sure they’re using every opportunity to deliver the message.

Don't Talk Technology, Talk Outcomes

We're IT people, so we talk technology. 

The impact of what we do should be obvious, no?

Well, it isn't.

As an example, "server virtualization" means nothing to most people. 

Cutting power by 60%, slashing capital and operational costs, and providing near-instantaneous response to new provisioning requests means more to people.

A nice blurb in the annual report on how your company is becoming green, freeing up budget for new business projects, and cutting time-to-market for new offerings means even more to people.

But we tend to use "server virtualization" to describe these outcomes, and not too many people can connect the dots.  So you should.

On a side note, you'd be surprised how much easier a technology evaluation discussion becomes when you've precisely framed the outcomes you're looking for.  On a personal note, every time someone wants to talk storage virtualization, I ask what they're trying to get done, and -- more often than not -- there's a cheaper, easier way to get to the outcome.

Recipe Ingredient #2: Take a look at all your IT projects and initiatives.  Put all the jargon in the back.  Describe them in terms of business outcomes.  Then do it again, and make it even more relevant to outsiders.

Manage Your Skills Inventory

We're not talking focused technical skills here.  You can rent those when you need them.

We're talking about business skills. 

Communication. 
Cross-functional leadership. 
Project management. 
Resolving conflicts. 
Engaging senior management. 
Business analysis.

Business leadership can be found in any corporate discipline, including IT.  And if IT thinks of themselves as specialists, rather than business leaders, it'll be hard to make progress.

Recipe Ingredient #3: Take a hard look at your group's skills portfolio, and ask -- do we have business leadership here?  Are we qualified, motivated and capable to lead?   If not, what's the get-well plan?

Know Where You Are On The Journey

One of the most influential books I have ever read on the subject is "Enterprise Architecture As Strategy". 

Among many useful points in the book is a clear model of how IT evolves as the business evolves.  It's like raising kids -- there's no shortcut to adulthood, you've got to go through the process.

Understanding -- and accepting -- where you are in the IT journey is a useful and powerful concept.  Maybe it doesn't ease the frustration, but at least it explains it a bit.

Recipe Ingredient #4: Have a model for IT evolution.  Validate it with senior management.  Share it with your co-workers and IT leadership team.  It'll be a useful discussion.

Patience and Persistence

Organizations take time to evolve.  Foundations and capabilities take a long time to put it and make work. 

I've seen unpleasant situations where someone tries to drive change on an over-accelerated schedule, and the machine starts to fight back.  Sometimes applying more testosterone isn't the right answer.

I believe that substantive change is subtle, non-linear and pervasive.  Almost like a long-term virus. 

I tend to manage things in my world using two lenses -- what are the short-term, visible things that we've gotten done that everyone can see, and -- more importantly -- what are the long-term, substantive changes that we've put in place that are ultimately more important, but entirely invisible to most people.

Recipe Ingredient #5:  Have two goal sheets.  One that focuses on the usual short-term deliverables.  And another that focuses on substantive changes that take quarters or years to play out.  If you don't do the latter, things may never change in a substantive (and positive) way.

It's A Treadmill

Look, the honest nature of IT is that no one can be perfect, or anything close.  The business changes too fast.  The requirements change too fast.  The technologies change too fast. 

I've met some of the most prestigious IT organizations in the world.  Yes, some do far better than others, but no one ever gets near to closing the gap between ideal and real world.

Recipe Ingredient #6:  Have fun, and enjoy the journey!