Theory "Project Environment"

The analysis and management of the environment and stakeholders, as well as communication with them, are essential steps in the planning and implementation of any agile project.

No project is carried out in a vacuum, whether it is traditionally organised or agile. Projects are constrained by legal or contractual conditions, as well as by personnel or professional limitations. Identifying and considering essential aspects in good time helps to create a successful project. As a team member of an agile project, you must ask yourself:

• What kind of environment does the project face?
• What should be taken into account?

The project and its environment¶

Even in an agile project, it is useful to conduct what is known as a PESTEL analysis.

PESTEL is an acronym that covers the following environments:

All impacts on your project can be summarised under one of these categories. It is important to remember that the project is influenced by its environment, and vice versa. Depending on the country in which your project takes place, environmental impacts may vary in significance.

These are the key questions to consider when evaluating the project environment.

Based on your environmental analysis, you can create an impact analysis:

• Where are the opportunities and risks for your project?
• How strongly do they affect your project?

Communication with the environment¶

Communication is essential in agile project management, and this includes communication with the environment. There are three possible levels of engagement. You can communicate with your environment using:

• the participative,
• the discursive, or
• the repressive approach.

With the participative approach, all parties affected by the project are treated as partners and actively involved. This ranges from information sharing and communication to inclusion in the decision-making process. The discursive approach aims to align the interests of various parties, making conflict resolution and negotiation techniques particularly important. The repressive approach means that the environment is only superficially involved. Decisions are made by a single person. This approach is only necessary in rare cases.

Stakeholder analysis¶

Why conduct a stakeholder analysis?¶

Stakeholders are affected by a project or can influence it. They may be positive, negative, or neutral towards the project. It is important to assess them to prepare for their reactions and develop appropriate communication strategies. The stakeholder strategy targets the project's stakeholders and involves them in shaping the future product—this helps ensure an optimal outcome and takes diverse interests into account.

Scrum Masters, Product Owners, or Project Managers should all consider their stakeholders to develop an optimal communication strategy.

The following steps are involved in stakeholder analysis:

1. Analyse stakeholders or stakeholder groups based on their influence and involvement.
2. Identify and analyse customer expectations.
3. Conduct an impact analysis: involvement (passive) - influence (active).
4. Assess stakeholder attitudes, importance, power, and expected behaviour.
5. Define actions to ensure project success and develop a strategy for dealing with stakeholders (via portal or newsletter, forming a core team, personal contact, meeting invitations).
6. Perform the analysis iteratively as needed and check for changes, especially after key events.

Stakeholder matrix¶

The stakeholder analysis can also be visually represented with a stakeholder matrix. Stakeholders are positioned in four quadrants based on their involvement and influence:

Based on their quadrant, the organisational attachment to the project and stakeholder communication can be determined.

Measures for project environment and stakeholders¶

Now that you have placed the stakeholders into the appropriate quadrants, you can focus on suitable actions. The Product Owner, Scrum Master, and project manager have flexibility in how they deal with the project environment and stakeholders. Possible measures (depending on the size of the project) include:

Quadrant 1: These are the stakeholders who derive significant benefit from the product and have a major influence on its creation. These can include, for example, customers, major investors, or particularly important users. These stakeholders are the supporters of the project and should therefore be involved - ideally by inviting them to (regular) meetings to identify their needs.

Quadrant 2: Here are the stakeholders listed, who are very interested in the success of the project, but only have a moderate or small influence on it. These can be, for example, frequent users of your product or people who have made smaller investments (e.g. via crowd-funding). Since these stakeholders are future users of the product, it makes sense to invite a selection of them to special meetings (like the Sprint Review Meetings). Other ways to engage them in the project could include videos or newsletters reporting on the project's progress. Alternatively, feedback can be gathered from them through online surveys - they might be happy to support the project.

Quadrant 3: Here you will find those stakeholders who have neither an interest in nor influence on your project. Therefore, it is often sufficient to inform this group when necessary. For example, in the form of a press release or by publishing an article on your company's website. It may be possible to win over stakeholders from this quadrant by actively involving them or by addressing their needs.

Quadrant 4: These are the people who have a significant influence on the project but are not particularly interested in its success. This may be, for example, a department head to whom the (Scrum) Team must report, but who does not invest their own budget in the project, or a software architect whose technical decisions must be followed by the team. Important customers of your company may also fall into this quadrant. Although these stakeholders have no direct interest in the product, they should still be satisfied, eventually becoming supporters as the project progresses.

For Scrum projects with fixed roles, the Product Owner and Scrum Master can integrate key stakeholders in the following ways:

Product Owner:
Participate in Sprint Planning and Reviews, set up external working groups, provide updates via newsletters or project portals.

Scrum Master:
Network within the organisation, maintain personal contact with key individuals, form working groups to establish Scrum, create information portals, and collaboratively develop next steps with leaders.