3.1 Why Identifying Stakeholders?
Stakeholder identification, or equivalently environment architecture, is a key systemic analysis: each mistake in this analysis may indeed result in flaws in the product under design. One must indeed remember that a system is nothing else that a concrete answer to a series of needs1We recall that we are using here the term “need” in a technical way. A need indeed refers to any property expected (which would correspond to a need in the common sense) or imposed (which would rather correspond to a constraint in the common sense) by the environment of a given system (see subsection 2.4.3 for more details). and that these needs are coming from external stakeholders. As an immediate consequence, forgetting important stakeholders, misevaluating their role and/or considering erroneous ones will result in missing needs and/or working with wrong needs, and hence in missing requirements and/or working with wrong derived requirements, relatively to a given system. The resulting concrete system that might be developed on such a basis will therefore typically either miss the functions and components that are specifically addressing these missing needs, or have unnecessary functions and components that are associated with these wrong needs. One can therefore easily understand the crucial importance of correctly identifying stakeholders – that is to say the necessary and sufficient ones – since any system development process fundamentally rely on the quality of this identification.
To stress on this last point, one shall also have in mind the potential cost(s) of a wrong stakeholder identification which explain why one must put the necessary energy in this core initial analysis. In this matter, one commonly considers that such costs follows a geometric progression within the system lifecycle (see Figure 39): if the correction of an error during stakeholder identification has cost 1 (i.e. typically adding a missing stakeholder or replacing an erroneous stakeholder in this analysis), one usually considers that correcting the consequence of that error will have cost 10 when done during system design, cost 100 when corrected during detailed design, cost 1.000 when discovered during integration and even cost 10.000 if managed when the system is in service. One must thus spend enough time initially in order to achieve an as-sound-as-possible environment architecture.
Figure 39 – Impact of an error in environment architecture
Any system architect shall in particular always be highly anxious of being sure that stakeholders were correctly identified since all the development process rely on that initial analysis!
Stakeholder Identification may Disrupt the Nature of a Design Problem: the Mobile Industrial Tool Case
AVORE is an industrial company that produces heavy industrial electrical generators, each product having typically a weight of more than 100 tons. The average production duration of these generators was unfortunately around one year due to the fact that the assembly lines of AVORE’s plants were never optimized. An obvious reason for such a bad production delay was due to the fact that the electrical generators were produced in an industrial chain organized in three successive workshops where the generators were progressively assembled. Due to the important weight of the generators, the logistical time required to move the generators from one workshop into the other represented 40 % of the total construction time, which was not “lean” at all!
The method responsible of the Alsacian plant of AVORE had then a brilliant idea. Instead of moving the generators to the workshops, why not doing exactly the converse and moving the workshops to the generators, which would suppress a lot of stupidly lost time. Following this intuition, he launched a study for developing a mobile industrial tool – allowing to do the production activities of the second and third workshops of his plant – that would allow to manage the construction of the generators without moving them. The initial step of this study was logically dedicated to a stakeholder identification. The first identified stakeholders were then naturally the plant, the industrial department of AVORE and the customers who would be the first beneficiaries of the new mobile industrial tool. In a second step, it was however understood that this tool had unfortunately a strong impact on another less important plant of AVORE, located in Normandy and dedicated to absorb the customer demands that the Alsacian plant could not manage. It indeed appeared that the efficiency increasing, brought by the mobile industrial tool, allowed the Alsacian plant to manage all customer requests, without any need of a supplementary plant.
The discovery of the Normand plant as a new stakeholder changed radically the problem which was not anymore a simple technical optimization question, but a deep political issue. Additional stakeholders emerged them immediately: trade unions, local Normand politicians and finally AVORE’s general direction who canceled after two months of discussions the mobile industrial tool project in order to avoid any social trouble …
Case study 5 – The Mobile Industrial Tool Case