A Guide to Core System Operations from a PM's Perspective 1: Is the IT Department a "Handyman"? — Redefining Core System Operations from a PM's Perspective

Introduction to the Series

When working in IT department, requests like "Could you help me with this?" come in daily. From small setting changes to urgent investigations, and even consultations outside your jurisdiction. Before you know it, your day is filled with "responses," and it's not uncommon that the maintenance and improvement of core systems that you should be doing get pushed back.

This is not a special case, and many IT departments may be experiencing similar situations. I am no exception. While continuing to address the challenges in front of me, I have repeatedly thought about and sometimes nearly lost sight of the question, "What role should an IT department fulfill?"

The core system is not a project that ends with implementation. It can be described as a 'continuous project' that is shaped by daily operations, improvements, and the accumulation of small decisions. Looking back, the current configuration and operation are a record of the constraints, priorities, and field judgments of each moment.

In this series, from that perspective, I will organize and write about how we as an IT department perceive and manage core systems. The content will cover a wide range, from concerns and trade-offs felt in the field, design and operational thinking, to the background that led to the current configuration.

This series has two purposes. One is to share practical insights and concerns with those who are also involved in core systems. The other is to record how our system has taken its current form through an accumulation of decisions. This may be an attempt closer to a 'log of decisions' rather than a technical explanation.

I hope that this series, "Core System Management Records Decoded from a PM Perspective," will serve as an opportunity to consider "what are we protecting?" even while being overwhelmed by daily operations.

Characteristics of the Structure Surrounding IT Departments

The characteristics of the structure surrounding IT departments include the following:

1. (In many cases) Not a profit center
2. The most important role is to not disrupt other departments' work
3. Stakeholders span across the entire company, making them numerous

From these characteristics, IT departments:

• Have achievements that are difficult to see and evaluate (difficult to establish clear numerical indicators like sales)
• Have wide entry points for requests and consultations, making it difficult to prioritize them (which takes priority: requests from Department A, Department B, or Department C?)
• Find it challenging to increase staffing (because achievements are unclear and they don't generate profit)

This tends to position them as "handymen" who are somewhat difficult for others to understand what they do, difficult to evaluate, yet are the first to be consulted when there's a problem, resulting in a busy and hectic situation.

Looking at IT Work from a PM's Perspective

Looking at such IT work from a PM (Project Manager) perspective, its biggest feature is that "it never ends." Typically, a project is a temporary endeavor with a goal and an end. However, in IT projects, continuous operation itself becomes the project, so there is no clear end.

Of course, IT work also includes new feature development, and in that case, we set delivery dates. However, even after delivering those features, they don't just end; they continue to be operated and maintained. I'm responsible for cooking at home, and what I feel doing IT work is that it's similar to these daily household chores. There are deadlines (breakfast, lunch, dinner times), but it doesn't end there; you clean up, go shopping, and prepare the next meal. In between, there's cleaning and laundry (requests from other departments). If a light bulb burns out, you go buy one (emergency response). And these tasks repeat tomorrow, the day after, and so on.

From a PM's perspective, this endlessness is completely different from regular project management. Because there is no end, a gap between ideal structure and reality can easily emerge. In other words, IT work is characterized by the fact that daily responses and decisions accumulate to form a structure. It's similar to how your home doesn't look like an ideal model room. Certainly, we want it to be neat, functional, and waste-free. We want that, but we can't not live anywhere until it becomes that way, nor can we think deeply about it; our current state comes about while responding to the daily household chores that arise in our lives. That's because the main purpose of housework is to live comfortably.

Similarly, because the main purpose of IT work is to continue business comfortably, while pursuing the ideal as an ideal, it tends to become somewhat cluttered.

Therefore, we can say that core systems are made up of decision histories, not blueprints.

Redefining the Role of IT Departments

Now, I think you understand that IT departments are prone to becoming "handymen" structurally, but is that really what an IT department is? Moreover, should we be content with being "handymen"?

I think the answer is "No."

I believe IT departments can play the following indispensable roles in an organization:

• Not as a handyman (repairer) but as a stable designer, building business quality into the organization
• Not just handling tasks but as an operational designer, continuously improving the foundation of business
• Bringing a perspective of long-term stability to organizations that tend to fall into short-term optimization through coordination with multiple departments

In terms of offense and defense, it's defense. In terms of short-term and long-term, it's long-term. I think these contributions are what make IT departments great.

Above all, having diverse users right in front of you is a strong point. This means that if IT departments train themselves to have a business perspective, they can position themselves to accelerate the company's entire business.

Series Declaration

In this series, I plan to write about:

• The configuration of Classmethod's core systems
• Their historical background
• Reasons behind decisions
• Operational realities
• Approach to improvements

from both PM and technical perspectives.

This is not just about sharing knowledge but also recording our decision-making.
Therefore, I hope it will be valuable not only to those outside the company involved in IT and core system operations but also to colleagues within Classmethod as a log.

Summary and Preview of the Next Installment

Due to its role, IT doesn't stand out.
However, I believe it is an important role that supports business as the foundation of an organization and, if done well, has the potential to boost operations.
And also, I think the state of IT reflects the history of an organization.

What decisions have accumulated to form your core system?

I would be happy if you continue reading the next installments with such thoughts in mind.
In the next installment, I would like to write on the theme of how to manage a never-ending project, focusing on the PM perspective.