In a recent article I explained how to identify, analyse and communicate to project stakeholders. This topic clearly has a political touch and according to my experience every major project is loaded with company politics. But fear not, my fellow requirements engineers, project managers and enterprise architects… a description language does exist…
I already mentioned „Archi“ in an earlier article where I explained how to model a new process and its IT support landscape using the Archimate 2.0 description language. Archi is a very versatile Enterprise Architecture Modelling (EAM) tool and helps to create a top-down story for each and every IT requirement.
It´s based on the Archimate specification which basically supports modelling on three layers: business layer, application layer and technology layer. On each layer three dimensions of modelling exist: behavioral, structural and informational. E.g. a behavioral concept on the business layer is a process. On the application layer application functions and interactions are behavioral elements of your model.
The Archimate specification supports several extensions. One extension is called „Motivation“ and its purpose is to support modelling of stakeholders, their motivations and resulting requirements. Archi´s support pages give you a detailed specification of this extension.
I will just supply you with a quick overview and discuss some pros and cons under the light of my recent article about stakeholder management. The following pic shows the major components of stakeholder modelling in Archi.
So starting from left to right:
- Stakeholders are individuals or groups who (can) influence a project in any way (such as scope, budget, objectives, resources, etc.).
- A stakeholder´s drivers actually initiate or promote change in an organization, e.g. the sales director´s strategic focus on new customers or a company´s strategy to rely on great service.
- An assessment is the result of analyzing a driver (e.g. „How great is our service in reality?“)
- A stakeholder´s drivers and assessments result in goals – measurable end states such as „Reduce customer complaints by 30% within 12 months“.
- A goal is either realized by a requirement (which in Archimate is de facto an IT requirement) or
- by principles such as „we write everything in Java“.
- A very special requirement is the constraint. In Archimate it means a technical restriction or limitation.
These are the elements of Archimates Motivation extension. I used them in my projects to model some stakeholder motivation structures. I wanted to share some practical experiences so here are my findings:
- Archimate´s motivation extension provides a comprehensive set of elements to exactly model a stakeholder´s motivations and resulting requirements.
- The graphical models however loose clarity with every new element added to the view. With 3-4 stakeholders and 3-4 goals and requirements per stakeholder a model quickly is overloaded.
- You can´t share your findings anyway because stakeholder analysis is a political topic.
So why create a diagram instead of lists and spreadsheets? Of course if your thinking is very graphical you might object here. However I met people creating graphical stakeholder modelling and they all were working higher layers (entity, relation) and did not add details such as goals, drivers, etc. to their diagrams.
However analyzing and modelling a stakeholder in such detail as suggested in Archimate offers you a great way to guide your thoughts. Only if you manage to understand all elements leading to a stakeholder expressing a requirement will eventually lead to a good requirement.
As a requirements engineer your need to find out about drivers and follow your stakeholders in their assessments, goal making and requirements definition. You need to do this because you cannot rely on your stakeholder´s structured thinking and conclusion drawing. People expressing requirements are rare (because most people express solutions to their requirements). But even if thy present you requirements you simply can´t be sure that these requirements are the result of a structured and logical thinking process.
My advice: whenever you think your requirements are not sharp enough or clear enough or lack a consistent link to an overall strategy or to operational process -> try Archimate´s motivation extension. It will show you where your stakeholder´s thought processes lack consistency.
