4.5IT investment management & solution use

Whether IT investment is skillful is not decided solely by whether each project is good or bad. Within a limited investment budget, the overall design of how to balance the whole company's portfolio of investments—how to allocate defensive investment that supports stable operation and offensive investment that grows and transforms the business—sways management. This section covers managing the whole company's IT investment as an IT investment portfolio, program management that bundles multiple projects toward a strategic benefit, the planning and requirements-definition processes of the common frame (SLCP) that is the shared language of the upstream, and the direction of procurement such as cloud/SaaS use and in-house vs. outsourced—framed as the strategist's judgment of balancing the risk and return of investment under budget constraints.

4.5.1IT investment portfolio and program management

• The IT investment portfolio classifies the whole company's IT investment into categories of differing character—maintenance/operation (Run = defensive / low risk, low return), operational improvement/growth (Grow), and business transformation (Transform = offensive / high risk, high return)—and allocates within budget constraints, balancing risk and return. Like a financial portfolio, leaning too defensive loses competitiveness, while leaning too offensive lacks stability.
• Program management, beyond individual projects (the object of project management), bundles and manages multiple related projects toward realizing one strategic objective or benefit. Even if each project completes (succeeds) on schedule and within budget, if the bundled strategic benefit is not realized the program fails—its viewpoint is on the outcome (benefit), not the output (deliverable).

4.5.2The common frame (SLCP) and solution use (cloud / in-house vs. outsourced)

• The common frame (SLCP-JCF) is a framework for sharing the work content and terminology of the software life cycle between the acquirer and the supplier. What an IT strategist is mainly involved in is the most upstream—the planning process (systemization concept, systemization plan) -> the requirements-definition process—where fixing requirements aligned with the business objective sways the success of downstream processes.
• The cloud/SaaS use strategy does not cling to in-house development or ownership: standard operations use SaaS for fast, low-cost introduction, concentrating the company's own investment and talent on areas that are a source of differentiation. The in-house vs. outsourced judgment is made on the axis of whether the operation is a source of competitive advantage (strategically important, with know-how to accumulate internally) or generic (an external standard solution suffices)—not decided by cost comparison alone.

A mid-sized company's IT strategist is about to bring to the management meeting how to allocate next year's IT investment budget. The budget is limited, and the field has raised three kinds of request: (1) renewing the aging core server (essential because all company operations stop if it goes down; the effect is maintaining the status quo), (2) streamlining the existing ordering process (a certain labor-saving effect is expected), and (3) launching a new subscription-type service leveraging collected customer data (a new revenue source if successful, but highly uncertain). What the strategist must not fall into here is allocating by near-term safety alone—"(1) is top priority because it is a problem if it stops, do (2) with the remainder, and shelve (3) because it is uncertain." That is a portfolio biased toward maintenance (Run), lacking growth (Grow) and transformation (Transform), and although safe in the short term, it carries the risk of losing competitiveness in a few years. What is appropriate is to grasp (1), (2), and (3) as investment categories of differing character and to balance risk and return within the budget constraint. Secure the minimum necessary for (1) as defense (Run) (without over-gold-plating it), allocate a certain amount to (2) as steady-return growth investment (Grow), and make (3) a high-risk, high-return transformation investment (Transform) with a stepwise allocation—starting small and adding investment after seeing results rather than pouring in the full amount at once—this is portfolio thinking. Next, in realizing the new service (3), the strategist judges in-house versus outsourced. The deciding factor is not merely low cost. If the new service's customer-data analysis logic will be a source of the company's competitive advantage, it should be built in-house to accumulate know-how internally even at some cost. On the other hand, generic functions that do not contribute to differentiation—authentication, billing, notification—are reasonably procured quickly and cheaply via cloud SaaS, concentrating the company's own investment and talent on the differentiating area. Further, if realizing (3) does not complete within a single project but spans multiple projects—building the data platform, developing the service, and constructing the sales structure—program management is needed to bundle them under the strategic benefit of "establishing a new revenue source." What is crucial here is the viewpoint that even if each project completes on schedule and within budget, if the bundled strategic benefit (the new service actually generating revenue) is not realized, the program is unmet. Thus, judging from the viewpoint of the balance of company-wide investment and the realization of benefits, rather than the acceptance of an individual project, is the strategist's core role in IT investment management.

4.5.3Section summary

• Balance Run / Grow / Transform under budget constraints via the IT investment portfolio (over-weighting Run loses competitiveness)
• Program management bundles multiple projects toward realizing the strategic benefit (outcome)—individual completion alone is not success
• The planning and requirements-definition of the common frame are the upstream core for ST; in-house vs. outsourced is judged by whether it is a source of competitive advantage or generic (not by cost alone)