9. Managing Projects

There are many project models (some of which are used more than others), such as the waterfall model, PROPS, Scrum, and Kanban. As noted above, they can be divided into two main categories: sequential and iterative. Below, we will review the models according to categorisation, and describe the different steps involved in each. It is important to highlight that hybrids and other types of mixed models may well exist, but our focus here will be on the simple, delineated models.

Sequential models have a long tradition and have evolved from a need for structure and control. The best-known sequential model is the waterfall model, introduced in the 1970s by Winston W. Royce. The model is based on a sequence of activities, each of which produces information required for the next step. The process is intended to be carried out sequentially, thus ensuring a well-functioning, tried and tested system by the end. The waterfall model is characterised by rigorous control via documents and other deliveries, which was more necessary during the 1970s and 1980s when IT activities were largely run by technicians and were frequently disorderly, or at least not customer-focused.

The first step (which is not really part of the project) is a feasibility study. This investigates whether there are enough resources, knowledge, time, and so on to carry out the project in a reasonable manner, within the budget and time frame that the customer has requested. If the answer is yes, the project continues, and if the answer is no, then it ends.

In this step, the system is built, according to the design document. Here, traditional system development processes take over and programmers, for example, create the system. Most of the work (in time) in the project takes place during this step.

A company’s IT systems must be integrated or interconnected. It is common to use an external system to manage logins, so that users do not need multiple passwords (single-sign-on). Data used by many sub-systems need to be shared, rather than duplicated, and so on. Integration is often one of the most difficult tasks in an IT project and it is usually the most competent technical staff who work on it.

When the system is fully integrated, testing starts. In this step, the functionality of the system is tested so as to iron out errors, both visible and hidden. Testing is a major aspect of IT and is often complex and difficult to implement properly.

After the system has been implemented and tested, it is time to hand it over to the customer or to deploy it in the organisation, and put it into production. This is often a relatively complicated process that requires extensive collaboration with the customer and knowledge of many areas within IT.

The waterfall model is still the central and most widely used model in many industries. However, we see major changes in, for example, how to produce goods and the length of projects, that have gradually caused the waterfall model to lose ground. The waterfall model was created when IT projects were large, required structure, had low-to-medium complexity, and it was still possible to set firm goals. Today, the world looks rather different and these conditions are not necessarily a given. IT is complex and a project’s goal or functionality will typically be revised repeatedly during the project timeline. On the one hand, this is because it is difficult to define exact functions and there is a learning curve in any project; the customer simply becomes more skilled and more informed and, during the project, builds up their own and the organisation’s knowledge of IT and IT systems. On the other hand, external and internal conditions can change, meaning that further IT support is required to keep the organisation operating effectively. The customer and the project now require greater interaction and visibility, and waterfall models suffer because the product development is invisible to the customer. It is only late in the process that the customer has the opportunity to test the system, and at that point they can have minimal influence on the end result. This lack of prolonged customer impact contrasts with the customer’s need to be able to change and correct the target image and requirements during the project.

Another aspect of product visibility is that we are now also looking for more innovative ways to deliver IT systems or programs. This is especially evident with apps and games, which can be delivered to the customer in different forms. It is possible, for example, to buy a basic version of a game/app and then add features as you go. Agile methods allow innovative delivery, where a product can be accessed in increments. Unlike in the waterfall model, it is central and part of the working method to involve the customer during the project (as opposed to just at the start and the end), in order to deliver a flexible end product. The waterfall model also focuses on functionality, and the aim of the project is to ensure that all requested functions are available. This is a view that does not reflect current discussions about how in order to realise the benefits of a project, IT must deliver business value to motivate investments. Instead, flexibility and the gradual development of understanding of needs and possible solutions form the basis and primary focus of agile methods.

