Ontology in IT Projects Based on OSM

Abstract

Project management is the discipline of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria. However, there can exist a considerable amount of uncertainty in decision making for project management stemming from the typical complex characteristics of projects. This study focused on two primary objectives: (1) to understand the role of project management in complex situations and (2) to offer a more robust model for project management. Pertinent literature on models for project management was collected and synthesized for application in complex situations. A cybernetic-based model is then developed. This model enables a manager to focus on internal organizational complexity while paying enough attention to external perturbations. The utility of the model is demonstrated in a case application in an organization in Belgium.

1. Systemic management models and their link to project management

Today, a project is defined by a defined start and end, constrained by time, funds, and measured by expected deliverables. So, the project organization within an organization takes place within the confines of operations with a bearing on project management.

Aim of projects is to deliver value to customers. The task necessary to deliver value is intricately related to many factors, some of which can be beyond the scope of the project itself as it is related to being a temporary organization within an organization. Enterprises today are socio-technical systems, constantly interacting with an increasingly complex environment. Investments are often done within specific projects as a temporary organization within an organization. The OSTO^® System Model (OSM) deals with processes that are strongly interrelated and is a result of a combination of technology, work organization, and human communication. The OSM is robust and mature model used over years in several management reorganizations [1].

As mentioned above, a project is aimed to delivers outputs as deliverables. In a good design, the output is the customers expected out-come, following the objectives. In the OSM, the objectives are injected into the system as a target to be reached while the system delivers the output. One should deliver what is requested, in the scope, quality, timing, and within budget, for the system to be considered reliable. Thus, one can conclude that an output is not sufficient but necessary. Clearly, other terms need to be considered. These include mission statements involving reason of existence and meaning. Reason for system existence relates to the needs or expectations of customers to make use of the products or services of the business system ( Figure 1 ). It is imperative that system actors know the “reason of existence” of the system. This involves long-term value-creation of the system leading to future-oriented execution of output, long-term thinking, and looking forward at the wider context rather than exclusively considering the economic reality of today [2].

Figure 1.

Complex cybernetic investment management framework based on OSM.

As previously mentioned, system components interact among themselves with a given system, as well as interacting with the environment. There is the need for stability and orientation within investment management. This orientation can only be given on a vision level through the statement of the system meaning. As suggested by a cybernetic model of a system, long-term survival of the business depends on having defined sustainable and future-oriented meaning statements. The focus here is on the system usefulness in terms of sustainability involving context of individual, cultural, ethical questions, and expectations within society. Such meaning statements imply that there are values defined for the owner of the investment. In this case, values are one-dimensional for measuring effectiveness. Effectiveness is assessed by quality metric, and efficiency is also measured as a productivity metric. Quality of output, in this perspective, is related to products or services especially the value assigned by the customers.

Beyond the original OSM, two new artifacts are introduced in the system model: Actor and Sensor. The actor has the responsibility to understand certain orders (e.g., management decisions) and translate them into actions. As the actor injects signals into the system, the sensor extracts information from the system and its output, and changes this information into a certain language to allow closing the cybernetic loop toward the actor.

A project as system consists of at least three main elements: objectives, inputs, and outputs. Objectives include a description of a situation beyond project conclusion. In objectives, there is also need to consider constraints that would enable or hinder the project as well as ensuring enough focus to enable delivery of the expected outcomes. Furthermore, objectives might depend on non-linearity of the situation which could be dominated by “the butterfly effect.” For a project manager, this implies that managing of a project is not static, since objectives could change based on individual, social, and environmental factors.

Inputs describe everything the project gets to execute, including all necessary actions and tasks, to deliver outputs according objectives. As the project is being executed, inputs are expected to change. Therefore, input is not fixed in time but is dynamic. Additionally, and in complex projects, it is expected that resources, associated with inputs, will change during execution. Reasons associated with such changes include, but not limited to capabilities, contractual obligations, and illness to stakeholders. Moreover, the scope could be redefined by the newly discovered insights in design and unforeseen circumstances. Outputs are everything the project produces. This involves physical and theoretical outputs. Physical outputs are the deliverables including documents, software, and equipment. Theoretical outputs include insights, knowledge, and experiences. In this case, projects, like complex systems, will have interacting components and processes, influencing output.

