PlanProjU: Automated Planning System for University Projects

1. Introduction

The design and execution of university projects are commonly carried out following the Project Management Professional (PMP) methodology [1]. However, in the context of official university outreach programs, the PMP methodology is often not fully implemented due to technical and structural limitations in higher education institutions. This gap indicates that having a generic project management methodology is insufficient; instead, there is a pressing need for detailed planning across all project phases.

From an AI perspective, the field of AI planning also known as automated planning provides a well-established computational framework to automate the entire planning process through the generation of executable plans, thereby streamlining the planning process and enhancing efficiency 2,3].

Recent progress in project planning has been driven by significant advances in decision-making, resource allocation, risk analysis, cost-benefit evaluation, and financial assessment techniques [4]. These traditional approaches have consistently proven effective in numerous contexts, yet they remain inherently limited in their ability to facilitate real-time monitoring and the explicit consideration of uncertainty factors that are particularly relevant in university environments. Over the past several decades, research has extensively explored diverse methodologies, mathematical models, and algorithms aimed at enhancing project planning efficiency [5,6,7,8,9].

A contemporary trend emerging alongside the rise of Generative AI is the integration of large language models (LLMs) into project planning. For instance, Zhen et al. [10] proposed a deep-learning-based task planning system embedded in an LLM to emulate human expert reasoning in task scheduling, demonstrating the ability of LLMs to enhance project planning capabilities. Similarly, Schröder [11] applied knowledge engineering to design a reasoning framework that, when integrated with an LLM, supports engineering project planning under the SCRUM methodology, further highlighting the benefits of LLMs in project planning. However, despite these advances, most applications remain confined to robotics and software engineering, revealing a significant research gap in the application of LLMs to broader project management domains, underscoring the need for further exploration and development in this area.

The integration of large language models (LLMs) into automated planning has been explored in recent attempts, as surveyed by Höller (2020) [12]. However, this approach is hindered by fundamental challenges, including hallucinations, which compromise the reliability of reasoning when transitioning from an initial to a goal state. This limitation is further emphasized by the fact that these challenges undermine the effectiveness of LLM-based project planning methods, highlighting the need for alternative approaches. Automated planning techniques, which generate plans using embedded constraints and heuristics, given a domain description and initial/goal states, offer a viable alternative [13].

One promising subfield is hierarchical task network (HTN) planning, which decomposes complex tasks into sequences of primitive, executable actions [14,15]. While primitive actions are explicitly defined by preconditions and effects, compound tasks lack such explicit semantics in the most widely used formalism, HDDL [15] the domain description language employed in the International Planning Competition (IPC) in 2020 and 2023 [16].

A key challenge in HTN planning is the manual creation of domain models, which demands expert-level knowledge. This process can be supported by structured representations of real-world knowledge, such as the Business Process Model and Notation (BPMN). Rooted in the principles of Frederick Taylor’s scientific management [17], BPMN assumes the existence of an underlying fixed business process (BP) that can be automated and executed by a process management scheduling (PMS) system [18,19].

The process of implementing a repeatable business process involves a structured approach that includes three key steps. First, it requires identifying a repeatable business process (BP) a structured abstraction of a real workflow. This step is crucial as it lays the foundation for the subsequent steps. The second step involves formalizing the identified BP into a process model that captures the task execution flows toward a business objective. This process model is often created using the explicit control flow in the Business Process Model and Notation (BPMN), a widely accepted standard for modeling business processes. The use of BPMN enables a clear and unambiguous representation of the process, facilitating effective communication and understanding among stakeholders. The third and final step involves automating the routing of the process via a PMS. The PMS assigns tasks to the appropriate participants, whether human or software agents, ensuring that the process is executed efficiently and effectively. This automation enables a seamless transition from an initial to a goal state, thereby justifying the representation of project management as a BPMN-modeled process.

BPMN offers two distinct advantages for modeling university projects: (1) it provides a graphical, hierarchical representation of cause–effect dependencies, and (2) its XML serialization can be parsed to identify state transitions in each project component. These transitions encode conditional operations for decision flows, yielding sequential and parallel task executions with their respective constraints [20].

Once the BPMN diagram is parsed, two HDDL files are generated: the domain file containing the HTN action model and the problem file defining the initial and goal states of specific university projects. The SHOP2 planner introduced in the 2002 IPC and originally implemented in LISP 2,22] was then applied. Unlike its predecessor, SHOP2 supports partially ordered subtasks, improving efficiency when operating over simple knowledge bases.

PyHOP is a simple HTN scheduler written in Python, compatible with versions 2.7 through 3.2, and contains fewer than 150 lines of code. Its scheduling algorithm is based on that of SHOP [22], but it avoids the need for a specific scheduling language by having the task network and its methods written in Python, using alternative syntax to logic for defining variables, actions, and methods. PyHOP’s development stemmed from the observation that application developers often wrote their own scheduling systems instead of learning specialized AI scheduling languages [23]. PyHOP was created with the hope of providing an HTN scheduler that would be understandable to people without AI experience. The author of Pyhop did not make much of an effort to promote it, but its ease of understanding and use has made it useful for rapid prototyping, leading to its use in various projects and publications.

Prior work combining automated planning and BPMN for process automation has demonstrated the effectiveness of this approach. Schuschel’s work (2006) [24] is a notable example, as it utilizes classical planning to automate process definitions for adaptive workflows, showcasing the ability to adapt to changing circumstances. Similarly, Moreno (2005) [25] successfully integrated knowledge models into temporal classical planners for telecommunications network installation, highlighting the effectiveness of this approach in complex domains. Furthermore, Da silva (2017) [26>] has addressed the challenges of human knowledge representation by utilizing inductive logic programming to discover action operators in classical planning, underscoring the need for improved knowledge representation in automated planning systems.

However, these contributions are limited to temporal and numeric classical planning without addressing HTN planning, which is a significant gap given the complexity of modern project management. This study addresses three critical gaps: i) the scarcity of automated execution systems for university projects; ii) the absence of HTN-based project automation to produce context-adaptive plans for dynamic project management conditions, which can result in inflexible and ineffective planning; and iii) the lack of project planning systems prioritizing automatic plan generation for university project execution, which can hinder the ability to respond to changing project requirements.

The objectives of this work are as follows: (a) To develop PlanProjU (Planning + Projects + University), a comprehensive HTN-based automated planning system specifically tailored for university projects, thereby enhancing efficiency and productivity in project management. (b) To represent real-world university project knowledge via BPMN diagrams, providing a standardized and visual framework for project planning and execution. (c) To validate PlanProjU through the generation of domains and problem instances, enabling the automatic production of executable project plans, thereby ensuring the accuracy and reliability of the system.

The main contributions of this research are multifaceted and far-reaching, encompassing both technical advancements and practical applications. First, the design and implementation of an innovative HTN-based automated planning framework for university projects represents a significant breakthrough in the field of project management. This framework has the potential to streamline project execution, enhance efficiency, and improve overall outcomes. Furthermore, the extension of HTN planning to non-traditional domains such as beyond robotics, manufacturing, risk management, and logistics demonstrates the versatility and adaptability of this planning approach. By applying HTN planning in these diverse domains, researchers can identify commonalities and develop more generalizable solutions, ultimately contributing to the advancement of the field. Theall, the integration of AI planning with organizational management represents a crucial step toward bridging the gap between theoretical AI research and practical projects. This integration has the potential to provide a more comprehensive understanding of how AI can be effectively used in other real-world contexts.

The remainder of this paper is organized in a logical and coherent manner, allowing for a clear progression of ideas. Specifically, the structure is as follows: Section 2 provides a comprehensive review of the relevant literature, establishing a foundation for the work presented in this paper. Section 3 outlines the methodology employed in developing PlanProjU, providing a detailed understanding of the approach taken. Section 4 show experiments. Section 5 presents the results of this development, allowing for an evaluation of the effectiveness of the methodology. Section 6 engages in a thorough discussion of the findings, highlighting key insights and implications. Section 7 concludes the paper. Finally, Section 8 shows future work, summarizing the main contributions and outcomes.

2. Related Work and Definitions

This section highlights the significance of research that has investigated the integration of automated planning for BPMN process modeling with other applications designed for constructing HTN planning domains and problems. A total of 27 studies that focused on the creation of domains and problems to generate plans that enable the implementation of process models and the generation of workflows supported by automated planning were identified.

2.1. Exploratory Search Alternative