Iterative models (or agile models) are considered by many to be the next step in project management development, and in this sense represent ‘the new’. Basically, iterative models are exactly what they sound like; work is done in stages and the plan, work, assess cycle is repeated over and over again. Some would trace the origins of iterative models or agile methods, as they are normally called, to the creation of Lean (coined in 1988 by John Krafcik), a cool for car production that has gradually evolved into a tool for realising value in all manner of projects. However, this change actually began even earlier because prototypes and iterative development have been concepts in the IT industry since at least the 1980s. The starting point for agile methods includes the business value, the benefit of activities and efforts to cut out “unnecessary work” or, in other words, work that does not create value, and to try to reprioritise those activities that at present seem most fruitful.

Agile methods were born out of a need to handle change in projects more smoothly. Recurring priority discussions between the “customer”—the client or project owner in whose business the project result is to be used—and the executors, who build the solutions, are central. Agile thinking is a popular solution to the challenge of managing difficult-to-understand initiatives, where the customer gradually learns more about their needs and how an IT solution can help to satisfy them, and where the developer gradually learns more about the customer’s needs and operations, and about how technical solutions can be developed.

The agile manifesto was presented in 2001 and forms the basis of the agile method. It presents the philosophical ideas behind agile thinking, and how to look at work and projects. The manifesto presents four theses: individuals and interactions versus processes and tools; working software versus comprehensive documentation; customer collaboration versus contract negotiations; and responding to change versus following the plan. These theses, or approaches, form the basis of the agile movement and its methods.

Individuals and Interactions versus Processes and Tools

In agile methods, the focus is on the individual and their competence, and projects rely on a group being able to self-organise through communication between members to solve problems and undefined processes and tools. For this to work, a well-functioning team who trust each other and allow open communication, is necessary. The team members must also be competent in their respective areas and constantly strive to improve and develop themselves. It is important that they take responsibility for the group and for the work they have undertaken, and it is important that all members understand this and take it seriously. There has been some criticism of agile methods because self-organisation is regarded as difficult in practice. It requires all members to take on considerable responsibility and teams to be very tight-knit, which can be difficult as most companies have a resource pool that cannot change from project to project.

Functioning Software versus Comprehensive Documentation

It is important that the team builds, experiments, and works closely towards a solution, using prototypes instead of spending time on documenting. Evolutionary work with prototypes and modularised solutions is central to all agile models. Documentation is not productive, whereas designing and coding are. This does not mean, however, that there should be no documentation, but rather that one should document thoughtfully and effectively. Agile methods do not advocate long reports on functionality or changes.

Customer Collaboration versus Contract Negotiations

The customer is seen as a natural and important part of the project, and is expected to participate and make important decisions as it develops. Agile methods are based on a partnership rather than a strict customer-supplier relationship. This means that we should move away from the concept of “the customer”, because in a sense there is no customer separate from the project in the agile world, since everyone works together on the project, preferably with the same target goal.

Responding to Change versus Following the Plan

The ability to respond to a customer’s desire for change and the resulting learning curve are more important than following a predefined plan. Handling change smoothly is a basic principle in agile methods; we know that things will change and that the specifications may be proven wrong, and this should impact our approach. In the agile world, we start with what we know, which is documented and regarded as a living requirement specification. Everything that the project adds or changes along the way is a natural part of the work. This is described in more detail in the example of Scrum below.

Scrum is the agile project method most widely used in the IT industry today. Methods always need to be adapted to the situation, and this applies no less to Scrum. Its name is a reference to rugby, and the cluster that starts the game. It is no coincidence that this word was chosen, as the success of Scrum, like that of many other agile models, depends on how well the project team works together, and requires them to work in tight-knit groups to inform each other and solve problems.

The process represented by Scrum is led by a Scrum Master who is equivalent to a project manager. The concept of project manager does not exist in scrums; the teams are self-organising, and the Scrum Master is responsible for several administrative tasks, problem-solving, and managing external communication.

