Export (0) Print
Expand All
Separating DSL Semantics from Implementation
Expand Minimize
Bb402953.skyscrapr_banner(en-us,MSDN.10).gif

The President's Dilemma: Business and Technology Strategy Rationalization

 

Tom Bugnitz

March 2007

Summary: How does an architect get approval and money from a business executive? Not by being an architect, but by thinking like the executive. (3 printed pages)

Contents

Introduction
Speaking the Same Language
Supporting the Business Case
Lessons Learned and Takeaways
Critical-Thinking Questions
Further Reading

Introduction

How does an architect get approval and money from a business executive? Not by being an architect, but by thinking like the executive.

A friend of mine is the president of a university of about 5,000 students and considers himself a technology novice. He told me that the "Web guys" had come to him with a request for $100,000 "to buy a new set of Web development tools, so that they can redo the school's Web architecture."

"Why?" I asked.

"They said it's hard to make changes, like increasing security, scaling applications, reusing content—that kind of thing," he said.

"What else did they say?" I wondered.

"Nothing. That was their entire case. I do not know what to do. They obviously know more about it than I do. They said we really need to 're-architect' the Web site, so it's hard to say no, but it just doesn't feel right."

To help him understand what he was facing, I posed a number of alternate scenarios for him. "What if the head of groundskeeping came to you for $100,000 to upgrade lawnmowers, so that it was easier for his workers to cut the grass?"

"Nope, that's easy. It's not worth the money. It doesn't do a thing for the school."

"What if a faculty committee wanted $100,000 to upgrade classrooms for multimedia and Internet access?"

"I'd think about that one. That might be good. Better student and faculty learning experience, maybe."

"What if the Dean of Students wanted to spend $100,000 on a recruiting effort that would attract 15 percent more students next year, and the incoming students would have higher test scores and better high-school grades than the current average?"

"That's a no-brainer. More and better students are a main goal in my 5-year plan that the Board just approved. She gets the check before she leaves my office."

I challenged him, "So, where does upgrading the Web architecture fit into those three alternatives?"

"It sounds like it's closer to lawnmowers than getting better students," he said.

Case dismissed.

It's hard to believe that a smart guy with a PhD. would equate new Web tools with lawnmowers. But in this case, he was absolutely right, given the information that IT supplied to him. That was the main problem. The re-architect project might have made sense, but the information he was given did not.

Speaking the Same Language

Take a look at the "case" that IT made. First, they asked him to buy them something that he did not understand ("Web tools"). Second, they explained it to him in their terms, not in any words with which he could identify. (What does a university president know—or care—about "Web architecture?") Finally, the problem they presented was theirs, not his, and the benefits were for IT, not for him or even the university—at least, not in the way in which they presented it. Given those factors, it was not surprising that he was confused. And, given the alternate scenarios as other ways to spend money, it was clear not only why he said no, but how IT could have gotten him to say yes.

Think about the world from his perspective. He is running a complex enterprise that includes technology, buildings, teaching, administration, health services, food services, dormitories, and athletics. He is trying to keep students, faculty, alumni, and the government happy—in many cases, in situations in which you can only make one group happy at the expense of the others. His budget is inadequate, and the amount of money that he can spend on new things is limited. He is constantly being asked for money every day, and the amount of attention that he can spend on any one problem is fairly small. In this case, the $100,000 Web question was one of over 50 such discussions in which he had been that week. The time that he could devote to IT's request was small. So, how do we get attention for "architecture" things in such an environment? How did he make his decision?

Let's start to answer that question by looking at how business executives make technology decisions (and, really, most business decisions). In many cases, they are acting with "acquired ignorance." They want things explained simply, quickly, and in short sentences, and they want to remain somewhat ignorant of the underlying details. "Just give me the bottom line," so to speak. They do not want technology vocabulary to get in the way; that is just too complex for them. They do not want to have to learn anything new to make the next decision. They want to use the same decision process for technology as for everything else. Finally, they want it all to happen quickly, so that they can move on to the next thing.

