Tải bản đầy đủ (.pdf) (26 trang)

PROBE–A multicriteria decision support system for portfolio robustness evaluation

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (747.34 KB, 26 trang )

ISSN 2041-4668 (Online)

PROBE – A multicriteria decision support system for portfolio
robustness evaluation

Joóo Carlos Lourenỗo1 and Carlos A. Bana e Costa1,2

1
2

CEG-IST, Centre for Management Studies of IST, Technical University of Lisbon
Operational Research Group, Department of Management, London School of Economics



Working Paper LSEOR 09.108


ISSN 2041-4668 (Online)

First published in Great Britain in 2009
by the Operational Research Group, Department of Management
London School of Economics and Political Science

Copyright © The London School of Economics and Political Science, 2009

The contributors have asserted their moral rights.
All rights reserved. No part of this publication may be reproduced, stored in a
retrieval system, or transmitted in any form or by any means, without the prior
permission in writing of the publisher, nor be circulated in any form of binding or
cover other than that in which it is published.



Typeset, printed and bound by:
The London School of Economics and Political Science
Houghton Street
London WC2A 2AE

Working Paper No: LSEOR 09.108


ISSN 2041-4668 (Online)

PROBE – A multicriteria decision support system for portfolio
robustness evaluation
Joóo Carlos Lourenỗo1
1
2

and

Carlos A. Bana e Costa1,2

CEG-IST, Centre for Management Studies of IST, Technical University of Lisbon

Operational Research Group, Department of Management, London School of Economics



Abstract: This paper deals with the problem of selecting a robust portfolio
of projects in the presence of limited resources, multiple criteria, different
project interactions and several types of uncertainty. We present a new

decision support system, PROBE – Portfolio Robustness Evaluation, and
the algorithms it implements. PROBE identifies all efficient portfolios,
either convex or non-convex efficient, depicting the respective Pareto
frontier, within a given portfolio cost range, and allows performing indepth interactive analysis of the robustness of selecting a proposed
portfolio.
Keywords: Portfolio decision analysis, resource allocation, portfolio robustness,
DSS.

Working Paper LSEOR 09.108


1. Introduction
Suppose that a manager has several projects, each one expected to add value to his
organization. The manager has associated a forward cost for each project and realized that
there is not enough money to fund them all. Therefore, he wants to select a portfolio of
projects providing the organization with the best value for money. An exhaustive analysis of
all possible portfolios, from the empty portfolio (in which no projects are funded and no
benefits are realized) to the full portfolio (that would require all projects to be funded), would
be impractical even if the number of projects is not too big. For example, 20 projects will
give more than one million portfolios (precisely 2 20 = 1,048,576).
A practical selection strategy would be to prioritize the projects in decreasing order of
their benefit-to-cost ratios and proceeding down the list until the available budget is
exhausted (Lorie and Savage 1955, Edwards 1977, Kirkwood 1997, Kleinmuntz and
Kleinmuntz 1999, Bana e Costa et al. 2006, Buede and Bresnick 2007, Phillips and Bana e
Costa 2007). The portfolio selected by this approach produces the highest benefit for the
money spent, but may not be the one that produces the maximum benefit for the money
available.

Alternatively, the optimization approach could be followed.


It consists in

searching for the portfolio with the highest benefit for the budget available, by solving a
(knapsack) mathematical programming problem (Martello and Toth 1990, Kellerer et al.
2004) that maximizes cumulative benefit without exceeding the budget constraint
(Weingartner 1963, Golabi et al. 1981, Kirkwood 1997, Kleinmuntz 2007).
As shown in Section 2, the portfolio selected by each one of these two approaches, for
the same fixed budget, is not necessarily the same, because the portfolio selected by the
prioritization approach cannot include any project with a lower benefit-to-cost ratio (that is, a
less “productive” or “profitable” project - Cooper et al. 1999, Brealey and Myers 2003) than
a non-selected project. This is not necessarily the case of the portfolio selected by the
optimization approach. Arguments favoring each one of the two approaches are discussed in
Section 2.
Resource allocation decisions often require project portfolio selections involving
multiple quantitative and qualitative benefit dimensions (or criteria). In a previous paper
(Lourenỗo et al. 2008), we studied commercial off-the-shelf software for multicriteria
portfolio analysis based on additive aggregation of multiple benefit criteria: Equity (Catalyze
2008), HiPriority (Krysalis 2007), Logical Decisions Portfolio (Logical Decisions 2008) and
Expert Choice Resource Aligner (Expert Choice 2007). Equity and HiPriority follow the

