8. Project Portfolios

No matter how someone chooses to work in an organisation, resources are limited and depend, for example, on what money is available for new investment, or which staff are available to work on projects. These limitations mean that not everything can be achieved, and organisations must choose where to put their resources. This choice is an important part of portfolio management. There are many methods and types of support that can be used to help an organisation make the choice, but each has both advantages and disadvantages.

Often, the decision situations with which we are faced are complex, and we need a decision process. A large proportion of the total working time is therefore spent on collecting, processing, and compiling information to create a reliable decision basis with all relevant information and all reasonable possibilities. As noted in the previous chapters however, decision-makers within an organisation are often required to make decisions based on a lack of clarity, and at worst on pure intuition. There is thus a great risk of making the wrong decision. The risk problem can be managed by introducing quality-assured decision-making processes that handle everything from idea generation to the identification and valuation of possible strategies to implement and follow up.

Most traditional decision models require relatively well-structured problems, however. By following a clearly defined process, the decision-maker can improve their overview of the decision material and the overall perspective of the problem. Such a work process cannot, of course, be simplified into a single formula, and must be well integrated into the organisation in order to effectively systematise and manage existing decision-making bases and uncertainties. We will present some examples that are common in project and portfolio management, and which gradually develop the decision model, pointing out the advantages and disadvantages of the respective methods. We will start with a simple method for project selection and end with an example of a multi-criteria-based model.

Common project models can be divided into two categories: quantitative and qualitative. Quantitative models create a basis for decision-making by quantifying and translating, for example, benefit or risk into money, while qualitative models are softer and focus on creating a discussion basis on which to work and ultimately from which to make decisions.

As you read about the below methods, consider how you think a more formal process should look. What is missing, and would prevent you from feeling comfortable making decisions based on the information each model contributes?

In Figure 8.3, we can see that business support (criterion 1) is considered slightly more important than well-defined project benefits (criterion 4), which in turn are more important than the return on investment (criterion 3), which is perceived as slightly more important than technical knowledge (criterion 2).

The overall structure and results of the rankings can then be modelled in a single-level multi-criteria tree, as in Figure 8.4.

Financial models deliver analyses based on financial data, such as the speed of the return on investment, the anticipated monetary value of the investment at a future point in time, or various types of comparison between costs and revenues. This information is important and should not be disregarded, but its value from a project portfolio perspective is limited, as the models disregard the soft benefits to which IT projects in particular contribute, and also owing to the fact that IT projects tend to be complex and permeate large swathes of the business, which makes it difficult to pinpoint the effects of IT investments, as they are often dispersed across the organisation. The last, and perhaps most serious, drawback is that benefits must be expressed in monetary value, which we know is almost impossible for soft benefits. Despite these problems, the models are still used extensively in project portfolios, for the simple reasons that they are seemingly easy and inexpensive to use, and that financial arguments carry weight in organisational decision processes. Some examples of financial models used in portfolio management are presented below.

The analysis of present value and future value introduces the parameter of time and considers what the value of an investment will be if return requirements and fluctuations in the value of money are taken into account. The present value is derived by recalculating all of the project’s payment consequences (expected payments and disbursements) since the project began, then adding them up, and discounting them according to relevant interest rates. Future value is instead derived by calculating the corresponding total at some point in the future. Normally, money now is preferable to the same amount of money at some point in the future (time preference). Future amounts may not be secure (What will sales actually be? How long will development take, and what will the hourly rates be?) and a compensation for the risk taken is desirable. The amounts are therefore calculated using an interest rate that includes both the time preference and the risk. The further into the future an amount falls, the less it is worth today (net present value).

The payback method focuses on how fast an investment pays for itself, or how quickly money is returned (the repayment period). If EUR 1,000,000 is invested in starting to sell goods through a company’s website and there is an increase in revenue due to the investment of EUR 200,000 per year, it will take five years to get the investment back (disregarding inflation and interest rates). In a situation where we are to evaluate prospective projects, we must define an acceptable payback period and compare the various projects to it. According to this approach, the method with the shortest payback or repayment time should be chosen. Unfortunately, it is rarely that simple, and there are other aspects that must be considered.

