Denica 2.0 and Tactical Management Information System (TMIS)

Abstract

Middle managers are often operating in complex and fast-moving environments, resulting in having to deal with enormous challenges in a short span of time, maneuvering diverse and numerous “givens” and aiming to achieve specific goals. These challenges are very diverse and require support tailored to the needs and characteristics of middle management. Due to the lack of tailored tools, middle managers often use methods that were originally designed for strategic or operational management, which they then adapt as best as possible to fit their tactical management needs. We thus see middle managers as the prototype of managers that have tactical management responsibilities, even though tactical management issues are also faced by executive, operational, and project managers. In a fast-changing world, heavily impacted by globalization and digitization, adaptability is one of the most essential characteristics of a middle manager. However, because of the lack of methods and systems tailored specifically to the tactical management level, middle managers are often not sufficiently supported to be able to deal with numerous givens, unpredictability, and a dynamic, turbulent, and complex environment. Hence, they lack proper support for being adaptable.

Graphical Abstract

1 Introduction

Middle managers are often operating in complex and fast-moving environments, resulting in having to deal with enormous challenges in a short span of time, maneuvering diverse and numerous “givens” and aiming to achieve specific goals. These challenges are very diverse and require support tailored to the needs and characteristics of middle management. Due to the lack of tailored tools, middle managers often use methods that were originally designed for strategic or operational management, which they then adapt as best as possible to fit their tactical management needs. We thus see middle managers as the prototype of managers that have tactical management responsibilities, even though tactical management issues are also faced by executive, operational, and project managers. In a fast-changing world, heavily impacted by globalization and digitization, adaptability is one of the most essential characteristics of a middle manager. However, because of the lack of methods and systems tailored specifically to the tactical management level, middle managers are often not sufficiently supported to be able to deal with numerous givens, unpredictability, and a dynamic, turbulent, and complex environment. Hence, they lack proper support for being adaptable.

To address the lack of tactical management tools, the DENICA artifact (Petrevska Nechkoska, 2020) was designed. This artifact consists of a managerial method designed to support the individual in facing the abovementioned challenges, with the goal of achieving a set purpose. It is founded on management science, management information systems, and complexity science, while it can be applied in diverse domains that require tactical management decisions.

In this chapter, the Denica method is used to develop a prototype of a software tool that can be used to implement a Tactical Management Information System (TMIS) that is adapted to the needs of the individual manager with tactical management responsibilities. For doing so, we enhanced the Denica method to better address the tactical management needs in highly unpredictable environments such as those observed during the COVID-19 pandemic, resulting in the proposal of Denica 2.0. The chapter starts with a literature study where all relevant concepts are described. Next, the research methodology is presented. This is followed by an analysis of the ability of the Denica method to be used as a method for developing a TMIS intended for use in a highly unpredictable environment. Then, Denica 2.0 is presented along with its use to develop a software prototype for implementing a TMIS. Finally, the chapter ends with conclusions, limitations, and recommendations for future work.

2 Background Section

To develop a TMIS that is tailored to the needs of the individual middle manager, a clear and comprehensive definition of what tactical management entails is needed. In what follows, the definition of tactical management which was used to create the DENICA artifact will be used. Thus, tactical management (Petrevska Nechkoska et al., 2015) is a managerial function on:

• How to achieve (tactics),

• What is expected (strategy),

• By utilizing what is given (operations),

• Following certain governing principles (strategic guidelines),

• In the current context of the organization and environment (adaptability).

To understand tactical management as a managerial function, it is crucial to know the system which is being managed or facilitated toward producing outcomes. This will be looked into through the research on complex adaptive systems. Afterward, the adaptation to the environment in which the system is being managed is discussed using the concept of situational awareness.

A complex adaptive system (CAS) is a “neural network”-like constellation of interacting, interdependent agents who are bonded in a cooperative dynamic whole by a common goal (Uhl-Bien et al., 2007). Such systems are adaptive in nature due to their individual and collective behavior mutations as a result of constant reaction between agents (Holland, 1992). Typical examples of CAS are cities, governments, and animal swarms (Strogatz et al., 2009). Also societies, organizations, states, unions, projects, etc. can all be seen as a CAS. Even a human being is by some considered as a CAS.

This definition has many similarities with how the middle manager function was described at the beginning of this chapter. The “neural network”-like constellations represent the roles interacting with each other and working toward the primary purpose of the system. Furthermore, Uhl-Bien states that a CAS is a changeable structure with multiple, overlapping hierarchies. This implies that the entities populating the roles interchangeably take leadership, or at least ownership. It takes several entities with different sets of skills, experiences, and resources to achieve predetermined outcomes. Depending on the requirements of the common goal, the roles will therefore be populated with different entities, based on their abilities. Therefore, it is crucial for the middle manager to have good people management, such that optimal teams can be composed.

Adaptability is the ability of a system to adapt itself efficiently and quickly to changes in the environment. An adaptive system is therefore a system composed of interacting entities forming an integrated whole that are able to respond to environmental changes together.

A CAS can also be defined through its distinctive features (Turner et al., 2018). A CAS operates in and as an open system. Closed systems are not influenced by external forces, which makes these systems much more predictable compared to open systems. An open system is non-linear and unpredictable due to many incoming external signals and interactions. The implications of this non-linearity and unpredictability will be investigated in the next section. A direct cause of unpredictability is the need to account for (possibly unknown) external signals, which makes planning less feasible. To cope with this, the CAS must be self-organizing to be effective. This happens through interaction and feedback between the agents of the CAS. This interaction is almost always characterized by the exchange of information (Stacey et al., 2000). Furthermore, the CAS operates at the edge of chaos, which can plastically be portrayed as the intermediate space between order and disorder as a result of the system having little structure. Having little structure provides the CAS with much more flexibility to cope with unpredictable influences. So, the CAS will allocate resources and reorganize itself as a response based on external signals received.

