BART PERKINS: When you get started, you typically have IT doing everything. They are figuring out the costs, the benefits, the timing, the risks and so on. If you want to do it more thoroughly, you will bring in the business beneficiary — the executive sponsor or the group, organization or individual — who will benefit most from the new system. If it’s a financial system, you are bringing in the CFO or some senior finance person to figure out the business problem, what the new system should do, the objectives, scope and benefits. They are the only ones who can define the benefits. IT can’t really define the benefits. If the project requires that there is a reorganization and people get laid off, IT can’t reorganize a sales or manufacturing group and reduce the head count and get the benefits.
To get more sophisticated, I would bring in the finance group because I’d want a financial model. It should include the one-time project costs. There may be one-time benefits. For example, if you are doing a supply chain program, it’s not uncommon to find that you can cut inventory levels by millions of dollars. There will also be ongoing operating costs and benefits. If I have those four things, I can calculate an internal rate of return or whatever financial metric the company uses. Now I’m in position to compare that investment with other investments available to the organization.
To get even more sophisticated, I’ll bring in the internal audit team because they will help me set the metrics to measure the project’s benefits and compare the current state with the future state before we actually implement the new project.
The real objective is to create a business case you can take to the executive committee. Typically, you will have 20 to 30 potential investments that different people or groups want to make, so the job of the executive committee is to sort through those and say: Which ones have the highest returns to the shareholders? Which ones have the best use of corporate funds? Some may have heavy IT components. Some may not. We are trying to make those trade-offs.
PERKINS: Each group has a distinct role. IT will look at the technical pieces and cost. They’ll talk about feeds and speeds. We need this much storage, bandwidth, processing power and so on.
The business people will talk about what the project is going to do and how it will change the business. How manufacturing or sales will change. They will also define the acceptance criteria: How do I know the system is ready to go into production? Is it really going to produce the benefits we thought it was going to produce? You have to have somebody give the “go” or “no go” on actually cutting over. So the business people will be there.
Finance is in there. They are helping with the financial modeling, both on the cost and benefit side. A risk team might be there for risk mitigation. An internal audit team might be there for specific metrics for pre- and post-project audits. Have a single business case template, not 10, because if you have one template with one way of analyzing projects, then you can look at them consistently across different parts of the business.
PERKINS: Have a well-defined process and a single business case template built around data, not passion and energy. I think passion and energy are fine, but when you are trying to do this, you want to make it as analytical as you possibly can.
Sometimes people are so excited. I’ll pick marketing or sales because they are so outgoing and tend to be extroverted and less concerned than, say, accountants are with numbers. They will come in and tell you how great it’s going to be. They have plenty of passion and energy that this will blow your socks off and be wonderful. They may not have the same discipline as accountants have in going through all the numbers.
It is important to go through the numbers to find the best, highest benefit. I’m reminded of the Edwards Deming quote, “In God we trust, all others bring data.” That’s the one I think about when I’m thinking about how to do a good business case.
PERKINS: The business people have to go all the way through the process. Up front, you’ve got them defining what the system is going to do, and as you go through any project, you really want the same people in the room making the decisions.
I would have a project steering committee for a good-sized project because they will monitor progress, cost, time and quality. With a big project, even if it’s broken up in small phases, somebody somewhere will come along and say, “Tell me one more time why we are doing this,” and question things. And you want the steering committee to be the cheerleader. The steering committee will remove roadblocks and make trade-offs. Any project always has trade-offs that come up.
You will find that some guy over in a related department may not think the project is a priority. He or she will say, “I’ve got to do this other work that I’ll do first and put the project second.” You want your steering committee to be the ones that tell him or her, “No, in this case, you have to work on the project.”
PERKINS: It’s the same team all the way through. It’s basically consistency. You need people from the team looking at the next release. And as we migrate to the cloud, it’s going to be even more important than in the past.
In the old days, with software packages that you install and run, you would be on a version, and when new releases come out, you would have a choice whether to install it because it’s running on your server. With new cloud-based systems, you don’t have a choice. When a cloud system says we are upgrading, they just do it. You can’t go back and operate the system from a year ago.
People on the team have to figure out what the implications are for their particular organization. Then they have to do any training that has to be done. They also have to figure out the implications for related systems and figure out if there are any new policy or procedure changes that go along with the new release.
PERKINS: First, change the language from “IT project” to a “business project that’s enabled by IT.” It doesn’t roll off the tongue, but that’s what it really is. It’s first and foremost a business project.
Second, anytime you put in a new system, there will always be skeptics. There are two kinds. There’s the skeptic who thinks, “If we do this, I’m going to have a smaller role post-project. Therefore, I want to kill it if I possibly can.” With these skeptics, you have to sideline them one way or another.
Then there are the loyal skeptics who really want it to work, but they want to understand the project first. They tend to be analytical and want lots of data. But once you convince them it’s a good idea, they will help you a lot. Really embrace these people. Answer their questions because as soon as you do, they will become your biggest defenders.
Third: Empower the staff to throw the flag. That’s a football analogy. In some organizations, you hear, “Failure is not an option.” Well, failure is always an option. You don’t like it. It’s not pretty. It’s not something we want to consider, but if the project is going off the rails, the sooner you know it, the better the chance you can get it back on the rails.
So make sure that people working on the project feel they have the power to come to the head of the project and say, “I’m uncomfortable with X, Y or Z, and I don’t think we’re going to make it.” I go into organizations periodically and find that if people question if we are going to make the deadline, they basically shoot the people who do that. You have to have enough trust in the organization, so that people will tell you what they honestly believe.
At Leverage Partners, Perkins has helped clients save more than $300 million in technology spending over the past six years. He’s the former CIO of YUM! Brands and Dole Food.