Acceleration
Yes, what does an IT department do for the company it’s part of? And specifically, from a business perspective? At first, my initial serious suggestion was, “The IT department supports the business.” At a glance, that seems reasonable, but “support” is a passive term. My second thought was therefore, “The IT department accelerates the business.” That was much better, because it highlights the department’s true value.
I’ve written about acceleration before, so this idea shouldn’t come as a big surprise. But consider the opposite: suppose the IT department were slowing down the business—would the organization still want to spend money on it? Let’s be honest—no organization would. So it’s all about acceleration. And by “acceleration,” I mean doing things faster, doing them better, at lower costs, with less complexity, and with fewer errors. Isn’t that what organizations expect from IT? Combined with the four generic tasks of the IT department, the following picture emerges.
Maintenance
The vast majority of an IT department’s efforts involve “maintenance.” Keeping existing functionalities up and running. No new functionality is introduced; instead, they maintain what’s already there. Think of it like car maintenance. You expect everything to function optimally again after maintenance, but you don’t expect a car stereo to suddenly be added. The IT department prefers to perform this “maintenance” function as efficiently and cost-effectively as possible. After all, nothing new is being created. You could compare this to maintaining a certain level—a ceiling, if you will. The “ceiling” is the maximum achievable; you can only perform worse than that. That’s why the core of “Maintenance” is “Efficiency.”
Projects
In my view, another important task of an IT department is “Projects.” After all, new functionality is implemented through projects. So while “Maintenance” is about reaching the “Ceiling” (and thus revolves around “Efficiency”), this is about raising the “Ceiling,” and the core focus here is “Effectiveness.” Why? Well, of course we want projects to be completed on time and within budget, but if they don’t add value (if they don’t accelerate the organization), then it’s still a waste of effort. For example, a project that is delivered later than agreed upon and may have been more expensive than budgeted, but which does accelerate the organization, still has value. “Effectiveness” is therefore more important than “Efficiency.” In the car example, you could think of installing a tow hitch. That has nothing to do with maintenance but adds a new function—the ability to tow a trailer.
On the Radar
The third function of an IT department is what I call “What’s on the Horizon” or “What’s on the Radar.” These are topics that the IT department may need to address in the future. They could include new technologies, business changes such as acquisitions, or changes in laws and regulations. This task presents two challenges. The first is: Can we successfully determine whether a topic will become important to the organization? For example, we might think a topic will become important, but in hindsight, that turns out not to be the case (Type 1 error), or we might think a topic isn’t important, but in hindsight, it actually is (Type 2 error). If we’ve managed to avoid these two types of errors, we still have another “hurdle” to clear.
This “Hobbel” is what’s known as the Eisenhower Matrix. This matrix has two dimensions: “Importance” versus “Urgency.” This results in four combinations. Once a topic has been deemed relevant (i.e., not a Type 1 or Type 2 error), the question is whether we can include it on the roadmap. Usually, topics that are urgent take priority, regardless of whether they are important. Topics that aren’t urgent but are important are postponed. In the example of the car, for instance, we can see that electric driving is the future. We want to prepare for that. So we might decide to install charging stations even before everyone is driving electric cars. That’s important. If we wait until electric cars are already on the road, we’ll be too late to install the charging stations.
This “On the Radar” function of the IT department is very difficult to carry out due to the challenges mentioned. The key is “relevance.” Correctly identifying relevant topics is the key to success.
Decommissioning
The final function within an IT department is the “decommissioning” of outdated technology and applications. Why is this an important function? Outdated technology and applications require a great deal of maintenance and therefore consume a disproportionately large portion of the budget. Furthermore, old or outdated technology often has security issues that require a lot of work and pose a risk of disruption. It is therefore wise to phase out old technology as soon as possible. Not too soon—because that would harm the organization—but certainly not too late either. In short, the essence of this role is “timeliness.” Using the car example, this could involve phasing out (selling) a gasoline-powered car because electric vehicles are the future.
If you're reading this, you're probably wondering how these four functions relate to each other in terms of the percentage of effort. I wondered that, too. Grok helped me out with this,
– maintenance 55% to 70%,
– Projects: 15% to 25%,
– On the Radar: 10% to 20%, and
– phasing out of legacy technology 3% to 10%
Incidentally, here’s another reason why “Maintenance” is all about “Efficiency.” It’s by far the function that requires the most effort. Improving efficiency here yields the greatest returns.
In practice, “decommissioning” will be a project or part of a larger project. For example, if an application is being replaced, it makes sense to include the removal of the old application as the final step in that process.
“Maintenance” imposes restrictions on “Projects”
Now that the core functions of the IT department have been identified, we can “test” the model. Is it useful? Does it provide insight? The first thing that stands out is that the results of the projects end up in “Maintenance.” So, the faster or more successfully we deliver project results, the more maintenance work there is to do. Consequently, more of the budget goes toward “Maintenance.” And as a result, we’re then able to undertake fewer projects. There is, therefore, a negative feedback loop between “Maintenance” and “Projects.” That’s an interesting insight.
The four main tasks follow a kind of “flow.” Items “On the Radar” eventually become projects. The results of those projects end up in “Maintenance,” and after several years, they are disposed of (“Decommissioning”). In effect, this is a “product life cycle.”
Factors Affecting the Budget
Many IT departments are currently facing budget constraints. Sometimes budgets are “frozen” or even reduced. The question then becomes: How can we make room for projects—since accelerating business growth remains essential? I see a few possibilities here.
The first option is to get the budget increased after all. Sometimes that works, if the business case is strong or if the business interest is so significant that it’s justified.
One alternative, for example, is to cancel projects or postpone them. This is a relatively easy solution that is often chosen. The problem with this is that it doesn’t help the organization move faster. It works for a while, but as soon as we start falling behind the competition, it’s too late. It is, therefore, only a temporary solution. There is another factor that underscores this. Management contracts are always long-term agreements. They are difficult or impossible to terminate early. That is why projects are the first to face budget cuts.
Another logical option is to carry out “Maintenance” more efficiently. This frees up budget for projects. This is why “Efficiency” is at the core of “Maintenance.” IT issues related to efficiency improvements therefore always pertain to the maintenance function of the IT department.
As a last resort, I see the phasing out of outdated technology, applications, and technical debt (“Decommissioning”). This reduces the maintenance effort and, consequently, the strain on the budget.
DevOps?
Many companies today operate according to the DevOps approach, in which the team is responsible for both software development and its management. This is also referred to as “You build it, you run it.” Does this contradict what was described above? No, these are two tasks assigned to the same team. The development work is essentially an ongoing project, or a series of smaller projects (we often call these “Sprints”). As for maintenance work, it too must be carried out as efficiently as possible. Maintenance work literally comes at the expense of development hours. A major advantage of DevOps is that the same people feel the operational consequences of their development work. DevOps therefore increases the likelihood of developing smart software with minimal operational impact. And that is desirable.
What about security?
Can this model help us gain insight into the topic of security? Most security topics relate to “Maintenance.” This is because both the effort required to maintain security and much of the work resulting from security incidents draw on (the budget for) “Maintenance.” Security is therefore primarily a “Maintenance” matter. There is, however, one exception. What could security look like in projects? That’s where “Secure by Design” comes in. And that’s smart because it makes it easier to maintain the security level after delivery (and thus during “Maintenance”). Less work and, therefore, lower costs. It is therefore certainly worthwhile to include security as a specific topic in a project. The same applies to “Decommissioning.” Why don’t we design systems during the project phase so that they can be decommissioned with minimal effort? A sort of exit strategy for the application.
Technical Debt
I’ve often seen clients struggle with outdated applications and technology. They had to spend an excessive amount of time on “maintenance,” and sometimes the application could no longer even be properly maintained—for example, because upgrades had become impossible. The latter is a source of security issues. In short, technical debt causes problems, slows things down, and places an excessive strain on the budget. The question, of course, is: How can I prevent creating tomorrow’s technical debt today? And just as with security, the answer lies in the projects you undertake. Can you design projects (and technical solutions) in such a way that you limit future technical debt—by design? I believe so. For example, by eliminating all manual tasks and by incorporating the maintainability of applications as a design criterion.
A good “design” question, then, is: Will my application be maintainable once I deliver it? And what will my colleagues need to be able to maintain it efficiently? That means thinking today about tomorrow’s maintenance challenges. I can assure you that those challenges are all about efficiency.
The obviously simple question
If you’re still reading, I hope that answering this obviously simple question will be enlightening for you as well. For me, the (business) operations of an IT department now make much more sense. I now understand how and why groups of tasks are organized the way they are and how they influence one another. That we see a “Product Life Cycle”-like “flow” in the tasks. I’ve tried to “test” the model, so to speak, with a few examples—to see if it provides us with insight, and in my opinion, it does. I’m sure there are more examples to consider. The model is in place; make the most of it.