As seen in the definition of the middle manager, the manager must achieve what is expected by utilizing what is given while following certain rules in the context of its organization and environment. Certain implications have to be considered when combining this definition with the knowledge gathered around CAS. The middle manager must manage the CAS to achieve its goal through the provision of simple rules, creating and maintaining moderately dense connections and providing clear guidelines on how to detect and interpret information and how to act in response (Waldrop, 1993; Petrevska Nechkoska, 2020). Because of the distinctive characteristics of a CAS, planning to the detail and 100% automatization may be counterproductive and a waste of time, as it will only complicate things further. Instead, the middle manager should be continually aware of the behavior of the CAS and take control of the CAS by managing the complexity of the system. This can be accomplished by visualizing the managerial (adaptable) system and communicating the visuals of the system among stakeholders, accompanied with the goals and governing principles.

To discover the needs of tactical management, it is crucial to get a grip on the environment in which the manager operates on a daily basis. The omnipresence of technology has transformed the world from the industrial age to the information age. This shift has led to a volatile environment bringing along challenges for organizations and the managers in charge. Many traditional managerial approaches and their supporting information systems rely on a relatively stable and predictable world (Reeves & Deimler, 2011). The sense-and-respond framework (Haeckel, 1999) provides a new way of reasoning to handle these new circumstances and challenges. Instead of trying to plan the future, the manager shall probe the environment to identify changing givens and challenges. Afterward, the manager will respond appropriately and timely with the purpose of eliminating potentially incoming risks or engaging on interesting opportunities before it is too late. This model clearly highlights the key characteristic of the middle manager, including the adaptability that is needed for achieving strategic goals, with its operative capacity at hand.

Figure 1 showcases the change that organizations must make to respond to a rapid changing environment with unpredictable dynamic changes. The key to thrive in the industrial age, where companies were defined by make-and-sell processes, was to be more efficient than their competitors. This has changed drastically. To thrive in the informational age, a company and its composing entities must dynamically adapt to the new environment and be able to respond to an abundance of incoming internal and external signals.

Fig. 1

Transformation from make-and-sell enterprise to sense-and-respond enterprise (Haeckel, 1999)

This transformation from a closed system to an open system, or from an introverted system to an extroverted system, also requires changes to the information systems needed to support the manager. Ultimately, the organization which can sense the most crucial signals and is able to respond in the most effective and fastest way will be able to reap the most advantages, and surf the waves standing. Thus, the information system should inform the manager of both weak and strong signals and support responsive decision-making, along with many other core requirements encapsulated in the Denica method (Petrevska Nechkoska, 2020).

Catching and interpreting signals and making the right decisions is dependent on whether the manager has a good awareness of the environment of the managed system. Situational awareness (SA) is defined as the perception of environmental elements and events with respect to time or space, the comprehension of their meaning, and the projection of their future status (Endsley, 1995). This dynamic environment requires the middle manager to make many decisions in short periods of time. This timely and responsive decision-making requires an up-to-date analysis of the environment. Thus, the challenge is to maintain an accurate and complete SA while the environment is constantly changing, often in complex ways (Endsley, 1995).

With this background it is now possible to conceive a generic method for developing a TMIS specifically designed for the middle manager. This method makes use of prototyping, which will be explained first.

Software engineering is an engineering discipline that is concerned with all aspects related to the production of software (Carrizo & Quintanilla, 2018). Therefore, it is highly recommended to use a systematic, disciplined, and quantifiable approach for the development of software (Radatz et al., 1990). It is good practice in software engineering to use the prototype methodology, which is a software development approach with the goal of creating, testing, and reworking a prototype until it fulfills the user’s requirements. Prototyping demonstrates the feasibility of a system early in the life cycle and allows for risk assessment and validation of user requirements (Rome, 1992). Experiments show that prototyping reduces the number of problems related to requirements specifications (Boehm et al., 1984). Other important benefits of using prototypes are the detection of missing user services, identification of misunderstandings between software developers and users, the adjustment of difficult-to-use or confusing user services, and the identification of inconsistent or incomplete requirements.

One framework to develop prototypes is the prototyping aspects model (Lang & Mjöberg, 2020), which is supported by Agile Prototyping Guidelines. There are several reasons for choosing this framework. Firstly, it supports evolutionary prototyping, which is the process of giving an incomplete system to the user, afterward modifying it, and augmenting it iteratively based on feedback; the outcome is a working software system for end users. This approach is important because the main focus is on the design of the software tool. Secondly, the framework guides the designer from start to finish, which is crucial for discovering the user requirements at the beginning while being able to validate the prototyped model at the end. The method also supports validation and improvement through user feedback. This is important because it allows the designer to improve the prototype based on real-life expectations and experiences of middle managers.

This approach to prototyping is based on four levels of aspects as shown in Table 1. These aspects represent the underlying methodology of prototyping activities. The model guides the developer by offering several choices for each prototyping activity and showcases the applications of prototyping. Understanding this model is crucial for the implementation of the Agile Prototyping Guidelines, which will be discussed in the next section.

Table 1 The four aspects of prototyping and their hierarchy, as adapted from the prototyping aspects model

The prototyping aspects model is supported by the Agile Prototyping Guidelines. The guidelines consist of five steps that should be followed in the development process of the prototype. These steps are the exploration of concepts, the discovery of software requirements, the device design suggestion, the testing and improving step, and lastly confirming the design. Each step is characterized by the choice made for each aspect; the choices are summarized in Table 2.

Table 2 Choice of every aspect for each step

3 Methodology

We have deployed a combination of qualitative and quantitative research methods, incorporating developmental methodology (prototyping and agile) to contemplate this chapter. Initially, the Denica method as the main theoretical pillar has been analyzed in depth and instantiated via training of managers and application of the method to their context, reflecting on their day-to-day tactical management issues. Then the cases were analyzed to fit the Denica generic principles and workflow (Petrevska Nechkoska, 2020). By doing this, we were able to discover some aspects of the method that were up for improvement. The conceptual learnings have been incorporated as enhancements into the Denica 2.0 managerial method, incorporating both managerial and informational aspects.

The resulting information requirements (structured via Agile Prototyping Guidelines) have been mapped and then translated into a software prototype for implementing Tactical Management Information Systems (TMIS), which was then validated on real cases—tactical managers who conveyed in-depth use of the Denica method in their actual work content. The managers are approximately in the same situation and populate the same role in the big four consultancy firms in Belgium. Manager A works as a manager, while Manager B is a senior manager for the team. The greater seniority of Manager B could possibly result in more extensive knowledge of the company and the ins and outs of the team. The same list with predetermined questions was used during the two interviews, which happened throughout half a year briefly before and during the coronavirus pandemic. While main functionalities have been achieved, the work in progress (at this moment) elaborates the dynamic and multi-user aspects for the software prototype application.

