A few words about stakeholders

"Find the right balance of competing claims of different stakeholder groups. All claims deserve attention, but some are more important than others."

--- Warren Bennis

With this quote, we begin the next installment of this series. [The first part]({{ "/in-search-of-lost-quality/" | prepend: site.baseurl }}) dealt with the concept of quality --- in this one we will deal with the concept of the stakeholder.

The concept of "stakeholder" is certainly familiar to most readers. Probably every person associated with the implementation of ventures and projects has sooner or later encountered this term. So let's remind ourselves what or who a stakeholder is. The literature provides many more or less successful definitions of the term, among which it is worth citing the PMI^1 (Project Management Institute) interpretation, according to which project stakeholders are "individuals and organizations actively involved in the project or whose interests are subject to favorable or unfavorable influences resulting from the implementation or completion of the project." Another noteworthy explanation is the interpretation heralded by David Cleland[^2], according to which intreressees are "groups of people who have or believe they have a legitimate right (claim) to important aspects of a project."

What do these definitions imply beyond academic value? What follows is that:

• stakeholders participate in the project work --- so they may be part of the team working on a solution or supporting those efforts,
• the course or results of the project affect stakeholders, both positively and negatively --- so they may have their own expectations and requirements for the solution itself, as well as for the way the work is carried out; they may also have objections to the goals of the undertaking and its results.

What further results from these considerations? Well, that:

• stakeholders are the source of information, expectations, needs, requirements with respect to the planned solution --- so they have a fundamental influence on the definition of the desired quality of the offering,
• stakeholders can impose constraints on the capabilities of the solution or the way in which the project work is to be carried out --- again, so they influence the scope and desired quality expected from the offering,
• stakeholders, by virtue of their role, have communication needs in relation to the project --- so these need to be taken into account when planning communications to minimize the risk of chaos, misunderstanding and misinformation.

Well, the definitions are already known. At this point, an attentive reader might ask what the above argument has to do with anything and with the quality that this series is supposedly about. To answer this question and give context to the above discussion, let's recall how we defined quality:

Quality --- the degree to which a proposed solution delivers value to specific stakeholders in their business, technological and cultural environment.

Quality is established and ensured in the process of building and executing the offering. One component of this process is business analysis and requirements engineering, consisting most generally[^3] of iteratively eliciting, analyzing and documenting stakeholder requirements for a planned product, or more generally --- an offering. These requirements usually need to be agreed upon before attempting to define a solution that meets the desired goals and expectations of the key parties, as in some cases stakeholder needs are not completely aligned. More --- to be in line with project realities --- in the case of a significant percentage of projects they are in complete conflict. Therefore, before we undertake the conception of the solution to be implemented in the initiative, it is first necessary to identify the stakeholders, analyze them and plan both the ways to realize their expectations and the methods of communication and cooperation.

In summary --- stakeholders are a key element of business analysis and requirements engineering in any endeavor. The implication of this statement is that when undertaking any initiative, stakeholder identification and analysis should be done first.

How? There are many sources of knowledge and best practices that can be used when undertaking the task: these range from international standards (such as the aforementioned PMI) to locally gathered experience. From these sources you can draw information about standard types of stakeholders, methods of identifying them and ways of further analysis.

For example, one such source, the BABOK® Guide[^4], offers the following list of "generic" stakeholders:

| Generic Stakeholder | Example/Role Alternative | | | | | | | Business Analyst | Business-System Analyst, System Analyst, Process Analyst, Product Owner | Client | Customer | Purchaser: broken down by market, geographic area, industry, etc. | Field Expert (SME[^5]) | Broken down by organizational unit, role, etc. | End User | Broken down by organizational unit, role, etc. | End User. | Implementation expert | Change manager, configuration manager, solution architect, developer, database administrator, information architect, usability analyst, trainer, organizational change consultant, etc. | Operational support | Help desk, network staff, release manager | Project manager | Scrum master, team leader | Provider | Contractor, consultant, etc. | Tester | Quality assurance analyst | Regulatory body | Government, regulatory bodies, auditors | Sponsor | Management, board of directors, product manager, process owner |.

The template taken from BABOK® can be used as an initial suggestion of the types of stakeholders involved in the planned initiative. This list can be expanded as needed to include other groups, such as marketing personnel, sales, etc.

In the process of identifying stakeholders, it can also be helpful to ask the following questions:

• Who can influence the definition of the business problem to be solved?
• Who is representative of the target group?
• Who is responsible for the plans to be undertaken?
• Who can support the initiative with financial and technical resources?
• Whose behavior must change to achieve success in implementing the change?

Complementing the above approach can be stakeholder classification techniques, such as an "onion" diagram or a simpler division of stakeholders into internal and external. The latter approach consists most generally of dividing those involved in the initiative into primary (internal) stakeholders --- which are formal project members and those with control over resources; and secondary (external) stakeholders --- which are informal project members, people without direct influence over resources, but who instead have a positive or negative impact on the project. While this classification seems simple and practical, it leaves the risk of omitting important information --- such as stakeholders "implicitly" influencing the project: legislation, business partners, standardization organizations. Subjectively, I therefore recommend using a more comprehensive method. Again, BABOK® comes to the rescue by introducing the following diagram to help identify stakeholders and their relationship to the project.

How to use the "onion" diagram to identify stakeholders? The approach taken largely depends on the situation and the point at which we begin the identification.

We can start from the "middle" --- identify the project team, then move on to identify the end users and others who use the delivered solution, then identify the sponsors and executives who collaborate or communicate with the solution users, and finally identify customers, suppliers and external partners. However, this is a detail-to-general approach --- it is unlikely to work when trying to identify stakeholders for a general outline of a business problem, the implementation of which is not yet the focus of the project and which does not have an assigned project team. In such a case, it will be wiser to approach the task in the opposite way --- from the general to the specific, starting from the "outside" and systematically decomposing the area of interest to the lowest level. This solution is advantageous in that it allows for a broader analysis of business aspects (external and internal environment), rather than focusing on a specific outcome of the project (i.e., software, for example) or characteristics of the project team.

Identifying stakeholders alone is not enough to manage stakeholder relations efficiently. Further analysis is necessary. This can involve determining the impact of stakeholders on the project and their level of interest in the project results --- which again can be helped by BABOK®, as well as other sources that describe the influence-interest matrix method.

The influence-interest matrix is a simple, yet very useful tool for analyzing stakeholder relations and planning collaboration. It is used as follows: previously identified stakeholder roles are analyzed by indicating their influence on the project (e.g., the level of decision-making on key issues) and the level of interest in the results of the project (in other words --- the impact of the initiative on the stakeholder, both positive and negative). Based on this information, we can indicate the stakeholder's "place" in the matrix and, consequently, visualize their participation in the project and plan the relationship accordingly. Thus, for example, a stakeholder with a very high level of influence and a keen interest in achieving the desired results (e.g., a sponsor) is the person with whom one should work closely on the ground of setting and implementing the vision, goals, approaches and key decisions for the planned solution. It is this stakeholder who has the authority to make important decisions --- so you need to secure his or her support in implementing the planned change.

An important activity in stakeholder relationship management is communication. Information sharing. Status meetings. Feedback. And many other elements that make up knowledge sharing.

Communication is an example of the "obvious" that is forgotten in most ventures or even organizations. After all, it's obvious that we communicate, right? So why mention it, or deal specifically with this particular topic?

Unfortunately, among other reasons, precisely because communication is so "obvious," it is rarely mentioned, and even more rarely --- planned for. The result of failing to think through a communication strategy can be the omission of important stakeholders in email communications and the involvement of the wrong people from the point of view of ensuring the success of the project. A real-life example of such a situation might be an email discussion between a project manager and a client representative regarding a change in key requirements, to which the analyst was not invited (mistakenly or intentionally). The result may be the issuance of an approval to implement a requirements change that has a fundamental impact on the scope/stability of the solution. Why such an effect? Well, from the fact that:

• the aforementioned project manager, in many cases, is not able to independently analyze the validity of the change or estimate its impact on other elements of the project,
• the client's representative does not necessarily represent the point of view agreed among business stakeholders --- he may represent only his own selected needs and perspectives (despite appearances, this is not a highly improbable situation).

The above example is a simple visualization of the lack of "procedures" regarding the rules and participants in the communication process. With help comes a simple tool, the RACI matrix. RACI makes it possible to depict the different types of stakeholder involvement and responsibility in the creation of a given work product or execution of an activity, and is also known as the RAM[^6] responsibility matrix. The name RACI is derived from the first letters of the English terms for the level of stakeholder involvement and means:

• R (responsible) --- responsible --- stakeholder performing a given task/creating a given work product
• A (accountable) --- accountable --- the decision maker, ultimately responsible for the proper execution and completion of a task or delivery of a product; a role with the authority to delegate to contractors to do the work
• C (consulted) --- consultant (a.k.a. advisor) --- stakeholders providing feedback on the work being performed/delivered product; usually domain experts
• I (informed) --- informed --- a person informed about the execution of work, current progress or completion of a task or product

An example of a RACI matrix for selected activities is shown in the table below:

| | | | | | | | | --- | --- | --- | --- | --- | --- | --- | | Zadanie | Wiodący analityk | Kierownik projektu | Analityk biznesowy | Właściciel biznesowy | Architekt oprogramowania | Reprezentant użytkowników końcowych | | Opracowanie podejścia do zarządzania wymaganiami | A/R | I | R | C/I | I | | | Konfiguracja narzędzi wspierających zarządzanie wymaganiami | A | I | R | I | I | | | Identyfikacja wymagań | A | I | R | I | C | C | | Uzgodnienie wymagań | A | I | R | C | C | C | | Opracowanie specyfikacji wymagań | A | I | R | I | C | C |

An additional aspect to consider in planning communications is the form and frequency of communication. Each type of stakeholder may have his or her own preferences for how or in what form information is exchanged. For example, business representatives may prefer a descriptive form of requirements over models, usually preferred in turn by technical people. In order to communicate effectively, the form of communication must be tailored to the recipient --- otherwise we run the real risk of misunderstanding and making decisions based on incorrect conclusions.

Regarding the frequency of communication --- we sense quite intuitively that different information is communicated at different intervals and to different audiences depending on the stage of the work. Thus, there is no basis for setting a fixed frequency of communication for particular tasks or work products --- nor is it necessary. For example, in the early stages of a project, communication regarding requirements reconciliation is essentially daily and occurs most often between analysts, representation of target audiences, business decision makers and technical people who can influence the adopted solution. In the later stages, this communication is usually much less frequent --- the requirements have already been more or less agreed upon and need at most to be confirmed/determined --- so there is no need to schedule daily meetings or deliberations.

The above-mentioned elements --- participants, role, form, frequency of communication --- can be put together in the form of a communication plan structuring and clarifying the rules of information exchange in a venture or organization. The template for a communication plan can be taken from the Prince2 standard, among others, and should include at least the following:

• A stakeholder analysis (ideally including a RACI matrix)
• Objectives and focus of the communication (e.g., work products to be shared)
• Communication strategy, including:
• Meeting schedules
• Procedures and templates for documenting conclusions and meeting notes
• Methods of access to information
• Potential risks

Summary --- stakeholders are an essential, too often neglected, component of quality management. It is from them that the key requirements, needs and information that define quality in a specific context come forth. To ensure the desired quality of an offering, care must be taken not only to identify the people involved in the endeavor, but also to further analyze them and develop a relationship management strategy.

In the next installments of the series, I will present the next elements of building a strategy for creating a new offering. The next topic covered will be the "why" --- i.e., the business case for the initiatives undertaken.

All posts in this series:

1. [In Search of Lost Quality]({{ "/in-search-of-lost-quality/" | prepend: site.baseurl }})
2. [About stakeholders a few words]({{ "/about-stakeholders-slow-something/" | prepend: site.baseurl }})
3. [How to pave the way for business]({{ "/how-to-pave-the-way-for-business/" | prepend: site.baseurl }})
4. [What is a business case]({{ "/what-is-a-business-justification/" | prepend: site.baseurl }})

The title of the series refers to Marcel Proust's series of publications "In Search of Lost Time", which is a record of the memories of the novel's protagonist. In the last volume of the series, the protagonist decides to write a novel describing his life which --- in his mind --- will enable him to regain lost time. In my series, I will use a similar procedure --- the series will begin with the earliest "stages of life", moving towards more and more advanced and mature themes, to reach a conclusion at the end....

Footnotes

[^2]: "Project Stakeholder Management," Project Management Journal, Vol. 17, No. 4, 1986 [^3]: A more detailed explanation of business analysis terms can be found, for example, in the BABOK® Guide http://www.iiba.org/babok-guide.aspx, or the IQBBA® program http://iqbba.org/; while the term requirements engineering is explained, for example, by SIĘ*http://www.sei.cmu.edu/productlines/framereport/reqeng.htm*or REQB® http://reqb.org/ [^4]: Business Analysis Body of Knowledge [^5]: Subject Matter Expert [^6]: Responsibility Assignment Matrix