Hidden Strategy of Open Intellectual Capital Acquisition: A Case Study of Innovative, Software-Developing SMEs

Abstract

Existing studies into information technology (IT) agile project management (APM) focus on describing the mechanism of how this process should be executed. The distinctive feature of the extensive literature on the subject is the consensus on the events and stages included in APM processes and maintaining discipline in their execution. However, a study of open intellectual capital acquisition (OICA) in innovative small and medium-sized enterprises in Poland that develop software (2009–2023) reveals the presence of an OICA stage in the events of the IT APM process, which is missing in the existing literature on the subject. The current study reveals that OICA is based on strategy. This strategy is inherently incorporated into the mechanism of APM. Moreover, the study shows that artificial intelligence and machine learning are increasingly used in this strategy, which makes it innovative. This text aims to present the results of the study, focusing on identifying and describing the strategy of OICA as an integral component of the IT APM process.

1. Introduction

In the extensive subject literature, intellectual property (IP) is treated as an important part of intellectual capital (IC) [1,2,3,4,5]. The results of studies in the literature reveal that small and medium-sized enterprises (SMEs) producing software acquire different components of IC from both internal and external environments, hence the term ‘open IC’ (OIC) [6]. The study results also indicate that OIC is obtained continuously and simultaneously from both internal and external sources by innovative SMEs producing and developing software. The acquired knowledge directly depends on currently implemented and managed information technology (IT) projects for software production and development [7,8]. What is more, the complementarity of OIC acquisition (OICA) has also been identified and confirmed in SMEs operating in different branches of knowledge-intensive industry [9]. In other words, it can be said that teams of developers acquire different project-related knowledge from the internal and external environments.

Added value is generated in IT projects implemented and managed in SMEs. This process directly involves software developers who partake in iterative teamwork, obtaining knowledge from internal and external sources of OIC [10,11,12]. To manage IT projects in today’s SMEs, techniques based on the Agile Manifesto are commonly used. These techniques are adapted individually to each enterprise’s conditions [13,14,15,16]. Thus, the process of software production and development is unique to each SME and allows for the greatest possibility of generating added value expressed in innovative products. Open intellectual capital acquisition is an internal part of the IT project management process. It depends on the different requirements of IT projects and the professional competencies of the development teams; as such, it is also unique for each project and SME [6]. Other results from studies on companies that produce and develop software, being wholly owned subsidiaries of the International Business Machines Corporation (IBM) in the period of 1998–2018, reveal that a multidimensional strategy of innovation development is used to manage the IP acquisitions and divestitures [17]. This is one of the dependent strategies playing its own role in the entire system of orchestrated strategies at IBM. However, none of the 18 techniques based on the Agile Manifesto describe a strategy dedicated to OICA [13,14,15,18,19,20].

The above-mentioned issues lead to the following research questions: How do teams of developers manage the identification and acquisition of specific knowledge necessary to incorporate it into software produced and developed in actual IT projects implemented in innovative SMEs producing and developing software? If an OICA strategy exists, how is it implemented into the mechanism of the IT agile project management (APM) processes? These considerations constitute the main difference between existing research on IT project management in innovative SMEs and this study. Obtaining results and answering these questions, based on empirical data, provides a theoretical contribution and justification for the research undertaken.

The main goal of this study is to answer these questions by describing how and where the hidden strategy of OICA is incorporated into the IT APM process of software production (and development) conducted in SMEs.

2. Literature Review—Characteristics of Software Development in Small and Medium-Sized Polish Enterprises

This chapter provides an adequate research context for the discussions and ensures that the conclusions drawn from the current study are properly situated within the business realities of the innovative SMEs producing and developing software.