For several decades, the AI community has been actively involved in business process management research, with a significant body of work examining the role of automated planning technologies in process management systems. These systems are designed to manage complex business processes while maintaining robustness, reactivity, and adaptability in response to environmental and tasking changes. One of the initial works addressing this research challenge is reference Reijers (2016) [27], which outlines how planning techniques from the planning community can be utilized to synthesize new business processes and repair previously defined processes that are no longer suitable for a given situation. This highlights the potential of planning techniques to improve business processes’ flexibility and responsiveness. Marella (2019) [28] further investigates the use of an intelligent assistant based on planning techniques, which may suggest compensation procedures or re-execution of activities if anticipated failures occur during process execution. This demonstrates the ability to plan techniques to mitigate potential failures and ensure the smooth operation of business processes. In M. Rosa (2017) [29] describe how planning can be integrated with process execution and plan refinement and investigate plans patching and plan repair as means to enhance flexibility and responsiveness. This integration of planning with process execution is crucial for ensuring that business processes remain adaptable and responsive to changing circumstances.

2.2. Automated Planning for BPMN

The application of planning techniques is also relevant in the field of web service composition, where complex challenges are addressed using planning. Notably, a limited number of studies employ domain-independent planners to generate compositions of atomic web services, demonstrating the effectiveness of planning in this area. Research in [28,29,30,31] has explored the use of planning technologies to achieve service composition at the knowledge level, as seen in [34], highlighting the potential of planning to address complex web service composition challenges. Furthermore, studies such as Hoffman [35] have utilized customized planners, including the FF planner, to construct service orchestrations from atomic IT entities described in a planning-like manner, showcasing the versatility of planning techniques in web service composition. Additionally, research in [34,35] has combined situation calculus with planning techniques to perform service composition, providing a comprehensive approach to addressing web service composition challenges. In contrast to works that view services as atomic planning operators, a significant body of research [36,37] has considered services as stateful entities, characterized by a well-defined behavioral description derived from BPEL specifications. In these studies, the requirements of the desired composite service are expressed in a temporal logic-like language, and planning techniques based on model-checking are employed for service composition, underscoring the importance of considering the stateful nature of services in planning-based web service composition. Similarly, recent advances in symbolic search such as the work of Bertoli (2006) [39] indicate that complex scenarios such as process modeling require the partitioning of action models. On the other hand, the development of research in process modeling has been developed mainly from the classical AP approach and not from HTN, due to the limitation of a development framework in HDDL. Given this difficulty Berchner (2025) [40] has developed a framework for HDDL like the development frameworks in PDDL to improve the construction of action and problem models in alternative contexts such as process modeling.

2.3. Contribution and Novelty

PlanProjU diverges from existing research by treating project planning as a collection of distinct, dynamic components without outlining the comprehensive transformation process from BPMN to an HTN planning domain and problem. A novel knowledge-representation framework is proposed, which extracts control-flow and data semantics from arbitrary BPMN structures and compiles them into two primary components: (i) action models, comprising tasks/operators with preconditions, effects, and resources, and (ii) a planning problem with ordering constraints derived from gateways, events, and artifacts. This results in a pipeline that generates executable HTN plans, eliminating the need for intermediate Gantt encodings, while maintaining a direct connection to the original process specification and organizational rules.

In contrast to earlier surveys of AI planning for process control flows, such as Stein (2008) [41] which fails to address implementable project-management instantiation, our approach takes a more comprehensive approach by treating the BPMN project model itself as the canonical source, then translating it into an HTN domain/problem for plan synthesis. This approach differs from Vanhatalo (2009) [42] propose knowledge-representation frameworks to aid experts in crafting action models, but do not explicitly ground real-world objects and resources within action schemas. Similarly, Barták (2010) [43] consider automatic action-model generation from elicited expert knowledge, but do not encode organizational knowledge in BPMN-like process frames as the substrate for constructing planning domains and problems. In contrast, PlanProjU closes these gaps by coupling BPMN-level semantics with HTN compilation, enabling explainable, policy-aware project plans that are directly traceable to institutional processes. Köckemann (2025) [44] emphasizes the importance of promoting the use of AI Planning across various domains, yet this goal remains unfulfilled due to the significant challenge of developing action and problem models by experts in AI Planning. Notably, the proposed AIDDL development framework has addressed the creation of action models for traditional and temporal planning, but it does not extend to HTN planning, thereby leaving a notable gap in its scope.

2.4. HTN Definitions

An HTN planning instance can be written as $P=\langle L,C, A,M,s_0,t_{nI},g,\delta \rangle$. Here, L, A, $s_0$, $g$ and $\delta$ have their usual meanings from classical planning (set of literals, set of primitive actions, initial state, goal condition, and cost/metric, respectively). The set C contains abstract task symbols (high-level activities) and is disjointed from the primitive task names, i.e., $C\cap A=\varnothing$. Tasks are arranged into task networks $tn=\langle T,\prec , \alpha \rangle$, where T is a (possibly empty) set of task identifiers, and $\alpha :T\to A\cup C$ labels each identifier with either a primitive or an abstract task—allowing the same task name to occur multiple times in the network. The precedence relation $\prec \subseteq TxT$ is a strict partial order over identifiers (irreflexible, transitive, and therefore asymmetric). The component $M$ denotes the set of methods that decompose abstract tasks into subnetworks, and $t_{nI}$ is the initial task network.

Two task networks $tn=\langle T,\prec , \alpha \rangle$ and ${tn}^{\prime }=\langle T^{\prime },{\prec }^{\prime }, {\alpha }^{\prime }\rangle$ are isomorphic when they differ only by a renaming of task identifiers. Formally, there exist a bijection $\sigma :T\to T^{\prime }$ such that for all $t,t^{\prime }\in T:\left(t,t^{\prime }\right)\in \prec \iff \left(\sigma \left(t\right),\sigma \left(t^{\prime }\right)\right)\in {\prec }^{\prime }$ and $\alpha \left(t\right)={\alpha }^{\prime }\left(\sigma \right(t\left)\right)$.

In HTN planning, decompositions are specified by methods. A method couples an abstract task symbol $c\in C$ with a subtask network, written $m=\langle c,u\rangle$, where $u=\langle U,{\prec }_U,{\alpha }_U\rangle$. Consider a task network ${tn}_1=\langle T_1,{\prec }_1,{\alpha }_1\rangle$ and an identifier $t\in T_1$ such that ${\alpha }_1\left(T\right)=c$. The method $m$ can be applied by replacing t with a fresh copy of the subtask network into a task network ${tn}_2=\langle T_2,{\prec }_2,{\alpha }_2\rangle$. Formally, there must exist an isomorphic renaming θ of u that produces $\widehat{u}=\langle \widehat{U},{\prec }_{\widehat{U}},{\alpha }_{\widehat{U}}\rangle$ with fresh identifiers $(T_1\cap \widehat{U}=\varnothing )$ and $u\cong \widehat{u}$. There is a task network ${tn}^{\prime }=\langle T^{\prime },{\prec }^{\prime }, {\alpha }^{\prime }\rangle$ with ${tn}^{\prime }\cong tn$ and $T_1\cap T^{\prime }=\varnothing$. The task network${tn}_2$ is defined as follows:

$${tn}_2=\left(\right(T_1\backslash \left\{t\right\})\cup T^{\prime },{\prec }^{\prime }\cup {\prec }_D,({\alpha }_1\backslash \left\{t\to c\right\}\cup {\alpha }^{\prime }\left)\right),$$

(1)

$${\prec }_D=\left\{\left(t_1,t_2\right)\left|\right(t_1,t)\in { \prec }_1,t_2\in T^{\prime }\right\}\cup \left\{\left(t_1,t_2\right)\left|\right(t,t_2)\in { \prec }_1,t_1\in T^{\prime }\right\}\cup \left\{\left(t_1,t_2\right)|\left(t_1,t_2\right)\in { \prec }_1,t_1\ne t\wedge t_2\ne t\right\}$$

(2)

$M$ is the set of decomposition methods. We will write ${tn}_{t,m}\to {tn}^{\prime }$ to denote that $tn$ can be decomposed into a task network ${tn}^{\prime }$ by applying the method $m$ to the task $t$, and $tn\to \ast {tn}^{\prime }$ if it is possible to decompose $tn$ into ${tn}^{\prime }$ using a sequence of methods.

The decomposition begins either with a single initial task or with a task network (that may include more than one task). A definition using a single initial task is sometimes beneficial to keep proof simple. Using an initial task network makes it possible to interpret every search node in the search space as a new planning problem [45]. However, both definitions are equivalent: Given an initial task network ${tn}_I$, it can be compiled away by introducing a new task $c_I$ (that is the new initial task) and a method $m$ that decomposes the new task into the original task network $m=(c_I,{tn}_I)$.

