Managing the Operation of Core Systems from a PM Perspective 2: Managing Never-ending Operations with Annual Planning

Do you ever find yourself thinking, "I didn't complete anything today" while working in IT systems administration?

Working in IT systems or managing core systems is a peculiar job.
Unlike projects, there is no clear "completion." You can't stop it, nor can you finish it. It's work that must be managed with the assumption that it will continuously move and change.

When trying to handle these never-ending projects with conventional project management thinking, problems inevitably arise. The metrics for progress and achievement become ambiguous, making it difficult to see "what constitutes success." As a result, teams tend to constantly feel overwhelmed.

This is where the concept of "accounting" becomes useful.
Accounting is designed with the assumption that organizations will continue indefinitely. The company will exist next year. Under this premise, artificial fiscal years are established to check results and make new plans. It's this artificial segmentation that makes never-ending activities manageable.

Core system operations can be approached the same way.
While assuming perpetuity, set themes and key initiatives for each fiscal year. Importantly, don't fill your schedule completely with planned activities. In reality, unexpected issues and investment decisions will inevitably arise. Therefore, deliberately reserve about 40-50% buffer, designing operations to accommodate "unplanned" work.

This isn't poor planning—it's a practical structure for managing never-ending projects. Having fiscal year boundaries while leaving room for change. This balance is key to stable long-term operations.

In this article, we'll organize how to design and review never-ending core system operations from a project management perspective using this fiscal year accounting approach.

The Reality of Never-Ending Projects

IT system administration work is like housework—it occurs daily and never ends.
Therefore, trying to manage it like normal development projects by requirements or functional units can be either overengineered or impractical.

Conventional project management is designed with the assumption of clear "beginnings" and "endings." Define requirements, determine scope, and complete deliverables by a deadline. When completed, it's one phase done. Evaluation is straightforward, and the definitions of progress and success are relatively clear.

In contrast, core system operations have no "completion." Improvement, maintenance, adjustment, and inquiry responses continuously occur. Fixing the scope is difficult, and unexpected tasks regularly intrude. In other words, trying to apply conventional project management frameworks directly creates a gap with reality.

This gap leads to IT systems staff burnout. Plans collapse almost immediately, priorities frequently change, and as never-ending work accumulates, it becomes easy to doubt whether anything is being managed properly.

However, this isn't actually an issue of individual capability or effort, but stems from the nature of the work itself being "never-ending operations." Thus, unless the management approach changes, the same exhaustion will repeat.

Can Work Without Goals Be Managed?

Humans struggle to handle work without goals (completion). This is because, as finite beings, we can't properly conceptualize infinity. Work without beginning or end is beyond human capacity.

Most importantly, without endings, evaluation becomes impossible. This isn't about external evaluation—it means we can't even establish checkpoints for self-evaluation of work. To evaluate, we need temporal boundaries. And naturally, without evaluation, we can't sense progress, so the feeling of "moving forward" disappears. People cannot endure tasks without a sense of progress. You can imagine the pain by considering eternally piling stones at the riverbank of Sai—the torment becomes immediately apparent.

Therefore, core system operations are extremely difficult to handle as finite project undertakings. Forcing this approach will inevitably result in exhausted team members.

Introducing the Accounting Mindset

In fact, there's a familiar world that manages while assuming perpetual continuation: corporate management activities. Businesses evaluate their performance through accounting, consisting of financial statements. In accounting, it's assumed that companies will exist forever.

This is known as the "going concern" principle. It's necessary because, for example, fixed assets like buildings can be expensed through depreciation assuming business continuity, but if we assumed company bankruptcy, they would be valued at disposal value, potentially becoming zero in some cases.

Incidentally, currencies like the Japanese yen operate similarly. Currency has value because people collectively believe it will maintain value eternally. This becomes clear if you imagine whether you'd value the Japanese yen the same if it might become worthless tomorrow.

I digressed. Anyway, corporate management assumes no ending. To effectively control and evaluate such endless business management, accounting establishes artificial goals called fiscal years. In other words, instead of segmenting by activities, it segments by time periods.

Fiscal Year Design as an Operations Framework