Innovative IT SMEs that produce and develop software operate in a knowledge-intensive industry. The business operations of these enterprises consist of producing and developing software based on two business models. The first is implemented when an enterprise undertakes IT projects individually commissioned by enterprises that conduct business in other branches and industries of the economy. The second is used when an enterprise that produces and develops software introduces its IT products to the market, which are systematically extended, improved, and distributed. The range of products developed by enterprises engaged in developing and improving their own computer programs is frequently designed for enterprises that conduct business in other industries of the economy. In both cases, SME managers maintain and continually expand their catalogues of regular business customers (list of business clients), domestic and foreign, whose opinions, expectations and needs are implemented in subsequent software versions. Needs reported by business customers result from the specific nature of business activities they conduct in their branches and industries. Thus, such needs and requirements are organised into a list of tasks dedicated to implementation in software through IT projects conducted by IT SMEs covered by the study described. Contemporary software-producing SMEs, not only in Poland but also in other countries, use IT project management techniques based on the Agile Manifesto that belongs to the family of software-developing APM techniques [14]; the production and development of software by SMEs in Poland are examples of such business activities. Such IT projects are unique and meet the criteria of being innovative; therefore, the SMEs covered by the study are innovative. The above-mentioned APM techniques assume the participation and cooperation of business customers with the teams of developers that are creating and improving software. In the discipline of management sciences, this is a well-known component of every software project management and is generally referred to as customer management [14,21,22]. This is the reason respondents identified the list of regular (i.e., those with a long track record of cooperation) business customers as an important source of OICA. Generally, two conclusions can be reached. The first is that regular business customers are important sources of OICA in the business operations of innovative software production. The second is that the business operations of SMEs that produce and develop software consist of their own computer programs as part of their IT projects, and they carry out projects individually commissioned by other enterprises in both domestic and foreign markets [23]. Thus, the operating activities of software-producing and developing SMEs carrying out innovative IT projects are undertaken in these SMEs continuously and systematically and include the development and improvement of software, wherein the writing of source code is accompanied by several repeated tests of the program under development, performed using dedicated computer equipment and environments.

As mentioned above, dedicated APM techniques are mostly employed to manage IT projects [15,18,24]. Two distinctive characteristics are evident in the IT project implementation process: iteration and the teamwork of programmers (teams of developers). This teamwork of software developers is repeated many times regularly as part of the software development and improvement cycles (sprints) [15,25,26]. Each sprint aims to implement specific features to be offered by the developed or improved software, addressing the business needs and requirements of customers. Sprints are repeated systematically, regularly, and in a timely fashion during each IT APM process. This means that the goal of each sprint is to achieve added value to the developed software. Each iteration of a sprint adds different and project-specific benefits. Sprint iterations are accompanied by other regularly recurring events included in the APM of software development [14,18,20], such as the product backlog, sprint backlog, sprint planning, sprint interaction, daily stand-up, sprint review, sprint retrospective, and software tests. Sprints and other events are repeated several times in each individual IT project in an orderly and timely manner. Each time, each of these events refers to different content related to the produced or developed software. Hence, the above events form an iterative mechanism of cooperation in teams of developers that creates added value to the software through the IT APM process. The iterative work of the development teams is based on the systematic and continual use of OICA, which is transformed, by way of the written source code, into added value, represented by new or improved functionalities offered by the final and innovative product of the IT APM process. These products are new or improved (next version) software. The value in innovative SMEs that produce and develop software is created and added systematically and continually as part of the IT APM process, which constitutes their principal operating activity. That is why these SMEs are characterised by the highest level of iterative and systematic use of OICA in their operating activities. The characteristics of the operating activities of innovative SMEs that produce and develop software also explain why this group of enterprises was chosen as the subject of these studies. The extensive literature on IC confirms that knowledge is an integral component of intangible assets [27,28,29,30,31,32,33]. Specific knowledge required to produce and develop software in realised projects is identified by teams of developers in the IT APM process. This operational requirement makes such knowledge a strategically important resource for the sustainability and growth of innovative, software-producing and developing SMEs. The results of contemporary research describe the presence of OICA as an integral part of the IT APM process. However, the extensive literature on the subject does not indicate that the strategy of OICA even exists. In the context under consideration, the identification of the OICA strategy reveals how the required knowledge is acquired in IT APM processes. These findings allow for a better understanding of IT APM processes managed in innovative software-producing and developing SMEs.

3. Materials and Methods

The main objectives of this study were to determine how teams of developers identify the specific knowledge needs for the currently realised IT project and where and how the OICA strategy was implemented into the mechanism of the IT APM process.

Innovative SMEs that produce and develop software acquire IC from both internal and external environments. Nevertheless, the way in which OICA is incorporated into the IT APM process has not been researched; thus, it is a relatively new and unexplored area. To research this area, it was necessary to examine closely the IT APM process implemented in operational activities of SMEs covered by this study. The study covered innovative SMEs that produce and develop software in Poland and perform their business activities in the knowledge-intensive sector. These SMEs employ 10–49 employees and 50–249 employees, respectively. The study covered the 15 years between 2009 and 2023, which were chosen based on data availability. Empirical data were obtained from Statistics Poland based on an individual agreement. Statistics Poland conducts regular surveys designated for innovative enterprises only. Detailed specifications of the questions were required to represent the answers in a time series. Each year, the number of software-producing innovative SMEs is different.

Table 1. Small and medium-sized enterprises (SMEs) covered by the study. Source: prepared by the author.

