# BPRM Methodology: Linking Risk Management and Lesson Learnt System for Bidding Process

Juan Diego Botero, Cédrick Béler, Daniel Noyes

► To cite this version:

Juan Diego Botero, Cédrick Béler, Daniel Noyes. BPRM Methodology: Linking Risk Management and Lesson Learnt System for Bidding Process. IFIP International Conference on Advances in Production Management Systems (APMS), Sep 2014, Ajaccio, France. pp.233-240, 10.1007/978-3-662-44739-0_29. hal-01388251

HAL Id: hal-01388251

https://inria.hal.science/hal-01388251

Submitted on 26 Oct 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# BPRM methodology: linking Risk Management and Lesson Learnt System for Bidding Process

Juan Diego Botero Lopez, Cédrick Béler, Daniel Noyes

Laboratoire Génie de Production / INPT-ENIT - University of Toulouse,
47, Avenue d'Azereix, 65016 Tarbes Cedex, France
{juan.boterolopez, cedrick.beler, daniel.noyes}@enit.fr

**Abstract.** The working relationship between industrial partners often begins with a bidding procedure by which a costumer chooses a provider of works or services. From the bidder point of view, there are several risks when responding because he must propose an offer for a future development. In this context, considering the whole project cycle is essential to identify all potential risks and take them into account during the development of the technical and commercial offer. In this paper, a methodology for bidding process risk management (BPRM) is presented. It is based on the experience acquired during past projects in order to manage the risks of current BP and make it more efficient.

**Keywords:** bidding process (BP), risk management (RM), project lifecycle, lesson learned system (LLS).

## 1 Introduction

In recent years, bidding process (BP) has become a key practice for almost all professional sectors. This practice is based on the competition of potential providers. Each one of them spends time and resources to make proposals that will not always be accepted or even, that will penalize the bidder during the product development. A successful BP is one that allows achieving both client and provider goals. To be efficient, proposals must meet client quality requirements while minimizing costs and time. These constraints make BP risky and complex. Since it is a widely used procedure, it is necessary to develop support management tools in order to assist this process.

Depending on the project advancement, two risk families are distinguished. The first one is associated to the BP itself in relation with the non-acceptance of the offer, and the second one is related with the project execution. An incorrect assessment by the bidder of the difficulties associated with the realization (inadequate estimation of development context, evaluation errors) can distort the offer. If it is accepted, the bidder may be engaged in a very penalizing process (cost overruns, non-compliance of technical requirements, non-compliance of deadlines...).

To effectively solve these major problems, a BP instrumentation is proposed by coupling a suitable risk management engineering with a dedicated lesson learnt system. This instrumentation and the underlying methodology (called BPRM "Bidding
Process Risk Management”) aims to assist BP by taking into account BP risks through a lesson learned system (LLS).

The central principle of BPRM approach is the capitalization of past BP cases in-
cluding all project cycles, focusing on risks. This goal is achieved through a fact sheet
featuring all relevant information to facilitate posterior exploitation. These fact sheets
are called “experiences” and they include information about a project: its context, its
analysis, its solution, its deployment and its closure. All these experiences are stored
in a database to be reused, once adapted, in new cases.

The paper is organized in five sections.

- In section 2, the general principles of BP are presented. BP is positioned in a pro-
ject management frame and set as the initial phase of the project.

- In section 3, the concept of BP risk is shown and a risk model called “CEMDEX” is proposed to store all relevant information dedicated to risk management.

- In section 4, the BP experience is presented and put in relation with the risk man-
agement process.

- The general approach of BPRM methodology is detailed in section 5. Here, the operating mechanisms of the proposed LLS are explained.

- Conclusion and perspectives are discussed in the last section.

2 Bidding process and project cycle

Bidding is a global process in which two entities are involved. The first one is the customer who makes a call for tenders for works, supplies or services; and the second one are the different bidders who respond to this request based on formal client requirements [1]. This process includes the steps of receipt of invitation to tender, feasibility study, decision making (go / no go), technical offer development, cost estimation and negotiation [2].

BP is part of a more global process, which is the actual project cycle [3]. A descriptive BP model and its positioning in the project cycle are introduced in Fig. 1. This model presents the classic project steps (client process) and their correlation with BP extended to development cycle (supplier process). The project steps related to BP are: expression of needs, feasibility and, if the offer is accepted, development.