Benefit versus Cost

Another common method is to try to compare the utility of a project with the cost. Simply put, if the benefit of a project is greater than the cost, it is a good investment. There are certain challenges with this method, as it requires all parameters to be quantified (usually in monetary terms), which can be very difficult. Several researchers and organisations, such as the Gartner Group, have tried to create frameworks/models to calculate the benefits of an IT investment, so far without complete success, which makes the model valuable mostly in theory, but unfortunately not easily practically applicable to IT investments. It is simply too difficult to quantify the benefits, and it is often almost impossible to accurately pinpoint the precise benefits that an IT project will yield. Digitisation is a complex interweaving of IT use and organisational practices, and tangible organisational outcomes that someone claims stem from a digitisation project could be partly or wholly due to other factors, either internal or external to the organisation. Even if the benefits can be quantified, it is important to remember that this model only evaluates a specific investment from a cost/benefit perspective, and not whether it is right according to strategic reasoning, ethical, social, or other standards.

Unlike the quantitative models presented earlier, qualitative models focus on soft benefits and values and try to analyse them from a more holistic perspective. Examples of models used in projects and portfolio management are presented below.

8.2.2.1. Expert Groups

A common means of evaluating project portfolios is simply to use expert groups that, through discussion and possibly modelling, decide which projects it is relevant to start. This way of working is not as rigorous as, for example, multi-criteria analysis, but still works well in cultures and situations where consensus-building is important, such as Sweden. Of course, these discussions can be carried out with the help of more rigorous practices, such as workshops and modelling, but they lack the numerical basis that many quantitative models generate. The idea behind this approach is that since most consequences of IT use are difficult to quantify, we should instead focus on discussing and intuiting or “guessing” the value of the benefits.

8.2.2.2. Sacred Cow

Unfortunately, the sacred cow is an all-too-common way of selecting projects. In effect, this means that a project is proposed by someone in the organisation who has great power, such as the CEO, and because of this, the project is begun, since there is little or no opposition to a proposal from the CEO. These projects are seldom successful, and usually become empty shells without money or resources. Of course, there are exceptions. One is Steve Jobs’ firm enforcement of the proprietary nature (patents or rights owned by the organisation) of Apple’s products. This worked, because users in general were not interested in customising their computers, and were rather more focused on usability and function. Even though this decision took some time to be accepted by consumers, today it can be considered highly successful.

8.2.2.3. Necessity

All organisations have an outside world by which they are affected but cannot control. This sometimes forces them to run projects, such as new legal requirements that make it necessary to correct a product, increase security, and so on. Another example is a bank offering to handle customer banking issues via the Internet. This should be seen as necessary if the banks do not want to lose their market share. There are different types of requirements to which an organisation can be exposed. Their only similarity is that they force action and change. Operating systems such as MS Windows, OS X, iOS, and Android, which serve as a foundation for other products, are good examples of must-have projects. Microsoft no longer has a choice on whether to develop Windows further or not, since so much of their business depends on it. In these cases, project evaluation is unnecessary, and the focus should be on implementing the projects as smoothly and cost-efficiently as possible.

8.2.2.4. Product Improvement / Extension of Product

Today, organisations must work actively with their products and develop them continuously in order to compete within their field. There are examples in all industries and in almost all types of products. In the automotive industry, this process of renewing the design of an older model, or modernising its look and thus the user experience, is called a face-lift. In the IT industry, it is seen in updated versions of existing software, apps that can be expanded and that continuously get new features, and so on. Improving or expanding existing products is central, as it is not only cost-effective, but also extends a product’s lifecycle, as these are becoming shorter and shorter.