Year	Number of SMEs
2009	288
2010	290
2011	292
2012	297
2013	342
2014	345
2015	353
2016	349
2017	367
2018	382
2019	403
2020	414
2021	428
2022	445
2023	468

shows the number of SMEs covered in this study.

Variables used in the study were directly related to OICA in eight events commonly used in the IT APM techniques based on the Agile Manifesto and presented in the subject literature (Section 2): product backlog, sprint backlog, sprint planning, sprint interaction, daily stand-up, sprint review, sprint retrospective, and software tests. The SMEs covered by this study pointed out those events where a lack of knowledge was identified. These events were selected based on extensive subject literature. The list of artificial intelligence (AI) tools was identified based on the answers provided by the SMEs in this study. As such, empirical data were collated from annual observations. To answer the research questions, the percentage share of all SMEs covered by the study across the entire research period was calculated for the usage of AI and lack of knowledge in each event of the APM process, according to Equations (1) and (2), respectively.

$$PSe{p}_{OICA}={\displaystyle \frac{{\displaystyle {\sum }_{t=1}^{N}En{t}_{t,ep}}}{{\displaystyle {\sum }_{t=1}^{N}EntRes{p}_{t,ep}}}}\times 100$$

(1)

where:

• PSep_OICA = the percentage share of knowledge lack identification over the entire research period;
• t = the subsequent year in the time series of the research period;
• ep = the subsequent position covered by the research;
• N = the number of annual observations in the time series;
• Ent_t,ep = the subsequent SMEs in each year t and entry position ep covered by the research in the entire period;
• EntResp_t,ep = the annual observation of the subsequent SMEs in each year t and entry position ep.

$$PSe{p}_{AI usage}={\displaystyle \frac{{\displaystyle {\sum }_{t=1}^{N}En{t}_{t,ep}}}{{\displaystyle {\sum }_{t=1}^{N}EntRes{p}_{t,ep}}}}\times 100$$

(2)

where:

• PSep_{AI usage} = the percentage share of usage of AI tools over the entire research period;
• t = the subsequent year in the time series of the research period;
• ep = the subsequent position covered by the research;
• N = the number of annual observations in the time series;
• Ent_t,ep = the subsequent SMEs in each year t and entry position ep covered by the research in the entire period;
• EntResp_t,ep = the annual observation of the subsequent SMEs in each year t and entry position ep.

All evaluation results are presented in the next chapter.

4. Results and Discussion

This chapter describes the findings on OICA as a part of the IT APM process implemented in the operational activities of SMEs covered by this study. The results are divided into two parts. The first subchapter is dedicated to the identification and description of the OICA strategy. The second subchapter is dedicated to describing which AI tools are used in the IT APM process and how they are used.

4.1. Strategy of Open Intellectual Capital Acquisition

All respondents pointed out that a lack of specific knowledge was identified during the implementation of the IT APM process. It is closely related to the tasks contained in the product backlog, making them impossible to accomplish and, consequently, to implement functionalities in the planned IT project. Taking into account the results of the study, the need for specific knowledge was identified during various events occurring in the IT APM process. These events are presented in

Table 2. Knowledge gaps related to the open intellectual capital acquisition strategy in the information technology agile project management (IT APM) process. Source: prepared by the author.

Events in the IT APM Process	Entry Position (ep)	Team of Developers’ Decisions	First Sub-Strategy	Second Sub-Strategy	PSepOICA
entry 1	1	Acquisition of missing knowledge possible within the scope of tasks currently specified in the product backlog. It is not necessary to formulate a new task related to acquiring the necessary knowledge.	1	-	31%
	2	Acquiring the missing knowledge requires formulating a separate task and placing it in a specific place on the task list in the product backlog.	-	2	12%
entry 2	3	The missing knowledge necessary to complete a given task can be acquired within the planned sprint. The knowledge planned to be acquired is included in the sprint backlog.	3	-	47%
	4	The identified lack of knowledge necessary to complete a given task requires the planning and implementation of a separate sprint. Acquiring this knowledge will enable the implementation of a related task specified in the product backlog in one of the subsequent sprints.	-	4	28%
entry 2	5	Identification of a barrier consisting of a lack of specific knowledge. Acquisition of the necessary knowledge as part of the currently implemented sprint.	5	-	78%
	6	Knowledge necessary to perform a given task cannot be acquired within the currently implemented Sprint. The lack of knowledge is noted and forwarded to the sprint review together with the planned and uncompleted task in the completed sprint.	-	6	9%
entry 2	7	A review of the missing knowledge and the need to acquire it results in the product backlog being supplemented with a separate task to be completed in one of the subsequent sprints.	-	7	3%

