Cognitive Factors and Risk Management of Concurrent Product Realisation

Abstract

In projects of development and industrialization of new products or to improvement of the existing ones not only quality and costs but also the time of product entering the market and delivery time to the client are important. This can be achieved by efficient project management, where classic methods of project management need to be upgraded by elements of concurrent engineering. In this chapter, a method for risk management in cyclically recurrent projects is demonstrated, in which conventional models of risk management based on an assessment of probability of risk event occurrence and an assessment of their consequences are supplemented by a third parameter—assessment of frequency of recurrence of risk events. An important advantage of the suggested solution lies in that a project manager and team members take into account cognitive factors, when managing recurrence of risk events which are usually due to poorly organized business processes of a company. A template was created in the Microsoft Project environment, by means of which the project team tested the suggested methodology on an example of concurrent realization of a pedal assembly of a car.

1. Introduction

Nowadays, the companies involved in development and industrialization of new products or in the improvement of existing ones mostly deal with orders for a known client. The client not only expects a product of high quality at acceptable prices but also delivery in a term agreed upon [1, 2]. This means that the companies predominantly face project manufacturing processes instead of conventional continuous processes (Figure 1).

Figure 1.

Processes in a manufacturing company.

Continuous processes run for an “indefinite time.” Based on demands of the market, they are used to define the necessary quantities of products, for which a process for their development and industrialization had been carried out before.

Project processes are carried out once or in regular intervals and are market oriented to reach a precisely defined goal, for a known client, usually with a higher added value. They have a limited expiration date.

A problem of risk management is relatively low in continuous processes, while it has a very important impact on the achievement of desired results/project goals in project processes.

The chapter only deals with cyclically recurring realization projects of an engineered product in a specific version and with projects that end with a transition to continuous production (e.g., engineering of a car component).

To reach a reduced time needed for product development and industrialization, strategies of concurrent engineering need to be included in processes of project management (parallelism, standardization, and integration), and a track‐and‐loop principle should be used to carry out activities [3]. Such projects will hereinafter be called concurrent product realization (CPR) projects.

Even though the strategies of parallelism, process integration, and the track‐and‐loop principle of implementation of project activities considerably shorten the time, reduce the costs, and achieve higher product qualities of the project [3], they may simultaneously be an important cause of risk events that might jeopardize the success of a project.

The importance of managing risks of CRP projects is very high although recurrent project processes are in question. These are the projects that are very precisely specified as to the time, the cost, and the quality, and any deviation from the project plan may result in a business and competitive loss for the company. The client and the company usually assume a joint risk for a successful realization of a project and product placement on the market at the very beginning of the project.

The companies often fear that a risk analysis might cause the projects to get paralyzed or that by identifying the risks we would get frightened and will therefore not carry out the project. In fact, risk management has the following benefits for the company [4]:

• Organizational benefits relating to an increase in efficiency of project implementation—less errors, corrections, and delays due to efficient cooperation and direct communication among project participants.

• Market benefits relating to success of projects—the more precisely the necessary times and costs for the implementation of a project are assessed, the more efficiently risks are managed, and the higher the earning in the implementation of a project and higher clients’ confidence.

• Strategic benefits of risk management on projects are logical if market benefits of a larger number of successfully completed projects are correlated and if long‐term benefits for the company are assessed.

Planned risk management of CPR projects makes the company more trustworthy and more respected. Progressive project management with an established culture of risk adoption allows the company to operate much more efficiently and successfully in the time of constant changes.

2. Methods of risk management of a project of concurrent product realization

Risks of an entire project or its activities [5] are potential events or situations that may jeopardize a planned implementation of a project. The most important in managing risk events of a project is use of various tools for analysis, evaluation, planning, and carrying out of measures to prevent or at least reduce the influence of risk events.

Several models and methods are available for managing risks of an entire project and of individual project activities [5–10]. The suggested risk management methods are similar to each other, a difference lies in a detail of subdivision of the entire risk management process to subprocesses. Table 1 illustrates a comparison of four various concepts [5–8], which were a basis for designing a model for risk management in the case of CPR projects.

The first three models are a general approach to project risk management and include methods and techniques that are generally applicable on any project. Colin’s model proved to be the most appropriate basis for a development of a risk management model in CPR projects since individual phases of a risk analysis are very precisely defined.

