Theory "Project Environment"

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

No project is carried out in a vacuum, neither traditionally organised projects nor agile ones. Projects are limited by legal or contractual constraints, personnel or technical issues. Identifying and taking into account the essential issues in time helps to create a successful project. As a member of an agile project team, you need to ask yourself the following questions:

What is the environment of the project?
What do I need to pay attention to?

The project and its environment¶

It is a good idea to carry out the so-called PESTEL analysis, even in an agile project.

PESTEL is an acronym that includes the following "environments":

All the impacts on your project can be grouped under one of these umbrella terms. It is important to keep in mind that the project is influenced by the environment, but also vice versa. Depending on the country in which your project is implemented, the environmental impacts may be more or less extensive.

But what is behind the respective headings?

Politics - Political Framework
What are the "centres of power" to be considered? Are there different fields of interest?

Economics - Economic Framework
Are there economic limitations? Prominent economic interests? Competitors? Are there seasonal or cyclical variations to consider?

Sociology - Socio-cultural Framework
Are there ethical or moral limits to the project? Is there a need to take into account the moods or emotions of the people affected by the project?

Technology - Technological Framework
Are there any technical innovations to be integrated in the project? Are the technologies tried and tested? Do property rights or rights of use have to be observed?

Ecology - Ecological Framework
Does the project pollute the environment? Do environmental requirements or constraints need to be addressed?

Legal - Legal Framework
What is the legal environment? What laws and regulations apply to the project?

These are the key questions to think about when evaluating the project environment.

Based on your environment analysis, you can prepare an impact analysis:

Where are the opportunities and risks for your project?
How much impact do they have on your project?

Communication with the environment¶

Communication is the be-all and end-all in agile project management, so it is obvious that communication with the environment also plays an important role. There are three possible levels of involvement. You can communicate with your environment via the

participative,
discursive, or
repressive approach.

When the participatory approach is applied, all parties affected by the project are treated as partners and are actively involved in the project. In this approach, participation ranges from information and communication to involvement in the decision-making process. In the discursive approach, the interests of the different stakeholders are reconciled. In this case, conflict management and negotiation methods should be used. The repressive approach is characterised by the fact that the environment is only superficially involved. Decisions are made by one person alone. There are only a few cases where this approach may be necessary.

Stakeholder analysis¶

Why is a stakeholder analysis carried out?¶

Stakeholders are affected by or can influence a project. They can be positive, negative or neutral towards the project. It is therefore important to get an impression of the stakeholders in order to be able to adapt to their reactions if necessary and to derive measures for appropriate communication. The stakeholder strategy addresses the stakeholders in the project and involves them in the design of the future product - this ensures that the best possible product is developed and that the different interests are taken into account in the product development.

Project participants are also stakeholders of a project.

In a Scrum project, the most important project participants are found in the Scrum Team. The Scrum Team consists of the Developers, the Scrum Master and the Product Owner. You can find out more about the three roles in the next chapter. In agile projects that are no Scrum projects, project participants can be, for example, the project manager or developers.

Scrum Master, Product Owner as well as project manager should think about their stakeholders, because this is the only way to develop an optimal communication strategy.

What can be examples of stakeholders from the perspective of the Product Owner and Scrum Master?

From the Product Owner's perspective: Customer, client, user, developers in the team, sales and marketing, suppliers, etc.

From the Scrum Master's perspective: All persons or units involved in the Scrum project, corporate environment, board area, superiors of the development team, line organisation, HR department, procurement, works councils, etc.

In a stakeholder analysis, the following steps must be carried out:

Analyse the different stakeholders or stakeholder groups based on their influence and affectedness.
Identity and analyse customer expectations.
Conduct an analysis [level affected (passive) - influence (active)].
Assess the stakeholders, e.g. whether the stakeholder is positive or negative about the project, what their importance and power are, or how they are likely to behave.
Determine measures to ensure the success of the project and develop a strategy for dealing with the stakeholders in the project (information via portal or newsletter, formation of a core team, personal contact, invitation to meetings).
Conduct the stakeholder analysis on a continuous basis as required and check for any changes, especially after important events.

Stakeholder analysis chart¶

The stakeholder analysis can also be presented graphically with the help of a stakeholder analysis chart. For this purpose, the stakeholders are classified into four quadrants according to how they are affected by and can influence the project:

Depending on the arrangement of the stakeholders in the different quadrants, the clarification of the organisational connection of the project and the stakeholder communication follows.

Measures for project environment and stakeholders¶

Now that you have arranged the stakeholders in the respective quadrants, you can start working on the corresponding measures. There are various measures to choose from, but the Product Owner and Scrum Master have the creative leeway in dealing with the project environment and the stakeholders. Possible measures (depending on the size of the agile project) can be:

Quadrant 1: These are the stakeholders who derive significant benefit from the product and have a major influence on its creation. These can be, for example, customers, big investors or decidedly important users. These stakeholders are the supporters of the project and should therefore be involved - ideally by inviting them to (regular) meetings to indentify 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. through 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 be in form of videos or newsletters reporting on the projects' 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 the company website. It may be possible to "recruit" stakeholders from this quadrant by actively involving them or by tapping into their needs.

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

The distribution of stakeholders is only a snapshot.

It is quite possible that stakeholders shift to other quadrants in the course of the project, so you should not just do the stakeholder analysis once, but take a look at it again and again and make updates if necessary.

Since there are fixed roles in a Scrum project, we would like to introduce you to further ways of integrating (important) stakeholders that the Product Owner and the Scrum Master can carry out:

Product Owner:
Participation in the Sprint Planning Meetings, participation in the Sprint Reviews, formation of an external working group, continuous information through newsletters or formation of a project portal.

Scrum Master:
Networking in the company, personal contact with key people in the company, formation of a working group to establish Scrum, creation of an information portal, development of the necessary steps together with executives.