. The identification was always performed by the team of developers. The lack of knowledge was identified in five out of eight events: product backlog, sprint backlog, sprint planning, daily stand-up, and sprint review. In three events—sprint interaction, sprint retrospective, and software tests—there was no lack of knowledge identified.

The first event in which the necessity for specific knowledge is identified is the preparation and review of the product backlog—determining tasks, preparing task descriptions (containing the characteristics of the customer’s expectations), and determining the order (priorities) of the tasks contained therein. The team of developers decides on the type, order, and method of acquiring the missing knowledge. If, during this event, a lack of knowledge necessary to perform and accomplish a task is identified, then the need to acquire the missing knowledge is included in the description and characteristics of the task that is currently included in the product backlog. This situation does not require the formulation of additional (separate) tasks dedicated strictly to acquiring specific knowledge. Such a situation occurs when, in the opinion of the team of developers, the acquisition of the missing knowledge can be achieved within one of the subsequent sprints, in which a specific task will be assigned for implementation. Therefore, acquiring this knowledge will not require planning and implementation of the entire sprint. This point of identification of a lack of specific knowledge is marked in Table 2 as No. 1. If the development team decides that acquiring the missing knowledge will require planning and implementation of at least one entire sprint, then it is necessary to create separate tasks and enter them into the product backlog. This point of identification of a lack of specific knowledge is marked in Table 2 as No. 2.

In the situations described above, the product log is supplemented. The scope of this supplementation is defined by two demarcation lines. The first is to add to an existing task in the product backlog an additional description and characteristics of acquiring the missing knowledge to be performed by the team of developers. Such additions to the product backlog do not result in the planning and implementation of an additional sprint. Instead, the team of developers takes into account the need to acquire specific knowledge necessary to complete a task already specified in the product backlog. This type of supplementation also means that the knowledge necessary to perform a specific task appearing in the product backlog can be acquired as part of one of the subsequent sprints. Therefore, such supplements affect the planning of the scope and types of tasks to be performed in subsequent sprints but do not require the planning and implementation of additional sprints. Therefore, it has a direct impact on the IT APM process through the adequate organisation of the development team’s work and the generation of specific added value within a given sprint. This is why competencies in IT project management, strategic management, and the efficient and effective implementation of changes are essential in managing the IT APM process. The second demarcation line is the addition of extra, separate tasks to the product backlog, consisting of acquiring missing knowledge. Separate tasks of acquiring specific knowledge enforce a specific order (priority) in the product backlog, as they must be completed before the task in which the acquired knowledge will be used in the next sprint. Separate tasks to acquire specific knowledge are also provided with appropriate descriptions and characteristics. They are intended to be performed by the development team. As the results of the study indicate, both situations described above apply to more than one task included in the product backlog, the first situation being the most frequently reported.

The second event in which the need to acquire specific knowledge is identified is sprint planning. The lack of specific knowledge and the need to acquire it is identified during the detailed division of tasks within the development team. The lack of specific knowledge and the need to acquire it concerns a specific subtask within sprint planning. Since the team of developers is self-organising, its members decide whether the acquisition of specific knowledge, together with the implementation of a specific task taken from the product backlog, will be included in the currently planned sprint. If the team of developers decides that acquiring the specific knowledge necessary to implement a given task is achievable within the planned sprint, then the description and characteristics of the missing knowledge are prepared, and its acquisition is planned to be achieved within the currently planned tasks. In this situation, the task related to acquiring specific knowledge is placed in the sprint backlog. This point of identification of a lack of specific knowledge is marked in Table 2 as No. 3. However, if the team of developers decides that acquiring the specific knowledge necessary to perform a given task specified in the product backlog requires planning and implementation of a separate sprint, then it reports this fact to the product owner to supplement the product backlog with a new task appropriately. This point of identification of a lack of specific knowledge is marked in Table 2 as No. 4. The up-to-date content of the product backlog, including the supplementation of the description of all tasks, is always conducted in consultation with the product owner.

