Is it easier to get the business’s buy-in for a strategy rather than a specific product?

893 views2 Upvotes4 Comments

Vice President for Information Technology in Education, 1,001 - 5,000 employees
When I got hired, the first thing I was asked to do was put in a new ERP. We had a legacy system that was built by a consortium of Florida colleges and no group of schools should ever have been charged with designing their own ERP and student information system. As we started to move forward, it occurred to me that this was a good opportunity to talk about the architecture and technology that I wanted the board and others to understand, rather than discussing a particular solution, which is a one-time conversation.

We talked to our executive team and board of trustees about why APIs and real-time analytics were important. That proved to be incredibly helpful because our president really clicked with these concepts and every acquisition of technology, not just by me, but across the college. And with every new acquisition, he began to ask, “How does it integrate with the other solutions we already have?” That led us to rethink and adopt technologies that were API-driven and easy to integrate, so that we could put pieces together to do things we couldn't do before, which was great during the pandemic. Talking about architecture and the qualities of technologies was more beneficial than trying to get the business sold on one product’s ability to do something, because it leveraged us more in the future. We've had some missteps too, but the architecture solution has proven to be good going forward.
CISO in Software, 501 - 1,000 employees
I think the buy-in should always be for a strategy rather than a product. Because the solution should be about solving a business problem or getting a business outcome, not putting a specific product in place. If you put your argument around a product I feel there is a natural distrust from the audience that you have bought into a product before thinking about the business problem it will solve. You should always look at a range of products too as part of your discovery so that you can justify why you landed on a certain product. Great question.
Associate Vice President, Information Technology & CISO in Education, 1,001 - 5,000 employees
Not necessarily! If the business sees a product, they get to experience it in real time, touch / feel / use is very appealing to the business. They can see it in action and resonate.

The right approach, of course, is to work out the strategy and understand the business requirements and how it fits within the technology stack / enterprise architecture, but sadly this isn't always the norm as the business is often getting more involved on the tech side of things.

Vendors know this and will try to meet with the business without IT at the table...

It's like buying a puppy. No matter how many problems it has, good luck taking it back to the store once the kids have fallen in love 😬
Chief Enterprise Architect in Finance (non-banking), 10,001+ employees
Since you are looking to get buy in from business, I am making an assumption there is no ask from business about the specific product. 

I would start with situation, problem, why, and benefits, customer back, and connect to the solution / capabilities required .. and then provide options/products etc. So basically paint the picture of what problem, connect to strategy, goals and outcomes. Get buy in on goals, outcomes, metrics ... thats where I will get buy-in ... 

At times, it might be ok not to have all the outcomes or metrics nailed but at least directionally correct outcomes and metrics will help to get the conversation going and start iteration ... 

Content you might like

Understanding customer requirements21%

Communication with other stakeholders56%

Visibility of workflow13%

Agile development practices8%


2.4k views1 Comment