6.3 Portfolio balancing
6.3 Portfolio balancing
The level of utilization an organization can sustain is determined not only by the amount of resources it possesses, but also by the nature of its work. The more unpredictability in the workload and the longer the duration of the projects it undertakes, the more white space or slack the organization will need to consistently deliver on its commitments.
6.3.1 Forecasting resource needs
Once the project's expected effort has been calculated, it is necessary to break it down according to competence types and spread it over the expected project duration. Since at this stage detailed plans for the project might not yet exist, the breakdown and the spreading of the effort would have to be based on project profiles, rather than on actual allocations.
Each project profile would specify the following:
-
The EffortBreakdownRatiopc for competence area c in projects of type p.
With
EffortBreakdownRatiopc = 1. -
The SpreadRatiopct for projects of type p of the apportioned efforts to competence c at relative time t. Again
SpreadRatiopct = 1.
An organization will typically have several project profiles, one for each class of projects, such as new platform development, product extension, research, and maintenance. The monthly or quarterly demand for each competence for a given project is calculated using the following expression:
See Table 6.10 for a numerical example of the utilization of techniques used to calculate the resource needs for a typical software development project.
| Step | Inputs and Process | Result |
|---|---|---|
| 1 | The expected duration and its standard deviation are calculated using a three point estimate. |
|
| 2 | The expected effort and its standard deviation are calculated using a three point estimate. Assume that: |
|
| 3 | The expected effort calculated in Step 2 is allocated to the different disciplines, competences or resource types taking part in the execution of the project. The project profile for this type of project specifies the planning constants to be used. |
|
| 4 | The effort for each discipline is spread over the duration of the project by multiplying the allocated man hours, see Step 4, by the constants below. Different types of projects are likely to have different constants. The constants form part of the project profile for that type of project. The normalized time is converted to project time by dividing the expected time calculated in Step 1 by the number of intervals, in this case 12, and multiplying it by the interval number. |
|
| 5 | The result is ready to be aggregated with other projects in the portfolio. |
Once the time-phased needs of the projects have been calculated, it is time to aggregate the individual requirements into the master plan. The aggregated demand would be
Since the projects in the portfolio have different objectives, teams, and project managers, it can be assumed that the actual time and effort required by each is largely independent of the others; in consequence, the standard deviation of the portfolio workload could be calculated as the square root of the sum of the squares of the standard deviations of each individual project. See below.
The contingency to be added to PortfolioDemandct to avoid the risk of exceeding the expected workload with a predetermined probability p can be calculated using the expression below[2]:
Or if the number of concurrent projects in the portfolio is greater than fifteen,[3] this can be done by looking at a table of normal probabilities.
Table 6.11 shows the amount of contingency to be added to the expected portfolio demand so that the probability of exceeding that amount will be lower than a prescribed value.
| Probability of Exceeding Planned Resources | Contingency To Be Added for Each Resource Type | |
|---|---|---|
| Fewer than 15 concurrent projects | 15 or more concurrent projects | |
| Higher risk tolerance 25% | 1.73 σ(PortfolioDemandct) | 0.68 σ(PortfolioDemandct) |
Once the workload and the contingency are calculated, these numbers must be transformed into head count by dividing the aggregated number of hours required by the effective number of work hours per month. The conversion factor from man-hours to head count can be easily calculated by subtracting from the nominal number of work hours, the average number of training hours, vacation, and sick leave. More mature organizations can include other factors, such as recruiting lead time, learning curves, and turnover rates; however, it is important to remember that for resource planning purposes, the consistent use of the numbers is as important, if not more important, as their accuracy. This is because if different departments use different definitions to plan and account for time, the results will be irremediably meaningless.
The contingency or slack added to the plans is not idle time. It is the time that the organization would use to do its training, its process improvement, and other like activities that could be postponed without too much harm should the need arise. The use of contingency time, however, must be closely scrutinized so that it is not used to hide or compensate for deficiencies in the planning and execution of the projects at the expense of these nonurgent, but nonetheless critical, activities for the long-term survival of the organization.
6.3.2 Forecasting revenues
Once the product or business managers have estimated the revenues to be generated by a given project, the process of spreading them over the life span of the product and aggregating across the portfolio is, with two exceptions, identical to the one used for spreading the resource demands of a project.
The first difference between the resource demands and the revenues stems from the time value of money. One hour of work today and one hour of work tomorrow represent exactly the same value. This is not the case with money, which is affected by inflation and by the cost of capital. In practical terms, this means that any amounts spread over time must be adjusted by inflation and by the cost of capital for any comparison to be meaningful. The formula to convert any future amounts to today's value is
where
| i = | dicount rate |
| t = | period in which the Amount takes place |
The second difference is that the assumption of independence used in the calculation of the standard deviation of the portfolio demand might or might not hold for the projects' revenues. As an example in which the revenues of two projects are not independent, take the sales generated by a project that delivers an update to a product developed by a previous project. Obviously, the revenues to be generated by the update will depend largely on the sales of the original product. If the original product was sold in large quantities, the update will likely sell in large quantities as well. Likewise, if the original product did not sell well, the update is not likely to sell well either.
In the example above, the revenues to be generated by both projects are correlated. Although the aggregated value of the revenues is calculated as before, the standard deviation is calculated using the formula below, or by means of Monte Carlo simulations.
where ρij ∈[−1,1] = the extent of the relationship between projects i and j; −1 means a perfectly inverse relationship; 1 a perfectly direct relationship; 0 no relationship at all; and the rest of the numbers something in between. The value of ρij must be "guessed" by the product manager.
6.3.3 Eliminating less valuable alternatives
Whenever a decision to scale back, terminate, or not pursue a particular project is about to be made, in addition to any direct losses or gains arising from it, it is necessary to consider the consequences of the decision across the entire portfolio.
A propagation matrix[4] (see Table 6.12) is a square matrix that records the extent to which a project j depends on another project i.
 |