The overall workflow in Scrum is similar to that in many other project methods, including the waterfall model, in that it is about implementing functionality and creating a product. What should be implemented is documented in a backlog. This backlog is then changed as tasks are completed and shipped, or as new information renders older backlog entries irrelevant, inefficient or otherwise undesirable, i.e., if the old entries do not promise to deliver enough value in the updated backlog context.

Step 1: Build the First Version of a Product Backlog

Since it is assumed that requirements cannot all be known from the beginning, this first step is about documenting requirements. This documentation can be achieved in different ways, such as through text, story or pictures. It is important that a product backlog is seen as a living list which, with the customer, is updated as changes arise, or new requirements are added. This can be done using the same approaches as for the waterfall method.

Table 9.1. Example of a backlog.

Step 2. Decide What to Implement in the Next Sprint

The next step is to define what needs to be done during the next sprint, or which requirements to implement. According to Scrum, it is the customer who at this stage prioritises and decides what is done, on the advice of those who are technologically savvy, so as not to create problems with the sequencing of activities, and so that the task list is based on realistic time estimates. Once several functions have been selected, they must be refined, detailed, and explained, so that, for example, a developer can start programming the function once the sprint begins. Work time is estimated, and this determines how many functions can be accommodated during the two to four weeks of the sprint. The result of this sprint planning is what is usually called a sprint log, and the associated necessary technical descriptions. The sprint log contains a subset of what is to be implemented in the backlog.

Step 3. Development/Sprint

Work is now done on the function or other tasks that have been chosen for the sprint. The method is not set in stone, and even the waterfall model is possible. The most common approach is to split the work as a group and to then work individually with the support of other members. Each morning a fifteen-minute Scrum meeting is held, where the group members organise themselves by dividing the work and coordinating in a way that suits them. Each member of the team should ask: What did I do yesterday? What do I intend to do today? What can stop me from accomplishing what I set out to do today (so that I may request assistance)?

Step 4. Possible Delivery-ready Product

After every sprint, it is important that there is a sub-product that could theoretically be delivered to the customer; all the results of a sprint must be deliverable. This means that it must have been tested and integrated with previous deliveries. If it is possible that a function will not be completed within the specified sprint time, then the data will be returned to the reverse log and may be included in a later sprint.

Step 5. Show to the Customer

The penultimate step is to show the work to the customer. This allows for discussion of what has been done, and gives the customer the opportunity to test the prototype, provide feedback, suggest changes, and so on. Any additional changes made during this preview are added to the product backlog, to be sprinted at a later date.

Step 6. Sprint Overview

The final step is to evaluate the sprint: How did it work? What was good? What was bad? Is there anything about the working method that should be changed before the next sprint? This is an important step as it enables work changes, such as how time is spent. It is an essential part of Scrum to question and improve the model, to learn from previous sprints, and to improve the work process.

We have previously discussed problems with the waterfall method, and agile methods equally have problems that should be noted. The first challenge is how well they really suit the way the market does business. In internal projects, this is not a problem, as the entire chain from financier to implementation can be controlled, but it is more problematic in a customer-supplier situation. Much of the business that is done within IT is about fixed price agreements, where a supplier takes on an assignment for delivery at a fixed price that is negotiated before the project starts. This way of working is the opposite of agile methods, where those involved have to be able to work more like partners with a current account. In reality, they do not know what the final price of the project will be, which makes the business relationship complex.

The second challenge is that agile methods require a team with the ability to self-organise without the involvement of an official project manager. This usually does not work completely smoothly. If the team is not experienced, coordination is required and the team will need support to self-organise. In larger projects, coordination between teams also becomes a challenge. The scrum masters must therefore meet in scrums (of scrums) in order to handle cross-team coordination. With six or seven people in a team, a third level of coordination will be needed. The larger the project, the more complicated cross-team coordination becomes.

The fact that the customer controls much of the work is the third challenge for the agile method. An ability to prioritise and drive the work forward requires relatively good knowledge of IT and systems development, which a customer normally does not have. In this case, one must guide the customer and converse with them in order to decide on sensible priorities. Also, sometimes customers may not be prepared to be as involved in the project as the method requires. In that case, someone on the developer side will have to act as the customer, thus introducing the risk that customer needs and priorities are not really understood or incorporated into the project.