A critical analysis of the discussed models and methods of project risk management supported by experiences in implementing projects in an industrial environment, particularly in car industry, led the authors to design a method for activity risk management of a project that is shown in Figure 2.

Figure 2.

Risk management method of CPR projects.

In the suggested method, the analysis of project risks and their activities is carried out in seven consecutive steps:

1. Step 1. Preliminary analysis of project risk management.

2. Step 2. Project risk identification/assessment.

3. Step 3. Activity risk identification/assessment.

4. Step 4. Qualitative and quantitative analysis of activity risks.

5. Step 5. Planning risk management measures.

6. Step 6. Monitoring, recording, control, and taking measures.

7. Step 7. Analysis, evaluation, and archiving.

Compared to the reference models of project risk management [5–8], the suggested methods differ in the following items:

• A phase of project risk analysis is separated from the project activity risk analysis.

• Assessment of risk parameters and a method for the assessment of project activity risks are logically linked to each other.

• A two‐dimensional (for one‐time projects) and a three‐dimensional (in cyclically recurrent projects) level of activity risk can be calculated.

• The use of a table of critical success factors is suggested for a qualitative and a quantitative analysis and for planning and monitoring preventive and corrective measures.

• Evaluation of project activity risk management and formation of new knowledge based on experience obtained from a completed project are emphasized.

When designing the suggested risk management model of CPR projects, we predominantly relied on the Colin’s concept [8], therefore, Table 2 shows the main differences between them.

Apart from the steps of performing a project risk analysis and a project activity analysis, the suggested method includes the most often applied work methods that a project manager and a project team can use in the implementation of an individual step of the risk analysis.

In literature, different processes and methods for risk management of project activities were proposed, but we did not notice any solution where cognitive factors and risk management of concurrent product realization were connected. Most of the methods are based on two‐dimensional risk analysis, therefore, we suggest a use of third factor—assessment of frequency of recurrence of risk events.

To the basic Microsoft Project software, a Monte Carlo method can be added, but this solution is insufficient for integration of cognitive factors with risk analyses.

Based on these facts and the experiences from real industrial environment (especially automotive industry), new individual steps of the suggested method for managing cyclically recurrent project activity risks with respect to cognitive factors are described with an emphasis on a detailed description of solutions suggested by the authors for the implementations of Steps 4 and 5.

2.1. Preliminary analysis of project risks

A project team conducts a creativity workshop to establish possible project risks with respect to strategic, organizational, and project goals. The team also analyses the stakeholders’ impact on risks.

The risks are divided into business‐related and project‐related risks. Business‐related risks especially have influence on a decision, whether a project is feasible or reasonable, whereas project‐related risks have influence on decisions how to carry out a project in the most successful way with respect to the goals and given circumstances.

In implementing this step, the project team uses a SWOT analysis, in which advantages, disadvantages, opportunities, and dangers related to project implementation and consequently its risks are defined.

Based on the findings of the SWOT analysis, the project team and the client who ordered the project conclude whether the risk is acceptable and the project will be carried out or that there is too much risk involved and the project will not be carried out.

2.2. CPR project risk identification

For identifying/assessing project risks, the project team can use one of the following models [9]:

• Standard model, in which the risk is defined by two parameters: a risk event and its impact on the course of the project.

• Simple model, in which the risk is defined by one parameter referring to the risk event and its impact.

• Cascade model, in which the risk is defined by the risk event, consequences, and impact on the course of the project.

• Ishikawa model, in which causes and respective risk events are determined for project‐related risks. The project team uses this model to identify those risk causes and risk events that have the greatest impact on the implementation of the project in question.

An analysis of application of said models in real life has shown that the most adequate model for identifying project‐related risks of development and industrialization of products/services is the Ishikawa model (Figure 3) which has the following advantages:

Figure 3.

Ishikawa model for identifying CPR project risks.

• The companies are already acquainted with the Ishikawa model as one of efficient tools for total quality management (TQM).

• The model clearly illustrates why project risks occur.

• Separate risk events allow prevention.

• The model supports the cause‐effect concept.

