There are 5 types of project stakeholder:

1. Individuals and groups performing the work
2. Individuals and groups affected by the work
3. Owners and shareholders
4. Customers
5. Statutory and regulatory bodies

1. The project team doing the work are key stakeholders in the project. They have to understand why the project is essential and why they should commit to the project delivery. Without this they are unlikely to be motivated to deliver the project. It’s essential that the project manager communicates the overall vision for the project.
2. People affected by the project are critical to the project success. For example, if the users are not happy then it is unlikely that the project will reap the intended business benefits. As you will learn when studying for the APM Project Professional Qualification (PPQ), understanding how the project will impact those affected is a key part of the success of the project. For example, a developer may want to discuss the impact of a development on the local schools.
3. Owners will want a return on the investment in the project, so they have a vital role in the critical investment decisions. They may not be the sponsor but will have the ultimate say on how the project proceeds. Communication and keeping the owners on-side is essential to any project. This will be especially true at gate decision points.
4. Ultimately, customers will influence the overall success of the project. If the customers are not happy with the outcome then they are unlikely to use the facility and will take their custom elsewhere. For example, if a customer doesn’t like a new airport, then they are highly likely to decide they want to fly from a different airport. In this case, it’s imperative to make sure we fully understand the customer needs.
5. Statutory bodies and regulators will set the legal standards against which the project has to be delivered. For example, they may set planning of environmental protection constraints. Because they are statutory rules, then these must be understood and followed by the project team.

We first need to understand what a risk is and the difference between a risk and an issue.

A risk is an event that may occur and will have an impact on the project objectives. An issue is something that is likely to cause the project to go outside tolerance and needs to be escalated to the next level. In practice, risks require a comprehensive assessment of the potential impact and tend to be in the future, and so project professionals have time to prepare risk reduction measures to control the impact on the project. This often requires a scenario assessment predicting likely outcomes if the risk was to occur. Issues, on the other hand, tend to be much more certain and immediate, affecting the day-to-day tasks of delivering projects. Issues also need to be significant and require escalation. A small problem that the project manager can deal with is not an issue. A problem such as the realisation that the benefits are no longer viable is an issue and will need to be escalated to the next level of management.

4 methods of identifying risk are:

1. Brainstorming
2. Prompt lists
3. Checklists
4. Delphi

1. Brainstorming is a technique which involves bringing the team together to generate a large number of risks quickly in a creative way. Ideally, a brainstorming session has three phases. First, a briefing by a neutral facilitator to set the scene and communicate effectively the objectives. Second, generation of lots of ideas, sometimes by taking turns, building on the ideas of others and everyone contributing. Finally, a collation phase where key ideas are pulled together into themes, duplicates removed and themes summarised. From this final list, the facilitator should create a finalised list of risks for evaluation.
2. Prompt lists are structured areas to consider or headings for risks. These lists often form part of a project methodology. Typically, they might include technical, commercial, legal, resources and environmental. Within each area a team can then brainstorm the likely risks. It’s a useful technique to break down a workshop into subgroups with each team considering one area of the prompt list and then reporting back to the rest of the group. Compared to brainstorming, prompt lists offer structure and ensure that key areas are not neglected.
3. Checklists are predefined lists of risks. These are used to ‘tick off’ risks that apply to a project. These are very useful in areas of the project that are more like business-as-usual. For example, this could include volume house building or IT desktop installs in a big organisation where the project will perform the same operation many times. Checklists are a good way of capturing and sharing common risks. Again, they are often developed and deployed as part of a project framework or method and are maintained by the project office.
4. Delphi is a way of consulting experts. This is differentiated from brainstorming because the experts don’t meet. The facilitator consults them individually and then collates the answers in an iterative process. During this process, the experts comment on the collated results and the risks are updated based on feedback. The process continues until consensus is reached across all the experts. Needless to say, this is a very slow and laborious process. It is reserved for the most challenging and difficult projects.

1. People and organisation
2. Processes
3. Products
4. Templates and documentation
5. Tools

1. People and organisation

The project method or framework will have a standard way of referring to roles and responsibilities consistently across the organisation. Standard terms will be used such as project manager, project sponsor, product manager, etc. These will indicate a certain professional project management capability within the project profession.

Where standard public tools are used, such as PRINCE2, these terms will be adopted, but where there is an internal system those terms will be used. It is important that the terms are consistent across the organisation so that everyone in the organisation is clear as to what the role entails, the responsibilities and where they fit in the project structure. The roles and responsibilities are also important in assessing the capability of a person, and by being consistent across the organisation the person becomes transferable to different projects within the organisation assuming all the projects will conform to the project methodology.