The challenge faced by the leader of a project portfolio is to find the right balance between different projects. They must decide which projects should be started so as to ensure that there are new platforms in progress, come up with new technology, develop new products, and improve existing ones. Each project idea is evaluated to ensure that it fits into the portfolio structure, so as to avoid a situation whereby, for example, as a product company, there are no new products in progress or too much time is spent on research. To support the work of balancing the portfolio, there are a number of tools that not only help us choose projects, but also visualise how the portfolio should look.

Instead of evaluating specific projects using quantitative and qualitative models, we can look at how our company portfolio is balanced, the types of projects we run, and match that with what kind of organisation we want to be. For example, a company should have a healthy mix of new development, improvement of established products, and in some cases research; if any of these is missing, the company risks being left without products in the future. By continuously analysing the balance of a project portfolio, one can invest in the right projects, i.e. those that will help the organisation to survive and be competitive in the future. Below are two examples of how this approach can be implemented. The first example is based on the model of the aggregated project plan and the second uses a Boston Consulting Group (BCG) matrix. Both models offer a graphic visualisation of the balance of the portfolio, which is important for explaining decisions to, and involving, stakeholders.

The aggregated project plan is a powerful tool for visualising, working with, and balancing project portfolios. The idea is to place projects in the model based on project type and show the major product and process changes they entail. Usually, projects are entered as shapes, where the area of the shape indicates the size of the budget. This not only provides a graphic depiction of the portfolio, but also enables us to see how the organisation’s money is invested, and what proportion of investment is allocated to each project type. The following process is the starting point for coming up with a series of proposals for projects:

We can use our retail-chain example. The following six projects are included in the example and the first step in the process is to arrange them into different categories. The categories can be determined by the organisation itself, but below we will use four common categories.

The aggregated project plan uses four categories that combined cover all of the projects that are reasonable for an organisation to run. Categorisation is not an exact science, and a project can be assigned to more than one category. The four categories are research projects, product development, platform projects, and improvement projects.

Research Projects

Defining a research project is not easy, as it can relate to just about anything. However, unlike other projects, there is no requirement to deliver a particular product. A company can choose to start a research project to develop new technologies, such as 6G wireless technology, on which Ericsson and several other companies are working, or a faster algorithm for storing and retrieving data from Google’s cloud. Such projects provide the technology necessary to develop the products of the future as opposed to a clear product that can be sold. Furthermore, research projects fail (i.e. simply do not deliver what was intended) relatively often. Research normally involves high risk, so failed projects are to be expected.

Product Development

A product such as a new car model or an IT system is usually developed through a project. Product development projects are arguably the most common category of projects, and organisations normally run a large number of them. This category is characterised by a product or service focus: i.e., it will deliver a product that will generate revenue for the organisation in the future. In other words, there is a great focus on delivery, costs, and schedule.

Platform Projects

In order to develop new products, it is sometimes necessary to create new technology, a new platform to build on, or a platform that enables, for example, specific software. Projects such as developing Windows or iOS are platform projects, as they form the basis for numerous innovations. A platform project is usually characterised by large budgets and relatively flexible time frames. Platform projects are usually very important within an organisation: think about what the next version of Windows means for Microsoft, or 6G for Ericsson. This type of project must succeed and can cost almost whatever is needed. Other business-related examples could be a new website as a platform for communication.

Improvement

Existing products, like everything else, have a lifecycle, a time span during which they are of interest in the market and create revenue. Depending on the product, this time span will vary, and it is the company’s job to improve and expand existing products so that it can continue to make money from them. Improvements and changes to existing products can be anything from a face-lift of a car model, to new features in an app, or expanding a service portfolio. Projects of this kind are traditionally quite short and introduce a small number of changes/improvements incrementally.

In our retail-chain example, we can categorise the projects according to Table 8.5.

Table 8.5. Project categorisation, example.