A disadvantage of the Ishikawa model is its complexity in case of a larger project and its inability to show interactions between influences of the same risk event in different risk causes [9].

The Ishikawa model for identifying project risks may be used both for identifying risks of the entire project or individual project activities.

When identifying CPR project risks, apart from the risks that are usual for development and industrialization of a product, there is a strong presence of risks that may be caused by process complexity due to performance of concurrent engineering loops.

The risks which may be due to the performance of concurrent engineering loops may be caused by the following:

• Poorly defined concurrent engineering loop and the activities performed within the loop.

• Lack of knowledge and willingness to participate by various individuals who make up working teams who simultaneously perform activities within the loop.

• Poor communication among individuals who perform activities that are carried out in parallel.

• Inadequately selected communication tools.

2.3. CPR project activity risk identification

For the purpose of a quantitative analysis of project activity risks, a project team may use techniques of collecting and presenting the data, e. g., recurrence frequency of risk event, wherein the findings from previously completed similar projects are taken into consideration, or a method of an itemized structure of project activity risks [10]. Apart from that, the methods indicated in Section 2.2 may be used, especially the Ishikawa model.

The method of the itemized structure of project risks is the most adequate method for practical use. In this structure, the standard WBS project structure [5, 10] is expanded by risks identified for each individual activity. If a risk is not identifiable at a certain activity, the risk is left out. An itemized structure of project activity risks is shown in Figure 4.

Figure 4.

Itemized structure of CPR project activity risks.

In the concurrent product realization, the same activity may be present in two or more loops, wherein identical or different risks may appear in all loops.

2.4. Qualitative and quantitative analysis of project activity risks

The qualitative and quantitative analysis of project activity risks is performed by assessing [5, 7]:

• Probability of occurrence of a problem/risk event.

• Consequences of the problem/risk event.

• Determining a risk level.

To assess the probability of occurrence of a risk event, either an interval assessment scale with rates from 1 to 5 or a scale with descriptive probability rates [5] can be used. For simplicity reasons, a scale with rates from 1 to 5 is usually applied in practice.

The values given in Table 3 are used to assess the probability of occurrence of a problem/risk event.

PMBOK 2013	PRINCE2	DOD Risk management	COLIN
Plan risk management	Identify risk	Identify risk	Risk content
Identify risks			Preliminary risk identification
			Detailed risk identification
Perform quantitative risk analysis	Assess risk	Risk analysis	Detailed risk analysis
Perform qualitative risk analysis		Risk mitigation planning	Detailed risk evaluation
Plan risk responses	Risk plan	Risk mitigation plan implementation	Risk treatment planning
			Prepare risk management plan
Monitor and control risks	Implement and communicate	Risk tracking	Risk monitoring and control
			Review

Table 1.

Overview of several models for project risk management.

Steps of the Colin’s model	Steps of the suggested model	Differences
1. Establishing a context	1. Preliminary analysis of project risk management	Steps 1 and 2 of the reference models are combined in one step in the suggested model Preliminary analysis of the suggested model refers to the entire project
2. Preliminary risk analysis
3. Detailed risk identification	2. Project risk identification	Step 3 of the reference model is logically divided into a risk analysis of the entire project and then to a detailed analysis of risk activities
	3. Activity risk identification
4. Detailed risk analysis	4. Qualitative and quantitative analysis of activity risks	Assessment of risk parameters and risk evaluation are logically connected
5. Detailed risk evaluation
6. Risk treatment (planning)	5. Planning risk management measures	Planning measures are carried out based on risk evaluation, so two steps are not necessary
7. Prepare risk management plan
8. Risk monitoring and control	6. Monitoring, recording, control and feedback
9. Review	7. Analysis, evaluation, and archiving	In the suggested model, emphasis is placed on evaluation and formation of knowledge based on experience obtained from the completed project

Table 2.

Overview of differences between the discussed risk analysis models.

Estimate	Probability of event occurrence—EP
1	Very little (~10%)
2	Little (~30%)
3	Medium (~50%)

Table 3.

Probability of occurrence of a risk event.

The values given in Table 4 are used to assess consequences of occurrence of a problem/risk event.

Estimate	Assessment of consequences of event occurrence—EC
1	Very small
2	Small
3	Medium
4	Big
5	Very big

