How to get your executives to buy into innovative IT projects

As excited as we all get about the latest trends in tech – iOT, big data, cloud, etc. – our peers may not share this enthusiasm when it comes to allocating cash to implement them. But as the CIO, your job is not only to keep the business running – it’s also to innovate; to show the C-suite, the board, and the marketplace ways of running a business, developing products, and providing insight they didn’t know were possible.

How can you, as the CIO, influence these decisions to get the cash and influence you need to do things that will actually move the needle?

There are three basic phases of getting buy-in:

1. Build credibility
2. Build the case
3. Demonstrate success

1. Build credibility

Keep the business running smoothly and efficiently

For better or for worse many still believe the CIO’s primary responsibility is to keep the business running efficiently, at minimal cost. This may or may not be true based on your business, but we need to acknowledge this is likely the viewpoint of at least some of the people you need as allies.

Make no mistake, 90% of your credibility is effective execution.

To build allies across the leadership team, you need to show them you’re interested in their priorities. Make sure your IT operations house is in order. For most companies this means committing to security, limiting downtime on critical revenue-focused systems, and keeping your user satisfaction rates reasonably high. If you already have some large projects running, be sure to maintain strong leadership and oversight at the top, as I wrote about here.

2. Build the case

Develop a strategic technology roadmap and, for most projects, a business case

I wrote about this recently here. Suffice it to say, I believe the strategic roadmap can and should be your most powerful ally.

The concept of a business case is sometimes interpreted as an extensive exercise to estimate the benefits and costs in dollars and demonstrate definite monetary benefit for a project. For some projects this is appropriate and you should spend time and money building a strong quantitative business case.

Not every project is a good candidate for this type of business case but that doesn’t mean you should eliminate this step altogether. Qualitative business cases – a clear narrative description of expected benefits – can also be powerful. To maximize the effectiveness of this type of case, the key is to be specific about cause and effect. For example: “This tool will increase the effectiveness of our salespeople by enabling them to access all opportunity data from the field. This will be done with a set of apps that is as intuitive as those they use in their personal lives.” Quantifying this type of benefit would be mostly guesswork but explaining the benefits in enough detail will still build your project’s case.

Ultimately, expect to track each benefit you include in the project’s justification so be careful what you’re willing to assign dollar values to.

Highlight benefits, but also address risk and how to control it

If you were to use traditional sales tactics you would focus on all of the great things a new solution can offer and downplay any areas you were worried about. When selling internally, however, you need to treat the potential downsides with a great deal of respect. At least some of your decision makers are prioritizing risk management.

Openly addressing the risks will demonstrate that you don’t see the solution as a panacea, that you acknowledge and are prepared to work hard to avoid negative consequences, and that you value the perspective of your risk-focused peers.

Avoid the “Blackbox” explanation

We all espouse the benefits of “cloud,” “the Internet of Things,” “virtualization” and the other latest trends in technology. The CIO-centered thought-sphere is full of stories about the transformational potential of these technologies and we integrate their names into our every-day language quickly.

The challenge for us is to not let our people, our vendors, or ourselves get too attached to the terminology and let the names themselves become the solutions. We’ve all done this – analytics will fix our understanding of customer purchasing behavior; SOA – that will solve our file transfer issues; cloud will help us avoid these costly upgrades.

The reality is the name of the technology does not terribly matter and it risks painting the solutions as purely IT-owned. What matters is the problem you’re trying to solve, specifically how a new tool will help solve it, and how the business needs to support it. It’s a subtle shift, but an important one.

3. Demonstrate success

Test, pilot, iterate

Piloting new solutions is one of the best ways to obtain buy-in. While strong testing will generate important feedback it’s nearly impossible to account for every important use case prior to deploying the real solution. Choose an area of the business where you have strong allies, great executive buy-in, and ideally a flexible and adept user base, and pilot your solution for some time before rolling it out widely.

One of the best outcomes of pilots is they can get the rest of the organization excited about what’s coming. Additionally, a pilot will build the solution’s credentials with the rest of the business, demonstrate a low tolerance for risk, and let you and your organization learn enough to be even more successful for subsequent rollouts.

Is it that simple?

Sadly, no. Ultimately, success will breed success. If you deliver one or two projects that are seen as both innovative and successful it will be much easier to achieve buy-in on the next one. But following these tips will make getting the first one done easier, and it will credential you personally as someone who can take important strategic risks and make them pay off for the company.