The next step in the process is to place the projects in a diagram that helps us to visualise the portfolio. We analyse the projects and rank them based on the size of their impact on the processes, and the size of the product changes introduced. The size of the squares in our case indicates the size of the project budget. In Figure 8.8, it becomes clear that our main focus at present should be to improve what we have: we see self-scanning as a platform for the future, and home delivery as a way of establishing a new market, from which we expect future revenue.

When faced with the choice of whether to undertake new projects, we can place them in the model below to produce a scenario on which to base our decisions. This is not an exact science, and should instead be seen as a form of decision support that gives decision-makers a better overview and a powerful tool to support their individual decision-making processes. The important thing is that the process arouses reflection and discussion within the organisation. An organisation must decide where in Figure 8.8 it should be; should it focus on research or product development? This is primarily determined by the organisation’s goals and strategies, but also by the industry in which it operates.

An organisation within the retail trade should reasonably focus most heavily on developing new products and improving existing ones, and far less on research projects.

The BCG matrix and other two-by-two matrices are common in management and leadership studies and practice, and also in project portfolios. They aim to place projects in one of four fields in order to achieve a balance suited to the organisation’s industry. It is important to point out that the applications of such matrices can differ, because each organisation is unique, so it is not possible to provide a specific formula. However, BCG matrices relate to products, so it is important that we consider which product the project aims to improve or develop.

There are four fields in a traditional BCG matrix, and in our example, these are: (1) Problem Child, (2) Star, (3) Cash Cow, and (4) Dog. Most new products, such as an iPhone app or a specific car model, start out as ‘problem children’, in that it is always uncertain whether they will be successful. If the product creator is lucky, the problem child becomes a star thanks to its great development potential, and thus assumes a significant market share. One example of this is the Angry Birds game, which was a great success (and the fifty-second attempt by its creator company, Rovio, to produce a hugely successful game). After a while on the market, development potential decreases (but market share remains stable), and a product becomes a ‘cash cow’. The company now makes big money from the product, but it has reached its peak, and from now on its market share will steadily decline and it will eventually become a ‘dog’, i.e., a product that is considered old and outdated.

There are many applications for the information we might glean from a BCG matrix, but from a portfolio perspective, its focus is creating projects that generate new products that will become stars of the future, updating and renewing existing products so that they can resume star status, and retiring products that have become too old and not profitable enough. The strength of any matrix lies in the graphic image that serves as a clear basis for making decisions from the outside, and that should provoke discussion in the organisation, thus leading to better decisions. If we apply the BCG matrix to the retail chain example, the process begins by first linking the organisation’s projects to the products that they are striving either to develop or to improve. For example, a project for handling receipts is proposing a completely new product and would therefore be categorised as a problem child, as we do not know whether it will be positively received by customers.

It is an established fact that IT initiatives are important for supporting an organisation’s business, and are central to evaluating any project. The question is to what extent the proposed project aligns with IT strategies and, by extension, business strategies. Projects that do not support these strategies should never be given a green light, and projects that no longer support those strategies (i.e., because strategies have changed) should be discontinued. Over the years, a number of different models have been presented regarding the implementation of strategic alignment. The most elaborate and established is the strategic alignment model by Henderson and Venkatraman (1999), which model focuses on the link between business strategies and IT strategies from four perspectives:

1. Strategy execution. This perspective emphasises that business strategies not only drive design choices, but also IT infrastructure and the decisions around it. Business management sets the strategies and IT management implements them. In this way, there is a clear link between strategy decisions and IT decisions, as well as the design and infrastructure they use.
2. Technical potential. This perspective regards IT strategies as the basis of infrastructure and technical decisions at more junior levels within the organisation. Senior managers should thus set an organisation’s visions for technology and technology investment, and the IT staff are the architects who implement them. In this way, the vision is firmly linked to the business benefit, as it is developed at a higher level where individuals have a better overview of the business, and who leave implementation to the IT department.
3. Competitive potential. This perspective focuses on how IT affects strategies and goals. Not only does IT help achieve such goals, but it also creates opportunities for new strategies and the development of existing ones. This perspective is important for exploiting the opportunities that IT creates.
4. Service level. From this perspective, it is necessary that the IT department functions well and is structured satisfactorily. It is the role of management to prioritise and help with the allocation of limited resources. It is important, however, that this process is not conducted solely from a technical perspective but includes, for example, licences, investments, and project start-ups. The IT manager’s role is to guide the group towards set business goals according to certain business priorities.