9.2.4.1. Real-life Examples

Which method to use and when will largely depend on the type of project and what kind of relationship the customer wants. Agile methods require the customer to actively participate in the project, and if the customer does not wish to do so, then it is safer to choose a more sequential model. In general, however, it can be said that the more uncertainty there is in a project, the more suitable an agile method will be. Conversely, the greater the stability, goal clarity, task familiarity, and size of a project, the more appropriate the waterfall method.

As noted, there are problems with both models, and nothing says that the waterfall model cannot be effective and deliver good results. Below are some examples of project types that fit each method.

9.2.5.1. Waterfall Model

• Fixed-price projects with a clear target.
• Short projects in which the limited time does not allow for changes.
• Projects whose goals are well-defined and relatively simple.
• Large projects whose tasks and solutions are familiar and possible to plan.

9.2.5.2. Agile Method

• Development of, for example, an app that you want to be able to deliver step by step.
• Unclear projects where the goal is not well-defined or clearly feasible.
• Complex projects in which changes are likely to occur.

This is a list of examples, as opposed to hard recommendations. In a given project, it is almost always possible to devise a way of using either method, or a combination of the two.

Regardless of the method(s) used, there are a number of basic skills that a project manager should possess. Of course, needs vary between organisations and the tools and methods below should be seen as examples and suggestions of how to meet them.

A feasibility study normally consists of five parts, each of which analyses a specific area of the project. It is important to point out here that these analyses cannot be made separately, because they will influence each other, so the feasibility study should be conducted as a whole. The five parts are: assessment of technology, economic aspects, legal aspects, operational considerations, and time schedule.

9.3.1.1. Technology

This part of the feasibility study is normally carried out by technically knowledgeable people who use an overall design to evaluate whether it is technically feasible to carry out the project. They also consider the technical solutions available and focus on ensuring that appropriate technology is used. It is important to ensure that there are technologies to solve the problem, and that it is possible to spend time changing an existing technology or developing new ones. Normally, there is no time to conduct research in a software or IT project.

9.3.1.2. Economy

Here we evaluate whether the proposed budget is adequate to implement the project. Another aspect evaluated is the question of whether or not the project will pay off, and usually a cost-benefit or business case analysis is carried out to ensure that the project will generate a profit, or other forms of benefits that might justify its resource consumption.

9.3.1.3. Legal Aspects

As more and more projects use open data or store information that may be considered sensitive, it is important to consider whether legal restrictions affect what data can be used, how it can be stored and handled, and how this affects the final product. Such analysis is normally conducted by lawyers with knowledge of IT-related issues.

9.3.1.4. Operational Considerations

This part focuses on the operationalisation of the proposed system or process. The focus is on how the intended change is to be introduced into the organisation. The underlying issue addressed is how to ensure that the IT system is accepted and utilised in the organisation and interacts well with organisational processes and practices. If we do not plan for implementation, the likelihood of resistance from future users is high, so there should be an analysis of what can be done to make the introduction as simple and painless as possible. This is about ensuring that you help the customer or recipient of the project to realise its benefits. One complicating factor is that project managers usually carry out one systems development project before moving on to the next one, and therefore in reality have very little opportunity to work to ensure that the desired benefits of a project are actually realised.

9.3.1.5. Timetable

Can the project be completed within the given time frame? This part is exclusively about ensuring that the time allocated to the project is sufficient to carry it out and that its individual stages are sensibly arranged.

Requirement management, or the process of understanding and defining a requirement, is relatively complex and consists of specification, analysis, and documentation. It often forms part of the pre-study work, but may well be a separate process that is carried out after a pre-study. There are many methods and processes for requirements management. Basically, requirements management consists of three aspects that are based on each other and when combined create a well-defined requirement. These are:

• Requirement definition. This is a requirement that is expressed in natural language, such as Swedish (rather than formal, artificial modelling language). This is primarily aimed at the customer as a way of creating an understanding of the project.
• Requirement specification. This is a structured description with all project requirements, which forms the basis for a contract between the customer and the supplier.
• Software specification. This is a technically detailed description of the requirements for the developers who will implement them. This can be created with the help of tools like UML (Unified Modeling Language).

If we put these together, we get the final requirements specification, which forms the basis for the continuation of the project. It should also include the relationships between the requirements and the external environment. There are many methods for obtaining requirements from the customer or the users, ranging from interviews to the analysis of systems specifications that customers have developed. More concrete examples of methods that can be used to obtain requirements are brainstorming, conceptual or process modelling, and working with prototypes. These different methods have their own strengths and weaknesses, and depending on the situation and type of system the customer is planning to build, different ones will be appropriate. Brainstorming is a convenient way to get started, or to find new ways to look at a problem. Modelling is most often used to analyse processes, and to determine how to improve them, or to chart what information the project should help in handling, and which conceptual data structures are needed to capture that information. Prototypes involve visualising something that can be complex, to test the usefulness of a certain functionality or to provide experience of potential user interfaces.

There are thus many methods with which to create a clear overview of requirements. It is important that the project manager understands the difference between each and chooses carefully, as it can be costly to choose the wrong one. The point is to find a mix of requirement management methods that works, and to deliver a result at the lowest possible cost. It is also important to understand that requirement management is a generic kind of knowledge used in both agile and sequential methods. The difference depends on when it is done and how many of the requirements are handled; agile methods focus on what is to be implemented in the immediate next step, while sequential methods identify all requirements of all steps before the project can start.

It is difficult to make predictions, especially about the future.

Karl Kristian Steincke, Danish politician

Estimating time frames is undoubtedly one of the most difficult activities in a project, but it is of utmost importance that these are as correct as possible when planning a project as, for example, cost (and often price) directly corresponds to hours spent on a given activity. There are a number of methods for estimating time, but in essence, it is about using past experience and/or statistics to estimate how long an activity takes. Estimates can, however, be more or less elaborate. What has never been done or experienced cannot be estimated, and then it is better to accept the help of experts who may have additional insights.

Before considering methods for estimating time, it is important to note that the planning horizon has a major impact on the quality of any estimate. The more distant the future of an activity, the greater the margin of error, and vice versa. This will have a greater impact on sequential methods, which require us to estimate the entire project and all of its stages before it has started, unlike iterative projects, where only the activities closest to us in time are considered.

Take a moment to imagine that you are expected to estimate how long it will take to do something that will happen in eight months’ time. Now do the same for something you will do tomorrow or next week. Which is easiest? It is nonetheless important to understand that we must actively work on estimations throughout a project, and adjust them according to what we learn from tasks we have already completed. For example, if our estimates are constantly 10% too high, then we can probably correct our estimates for all upcoming tasks by reducing them by 10%.

Below we will discuss some methods for estimating time frames: work breakdown, historical data, and experts.

Work breakdown structure (WBS) is a common tool used in a variety of applications, and, in addition to time estimation, helps us to understand the activities that are part of a project and its scope. There are numerous variants of WBS, such as product breakdown structure (PBS), which is often used in agile projects, because it focuses on products and regards functions in IT systems as products, in line with the agile view of business value.

9.3.3.1. Historical Data

Using historical data for estimation is a reliable method, when possible, since it offers facts: the end result, or how long a past project actually took. The most common way to work with historical data is to look at similar projects that the organisation or others have undertaken, see how long they took and use this as an estimate or as the basis of an estimate. For this to work, it is important that the organisation works actively to finish projects to a good standard, that employees learn from what they have done in the past and, above all, document the projects in a way that allows them to reuse the information. It is important to point out, however, that the tasks must actually be the same, that the project context is similar, and so on, otherwise there is a risk that the estimates will be incorrect because the projects are too different.

