What Does an IT Planning Department Actually Do? — From Building Systems to Deciding What to Build

Wait… I’m the one moving to the “client side”?

It was my eighth year with the company.

Until then, I had spent most of my career building systems.

I gathered requirements, designed systems, developed them, tested them, and released them.

When one project ended, I simply moved on to the next.

That was the work I had been doing over and over again.

Suddenly, I Was Moving to the “Client Side”

At the time, I was working on the vendor side, receiving orders from another company.

I had seen several people around me being assigned to the companies that were actually placing the orders.

“Huh. So that’s another way of working.”

That was about as far as I had thought about it.

Then, one day:

“Yamaguchi-san, we have an opportunity for you to be assigned to another company.”

My heart skipped a beat.

So, it was finally my turn.

But when I heard the details, it was different from the assignments I had seen before.

I was going to be assigned to the client side.

“The client side?”

“The side that places the orders?”

“The side that plans the systems?”

My head was suddenly filled with questions.

My position was clearly going to be very different from what I had experienced before.

From “Building Systems” to “Seeing the Whole Company”

Fortunately, there was a predecessor in the position.

So, the first thing I did was listen carefully to what my predecessor had to say.

That was when I gradually began to understand what an IT Planning Department actually does.

Its job is not simply to build systems.

You need to understand the current state of IT across the entire company.

What systems are already in place?

What risks exist?

What needs to change in the future?

In other words, rather than looking at individual systems, the role was about looking at IT from the perspective of the entire company and thinking about where it should go next.

The major projects had already been completed.

So from that point on, management and governance would become a major part of the job.

At the same time, we also had to start planning the next generation of projects.

“Okay… this is completely different from what I’ve been doing.”

Little by little, I began to see what the job was really about.

Two Years Felt Surprisingly Long

There was one rule about this assignment.

My predecessor had spent two years in the role.

And I would spend two years there as well.

No matter what happened, the assignment would end after two years.

“Two years…”

Honestly, it felt a little long.

Most of the projects I had worked on until then lasted anywhere from three months to about a year.

For someone who was used to moving from one short-term project to another, staying in the same place for two years felt strangely long.

But when I thought about it more carefully, I realized there would be plenty to do.

Understand the company’s overall IT landscape.

Identify and manage risks.

Coordinate with vendors.

Organize the needs of management and the business.

And think about the next IT strategy and projects.

“Will I actually be able to make an impact?”

That uncertainty was there.

And there was another thought.

This was a temporary assignment.

“Do I need to make sure my own company benefits from this as well?”

I found myself thinking about all kinds of things.

The IT Planning Department: “The IT Team That Doesn’t Just Build Systems”

But strangely enough, I felt more excited than anxious.

Until then, my focus had been on building systems.

Now, I would be on the other side, thinking about why the company should use a system and how it should evolve.

An IT Planning Department is not simply a department that orders systems from vendors.

It is a department that connects the future of the company with IT.

Once I saw it that way, two years no longer seemed too long.

In fact, perhaps two years was exactly what was needed to understand the company as a whole and think seriously about its next move.

My eighth year with the company.

After years of building systems, I was now moving to the other side—to the side that asks:

“What should we build in the first place?”

That assignment became a major turning point in my career as an IT engineer.

And that experience later became an important foundation for how I approached DX and IT strategy.

I can do this! Let’s take the first step tomorrow.