“They just don’t get it.”

How often have you heard that when people talk about the
relationship between IT and the business? It’s a sentiment expressed regularly.
It is expressed by the business.  And it
is expressed by IT. It can frequently feel like the two organizations are in a
bad relationship.

There are scores of articles on “aligning IT with
business.” Everyone stresses the importance of engaging with the business,
bi-directional communication, benchmarking, and many other often-repeated
buzzwords. And that’s all true.

It just isn’t always very practical.

As the CIO of a midsize company, I need results a whole lot
faster than that. We don’t have the luxury of being able to allocate a team to
“align each function with enabling technologies.” Maybe I can get an
hour with the business leaders to discuss some of these issues. Maybe. And then
everyone is going to go back to doing what they have to do to keep the business
running and growing. Crafting whitepapers on alignment strategies is most
definitely not on that list.

So what can be done?

One approach that results in immediate value is education.
Create an informal program to educate business leaders on why IT does some of
the things it does. This approach doesn’t require any takeaways or weekly
workgroup sessions. It isn’t a master plan to solve everything. What it will do is help the business, little by
little, understand IT’s perspective.

The reality is that IT and the business look at an
initiative very differently. And that’s good. They each have to focus on
different aspects. The business needs to be primarily focused on customers,
product differentiation, revenue targets, and the like. IT needs to be
primarily focused on architecture, stability, maintainability,
interoperability, and all the other “ilities.”

Pain point: Change requests

One situation I have run into a lot involves the business
asking for multiple features simultaneously. Because they don’t know much about
the development process, they can’t understand the impact all those change
requests have on our projects.

What seems obvious to the dev team (even concepts like
dependencies and source control), is completely off the radar of some business

I was working on a consulting engagement once where our
client had a bad case of change-request-itis. We were in the midst of a
carefully prioritized set of changes to a specialized retail management system.
The business lead came to me with a quick change.

“This would be something that we’d really like to see
go out immediately. And I know that it is a pretty minor change. It would
probably take only a couple of days to code, right? We can afford to give up a
couple of days on the next phase to have this now.”

He was right. Sort of. Taken all by itself, the change would
require only a couple of days to program (and some time for testing and
user-acceptance… something that this particular client always overlooked). But
he was requesting that this change be made at the same time as some other
changes to the same system. What he didn’t realize was that these affect each

I explained that the overall impact on the project would be
longer than two days (plus time for testing and user acceptance) because of the
dependencies between his small change and the larger initiative.

“Agile!” he said.

Okay, yes. We recognize that business needs change and that
a key precept of the agile philosophy is to “welcome changing
requirements.” But that doesn’t necessarily translate into efficiency. “That
change might have been two days (plus time for testing and user acceptance)
last month and it might be two days (plus time for testing and user acceptance)
next month, but it’s not two days right now.”

To help explain why, I used the metaphor of home
construction. I articulately explained how multiple projects could require
access to the same resources and how adding more workers didn’t necessarily
make a project easier. I then explained the different tools that software
engineers use to manage these problems. He left the conversation with a
stronger knowledge of software development and a full understanding of the
impact of his request.

Okay, that’s not entirely true. I actually fumbled through a
probably-too-technical explanation of what he was asking. He left frustrated
and confused. Full disclosure: I might have used the word “semaphore.”

But what I did next was prepare a write-up that went through
the explanation I wished I had been able to give from two paragraphs ago. I
walked him and some of the other business leads through it during a program
status meeting a few days later. And that actually did result in giving him a
stronger knowledge of the impact of requests and how their timing could affect

The presentation

I created a presentation based on that write-up and
discussion.  It explains some basic
concepts to our business leaders and stakeholders and demonstrates how requests
can sometimes be ordered differently and completed more efficiently. 

It covers some simple concepts:

  • What is “a build”?
  • What is “source control”?
  • Why are some changes dependent on each other?
  • How does that affect IT’s ability to deliver
  • Why can’t we just throw more developers at the

If your organization builds software of any kind, some — or
all — of this presentation will be relevant.

I kept the presentation fairly general so that it can be
customized for any organization. Some generic system names are referenced, and
I encourage you to replace those with names of systems from your environment
that your business leaders will understand. (If you happen to know how many
source files your applications encompass, there is a place to put that in, as
well. It is a somewhat meaningless number that can be very impressive.)

Feel free to modify the content and formatting to fit your
needs. Put it in your company’s PowerPoint template; put your corporate logo on

The presentation is also designed to address only a few
specific issues. My experience is that these knowledge-sharing efforts are most
productive when they are targeted. A likely follow-up topic might be agile vs.
non-agile approaches and the importance of early user feedback.

The goal of an educational session like this is not to turn
everyone into an IT person. The audience doesn’t need to come away as experts.
A major objective is to reinforce the understanding that IT’s decisions are not
arbitrary. They are based on best practices and are rooted in the desire to
deliver the most value to the business.

Simply getting that point across can make the relationship a
whole lot smoother.

About the author

Keith Faigin is the CIO of EHIM, a
health services company in the Detroit area. His 20 years of professional
experience have included positions as an executive, a consultant, and as the
founder of a startup company. Keith recently published his first novel, The Bone Eaters: Nick & Amato Investigation #1.