9.3.3.2. Experts

Seeking help from people inside and outside the organisation is a common and well-tried approach to estimation. All organisations have experts in different areas, and the underlying assumption is that if someone is good at something, like programming, they are more likely to be able to estimate how long an activity within their field of competence will take. The Delphi method asks a number of experts to individually estimate how long activities will take. The results are collected and a group discussion with the experts then follows, giving an opportunity to review, compare, and discuss the individual estimates before reaching a final estimate. This approach can provide well-founded estimates, but takes a long time and is costly, so care is needed in applying it.

To mitigate a risk is to prepare for unfortunate outcomes or to ensure that they do not occur, or at least that their probability of occurring is very small. There are basically four ways to counteract risks: avoid, share, reduce, and transfer.

• Avoiding risks is usually about evaluating and selecting other solutions or making other choices to find less risky alternatives. One common way of doing this is to choose proven working methods and technical solutions instead of untested ones.
• Sharing a risk means, for example, choosing to work with another organisation meaning that each organisation is only exposed to a portion of the risk.
• Reducing a risk means acting so that the risk becomes smaller, for example, by hiring an external expert to go through the project or by placing staff members with the greatest experience in time-critical activities on a project.
• Finally, the risk can be transferred to someone else. An obvious example is if one insures against a risk through an insurance company.

We can look more closely at the simple example of project delay above. Suppose that the anticipated delay depends on a lack of internal competence, which can result in a delayed delivery to the customer. The analysis can now be expanded and clarified through trees, which makes it possible to specify sequential events. We therefore continue to assume that the delay can have different effects in terms of market share.

After a more detailed analysis, we find that if the project is delayed for more than six months, the supplier has more than a 50% probability of losing the entire market as a result. This is a catastrophic scenario, which we estimate as having a value of 0. However, even less catastrophic scenarios involve substantial losses (value: 0.2–0.3).

If the delay is instead between three and six months, the supplier has a probability of over 75% of losing a very important customer (value: 0.2–0.3), but with a little luck (less than 25% probability), everything will go well (value: 1.0).

If the project is delayed by between one and three months, the supplier has a less than 30% probability of losing the customer (value: 0.2–0.3). Of course, if there is no delay, nothing will happen (value: 1.0). The event tree in Figure 9.4 shows the aggregate risks.

The company can now decide, in order to mitigate the risk of delay, to recruit a smaller or larger group of technicians, for example. The effect of recruiting a larger group means that there is more than a 90% probability that there will be enough qualified personnel to implement the project on time, and a maximum 10% probability that the delay will be between one and three months. The risk of even later delivery is non-existent. At the same time, the costs increase so substantially that the company risks a 20–30% probability of bankruptcy. The supplier perceives this outcome as negatively as losing the entire market. In any event, the costs will be so significant that the value of a successful project will be significantly lower. The value of delivery in both cases thus decreases (by 0.2), as the costs of saving the project in this way are so large.

Recruiting a smaller group is cheaper and means that the bankruptcy risk is below 5%, but the probability that the project can be implemented in time then drops to 70–80%. The risk of a one-to-three-month delay is 10–20% and that for a three-to-six-month delay is less than 10%. The value of a successful project also decreases here, however (by 0.1), thanks to associated costs.

In Figure 9.6 we see how the alternatives perform in relation to each other, given the background information. The further up the bars they are, the better the options they represent. It can now be seen that the alternatives of either not recruiting at all, or recruiting a smaller group, are clearly much better than recruiting a larger one, based on the information available. The two better alternatives are rather similar, with no risk mitigation (Alternative 1) and a somewhat larger range of potential outcomes. Recruiting a smaller group (Alternative 3) appears to be slightly better, with a smaller range and a somewhat higher mean expected value.

9.3.4.3. Create and Establish a Follow-up Process