The OSM identifies three processes: Target Core Process (TCP), Individual Core Process (ICP), and Organizational Core Process (OCP). TCP combines all activities, communication, and tasks necessary to produce the expected output. This is known as one-dimensional project management. ICP is influenced by the mood of each individual human, which can be influenced by situations within and outside the system. OCP considers interactions among individuals, system organization, and the project itself [3].

As previously suggested, there are “hard” and “soft” elements and that these interact in project management. The sensor interprets the output of the system and provides measurements for the management. The sensor also looks on other steering parameters like objectives, reason for existing, reason for meaning and basic reason, as well as their changes. However, each sensor has a limited view of the system by its own boundaries. The actor gets the results of the project managers decisions based on the data of the sensor. These results will be transformed into steering input. Then, the actor injects this into the system in a structured way to steer the project. However, this planning is with uncertainties. Moreover, the system must contend with external disturbances, involving inputs not planned for or foreseen by the steering. These disturb the efficiency and effectiveness of the system.

2. Model of the system

Starting with the abstraction that the probability of each state of a system is 100%, it is possible to model system dynamics and interactions. Any process or change in state of the system is represented as a transformation. We define the function T as one-to-one which means that an initial state S_(t + 1) always mapped onto a single state S_(t). The function can be used as a dynamical representation to model the interactions between components of a system. The project manager is a system, represented as a Project Manager. He affects the system P or the project itself. We assume that the state of P, at time t + 1, is dependent on the state of the project at time t.

E1

S_PM plays the role of the input of the project. In general, the project will not only be affected by an outside system, but also be effected by other systems causing external disturbance (S_ED).

E2

The project is aimed to produce output which is system S_O. This leads to the transition

E3

a project is a process that transforms input into output. If the observer does not know the states of the project, and precise transformations T and T′, then the project acts as a black box for the observer. By experimenting with the sequence of inputs S_PM(t), S_PM(t + 1), S_PM(t + 2), etc., and observing the corresponding sequence of outputs S_O(t + 1), S_O (t + 2), S_O (t + 3), …, the observer may try to reconstruct the dynamics of the project. In some cases, the observer can determine a state space SP so that both transformations become more deterministic, without being able to directly observe the properties, processes, or components of the project. Internal disturbing make modeling black-box a difficult endeavor.

A project manager is seen as the Observer. This notion is said to hold true for all decisions taken by a project manager in any project management process. Managers see the system as a linear one and try to master the feedback loop. However, since projects are nonlinear in nature, a project manager serving as observer, needs to be more trained to deal with uncertainty of nonlinear systems and focus on positive feedback of the project. This suggests that they might let the system freely float to a certain degree or even intentionally destabilize the system to learn the equilibriums and the resistance to change. Operating at the verge of chaos has been suggested as the most successful strategy to dealing with non-linear systems. Nonlinearity is based on the internal disturbance as well as parallel active processes. This suggests that traditional objectives of a project can have dependencies which are often beyond internal control mechanisms of the system including elements of reason for existing, reason for meaning, and basic reason. In such a case, a non-linear model of OSM is necessary.

At the beginning of the project (t = 0), the project manager provides the necessary input for the project. This input is, in the first place, clearly defined in objectives (i.e., what to deliver). In the second place, project manager provides the scope (i.e., how to deliver), resources (i.e., with what to deliver), and timings (i.e., when to deliver). These inputs are based on the planning of the project. After a control period, the project manager gets information out of the system SP(t) as output S_O(t). With this information, the project manager, S_PM, can make certain decisions. These decisions must be translated into input parameters. This enables the project S_P to change into the state t + 1.