1


prioritization approach, Expert Choice Resource Aligner (Expert Choice 2007) follows the
optimization approach, and Logical Decisions Portfolio implements the two approaches.
Section 3 introduces PROBE – Portfolio Robustness Evaluation, a new decision
support system for multicriteria portfolio analysis that implements the optimization approach
but also finds the solutions given by the prioritization approach. When several benefit
criteria are defined, PROBE calculates the benefit value of each project by an additive value
model. Therefore, the basic project inputs for a multicriteria portfolio analysis are the cost of

each project and its value scores on each one of the benefit criteria, and the weights that
capture trade-offs between criteria (see Section 3.1). Different types of project interactions or
interdependencies can also be inputted (see Section 3.2).
For a resource allocation model defined with the data inputted by the user, PROBE is
able to identify all efficient portfolios, distinguishing the convex from the non-convex
efficient ones, and depicts the respective Pareto frontier, running the algorithms presented in
Section 4.1. Several sources of uncertainty are often present in real-world resource allocation
contexts, affecting the precision of some of the inputs. Many times, a “best” portfolio is
selected on the basis of “best guess” input data only. It would then be wise to analyze the
robustness of that “best” portfolio taking into account, simultaneously, uncertain data
affecting the costs and benefits of the portfolios, that is, imprecise project costs and benefit
values and criteria weights. Portfolio robustness evaluation (see Section 4.2) has been the
core motivation for the conception of PROBE, because our previous study of commercial
packages (Lourenỗo et al. 2008) revealed that none of them addresses robustness analysis.
The example in Section 5 illustrates how a robustness analysis can be conducted with the
DSS PROBE within a given uncertainty domain. Some final remarks about our approach are
presented in Section 6, namely a short comparison with the pioneer research of Liesiö et al.
(2007, 2008) on “robust portfolio modeling (RPM)”.
2. Basic concepts and portfolio selection approaches
In this paper, portfolio selection is only concerned with a set X of m projects that worth
funding, therefore assuming that project proposals that do not worth funding were screened
out in a previous phase of the selection process. Conceptually, the benefit value of a project
that adds no value to a portfolio should be zero; consequently, the benefit value of a project
that worth funding should be defined as the value that it adds to the portfolio. Let cj > 0 and
vj > 0 be, respectively, the cost and the benefit value of project j of X (j = 1,…, m) and B the
budget available. For simplicity, without loss of generality, we assume that the m projects of

2



X are presented in decreasing order by their benefit-to-cost ratio r j = vj/cj (j = 1,…, m) such
that r p ≥ r p+1, p = 1,…, m-1, as the four projects (1, 2, 3 and 4) in Table 1 are.
Table 1. Benefit values, costs and benefit-to-cost ratios of four projects.
Projects j
1
2
3
4

vj
3
4
3
2

cj
4
8
10
8

vj/cj
0.75
0.50
0.30
0.25

Let vij be the value score of project j on the benefit criterion i, i = 1,…, n ( n  1) and
wi ( wi  0 ) the weight of criterion i, i = 1,…, n (with




n
i 1

wi  1). The benefit value vj of

project j is given by

vj   i 1 wi .vij .
n

(1)

A portfolio (p) is a subset of projects of X ( p  X ) and the number of possible
portfolios is 2m. Let cp and vp be the cost and the benefit of portfolio p given by, respectively

c p   j p c j

(2)

and

v p   j p vj   jp i 1 wi .vij .
n

(3)

A portfolio p dominates another portfolio d if cp ≤ cd and vp > vd, or if cp < cd and vp ≥
vd. A portfolio is efficient (Pareto-efficient or Pareto-optimal or non-dominated) when no

other portfolio dominates it.
Figure 1 shows all (16=24) portfolios that can be formed with the four projects of
Table 1 (including the empty portfolio {} ).
{1, 2, 3, 4}

12

{1, 2, 3}

Cumulative benefit

10

{1, 2, 4}

8

{1, 2}

6

{2}

4

{1}

2

{}

0
0

2

4

6

8

10

12

14

16

18

20

22

24

26

28


30

Cumulative cost

Figure 1. Chart showing the portfolios that can be formed with the four projects.
Note. Efficient portfolios are represented by triangular dots and dominated portfolios by squared dots.

3