Table 4.

Assessment of consequences of risk event occurrence.

The project team may perform a qualitative risk assessment by means of a probability and impact matrix [7] or can calculate a rate of project activity risk [4] based on the assessment of probability of occurrence of a risk event and the assessment of consequences of risk occurrence. The rate of activity risk in the two‐dimensional analysis is

$R{L}_2=EP\times EC$E1

where RL₂ is the rate of activity risk in the two‐dimensional analysis of a project activity risk; EP is the probability of occurrence of an activity risk event; and EC is the assessment of consequences of occurrence of an activity risk event.

The data on the quantitative and qualitative risk analyses of a certain project activity are entered into the table of critical success factors as shown in Table 5.

No.	WBS code/activity/problem	Event probability—EP	Assessment of consequences—EC	Risk rate—RL2
1.	Activity 1/problem A	3	2	6
2.	Activity 2/problem B	2	4	8
:	:	:	:	:
j.	Activity j/problem N	4	5	20
:	:	:	:	:
n	Activity n/problem X	4	5	20

Table 5.

Table of critical success factors—two‐dimensional analysis.

Instead of calculating the risk rate, the project team may use the probability and impact matrix [7].

As this chapter discusses the risks in cyclically recurrent projects, the experience obtained from previously performed similar projects can be used for the assessment of the frequency of recurrence of risk event occurrence [4].

Example: in its product realization, a company plans activities such as client’s confirming documentation and samples. The time needed for the implementation of these activities is planned, however, a client frequently, yet not always, exceeds the planned time. Hence, this is a recurrent risk event.

To assess the frequency of recurrence of risk events, the authors suggest the values indicated in Table 6.

Estimate	Assessment of event recurrence frequency—ER
1	Never
2	Very rarely
3	Rarely
4	Often
5	Very often

Table 6.

Assessment of recurrence frequency of a risk event.

The level of project activity risk in the three‐dimensional analysis is

$R{L}_3=EP\times EC\times ER$E2

where RL₃ is the level of activity risk in the three‐dimensional analysis of activity risk; EP is the probability of occurrence of an activity risk event; EC is the assessment of consequences of occurrence of an activity risk event; and ER is the assessment of frequency of recurrence of a risk event.

Table 7 shows an example of calculation of critical success factors for the three‐dimensional risk analysis.

Risk analysis
No.	WBS code/activity/problem	Event probability—EP	Assessment of consequences—EC	Assessment of recurrence frequency—ER	Rate of risk—RL3
1.	Activity 1/problem A	3	2	4	24
2.	Activity 2/problem B	2	4	4	32
:	:
j.	Activity j/problem N	4	5	5	100
:	:	:	:	:
n	Activity n/problem X	4	5	3	60

Table 7.

Table of critical success factors—three‐dimensional analysis.

2.5. Planning measures and risk management

Once the two‐dimensional risk analysis is completed, it should be determined—based on the assessment of probability of event occurrence and the assessment of its consequences, based on a decision matrix [5, 7]—whether the activity risk is low, medium, or high.

In the suggested three‐dimensional risk analysis, the activity risk is determined based on predefined boundary values of a rate/probability of risk [4]:

• If RL ≤ 24 (risk probability up to 20%), the risk is low.

• If 25 ≤ RL ≤ 60 (risk probability between 20 and 50%), the risk is medium.

• If RL ≥ 61 (risk probability higher than 50%), the risk is high.

If the risk is low, the project team does not prepare potential measures.

If the risk is medium, the project team prepares preventive measures directed at eliminating causes for the occurrence of risk events. If a risk event occurs anyway, the project team must immediately prepare corrective measures.

In the event of a huge risk, the project team prepares both preventive measures to prevent the occurrence of risk events (risk elimination, lowering of probability of realization, transfer of risks) and corrective measures (active adoption of risks) that can trigger processes for alleviation of consequences of a risk event.

We suggest using Table 8, which is an amendment of Table 7, for entering the measures together with responsible owners.

Risk analysis						Risk management
No.	WBS code/activity/problem	Event probability—EP	Estimate of consequences—EC	Estimate of recurrence frequency—ER	Risk rate—RL3	Measures	Risk owner	Indicator
						P—preventive
						C—corrective
