Getting Your IT Projects The Executive Stamp of Approval

image for 'Getting Your IT Projects The Executive Stamp of Approval' | CAT.Models.Category

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.

EXCERPT:

There are three basic phases of getting buy-in:

  • Build credibility
  • Build the case
  • Demonstrate success

1. Build credibility

Keep the business running smoothly and efficiently

[...] 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.

2. Build the case

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

[...] 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.

Avoid the "Blackbox explaination [...] 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

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.

Building credibility

Have you had success with projects or pilots of this scope before? Do the day-to-day operations suffer if you're fully immersed in a new project? Proving that a project won't be a detriment to the organization can go a long way to gaining the approval of others--especially if those others would be gaining additional work or responsibilities while your project is in progress.

Building the case

Building a case and pilot for any technology endeavour, whether it be replacing destkop software with a SaaS, outsourcing hardware management, or shifting to a new operating system can ease the pitch when you take it to you the leadership team.

Depending on your organizational requirements, a good practice I've had in the past is to use the goals or KPIs of your organization when building your business case: If a pillar of your company (or department) is to provide efficient communication with customers, then how does {business case} benefit that pillar?

As Steve mentioned in his article, finding cross discipline advantages (and selling those advantages) can also help with buy-in.  How does this project benefit another department? Would this new technology's ROI lower the spend somewhere else?  Make allies and partnerships with internal customers and demonstrate how a technology can be beneficial to those internal customers and the buy-in will follow.

Demonstrating success

Piloting in a specific cohort, gathering data, and iterating is where it's important to "fail early, fail often."  As with everything, there's a limited scope of what failure can be, but quick iterations on a pilot group, showing growth/innovation, and contintious improvement will reduce the aversion internal customers have with a new product rollout.

One example I've had was rolling out a piece of testing software to almost 30,000 internal PCs during a tiny window each year.  Each year, we iterated on the process--the packaging for the software, the steps required for onsite technical staff, the steps required for onsite teaching staff, failovers for the process, etc. Year 1 was a bit of a disaster--a lot of headaches, reinstalls, and a few borked computers, but that knowledge made Year 2 almost seamless with additional automation, better instructions, and a hands-off restore process in the event of failure.  By that point, the case study for those rollouts was etched and we could refer to that as 'how we roll out software.' No longer did those customers cringe when it was brought up--they looked forward to how we could optimize the experience next time.

 

  • projects
  • approval
  • executives
  • management
author photo - David Longnecker by David Longnecker

Comments

Stay Connected