The efficient portfolios are shown as triangular dots and form the efficient frontier (or
Pareto-front), associated for simplicity with the dotted line in Figure 1, whereas the dashed
line links only convex efficient portfolios (the convex efficient frontier, which is the convex
hull of the Pareto-front). As can be seen in Figure 1, there are two efficient portfolios that are
non-convex efficient (those that belong to the dotted line but not to the dashed line): portfolio

{2} and portfolio {1, 2, 4} . Given a fixed budget B, the prioritization approach selects the
convex efficient portfolio formed by the projects j, j = 1,…, k with k ≤ m, such that



k
j 1

c j  B and



k 1

j 1

c j  B . In this approach, the notion of “value-for-money” of a project

(Bana e Costa et al. 2006, Phillips and Bana e Costa 2007, Phillips 2007) or its “bang-for-thebuck” (Cooper et al. 2001, Brealey and Myers 2003, Buede and Bresnick 2007) is associated
with the slope of the benefit-to-cost triangle of each project, as shown in Figure 2 for the four
projects of Table 1. The last column of Table 1 shows that the order of selection by
prioritization would be: first project 1, then project 2, followed by project 3 and finally
project 4. When the budget increases from 0 to 30 (see Figure 2), the sequence of selected
portfolios, from the empty portfolio {} to the full portfolio {1, 2,3, 4} , starts by portfolio {1}
for 4 ≤ B < 12, followed by portfolio {1, 2} for 12 ≤ B < 22, and then portfolio {1, 2,3} for 22
≤ B < 30.
{1, 2, 3, 4}
12

4

{1, 2, 3}

Cumulative benefit

10

8

3

{1, 2}

6


value-for-money slopes
2

4

2

{1}

1

3
4

2

1

{}
0
0

2

4

6

8


10

12

14

16

18

20

22

24

26

28

30

Cumulative cost

Figure 2. Cumulative cost versus cumulative benefit chart showing the portfolios formed by
the benefit-to-cost ratio approach.
Notes. The value-for-money of each project is given by the slope of its benefit-to-cost triangle. The arrow in the
value-for-money slopes box shows the direction of improvement of the benefit-to-cost value of the projects.
The composition of each portfolio is shown in brackets next to the corresponding dot.


Alternatively, the portfolio selected by the optimization approach is the optimal
solution of the following mathematical programming problem (known as the knapsack
problem):

4


m

maximize

v x ,
j 1

j

j

m

subject to:

c x
j 1

j

j


 B,

(4)

x j  0,1 , j  1, , m,

where xj is a binary variable such that xj = 1 if project j integrates the optimal portfolio and xj
= 0 otherwise.
For the four projects in Table 1 and a budget B = 20, the optimal portfolio is {1, 2, 4}
with a benefit of 9 for a cost of 20 (see Figure 1); whereas the portfolio selected by the
prioritization approach, for the same budget, would be {1, 2} with a benefit of 7 for a cost of
12 (see Figure 2).

Figure 1 shows that both portfolios are efficient, but it seems that

optimization identifies a “better” portfolio than prioritization. This is true for a manager only
concerned with getting more benefit (9 > 7), but not necessarily if the “bang-for-the-buck”
received also matters (9/20 < 7/12). Note that portfolio {1, 2, 4} includes project 4, which is
“less productive” than the non-selected project 3 (because r 4 < r 3 – see Table 1). Kirkwood
(1997, Chapter 8.1) and Kleinmuntz (2007) also briefly discuss pros and cons of these two
approaches.
Any efficient portfolio can be selected by the optimization approach, whereas the
prioritization approach always selects a convex efficient portfolio.

When the optimal

solution of the knapsack problem (4) is a convex efficient portfolio, the portfolio selected by
prioritization is the same; but, when the optimal solution of problem (4) is a non-convex
efficient portfolio, the portfolio selected by prioritization is the first convex efficient portfolio
at its left in the convex efficient frontier. This portfolio could be found by constraining the

knapsack problem in such a way that the optimal solution does not include any project with a
lower benefit-to-cost ratio than a non-selected project.1

1

As proved by Dantzig (1957), a portfolio formed through the prioritization approach is included in the optimal
solution of a (relaxed) knapsack problem in which the projects are assumed to be divisible (see also Martello
and Toth 1979). The benefit-to-cost ratio algorithm is also designated by the “greedy algorithm for the
knapsack problem” in (Kellerer et al. 2004, Korte and Vygen 2006).

5