| i | j | Project 2 | Project 3 | … | Project n − 1 | Project n |
|---|---|---|---|---|---|---|
| | ||||||
| Project 1 | 0 | 0.25 | 0 | 0.30 | 0 | |
| Project 2 | 0 | 0 | 0.90 | 0.5 | 0 | |
| Project 3 | 0.30 | 0 | 0 | 0 | 0 | |
| … | 0 | 0 | 0 | |||
| Project n − 1 | 0 | 0 | 0 | 0 | 0.25 | |
| Project n | 0 | 0 | 0 | 0 | 0 | |
|
The exact meaning of pij depends on what it is we are trying to propagate. For example, if we are trying to propagate effort from one project to another, pij would represent the percentage increase of work in project j to compensate for what is not going to be done in project i, should this be canceled. If what we are trying to propagate is the loss of revenue in project j resulting from the cancellation of project i, the meaning of pij is the percentage of the total revenue of project j that would not be realized in the event i is canceled. Each dimension, the consequences of which we would like to propagate through the portfolio, would require a different matrix.
Table 6.13 details the process by which the effects of a decision are propagated across the portfolio.
|
|
|
|
|
|
Although comparing the rows and columns of the propagation matrix could signal how strongly a project influences the outcomes of other projects in the portfolio, or how dependent a project is on other projects, these indicators alone must be used with caution, since a large number of small dependencies could be offset by a single dependency that affects a very large project.
6.3.4 The portfolio approach
The reason for instituting project portfolio management in an organization is to select and execute those projects that balance its conflicting needs, such as high returns and low risk, current versus future returns, capacity to quickly respond to new demands and efficiency, and so on. Consequently, once the benefits to be derived from the execution of individual projects has been evaluated, or revisited in the case of projects already in the portfolio, it is time to decide how the organization's resources should be allocated across the different projects in order to achieve the balance sought.
6.3.5 Building visual maps
Visual mapping tools use graphical and charting techniques to simultaneously portray the benefits and costs of the projects under consideration. Probably the most conspicuous of these is the bubble diagram (see Figure 6.11) that shows the projects in a two-dimensional plot [9], using the size and sometimes the color or shape of the "bubbles" to convey additional project information. Each of the axes of the diagram corresponds to a dimension on which the project is ranked.
Figure 6.11: Bubble diagram.
Generally, two bars are drawn dividing the chart space into four quadrants. Each bar defines a threshold that projects must exceed in order to be included in the portfolio. The most popular diagram is a risk-return diagram (such as the probability of technical success and reward). In this case, each quadrant represents a different combination of risk/return: low-risk/ low-return; high-risk/high-return; low-risk/high-return; high-risk/low=return.
Other visual mappings (see Figure 6.12) show the number of resources required over time as a function of technology or stage of innovation of the products the projects support.
Figure 6.12: Resource-requirements map.
Because of their ability to portray in a simple way complex relationships between or among projects, visual maps are one of the most popular tools employed in balancing the project portfolio.
6.3.6 Ranking projects
The paired comparisons method (see Figure 6.13) ranks projects against one another in one or more dimensions. In its simplest form the method uses a single rating (i.e., which of two projects being compared is better with respect to a certain attribute); in sophisticated approaches, the method allows for a value specifying how much better (i.e., twice as good, three times better), one project is with respect to the other.
Figure 6.13: Paired comparisons process.
The output of the paired comparisons method is a matrix or table (see Table 6.14) called a judgment matrix, which contains the result of the comparisons between all possible pairs of projects for each dimension being evaluated.
|
| Project 1 | Project 2 | Project 3 | … | Project n − 1 | Project n | |
|---|---|---|---|---|---|---|
| | ||||||
| Project 1 | 1 | 1 | 1.5 | … | 3 | 5 |
| Project 2 | 1 | 1 | 1.5 | … | 2 | 5 |
| Project 3 | 0.67 | 0.67 | 1 | … | 2 | 4 |
| … | … | … | … | 1 | … | … |
| Project n−1 | 0.33 | 0.5 | 0.5 | … | 1 | 1.5 |
| Project n | 0.2 | 0.2 | 0.25 | … | 0.67 | 1 |
|
where 
is the relative importance of project i with respect to project j along dimension d as judged or perceived by the evaluator. In Table 6.14, Project 1 is judged to be equally as important as Project 2, a12 = 1, and Project 1 is judged to be 3 times better than Project n − 1, a1n − 1 = 3. Notice that in a perfectly consistent judgment matrix all elements satisfy the condition aij ajk = aik, which is clearly not the case in Table 6.14, where Project 1 is judged to be 1.5 times better than Project 3 and 5 times better than Project n, but Project 3 is judged 4 times better than Project n, whereas in a perfectly consistent judgment it should have been said to be 
times better. The good news is that these inconsistencies, if kept within certain limits, are actually good, since nobody knows what the true value is anyway. Remember that the values are judgments, and by definition, judgments are subjective.
If there are n projects being compared among m dimensions, the total number of comparisons to be made is 
. To prevent this number from growing too large, which is the major drawback of this method, it might be necessary to break down the total portfolio into subportfolios based on customer, product line, or some other relevant criteria.
A verbal scale like the one shown in Table 6.15 can be used to facilitate the judgment process by avoiding lengthy and futile discussions about whether a particular project is twice or twice and one quarter more important than the other, without affecting its output in a significant way.
|
| Definition | Explanation | aij value if project i is preferred to project j | aij value if project j is preferred to project i |
|---|---|---|---|
| | |||
| Of equal value | The two projects are roughly of equal value. | 1 | 1 |
| Slightly more (less) value | Experience and/or judgment recognizes one project as being somehow more (less) valuable than other. | 3 | .33 |
| Essential or strong (weak) preference | Experience and/or judgment strongly favor one project over other. | 5 | .2 |
| Very strong (weak) preference | The dominance of one project over other is self-evident. Dominance is demonstrated in practice. | 7 | .14 |
| Strongest (weakest) preference | The difference between the projects being compared is of an order of magnitude | 9 | .11 |
| Intermediate values between adjacent scales | When compromise is needed | 2, 4, 6, 8 | .5, .25, .16, .12 |
| After: [10] | |||
|
Once the judgment matrices, one for each dimension, have been completed, the next step is to verify the consistency of the comparisons and derive a ranking from them. This is the point at which the different methods—logarithmic least squares (see Table 6.16) and the eigenvectors method, better known by its commercial name as the analytic hierarchy process (see Table 6.17)—differ.
|
|
|
|
|
|
|
|
|
|
These methods might seem overly complicated for simple one-dimensional comparisons; however, they become invaluable when it is necessary to produce a ranking of projects across a hierarchy of sometimes conflicting attributes. The mathematics in this case are similar to that presented here, with the result of one dimension being scaled by the relative weights of the dimensions.
[2]The formula for k is derived from a one-tailed version of Chebyshev's inequality, which states that 
[3]We assume that the distribution of the sum of the projects' demands tend to a normal distribution via the central limit theorem. More stringent conditions could be imposed or other distributions deemed more appropriate under special circumstances, but this will come at the expense of formulations that are more complicated. Therefore, a balance must be struck between accuracy and practicality.
[4]This is referred to as a dependency matrix in Reference [7]; however, I decided to call it a propagation matrix in order to avoid any confusion with the dependencay matrix described in Chapter 3.
EAN: 2147483647
Pages: 81