A task network $tn=(T, \prec ,\alpha )$ is a solution to a given HTN planning problem $P=(L,C,A,M,s_0, {tn}_I,g,\delta )$ if and only if the following solution criteria hold:

• ${tn}_I\to \ast tn$, i.e. It can be reached by decomposing the initial task network.
• $\forall t\in T:\alpha \left(t\right)\in A$, i.e. all task names are primitive.
• There is a sequence $\langle t_1,t_2\dots .t_n\rangle$ of the task in $T$ that is in line with $\prec$, i.e. $\forall i<j:(t_j,t_i)\notin \prec$, and the application of $\langle \propto \left(t_1\right)\propto \left(t_2\right)\dots ..\propto \left(t_n\right)\rangle$ in $s_0$ results in goal state.

The last solution criterion requires an HTN solution to result in a goal state. This is quite unusual, since most hierarchical formalisms lack a (state-based) goal definition though some have one, e.g. these introduced by Bercher (2017) [46] and [47].

2.5. SHOP 2

SHOP 2 was first demonstrated in 2002 at the “International Planning Competition” [48]. It was originally written in Lisp, a functional programming language like SHOP. One of SHOP 2’s key properties is that it maintains the same order of planning tasks as they will be executed, which enables it to generate plans quickly [21]. However, SHOP 2 differs from SHOP in one significant way: it allows subtasks to be partially ordered, while still preserving performance. This modification also enables the use of simpler knowledge bases. Furthermore, SHOP 2 can interleave subtasks from different tasks using the Planning Operator Transfer and Decomposition (POTD) method [1] and [21], thereby avoiding the need for global planning instructions.

As explained in reference [21], the basic elements of SHOP 2 are as follows: Logical Atoms, which consist of a predicate name combined with a list of arguments, World State, which is a collection of ground Logical Atoms, and Tasks, which are syntactically similar to Logical Atoms but differ semantically, consisting of a task name and a list of arguments. In SHOP and SHOP 2, domain-specific knowledge is necessary for planning within a particular domain. This knowledge includes Axioms, which are expressed using Horn-Clause, Methods, which function as if-then-else statements, and Operators, which comprise a Task Atom, a Delete List, and an Add List. The Operators modify atoms within the World State. Additionally, Operators can include “protection request” and “protection cancelation,” indicating that certain conditions should not be removed or should be considered removable, respectively. In our case, we utilize “Effects,” which can be used to modify global variables, mimicking the functionality of the Delete and Add lists.

Task: The task is an activity to be performed, which can be either a Primitive task or a Compound task. Primitive tasks utilize their task symbol as the Operator name and the Task arguments as the Operator parameters. If the task is Compound, it must be decomposed into subtasks using Methods. Operator: An Operator represents a Primitive task to be performed. It consists of a head, which includes the name and arguments of the task, Preconditions expressions that must be satisfied, and an Effects list, which replaces the Add and Delete lists. No two operators can have the same name, and all applications of an Operator are instances of the same Operator. Each Operator can have a “cost” expression; the cost of all plans is the sum of the operator’s costs. Method: A Method indicates how to decompose a compound task into a subset of tasks. It consists of a head, which includes the name of the task, a list of Preconditions that must be satisfied, and a list of sub-tasks to be decomposed into. SHOP 2 allows the use of the keyword “: ordered” to force sub-tasks to be Totally Ordered. If not used, the subtasks can be Partially Ordered, or by using the keyword “: unordered”. The method can have a form: $(:method head \left(m\right) p_1 t_1 p_2\dots ..p_n{t}_n)$ Decomposition can be viewed as an if-then-else statement. The first requirement, p1, is checked. If it is satisfied, the subtasks t1 are applied. If not, the planner moves on to the next requirement, p2, and repeats this process until a requirement is satisfied. This can result in different ways to solve the problem, generating alternative branches in the search space.

To start the planner SHOP 2 it is required to define: $s:initial state, T:partially ordered set of sub tasks and D:domain or action model$. Starting with a: run SHOP 2($S,t,D$). The Pseudo-code example from [1]:

$$M\leftarrow m,\theta$$

$$if M=0 then return failure$$

$$non-deterministically choose a pair \left(m,\theta \right)\in M$$

$$modifiy T by removing t, adding sub\left(m\right)$$

$$if sub\left(m\right) !=0 then$$

$$T_0\leftarrow t\in sub\left(m\right)$$

$$else T_0\leftarrow t\in T$$

SHOP 2 is considered more beneficial for real-world domains than for classical planning operators because it more accurately represents the domain designer’s perspective on the problem. Although SHOP 2 features a domain-independent planning engine, its HTN methods are domain-specific and must be modified for each individual problem. The incorporation of domain-specific problem-solving knowledge can enhance a planner’s performance.

2.6. HDDL

The Hierarchical Domain Definition Language (HDDL) is an extension of the Planning Domain Definition Language (PDDL) that incorporates hierarchical task networks (HTN). Introduced by Holler [15], HDDL offers a standardized language for hierarchical planning systems, accompanied by comprehensive documentation and a range of domains and problems. Many of these resources are sourced from the hierarchical task network tracks of the International Planning Competitions (IPC-HTN), specifically from the 2023 IPC-HTN tracks. HDDL’s design enables users to define or modify problem-solving approaches by adjusting the hierarchical task networks to suit their specific needs.

Definition of planning action model or Domain: A planning domain $D$ is tuple $(L,T_p,T_c,M)$ it define: $L$ is the underlying predicate logic, $T_p and T_c$ are finite sets of primitive and compound tasks, $M$ is a finite set of decomposition methos with compound tasks from $T_c$ and tasks networks over the set $T_p\cup T_c$.

Definition of planning problem: A planning problem $P$ is a tuple $(D,s_I,t{n}_I,g)$, it defines: $s_I\in S$ is the initial state, a ground conjunction of positive literals over the predicates assuming the closed word assumption. $t{n}_I$ is the initial task network that may not necessarily be grounded. $g$ is the goal description, being a first-order formula over the predicates (not necessarily ground).

In other words, beyond the action definition in PDDL, which establishes the rules of interaction with the environment, HDDL introduces two additional operators: task and method. The introduction of these operators enhances the expressiveness of HDDL, allowing for a more detailed representation of complex problem-solving scenarios. A task in HDDL represents a high-level action, which can be broken down into more specific and manageable components. Conversely, a method is a strategy to accomplish a task, indicating that multiple methods can exist to perform a single task. This flexibility is crucial in problem-solving, as it enables the exploration of different approaches to achieve a common goal. Furthermore, a method in HDDL is essentially a task network that decomposes a high-level task into a partially or totally ordered list of tasks and actions, providing a structured framework for planning and execution.

An example of tasks and methods definition in HDDL:

(: task get-to: parameters (?l - location))

(: method m-drive-to-via

           : parameters (? li? ld - location)

           : task (get-to? ld)

           : precondition ()

           : subtasks (and

                  t1 (get-to? li))

                   t2 (drive? li? ld)))

           : ordering (and

                    (t1 < t2)))

An example of the goal in a transport problem is:

(: htn

        : tasks (and

              (deliver package-0 city-loc0)

              (deliver package-1 city-loc2))

        : ordering ())

2.7. PyHOP

PyHOP is a simple HTN scheduler written in Python, compatible with versions 2.7 through 3.2, and contains fewer than 150 lines of code. Its scheduling algorithm is based on that of SHOP [22], but it avoids the need for a specific scheduling language by having the task network and its methods written in Python, using alternative syntax to logic for defining variables, actions, and methods. PyHOP’s development stemmed from the observation that application developers often wrote their own scheduling systems instead of learning specialized AI scheduling languages [23]. PyHOP was created with the hope of providing an HTN scheduler that would be understandable to people without AI experience. The author of Pyhop did not make much of an effort to promote it, but its ease of understanding and use has made it useful for rapid prototyping, leading to its use in various projects and publications.

It typically uses a list of tasks, actions, methods, and goals expressed as functions, which facilitates the decomposition of tasks into task methods and goals into goal methods. Therefore, the PyHOP scheduler can return either the list of tasks or the list of goals. One limitation is that loading different domains and scheduling problems requires restarting Python to re-execute, as it has a limited ability to recognize domain and problem files. However, the domain and problem files can be in JSON, PDDL, or even HDDL format. Another limitation with more advanced schedulers like PyHOP 2.0 and GTPyHOP is the less extensive standard documentation compared to other HTN schedulers.