Finally, if there are at least two projects with the same benefit-to-cost ratio, some
convex efficient portfolios are not identified by the prioritization approach. However, the
prioritization approach can easily deal with a large number of projects, contrary to knapsack
optimization algorithms. Indeed, the knapsack problem (4) is technically difficult to solve
despite its straightforward structure, due to the integrality constraints xj {0,1} , j = 1,…, m.2
3. Introducing the DSS PROBE
3.1 The MCDA and PDA components and basic input data
PROBE is a multicriteria decision support system for portfolio robustness evaluation that
integrates two main architectural components: a multicriteria decision analysis (MCDA)
component and a portfolio decision analysis (PDA) component.
The MCDA component allows the user to structure the benefit criteria in the form of a
value tree and input data for the costs of the projects and their benefit scores on each bottomlevel criterion of the value tree. Let X be a specific set of projects j (j = 1,…, m) defined by
the user. Even when uncertainty is present, PROBE always asks the user to input, for each
project j, a (“best guess”) cost cj and (“best guess”) benefit value scores vij on each bottomlevel criterion i, i = 1,…, n (n=1 if only one benefit dimension, such as NPV, is defined).
For a value tree with only one level of n>1 benefit criteria i (i = 1,…, n), (“best guess”)
weights wi (i = 1,…, n) should be introduced and PROBE computes the benefit value vj of
each project j (j = 1,…, m) by applying the non-hierarchical additive model (1). If the value

tree has two or more levels below the root node, crisp weights are defined for the criteria at
each level and PROBE uses a hierarchical value model to compute an aggregate benefit value
vj of each project j (j = 1,…, m) by applying model (1) bottom-up successively. If a branch of
risk criteria is included in the value tree set of criteria, the vj of each project j is more
adequately designated by “risk-adjusted benefit” (Phillips and Bana e Costa 2007). For the
sake of simplicity, without loss of generality, all programs and algorithms presented in this
paper assumes a non-hierarchical benefit model, which can be easily extended to the
corresponding generic hierarchical formulation implemented in PROBE.

2

The knapsack problem is considered to be a nondeterministic polynomial-time hard (NP-hard) problem (for a
discussion on complexity and hardness see Garey and Johnson 1979). A significant number of exact and
approximate resolution algorithms for this problem have been thoroughly studied (Martello and Toth 1990,
Kellerer et al. 2004)

6


For the given project costs cj and benefit scores vj (j = 1,…, m), the PDA component
solves the knapsack optimization problem (4) – with or without additional linear constraints
possibly added by the user to model project interactions (see Section 3.2) – for any fixed
budget B, finds all efficient portfolios, distinguishes convex from non-convex ones (see
Section 4.1) – a functionality not included in the software packages analyzed in (Lourenỗo et
al. 2008) – and displays the portion of the Pareto-front for an user-defined limited portfolio
cost range [ B, B] (see section 4.1). When the number of projects of X is compatible with a
reasonable computational time (see the Appendix), PROBE automatically displays the full
efficient frontier, assuming by default B = 0 and B   j 1 c j .
m


Concerning the modeling of uncertainty, PROBE allows the user to input: a set c of
plausible cost ranges [ c j , c j ] such that cj  c j  c j (j = 1,…, m); a set v of plausible benefit
scores ranges [ vij , vij ] such that vij  vij  vij (i = 1,…, n; j = 1,…, m); linear relationships on
the weights (for example, weights rankings and/or weights ranges) defining a set w of
feasible weights such that wi w (i = 1,…, n). The MCDA component uses the additive
model to calculate by optimization the feasible benefit value range [ vj , v j ] defined by v 
w for each project j (j = 1,…, m) as follows: vj  min  i 1 wi .vij and v j  max  i 1 wi .vij . It
n

w

n

w