Throughout the artifact enhancement, from Denica to Denica 2.0, and from information requirements to the TMIS software prototype, the research has incorporated knowledge from multiple supportive disciplines, such as requirements engineering, communication methods, and managerial theories (systems theory, control theory, etc.). The software prototype development was guided by software development methodologies such as evolutionary prototyping, the Prototyping Aspects Model (Lang & Mjöberg, 2020), and the Agile Prototyping Guidelines. The overall research methodology that guided our research and development efforts was Design Science (Simon, 2019; Hevner, 2007). Research activities included desk research and (semi-)structured interviews.

4 Analysis

This section describes the results of the interviews conducted to test the original DENICA components, with the purpose of assessing the ability of the Denica method to be used as a method for developing a TMIS intended for use in a highly unpredictable environment. The aim of the analysis was to investigate how managers perceive their system and information flows, and the results they obtain when applying the DENICA managerial method to their current situation. It also elaborates on changes to the managerial systems caused by the COVID-19 pandemic, differences between respondents, and their feedback. This was used as input to conceive an improved artifact, DENICA 2.0.

In the further paragraphs, we present and discuss the analysis of the Denica components, following the initial Denica method roadmap (Petrevska Nechkoska, 2020).

4.1 Primary Constituents and Reason for Being

The primary constituents identified during the meetings were the project manager (provider) and client management (customer). The provider has the final responsibility of accomplishing the primary purpose. The customer validates whether the desired outcome was reached.

The identification of the reason for being proceeded in a similar fashion for the two managers, but with notable differences. The delivery of an ERP system to a client was the starting point for both. A mere system delivery (output) is no guarantee for a satisfied customer, and both emphasized that as well. They focus on delivering a qualitative and all-entailing service to their customer (outcome). Two tactical managers have been involved in depth with the Denica method. Manager A identified a “no-error solution” for the client as a desirable outcome. Manager B identified “system delivery and/or advice based on leading practices” as the primary purpose. However, this is more an example of an output (what one is producing) while the DENICA method focuses more on desired outcomes (what one is achieving).

4.2 Governing Principles

Governing principles are standards, as well as always/never principles, that managers are expected to know and expected to do. These are mostly communicated top-down by upper management and can be seen as one of the givens for the tactical manager to work with. Manager A identified the general way of working as the most important general principle. Manager B did not necessarily disagree with these principles but saw them more as processes than as governing principles. Governing principles that were agreed upon by both managers included the need for clear, consistent, and timely informing of the client surrounding the project and where it was at, before moving on to the next phase of the project.

4.3 Role-and-Accountability Diagram

The design of the role-and-accountability diagram (R&A diagram) can be seen as the most important step when binding DENICA’s theoretical concepts to an actual business case, where the method is being instantiated. It is a form of system design with a purposeful nature, generic enough to be applied to any kind of situation. The roles that are displayed do not comprise job positions but are located on a higher conceptual level. Thinking in terms of roles can be challenging for managers, since it is not used in organizations. This became clear when conducting the interviews. Every interaction in the diagram is defined with conditions of satisfaction under which the accountability is valid. It is important to note that the R&A diagram has no time dimension and that it focuses on desired outcomes, not outputs. The interviews resulted in similar diagrams, but with interesting differences. Manager A saw an extra role in the “operational” part of the diagram, in the form of an expert. Manager B thought that the role populated by upper management was directly accountable to the customer as well. These were the biggest contrasts between the respondents (Figs. 2 and 3).

Fig. 2

Role-and-accountability diagram of Manager A (Source: Authors)

Fig. 3

Role-and-accountability diagram of Manager B (Source: Authors)

4.4 Conditions of Satisfaction

For all the outcomes accountable for interactions in the R&A diagram, there needs to be a specification of the conditions of satisfaction (CoS). Both the provider and customer need to agree upon the CoS in order for them to consider the outcome valid. This proves that a desired outcome actually is a two-way street. CoS are directly linked to the interdependencies identified in the R&A diagram. Thus, the differences in the aforementioned diagrams also explain a lot of the differences in the CoS. Outcomes that were common resulted mostly in the same CoS (Table 3).

Table 3 Conditions of satisfaction

4.5 Information Sensors

Information sensors are “what the tactical manager would need to have as information (regardless of the current supply with reports) in order to have dynamic and continuous overview of his system” (Petrevska Nechkoska, 2020, p. 216). The two managers each put up sensors with five roles, among which four were shared. Manager B had more detailed sensors: a fact that could be explained by Manager B’s seniority and experience (Table 4).

Table 4 Information sensors

4.6 Information Emitters

Information emitters are “what the tactical manager would like to have been told by the other roles in order to be aware in a timely manner of possible issues disturbing the agreed outcomes” (Petrevska Nechkoska, 2020, p. 217). Unlike for the information sensors, Manager A had more emitters than Manager B. Most of the emitters were common. The difference is mainly due to an extra role that Manager B did not have in her R&A diagram (subject matter expert) (Table 5).

Table 5 Information emitters

4.7 Risk Management

Risk management is about mapping possible risks that can get in the way of reaching desired outcomes of the R&A diagram (Petrevska Nechkoska, 2020). Here we see the same trend that Manager B mapped more risks than Manager A. She took the identified risks by Manager A and delineated them with more details. Although Manager B identified more possible risks, she had more of an internal locus of control, saying that it is a manager’s responsibility to mitigate certain risks (Table 6).

Table 6 Risk management

4.8 Application of the Denica Method in Regular and in Times of Pandemic