This reflex is also basic for project organization. A team of project experts can be seen as system, S_P, while the decision makers as system, S_PM. The decision makers can get their guidance through higher level system representations of reason for existing, reason for meaning and basic reason. This system is normally known as steering committee (S_SC) ( Figure 2 ). When these systems are logically separate, a hierarchy is evident as shown in a basic organizational model [4].

Figure 2.

A basic organizational hierarchical model of a project.

3. Ontology of a project system

It is safe to say that each project starts with objectives. These objectives are a combination of different types of statements based on assumptions regarding the environment, E. These are realis moods of domain assumptions describing the environment of the requirements engineering problem as it is known. The second type of statements in objectives is irrealis mood statements describing situation-to-be, how the situation and environment should look like. These irrealis mood statements prescribe what the outcome of the project should be. Figure 3 shows that objectives can be described in functional requirements which are defined as goals (g) and non-functional requirements, which are divided into soft goals (f) and quality constraints, q [5].

Figure 3.

Types of statements within objectives.

With a justified approximation (jappr), it is possible to define softgoal, F, a quality constraint, Q, that can exist for which it is justified to assume that if the quality constraint, Q, is met, then the softgoal, F, is also automatically fulfilled as described in

Additionally, one can define a requisite (req) relation as an asymmetric relation defining that in order to make a certain statement true, another statement also needs to be true. This is valid for all statements within requirements (q, g, and s) but not for domain assumptions

for requirements. Similar equations are necessary for S (soft goals) and Q for quality constraints. Such requisite relations are important if there are hidden objectives. In this case, there are certain quality constraints, goals, or soft goals identified, which are not directly linked to the objectives, that could be an indicator for an implicit objective based on assumptions. Similar to the requisite relation, an exclude (excl) relation defines a symmetrical relation stating that some statements can exclude each other. These are indicators for conflicting objectives and not valid for quality constraints

for requirements. And again, similar equations are necessary for S (soft goals) and Q for quality constraints.

In project work, one can make a separation between domain assumptions, goals, soft goals, and quality constraints as objectives and the realized deliverables as linked output. For all objectives, O, there can be a corresponding objective (r_n, d_n, s_n) at least one deliverable d_m within the full set of deliverable, D, to fulfill a given objective. Notice that each deliverable is linked to one or more objectives and is the proven fulfillment of the objective.

This relationship can be described in by

. The full set of all deliverables, D, is the result of processes executed by resources with a necessary input. Figure 4 depicts type of expected inputs. This input is either information (both steering information or knowledge and expertise) or resources as describes in Figure 4 .

Figure 4.

Different types of input.

In analogy with the objectives, depicted in the equation above, one can define a justified approximation (jappr) between expertise “e,” and knowledge, “k”.

E4

We can also define similar requisite relations among budget, manpower, and raw material, as well as some exclude (excl) relation. Additionally, raw material, in each process step after the first process step, is also the deliverable of the first process step.

E5

With these inputs, output, transformation processes, and steering, one can model the traditional project based working. The transformations follow an environmental adapted approach. This could be traditional waterfall (sequencing) or agile approach (iterative):

E6

When comparing linear model with the real-life system, one can see that some additional artifacts are necessary to create a more accurate model. As the objectives are defined to contribute to a defined strategy, each transition must bring an added value. As we have defined the transition:

with

. The transition is not a linear one as assumed above. The transition depends on three processes and internal disturbances as shown below. Internal disturbance is unknown transitions of the systems generating risks. In this case, risk is the possibility of not being able to fulfill the objective as expected and not to deliver the deliverables linked to the objective:

• Target Core Process (TCP) with

  

• Individual Core Process (ICP) with

  

• Organizational Core Process (OPC) with

  

• Internal disturbance (ID) with

  