1.	Activity 1/problem A	3	2	4	24
2.	Activity 2/problem B	2	4	4	32	P—prevent. measure 1	Project manager
:	:	:	:	:	:	:	:	:
j.	Activity j/problem N	4	5	5	100	P—prevent. measure 2	Head of develop.	Delay x days
						C—Corr. measure 1
:	:	:	:	:
n	Activity n/problem x	4	4	3	48	P—measure 3	Project manager

Table 8.

Amended table of critical success factors.

Table 8 was also the basis for a template in the Microsoft Project software that allows the project manager and the project team to plan, monitor, control, and take measures if a risk event occurs in an activity.

This approach provides more opportunities to the project team and other project stakeholders for identification of potential risk events and searching for possible solutions for elimination or mitigation of risk consequences based on thinking out of the box with the use of cognitive factors. Based on this approach, the solutions for risk management are more sufficient, creative, innovative, and clearly described and collected in one place.

2.6. Monitoring, recording, control, and taking measures

Responsibility for monitoring project activity risks and their implementation lies with: project manager, project team, client, and individuals performing the activities.

Responsibility of a risk owner should be determined for each risk. The risk owner has a task to detect a symptom of an approaching risk as soon as possible and to trigger planned measures accordingly. The sooner a risk is discovered, the less serious the consequences.

The project manager verifies the status of risks at regular control briefings and amends a list of risks if necessary. The team must bear in mind that the level of risk can vary during the entire project—there is a higher possibility of one risk getting realized in a certain phase and of another risk getting realized in another phase. To have a better control, the risks should be specified in the table by size and topicality.

Several approaches are suggested to reduce the level of project risks:

• Active risk assumption.

• Risk elimination.

• Reduction in probability of risk realization.

• Alleviation of consequences by transferring risks to another organization.

• Passive assumption of risks with a reserve in time and money.

Active risk assumption means that a plan of measures is prepared for the event of occurrence of an activity risk event. Usually, reserves in time and money are foreseen to solve the consequences of the occurred risks.

A risk may be completely avoided by eliminating or circumventing a cause for its occurrence. The latter is possible by changing a project plan, wherein a change is applied on the entire project or only an individual phase, activity duration, tactics of activity implementation, supplier, or contractor. A new plan which attempts to circumvent a risk can be defined as an alternative method for achieving key events and can be more expensive.

Another way of risk elimination is elimination of certain requirements by the client that are hardly achievable and represent various risks (time, costs, and quality). This mode of risk elimination includes negotiations with the client, and when deciding, a size of a risk must be compared with the positive effect of realization of the client’s or customer’s requirement.

By listing a risk to the risk list, a probability of occurrence of a risk event is automatically reduced due to subsequent systematic control. Planned reduction in probability can be achieved by additional activities and costs; there are also measures such as better and more expensive equipment, better and more expensive technology for the implementation, assistance of external experts, and preliminary simulations.

When a reduction in risk consequences is in question, the best solution is to transfer the risk to another organization. Among participants in a project the risks may be transferred to the client, an external contractor or supplier, wherein the transfer of risks (delays and extra costs) is defined by a contract [11]. As the risk owners tend to avoid extra costs, a probability of occurrence is consequently reduced. Another way of alleviating the consequences is insurance. Insurance is the most adequate when a huge risk is encountered, the probability of occurrence is rather low but may have devastating consequences for the project.

The more project activities on a critical path, the riskier the project since a delay in critical activities has a direct impact on a delay of the entire project. Time reserves in noncritical activities can be an important factor for risk reduction due to a delay in the implementation of activities.

Microsoft Project is a tool often used in information support to project management, therefore the Laboratory for Manufacturing Systems of the Faculty of Mechanical Engineering in Ljubljana has decided in cooperation with partners in companies to integrate the presented expanded methodology of project activity risk management into previously created templates. Although a server version of the Microsoft Project offers a possibility of use of the tool for risk analysis, we estimate that the suggested solution is simpler for a user yet very efficient. This allegation is especially confirmed by use of the expanded risk analysis on several projects from industrial environment [12, 13].

2.7. Analyzing, evaluation, and archiving

