Who is a stakeholder
There’s always one more System Stakeholder than you know about; and the known stakeholders have at least one more need than you know about now.
Tom Gilb
The code itself, no matter how ideal it is, is not worth a penny. What matters is the business functionality that this code implements. Or rather, the people who are willing to pay for this business functionality, because it solves their problems, or just entertains. All these people, for whom developers, architects, managers work all over the world, are called stakeholders. Project development is all about its stakeholders. And the developers themselves are also among these people.
A stakeholder is a person or organization that has rights, share, claims or interests with respect to the system or its properties meeting their needs and expectations.
To put it more simply, the interests of stakeholders have some influence on the project, so their opinion should always be taken into account. If you do not do this and overlook one of the key stakeholders, you can ruin the whole project and it will be much more expensive than just letting a development bug in the project. Stakeholders provide opportunities and limitations for the system and are the source of requirements.
An interesting point is that often stakeholders are not defined before the decision making stage. But as soon as the decision is designed, announced, or implemented, everyone affected by this decision will express their opinion. To save the project from potential harm, you are recommended to firstly answer the questions why and to whom, and only then how.
Stakeholder types
For whom is the project usually created? An adequate answer will be — for end users. End users are also stakeholders on the project. However, they may not be the key ones. Therefore, in software development, it’s worth focusing not on end users, but entirely on stakeholders.
It’s impossible to compile a complete list of stakeholder types since, for different systems, they can differ significantly.
Let’s highlight the following stakeholders as the most common. Also, let’s look at each category in terms of consequences when ignoring their interests:
● Those who are involved in the project and work on it.
○ Project team. Imagine that you have developed a solution that uses the .NET technology stack. But there is one problem. You have twenty available Java developers in the company and no one who knows .NET. I suppose after you remember this, there will be no need in explaining why the designed solution is bad. And this is the simplest example. You need to know the team to understand what technologies they know well and which of them should not be used just because they are trending.
○ Management team. Let’s say you forgot to ask your project manager about something important before making a decision. But they will cover you and do so for the designed solution to reach the final result. Moreover, often a project manager has more information and listening to their opinion is very useful.
○ Third-party companies. There may be various problems from the complexities with integration to the inability to use third-party solutions.
○ Supporting team. An organization or a person who supports the system at one or more stages of its life cycle. Let’s say an architect forgot to come up with a support system. This raises such questions as, “Was the designing of this system just a hobby and how do we support it?”.
● Those who are affected by the project and who will use its artifacts, including the results.
○ Customers. Customers are one of the key stakeholders. If you are an architect, then there is only one question. How could you forget to discuss your decision with the people who pay the money for the project development? I will answer myself. In fact, it’s easy. In my practice, there was one example when an amazing technical solution for real-time data processing and synchronization was created. This decision was one of the most advanced on the market, taking into account the latest technological trends. Furthermore, it was competently designed, perfectly tested, and shown to the customer. And then it turned out that the customer wanted something different. More precisely, a completely different solution. And they did not need super synchronization at all.
○ Heads and employees of functional units. They are rarely encountered in practice, but they are one of the most demanding stakeholders. If you forgot them, then prepare yourself for them putting sand in your wheels. For example, you are designing an accounting system that affects two departments. Each department has a head and 15 employees. The designed system further optimizes the work of one of the departments and allows to free 12 out of 15 people. At the same time, the manager is very greedy for power and is shocked that, due to the additional functionality you have developed, they will have only three employees. Therefore, they try to look for flaws in the system, write a huge number of emails to all key persons on the project, and simply stall the process wishing this functionality would be removed.
○ End users. So, we finally got to them. I wish they always had a key influence on the project, but in practice this is not true.
● Those who are not involved in the project, but because of their position or activities can influence it.
○ Top-managers of the company. The company’s profit, success, and position, as well as the success of projects, are important for them. We should try to take this into account.
○ Owners of the company. They get very upset hearing the words “project” and “risks” in one statement. Try to minimize them when designing your project.
○ Shareholders and creditors. The company’s profit is very important for these stakeholders. Moreover, they want to get it as soon as possible and be stable. Designing a solution that will be done in five years, although you can divide it into iterations and start earning tomorrow is a mistake that can cost you your career.
○ Regulatory structures. You designed a system that does not correspond to some standards and guides, and then your solution is banned from the AppStore? This is anything but a good solution.
Also, it is worth paying special attention to the fact that stakeholders can have not only a positive attitude towards the project, but also a negative one. Therefore, we will consider how to define stakeholders for a specific project.
Theory of stakeholder management
The theory of stakeholder management was firstly detailed by Edward Freeman in the book “Strategic Management: A Stakeholder Approach”. It states that understanding and defining groups of people that can influence a business or a specific project makes it possible to clearly structure and optimize the management process. And although this process is more related to the realm of management, let’s not forget that we are not just coders, but architects, and this applies to us too. In his concept, Edward Freeman divided the process of stakeholder analysis and management into six stages:
Let’s look at these stages in more detail.
Identifying all stakeholders
Since stakeholders have influence on the project, all stakeholders should be identified and studied strictly before starting the design. This can be done by a business analyst or an architect. Information about stakeholders should be used by the project manager at the business analysis stage, during the creation of the architecture, and also when implementing the designed solution.
It is very important not only to identify stakeholders but also to find ways to influence them, so that later it is easier to come to an agreement on various issues.
Communication is the main tool used to influence stakeholders. It should always be used first. In particular, it allows you to determine their motivation for acting a certain way.
To communicate effectively with stakeholders, you need to know them well. Without that it is impossible to work efficiently.
Any stakeholder analysis begins with identifying all the stakeholders of the project. It will be useful to use the technique of brainstorming. The following questions can help identify stakeholders:
● Whose actions can result in failing to meet the project goals?
● Who has the most interest in developing this project?
● Was there a project like this before? If so, was it successful?
● Is it necessary for all departments to participate in this project?
● What issues need to be solved during the project?
● Who knows this data better than everyone else, and is able to design it independently?
Stakeholder analysis allows:
● Identifying the interests of stakeholders that may affect the project.
● Identifying the potential difficulties that may interrupt the project or reduce its success.
● Identifying the key persons who need to be informed about the project progress.
● Identifying the groups of people that need to be involved at each stage of the project.
● Evaluating the means, rules, and principles of communication throughout the project.
● Planning actions to reduce the negative impact of stakeholders on the course of the project.
Bear in mind that the designed architectural solution must pass several phases of work with stakeholders to be recognized as successful.
According to the OMG proposals, we can distinguish six project states in terms of accounting for, involving, and satisfying the stakeholders:
● Recognized — stakeholders are identified.
● Represented — methods of engaging stakeholders are agreed upon and representatives from each group of stakeholders are appointed.
● Involved — representatives of stakeholder groups take an active part in the project and fulfill their duties.
● In agreement — representatives of stakeholders are all in agreement.
● Satisfied for deployment — the minimum expectations of the stakeholder representatives are achieved.
● Satisfied in use — the system meets or exceeds the minimum expectations of the stakeholders.
Determining the requirements with the stakeholders’ help
After determining the list of stakeholders, it is necessary to understand their position. Their importance and influence allows us to identify the main requirements and exclude unnecessary ones.
To do this, you can use the following strategy of stakeholder management, which is usually used in project management:
The stakeholder map is a two-axis chart with axes of influence and importance.
Influence is the stakeholder power in project management. The stakeholder power is in influencing the level of the project investment, participating in the project budgeting, and having impact on people who make decisions on key issues during the project.
Importance is the stakeholder’s contribution to the project outcome. It is determined by how satisfying the needs, solving the problems and interests of each stakeholder can affect the project outcome. The importance is, for example, the special knowledge or skills of the stakeholder, as well as the needs that must be satisfied for the project to become successful.
The map is divided into four sectors, which are the stakeholder groups. Different working methods are applied for each group.
The first group is High influence, high importance — Good relations. It is necessary to establish close working relations with these stakeholders because, for them, the project is important, they are involved in the implementation and actively influence the process and result.
The second group is High influence, low importance — Monitoring. These stakeholders have power to implement the project, but are not too interested in it. With this combination of factors, they can become sources of risk, so careful monitoring and management are required.
The third group is Low influence, high importance — Protection. They require special initiatives to protect their interests, because the project is quite important for them, but their impact on its implementation is insignificant (or they have no possibility to influence).
The fourth group is Low influence, low importance — Low priority. This group of stakeholders is involved and relatively interested, but not so much. Therefore, from the perspective of attention allocation, this group has a low priority.
Applying your stakeholder knowledge
When the list of stakeholders is formed, the importance-influence map is drawn, the list of requirements is created and approved by the key stakeholders, you can start designing the project. Further, the project manager should work with the key stakeholders and accompany them throughout the whole life cycle of the project. The project manager must ensure that the requirements of stakeholders are applied during development, and in case of sudden changes in the requirements or stakeholders themselves, the manager should inform the architect who will be responding to these changes.
It is important to remember that if the architect does not propose the most optimal algorithm, this can lead to the project becoming more expensive with varying consequences. If the architect fails to identify one of the key stakeholders, it may cost him his career.
No comments:
Post a Comment