For a project that involves a call for tenders’ procedure, the request is made during
the phases of expression of needs and feasibility study (cf. Fig. 1). In these steps, for-
mal requirements are established, criteria on which the project will be evaluated are
defined, and the call for tenders is issued. This invitation is received by several bid-
ders who respond depending on their capability and their interest in the project.

For bidder, BP includes the request analysis (from call for tenders to “go / no go”
decision) consisting of a feasibility study and decision-making steps. This decision is
based on the ability to meet customer demand but also on bidder competitive and
commercial strategy. The next step, technical offer design, which consists in drawing
up the client proposal, is essential because future design scenario must be considered
in order to develop an adapted proposal that meet both client specifications and sup-
plier constraints. Then, costs are estimated in order to establish the price of the offer based on resources to be used and on expected gain. The negotiation phase consists in sending the offer to the client and discussing with him on technical and economic issues that can arise. This last step leads to a positive or negative response from the client.

<figure><img src="image_2.png" /><figcaption>Fig. 1. BP and project cycle</figcaption></figure>

If the bidder’s offer is accepted, the development phase begins. This product devel-
opment cycle includes the steps of preliminary design, detailed design, production and
delivery [4]. A control phase from the client process to the bidder process occurs to
inspect the expected characteristics. Finally, the product is delivered for its use by the
client.

BP has several critical features. This process has a short duration (bidders often have
little time to prepare the proposal) and, very especially, it is conducted under uncer-
tainty (since the product does not exist yet and since the available information is not
always reliable). It has a big impact on the whole project since BP set up the condi-
tions for future development [5]. These characteristics impose severe constraints and
expose the bidder to different kinds of risk. The first level of risk is associated with
the client decision (acceptance or rejection) and the second one is related to the pro-
ject development where bidder can be penalized (several reasons are possible: lack of
skills, cost overruns, delays...). Note that an upstream risk can also be associated with
the "go / no-go" decision in relation to the project interest the bidder may have.

3 BP risk and CEMDEx model

A classic view of risk is related to the perception causes / consequences of an unwant-
ed event. Risk is associated to the occurrence of this event correlated with the conse-
quences it induces [6]. The occurrence context of an unwanted event establishes the
hazard and, depending on this, the potential consequences can be more or less serious. A risk model that integrates this characteristic has been developed in previous work [2]. This approach takes into account external factors present in the context (that may increase or reduce the consequences). In addition, the “control” aspect is integrated to represent actions carried out on causes and on consequences.

In order to manage BP risks, it is very important to define risk in this context. Since BP is an upstream phase of a project and since the whole project cycle is considered for risk management, definitions of risk in the broad sense and of project risk in particular have been used to establish the following BP risk definition: “*BP risk is associated with the occurrence of an unwanted event whose occurrence affects, firstly, acceptance objectives and, secondly (if the proposal is accepted), the objectives of quality, cost and timeliness*”.

Regarding an unwanted event, several properties characterize the associated risk and its possible management. In this regard, an adapted risk model has already been developed [7]. It allows understanding all the useful features to inform the processes involved in BPRM methodology. Five aspects are highlighted in this representation, forming the five dimensions of the CEMDEX model (Causes, Effects, Mapping, Description, and Experience) introduced in Fig. 2.

<figure><img src="image_3.png" /><figcaption>Fig. 2. CEMDEX model</figcaption></figure>

*Causes* (*<C>*). According to the classification of risk factors for an unwanted event proposed in [8], a partition “external / internal causes” has been created. In this approach, external causes include all causes from the bidder outside context in relation with the current BP. Internal causes include all causes which are specific to the bidder context. Classes included in these two categories are respectively *client* causes, *competition* causes and *environment* causes for external causes, and *strategy* causes, *project* causes and *product* causes for internal ones. Each class may have other specific subclasses, which are typically: organizational, technical, financial, human and juridical ones.

*Effects or consequences* (*<E>*). As was done for the causes, effects of unwanted event are split up according to the partition “external / internal effects”. In this case, external effects include all effects affecting the bidder outside context in relation with
the current BP. The internal effects include all effects affecting the bidder context. Effects in relation to the *client* and the *environment* are identified as external effects, and effects related to the *project* and the *product* are identified as internal ones. Like for causes, subclasses (organizational, technical, financial, human and juridical) may be associated with each effect.

