Acceleration
Yes, what does an IT department do for the company it’s part of? And specifically, from a business perspective? My first serious answer was: “The IT department supports the business.” At first glance, that seems reasonable, but “supporting” 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 work involves“maintenance”—keeping existing functionality up and running. No new functionality is introduced; instead, the department maintains what’s already there. Think of it like car maintenance. You expect everything to work just as it did before after the service, but you don’t expect a car stereo to suddenly be added.
The IT department performs 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 do worse. That’s why “efficiency” is at the heart of “Maintenance.”
Projects
In my view, another important responsibility 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 help the organization move forward), then it’s still a waste of effort. For example, a project that is delivered later than agreed upon and may have cost more than budgeted, but which does help the organization move forward, still has value.
“Effectiveness” is therefore more important than “efficiency.” In the example of the car, you might consider installing a tow hitch. This 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 can 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 an issue will become important to the organization? For example, we might think an issue is going to become important, but in hindsight, that turns out not to be the case (Type 1 error), or we might think an issue isn’t important, but in hindsight, it actually is (Type 2 error). Once we’ve managed to avoid these two types of errors, we still have another “hurdle” to clear.
This hurdle is called the Eisenhower Matrix. This matrix has two dimensions: important and urgent. That 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, urgent matters take priority, regardless of whether they are important. Matters that are not urgent but are important are put on hold. In the example of cars, for instance, we can see that electric vehicles are the future. We want to prepare for that. So we might decide to install charging stations even before everyone is driving electric vehicles.
That's important. If we wait until electric cars are on the road, it will 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, 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 “timing.” In the example of the car, we might consider 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.
Projects 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 project results end up in “Maintenance.” So, the faster and more successfully we deliver project results, the more maintenance work there is to do. Consequently, more of the budget goes to “Maintenance.” And as a result, we’re then able to undertake fewer projects. So there’s 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.”
Impact of the budget
Many IT departments are facing budget constraints these days. Sometimes budgets are “frozen” or even reduced. The question then becomes how to make room for projects—because accelerating business growth remains a priority. 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 is: it doesn’t make the organization more agile. 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 therefore the rationale behind 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 decommissioning of outdated technology, applications, and technical debt. This reduces the maintenance effort and, consequently, the strain on the budget.
What about 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, the same principle applies: it must be done 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-related topics pertain to “Maintenance.” Both the effort required to maintain security and much of the work following security incidents draw on the “Maintenance” budget. Security incidents draw on (the budget for) “Maintenance.”
Security is therefore primarily a “Maintenance” matter. There is, however, one exception. After all, what could security look like in projects? That’s where “Secure by Design” comes in. And that’s a smart approach 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 be properly maintained. This was due, for example, to the fact that upgrades had become impossible. The latter is a source of security issues.
In short, technical debt causes problems, slows things down, and puts too much strain on the budget. The question, of course, is: How can I prevent myself from creating tomorrow’s technical debt today? And just as with security, the answer lies in the projects you undertake.
Is it possible to design projects (and technical designs) in a way that limits future technical debt—by design? I think so. For example, by eliminating all manual work and by incorporating the maintainability of applications as a design criterion.
A good “design” question, then, is: Will my application be maintainable once I’ve delivered it? And what will my colleagues need to be able to do that efficiently? That means thinking today about tomorrow’s maintenance challenges. I can assure you that those challenges have to do with efficiency.
The obviously simple question
If you’re still reading, I hope that answering this seemingly 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 certain groups of tasks are organized the way they are and how they influence one another.
We see a “Product Life Cycle”-like “flow” in the tasks. I’ve tried to “test” the model, so to speak, using 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 come up with. The model is ready; make the most of it.
To find out what SUE manages for you and what your team will continue to handle on its own, visit the page Managed Services. The guide to outsourcing IT management will help you make that decision.