Once a project is completed, the project team, apart from performing other analyses, performs a risk management evaluation to establish which anticipated risk events have actually happened, what the consequences were and how efficient the preventive and corrective measures were.

All documents related to risk management are archived and the database of knowledge about risks is adequately amended.

3. Case study

The suggested method for project activity risk management was performed on an example of a project of concurrent development and industrialization of a pedal assembly for a personal vehicle as shown in Figure 5.

Figure 5.

Pedal assembly for a personal vehicle.

A customer who develops a new car sent an order for development and industrialization of a pedal assembly to his development supplier. Since the terms for obtaining an order were very demanding in terms of time, costs, and quality, the management of the company decided to include as many elements of concurrent engineering in the project management of the pedal assembly as possible and to organize the project by the track‐and‐loop principle [3, 12, 13]. In fact, the company faced a huge risk because such mode of carrying out a project requires the project participants and the contractors to be well connected in terms of organization and information exchange.

It was for the first time that the company dealt with implementation of a risk analysis of such a project, and the management of the company therefore organized a creativity workshop [14], the goal of which was to identify all types of risks by means of the Ishikawa model, which can occur in the implementation of the CPR projects in their company.

The result of the creativity workshop is the Ishikawa chart (Figure 6), which includes four major causes for the occurrence of risk events in the CPR project of the pedal assembly.

Figure 6.

Ishikawa chart of project risks of the CPR project of the pedal assembly.

Based on the created Ishikawa chart, the project team reviewed the WBS structure of the project of the pedal assembly, which was created by the principle of concurrent engineering loops and identified potential risk events in each activity.

Figure 7 depicts a track‐and‐loop principle of implementation of the CPR project of the pedal assembly, which is divided in six stages and five concurrent engineering loops (T‐3 loops).

Figure 7.

Track‐and‐loop principle of implementation of the CPR project of the pedal assembly.

The WBS structure of the CPR project consists of five tasks at the first level, the tasks representing concurrent engineering loops. This is shown in Figure 8.

Figure 8.

First level of the WBS structure of the CPR project of the pedal assembly.

The project team amended the WBS structure of the project with assessed potential activity risks and transformed the structure into an itemized structure of project risks by adding potential risk events to the activities. Figure 9 shows a more detailed itemization of loop 2: a loop of product development on the activity and on the last level on potential risk events.

Figure 9.

Itemized structure of activities and risks of loop 2 of the CPR project of the pedal assembly.

The project team made a table of critical success factors for a qualitative and quantitative analysis of activity risks of the pedal assembly project. The team members have decided to perform a three‐dimensional risk analysis, in which it should be determined for each activity and the risk associated therewith—in compliance with the suggested model: probability of occurrence, assessment of consequences, and assessment of recurrence frequency of a risk event, then the level or activity risk should be calculated. For the activities, in which the risk is medium or high, preventive, or corrective measures and status indicators are foreseen.

Figure 10 shows the part of the table of critical success factors for loop 2 of the pedal assembly.

Figure 10.

Table of critical success factors of loop 2 of the pedal assembly project (part).

The table of the critical success factors empowered us to identify several potential risks in each activity and to take the maximum value as the level of activity risk.

As the company uses Microsoft Project software for planning and managing projects, we used a standard template for activity risk management of the project (Microsoft Project template).

The project manager inserted the data from Figure 10 into a prepared template, the result is shown in Figure 11.

Figure 11.

Activity risk analysis of the pedal assembly project of loop 2 in MS Project (part).

The advantage of the suggested template for managing activity risks of the project is the fact that the software tool which serves for planning time, resources, and project activity costs can also be used to manage activity risks of the project.

Apart from the advantages, the suggested template also has a limitation. If several potential risks are identified at an activity, only a risk having the maximum level of activity risk is entered in table in Figure 11, the remaining risks are noted in a notepad of activities.

The project manager, the project team members, and the individuals performing activities can obtain the following data from the table in Figure 11:

• Short risk description.

• Assessment of probability of event occurrence.

• Assessment of consequences of event occurrence.

• Assessment of frequency of event occurrence.

• Level of risk and risk indicator (in colors).

• Responsibility for risk management.

• Link to a document containing a detailed description of risks and measures.

