When it comes to making fundamental changes to a business, speed trumps everything, says consultant Jack Bergstrand. Indeed, the firm of which he is CEO is called Brand Velocity, for its focus on helping companies in reinvention mode accelerate their time frames.

Bergstrand is no stranger to personal reinvention, either. In a whirlwind career at assorted Coca-Cola entities, he held successive executive management positions in marketing, distribution, manufacturing and logistics, finance (as CFO of Coca-Cola Beverages Ltd. in Canada), and information technology (as vice president of business systems for The Coca-Cola Co.). After all that change, he left the company in 2001, still young at 43, and hung out his shingle as an IT and project-management adviser.

Bergstrand’s ascension to CFO came in 1995, after he took some time off to attend Stanford Business School. But his headiest job at Coke was the IT role, in which he oversaw a billion-dollar SAP implementation and restructured the company’s global systems and data-standards operations. Those projects, completed in a year and a half, provided a crash course in speedy implementation. “So that it would not take forever, we made key steps quarterly, which is pretty quick for an organization the size of Coca-Cola,” he says.

Bergstrand sat down with CFO this week to talk about his views on organizational change and the challenges confronting IT organizations. An edited version of the interview follows.

What in your background qualified you for that big IT job?

IT reported to me when I was CFO in Canada, and in fact I had had close relationships with IT since my distribution job, which involved putting together a lot of systems that had never been envisioned as being together. The manufacturing and logistics job had a heavy systems component, too. By the time I was CFO I was pretty comfortable with IT.

What is the key to doing major IT restructuring well?
It’s having a clear vision of what you’re going to do — and not do. When SAP went live, I was asked to combine the SAP and IT organizations, which were separate. There are really two ways to do that. One is that you take SAP and move it under IT, which seems reasonable. Unfortunately, what often happens is that although implementing a new ERP system is a major investment, when you go live, a majority of your transactions and talent is [still] dedicated to legacy systems. If you just keep the IT structure in place and throw on the new ERP system as a wing on the house, then you’re probably not going to get the most out of the investment.

The other way is to build a new foundation for the house, keeping a very consistent vision for what the structure is going to be and why. But you have to be very careful in how you go about the restructuring. At Coca-Cola there was a lot of duplication in the [SAP and IT] camps, but also a lot of knowledge.

In your book Reinvent Your Enterprise, which was published last year, you wrote that many companies fail to realize the difference between information and knowledge. What did you mean by that?
To address a problem, you [need to] bring in people who have different information and skills. That’s what creates knowledge: it’s more of a social activity than an information-systems activity.

A lot of companies go down the wrong path by competing on analytics, where data is seen as the Holy Grail. Let’s say you’re changing your supply chain. Information isn’t going to drive that change. What will drive that change is a social construction that puts together people who oversee distribution, manufacturing, IT, sales and marketing, and finance.

A lot of technology projects, about 70%, fail to deliver what was intended. It’s usually not the technology itself that fails, but rather the way people work together to move from point A to point B.

Your firm’s Website says, “Velocity is what we stand for, by being experts in accelerating organizational results.” Why the focus on speed?
Because the competitive world is continuing to accelerate. To keep up or move up, you’ve got to be fast. Where success or failure happens is in the ability to make a change. Changes require projects, which need to be accelerated.

We often come in on large technology-project failures, where it’s important to get stuff done very quickly. Say you’ve got a major software project that’s costing $100 million. The normal way of looking at that is to say, it’s $100 million, so we’ve got to make sure we get it right, so let’s take plenty of time. But it’s not really a $100 million project; it’s a $100,000-per-day project. And what’s happening per day is that people are busy making trade-offs, they’re going to meetings, there are too many decision makers; all of those things bog you down. You end up doing the wrong things for the right reasons.

So how do you achieve acceleration?
We start with a sort of Myers-Briggs approach, using a tool we created to understand what’s driving the individual, the team, and the company. Normally all of that is invisible, because it’s in people’s heads. Once it is made visible, it’s much easier to put together a game plan for doing the project in an accelerated way.

Normally when you get a project team together, people start to fight, because they’re all different. Maybe what drives you is analysis, and what drives me is relationships. If there isn’t a framework that puts us on the same page, I’m going to battle you on the weaknesses of the analytical approach, and you’re going to battle me on the weaknesses of schmoozing too much. Finally, people give up fighting and really become a team, but it takes a lot of time.

The process of understanding up front that all this storming will be going on, and building a project methodology that incorporates where you’re going and why, what you’re going to do and when, and who’s responsible for what, results in much faster projects at lower costs.

What other major IT challenges do companies face?
One of the biggest is around governance. You’ve got a lot of people fighting for priorities, and a lot of internal energy is absorbed in trying to get projects on the table. A lot of times IT organizations try to please as many people as they can, so they do more things but do them slower, even the most important ones. Then nobody’s happy.

In the IT world, you hear a lot about aligning with the business. That’s a fundamental problem, because IT needs to be integrated with the business, not aligned. There’s a big difference [between the two]. Integration requires trade-offs: one system is chosen over another, and therefore one person loses to another. Alignment is often just about trying to make people happy. With ERP projects, it’s not uncommon to have more than 100 people in steering committees and subcommittees. That never works. It gets bogged down until somebody says “enough,” and then it takes more of a turnaround mind-set. Then people aren’t aligned anymore; they are integrated, and making decisions faster and getting stuff done.

What’s your best advice for a CFO who is taking on oversight of IT?
The CFO and the CIO need to speak the same language, but they typically don’t. They should jointly put together a game plan in business language, and seek a common language for the rest of the organization as well. Then they won’t be fighting each other, which is what happens when they don’t look at the world in the same way. Typically the CFO is trying to cut costs, and the CIO is wishing he reported to the CEO.

Technologists are notoriously bad at speaking in English. Some of that is just the nature of the function, but I think some of it is also a protection mechanism. It makes the IT function seem so specialized and complex that nobody from the outside dares touch it [for fear] it will fall apart. I do think that if a CIO is working for you as the CFO, then you need to spend the time not to learn IT, but to get on the same page as to where the company is going and where IT fits. That’s a discussion that can be held in business language.

Even when it comes to some technical areas, like how the networks will work or what hardware platforms to use, it’s better if it is based on a clear strategy that is in business language. And the CFO doesn’t need to know a lot about it, any more than the CIO needs to know a lot about treasury.