“Leaving IT to the Experts” Creates a Fatal Stalemate in Management Decision-Making

The Invisible Chasm Between “Delegating” and “Abandoning”

“IT should be left to the experts.”

You hear this phrase from executives almost every day. On the surface, it seems like a healthy attitude with clear role division. However, this is precisely where the fundamental reason lies for why Japanese companies’ IT investments fail to yield results. The problem is not the act of “delegating” itself, but rather skipping the crucial “definition” that management must perform beforehand.

Having observed the operations of over 38 companies as a management consultant, I see a common pattern. It’s a structure where the management team outsources the definition of the objective function—”why is this SaaS needed?”—to the IT department or external vendors, rather than deciding “which SaaS to introduce.” As a result, implemented tools become fragmented across departments, data becomes impossible to integrate, and return on investment becomes immeasurable. This is no longer “delegation”; it is an “abandonment of judgment.”

A Concrete Example: The “Goal Substitution” in Sales Support SaaS Implementation

At a mid-sized company, the introduction of a new CRM (Customer Relationship Management) tool was decided to improve sales department productivity. The management team only indicated a policy of “wanting to strengthen sales.” The selection was entirely delegated to the IT department and the sales manager. Consequently, a “user-friendly, ready-to-use cloud-based CRM (e.g., Salesforce or HubSpot)” that heavily reflected the sales team’s voice was chosen.

Six months after implementation, the “visualization of the sales pipeline” and “analysis of win rates” that management wanted to know had barely progressed. Instead, the activity management of individual sales representatives became more detailed, only increasing data entry burdens. Why did this happen?

The reason is clear. The “purpose” that management should have defined was substituted at the operational level with “means.”

• The Purpose Management Wanted: Building a “reproducible and analyzable foundation for sales activities” for decision-making (= Management IT)
• The Purpose of the Means Chosen by Operations: “Simplifying individual activity management and record-keeping” for operational efficiency (= Operational IT)

These two are not mutually exclusive, but their priorities and investment focus are entirely different. The moment management delegated the choice of means without defining the purpose, the more vocal operational goal of “ease of use” took precedence, and management’s goal of “improving decision-making quality” receded.

The Pitfall of “Ease of Use”

A trap that managers, especially in SMEs, often fall into is making “ease of use” or “speed of implementation” the sole evaluation criteria. Certainly, user resistance is a major cause of implementation failure. However, prioritizing “ease of use” as a management decision means placing “short-term friction avoidance” above “long-term strategic value.”

In the previous example, what if management had defined, “The primary purpose of this CRM introduction is to improve the accuracy of quarterly sales strategy decisions by 20%,” and presented “the ability to aggregate the stage and estimated deal value of all opportunities in real-time” as a mandatory requirement? The selection criteria would have significantly shifted from “ease of use” to “data integrity and reporting functionality.”

The “Three Moments” When Management Steps Back from IT

So, at what moments do executives unknowingly halt their judgment? Primarily at the following three moments.

1. The Moment of Budget Approval: Not Defining “How to Measure Effectiveness”

“Approve a budget of 5 million yen (~$31,500 USD) for CRM introduction to improve sales efficiency.” Countless approval documents like this exist. What is fatal here is that the definition of “how to measure effectiveness” is often missing. If effectiveness measurement ends with “user satisfaction surveys” or “reduction in input time,” it remains an evaluation as an “operational efficiency tool” and does not become a management investment decision.

The Question Management Should Define: “Which decision-making process will be improved by this investment, by which metric, and by how much?”

2. The Moment of Requirements Definition: Not Deciding “What to Give Up”

No perfect tool exists that meets all requirements. Budget, timeline, features, customizability—choosing one thing means giving up another. Management tends to delegate this “trade-off” judgment to technicians or vendors.

For example, a requirement like “We want to fully systematize our complex quotation workflow” implies significant custom development, inflating implementation cost and timeline. If management had made the judgment, “In that case, let’s first focus only on the main workflows manageable with standard features, and continue managing complex parts with the current Excel for the time being,” the project’s scope and definition of success would be entirely different.

3. The Moment After Implementation: Not Updating the Definition of “Success”

Once a tool is implemented and operation begins, management’s attention shifts to other new challenges. However, the true value of IT investment is created not by “implementation” but by “utilization.” Three months, six months after implementation—is the initially defined “success” being achieved, or does the “definition of success” itself need to be reviewed according to changing circumstances? If management withdraws from this continuous evaluation process, the investment ends with just “the fact that it was implemented.”

Practical Framework: Translating IT Decisions into “The Language of Management”

To place specialized IT discussions on the table for management judgment, translation is necessary. Use the following framework to break down your next IT-related agenda item.

1. Verbalizing the Purpose: Dig into the “Why,” Not the “What,” in Three Stages
Example: In response to a proposal to introduce a new project management tool (e.g., Asana)
・Surface Purpose: Want to visualize project progress (Means)
・Core Purpose: Want to early detect resource conflicts between multiple projects and allocate appropriately (Operational Issue)
・Management Purpose: Want to achieve concentrated investment in high-profitability projects with limited human resources and improve gross profit margin (Management Issue)

2. Clarifying Decision Criteria: The “Must-Haves” and “Nice-to-Haves” Decided by Management
“Must-haves” are requirements absolutely indispensable for achieving the management purpose. For example, “Must be able to view integrated with other departments’ resource usage.” “Nice-to-haves” are desirable requirements but can be substituted by other methods if absent. This includes UI aesthetics or detailed notification features. If management does not perform this separation, all requirements carry equal weight, and selection loses direction.

3. Pre-setting Evaluation Metrics: Decide “How to Measure” Before the Investment
Set quantitative evaluation metrics *before* the investment, such as “Reduce the average deviation rate between project plan and actuals by 15% within six months of introduction” or “Identify the monthly occurrence of resource overallocation and report quarterly.” This positions implementation not as a “goal” but as the “start of an experiment.”

The Correct Way to “Delegate” to Experts: Hand Over the Purpose, Delegate the Choice of Means

This article does not deny reliance on IT experts. Rather, it proposes the correct “way to delegate” to maximize their expertise.

What management should do is clearly define the “Purpose,” “Constraints (Budget/Timeline),” and “Definition of Success,” and then, within that framework, delegate the selection and execution of the optimal “means” (which tool, how to implement) to the experts. This is the polar opposite of a blank-check “abandonment.”

CTOs, IT departments, and external consultants can propose creative solutions within a clear framework of purpose and constraints. However, if the purpose is ambiguous, they are forced, often unconsciously, to make proposals optimized for “metrics by which they are easily evaluated” (e.g., system stability, low user complaints). This is the structural cause of misalignment between IT and business departments.

Reclaiming IT as a Decision-Making Apparatus for Management

IT transcends being a mere tool for operational efficiency; it is the most powerful “decision-making apparatus” in the modern era. It provides the foundation for collecting data, analyzing it, and predicting the future. If management does not draw the first line of this apparatus’s blueprint, the organization falls into a state of having data but no insight, tools but no strategy.

The next time an “IT topic” comes up in a meeting, first ask yourself: “Am I about to delegate the choice of means, or am I about to abandon the definition of the purpose?” Drawing that line is the first and most crucial step in transforming IT into a true management resource.