The worldwide outbreak of COVID-19 caused big disruptions for many organizations. Because DENICA was developed specifically to support tactical managers and their need for adaptability, it was interesting to document the changes since the start of the pandemic and see if DENICA was sufficiently able to accommodate and document them. With clients in a multitude of different locations and team members sometimes staffed on multiple projects, the organization was well accustomed to working remotely. Because of this, there were no changes to the big picture. Projects were continued and there could be no deviation from the quality of work. Because the organization tried to change as little as possible, there were no notable changes to the primary constituents, the reason for being, the role-and-accountability diagram, or even the conditions of satisfaction. We may say that there were core (kernel) components in the method that did not change and some peripheral components which witnessed notable changes.

Because of this new way of remote communication, there were changes in place in some of the governing principles. As mentioned before, there have been certain steps in the project process requiring in-person meetings. This is the clearest example of a governing principle that could not be upheld because of the global pandemic. Other principles such as frequent standups, water cooler discussions, and internal meetings, such as status updates or performance management sessions, were also subject to change. These meetings changed in scope, frequency, and communication channel. The approach for internal communications was changed to minimize risks and address uncertainty as much as possible to team members.

There were both new information sensors as well as changes to already existing sensors. Of course, the way of receiving information also changed. Where the bulk of information used to be gathered through meetings in person, everything changed to being discussed online. New sensors included a “COVID-19 update” by the upper management. Another new sensor was the follow-up of analysts who were not staffed on a particular project and were working on isolated tasks. It was important for the managers to keep in touch, communicate on work to be done, and check on their motivation. Another trend that came up during the interviews was a change in frequency of existing sensors. Internal status meetings were held daily to make sure everyone was on the same page. As for the information emitters, evidently, the way of receiving the information changed as well. Most new emitters were already in place before the crisis, but the focus shifted to particular events that could occur because of the pandemic.

A crisis situation like a global pandemic brings along a lot of risks. Both new risks and a greater probability of present risks could be observed. In extreme cases, projects could be terminated early or put on hold. Financial issues for customers could result in budget adjustments or payment issues. Both managers recognized an increased difficulty for establishing a relationship of trust with clients, without the possibility of in-person meetings. This results directly in an increased risk of not receiving enough involvement or empowerment by client management. Mental well-being of staff could be affected by being stuck at home. This was managed as much as possible by keeping close contact with everyone (reflected in information sensors and information emitters). Performances fluctuated from person to person. Some workers saw a drop in output; others worked more. Lastly, one of the most obvious risks in a pandemic is that people tend to get sick more frequently being reflected in family logistics, home offices, etc. Both managers had staff that were infected with COVID-19.

4.9 Contextual Differences Between the Managers

The managers are in the same situation and populate the same role, having a helicopter view, which normally should result in similar systems. Nonetheless, they see and describe their situation differently sometimes. This makes it interesting to look at the different interpretations of the same system. Manager A works as a manager for the team, while Manager B is a senior manager. This could be a possible explanation why Manager B was more concerned with using in-house terminology. As a senior she is also more involved with upper management, making it possible for her to better portray the interactions surrounding that role. The same list with predetermined questions was used during the two interviews. But Manager A was interviewed before Manager B, so the researcher had the opportunity to ask Manager B for her opinion on things that Manager A had mentioned during her interview. The answers from Manager B are therefore at times more exhaustive.

4.10 Managerial Feedback on DENICA

Both Managers A and B liked the adaptability provided by the DENICA managerial method: the adaptability to different types of organizations and how easily the method is implemented through the established roadmap, but also adaptability to different situations in a certain case study, for example, how easily the changes since the start of the COVID-19 pandemic are documented throughout the different components. They also noted that DENICA’s strength lies in its ability to show the informational flows in a system. Not exhibiting all kinds of flows that go through an organization, which would often be irrelevant, but really focusing on flows that are needed for achieving the “primary purpose”.

Manager A was also of the opinion that the method focuses too much on the system, the information flows, and the delivery to the client. A matter that is underexposed, according to her, is the people aspect of being a manager. Both managers had a hard time making a distinction between the information sensors and emitters. Sensors were sometimes placed under emitters and vice versa. The information sensors include the “way of receiving” which is oral, written, or both. This description felt insufficient. The information emitters, on the other hand, could carry a few more attributes (Petrevska Nechkoska, 2020).

5 Conceptualization of DENICA 2.0

5.1 Enhancing the Denica Method

The analysis was used as input to conceive additional components and improvements to the existing components of the Denica method. Afterward these new and improved components are consolidated with the original building blocks to create a new and improved managerial method—DENICA 2.0.

5.2 Additions to the Initial Managerial Method Denica

5.2.1 Distinction Between Information Sensors and Information Emitters

One of the problems encountered during the DENICA implementation was telling apart the differences between information sensors and information emitters. There were a great deal of information flows that were important for the manager and the system, but it was not always easy to place them in the right category. So, an attempt to make the difference between the two more intuitive was undertaken.

A useful concept to describe the way that information is distributed is through the concepts of information push and information pull (Cybenko, 1999). When a user requests and receives a specific kind of information, that is information pull. If the information is sent to anticipate the user’s needs, or the information was not directly solicited, then we are speaking about information push. In this case, the information is mostly triggered by a contextualized event (Cheverst et al., 2002). In the DENICA method, the information sensors are clearly a pull mechanism. The tactical manager specifically needs this kind of information to get a good overview of the system, and actively requests it from the other roles in the system. While information emitters are more an example of information push. The tactical manager wants to be told certain things by the other roles in the system. The pull and push mechanisms are added to the components. Do not be confused by the positioning of the arrows. The information is going in the direction of the tactical manager in both cases. The pull arrow is positioned away from the tactical manager to stress that he or she takes the initiative to gather the information (Fig. 4).

Fig. 4

Pull and push dynamics of information sensors and information emitters (Source: Authors)

5.2.2 Enhancement of Information Sensors Attributes

During the interviews, while identifying the information sensors and emitters, we ran into a limitation of how these components were documented. For information sensors, the attribute “way of receiving” divides the different sensors into being either “event-driven” or “on-demand” as well as mentioning if they are received in an oral or written way. The respondents acknowledged the benefit of documenting this information but found the current way rather confusing. The most tangible examples are in meetings with supporting notes and presentations. Is it oral or written? How to document the difference? It would be useful to enhance the sensors to get more detailed information.