This led to an unsolvable equation based on the odd number of functions f and inputs i. This is in fact a characteristic for complex systems. Each of these transitions contributes to the delivery of the expected deliverable. Additionally, the external disturbance can be seen as input i_ED and depends on unknown environmental changes or changes brought about by stakeholders.

E7

This input can also be seen as a risk, since it is unknown to the system and similar modeled as other inputs.

Objectives are derived from strategic drivers. These strategic drivers, sd, are the concretization (detailed description) of the strategy, S. Each strategy has at least one strategic driver and at least one objective. The contribution of the objective to the strategic driver is an estimation, since the use of the deliverables linked to the objective is in the future. This estimation is mostly done in a matrix with value areas so that the contribution can be estimated [6].

The result of the estimation is mainly in odd categories (e.g., low, medium, and high) added by “non.” For each estimated contribution, a financial analysis of efficiency (e.g., Net Present Value and Return On Investment) is done to estimate the revenue. Within this calculation, a link is made among the necessary input of the project, the expected delivery, and the estimated revenue. This is done in the Business Case. This Business Case is the economical reason for existing (i.e., RFE) of the project. The calculation is based on the link between all elements of the input, I, necessary for all deliverables, d, linked to objective, o, in relation to the estimated contribution [7].

E8

As scope, timing, and resources (input) are related to each other by the “Devil’s triangle,” we can calculate each point as a variable of the two other points leading to the function to calculate the timings of the project:

E9

This unsolvable loop of equations can be approximated by different iterations and adapted estimations during the project definition. In case a level of uncertainty (at the stakeholders) is reached, the iterations will stop and the project is defined with all necessary information to execute the transition, T (process all input I to the desired deliverables D). The system is ready defined by Objectives

, expected deliverables

, Scope (transitions),

, Resources and input

, Risks (external and internal disturbance) TID and i_ED as well as Timings

. Similar to the definition of the link between objective and deliverable as

.

The link between objective and strategic driver/strategy, objective and Business Case, strategic driver/strategy and Mission, and Mission and Vision can be described similar. Mission is a foundational statement that describes the purpose of projects existence. It answers questions such as “why do we do what we do” and “who do we serve.” For each project, this is the Business Case that should distinguish one project from another. Within a Business Case, different statements are made, as seen in Figure 5 . Beside measurable economical facts, there is a possibility for quantifiable, measurable, and observable parameters. Additionally, all needed measurements need to be covered by having parameters concerning output, people, and organization [8].

Figure 5.

Statements in a Business Case.

Vision can be described as an image or description of the customers’ system after the implementation of the deliverables of the project. In this vision, a strategy is essential and takes different forms. It requires the use of strategic drivers to translate the strategy into the project objectives. Traditional approaches, as described above, or the use of moving averages can be used to define the strategic drivers, which are shown in Figure 6 .

Figure 6.

Strategic drivers.

The Sensor must be able to measure all outputs of the system. In this case, a Sensor, s, of the Target Core Process (Sensor _TCP) extracts all the necessary information from the system and prepares this information for management decision of the project manager who deals with system feedback:

, with

, and

.

The Sensor, s, for the Individual Core Process (Sensor_ICP) and for the Organizational Core Process (Sensor_OCP) identifies, similar to the Sensor _TCP, data according to parameters defined. As these are not always objective, other measurements are necessary. For the Sensor_ICP possible examples are, among others, Employee Satisfaction Surveys, Bilateral meetings, Coaching moments, Evaluations, and follow-up discussions.

For the Sensor_OCP possible examples are, among others, Outstanding reorganizations, “Over the fence” management of departments, and Leadership Decision Management Systems.

In reality, most of the sensors are focused on TCP second on OCP, and there is a minor group measuring the ICP. In opposite to that, studies show that the organizational aspects as well as the individual integration in the team are significantly impacting the result of the project. This is even more visible when looking the output in general. The output of the system is not only a set of deliverables but also changes in knowledge, experiences, and other insights [9].