3. Methodology

This research employs the Design Science Research (DSR) approach, a systematic methodology that aims to develop innovative solutions to real-world problems [49]. DSR serves as a framework for managing project risks, constructing theories, and publishing results. Its relevance in this study lies in its focus on designing artifacts that serve human purposes, ultimately generating scientific knowledge to address real-world issues and contribute significantly to the field. The article seeks to develop implementation plans for university projects using automated planning, a method validated through case studies [50]. To achieve this objective, two key questions will be addressed: What is the most suitable methodology for building a planning system using automated planning? And how can the methodology be validated to generate plans for the implementation of university projects? The resulting planning system will enable the identification of project implementation plans in universities and facilitate the creation of a general project planning environment applicable across various contexts. The next Figure 1 shows the DSR methodology

Figure 1. The research process in design sciences is a structured and systematic approach that involves several stages to ensure the development of a well-informed and effective solution to a relevant problem. The process commences with the identification of a relevant problem in stage 1, which is essential for formulating a structured research question in stage 2. Understanding the problem and its context, including causes and functionalities of the artifact, is crucial in this stage as it provides a solid foundation for the subsequent stages.

A systematic literature review in stage 3 involves consulting various technical databases, such as Scopus, WoS, IEEE, Google Scholar, Science Direct, and ArXiv, to justify the importance of developing the artifact and solving the problem. This stage is critical as it enables researchers to identify existing knowledge gaps and areas for improvement, thereby informing the development of the artifact. In stage 4, identifying artifacts that address similar problems allows researchers to apply best practices, while configuring the problem class defines the scope of their contributions.

This stage is essential as it enables researchers to build upon existing knowledge and develop a solution that is tailored to the specific problem at hand. The proposal of artifacts in stage 5 is related to solving a specific problem, and the researcher considers the feasibility and reality of the proposed artifacts. This stage is critical as it enables researchers to develop a solution that is practical and effective. In stage 6, the design of the selected artifact involves considering the entire context in which it operates and satisfactory solutions to the study problem.

It is essential to describe all procedures for the construction and evaluation of the artifact in this stage as it provides a clear understanding of the research methodology. The construction of the artifact is carried out in stage 7, while stage 8 involves evaluating the behavior of the artifact to provide a satisfactory solution to the problem. This stage is critical as it enables researchers to assess the effectiveness of their solution and identify areas for improvement. Stage 9 involves clarifying the learning achieved, explaining the factors that contributed to the success of the research and the elements that failed.

This stage is essential as it enables researchers to reflect on their experience and identify areas for improvement. The conclusions in stage 10 present the results of the research, the decisions made during its implementation, and the limitations of the research that may give rise to future studies. This stage is critical as it enables researchers to communicate their findings and contribute to the advancement of knowledge in the field. Stage 11 allows for the generalization of knowledge to similar situations by other organizations, while stage 12 involves communicating the results, contributing to a significant advancement of knowledge through publications in journals, seminars, conferences, and other platforms. This stage is essential as it enables researchers to disseminate their findings and contribute to the broader academic community.

3.1. Design Artefact: Mapping to a Graph Model BPMN

In this step, stage 5 of the DSR methodology is presented, given that the previous stages have been thoroughly developed and validated. The foundation established in the preceding stages provides a robust framework for the subsequent stages, ensuring a cohesive and systematic approach to the research. In this stage, algorithm 1 is introduced, specifically designed for parsing the BPMN diagram. This diagram was previously developed by a process design expert for university outreach projects as a case study, providing a real-world context for the research.

3.2. Algorithm Parser or Translate BPMN to HDDL

The algorithm is designed to automate the process of translating BPMN diagrams into a more structured and machine-readable format, specifically an XML structure. This translation enables the BPMN diagram to be further processed and converted into an HTN planning domain structure in HDDL language, which is a standardized format for representing planning domains and problems. This algorithm facilitates the conversion of BPMN elements, such as activities, gateways, and events, into their corresponding representations in the HTN planning domain structure, including primitive tasks, methods, sub methods, and operators.

3.3. Artifact: PlanProjU

The PlanProjU system, designed within the framework of the DSR methodology, offers a structured approach to project planning. By taking the BPMN diagram of relevant university projects as input, the system translates this information into a HDDL domain, allowing for a comprehensive representation of project details. This process is facilitated by the planning expert, who translates project management descriptions into problems that can be solved by the system. The use of a BPMN diagram as input enables the capture of a significant amount of project semantics, ensuring that the generated plans are accurate and effective. The subsequent application of the SHOP 2 planner generates valid plans for project implementation, thereby providing a systematic and reliable approach to project management. Figure 2 shows the architecture.

Figure 2. Shows summarize the layered software architecture of PlanProjU, emphasizing a clear separation of concerns across four tiers and the end-to-end data flow required to generate HTN plans from BPMN models. At the presentation layer, a responsive web interface (React + Material UI) communicates over HTTP/HTTPS with the application layer, which exposes a REST API implemented with FastAPI and documented via OpenAPI, thereby enabling standardized service interaction and traceability. Security and governance are handled through an authentication module based on JWT tokens, user management, and RBAC, which constrains access to project operations and enforces role-dependent capabilities. The project management component orchestrates CRUD operations, file uploads, and metadata handling, delegating persistence responsibilities to the data layer, where PostgreSQL supports transactional storage (ACID) and JSONB structures, Redis provides coaching for hot data and TTL-based performance optimization, and file storage maintains BPMN files and associated documentation. Finally, the processing layer operationalizes the core research contribution: a BPMN parser performs XML processing, structural validation, and model feature extraction, feeding a planning engine that executes planning requests using alternative algorithms (SHOP 2 and Pyhop) to produce comparable plan variants. This pipeline illustrates an architecture designed for modularity and extensibility allowing independent evolution of the BPMN parsing subsystem, the planning back end, and the user-facing interface while also enabling systematic comparison of planning outcomes using consistent inputs and integrated execution within a single platform. Figure 3. Shows the component of PlanProjU.

Figure 3. Provides a component-level view of the PlanProjU platform, detailing how the user-facing modules are coupled to backend services and, ultimately, to the HTN planning engine through a controlled processing pipeline. At the frontend, the workflow begins with the Login Module (secure credentials and validation form), continues with BPMN Upload (drag-and-drop plus format validation), and culminates in three key capabilities: (i) a Plan Visualizer that supports hierarchical tree inspection and visual comparison, (ii) a Configuration panel to set algorithm parameters and user preferences, and (iii) an Exporter that generates multi-format outputs (PDF/Excel/JSON). These interactions are mediated by backend services organized around JWT-based authentication (token generation, session management, security layer), project management (CRUD operations, file/metadata handling), a planning service that acts as an orchestrator (algorithm selection and asynchronous execution), and an administration module for user/system configuration and analytics. Within the processing engine, the BPMN parser performs XML parsing, schema validation, and structural extraction, producing the planning-ready representation that is then executed by two alternative planners SHOP2 (hierarchical HTN, depth-first search, cost optimization) and a Pyhop-based engine (state-based HTN execution). Plan outputs and runtime metrics are consolidated by a dedicated Metrics Analyzer that supports quality assessment, performance statistics, and comparative evaluation, and the resulting data is fed back to the frontend for visualization and decision support. Overall, architecture evidences a modular design that makes the planning subsystem, metric evaluation, and UI-layer comparison tightly integrated but independently evolve an important property for replicable experimentation and iterative enhancement in a research-grade planning platform. Figure 4 shows the usage layers.

Figure 4 formalizes the interaction model of PlanProjU by mapping system actors to the platform’s core use cases, making explicit how permissions and responsibilities are operationalized across the workflow. At the top, two actor profiles structure the access-control logic: the Operational User, who executes the end-to-end project planning flow with full access to planning functions, and the Administrator, who holds supervisory privileges with total system access for governance, configuration, and user management. These roles connect to a set of use cases that represent the platform’s functional backbone. The operational flow begins with Upload BPMN Project (XML upload, schema validation, and storage), proceeds to Generate Plans (execution of SHOP 2 and Pyhop with AI-driven processing), and then to Compare Alternatives, where users inspect plan outputs through metric-based analysis, visualization, and a consolidated quality score. The workflow is complemented by Export Results, enabling multi-format reporting (PDF/Excel/JSON) and customizable report generation, which supports traceability and offline review. In parallel, the platform exposes governance-oriented functions Configure Parameters (algorithm settings, advanced adjustments, and fine-tuning) and Manage Users (CRUD operations, roles/permissions, and access control) which are primarily aligned with the administrator’s responsibilities but may be visible depending on privilege assignment. Overall, the diagram demonstrates a clear separation of concerns between operational execution and system administration, while ensuring that the full planning lifecycle from BPMN ingestion to plan evaluation and reporting is supported under a coherent role-based access control (RBAC) scheme.

