Roughly one year ago, I graduated from college. Lecture halls, tutorials, textbooks and case studies are now a thing of the past. Friends who are still studying often ask me, “Is your study very different from practice?” The only practical information during your studies are often the case studies in your textbook. And unfortunately, despite the authors’ efforts, these cases are not representative of practice. Take the companies used in the case study, they are mostly companies in the “state-of-the-art and innovative” category. Think Google, Facebook, Apple and Tesla. High-tech, ahead of the market, enthusiastic employees and virtually no constraints such as money and time. That the case histories from your textbooks differ from reality should come as no surprise, but how exactly?
First of all, industry practice is much more complex and difficult than I imagined during my studies. Very rarely the reality is like in the textbooks, where the organization starts by mapping the requirements and wishes of the stakeholders, draws up user stories based on these, determines functional and technical specifications and then develops something. Constraints (technical and/or financial) hardly seem to exist.
Although organizations try to achieve ideal scenarios like in the textbooks, the reality is often different. A clear project plan is drawn up and everyone enthusiastically sets to work. And then come the first surprises. For example, due to greater functional or technical complexity than expected, insufficient support or a changing project environment. As a result, the development of the new system takes longer and investments are higher. The phasing out of old systems takes longer, resulting in lower savings. The project seems to have reached a dead end and management demands improvement.
I experienced this myself on a project I was involved in for three quarters of a year. The project was a difficult implementation of a complex information system. For example, because of the migration of the existing database; after all, history should not be lost. In my experience, it can be very complex to complete a migration because of a lack of knowledge within the organization about the existing database. The database has existed for many years, the people who designed the database no longer work at the organization, and no proper documentation has been maintained. More the rule than the exception in practice….
Then there is the human aspect of organizational development. Subjects such as “Organizational Behaviour” and “Project Management” are often not the most difficult exams during your studies, but in practice these are usually the biggest challenges. Support among employees is essential but difficult to influence. During the project, almost every day I heard statements such as, “what a waste of money,” “people have been saying for five years that the information system can be implemented at any moment,” “we don’t want this, management wants this,” and the most frequently heard, “first see, then believe.” Yet employees are essential to developing a new information system. Without their input and cooperation, a project has no chance of success because the employees have knowledge of the work processes. The work processes must be captured in business rules (formal elaboration of the work processes, procedures and protocols that apply in an organization) in the information system. Without support, this knowledge will not surface and the project will fail.
Support within management is also crucial and cannot be taken for granted, even if management is your client. In practice, there is often a difference between saying and doing. Yes’ is not by definition ‘yes’, but regularly ‘maybe’ or even ‘no’. This happened recently during a meeting with a project leader and client about the preparation of a workshop. The purpose of the workshop was to evaluate their project and define objectives for the follow-up project. Because of the limited time available for the workshop, we, the consultants, emphasized several times that attention had to be paid to time. Of course, the client and project leader completely agreed with us. But on the day itself, the project leader gave a far too long introduction and an extensive product presentation was given by one of the project members, at the project leader’s request. Even before the workshop had actually started, the schedule had been skillfully killed by the project leader…. This, of course, immediately raises the question, “Does the project manager actually want a thorough evaluation of his project?” No, because the project did not deliver what was intended and the project leader did not want a thorough evaluation of his performance. So, the cooperation of employees, project leaders and clients is not a given. Not even when there seems to be agreement. The trick as a consultant is to respond to this in a handy way and to be flexible enough to deal with it. To do this, you have to recognize that there are interests, that you are working with people who have their own limitations and that you can stretch the context a bit but you can’t just change it. In addition, it is important to realize that a lot of influencing does not take place at formal moments, but rather via the informal route.
Another topic that the cases in textbooks do not address is the connection with other systems. There are virtually no business systems that are not linked to other systems such as the financial system, for example. The proper design, development and testing of links is a sub-project in itself. It becomes even more exciting when links are established with chain partners, which is increasingly common. Different databases, different business rules, different people and divergent interests.
Digitalization throughout the whole chain brings other challenges, as I recently experienced during another project. Suppose organization A buys a new information system that gives organization B better information at its disposal and therefore allows it to work more efficiently. This makes the chain more efficient, but will organization A do this? Most likely not because organization A incurs the costs but organization B receives the benefits. Conflicting interests that are difficult to resolve and are the rule rather than the exception in chain digitalization. Not to mention the complexity in terms of definitions, technology, migration and information standards, for example. These are the major challenges that organizations face in the coming years, and we as information experts can play an important role in them.
Going back to the question, “Is practice very different from theory?” Absolutely, but it is much more fun because of that! During my studies, I did not overlook the importance of existing systems and databases, support among employees, links to other systems and chain issues. You don’t learn that in a case study, you learn it in practice. And how do you deal with these challenges? Partly through an extensive analysis in the initial phase of the project. Only by understanding the current situation can you foresee what challenges you are going to encounter in the development of a new system. But a thorough analysis does not prevent you from encountering surprises on a substantive, technical, organizational and human level. That’s what makes the work of a consultant so fun and challenging!