The color of the risk indicator visually draws attention of the project manager and the team members to the level of risk of an individual activity and to foresee preventive and corrective measures.

A level of risk of the entire project is interesting for a comparison of risk of a project with risks of other projects. We decided based on Ref. [15] that a risk level of activity groups and of the entire project is calculated as an average level of activity risk (the lowest level of a WBS project). Of course, an average risk level of a project can only be a statistical piece of data and can be deceiving if uncritically discussed. It may happen that a project has a low average risk level, but includes activities that have a high‐risk level. If a risk event occurs in these activities, the project might be seriously jeopardized in terms of foreseen scope, time, and cost.

Apart from the risk indicator, other indicators that warn us of other project‐related dangers can be included in the table in Figure 11, for instance delays in time, consumption of time reserve, and excess in actual costs compared to the planned ones.

In the case of the pedal assembly project, an overview of risks by CPR loops (Figure 12) was made. It can be determined that most risk events occur in loop 3, i.e., a loop of process development.

Figure 12.

Overview of risks by CPR project loops.

Moreover, an overview by risk rate size (Figure 13) was made for a more detailed analysis. It shows that most potential risk events belong to a medium‐risk category (49 risk events), high risks come second (24 risk events), and low risks with 14 risk events are in the last place.

Figure 13.

Overview of risks with respect to the level of risk.

Both analyses performed show that the project of the concurrent realization of the pedal assembly is very risky and this demands from the project team to pay more attention to risk management of this project.

The proposed method requires comprehensive approach for cognitive solving of the risk management problems of concurrent product realization with the use of three factors and three different views on the same risk, which provides better solutions based on team work. Team work is based on a multidisciplinary team of different members for different organizational units of the company and external stakeholders. This helps a company to detect and solve the main causes of risk based on different point of view taking into account various human and cognitive factors.

This solution is integrated in the proposed model for cognitive risk management and supported with a template in the Microsoft Project software.

4. Conclusion

This paper presented a problem of risk management in CPR projects that are market oriented, i.e., in projects of products and services. It was determined that in such cyclically recurrent projects we frequently run into recurringly similar causes that cause a risk in the implementation of project activities.

In CPR projects, classic methods of project management are upgraded by concurrent engineering elements and a track‐and‐loop principle of performance of activities is used, hence, we face a huge need for managing risks that may appear in the implementation of the concurrent engineering loops [12, 16]. These risks most often occur because of poor team work, unfamiliarity with the tools of concurrent engineering and lack of cooperation and communication among activity performers (working teams) in concurrent engineering loops. Not only a team responsible for the implementation of the entire project is needed in the implementation of the concurrent engineering loops but also a need for creating working teams for the implementation of the loops [3]. Such team is made up of responsible persons of participants of organizational units who carry out activity loops. Since several activities are carried out in parallel, there is a need for permanent and direct communication between activity performers. Although such projects are cyclically recurrent in companies, it was established that the risk events keep occurring each time a project is repeated.

We therefore suggested a method for managing activity risks of a CPR project, in which a third parameter was added to the generally known two‐dimensional method of risk analysis—the recurrence frequency of a problem. This piece of data can be evaluated based on the evaluation of previously performed or completed projects. The introduction of this additional parameter has proved to be utterly necessary since it was claimed both by product customers and auditors of a company’s project management system.

If the frequency rate of problem recurrence is high and does not have a tendency to reduce in subsequent similar projects, this is a clear indicator that a company does not manage/efficiently eliminate permanently recurring problems. This is an important indicator for the management of a company to urgently adopt adequate measures. A further goal of the suggested method is to gradually reduce the frequency rates of recurrent problems (the goal is rate 1) and to gradually make a transition to a two‐dimensional risk analysis.

Since the companies often use the Microsoft Project software to support project management, the Faculty of Mechanical Engineering of Ljubljana in cooperation with partner companies prepared an additional table in support of conventional templates. The table allows a risk analysis in the Microsoft Project environment. The use of such template has proved to be a useful tool since project managers can use the same software to plan and carry out risk management measures.

In the future work, current Microsoft Project templates could be generalized for business use, especially in small companies.

The proposed solution will be extended with the design of threshold area of expected loss, which is an important information for decision‐making of risk mitigation or elimination.