Who Bears The Responsibility?

Harald Rotter, Chief Information Officer at the University of St.Gallen

Harald Rotter, Chief Information Officer at the University of St.Gallen

In Switzerland, at least, it is called directors' and officers' liability. By definition, responsibility cannot be delegated. Thus, following the organization chart, it "moves" up the hierarchy. So far so unambiguous. And for, let us say serious cases, there is no big deal there either. It is, at least in my perception, relatively clear and unambiguous.

But how does it look when we look at the day-to-day business of an IT department? Is the CIO, at the highest hierarchical level in the department responsible for everything? Not only for system availability but also for all data and applications in use? Or, as is often the case at universities, for hardware and software procured independently, bypassing the central IT department? What about around agile working methods? Who prioritizes the projects and plans at the end? In theory, this is clear. The client, the customer, the business owner, the product owner, and so on.  Under no circumstances should this be done by IT. But the reality, in my perception, (too) often looks different.

Phenomenon 1: The Applications and The Data in The Business Units

No matter which "framework" is considered, the business applications normally are always the responsibility of the business department. In technical jargon, this means product ownership. Although the IT department often hosts these systems in the data centers, we have no in-depth knowledge of the functions required in the business. We are dependent on concretely specified orders from the business. So much for the theory. In practice, however, we often experience a different situation. Because it is an IT system, the IT department is not only responsible for its operation but also for its further development. And this is despite the fact that we hardly have any in-depth knowledge of operational processes, especially in larger organizations. By the way, I see the same thing with unstructured data (Word, Excel, PDF, etc.). Here, too, the responsibility for access rights is often blamed on IT. However, each employee is responsible for the data produced. It is not uncommon for me to see audit - findings regarding rights adjustments and the like. These and similar tasks cannot and must not be carried out by us. For this, we would first have to acquire editing rights and then set or revoke them. Here, too, attempts are made (often successfully) to shift the responsibility to IT. Incorrectly assigned or not revoked identities, or for example, setting an MS TEAMS channel “publicly” etc. are often seen as a mistake in IT. Although in many cases, depending on the system configuration, we probably have relatively little or no influence on this. We just provide “the tool”.

Phenomenon 2:  Work (Project) Prioritizations

In the classic project business, the issue can be managed fairly easily. Project resources are reserved for projects and the hours incurred are billed. Although there is often a bottleneck there as well, this can be partially managed by controlling project starts. In the area of internal operational IT, this is much more difficult. Safeguarding operations comes first, and projects and innovation initiatives are always secondary. Nevertheless, these tasks must also be completed, and in a certain order. So it's a matter of prioritizing.  Who does this now? Should the IT department prioritize or should the business do it? In theory, and my opinion, this should be done by the business departments. But as with the first phenomenon, this responsibility is still (too) often shifted to the IT department. And this, although we do not know about the respective effective time priorities. Only the business departments can define how time-critical their requirements are. If there are three prior-one projects in the backlog, but IT can only work on two of them in parallel, the business departments should agree on which work should be processed first. Not IT. In practice, however, we very often see that this responsibility ultimately ends up back with IT. This fact is not new. In my perception, however, it gets worse when agile working methods are used. Because in such a setting (e.g., big room planning from the SAFe framework), customer collaboration is assumed. Priorities are discussed together and defined for the next planning iteration. And this is where we currently see bigger challenges. Possibly it is due to too little training or a too short defined adaptation period. Currently, I see the responsibility being shifted from the business to IT. In my perception, it will probably take a long time of greater effort before IT is released from its often-uncontrollable responsibility in this area as well.

“No matter which "framework" is considered, the business applications normally are always the responsibility of the business department. In technical jargon, this means product ownership.”

For me personally, these two phenomena, representative certainly also of other topics, are neither good nor bad. I do not want to evaluate them, only describe them. It is largely up to the IT departments to help the respective business departments, to train them, and perhaps also to educate them better. Perhaps this will make the business more aware of their responsibilities. A constant exchange, a "mutual mindset" will help us to drive this transformation steadily forward. It will take the proverbial staying power. So rather the marathon than the sprint. Personally, I am 100 percent convinced that in the end, it will be beneficial for everyone involved and that we will add value to our organizations.

Agile