How to Evaluate Software by Navigating the Conflict Between IT and Operations

In my years I’ve learned that selecting the right software has very little to do with the best features and everything to do with navigating the invisible struggle between internal stakeholders.

When a transformation fails, it’s rarely because the code was buggy. It’s usually because the software served the incentives of one department while actively sabotaging another. To choose a system that actually sticks, you have to look past the demo and map out the conflicting motivations of your IT and Operations teams.

Here is how you should evaluate software based on the reality of internal stakeholder incentives.

Who Wants What?

Before looking at a single vendor, you must understand that success looks different depending on who you ask. In my experience, the friction usually boils down to two distinct worldviews:

• The IT Perspective: IT departments are incentivized to reduce complexity. Their win is a clean, standardized tech stack that is easy to secure, maintain, and scale. They favor technical purity by selecting a single ecosystem because it minimizes integration headaches and keeps the infrastructure predictable.
• The Operations Perspective: Business leaders are incentivized by agility. They don’t care if a system is technically pure or cloud-native, they care if it works for their specific workflow. Their win is the ability to pivot when customer needs or regulations change. They will fight for best of breed solutions because they prioritize functional excellence and flexibility over IT’s desire for a unified platform.

The Lesson: If you only listen to one side, you’ll end up with either a system that is easy to manage but useless for the business, or a powerful tool that IT can’t or won’t support.

Flexibility vs. Scalability

When evaluating a new platform, the most critical question is:

Where is the line between standard and custom?

Software vendors often push out-of-the-box best practices. From an IT standpoint, this is the fantastic, it’s salable and easy to upgrade. However, from a business standpoint, standard can be a death sentence if your competitive advantage lies in a unique, proprietary process.

You should evaluate software by testing its degree of elasticity:

• Can it handle our unique customer-facing secret sauce without breaking the core code?
• Is IT’s push for zero customization going to strip away the very flexibility that makes the business profitable?

A successful evaluation identifies which processes should be standardized (like back-office accounting) and which must remain flexible (like customer service or specialized manufacturing).

The Finance Friction

One often-overlooked incentive is how the software affects the balance sheet.

Modern IT is heavily incentivized toward OpEx through SaaS and cloud subscriptions. It’s modern, it’s cutting-edge, and it’s an annual cost. However, many operations leaders, especially in asset-heavy industries like manufacturing, are wired for CapEx. They are used to buying an asset, depreciating it, and sweating it for a decade.

When evaluating software, you must understand the CFO’s incentive. Moving to a cloud-first model might be technically superior, but if it shifts the financial burden in a way that hurts the company’s EBITDA or investment strategy, you will face silent, stubborn resistance from the top.

Avoiding the Technical Purity Trap

The most dangerous pitfall in any digital transformation is choosing technology for the sake of technology.

I’ve seen IT departments push for a cutting edge cloud migration even when the legacy on-premise system was performing perfectly for the business. Why? Because IT is incentivized to stay current with emerging trends to keep the organization’s infrastructure relevant.

To evaluate software correctly, you must ask: Does this solve a business problem, or does it solve an IT problem? If the legacy system just works for operations, but IT wants to move to a newer version that actually has fewer features, you are heading for a change management disaster.

Value operational performance over technical trends.

The Neutral Ground

Because these incentives are in direct conflict, you cannot delegate the software decision to a single department.

In my experience, the only way to navigate these conflicting incentives is through a balanced steering committee. If the CIO is the only sponsor, the project will lean toward technical purity and IT ease. if the COO is the only sponsor, you’ll end up with a fragmented, unmanageable mess of best of breed apps.

Success requires a neutral leader to step in and say:

This is our corporate strategy. Does this software choice align with our goals, or are we just satisfying the internal incentives of one department?

Final Thought

Evaluating software isn’t about the Cloud, AI or ERP. It’s about human psychology and departmental goals. When you understand that IT wants stability and Operations wants agility, you can stop fighting about the tech and start building a strategy that serves both.