However, different measurements can be combined and considered in a multi-dimensional matrix. The change periods, CP, is related with each other. An exact relation depends on the environment. Obvious in fast changes environments (e.g., mobile application development) the period is much shorter than in slow changing environments (e.g., industrial plant investments). This discussion provides a basis for linking different elements including sensors and system vision. A systematic overview of possible sensors is given in Figure 7 .

Figure 7.

Relating sensor and deliverables, objectives, reason for existing, mission as well as vision.

Up to this time, time aspect of dependency has been overlooked. However, this aspect is introduced by the Business Case which accounts for maximum in project duration and the return period. For the project, Business Case is translated into a “plan in time.” The plan is part of the steering and is indicated by the dotted line (box). Taking the picture Figure 7 , one can reduce the information into a class model Figure 8 to be able to design the system.

Figure 8.

Class model for deliverables, objectives, reason for existing, and vision.

As the information of the Sensor is multidimensional, it can be seen as a vector of information. The project manager executes a transformation of the information to create an input to the system:

with

.

In this transition, T_PM, project manager, S_PM, converts the information of the Sensor into input of the system. All necessary processes can be found in process-based method for effective project management. The output of this processes will be injected back into the system project SP by a translation f(IP). This translation helps in ensuring that missing resources are injected or that more material is provided.

4. Briefly use case

In this section, we provide an application of the developed model. A non-disclosure agreement prevents us from disclosing certain detailed information regarding the company (entity) of analysis. Therefore, some information is masked. However, we provide sufficient information to demonstrate the usability of the model. Within this company, different and sometime conflicting core activities are present. The global mission statement is translated into global strategic statements within each business unit and has a defined strategy for fulfilling the requested group strategy. Measurable strategic drivers are given and defined as Performance (mainly driven by Cost/income ration), Empowerment (mainly driven by maturity levels), Accountability (mainly cultural driven), Responsiveness (time2market), and local embeddedness (local compliance).

Additionally, the company wants to “aim to be the first company TOMORROW to be the reference … TODAY.” The given drivers on group level are defined on coarse grain level. Each Unit determined their own strategy to fulfill the expected groups’ strategy. Therefore, they defined meso-grain drivers to evaluate their own operations and investments, the so called “Rose.” This level is the strategy of the Business Unit and represents the next detailed level.

At this level, the link to the Business Case is already implemented as drivers for the investment analysis as analysis of efficiency or Business Case. The other drivers are defined for the purposes of ranking initiatives according to an added value without executing a detailed Business Case—called back-log. These drivers are separated into two groups (compare Figure 9 ). The first group is the “Externally drivers” and provides KPIs related to the company outside world, while the others took on “Internal aspects” of the organization.

Figure 9.

An example of statements, the case emerging from mission statement.

Besides business (BUS)-related drivers, the company also has information and technology (IT)-related drivers. These drivers are also defined on strategic level. Figure 10 shows a mapping indicating where drivers are complementary and where the drivers are supplementary.

Figure 10.

A list of strategic drivers used in a business unit and IT-related drivers.

As previously mentioned, all cases are listed in a “back-log.” In this back-log, all scope-items are listed and are prioritized according the drivers of the Business Unit as indicated above. While some of these items can be executed separately, others require a “project” approach. To define the priority, the value of each driver is defined and described along with the degree of performance.

The use of this methodology provides insights into the expected deliverables as well as the objectives. The deliverables are mentioned as a single line and describe the expected outcome of the task as clusters defining objectives. The objectives are mentioned as numbers in the list. The methodology can be seen in Figure 11 , but on confidentiality reasons the detail-content is blanked.

Figure 11.

Project links among sensor and deliverables, objectives, reason for existing, mission and vision.