*Form or “mapping”* (*<M>**)*. This dimension allows clarifying the number and form of dependencies between the possible causes of an unwanted event and its effects. Four basic forms may be considered with respect to the generic risk representation: i) one cause to one effect, ii) one cause to multiple effects, iii) multiple causes to one effect, and iv) multiple causes to multiple effects. Considering “multiple causes to multiple effects”, aggregation operators (conjunctive or disjunctive) must be defined and have an important impact on the adopted risk management strategy. For instance, the application of “cause avoidance” techniques is, a priori, more favorable to con- junctive causes than those of disjunctive (in the first case, avoidance of one possible cause is sufficient to exclude the occurrence of the unwanted event).

*Descriptive characteristics* (*<D>*). The main descriptive characteristics in quantita- tive terms are the following properties: i) occurrence (often expressed with probabili- ties), ii) impact or severity (often expressed with scale of values), iii) detectability (expressed as binary or gradual value), iv) risk level (often expressed by the product of occurrence and impact), and v) trust-level (confidence level expressed as gradual value). Qualitative characteristics are those that describe the management actions carried out (or likely to be carried out). This description combines classically choices and actions of conservation (passive risk acceptance), avoidance (actions to avoid causes), reduction (actions to limit consequences), and transfer (insurance).

*Experience category* (*<Ex>*). This last dimension refers to risk scenarios already found in past experiences; it is directly related to the LLS. In the context of past BP, several risk scenarios for the project development have been identified. Starting from risk associated with an unwanted event, a risk can be: i) anticipated and not occurred (a risk that should not have been considered or, on the contrary, a risk for which ac- tions carried out avoided its occurrence), ii) anticipated and occurred (a risk for which actions carried out were not enough), and iii) unanticipated and occurred (a risk in which the analyst did not think).

This generic BP risk model can be refined according to the system to be developed (product/service). This representation is exploited in decision-making processes in- volved in the BP different phases. For more information about CEMDEx see [7].

**4 Experience concept and BP guideline**

In order to carry out activities related to LLS (capitalization, processing and exploita- tion) [9], an experience vector (set of structured information eventually nested) has
been proposed. It allows to record all relevant information to the implementation of a LLS towards BP risk management and is made of five elements: i) the “context” describing the current BP framework, ii) the “analysis” conducting feasibility studies and risk analysis, iii) the “solution” describing the technical and commercial offer, iv) the “deployment” presenting the product development as well as the encountered difficulties (if the offer is accepted), and v) the “closure” giving the final risk analysis and synthesis of the project.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Experience vector</figcaption></figure>

This experience vector has been implemented in a LLS computerized fact sheet that allows capitalizing and exploiting experiences in a practical way. This sheet aims to trace BP (extended to the project) in order to facilitate the extraction of information and to simplify the mechanisms for its reuse during a new BP. A key aspect of this tool is to provide the full traceability of the expert reasoning when dealing with risks during a BP. In particular, special information fields have been developed to include (eventually) expert comments.

Based on this experience frame, a guideline with six stages for processing a new BP is offered: i) fact sheet assignment, ii) similar experiences lookup, iii) risk extraction and analysis, iv) offer estimation (quality, cost and timeliness), v) solution deployment, and vi) final risk analysis and project closing. Coupling between the BP stages, the experience vector and the offered guideline is given on Fig. 4.

<figure><img src="image_5.png" /><figcaption>Fig. 4. Matching between Experience, RM and LLS</figcaption></figure>

Note that correspondence between these three elements is straightforward. Each BP stage (extended to project) matches an element of the LLS fact sheet (the description of the experience) and a phase of the advisable guideline.
# 5 General approach for BP risk management

The previous guideline for BP risk management allows both to lead BP effectively and to lead risk management in accordance with ISO 31000 [10]. Indeed, our BPRM methodology follows, in an original manner, the stages of risk management, which are: communication, context set up, risk appreciation (identification, analysis and evaluation), treatment and monitoring. Fig. 5 illustrates risk management mechanisms involved in the BPRM methodology via the LLS.