The original “way of receiving” column for information sensors can be split up into two separate columns since it entails two types of metadata, those types being how the information is triggered and how it is received. The first new column “trigger” states if the information is gathered event-driven or on-demand. The original column “way of receiving” now states the actual form of communication that is used. Whether the channel is oral, written, or both is still mentioned. The qualitative/quantitative aspect denotes whether the expected information content is a description, sentence, explanation, or a quantitative indicator which has its logical connection to the system of roles and accountabilities, and its primary purpose (Table 7).

Table 7 Enhancement of information sensors

5.2.3 Enhancement of Information Emitters Attributes and Conjugation with Risks

Another thing which was discussed during the feedback part of the interviews was the information emitters. The respondents felt like the emitters conveyed less information than the other components. Information sensors possess extra attributes such as way of receiving, qualitative/quantitative, and frequency. Risk management makes mention of probability, impact, and approach. Information emitters, on the other hand, only mention who is the emitter and what type of information should be disclosed. So, it seemed like there was room for expansion.

An important objective of the information emitters is to make managers aware of possible risks in a timely manner. During the case study, it became clear that a large part of the emitters dealt with information linked to the risks that were listed in the risk management component. Evidence suggests that when information concerning risks is presented in a clear and understandable format, people’s understanding and perception of that risk goes up (Ahmed et al., 2012). Thus, it makes sense to link information that could have an impact on an identified risk to the corresponding risk. Next to a possible link to a risk, a connotation (+/−) was added, to give insight if the information emitter may contain positive content with regard to the primary purpose or role accountability, or negative—giving the manager an idea of the type of information that could be emitted. All information sensors, information emitters, and risks are actually different aspects of the same story—what the manager needs to know to sustain the system (Table 8).

Table 8 Enhancement of information emitters

5.2.4 Introducing a Fifth Visual Component: People Management

Even though the Denica method was originally designed to address exactly that—the people and resources management, reconfiguration, and adaptation, one of the biggest critiques of the practitioners was that DENICA did not focus enough on the people aspect of being a manager. The method maps out the different roles in the R&A diagram. What the graph of the managerial system, i.e., the system diagram of roles and accountabilities, does not do is depict who exactly populates these roles. The respondents felt like this was missing and should be added. The composition of a team has a big impact on that team’s dynamic and its performance (Bell, 2007), so it is of great importance for a manager to have a clear and complete image of who is part of his or her team, and which role they populate, along with many other relevant details on request.

A “people management” component was created to provide the manager with an overview of the team they are working with (Santa & Poels, 2019). Following attributes are documented: the team member’s name, the role the person populates in the system, years of experience, situational leadership that suits the team member best, and room for additional necessary information. These attributes were selected since they all have a big impact on the way a manager needs to interact with his or her team (Table 9).

Table 9 The new component “People Management”

5.3 The Artifact DENICA 2.0

The additions and improvements that were conceived with the input and feedback of the respondents are consolidated and merged together with the already existing components of DENICA. This results in a new and improved managerial method—DENICA 2.0.

The generic implementation roadmap, which was already part of the original method, is kept. According to the respondents this was one of DENICA’s strong suit, providing managers with a straightforward and easy-to-use guide to implement the method. The roadmap includes following steps:

• 1. Identification of the primary constituents.

• 2. Clarification of the reason for being and levels of desired effects.

• 3. Framing of the governing principles.

• 4. Designing the role-and-accountability system diagram around the primary purpose.

• 5. Setting up the initial conditions of satisfaction.

• 6. Addressing managerial and informational needs through the heads-up displays and the commitment protocol.

• 7. Continuous performance of the Sense–Interpret–Decide–Act (SIDA) Loop and effectuating adaptability to changes through the R&A diagram.

The components of the DENICA 2.0 method are visualized in Fig. 5 and described as follows:

• 1. A system of roles and accountabilities, designed according to the sense-and-respond framework principles:

  • (a) Having in mind the purpose, the end, and the reason for being.

  • (b) Visualizing the role-and-accountability diagram.

  • (c) Specifying conditions of satisfaction for every negotiated outcome accountable for.

• 2. People management (new explicit aspect of the visualization, previously it was more implicit).

  • (a) Visualizing the people that populate the different roles around the system designer—the tactical manager.

  • (b) Stating the necessary attributes for people management:

    • Team member’s name.

    • The role the person populates in the system.

    • Years of experience.

      • Situational leadership that suits team member best (directing, coaching, supporting, delegating).

    • Additional necessary information (domain, capabilities, cost, etc.)

• 3. Risk management (along with risk positioning and information flows).

  • (a) Visualizing the risks per role, around the role of the system designer but to some extent also around all other roles too.

  • (b) Stating the necessary attributes for risk management:

    • Interested party (usually the tactical manager for his or her system, but also any other role for his or her outcome’s respective system).

    • Sensor, the actual role or entity or business process or general place where the tactical manager needs to point the “radar” to in order to receive that signal.

    • Risk type (experience of management, lack of knowledge for cross-checking, etc.)

    • Probability to happen (1 [low]–5 [high]).

    • Impact on the business (1 [low]–5 [high]).

    • Risk management approach (accept, avoid, transfer, mitigate, contingency plans).

• 4. Information sensors—specific information that the tactical manager requests from other roles to have an overview of his or her system (regardless of current supply of reports):

  • (a) Visualizing the information sensors per role and accountability, around the role of the system designer—the tactical manager.

  • (b) Stating the necessary attributes of the information sensors.

    • Interested party (usually the tactical manager for his or her system, but also any other role for her outcome’s respective system).

    • The entity where the tactical manager places the information sensor.

    • The type of information to be obtained (progress feedback, results, issues, etc.)

    • The type of trigger for requesting the information (on-demand or event-driven).

    • The way of obtaining information (meeting, presentation, conversation, etc.)

    • Type of content (qualitative or quantitative information).

    • Frequency of obtaining the information (hourly, daily, monthly, quarterly, etc.)

• 5. Information emitters—what the tactical manager would like to have been told by the other roles in order to be aware in a timely manner of possible issues disturbing the agreed outcomes.

  • (a) Visualizing the information emitters per role, around the role of the system designer—the tactical manager.

  • (b) Stating the necessary attributes of the information emitters:

    • Interested party (usually the tactical manager for his or her system, but also any other role for his or her outcome’s respective system).

    • Emitter (the role that should emit the specific information).

    • Type of information (expectations, personal issues, not recording logs, etc.)

    • Connotation of the information (positive or negative sentiment).

    • Possible link to corresponding risk.