When segmenting by time periods, any range would technically work, but aligning with fiscal years like management plans is recommended. This is because IT systems activities should already have budgets allocated by fiscal year within management plans. Synchronizing these is generally convenient. Of course, after segmenting by fiscal year, further dividing into quarters is also beneficial.

After segmenting time periods, determine what to accomplish within each period. The important thing here is to follow the principle of "One Term, One Issue". Realistically, including minor matters, there are countless things you'll want to address. However, experience shows that satisfactorily handling all of them is impossible. As mentioned repeatedly, IT systems work never ends, and task-level work flows in daily. Under such circumstances, trying to do everything will inevitably leave everything half-finished.

Therefore, ideally set just one initiative per fiscal year. At most, three. Then, set exactly one milestone for each initiative per quarter. It helps to express this in a single sentence. In practice, since multiple team members will share work on one initiative, each member will need to establish goals further divided from these initiatives. Even then, keeping these few and expressible in single sentences is beneficial.

Buffer Design Saves Reality

Things don't go according to plan. This is an inescapable truth since humans cannot predict the future. So, are the annual and quarterly goals we just established meaningless? The answer is both Yes and No. Plans and goals serve as landmarks. During the execution phase, amid various unplanned events and troubles, they help us keep sight of where we're heading. That's why we shouldn't set too many—too many landmarks cause confusion.

Now, given that we know things won't go according to plan and unpredictable events will occur, what's the optimal solution for somehow achieving our goals?

The answer is to maintain flexibility (buffer).

For example, if you're going on a date by car where being late is absolutely not an option:

• Leave home early with extra time
• Maintain safe following distances with buffer to avoid accidents
• Consider several routes beforehand with contingency planning

The same principles apply to IT work.

So how much buffer should we allocate?

From experience, IT systems work requires a minimum buffer of 40-50%.
In IT systems where tasks constantly flow in, including minor ones, it's somewhat "miraculous" if you can dedicate even 50% to your original goals. This becomes easier to imagine when thinking about planning a trip while managing household chores. In such cases, wouldn't it be a triumph to allocate even 20% to trip planning? This further emphasizes why we must limit the number of plans and goals.

PM Thinking for Sustained Operations

Unlike conventional project PMs, IT systems PMs must focus not on "operating" projects but on "continuously operating" them. Simply put, continuity takes precedence over optimization.

The finest ingredients, perfect cooking, exquisite taste and nutritional balance, menus optimized for family health conditions... it's impossible. It's impossible for someone who must provide meals every day. It's impossible for someone with numerous responsibilities beyond meal preparation. More important (?) than perfection is being able to provide meals again tomorrow. That's the point.

This doesn't mean never pursuing optimization. Rather, short-term optimization doesn't take priority over long-term continuity. Of course, we undertake gradual, continuous improvements. However, such efforts presuppose continuity.

There's probably a phrase that many IT systems engineers strongly dislike:

"Why not just rebuild everything from scratch?"

Look, we can't just stop everything. There are various reasons things are the way they are. We're not in a position to fully understand all specifications. We're well aware things aren't optimal, but we've somehow managed to reach this point.

Would you say such things at home? Saying something like that is essentially like saying "things aren't optimal, so let's remake the family from scratch"... That's grounds for divorce, you know?

IT systems PMs must prioritize continuity while keeping an eye on goals set at the beginning of the period, gradually improving their surroundings. To repeat, this requires completely different abilities from conventional development project PMs. Specifically, controlling improvements becomes the primary approach. This is because, to do anything while maintaining continuity, improvements are the only option, and by implementing improvements, we can hope to secure resources for our goals.

Conclusion: Creating Boundaries for Never-Ending Work

We've discussed how IT systems work never ends. Therefore, segmenting by time periods rather than by activities is effective, buffers are crucial, and PM thinking that prioritizes continuity is important.

Annual design is not a goal but a "framework to make management possible." Breaking down never-ending operations into visible units. The accumulation of these eventually becomes a stable improvement cycle.

Next time, we'll explore how this "design for continuous operation" manifests in actual core system configurations. Current configurations didn't happen by chance but are accumulations of past decisions and practical constraints. We'll unravel these backgrounds and organize "why things are the way they are now" from a PM perspective.

Is your operation designed with the premise that it "never ends"?