As part of these decisions, executives understand a very basic economic principle: Money is money. The budget is a zero-sum game. A dollar spent on technology is a dollar that cannot be spent on other things for the business. Except for the government (and who wants to get into that?), all dollars are "fungible" and can be spent on whatever the business needs. The executive's job is to invest them in the things that will help the business succeed the most.

Which leads to another very simple—but very powerful—principle: Executives spend money on things that support the company's business strategies or the executive's personal business goals; they do not spend money on things that do not—period.

The main problem for technology people when dealing with the executive suite is that funding requests for things like infrastructure, architecture work, security upgrades, and so on are made on technology grounds, not business grounds. They are often presented as complex issues that need detailed explanation. There is no clear connection to the things that interest the executive. You need bigger servers; he needs higher customer-satisfaction numbers. You need upgrades to operating software; she needs faster product rollouts. You have a technical problem to solve; he doesn't care about your problems, he cares about the business's problems. All of the things that you must do—and for which you need approval and money—are obvious to you, and are clearly the right things to be doing. To the executive, however, they are anything but obvious. Your requests are competing with an enormous number of other ideas and projects for a limited pot of money, and they might or might not be the right things to do, from the business perspective. The bottom line is that if you want money from a business executive, you'd better be solving a business problem for him. You'd better be doing something that supports the company's mission. And you'd better explain it that way.

Supporting the Business Case

So, let's go back to our university president. What could IT have done differently?

The president has two hot buttons right now: increasing enrollment and improving the teaching experience for faculty. If the Web people need new tools, they must somehow relate their needs to those items. In this case, a new and very energetic Dean of Admissions had been hired and was anxious to use Web-based tools for recruiting, application processing, and communicating with prospective students. Additionally, a faculty committee was recommending that the university acquire a Web-based classroom-management tool for all classes and students.

Would the current Web architecture support either of these sets of tools? According to IT, not a chance. It would take 1 to 2 years to implement either one; and then it would be a kluge, at best. Did the president understand this? No. No one had put it together for him. When IT talked about a new architecture, they talked about what it would mean for them. They didn't relate it to the hot buttons. And why not? They did not know. IT had not stepped outside of its own domain to find out what the university was thinking about, what IT could do to help, and how to explain to the university decision-makers what IT could do to help them achieve their goals.

Had IT explained its request in terms of supporting recruitment or faculty teaching, the case would have made itself. Should the president have been able to figure it out? Probably not; that's not his job. But IT should have been able to make the business case for him.

Lessons Learned and Takeaways

To be successful, keep in mind that:

  • Money is money. Money spent on technology is not spent on other things that the business might need. Do not forget that you are competing for resources, and that you must have a strong case.
  • Business executives spend money on things that solve their problems, not other peoples' problems. Know what those problems are, and relate what you are doing to solving those problems.
  • You should speak in terms of what you are doing for the business. Technology is there to support the business. Be sure that you understand how it does that, and what the business gets out of it.

Critical-Thinking Questions

  • What issues is the business facing? What are the executives trying to get accomplished in the next 18 months? What are they spending money on, in the business?
  • What are we doing in IT that has any impact on those things? How is technology helping the business?
  • How do we communicate with the business executives? How much technical detail do we provide, and how much business detail?

Further Reading

Benson, Robert J., Thomas L. Bugnitz, and William B. Walton. From Business Strategy to IT Action: Right Decisions for a Better Bottom Line. Hoboken, NJ: John Wiley & Sons, 2004.

Keen, Jack M., and Bonnie Digrius. Making Technology Investments Profitable: ROI Roadmap to Better Business Cases. Hoboken, NJ: John Wiley & Sons, 2002.

 

About the author

Tom Bugnitz is the president of The Beta Group, a consulting company focused on strategic and financial IT management. Before going into consulting, he was a mainframe systems programmer for a number of large corporations and was director of computing for a large university. The Beta Group's Web site is www.the-beta-group.com, and Tom can be reached at Bugnitz@tbgmail.com.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.

Show:
© 2014 Microsoft