• 6. Continuous performance of the Sense–Interpret–Decide–Act (SIDA) Loop and effectuating adaptability to changes through the R&A diagram and Plan–Do–Check–Act (PDCA) Loop for improvements. The pull and push mechanism is made more explicit!

Fig. 5

New DENICA 2.0 (the Denica managerial method with recommendations added) (Source: Authors)

The new people management component is added to the existing framework together with the visualization of the pull and push dynamics. The tactical manager is added in the center, surrounded by all the components of his or her system. This stresses the fact that the manager is the focal point of the method.

A visual divide is made to showcase where the managerial and informational aspects of DENICA are positioned. The system of roles and accountabilities is moved upward to oversee all the other components. The R&A diagram is not only part of the managerial needs; it also lays the groundwork for the manager’s informational needs. Since it is part of both aspects, the two sides of a coin, it does not make sense to include it in either, giving it a rather central place in the framework.

People management is added to the managerial aspect, together with risk management. There are no changes made to the informational components, but arrows are added to establish who is taking the initiative of providing the necessary information. The tactical manager is responsible for setting up his information sensors in the right places. Information emitters are in charge of getting the information to the manager when a specific trigger or event occurs. Lastly, the linkage that was made between the information emitters and risk management is also included.

As the Denica 2.0 is introduced, it provides a substantiation foundation for shaping the Tactical Management Information System in its proper outlook, as continued in the headings further on, in this chapter.

6 Tactical Management Information System (TMIS): From Concept to Prototype

User requirements are statements, in a natural language, of what services the system is expected to provide to system users and the constraints under which it must operate (Sommerville, 2011). These user requirements, guiding our conceptual work, are gathered through an extensive literature study, seminars, and analysis of the findings of research (Petrevska Nechkoska, 2020). Documenting the user requirements is essential for the further design of the prototype. It is used to verify if the designer has a good comprehension of what the software tool should provide. In addition, these user requirements are used as a foundation for the documentation of the system requirements, which are in turn used for the development of the managerial cockpit.

Software requirements are expanded versions of the user requirements and are used by software engineers as the starting point for the system design; they define what is to be implemented and are a more detailed description of the software system’s functions (Sommerville, 2011). The software requirements specification can be seen in Table 10. The software requirements are mapped to the user requirements with the help of the number coding from Table 11.

Table 10 User requirements specification

Table 11 Software requirements specification and mapping with the user requirements

At this point, the user requirements were specified based on an extensive literature study and analysis of previous research. Different crucial concepts for the design of software such as MIS, SA, and BI have been discussed. The user requirements were transformed into software requirements based on this knowledge. The software required for the development and the given input has been discussed. This means that all the necessary requirements needed to start the modeling of the software tool are fulfilled. Figure 6 shows the first version of the prototype. This is the result of many design choices which implement all the software requirements to the best of the designer’s knowledge. The prototype will be explained by splitting the dashboard into different components and discussing the individual compartments in more detail.

Fig. 6

First version of the prototype (Source: Authors)

The first big compartment of the dashboard is the system of roles and accountabilities (1). Because of its importance, it takes a central position in the overall software and the dashboard is designed such that it is always visible. This should allow the middle manager to always have a big view picture and improve the understanding of how the different roles are related to each other. The choice has been made to use a graphical representation, since this is the better option for the identification of relationships, as seen in the concept exploration.

In this network, the roles are represented by the different nodes and the accountabilities are represented by the edges between the nodes. The names of the roles are abbreviated for the purpose of readability and placed inside the node. However, when clicking on a node, the full name is displayed in the filter function (5) for selecting roles. In addition, the selected node will turn green to highlight which node has been selected by the user (Fig. 7).

Fig. 7

Filter function for selecting roles (Source: Authors)

The primary purpose in the system of roles and accountabilities, which is the most important goal where every role in the system works toward, is an edge displayed in orange, annotated with the beginning of the primary purpose in text. The customer and provider roles, receive and deliver the primary purpose, respectively, are also colored orange. The legend (4) shows a description of the color codes used in the system of roles and accountabilities. The dashboard is also supported with some guidelines (3), such that the user instantly knows how to work with the dashboard.

The system of roles and accountabilities can be expanded by the option bar (7), which has two options to choose from: either “the roles-and-accountabilities diagram” option which results in displaying the diagram from Fig. 6 or choosing the “all data points” option which results in displaying the system seen in Fig. 8. This network represents all the roles involved in the project and how they are connected. In the roles-and-accountabilities diagram, the edges only represent the predetermined outcomes and the respective conditions of satisfaction. While in the network with all the data points, edges can be conditions of satisfaction, signals from information sensors, signals from information emitters, or risk signals.

Fig. 8

Network with option: “all data points” (Source: Authors)

At first glance, the system can be overwhelming due to so many connections. Although it quickly shows the user which roles have many connections with each other. The “all data points” network is mainly created to be used in combination with the connected nodes switch (8). When switching this option on, it will only show the connections with the selected node, providing great insight into the relations and responsibilities of the selected role. An example is shown in Fig. 9 based on the case study; the user directly notices that the subject matter expertise has relations to three other roles: technical analysis, project management, and functional analysis. The user also notices that the relation is much stronger with project management due to the many connections between them compared to the sole condition of satisfaction with both the technical analysis and the functional analysis. In addition, it is clear that the relation between subject matter expertise and project management is mainly information based: the SME has to inform the PM about one risk signal and has to emit information in case of four events/triggers and the PM has to request the SME about three different information sensors. And lastly, this example shows that SME and PM do not work together on a predetermined outcome, since there is no condition of satisfaction connection between them.

Fig. 9

System showing only the connected nodes (Source: Authors)