is within a user-defined uncertainty domain  = c  v  w that portfolio robustness
evaluation takes place (see Section 4.2).
PROBE is coded in the C++ programming language (Stroustrup 1994, 1997) using the
C++ Builder development software having Microsoft Windows as its target environment.
PROBE uses the mixed integer linear programming (MILP) solver “lp_solve” 5.5.0.14
(available at to solve the optimization problems
included in the PROBE algorithms presented in Sections 4.1 and 4.2. This solver is based on
the revised simplex method and on the branch-and-bound algorithm to deal with integer
variables.

7


3.2 Inputting data for modeling project interactions
Synergies among projects

To address a synergy between the costs or/and the benefits of two projects s and t, an
auxiliary project (s,t) must be added to X together with their conjoint cost c (s,t) and benefit
values vi(s,t) on each benefit criterion i, i = 1,…,n. PROBE then automatically defines an extra
binary variable x(s,t) such that x(s,t) = 1 if both projects are selected for the portfolio, or x(s,t) = 0
otherwise, and adds the following constraint to problem (4):
xs  xt  x s ,t   1.

(5)

Synergies between more than two projects are more complicated to model and imply
more extra binary variables and more constraints as well. Let us see a first example with
three projects s, t and u that synergize only when the three of them are simultaneously
included in a portfolio (that is, they do not synergize when only two of them are together in
the portfolio). In this case, an auxiliary project (s,t,u) must be added to X, and its conjoint
benefit value vi(s,t,u) on each benefit criterion i, i = 1,…,n and conjoint cost c(s,t,u) introduced in
PROBE, which subsequently adds to problem (4) an additional binary variable x(s,t,u) and the
following four additional constraints:

xs  x s ,t ,u   1,
xt  x s ,t ,u   1,
xu  x s ,t ,u   1,

(6)

xs  xt  xu  2.
Constraint on projects
Besides synergy effects, PROBE also allows the user to add other types of constraints to
problem (4), to model different types of project interactions, such as:







Force in a project j
x j  1.

(7)

x j  0.

(8)

Force out a project j

Dependency between two projects i and j (i can only be selected if j is also selected)
xi  xj  0.

(9)

8




Mutual inclusivity of two projects i and j
xi  xj  0.

(10)


Note: Dependencies or mutual inclusivity among more than two projects are easily
modeled by adding extra constraints of types (9) or (10), respectively.


Mutual exclusivity of two projects i and j
xi  xj  1.

(11)

Mutual exclusivity of more than two projects are easily modeled by adding extra
binary variables in the left hand side of (11).


Group constraints on a subset G of nG projects (1 ≤ nG ≤ n), such as (with 0 ≤ q ≤ nG)



jG

x j  q,

(12)



jG

x j  q,

(13)




jG

xj  q.

(14)

PROBE includes an interface that allows the user to add to problem (4) any other type
of linear constraint. A feasible portfolio is a portfolio that respects all of the constraints
introduced by the user.
4. PROBE innovative functionalities
4.1 Finding all efficient portfolios within a given portfolio cost range
For project costs cj and benefit scores vj (j = 1,…, m) given by the MCDA component, and
supposing for now that no project interaction constraints were defined, the PDA component
starts searching for the efficient portfolios, within a given portfolio cost range [ B, B] , by
solving problem (4) with B  B . Next, problem (4) is again solved with B equal to the cost
of the optimal portfolio previously found minus a small enough amount ; and so on while

B  B . The algorithm designed to implement this process, FindEfficientPortfolios, presented
in Figure 3, is also capable of identifying all possible multiple optimal solutions. Finally,
PROBE uses another algorithm, FindConvexEfficientPortfolios, presented in Figure 4, to
differentiate convex efficient from non-convex efficient portfolios.

Additional linear

constraints of the types described in Section 0 can easily be added to both algorithms to take
project interactions into account when finding efficient portfolios.


9


Algorithm FindEfficientPortfolios(c, v, B , B )
Given the cost cj and benefit value vj of each project j (j= 1,..,m) of a set X of m projects, algorithm
FindEfficientPortfolios finds the whole set of efficient portfolios for a given portfolio cost range, defined by
its lower and upper bounds B and B , respectively. The optimization problem inside each solve call is
presented including only the cost constraint, but other linear constraints can easily be added. The efficient
portfolios found by the algorithm are stored in a matrix mEP with a number of rows equal to the number of
efficient portfolios and a number of columns equal to m+ 2. Each row stores the data of one efficient
portfolio, with its cost inserted in the first cell and its benefit value in the second one, and each of the other
m cells corresponding to each project j, j=1,…m, in such a way that 1 is inserted in cell j+2 if project j is
included in the portfolio, or 0 otherwise. When searching for multiple optimal portfolios with the same
cost, each time an optimal portfolio is found a constraint is added to the optimization problem to prevent
that portfolio to be found again; the set of these constraints is designated by NRS. At the end, the efficient
portfolios stored in matrix mEP are sorted by increasing order of cost.
initialization
B : B ; stop := false; duplicate := false; := 10-6; r := 0
search for efficient portfolios
while (stop = false) do
if (duplicate = false) then
m
solve ( z : max  j 1 vj xj , s.t.
else



m
j 1


c j xj  B , xj  0,1 )

search for other optimal portfolios with the same cost
m
solve ( z : max  j 1 vj xj , s.t.  j 1 c j xj  B , NRS, xj  0,1 )
m

end if
if (a portfolio is found and



m
j 1

c j x*j  B ) then

add one row to mEP; r := r + 1
mEP[r][1] :=



m
j 1

c j x*j

mEP[r][2] := z
for (j := 1 to m) do
mEP[r][j + 2] := x*j

end for
if (duplicate = false) then

stores the cost of the portfolio found
stores the benefit of the portfolio found
stores the solution found

B :  j 1 c j x*j ; duplicate := true
m

end if
for (j := 1 to m) do
prepares the LHS of a new NRS constraint
sets the variables with the solution found
xj : x*j
end for
m
m
add to the optimization problem the new NRS constraint  j 1 xj  j 1 x*j  1
else if (duplicate = true)
remove the NRS constraints from the optimization problem

B :  j 1 c j x*j   ; duplicate := false
m

else
stop := true
end if
end while
reverse the order of portfolios in mEP

return mEP

to get them sorted by increasing cost

Figure 3. Algorithm FindEfficientPortfolios.

10


Algorithm FindConvexEfficientPortfolios(mEP)
Given a matrix mEP of efficient portfolios found with algorithm FindEfficientPortfolios, algorithm
FindConvexEfficientPortfolios finds which ones are convex efficient. A new column denoted as “lastCol”
is added to mEP to register which portfolios (one by each row) is, or it is not, convex efficient, in such a
way that 1 is inserted in cell lastCol if the corresponding portfolio is convex efficient or 0 otherwise.
initialization
stop := false; pos := 1; r := 1; lastCol:= m+3
endPos := number of rows of the matrix mEP
add one more column to the right of mEP and set all the values of the lastCol to 0
mEP [1][j] := 1
records the first entry of mEP as the first efficient portfolio
if there is only one efficient portfolio the algorithm stops
if (endPos = 1) then
exit
end if
search for convex efficient portfolios
while (stop = false) do
maxSlope := -1
maxIter := -1
for (iter := pos + 1 to endPos) do
if (mEP [iter][2] - mEP [pos][2] = 0) then

maxIter := iter
exit for
else
slope := (mEP [iter][2] - mEP [pos][2])/( mEP [iter][1] - mEP [pos][1])
if (slope > maxSlope) then
maxSlope := slope; maxIter := iter
end if
end if
end for
mEP [bestIter][lastCol] := 1
records the efficient portfolio found
if (maxIter = endPos) then
stop := true
else
r := r +1; pos := maxIter
end if
end while
return mEP

Figure 4. Algorithm FindConvexEfficientPortfolios.

11


4.2 Portfolio robustness evaluation
For the given costs cj and benefit scores vj (j = 1,…, m) of the projects, let p*, with cost cp*
and benefit vp*, be a specific efficient portfolio selected by the user, either by asking PROBE
to found the optimal solution of problem (4) for a fixed budget B or by inspection of the
efficient portfolios found by PROBE within a portfolio cost range [ B, B] . In one situation or
the other, the user may be concerned with the robustness of the choice of p* in face of an

uncertainty domain  (see Section 3.1), within which c p* c p* c p* and v p* v p* v p* .
Portfolio robustness evaluation (PROBE) is based on the extension of the MCDA
notion of “additive dominance” between projects (Bana e Costa 1990, Bana e Costa and
Vincke 1995) implemented in the original preference robustness evaluation PROBE software
(Bana e Costa 2001, Bana e Costa et al. 2007). Given an uncertainty domain , we say that
portfolio p* additively dominates portfolio p if and only if the result z of optimization
problem (15) is non-negative:






z : min  wi   vij   vij   vij  
 j p

i 1
j p 
 j p*



j
p
j
p
*
*




n

subject to:

c c
j p
j p*

j

j p*
j p 

j

 0,

(15)

wi w , i  1,, n .
Which portfolios p (henceforth called candidates) should be pairwise compared with
portfolio p*? Using algorithm FindCandidates, described in Figure 5, PROBE takes as
candidate any portfolio p such that there exists at least a point in the given uncertainty
domain  where the cost of p is not higher than the cost of p* and the benefit of p is not
smaller than the benefit of p*. Next, PROBE uses algorithm FindNonDominatedPortfolios,
described in Figure 6, to solve problem (15) for each candidate portfolio p and find which
portfolios p (the competitor portfolios) are not additively dominated by p* (the proposed
portfolio).


12


Algorithm FindCandidates(, p*)
Algorithm FindCandidates selects “candidate portfolios” p that may be non-dominated by p* given an
uncertainty domain . The candidate portfolios p are stored in matrix mCP.
initialization
c p* :  j p* c j

stores the upper bound cost of the efficient portfolio p*

compute v p*
store vj* ,  j p*

computes the minimum benefit value of the efficient portfolio p* given v  w

vS : M
stop := false

M denotes a huge positive finite real number



the v j * are the benefit values of projects j  p * when the benefit value of p* is minimum


search for candidate portfolios
while (stop = false) do
solve( z : max  vj xj 
j p *


 v x , s.t.  c x   c x

j p *

j

j

j p *

j

j

j p*

j

j

 c p* , xj  0,1 , j  1,, m )

if ( z  v p* ) then
add one row to mCP
store the result z and the portfolio found p in the new added row of mCP
if ( z  vS ) then
vS : z
if (there are bound or/and NRS constraints added on previous iterations) then
remove the bound and NRS constraints previously added

endif
add to the optimization problem the bound constraint
for (j := 1 to m) do
xj : xj



m
j 1

v j xj  vS

prepares the LHS of a new NRS constraint
sets the variables to the solution found

end for
add to the optimization problem a new NRS constraint



m
j 1

xj  j 1 xj  1
m

else
for (j := 1 to m) do
xj : xj


prepares the LHS of a new NRS constraint
sets the variables with the solution found

end for
add to the optimization problem a new NRS constraint



m
j 1

xj  j 1 xj  1

endif
else
stop := true
endif
end while
return mCP

Figure 5. Algorithm FindCandidatePortfolios.

13

m


Algorithm FindNonDominatedPortfolios(v, w, p*, mCP)
Algorithm FindNonDominatedPortfolios searches for portfolios that are non-dominated (the competitor
portfolios) by the efficient portfolio p*(the proposed portfolio) given an uncertainty domain. The

algorithm analyzes the matrix mCP of candidate portfolios p previously found by algorithm
FindCandidates. The non-dominated portfolios found by algorithm FindNonDominatedPortfolios are
stored in a matrix mNDP.
initialization
k := 1
search for non-dominated portfolios
for (k := 1 to the number of rows of mCP) do
p := mCP [k]
the projects of the k candidate portfolio are used to define p







solve ( z : min  wi   vij    vij   vij   , s.t. wi w , i  1,, n )


i 1
j
p
j
p
j
p



*

 j p *


j p *



if the portfolio p is non-dominated by p*
if ( z  0 ) then
add one row to mNDP
store the result z and the portfolio p in the new added row of mNDP
k := k + 1
end if
end for
return mNDP
n

Figure 6. Algorithm FindNonDominatedPortfolios.
We say that the choice of p* is undoubtedly robust when no portfolio p exists.
Otherwise, for each portfolio p PROBE solves problem (16)






z : max  wi   vij   vij   vij  
 j p

i 1

j p 
 j p*



j
p
*
j
p
*



n

wi w , i  1,, n .

subject to:

(16)

The result z is the upper bound of the range of variation of the difference between
the benefit value of the proposed portfolio p* and the benefit value of the competitor
portfolio p in the uncertainty domain :  v p*  v p    z, z  , with the lower bound z


already calculated by problem (15).

Finally, using expressions (17) and (18), PROBE


calculates the lower bound d and upper bound d of the range of variation of the difference
between the costs of p* and p in :  c p*  c p   d , d  .


d

c c

j

(17)

c c

j

(18)

j p
j p*

d

j p
j p*

j

j


j p*
j p

j p*
j p

14


The user is then in conditions of analyzing the differences in cost and benefit between
the proposed portfolio p* and each competitor portfolio p , as illustrated with an example in
Section 5. Finally, “star projects” can be identified as those projects that are common to the
proposed portfolio p* and all of its competitors.
5. Example
A manager has to allocate resources to 12 projects from four departments, totaling €14
million (see Table 2), largely exceeding the €5 million available. The manager and the four
department directors constitute the decision making group (DMG) that developed a portfolio
decision analysis with the support of PROBE. The DMG evaluated the added value of each
project on each one of four benefit criteria (B1, B2, B3 and B4). The respective benefit value
scores of the projects are shown in columns “B1” to “B4” in Table 2. Using this data and the
criteria weights indicated in the last row of Table 2, the MCDA component of PROBE
computed the benefit values of the projects shown in the last column of Table 2.
Table 2. Basic input data of the 12 projects and MCDA output
Project
P01
P02
P03
P04
P05

P06
P07
P08
P09
P10
P11
P12
Weights

Dept
A
A
A
A
B
B
B
B
C
C
D
D

Cost
(€106)
1.1
1.9
0.9
0.9
1.8

1.3
1.3
1.1
0.9
1.3
0.7
0.8
=14

B1
67
55
100
90
48
43
42
40
80
88
41
86
0.31

Benefit value scores
B2
B3
40
30
37

40
90
80
80
70
35
40
32
25
64
80
50
44
90
78
66
80
48
49
88
90
0.19

0.29

B4
50
20
90
95

33
44
55
20
66
70
25
72

Benefit
value
47.57
39.88
90.20
83.35
40.06
35.90
59.93
38.86
78.38
77.72
41.29
84.60

0.21

Figure 7 is a snapshot of the main window PROBE, displayed by the PDA component
for the basic input data in Table 2. The portfolio selected by the optimization approach,
solving the knapsack problem (4) for a budget of €5 million, is the efficient portfolio (4.8,
414.25)3, indicated by a star dot in the graph, with cost €4.8 million and a benefit of 414.25

and composed by five projects, P03 and P04 of Dept A, P09 and P10 of Dept C and P12 from
Dept D, as highlighted in the tables above the graph.

3

For the sake of brevity, we will use the ordered pair (x, y) to denote the portfolio with cost €x million and
benefit y.

15


Figure 7. PROBE analysis of efficient portfolios.
Notes. Each row of the top-left table shows information about one efficient portfolio: a 1 or a 0 in column “CE”
indicates whether the portfolio is convex efficient or non-convex efficient, respectively; a 1 or a 0 in each one of
the columns“P01” to “P12” indicate whether the respective project is included or not, respectively, in the
portfolio. The top-right table window shows the projects structured within areas (the four departments). Each
efficient portfolio is represented by a dot in the bottom graph (where the star dot indicates the selected
portfolio), with the convex efficient ones linked by a dotted-line.

This optimal portfolio (4.8, 414.25) is convex efficient, therefore it is also the one
selected by the prioritization approach as shown in Table 3. (This implication would not be
necessarily true if additional project interaction constraints had been defined.)
Table 3. Projects ranked by decreasing benefit-to-cost ratio (order of priority).
Project
P12
P03
P04
P09
P10
P11

P07
P01
P08
P06
P05
P02

Benefit
84.6
90.2
83.35
78.38
77.72
41.29
59.93
47.57
38.86
35.9
40.06
39.88

Cost
0.8
0.9
0.9
0.9
1.3
0.7
1.3
1.1

1.1
1.3
1.8
1.9

Ratio
105.8
100.2
92.6
87.1
59.8
59.0
46.1
43.2
35.3
27.6
22.3
21.0

16

Cumulative cost
0.8
1.7
2.6
3.5
4.8
5.5
6.8
7.9

9.0
10.3
12.1
14.0


The director of Dept B argued against the selection of portfolio (4.8, 414.25) because
it does not include any project from his department. The DMG decided to analyze what
would be the loss of benefit of imposing that at least one project from each department must
be selected. Accordingly, four constraints of type (13) with q = 1 were added to PROBE,
giving rise to the new results shown in Figure 8.

Figure 8. PROBE analysis of efficient portfolios with group constraints.
The optimal portfolio is now (4.8, 396.46), by coincidence with the same cost of
portfolio (4.8, 414.25) but giving less 17.79 units of benefit, caused by replacing P10 by P07,
as well noted by the director of Dept C.
The robustness of selecting portfolio (4.8, 396.46) was then evaluated for an
uncertainty domain  defined by all benefit value scores of all projects on all criteria varying
±10 units and the weights varying within the bounds indicated in Table 4.
Table 4. Uncertainty on the weights.
Criterion

Weight

B1
B2
B3
B4

0.31

0.19
0.29
0.21

Lower
bound
0.26
0.14
0.24
0.16

17

Upper
bound
0.36
0.24
0.34
0.26



×