The third event in which a lack of knowledge necessary to complete a task during the current sprint is identified is the daily stand-up. According to the agile concept, during this meeting, each participant answers three questions: ‘What did you do yesterday?’, ‘What will you do today?’ and ‘What is blocking your progress?’ [13,14,18,20]. The results of the study indicate that the last question most often involves identifying a lack of relevant knowledge. The lack of knowledge reported during the daily stand-up meeting concerns specific issues related to the implementation of a given function, functionality, or methods and problems related to the software on which the team of developers is working in the current sprint. The reported barrier (in the form of a lack of specific knowledge) is recognised by the team of developers. If determining how to acquire specific knowledge exceeds the time allocated for the daily stand-up meeting, then an additional meeting of the development team is organised by the scrum master; however, only the developers participate in the meeting. This type of meeting is not reflected in the descriptions of IT project management techniques based on the Agile Manifesto, even though it is implemented as part of the IT APM process. If the reported knowledge gaps are relatively detailed, they do not require the entire sprint to be planned for them. In such a case, the development team usually decides to include the acquisition of the necessary knowledge within the currently realised sprint. However, it is important to note that acquiring specific knowledge always requires the allocation of resources, including time, the amount of which is sometimes difficult to estimate. For this reason, it is necessary to use time reserves or time buffers, which are well known in project management methods and practice [34]. This point of identification of a lack of specific knowledge is marked in Table 2 as No. 5. However, if the acquisition of specific knowledge exceeds the scope of the current sprint, but the lack of knowledge will result in one of the tasks planned in the current sprint not being achieved, then this task and the lack of specific knowledge are revisited during the sprint review event, which always takes place after the sprint is completed. This point of identification of a lack of specific knowledge is marked in Table 2 as No. 6. At the same time, the given task and identified lack of specific knowledge are presented during the sprint review event.

The sprint review is the fourth event in which the knowledge necessary to perform the tasks is identified, the lack of which has not been noted so far. The results of the research indicate that in this case, the decision to acquire specific knowledge always leads to the product backlog being supplemented. The process of supplementing the product backlog is described above. The identification of a lack of specific knowledge during the sprint review is marked in Table 2 as No. 7.

The above description of the identification of a lack of specific knowledge signifies that it is iterative in nature. It is an OICA sub-process that is inherently included in the IT APM process. As part of each lack-of-knowledge identification, an adequate description and characteristics are prepared, depending on the needs of the developers. On this basis, goals and objectives are formulated, describing the state in which the specific knowledge (OIC component) needed for further production and development of the software is acquired and ready for use by the developers. The activities and tasks necessary to achieve the goals and objectives are selected and allocated. Thus, the efficient and effective acquisition of specific knowledge, testing, and implementation of the solutions obtained in the IT APM process is being implemented. The persons (members of the project team) responsible for performing tasks related to acquiring the necessary knowledge (described by the goals and objectives) and preparing it (processing, adapting) for use in the IT project, as well as the time and resources necessary to perform the task, are also specified. The necessary knowledge is acquired from both internal and external SMEs. The above elements (goals, objectives, targets, and the resources allocated to achieve them on time) are sine qua non components of the strategy framework [35,36,37,38,39,40]. Thus, they constitute the content of the formulated and implemented OICA strategy. The results obtained in the study indicate that the OICA strategy consists of two sub-strategies. The OICA strategy sub-process described above is summarised in Table 2 below.

The first sub-strategy (Table 2) is created at the points of identification of a lack of specific knowledge marked with numbers 1, 3, and 5 as part of the following events: product backlog preparation and review, sprint planning, sprint backlog, and daily stand-up. The second sub-strategy arises at identification points 2, 4, 6, and 7, within the following events: product backlog preparation and review, sprint planning, and sprint review. A comparison of the points of identification of missing knowledge, sub-strategies formation, their content and methods of implementation in events of a given IT APM process leads to the conclusion that the two sub-strategies differ from each other but also remain closely related. The first sub-strategy can be described as an ‘ad hoc’ strategy. Its time horizon (implementation interval) is relatively short—similar to the duration of a sprint. Its implementation requires a lower level of involvement of tangible and intangible assets and the introduction of relatively minor changes to the IT APM process. Therefore, this sub-strategy requires a relatively low level of flexibility in the IT APM process. In addition, a team of developers is involved in its implementation. The second sub-strategy, on the other hand, requires an expansion of the product backlog. New tasks are strictly related to the need to acquire the necessary knowledge. In this case, not only is the team of developers involved in its formation but also the scrum master and the product owner. It therefore requires significant changes to the IT APM process. Thus, its implementation requires a higher level of flexibility in the IT APM process. In addition, the time horizon of the second sub-strategy is considerably longer and requires the involvement of a higher level of tangible and intangible assets. Identifying and then acquiring specific knowledge is mainly the task of the team of developers, which, at various stages of the iterative process of software production and development, performs the following tasks:

• Identifies the lack of specific knowledge and the need to acquire it,
• Draws up a description and characteristics of the missing knowledge, including the purpose and reason for its acquisition,
• Formulates the goals and objectives to be achieved in acquiring the missing knowledge,
• Determines the method, time and development team member(s) involved in acquiring the necessary knowledge,
• Determines the tasks in which the acquired knowledge will be transferred to other members of the team of developers and selected members of the project team,
• Indicates how the acquired knowledge will be used in the current IT APM process and
• Sets out the scope and form of documentation necessary to be kept in the created library of acquired knowledge, which constitutes a method of managing the acquired knowledge in the further activities of SMEs.

Each position (row) of the percentage share of knowledge lack identification over the entire research period in Table 2 was calculated based on Equation (1).

The lack of knowledge was most often identified in the daily stand-up event (78% of all SMEs covered by the study), which belongs to the first sub-strategy. The next highest percentage share values also belong to the first sub-strategy. They were indicated in the following events: sprint planning (47%) and product backlog (31%). The greatest lack of knowledge constituting the content of the second sub-strategy was recorded in the following events: sprint planning (28%), product backlog (12%), daily stand-up (9%), and sprint review (3%). In conclusion, the results of the percentage share of knowledge lack identification indicate that most SMEs covered by this study identified the lack of specific knowledge in the first sub-strategy. Since the first sub-strategy contains a lack of detailed knowledge, it can be concluded that teams of developers have advanced competencies and skills in software production and development.

A comparison of the points of identification of gaps in the knowledge necessary for the implementation of software in a project, as well as their content, also indicates that both sub-strategies described above suggest a high level of complementarity and interdependence of the knowledge acquired. The inability to acquire specific knowledge in each of the sub-strategies limits the ability to perform subsequent tasks specified in the product backlog, which ultimately leads to the necessity to make significant modifications to the project being implemented. In extreme situations, the lack of specific knowledge and the inability to acquire it mean that given tasks in the product backlog cannot be implemented, which may result in the IT project being abandoned. This situation is known and reported in the form of innovation processes that have been abandoned, discontinued or postponed.

4.2. Artificial Intelligence Tools Used in the Information Technology Agile Project Management Process and Open Intellectual Capital Acquisition Strategy

The results of this study indicate that the last 5 years of the study period (2019–2023) saw a significant increase in interest and the use of AI tools in IT APM processes. Prior to 2020, no results indicated the use of AI tools in the IT APM process. The use of AI tools is highlighted by the SMEs covered by the study in several events of these processes, including the formulation and implementation of the OICA strategy. The use of AI tools is revealed in various forms and at various events in the IT APM process. Among the AI IT tools, the following are mainly specified by SMEs covered by this study: generative AI (gen AI), machine learning (ML), and software computing (SC). Each of them performs a different task in the software production and development processes. Generative AI tools are mainly based on the use of large language models. They include improvements in the software production and development process through the automation of its main stages, and dedicated functionalities that provide support for gathering requirements, generating ideas, producing code and testing software. Each of these stages of software production and development is supported by gen AI to various degrees, depending on the needs and software used. Currently, the most frequently mentioned task of gen AI in software production and development processes is the automation of programming code generation and testing. Features such as code autocompletion, code synthesis, and prediction of subsequent lines of code allow for increased productivity within an IT project. On the other hand, ML utilises the natural language processing mechanism. It is used to interpret natural language (commonly used by members of the team of developers) to generate a specific piece of programming code. Usage of ML reduces the possibility of errors made by coders when writing software. In this way, the team of developers can devote more time and energy to solving more complex tasks that require a greater degree of creativity. Machine learning is used when the development team works iteratively and requires a different organisation of work that unleashes the dormant and previously untapped creativity of the developers.

Software computing is a set of IT solutions used to solve complex automation problems using various techniques (e.g., fuzzy logic, genetic algorithms, and neural networks). The solutions are selected individually, depending on the needs of the IT project currently being implemented; they are based on AI tools and have dedicated applications at almost every stage of the IT APM process. The requirements formulated by the customer ordering the software form the basis for the team of developers, who then use gen AI tools to prepare the final user description of the software and the descriptions and characteristics of the tasks contained in the product backlog. Both ML and SC solutions are used in sprint planning and during the execution of individual tasks within the sprints (including code generation and the generation of testing and error correction conditions specific to the software being produced and developed). In addition, AI DevOps tools support IT project management. DevOps solutions combine the work of the development team (Dev) with operational activities (Ops) within the currently implemented project. They are designed to support the added value generation by the developers manifested in working software stages. DevOps provides tools for intelligent time estimation and process optimisation for continuous integration and continuous deployment (CI/CD). DevOps and CI/CD solutions are most commonly used in multi-project environments. Hence, their use in innovative SMEs that produce and develop software is relatively low.