4. Experiments

Experiments were conducted using PlanProjU with a dual objective. Firstly, to verify that well-structured process models selected for this purpose possess a corresponding HTN representation capable of capturing the knowledge inherent in the process. This objective is crucial as it ensures that the HTN representation accurately reflects the complexities of the process, thereby enabling effective planning and scheduling. Secondly, to demonstrate the feasibility of using this approach to facilitate a planning process that generates a contextual plan, considering the ordering of tasks and resource requirements for university projects. The experiments were specifically designed to showcase the planning and scheduling capabilities of the developed approach, thereby providing a comprehensive evaluation of its effectiveness. This demonstrates that knowledge structured in BPMN format can be effectively captured in an HTN action model for planning purposes, given the level of detail typically required for university projects. The successful implementation of this approach highlights its potential for real-world applications, particularly in the context of university projects where complex planning and scheduling are essential.

Specifically, the following are some of the expected results of these experiments: 1) verifying that a corresponding HTN representation exists for process models that include a combination of workflow patterns; 2) finding a plan instance that preserves the semantics associated with those workflow patterns; 3) verifying that the interpretation of the same HTN action model can find different plan instances for different combinations of input parameters. The successful application of PlanProjU in real-world processes demonstrates its practical utility. Notably, it has been utilized in three distinct university projects: patenting, co-creation, and the construction of a science, technology, and innovation laboratory. These projects, managed simultaneously within the framework of open innovation and intellectual capital of two Colombian universities, showcase the versatility of PlanProjU.

Researchers are strongly advised to utilize a computer equipped with a minimum of 32 GB of RAM, a hard drive with a storage capacity of at least 500 GB, and the Python programming language installed. Furthermore, it is highly recommended that they conduct tests on Google Collaboratory from a Gmail account to guarantee compatibility with the user interface. User experience evaluations have consistently shown that the system requires approximately 0.5 minutes to start up. On average, decision makers utilized the BPMN upload function 14.8 times and accessed and saved plan information 15.3 times. In addition, this study systematically tested all execution plan generation processes contextualized with the university project. The plan generation process for different projects was repeated five times, introducing different BPMN models and action enhancements to the HTN planning domain action model. This rigorous validation process helped verify various metrics such as the number of actions, tree depth, length, and size of the plans generated for each project.

The evaluation methodology for the PlanProjU system adhered strictly to the human evaluation approach outlined by Owczarzak (2012) [51], which emphasizes the necessity of establishing explicit evaluation criteria to enable users to objectively assess a system’s quality and interoperability. This approach ensures that the evaluation process is thorough and reliable. The system was rigorously tested for one week by eight project managers from diverse fields at Colombian universities, thereby providing a comprehensive and unbiased usability assessment for university project management. For the first experiment, the UNAL-Audifarma extension project was used, which generated the following planning domain and problems in PlanProjU.

Domain:

(define (domain university_extension)

(:requirements :typing :hierarchy :equality)

(:types actor resource project material document task)

(:predicates

        (done ?t - task)

        (available ?r - resource)

        (assigned ?a - actor ?p - project)

        (created ?m - material)

        (approved ?d - document)

        (completed ?t - task)

        (executed ?t - task)

)

(:action solicitar_curso

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)

(:action enviar_propuesta

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)

(:action revisar_y_decidir

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)

(:action definir_fechas_y_horarios

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)

(:action asignar_costos_adicionales_empresa_asume

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)

(:action asignar_docente_y_plataforma_meet

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)

(:action mdulo_1_generalidades

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)

(:action mdulo_2_habilidades_de_un_buen_formador

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)………

Problem 1

(define (problem docente_problem)

(:domain university_extension)

(:objects

        a_docente - actor

        r_docente - resource

        p_docente - project

        m_docente - material

        d_docente - document

)

(:init (available r_docente))

(:tasks (t1 (docente_project a_docente r_docente p_docente m_docente d_docente)))

(:goal (done p_docente))

)

Problem 2

(define (problem universidad_nacional_de_colombia_problem)

(:domain university_extension)

(:objects

        a_universidad_nacional_de_colombia - actor

        r_universidad_nacional_de_colombia - resource

        p_universidad_nacional_de_colombia - project

        m_universidad_nacional_de_colombia - material

        d_universidad_nacional_de_colombia - document

)

(:init (available r_universidad_nacional_de_colombia))

(:tasks (t1 (universidad_nacional_de_colombia_project a_universidad_nacional_de_colombia r_universidad_nacional_de_colombia p_universidad_nacional_de_colombia m_universidad_nacional_de_colombia d_universidad_nacional_de_colombia)))

(:goal (done p_universidad_nacional_de_colombia))

)

Problem 3

(define (problem universidad_nacional_de_colombia_problem)

(:domain university_extension)

(:objects

        a_universidad_nacional_de_colombia - actor

        r_universidad_nacional_de_colombia - resource

        p_universidad_nacional_de_colombia - project

        m_universidad_nacional_de_colombia - material

        d_universidad_nacional_de_colombia - document

)

(:init (available r_universidad_nacional_de_colombia))

(:tasks (t1 (universidad_nacional_de_colombia_project a_universidad_nacional_de_colombia r_universidad_nacional_de_colombia p_universidad_nacional_de_colombia m_universidad_nacional_de_colombia d_universidad_nacional_de_colombia)))

(:goal (done p_universidad_nacional_de_colombia))

For the second experiment, the extension project of the University of Caldas #304 was used, which generated the following planning domain and problem in PlanProjU.

Domain:

(define (domain university_extension)

(:requirements :typing :hierarchy :equality)

(:types actor resource project material document task)

(:predicates

        (done ?t - task)

        (available ?r - resource)

        (assigned ?a - actor ?p - project)

        (created ?m - material)

        (approved ?d - document)

        (completed ?t - task)

        (executed ?t - task)

)

(:action recopilar_informacin_del_proyecto

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)

(:action diligenciar_datos_generales_ttulo_modalidad_coordinador_duracin_fechas_lugar

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)

(:action redactar_descripcin_problema_y_antecedentes

        :parameters (?a - actor ?r - resource ?p - project)

        :precondition (and (available ?r))

        :effect (and (done ?p) (executed ?p))

)…….

Problem:

(define (problem proyecto_principal_problem)

(:domain university_extension)

(:objects

        t_recopilar_informacin_del_proyecto - task

        t_diligenciar_datos_generales_ttulo_modalidad_coordinador_duracin_fechas_lugar - task

        t_redactar_descripcin_problema_y_antecedentes - task

        t_definir_articulacin_con_planes_institucionales_pdi_ppu_plan_facultaddepartamento - task

        t_definir_objetivo_general_y_objetivos_especficos - task

        t_definir_metodologa_diseo_desarrollo_evaluacin_y_oferta - task

         t_definir_catlogoportafolio_de_educacin_continuada_cursos_diplomados_talleres - task

        t_definir_poblacin_beneficiada_y_cantidad_esperada - task

        t_definir_novedad_de_la_propuesta - task

        t_definir_impacto_esperado - task

        t_definir_productos_esperados - task

        t_revisar_coherencia_y_completar_la_propuesta - task

        t_ajustar_contenido_y_anexos_de_la_propuesta - task

        t_enviar_propuesta_a_la_convocatoria_interna - task

        proyecto_principal - actor

)

(:init

        (pending t_recopilar_informacin_del_proyecto)

        (assigned_to t_recopilar_informacin_del_proyecto proyecto_principal)

        (can_start t_recopilar_informacin_del_proyecto)

        (pending t_diligenciar_datos_generales_ttulo_modalidad_coordinador_duracin_fechas_lugar)

        (assigned_to t_diligenciar_datos_generales_ttulo_modalidad_coordinador_duracin_fechas_lugar proyecto_principal)

        (pending t_redactar_descripcin_problema_y_antecedentes)

        (assigned_to t_redactar_descripcin_problema_y_antecedentes proyecto_principal)

        (pending t_definir_articulacin_con_planes_institucionales_pdi_ppu_plan_facultaddepartamento)

        (assigned_to t_definir_articulacin_con_planes_institucionales_pdi_ppu_plan_facultaddepartamento proyecto_principal)

        (pending t_definir_objetivo_general_y_objetivos_especficos)

        (assigned_to t_definir_objetivo_general_y_objetivos_especficos proyecto_principal)

        (pending t_definir_metodologa_diseo_desarrollo_evaluacin_y_oferta)

        (assigned_to t_definir_metodologa_diseo_desarrollo_evaluacin_y_oferta proyecto_principal)

        (pending t_definir_catlogoportafolio_de_educacin_continuada_cursos_diplomados_talleres)

        (assigned_to t_definir_catlogoportafolio_de_educacin_continuada_cursos_diplomados_talleres proyecto_principal)

        (pending t_definir_poblacin_beneficiada_y_cantidad_esperada)

        (assigned_to t_definir_poblacin_beneficiada_y_cantidad_esperada proyecto_principal)

        (pending t_definir_novedad_de_la_propuesta)

        (assigned_to t_definir_novedad_de_la_propuesta proyecto_principal)

        (pending t_definir_impacto_esperado)

        (assigned_to t_definir_impacto_esperado proyecto_principal)

        (pending t_definir_productos_esperados)

        (assigned_to t_definir_productos_esperados proyecto_principal)

        (pending t_revisar_coherencia_y_completar_la_propuesta)

        (assigned_to t_revisar_coherencia_y_completar_la_propuesta proyecto_principal)

        (pending t_ajustar_contenido_y_anexos_de_la_propuesta)

        (assigned_to t_ajustar_contenido_y_anexos_de_la_propuesta proyecto_principal)

        (pending t_enviar_propuesta_a_la_convocatoria_interna)

        (assigned_to t_enviar_propuesta_a_la_convocatoria_interna proyecto_principal)

)

(:htn :tasks (t1 (gestionar_proyecto_principal proyecto_principal)))

(:goal (and (completed t_recopilar_informacin_del_proyecto) (completed t_diligenciar_datos_generales_ttulo_modalidad_coordinador_duracin_fechas_lugar) (completed t_redactar_descripcin_problema_y_antecedentes) (completed t_definir_articulacin_con_planes_institucionales_pdi_ppu_plan_facultaddepartamento) (completed t_definir_objetivo_general_y_objetivos_especficos) (completed t_definir_metodologa_diseo_desarrollo_evaluacin_y_oferta) (completed t_definir_catlogoportafolio_de_educacin_continuada_cursos_diplomados_talleres) (completed t_definir_poblacin_beneficiada_y_cantidad_esperada) (completed t_definir_novedad_de_la_propuesta) (completed t_definir_impacto_esperado) (completed t_definir_productos_esperados) (completed t_revisar_coherencia_y_completar_la_propuesta) (completed t_ajustar_contenido_y_anexos_de_la_propuesta) (completed t_enviar_propuesta_a_la_convocatoria_interna)))

)

5. Results

The research demonstrates a platform that combines an HTN planning environment with the capture of base knowledge for any university project represented in the BPMN standard. This platform produces plans that help project managers choose the best approach for implementing a project at a university. Project formulators or those responsible for executing university projects can obtain implementation plans for different university contexts through the system, which is user-centered. Rather than requiring a planning expert to model actions and problems, the platform accepts a BPMN diagram in .xml format. By mapping the diagram, the platform captures approximately 98 % of the data and automatically generates multiple plans for a project. These plans incorporate activity costs and complexity parameters provided by the project formulators, allowing the best plan to be selected for implementation. The system automates the generation of diverse project implementation plans, enabling university project planners to focus on decision-making and critical analysis. This is achieved by incorporating cost metrics and visualizing plan length and execution time using an HTN planners SHOP 2 and PyHOP in this research.

The research demonstrates how the PlanProjU system integrates an HTN planning environment with a BPMN knowledge source specifically for university projects. It generates a variety of plans based on different metrics, thereby supporting project implementation within the university context. Project developers can automate implementation or execution by generating plans, while the system remains focused on the user’s needs. Usability tests were carried out with 3 public universities in Colombia. For the UNAL-Audifarma project, the following BPMN was generated on the bpmn.io platform, as shown in Figure 5.

Figure 5. Represents a BPMN model of the Audifarma-UNAL Train-the-Trainer extension project, structured by pools/lanes that define responsibilities (requestor, course coordination/management, and teaching/delivery role). The flow begins with the course request and the preparation/submission of the proposal, followed by a review and decision activity supported by a dedicated gateway, which branches the process toward approval or closure due to rejection. In case of approval, the model incorporates planning activities such as defining dates and resource allocation, as well as a gateway that specifies logistical and/or cost conditions, articulated with the rule that additional costs are assumed by the company. Then, the delivery of the course (3 hours per session and 5 sessions) is connected to the attendance record, which acts as compliance control: a final gateway applies the certification policy, where a certificate is only issued if the participant attends at least 80% of the classes; Otherwise, it leads to the event of non-certification. Overall, the diagram demonstrates a process with explicit decision points, cost traceability, and a verification mechanism (attendance) that ensures consistency between the provision of the training service and the institutional certification criteria.

The interaction with each official took approximately 1 to 1.5 hours, given the interruptions during the platform demonstration meeting. Each official was given a tour to navigate the platform and informed that a question mark in the upper right corner contained a guide developed within the platform to help them build the BPMN. During the interactions, some officials felt it necessary to view the file in BPMN or XML format. They were informed that this visualization was not available on the PlanProjU platform, as it focuses on HTN-type artificial intelligence planning and not on generating diagram visualizations under the BPMN standard. However, it is made clear to them that with the bpmn.io tool they can load the generated bpmn or xml file to visualize and modify the diagram, and that the integration of a visualization module into the platform’s architecture is considered as future research work. Figure 6 shows the plans generated in PlanProjU.

Figure 6. The output of PlanProjU for the Audifarma - UNAL Trainer Training case study is shown. The platform generates six plans, with three variants for each planner: SHOP2 and PyHOP. It presents, in summary form, the best plan from each algorithm along with an overall recommendation based on the lowest cost criterion. This organization is relevant for validation because it transforms the result of the BPMN 2.0 process into a set of comparable alternatives based on cost and step length metrics. This allows the end user or public official to evaluate not only a single plan but also the stability of the solution against different search/heuristic variants.

Analyzing the National University of Colombia block reveals a clear trade-off between economic efficiency and plan length: SHOP2 is selected as the best in its family with a cost of 6 and 7 steps, while Pyhop v3 has a cost of 7 with 4 steps. Consequently, the platform recommends SHOP2 because it is one unit cheaper, even though the plan is longer. This behavior suggests that, for this project, the search process penalizes certain decisions more significantly than simply reducing the number of activities. In terms of interpretation, Pyhop seems to produce plans with fewer steps but a higher overall cost; SHOP2, on the other hand, achieves preferable solutions, which is consistent with scenarios were breaking down activities further allows for choosing less expensive alternatives.

Finally, when comparing the three panels Requesting Company, National University, and Professor it is clear that the platform maintains the same decision logic and explicitly highlights the sensitivity of the result: for example, in the Requesting Company panel, the recommendation favors SHOP 2 due to a marked cost difference of 1 vs. 5, while in the Professor panel, the advantage of SHOP 2 also remains (5 vs. 7), although with shorter plans of 4–5 steps. This cross-cutting consistency reinforces the usefulness of PlanProjU as a decision support tool, since the user, as an extension office staff member, can justify the selection of the recommended plan based on quantifiable differences. Furthermore, they can examine alternatives (v1–v3) when cost is not the only relevant criterion. Taken together, the figures demonstrate that the validation process is not limited to generating plans but also enables a reproducible comparative analysis between the plans generated by the planners.

Table 1. Plan found for project to UNAL-Audifarma with PyHOP.

Plan 1	Plan 2	Plan 3
client_need_management3	client_need_management3	client_need_management3
proposal_presentation3	proposal_presentation3	proposal_presentation3
technical_and_financial_analysis_of_the_proposal3	approval_by_the_faculty_council3	verify_proposal_presentation2
request_for_approval_from_the_research_and_extension_committee6	campus_council_approval_if_applicable_	technical_and_financial_analysis_of_the_proposal6
approval_by_the_faculty_council6		request_for_approval_from_the_research_and_extension_committee6
campus_council_approval_if_applicable_		verify_request_for_approval_from_the_research_and_extension_committee4
		approval_by_the_faculty_council9
		campus_council_approval_if_applicable_

Table 1. Plan found for project to UNAL-Audifarma with PyHOP.

Plan 1	Plan 2	Plan 3
client_need_management3	client_need_management3	client_need_management3
proposal_presentation3	proposal_presentation3	proposal_presentation3
technical_and_financial_analysis_of_the_proposal3	approval_by_the_faculty_council3	verify_proposal_presentation2
request_for_approval_from_the_research_and_extension_committee6	campus_council_approval_if_applicable_	technical_and_financial_analysis_of_the_proposal6
approval_by_the_faculty_council6		request_for_approval_from_the_research_and_extension_committee6
campus_council_approval_if_applicable_		verify_request_for_approval_from_the_research_and_extension_committee4
		approval_by_the_faculty_council9
		campus_council_approval_if_applicable_

Table 2. Plan found for project to UNAL-Audifarma with SHOP 2.

Plan 1	Plan 2	Plan 3
execute_request_for_approval_from_the_research_and_extension_committee34	execute_technical_and_financial_analysis_of_the_proposal38	execute_proposal_presentation33
execute_technical_and_financial_analysis_of_the_proposal40	execute_approval_by_the_faculty_council46	execute_campus_council_approval_if_applicable29
execute_client_need_management40	execute_technical_and_financial_analysis_of_the_proposal38	execute_campus_council_approval_if_applicable45
execute_campus_council_approval_if_applicable	execute_approval_by_the_faculty_council45	execute_client_need_management
	execute_proposal_presentation39
	execute_request_for_approval_from_the_research_and_extension_committee

Table 2. Plan found for project to UNAL-Audifarma with SHOP 2.

Plan 1	Plan 2	Plan 3
execute_request_for_approval_from_the_research_and_extension_committee34	execute_technical_and_financial_analysis_of_the_proposal38	execute_proposal_presentation33
execute_technical_and_financial_analysis_of_the_proposal40	execute_approval_by_the_faculty_council46	execute_campus_council_approval_if_applicable29
execute_client_need_management40	execute_technical_and_financial_analysis_of_the_proposal38	execute_campus_council_approval_if_applicable45
execute_campus_council_approval_if_applicable	execute_approval_by_the_faculty_council45	execute_client_need_management
	execute_proposal_presentation39
	execute_request_for_approval_from_the_research_and_extension_committee

Figure 7 shows the metrics for the plans generated for the UNAL-AUDIFARMA extension project.

Figure 7 provides a quantitative side-by-side comparison of the plans generated by the two HTN planners (SHOP 2 vs. PyHOP) using two decision metrics: total cost and number of steps. In the upper chart, SHOP 2 achieves a substantially lower aggregate cost than PyHOP, and the dashboard explicitly reports a cost gap of 33 units, indicating that under the same problem encoding and cost model SHOP 2 produces a solution that is more cost-efficient for this case. In the lower chart SHOP 2 also returns a shorter plan (fewer actions) than PyHOP, which suggests a more compact decomposition and/or fewer required operator applications to reach the goal state. Taking together, these results support the platform’s recommendation logic: SHOP 2 is preferable here because it dominates PyHOP on both criteria (lower cost and fewer steps), which typically implies reduced execution effort, lower resource consumption, and a simpler implementation trajectory for the underlying BPMN-derived project activities. For the Universidad de Caldas project, the following BPMN was generated on the bpmn.io platform, as shown in Figure 8.

Figure 8. Represents an end-to-end BPMN flow that structures the process as a chain of sequential activities, interrupted by decision points that determine alternative paths and control the case’s evolution until its closure. In modeling terms, the diagram shows a defined main path (start → execution of operational tasks → completion), complemented by conditional branches that introduce exception or validation scenarios. This architecture is relevant to the thesis because it allows us to justify that the model is not limited to listing tasks, but rather captures business logic, dependencies, and continuity criteria, which increases the process’s fidelity to the actual operation. Furthermore, the presence of explicit decisions facilitates the transition to automated planning: each task can be formalized as an action (with preconditions and effects), while the decision points translate into conditions that define multiple execution paths and enable the comparison of solutions in terms of cost and number of steps, aligning with the objective of evaluating implementation variants within the platform. Figure 9. Shows the plans generated in PlanProjU.

Figure 9. Shows the platform’s plan comparison module, where the best plan generated by SHOP 2 is compared to the best plan generated by PyHOP in terms of total cost (objective function) and number of steps. In this case, SHOP 2 selects the option with a cost of 19 and 3 steps as optimal, while PyHOP reports its variant with a cost of 66 and 10 steps as best. This supports the interface’s automatic recommendation in favor of SHOP 2, as it is 49 units less expensive. The breakdown of the SHOP 2 plan shows a concrete and traceable sequence of activities, suggesting that the plan prioritizes a minimal procedure to reach the target state with the lowest aggregate cost. Similarly, the presence of multiple variants per planner reveals a range of solutions with cost-length trade-offs: SHOP 2 offers alternatives with simultaneous variations in cost and steps, while Pyhop maintains a constant length of 10 steps but with different costs (17 and 66), consistent with differences in search strategy and task decomposition. Overall, the figure supports the idea that the platform generates plans and allows users to select the best plan based on cost and step length metrics.

Table 3. Plan found for project to Universidad de Caldas with PyHOP.

Plan 1	Plan 2	Plan 3
collect_project_information3	collect_project_information3	collect_project_information3
fill_in_general_data__title__modality__coordinator__duration__dates__location_3	define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_3	fill_in_general_data__title__modality__coordinator__duration__dates__location_3
write_description__problem_and_background_3	define_general_objective_and_specific_objectives3	verify_fill_in_general_data__title__modality__coordinator__duration__dates__location_2
define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_6	define_continuing_education_portfolio_catalog__courses__diplomas__workshops_6	write_description__problem_and_background_6
define_general_objective_and_specific_objectives6	define_beneficiary_population_and_expected_quantity6	define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_6
define_methodology__design__development__evaluation_and_offering_6	define_novelty_of_the_proposal6	verify_define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_4
define_continuing_education_portfolio_catalog__courses__diplomas__workshops_9	define_expected_impact9	define_general_objective_and_specific_objectives9
define_beneficiary_population_and_expected_quantity9	define_expected_products9	define_methodology__design__development__evaluation_and_offering_9
define_novelty_of_the_proposal9	adjust_content_and_attachments_of_the_proposal9	verify_define_methodology__design__development__evaluation_and_offering_6
define_expected_impact12	submit_proposal_to_the_internal_call	define_continuing_education_portfolio_catalog__courses__diplomas__workshops_12
review_coherence_and_complete_the_proposal12	define_novelty_of_the_proposal6	define_beneficiary_population_and_expected_quantity12
adjust_content_and_attachments_of_the_proposal15		verify_define_beneficiary_population_and_expected_quantity8
submit_proposal_to_the_internal_call		define_novelty_of_the_proposal15
		define_expected_impact15
		verify_define_expected_impact10
		define_expected_products18
		review_coherence_and_complete_the_proposal18
		verify_review_coherence_and_complete_the_proposal12
		adjust_content_and_attachments_of_the_proposal21
		submit_proposal_to_the_internal_call

Table 3. Plan found for project to Universidad de Caldas with PyHOP.

Plan 1	Plan 2	Plan 3
collect_project_information3	collect_project_information3	collect_project_information3
fill_in_general_data__title__modality__coordinator__duration__dates__location_3	define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_3	fill_in_general_data__title__modality__coordinator__duration__dates__location_3
write_description__problem_and_background_3	define_general_objective_and_specific_objectives3	verify_fill_in_general_data__title__modality__coordinator__duration__dates__location_2
define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_6	define_continuing_education_portfolio_catalog__courses__diplomas__workshops_6	write_description__problem_and_background_6
define_general_objective_and_specific_objectives6	define_beneficiary_population_and_expected_quantity6	define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_6
define_methodology__design__development__evaluation_and_offering_6	define_novelty_of_the_proposal6	verify_define_alignment_with_institutional_plans__PDI__PPU__faculty_department_plan_4
define_continuing_education_portfolio_catalog__courses__diplomas__workshops_9	define_expected_impact9	define_general_objective_and_specific_objectives9
define_beneficiary_population_and_expected_quantity9	define_expected_products9	define_methodology__design__development__evaluation_and_offering_9
define_novelty_of_the_proposal9	adjust_content_and_attachments_of_the_proposal9	verify_define_methodology__design__development__evaluation_and_offering_6
define_expected_impact12	submit_proposal_to_the_internal_call	define_continuing_education_portfolio_catalog__courses__diplomas__workshops_12
review_coherence_and_complete_the_proposal12	define_novelty_of_the_proposal6	define_beneficiary_population_and_expected_quantity12
adjust_content_and_attachments_of_the_proposal15		verify_define_beneficiary_population_and_expected_quantity8
submit_proposal_to_the_internal_call		define_novelty_of_the_proposal15
		define_expected_impact15
		verify_define_expected_impact10
		define_expected_products18
		review_coherence_and_complete_the_proposal18
		verify_review_coherence_and_complete_the_proposal12
		adjust_content_and_attachments_of_the_proposal21
		submit_proposal_to_the_internal_call

Table 4. Plan found for project to Universidad de Caldas with SHOP 2.

Plan 1	Plan 2	Plan 3
execute_review_coherence_and_complete_the_proposal38	execute_write_problem_description_and_background45	execute_collect_project_information42
execute_define_beneficiary_population_and_expected_quantity30	execute_collect_project_information38	execute_define_expected_impact39
execute_fill_in_general_data_title_modality_coordinator_duration_dates_location	execute_define_general_objective_and_specific_objectives35	execute_fill_in_general_data_title_modality_coordinator_duration_dates_location
		execute_adjust_content_and_attachments_of_the_proposal33
		execute_define_expected_impact29
		execute_define_general_objective_and_specific_objectives

Table 4. Plan found for project to Universidad de Caldas with SHOP 2.

Plan 1	Plan 2	Plan 3
execute_review_coherence_and_complete_the_proposal38	execute_write_problem_description_and_background45	execute_collect_project_information42
execute_define_beneficiary_population_and_expected_quantity30	execute_collect_project_information38	execute_define_expected_impact39
execute_fill_in_general_data_title_modality_coordinator_duration_dates_location	execute_define_general_objective_and_specific_objectives35	execute_fill_in_general_data_title_modality_coordinator_duration_dates_location
		execute_adjust_content_and_attachments_of_the_proposal33
		execute_define_expected_impact29
		execute_define_general_objective_and_specific_objectives

Figure 10 Shows the metrics for the plans generated for the Universidad de Caldas extension project.

Figure 10. reinforces the comparative evaluation between SHOP2 and PyHOP using the same two decision criteria: total cost and plan length (number of steps). In the upper panel the platform reports a cost difference of 189 units, with SHOP 2 producing a markedly lower-cost plan than Pyhop; this indicates that, under the configured cost function SHOP 2 finds a solution that is substantially more resource-efficient for the same BPMN-derived planning problem. In the lower panel SHOP 2 also generates a shorter plan (roughly a third of PyHOP’s steps in this case), which suggests a more compact decomposition and fewer operator applications to reach the goal. Overall, the joint dominance of SHOP 2 on both metrics (lower cost and fewer steps) provides strong operational evidence for the dashboard’s recommendation, since it implies lower effort, reduced cumulative resource consumption, and a simpler implementation trajectory for the project activities represented in the underlying process model.

6. Discussion

The research results introduce an innovative method that surpasses existing approaches analyzed in academic literature and offers a practical alternative for implementing university projects by converting them into BPMN process standards. These processes can then be modeled by PlanProjU to generate implementation plans for each project, supported by HTN planning with two planners: SHOP 2 and PyHOP. This method significantly improves the project implementation process in university environments by providing project developers with a robust, automated tool for generating user-centered plans. Automating the generation of plans for university project implementation streamlines decision-making regarding the necessary conditions for successful completion and promotes the use of the BPMN standard to capture all the knowledge inherent in any formulated project.

The considerable difficulty of formulating a project, compounded by the biases inherent in the formulation process, necessitates capturing project knowledge using a standardized process such as BPMN. Furthermore, the lack of automation in various implementation scenarios increases costs for universities when executing projects aligned with their mission and strategic plans. Therefore, an HTN planning system like PlanProjU is essential for automating project implementation, as it generates plans that provide project designers with alternative scenarios and pathways to successfully complete projects within a university environment. The evaluation shows that the system generates plans for the various problems corresponding to each process. By applying the parsing or pre-planning algorithm, a general domain is generated in HDDL, along with separate problems for each branch variant, gateway, and subprocess, also expressed in HDDL. The evaluation focused on confirming that the parsing algorithm preserves the domain and problem structures under the HDDL formalism for three different projects generated by two different public universities in Colombia.

The evaluated projects correspond to an extension training program for an organization known as Audifarma, developed by the National University of Colombia, Manizales campus and the creation of an innovation office, developed by the University of Caldas. Optimalness metrics such as cost and completeness (i.e., plan length) were evaluated. These metrics were visually generated by PlanProjU for each project. PlanProjU allows the average user to verify whether the domain, problem, and generated plans accurately represent the evaluated project, and to approve or reject the project. If not, the administrator can then modify the planning engines and the pre-planning algorithm.

The PlanProjU platform proved effective in automatically extracting knowledge from domain-specific projects and planning problems described in the HDDL formalism. By employing SHOP 2 and PyHOP planners, it generates multiple alternative implementations plans for each project, with plan variations based on the cost and complexity parameters of each activity. This demonstrates that PlanProjU could be adopted by any university thanks to its portability and user-centered design. Using the BPMN standard, it can model any type of project and generate diverse implementation plans in a university environment, thus eliminating formulation bias and automating implementation through HTN planning.

7. Conclusions

This study introduces several improvements over previous research. First, it captures knowledge from university projects using the BPMN standard, reducing bias in project formulation. Second, it employs an algorithm or pre-planner that translates BPMN models to automatically create the HTN planning problem and action model in the HDDL formalism. Third, the PlanProjU system focuses on usability for university project planners, including those without prior experience with HTN-type automated planning.

Fourth, it is the first work to apply HTN planning to university project management, whereas previous studies have focused on areas such as robotics, logistics, production, and disaster relief. Fifth, by using the HDDL planning standard, the system can be generically implemented in any university interested in project management. Sixth, unlike other research on HTN, this study does not rely on large language models to generate domain and application problems for comparison with planners like SHOP 2 and PyHOP. Instead, our algorithm translates an ongoing project under the BPMN standard, which in turn generates an action model and planning problem.

This allows the end user to approve or reject the generated plans based on whether they accurately represent the information of the evaluated project. The research focuses on automating the generation of plans for project execution or implementation in a university context, thus addressing the cost and bias issues that arise during formulation and implementation with the help of HTN planning. Studies like this drive innovation and scientific progress by integrating two areas of knowledge: project management and automated planning such as HTN.

The innovations highlighted in this study include several key distinctions: while existing tools leverage broad language models to refine domain construction in PDDL and HTN, they omit consideration of the HDDL formalism and limit their testing to well-known domains, such as logistics, robotics, transportation, and risk management, for plan generation. In contrast, PlanProjU incorporates HDDL formalism, analyzing a new domain such as university projects to generate multiple plans using SHOP 2 and PyHOP planners, and offers an intuitive interface designed for non-technical users, including university project developers, thus opening new avenues for research in HTN planning and project management. Experimental validation with two universities and three different generated projects demonstrated that PlanProjU reduced the time required for project implementation. This efficiency was due to the automation of 98% of the knowledge gathered for projects conceived by extension offices. The resulting plans were endorsed and approved by extension officers at the Colombian universities in the case studies. These quantitative findings demonstrate that PlanProjU not only automates the execution and implementation of university projects but also enables the deployment of HTN artificial intelligence planning in previously unexplored contexts, generating effective results in project planning.

8. Future Work

Future research will aim to consolidate and broaden the methodological framework that merges Business Process Modeling and Notation (BPMN) with Hierarchical Task Network (HTN) planning to automate university outreach projects; although the present system successfully converts BPMN process structures into HDDL domains, additional effort is required to refine the semantic representation and contextual nuances of actors, resources, and control-flow dependencies, and by incorporating domain ontologies and knowledge graphs we can achieve a more accurate alignment between BPMN entities and HTN constructs, thereby enhancing the expressiveness of the resultant planning models.

Finally, the research agenda calls for integrating neuromyotonic learning methods to boost the system’s adaptability and predictive power; by blending machine-learning techniques with HTN symbolic reasoning the system can automatically learn action models, cost estimates, and decomposition patterns directly from project execution logs, and by leveraging large-language models and transformer-based architectures it can extract procedural knowledge from textual project documents.