The network can be adjusted with the help of two switch buttons. Button (9) can be switched on if the user wants to move the network around or if the user wants to switch on the ability to zoom in or out. Button (10) can be switched on if the user wants to move the individual nodes; the edges between the nodes will be moved automatically. These buttons provide flexibility to the user; they can be used to give a better overview for a specific situation or to take a closer look. In addition, the user can organize the network as they require for a specific situation and take a screenshot to be used in a meeting or presentation.

The second big compartment of the dashboard are the tables with information (2). As seen in the concept exploration, for analyzing exact values, qualitative data, and making an overall judgment, it is advised to use the tabular representation. These tables are highly interactive, such that the user is able to receive the right information at the right time. The user can request information by selecting the role they want information about in the dropdown function (5); the selected role will directly light up green in the system of roles (1) such that the relation with other roles is also clear. Or the user can simply click on a node to see the corresponding information about the role or click on an edge between two roles, such that only information is displayed where both roles are involved. In addition, the user can specify which type of information they would like to receive by choosing one of the following options: “conditions of satisfaction,” “risk,” “people,” “information sensors,” “information emitters,” from the dropdown function (6).

Figure 10 shows the tabular representation of the conditions of satisfaction for the finances role based on data gathered in the case study. Colors have been used to improve the user’s cognition. If the selected role is the supplier role of the outcome, it will be represented by the neutral color blue. The corresponding condition of satisfaction to fulfill the predetermined outcome will be colored blue as well, such that the user directly notices which information applies to the selected role. On the other hand, if the selected role is the customer role, it will be represented by the neutral color purple as well as the respective condition of satisfaction. The other variables (columns) apply to both the supplier and customer role; therefore, there is no color coding required to link the information to the specific role.

Fig. 10

Conditions of satisfaction for the finances role (Source: Authors)

The choice has been made to keep the tables as compact as possible, such that the user is able to find the information they are looking for as fast as possible. Consequently, long pieces of information will be compacted to fit in the table. However, when the user has found the information that he needs, they can hover over the piece of information to receive the full text (Fig. 11).

Fig. 11

Hovering over table to read full information (Source: Authors)

Figure 29 shows the example of viewing the edge information between the project manager and the client management. Only information will be displayed that involves both roles. This example also showcases the visual representation of the primary purpose. The outcome which is the primary purpose of the project will be colored orange, which is the same color used for the representation of the primary purpose in the system of roles and accountabilities (Fig. 12).

Fig. 12

Accountability (edge) information and primary purpose (Source: Authors)

An important part of the dashboard is to create immediate SA for the user. Therefore, certain pieces of important information are represented in intuitive meaningful colors. A great example of this is displayed in Fig. 30. The user has requested information about risk management for the project manager. The user can immediately make sense of the situation by assessing which pieces of information are important by looking at the colors. The variables “Probability” and “Impact on Business” are colored green for respectively low probability of occurring and low impact on the business when occurring, orange for medium probability and impact, and red for high probability and impact (Fig. 13).

Fig. 13

Example of intuitive meaningful color usage (Source: Authors)

The tabular representation of the people management data is used to gain deeper insights into the entities who populate the roles. It is also frequently used to populate the roles with diverse people for specific outcomes based on their skill set, experience, and other characteristics. Another frequent use of the “People” table is when the user knows he has to receive or deliver information to a certain role, then he looks up which entity they can best contact within the role (Fig. 14).

Fig. 14

Example of the people management for the functional analysis role (Source: Authors)

The information emitters table displays data for the selected role, about which party must be informed when a specific trigger/event happens, to be aware in a timely manner of possible issues disturbing the agreed outcomes. The user is immediately aware if the information is positive or negative by looking at the color of the connotation variable. The variable makes use of the intuitive meaningful colors green, red, and orange to, respectively, indicate positive, negative, or neutral signals (Fig. 15).

Fig. 15

Example of the information emitters for the client management role (Source: Authors)

The information sensors table displays data for the selected role, about which party is interested in certain information and at which sensor they can request this information. Additional variables are available depending on the specific project. This table is frequently used by the interested role to find which sensor is able to provide information needed for a certain decision and how they can request this information, if it is not event-driven. Frequently, these sensors are what the middle manager would need to have as information to have an overview of his system (Fig. 16).

Fig. 16

Example of the information sensors for the functional analysis role (Source: Authors)

Two scenarios are given to demonstrate how actual information such as performance management data can be retrieved by the middle manager. In the first scenario, the middle manager needs performance data on a new employee to populate a role as a temporary replacement for an employee on sick leave. The managerial cockpit shows that the middle manager can request this information from the human resource manager in an oral or written manner (Fig. 17).

Fig. 17

Information sensor scenario 1 (Source: Authors)

The second scenario is situated in a large company which uses traditional business intelligence tools and an ERP system in combination with the managerial cockpit. The middle manager needs to know the duration for some process which needs to be revised because it is too long. The managerial cockpit shows that the middle manager has to request input from the operational manager and is able to retrieve information about processes in the ERP system under the Process Data section (Fig. 18).

Fig. 18

Information sensor scenario 2 (Source: Authors)

It is important to keep in mind that the managerial cockpit is an intermediary layer between the manager and the operational BI. It consists of the managerial system and relevant aspects (people, risks, etc.) and serves as a portal which can be connected to various incoming data.

7 Competitive Advantage in Tactics

“The DENICA artifact is a complete functional method intended for people that need to steer others or themselves in accomplishing outcomes. Of course, it has issues that can be worked on, to make things easier and simpler to use” (Petrevska Nechkoska, 2020). For a long time, middle managers have been using methods designed for strategic or operational management, which they tried to adapt to fit the tasks of tactical management. Our research has shown that middle managers need methods designed for their characteristics such as provision for adaptability and context capture.

Implementing and utilizing the DENICA artifact can provide a competitive advantage in tactics. The managerial cockpit was developed to leverage the competitive advantages which can be achieved by using the DENICA artifact. The dashboard supports the DENICA artifact by amplifying the cognition of the user, improving the communication among stakeholders, and saving time and effort. These advantages lead to the manager being able to deal with the complex and dynamic environment in a more effective manner, focusing on managing and facilitating comprehensive and non-overwhelming data and reports.