Artificial intelligence-based tools help to plan tasks more effectively, allocate resources more efficiently and monitor project performance in real time. This allows for increased productivity and minimises failures during IT APM implementation, leading to the creation and use of shorter procedures. The result of the study representing the spectrum of AI tools use in the period 2019–2023 is presented in

Table 3. The scope of artificial intelligence (AI) tools used by the small and medium-sized enterprises covered by the study. Source: prepared by the author.

Entry Position (ep)	Events and Tasks Where AI Tools Are Used	PSepAI usage
1	Automation (testing)	63%
2	Code generation (team of developers)	57%
3	Realisation of open intellectual capital acquisition (OICA) strategy	51%
4	Testing, errors detection and fixing	45%
5	Formulation of OICA strategy	32%
6	Documentation (descriptions, characteristics)	22%
7	Project management	13%

.

Each percentage share of usage AI tools over the entire research period presented in Table 3 was calculated based on Equation (2). Artificial intelligence tools are mostly used for automation procedures (mainly for software testing processes) by 63% of all innovative SMEs producing and developing software covered by this study. The use of AI tools for code generation (specifically used by teams of developers during a sprint) was declared by 57% of respondents and 45% for tasks directly related to testing (also directly related to a sprint). Dedicated AI tools in all events in IT APM processes are used for the formulation (32%) and realisation (51%) of the OICA strategy. The low level of use of AI tools in project management indicates that there is a relatively large scope for developing more advanced AI tools in this area. All respondents confirmed the continuous use of AI tools in their operational activities and an ongoing interest in expanding their application in IT APM processes.

In the formulation and realisation of the OICA strategy, the application of AI tools for knowledge acquisition was highlighted primarily in external sources, including open sources, social forums and technical support from various IT centres. For the internal sources of knowledge acquisition, AI tools are used for intelligent searching of the knowledge database, which is regularly managed and developed by the SMEs.

Knowledge acquisition is becoming increasingly automated, and its forms are diverse, such as conceptual descriptions and programming code examples. The acquired knowledge is processed, adapted and tested to meet the requirements of the software currently being produced and developed. In this way, the diverse forms of acquired knowledge are transformed into unique—and therefore innovative—solutions, which are ultimately applied to the currently implemented IT APM process.

5. Conclusions and Future Research

Approximately 18 techniques of the IT APM processes are created and described based on the Agile Manifesto. All of them are based on the scrum technique, which is considered the basic mechanism for managing IT projects [41,42]. These techniques consist of common events. This study has revealed that a previously undescribed sub-process of OICA occurs within these events. Open intellectual capital acquisition is a sub-process continuously realised in the operational activities of SMEs covered by this study.

The results presented in the first part of this study identify that the OICA sub-process is continuously realised as a strategy. The findings indicate that this strategy is an integral part of IT APM processes. Thus, its use is unavoidable. These conclusions constitute a main difference between this research and the results presented in existing subject literature. Different types of ‘lack of knowledge’ are identified in different events, and, therefore, in a different sub-strategy. Formulated goals, objectives, tasks and allocation of tangible and intangible assets required for OICA are the framework for any strategy. Prepared descriptions and characteristics represent the purpose, meaning and scope of the knowledge required in the currently realised IT project. The content of these descriptions and characteristics constitutes the basis for formulating the goals and objectives intended to be achieved in the OICA sub-process. From a strategic point of view, goals, objectives and targets are the most common elements of strategies. Achieving goals, objectives and targets requires a set of logical, consecutive activities and tasks, along with the allocation of all necessary assets, and represents the framework of any strategy. These are essential elements of each strategy. It is important to take into account all resources necessary for performing the activities and allocate all tangible and intangible assets (e.g., dedicated computer equipment and software, internet access, assignment of required time synchronised with other tasks in the IT APM process, competences and skills necessary to acquire new knowledge needed in the currently realised project). Allocated activities and tasks are meant to achieve goals, objectives and targets. In turn, it is a strategy process dedicated to generating added value, which is (in direct relation to the context under consideration) the acquisition of necessary knowledge in the OICA sub-process, an integral part of the IT APM process.