The last task in the risk analysis process is to establish a system for continuous monitoring during the project. We will discuss this in more detail in the next section. Monitoring the project is part of the project manager’s responsibility. The work process runs throughout the project and helps the project manager to correct plans and current approaches. In its most basic form, the work process looks like this:

Figure 9.7 shows a traditional work process for monitoring and controlling projects. It is a loop with a plan for what is to be done, monitored via, for example, KPIs and correct plans and behaviours. The most interesting areas to monitor/follow up on depend on the context and the type of project. In general, however, four areas of interest can be noted: (1) risks, (2) budget, (3) resources, and (4) goal fulfilment. Information is required to be able to monitor them and make decisions about which changes should be implemented. How information is collected is not important in itself. The important thing is to understand the composition, which will be a mix of quantitative and qualitative data and more free-format sources, such as reports, from project members and the project manager. The monitoring process is about setting up an information flow, getting members to report on how their work is progressing, the rate at which money is spent in relation to goal fulfilment, and so on. The major challenge in monitoring a project is to find a balance between information needs and the opportunity and willingness of members and other participants in the project to deliver. It is all too easy to create a process requiring a large amount of data, with members spending hours reporting the status of various activities, which is not cost-effective, and will eventually become tiring. The basic rule is to automate as much information collection as possible. For example, financial data can be retrieved from the financial system; a consultant’s billable hours can probably be found in the time-reporting system used by almost all consulting companies; and so on. It is important that the project manager explains, and points out to participants right from the start, the importance of reporting what they do, the status of activities, and so on, so that this becomes a natural part of the workday.

Exactly how the follow-up and control process in a particular organisation looks is not our main topic, and instead we focus on which questions require answers in the different areas of risk, budget, resources and goal fulfilment.

Risks

• Have probabilities and effects changed compared to the plan?
• Have new risks arisen and old ones disappeared?
• Are risks handled correctly?
• Have new risks arisen that need to be dealt with?

Budget

• How much money has been spent compared with the plan?
• How does the requested change affect the plan?
• Are the cost estimates correct?
• What corrections need to be made?

Resources

• To what extent are the resources used?
• Are the resources used for the right things?
• Have the right staff been allocated to the right tasks?

Goal Completion

• Do activities end on time?
• Are the time estimates correct?
• Do planning and working methods work?
• Do forecasts need to be updated?

There are, of course, more questions to answer. Questions must be tailored to the specific situation and the above questions should therefore be seen merely as examples of basic questions. The questions and answers mean that plans must constantly be updated to reflect the changes and decisions being made.

In this chapter, we have discussed how projects can be managed and implemented. Projects are a key route for an organisation to realise benefits and value offerings, since they involve activities that bring the organisation closer to its goals and ultimately realise its vision.

We have looked more deeply into two areas: project portfolios and individual projects. Project portfolios are simply about making sure that money is invested, and that other resources are spent on the activities and projects that bring an organisation closer to its goals. If project portfolios focus on the holistic, then projects are more specific, and focus on a specific investment.

We posed and answered questions such as how projects are selected and resources used, in order to ensure that the right course of action according to the goals set is taken.

Project management is difficult and requires a number of skills and the ability to change roles frequently, for instance between leading and marketing a project without much preparation time. It is important to remember that all projects involve risk and the project manager has a great responsibility to manage them properly. We have discussed a number of risk management approaches, from fairly simple to more complex multi-criteria analyses.

The purpose of this chapter was not to give a comprehensive overview of projects and portfolios (there are entire books on these topics), but to situate the project in the context of its benefit, and how this benefit is realised.

What a project manager chooses to do, or how they choose to manage a portfolio, is ultimately up to them and their organisation. Here we have indicated a number of areas that are important to consider, and suggested a number of ways of working. How you proceed with and apply them is your choice!

We are now starting to approach the end of the book, but before wrapping up, we will look at digital transformation in higher education, and in doing so, move towards a global perspective.