2. Processes

Processes are those activities which are defined in the project methodology and are linked to the project life cycle. They are referred to and described in the project plan. They are used by project leaders to tell the stakeholders (via a written report or document) how things are going to be done and will align with organisational governance. For example, the process may say that a project cannot be approved for the delivery without a successful gate review at the end of the definition phase or will set out the control processes for things such as risk management, change control or reporting.

3. Products

Products are those things which are produced by professional projects and can be two types: a) those produced as part of running the project, i.e., the project plan or b) those produced as part of the project output which will need to fulfil success criteria for acceptance. The project methodology will define what products are to be produced and when. It is important to clarify the product requirements and communicate them to the project team.

4. Templates and documentation

Templates and documents may be produced as standard, or a list of those required will be included in the project method. The templates may act as a prompt for ideas or work where there are pre-entered information or titles – i.e., a risk assessment or risk matrix. The templates and standard documents are important for communicating the work done in a consistent way. They can be Word templates such as the project plan and business case, or Excel templates such as the risk register.

5. Tools

The project method may require the use of certain tools. These may be public, such as Microsoft Project, or proprietary internal tools developed by the teams to help them negotiate effectively with stakeholders, for example, or define technical requirements. The tools will improve continuity across projects as they will all be working with the same standard tools. This will help with reporting from a number of projects to the stakeholders, and will also enable resources to be moved around the organisation as the people will be familiar with the tools used.

The main purpose of a business case is to facilitate the investment decisions about the project. It summarises the costs, benefits and risks and enables the organisation to take a decision about whether to fund the project or not. This is important because it enables the organisation to take an informed decision based on realistic facts. In comparison to the project plan the business case needs to be more concise and written from a business perspective.

The components of a business case are:

1. Costs
2. Benefits
3. Risks
4. Timescales

Costs

The costs in the business case will inevitably be high level. This is because we have not yet completed the detailed work required to produce baseline costs. They need to have sufficient detail and accuracy to enable an effective investment decision. Typically, some organisations use +/- 30% estimates.

Benefits

The benefits in the business case will define the return from the completion of the project. Typically, they are monetary in nature. For example, they might include the revenue from the sale of houses or income from a wind farm. They are important because they will be evaluated against the cost to see if the business case is justified.

Risks

The risks in the business case include the risks to the delivery of the project and the benefits. Again, at this stage they will be quite high level. In comparison to the risk log in the project plan they will include risk to the benefits whereas the project plan mostly focuses on delivery. Nevertheless, the risks are very important in reaching the right decision so are an important element of the business case.

Timescales

The business case will also include high-level timescales. These are important to define when the benefits will start. They will be used as part of the cost/benefit analysis for the project. This is because the timing of the benefits can be affected by discounting factors. The benefits may also be subject to changes in the project context. For example, change in political or economic conditions.

Advantages of a matrix organisation structure when used in a project environment:

1. Shared resources
2. Specialist skills
3. Project leaders have line management authority

The sharing of resources across the business is an advantage of a matrix organisation. The project manager can source specialist skills and core competencies by liaising with the functional heads and identifying who is available, their ability and ultimately use them on the project. By sharing resources, it can save on costs as the staff are already employed within the business.

Staff with specialist skills working on a project is an advantage of matrix organisation. These members of staff can be seconded from their day job in a functional department to a project environment for a period of time. Their skills can be utilised on the project but will remain within the business once the project ends. It also allows for the members of staff to become more motivated as they can develop in areas that maybe they get no experience in on their day job.

PMs having a clear line of authority is an advantage of a matrix organisation. Resources will be aware of the reporting line whilst working on the project.

Disadvantages of a matrix organisation structure when used in a project environment:

1. Line management conflict
2. Resource management culture

Line management conflict can be a disadvantage of a matrix organisation. By working in a matrix organisation, the resources are only seconded to the project for a limited amount of time. They do still have their line manager from their functional department. This sometimes can cause conflict if they are asked to carry out tasks from both areas. The resources would need to identify how to prioritise work in these situations.

Resource management culture is also a disadvantage of a matrix organisation. The project manager would need to be an excellent communicator and ensure they are aware of who the available resources are, their skills and ability and their willingness to join the project. The functional manager would need to work with the project manager to identify these people. For example, they would arrange networking sessions or informal presentations so that both the staff and the project manager are fully aware of all the opportunities available to them.