The revealed OICA strategy is composed of two sub-strategies. Both are formulated and realised during the mentioned events in the IT APM processes. The characteristics of these OICA sub-strategies, revealed and described based on findings of this study, have not yet been comprehensively described in the extensive subject literature. It is a new issue, in the exploration phase. Comparing these two sub-strategies, the first one can be characterised as ad hoc and has a shorter time horizon. It is composed of minor shortcomings in specific OIC that can be acquired in the OICA sub-process and does not require additional tasks to be included in the product backlog and separate newly planned sprints. Thus, OICA is realised within existing tasks in the product backlog and iterative sprints. The second sub-strategy has a longer time horizon. It is composed of significant gaps in specific OIC, necessary to acquire in the currently realised IT APM process. These gaps are crucial to achieving project success. Acquiring this OIC is crucial to further development and project success, as well as bringing the entire project to a successful conclusion. A failure of this OICA can even cause the entire IT project to be halted. These two sub-strategies are in mutual relations that change as the content of both sub-strategies changes in the IT APM process. Although these two sub-strategies differ in content and timeframe for their formulation and realisation, in both sub-strategies, the OICA sub-process occurs continuously, and missing knowledge is acquired from both external and internal sources. It is an iterative sub-process permanently integrated into the IT APM process. The iterative nature of the OICA sub-process allows the necessary knowledge to be obtained more efficiently and effectively, which has a significant influence on the realisation of the IT APM process. Furthermore, in many cases, the acquired OIC in both sub-strategies revealed complementarity. It can be concluded that both sub-strategies require orchestration; this is why both sub-strategies compose one coherent OICA strategy hidden within the IT APM process. Efficient and effective formulation and realisation of the OICA strategy requires deep competencies and experience in strategic management and close cooperation between members of the IT project team. However, the literature on the subject, as well as professional training courses in techniques based on the Agile Manifesto, does not devote adequate time and attention to these competencies, mostly focusing on management mechanisms described in the particular agile techniques.

The findings presented in the second part of this study reveal that AI tools have been increasingly used in IT APM processes in the last 5 years of the research period. The AI tools are mostly used for automation of test processes and code generation, which is commonly used by teams of developers. The use of AI tools for auto-completion and code synthesis further enhances productivity by predicting next lines of code and even generating entire functions. These tools are used to adapt and evolve, leveraging ML models and deep-learning techniques, leading to more efficient coding practices; this results in greater added value generated by the team of developers, achieving sustainability and success of IT project management. On the other hand, less common AI tools are used for the APM process, primarily because the study covered innovative SMEs producing and developing software. Artificial intelligence tools dedicated to managing IT projects more efficiently and effectively are designed for use in a multi-project environment, which is typical for large enterprises. Nevertheless, the use of AI tools is growing dynamically, both through new applications and through the scope of their use in IT projects. Therefore, both the types and the scope of AI tools use are constantly changing, which is a challenge for future research in this area.

The results obtained from this study also have implications for IT APM practice. The scope of AI tool application in IT projects depends primarily on the size and complexity of the projects being implemented. The impact of AI on ongoing projects is evaluated depending on the project stage and the type of application. Among the many benefits, the most frequently cited are the accelerated completion of project tasks (both individual and team) and the more efficient acquisition of necessary knowledge. This, in turn, considerably improves the efficiency and integrity of IT project management. These fundamental benefits also reduce project costs. Simultaneously, the project team members are more efficient in knowledge acquisition, which leads to a more effective learning process. As a result, the level of valuable knowledge increases more efficiently. In both cases, a significant reduction in the amount of time spent on activities related to searching for the best IT and management solutions is noted. In other words, the amount of unnecessary work decreases in the IT project. The benefits described above are achieved gradually and require the selection of appropriate AI tools for the tasks performed in an individual IT project. At the same time, this selection improves the integrity of project management through more consistent cooperation between project team members involved in individual stages of project work.

In conclusion, successful and sustainable IT project management requires competencies that go far beyond describing event organisation mechanisms, scope of responsibility, role description, and allocation and flexibility. Product owners, scrum masters, and development teams should represent and use strategic management competencies in practice. Supplementing these competencies seems to be of fundamental importance for increasing the efficiency and effectiveness of management and, therefore, for maintaining the sustainable development of innovative IT projects. The conclusions regarding both the OICA strategy and the use of AI tools are that IT projects are thoroughly innovative because they meet the definitional criteria of innovation processes. Furthermore, the OICA strategy should be used in future studies on SMEs belonging to the knowledge-intensive software production branch.

The study is subject to several limitations. The most significant of these is the limited availability of data on the use of AI in IT projects. Despite the long-standing presence of AI tools, the data accessible for this research covered a relatively short timeframe. Consequently, simpler analytical methods had to be employed. This, in turn, necessitated greater caution in formulating conclusions, which makes them less precise. Another important limitation was the absence of a clear distinction between SMEs, which were grouped as a single unit of analysis. Moreover, the landscape of AI tools is continuously expanding and evolving, which complicates efforts to obtain a comprehensive and up-to-date understanding of their application in IT projects.