The DENICA artifact is designed to support the user in achieving goals by creating a good SA and managing what is given through time. The managerial cockpit can amplify the cognition of the middle manager by providing a helicopter view over their situation. The visual representation of the system of roles and accountabilities, which is directly linked to the tabular representation of the data, is one of the biggest advantages of using the managerial cockpit. The option to look at the big picture, while being able to look at different viewpoints to investigate data in detail, greatly supports the user in creating SA. In addition, the user can map their own information requirements needed for specific projects and change them frequently. In this way, the user is provided with a lot of flexibility needed to compete in a complex dynamic environment. The DENICA 2.0 managerial method does a great job in supporting the practitioner in managing what is given to achieve what is expected based on the complex environment of the user. The managerial cockpit tries to improve the effectiveness of this process by utilizing visual features. The use of concepts such as intuitive color coding or representing data in certain ways can improve the cognition of the user even further. The managerial cockpit facilitates the decision-making process because the user can make certain connections or assess the situation much faster.

An important element of the DENICA 2.0 artifact is to improve the communication among the middle manager and other stakeholders. It is crucial for the middle manager to be able to communicate the mission/vision, governing principles, expected goals, accountabilities, and so on. If this communication is not clear, the stakeholders would not be able to accomplish the goals. In addition, the communication must be clear and relevant; the different stakeholders must know when and what information must be communicated. This advantage has not been tested to the full extent since the managerial cockpit was validated by a single user instead of having a case study where the interaction between stakeholders and the user could be investigated. However, the benefits which could be obtained by utilizing the managerial cockpit are made clear in a couple of scenarios.

Scenario 1 between the middle manager and the top manager: The middle manager can use the managerial cockpit as a visual reporting tool in meetings with the top manager to discuss the current status and future events. For example, the managerial cockpit can show that there is a need to hire a new employee because a certain role has too many tasks and responsibilities for the number of entities populating that specific role. In this case, the managerial cockpit can be used by the middle manager to show the top manager the reasoning behind the request of hiring a new employee.

Scenario 2 between the middle manager and an external party such as the customer: By simply screenshotting the dashboard, the user can easily communicate the progress or status of the project to the customer. The user is able to customize the managerial cockpit by only showing relations between certain nodes or deleting irrelevant or confidential columns and rows. This is a big improvement compared to showing Excel sheets, which could still contain confidential and irrelevant information or by having to make customized presentations for each new meeting.

Scenario 3 between the middle manager and an internal role: The managerial cockpit supports the DENICA artifact on the one hand, clearly stating which role has to communicate which information to whom and when. And on the other hand, facilitating the visual representation of the network of roles and accountabilities and the tabular representation of the data. This facilitates the communication of what is expected from a certain role or communicating to a team what the primary purpose is and how everyone has to work together to achieve it.

Before the development of the managerial cockpit, the practitioners of the DENICA managerial method were offered an Excel Workbook with four worksheets for each core component. The visualization of the graphs was done by the user or in beta versions of different software packages that deal with social network analysis. This becomes very time-consuming for the practitioner, especially when more projects need to be involved or when things have to be shared with other stakeholders. The managerial cockpit provides simple and straightforward tool support which can produce easy drawings of the diagrams, and is able to easily maintain the information sensors, emitters, and risks in a dynamic sense.

7.1 Limitations and Further Research

The DENICA 2.0 managerial method and the managerial cockpit go hand in hand. Therefore, it was important for the designer to validate the model based on user feedback from a middle manager with experience and knowledge of the DENICA artifact. It was planned to receive validation from the middle managers, who had been involved in case studies to validate the DENICA artifact. Although this feedback was crucial for the improvement of the managerial cockpit, it would be very valuable to conduct a real-life case study in which middle managers use the DENICA 2.0 managerial method along with the managerial cockpit to gain deeper insights.

A limitation of the current dashboard design is the dependence on Excel for the user. In an ideal situation, the dashboard would be supported by a database management system. Instead of storing the data in an Excel sheet, the user would be able to add their new data to the dashboard interface and it would be stored and updated automatically. In this case, the user would not have to be in touch with other software besides the dashboard interface itself. Future work is already in place to plug the managerial cockpit to operational business intelligence systems.

The current dashboard is specially designed for desktop use, this is sufficient for the purpose of this chapter, although, in the mobile world of today, it could be interesting to make the dashboard functional on a mobile application. This would imply making the managerial cockpit a standalone and online application. This could be done by upgrading the used software to Dash Enterprise, which allows for building and deploying Dash apps in an organization.

8 Conclusion

This research tries to contribute to the ongoing effort of shedding more light on the tactical managerial function and the MIS supporting this level. By implementing the original Denica method as a case study at a big Belgian firm, we were able to not only validate it, but also conceptualize an enhanced “Denica 2.0” method expanded with a Tactical Management Information System prototype. This research is situated at a crossroads, where it is both able to help managers with carrying out tasks in a complex, tactical context and stimulate the academic field in its efforts to further study tactical management as a concept.

Tactical management connects the operational to the strategic level in organizations; thus, it has a big impact on different stakeholders on several levels. The different kinds of stakeholders were engaged as much as possible in this research. The Denica artifact was not only implemented and validated by middle/tactical managers; it was also validated by a strategic manager. The connection between a tactical and strategic manager is of the utmost importance, to both managers their respective systems. That is the reason why the strategic manager was involved, to enhance the informational and managerial flows in both ways.

The TMIS prototype was designed to not only support the tactical manager, but all kinds of roles in the hierarchy of an organization. Therefore, research and input was gathered of several different stakeholders, such as operational and strategic management, although the most important input remained tactical management. The prototype supports the user in achieving goals by creating a good SA and managing what is given through time. In addition, the dashboard supports the DENICA artifact by amplifying the cognition of the user, improving the communication among stakeholders, and saving time and effort.

Denica was implemented, tested, and validated at a Belgian firm. The case study provided us with some interesting and relevant insights. However, all of those insights are to be traced back to managers of one specific team in a big organization in the consulting sector, which is a rather narrow scope. It would be interesting to implement the Denica method at other types of organizations in other industries, to see if this would bring other observations.

Because this research originated during COVID times, it was conducted entirely remote. This did not withhold us from reaching useful results, but being able to meet with the respondents in person might have had a positive impact on the interviews and thus the remainder of the study as well.