What is most striking about the above model is the close collaboration between the IT manager and senior managers. IT highlights the importance of active leadership at the highest level, and must support the business and its goals, which is only ensured through mutual cooperation. Another aspect that cannot be ignored is the fact that today there are many organisations that do not have their own IT department or internal IT skills. It is also reasonable to believe that the number of such organisations will increase, as more and more IT functions can now be purchased in cloud solutions. If so, it is important, as we highlight elsewhere in this book, that business managers shoulder their responsibility and drive IT issues as a central aspect of doing business. This requires insight on digitisation, either from within the business management team, or via external expertise consulted to support strategic dialogues.

All organisations have the capacity and opportunity to invest in new ideas. Capacity is usually equated with resources, such as money, personnel, or machines. Resources are ultimately limited in all organisations, because no organisation has an infinite supply of money or staff, so these must be balanced, and require thoughtful decision-making. Deciding how best to use resources is not easy; it requires assumptions and, in some cases, even guesswork. Employees and their time often create bottlenecks in projects, so we will focus below on efficient use of time as a resource.

An important starting point is to define what time means to an employee, and how much time an employee has in an organisation. The simple answer is that most people work about forty hours per week; however, part of that time will be spent on internal meetings and administration, so this is not all at the project manager’s disposal. Consultancy companies usually expect their consultants to work for around 85-90% of their time on billable activities. From a project portfolio perspective, it is unreasonable to expect that an employee will spend 100% of their time working productively. Of course, it is desirable to minimise the time that cannot be used for a project, but there will always be start-up and switchover time, or time spent on coordination that may not feel like “getting the project done”, etc. There is also a tendency to underestimate this “non-productive” share of total working hours.

The most important way to manage an employee’s time effectively is not to spread it thinly across too many different activities. An employee working on several projects or often engaged in other activities will be less efficient and more stressed. In essence, this is because they will spend time switching between activities, thereby reducing effective working time. One must also consider the relationship between the employee’s competence and the task they are working on. The gaming industry uses the term “flow”. If a game challenges us at just the right level, i.e., it is not so difficult that we do not progress in it, and not so easy that it becomes boring, then it has “flow”. The concept of “flow” is relevant to this discussion because an employee’s skills must be at the right level for, or at a level slightly below, what is required by a certain task. When competence is harnessed most effectively and an employee feels motivated, this will easily prompt efficiency of time and energy. The third and final variable is the working group, which, if it functions well, provides an employee with support and help, which increase motivation and improve team performance. It is important that team members complement each other, through similar levels of competence in different areas, and through a sense of collective responsibility.

To summarise, effective use of time is about ensuring that an employee can focus on several tasks at once, and that the challenge presented should be well-matched to a particular employee’s competence.

Evaluating how well projects are carried out is not easy, but it nonetheless requires thought. This section will introduce and discuss a number of issues surrounding project implementation, before indicating a number of approaches to project portfolios.

There are two basic phases of project evaluation: during project implementation, and after completion. Both are important, although they have different goals.

Evaluation of a project after its completion places the emphasis on organisational learning, by giving the organisation an opportunity to decide what did and did not work, so that working methods and routines can be changed to improve future projects. Unfortunately, many organisations act regard such evaluation as wasted, unproductive time. This is a major mistake, as organisational learning and development are vital parts of successful project execution. Whilst there may be organisational guidelines to evaluate and draw lessons from completed projects, such activities tend to be poorly prioritised. In agile approaches, recurring retrospectives—reflection time allotted at intervals during a project—are one way of narrowing the gap between the idea and the practice of evaluating projects.

