Ain’t Nobody’s Business But Your Own

February 1, 2016 Dan Burger

The distance between the IT department and the executive suite in some IBM midrange shops makes a trip to Mars seem like a hop, skip, and a jump. How do you close that gap? How do you explain to the decision makers the difference that IT can make within the organization? You know what could be accomplished with investments in IT, but executive sign off on IT strategy never materializes. You’re spinning your wheels.

You want to get traction? Build a financial foundation for the project. That’s easy to say, but harder to do. You’re going to need help. Going after project approvals on your own only adds to the degree of difficulty. Presenting your ideas to the person who holds your fate in his or her hands takes a different skill than if you were explaining them to your staff over coffee and donuts. For one thing, you probably will need to learn another language. No, not Java. Not HTML, either. It’s the language of business. Anyone who relies on geek speak to make presentations to a non-geek speaking audience will not fare well.

So what would work well? Let’s turn to someone who has been successful in getting projects approved and consider his advice. Beware though, Jim Oberholtzer is a consultant. For some, that’s reason enough to be skeptical. Oberholtzer couldn’t agree more. Healthy skepticism is totally appropriate.

Don’t let Oberholtzer manage the project for you. His job, as a consultant, is to sell hours of his time. He told me that himself.

“When you have a consultant running the project, with the responsibility for managing it, there is no incentive, outside of personal pride, to bring the project in on time and on budget. The incentive is there for just the opposite,” Oberholtzer advises. That’s neither a confession nor a statement about how he does business. It’s merely advice for those who turn to consultants for advice and then turn over the keys to the house.

Take into account, however, that Oberholtzer has more than 30 years of experience helping companies deliver IT projects. Many of those have been completed after he helped build the business case for them on the front end. It makes sense that a consultant would have more practice than most IT managers at scoping projects and talking with executives about why the projects make sense.

Oberholtzer recommends three books containing insights into business decision making. “Orbiting the Giant Hairball” is his favorite.

One key to success, he says, is to identify the root cause of the problem that needs to be solved. Then it’s possible to determine the action that needs to be taken.

“Most don’t do that,” he says. “They treat symptoms. It’s easy to find symptoms to treat. For example: Users don’t like the green screen because they have to navigate four screens to get a task done when they could do it with a single screen. The root cause is the application is not efficient in the way it does transactions. It’s about the process of getting an order in, getting the shop order though, and getting the shipment done. It’s about streamline this process and saving money. If the project does not result in making money, you are not going to get money to fund the project.”

Return on investment is another important factor because it requires quantification. It could be that the sales department projects a 20 percent increase in revenue because the IT project allows customers to order parts online as they need them. That’s a benefit that generates more revenue. It could also reduce the cost to process the orders by reducing the dependency on order entry or customer service staff. Consequently, the staff can be assigned other tasks in profit-making processes. After the project has been running, it may be discovered that errors in shipments have been reduced. IT needs to take credit for its quantifiable accomplishments.

Cost savings discussions are much more powerful and persuasive than technical discussions.

“When you talk to the business-level people, they don’t care about how much cache is on the chip. They don’t care that IBM has the biggest cache controllers for I/O. What they want to hear is how to make money with IT,” says Oberholtzer, the CEO at Agile Technology Architects.

That doesn’t rule out all tech talk.

In situations where IBM i on Power is going up against Windows/Intel, demonstrating the hardware equivalencies is a money issue that Oberholtzer does not shy from. He’s been in a lot of these battles and says there’s a track record of projects that were planned for a four-core Intel box running Windows, but ended up with four to five times as many cores to handle the job when all is said and done. He’s also adamant about claims that Windows environments that run more than a single application are common. In reality, he says, it’s more common to see Windows Active Directory on one box, a secondary AD server on a second box, SQL Server on another, and the IIS web server on another box. The number of applications that can run on a box and the number of boxes it actually requires to handle a given project is understood by non-technical executives when the true costs (hardware, software, and maintenance) are attached.

Emphasizing business benefits is Oberholtzer’s strongest advice, and that’s done by steering clear of technical dialogue and learning how to talk in terms of business advantages. Most IT managers, who have come up through the ranks of the IT department, are very good at explaining technical features and functions. They have to learn business feature function.

“I’m a natural geek,” Oberholtzer says. “I slide into techno-geek without even thinking about it. I have to remind myself when I’m standing in front of executives that I can’t talk tech. I have to be at a business level with them.”

So how do you switch from a tech brain to a business brain? You can’t just flip a switch. Often you have to get some help to figure it out.

“I once thought the hardest thing I’d done in my career was to go from a procedural programmer to becoming an object oriented developer. I had to take my head off, shake it, spin it around, and put it back on again with a different mindset. The transition from tech to business is equally hard if not harder,” Oberholtzer warns.

To gain valuable insights into how the business brain works, he suggests sitting in on classes at a local business school. Most instructors will allow a little bit of this without enrolling in the class. Find a class with a financial analysis focus. It will become clear what your executive management really cares about.

Oberholtzer recommends three books: Selling to VITO (The Very Important Top Officer) by Anthony Parinello; The Question Behind the Question by John G. Miller; and Orbiting the Giant Hairball by Gordon Mackenzie. Each provides unique insights into the inner workings of the business-minded brain and advice for honing your business plans and executive presentation skills.

There’s a large confidence factor involved with the technical to business mind shift. There’s awkwardness and uncertainty. Success doesn’t come easy. It comes with planning. You need a plan to modernize old code, to rework databases, to regain the competitive advantages that have been built into your system over time, and preserve valuable investments rather than toss them away. But it all has to make business sense. Business sense becomes common sense.

“I’ve found the way people get success is to realize CFOs are data-driven people. So you tell them, ‘Look, I can give you all the facts and figures you need to make a good business decision, but you have to give me the time to do it. And that means sacrificing something,'” Oberholtzer says. A CFO understands that.

And one final piece of advice from Oberholtzer: “Just because it’s green screen doesn’t mean it’s not making you money.”

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search