<figure><img src="image_6.png" /><figcaption>Fig. 5. Operating mechanisms of LLS database for risk management in BP</figcaption></figure>

The first step consists in requesting the LLS database in order to find relevant experiences for a new case ①. This request may use three lookup mechanisms: i) similarity of experiences (considered as a whole), ii) similarity of risks associated to specific context elements of experiences (stored in past experiences for each risk) iii) search for peculiar risks (according to the expert knowledge and know-how).

Step 2 returns inferred risks to be studied drawn up from full experiences and specific risks ②. This risks list can be completed by letting the analyst add new risks (no previous occurrence). Such risks are conformant to the CEMDEX model.

The third step involves the transition from assessed risks to retained risks (risks to be considered in current BP) ③. Each risk component must be adapted to the current case. This can be done through the analyst expertise (or eventually by using automated rules). Again, a particular attention has been paid to capitalize the analyst reasoning trace for each risk analysis (“risk trace” history is available) ④.

Finally, step 5 concerns the transition between considered risks (in BP phase) to effective risks occurred during the project execution ⑤. Here, the provider can see if the implemented risk strategy was adequate (pertinence of retained risks and effectiveness of the corresponding risk management actions).

Note that, even if last step of risk management cycle (monitoring) is not explicit in Fig. 5, it is implicit in the methodology because, through the LLS implemented, risks are under control, and revision and updates are systematically carried out when the risks adaptation for new cases of BP is made.
# 6 Conclusion and perspectives

Bidding process (BP) is an unavoidable and risky practice for companies that respond call for tenders. The BPRM methodology was proposed so as to give such companies a tool to control the different kinds of risk associated to tenders. The originality of this work is the coupling of risk management with a lesson-learned system (LLS).

The first contribution was to define what essentially is a BP Risk. A generic model called CEMDEX has been used for this purpose. The second contribution is the proposition of a guideline that helps following BP while capitalizing all related information in concordance with, not only BP, but with the whole product cycle. This ends up in an information vector called “experience” that is stored for later reuse and which is the central part of the LLS.

Up to now, a fact sheet representing an experience has been implemented and several lookup mechanisms have been designed. Capitalization of the expert reasoning (trace) was our first concern and although exploitation mechanisms are not yet implemented. The usage of a flexible model and its associated meta-model have been decided to be able to implement different lookup strategies (based on similarities).

# References

[1] J. D. Botero, C. Béler, D. Noyes, and L. Geneste, "Integration of experience feedback into the product lifecycle: An approach to best respond to the bidding process" in *Information Control Problems in Manufacturing*, vol. 14, pp. 1095-1100, 2012.

[2] J. D. Botero, C. Béler, and D. Noyes, "Risk analysis in project early phase taking into account the product lifecycle: Towards a generic risk typology for bidding process" in *Manufacturing Modelling, Management, and Control*, 2013.

[3] J. Wang, Y. Xu, and Z. Li, "Research on project selection system of pre-evaluation of engineering design project bidding" *International Journal of Project Management*, vol. 27, no. 6, pp. 584-599, 2009.

[4] N. Cross, "Engineering design methods: strategies for product design", 2008.

[5] R. Chalal and A. Ghomari, "An approach for a bidding process knowledge capitalization" *World Academy of Science, Engineering and Technology*, vol. 19, 2006.

[6] R. Gouriveau and D. Noyes, "Risk management-dependability tools and case-based reasoning integration using the object formalism" *Computers in industry*, vol. 55, no. 3, pp. 255-267, 2004.

[7] J. D. Botero, D. Noyes, and C. Béler, "Modèle des risques pour les soumissionnaires aux appels d'offres" in *10 Congrès International de Génie Industriel (CIGI)*, 2013.

[8] A. M. Alquier, E. Cagno, F. Caron, V. Leopoulos, and M. A. Ridao, "Analysis of external and internal risks in project early phase" *PRIMA Project*, pp. 147-155, 2000.

[9] H. Rakoto, J. Hermosillo, and M. Ruet, "Integration of experience based decision support in industrial processes" in *International Conference on Systems, Man and Cybernetics, 2002*, vol. 7, pp. 6-pp, 2002.

[10] ISO/31000, *Risk management — Principles and guidelines*. ISO, 2009.