Evaluating a project during its implementation means finding and solving problems, and steering the project towards an end goal, or in our case deciding how a portfolio should be adapted in order to be “effective”. Basically, both types of evaluation seek to create a basis for decisions, in order to change a way of working, or the way a project or project portfolio is run, and they should be seen in this light.

The most common way to follow up on a project is to use key performance indicators (KPI). They measure different aspects of the projects in a portfolio as well as the portfolio itself, and assign them a value or rating. The value, or grade, is then used by the project or portfolio manager as a basis for making decisions. Common KPIs include the proportion of time spent on project activities, the amount spent versus the forecasted budget, or the actual number of activities completed compared to the projected number. There are many other KPIs, but they all have one thing in common: they require accurate information to work. KPIs are clustered to answer questions about how a project, such as keeping to budget, is progressing. However, there are a number of problems with them that should be highlighted. They usually require quantification of what is to be measured, that is, aspects of a project must be translated into numbers that can then be analysed. This is not always so easy, because project progress often depends on nebulous factors such as customer relationships and employee motivation, which are difficult to quantify.

KPIs also define what is measured and how. This often leads to measuring what is visible (or identifiable) and easy to measure, and omitting aspects that are complicated or that have not arisen, which in turn can generate a misleading perspective on a project. Organisations also tend to focus on financial variables, as these are easily accessible and measurable, but they may not always be as rewarding or enlightening from a project perspective.

The follow-up process attempts to gain a fuller picture of a portfolio. Although KPIs provide many answers, they do not create a full image, because they focus too much on details. They raise the question of how one ever knows that one has a correct and complete picture of a portfolio. If, for instance, we use ten KPIs to evaluate a project (in reality there are usually more) in a portfolio, it will unfortunately be impossible to tell whether that number is sufficient for us to have a reliable decision-making basis. We must therefore simply guess that the number of KPIs we choose is sufficient, and this is not the most appropriate way of dealing with uncertainty.

Once a project is completed, it is important to follow up on and evaluate it. This results primarily in organisational learning and allows us to benefit from experiences, good and bad, gained during the project’s implementation. There are certain questions that should be answered, such as: (1) How well did our assumptions and plans match up with reality? (2) How realistic were the time estimates? (3) How well did our methods work, and what can we do better in future? There are, of course, many more questions that could be posed, but time constraints and resources usually limit the selection along these lines. Exactly how a follow-up, or post-mortem as it is often called, works depends on how the organisation works, the kind of information that is required, and so on. What is important is not how it is done, but that it is implemented and its results provide useful lessons.

Project portfolios are basically a collection of guesses and bets about the future, but in practical terms they are a collection of projects that need to be managed in order to avoid conflicts, failures or mis-investments. How this is done depends largely on how an organisation views its projects and works with strategies.

This chapter has offered a range of ways of working, and has flagged the most important areas. We began by considering how certain projects are selected, and what such decisions are based on. We have highlighted the challenges in quantifying the benefits of IT projects, and have examined both the qualitative and quantitative models for doing so. The chapter then described two ways of visualising a project portfolio: the aggregated project plan and the BCG matrix. These models can easily produce a visual image of a portfolio. We then briefly presented a model for strategic alignment. The important thing to understand here is that an organisation’s goals, strategies, and business models are constantly changing, and that it is therefore of utmost importance that ongoing project evaluation supports its current goals and strategies, and that action is taken if they do not. We ended the chapter with a discussion of resources and follow-up as vital parts of portfolio work.

The information we obtain from the models and the working methods can only provide help and support, not firm directives. It is almost impossible to create processes and systems in an organisation that give unequivocal answers about which projects we should start, which we should end, and which we should invest in. All of this depends on the wider context in which the organisation is situated and the current events affecting it.

Below are a number of articles and books that provide more information about certain topics covered in this chapter.