At this level, we have identified several projects scope items with the exclusion of approximate relations between drivers. Interestingly, as some IT-related drivers are fulfilled, Business Unit drivers are also fulfilled. However, there can be contradictions among drivers. This is the case when, in one project, the meso-grain drivers are detailed into fine-grain drivers within the Business-Case. Figure 12 shows an example for strategic statements. The first statement was “to become the first with easy access techniques for the customers.” This follows the driver “to be the reference and the first of this easy-access today.” On the next level, the management decided that “using other identification and authentication technique” allows to assume (justified approximation) that these techniques will increase the easy access. Finally, a similar assumption is made to “use voice and face recognitions for identification.”

Figure 12.

An example of statements in the case of starting from mission statement.

Similar to this depicts another strategic statement ( Figure 13 ). Here, the company is obligated to fulfill the regulators request to be able provide legal provable identification and authentication. This follows the local embeddedness and compliance with the local regulations. The next management level assumed that only using legal accepted techniques can give evidence that the mission statement is fulfilled. This statement leads to the conclusion that old existing technique is actually the only technique for fulfilling the statement.

Figure 13.

A second example of statements in a case starting from mission statements.

Taking e₁ and f₂ as independent from each other in one system, the mission statement is without exclusions. On the next level, one sees that the statements are excluding each other excl (f ₂, f ₂) and excl (f ₃, e ₃)]. If a project, in this case, starts to increase easy access to the system, then the same project will be confronted with statements which will not allow the project to deliver successfully. The project manager needs to detect this exclusion and create another input into the system. This input is considered new information coming externally as information from another system, the company S_ED. The project itself faces the problem (S_P) and the Project Manager transforms this into the scope change (S_O). We can conclude that the project manager transforms information received, the exclusions, to allow for a change in scope, S_O, which results into a new scope, S_O(t + 1), as described. The project will deal with the highest exclusion. This means dealing with clarification of any legal provisions and authentication techniques. Once the exclusion of e₂ and f₂ excl (f ₂, e ₂)] is met, the project will deliver a solution which fits more to the mission of the company.

Another example of a project is a company deciding to respond to local markets with local front-ends in local language. This should increase the local embeddedness and time2market as the local developers do not need to translate. Subsequently, such a project reduces costs for the company. This type of a project also presents a unique opportunity in terms of using the same solution in other markets (i.e., regions and countries) that uses a different language, for example. In the case study, two different projects were defined from the “back-log” and the dilemma, as shown in Figure 14 . One project is a local implementation on the same SharePoint tenant as an international implementation. However, both projects are defining their case separately as described.

Figure 14.

Two project sequences in different entities using the same mission statement.

However, during the local translations and the concrete implementation in the BUS-Case, both the projects used different statements, d₂ and g₂. Obviously, both PM’s have different ways to deal with the issue of the excluding statements d₂ (passing translations and Multilanguage) and g₂ (maximizing reusability) to reach the statement d₁ (decreasing costs). Each might view the other statement “d₂” or reverse “g₂” (the decision) as a disturbance, and therefore try to mitigate its impact. On the other hand, both PM’s could elevate the issue to a higher level by using appropriate feedback loops. In the case study, both PM’s decided to escalate issue via their steering committee. These committees decided to escalate on an international level, where problems could be solved. This approach was taken since projects where able to show logical link of their own drivers to the drivers of the Business Unit and drivers on group level. The group steering committee decided that reusability should be implemented. This enabled savings of the second project to be used as subsidies to the first project. As expected, both projects received changes to the inputs including change in scope, change in budget, and change in resources.

5. Conclusion

The discussed model provides a clear overview about influencing parameters, disturbances, and processes executed during a project. The offered more robust model for project management in complex situations allows the project manager to understand more the role of project management and provides possible steering once the system is implemented in real projects. Within a brief use-case, the focus on internal organizational complexity is shown.

The model not only proved the usability but also shows the effort necessary to be implemented. As the elements of the system are not clear enough in the beginning, the implementation takes some experience and time to be valid enough for use. Within the presented case, the usability of the model was reached after 2 years and proves the value in prediction of the impact of steering. This means a more practical implementation guide as well as supporting documentation is necessary to use this model more in practice. Here, additional work is necessary.