8 Ways to manage that “sticky stakeholder” that tends to trip us up every time!
Every Business Analyst would have encountered what I call ‘a sticky stakeholder’ here, as part of their journey for at least one project, right? Well, I have had these encounters occur in different shapes, contexts and levels of seriousness on a number of occasions during my career as a Business Analyst. I also consider myself quite lucky in being able to deal with these situations in a positive and constructive way…most of the time!
In terms of a Business Analyst’s role, whether it is performed in an Agile environment, a waterfall environment or simply in a regular business process change initiative, the ‘problems’ we encounter with stakeholders always somehow relate to a requirement conflict.
Depending on the nature of the requirement’s conflict, there are various ways to negotiate your way through it. The remainder of this article is educational in nature – written to help you learn an approach to deal with that ‘sticky stakeholder’ in a professional and effective manner. Requirements conflicts can occur at any stage of the project, but tends to raise its head most often during requirements validation activities…
This lesson covers an approach including practical techniques about Requirements Negotiation
What is Requirements Negotiation?
Requirements negotiation is about resolving any contradictory requirements that exist within the requirements set. It sometimes happens that different stakeholders are requesting contradictory requirements to be included in the requirements. Not only is it impossible to implement contradictory requirements in the final solution, but this also creates conflicts between different stakeholders or stakeholder groups.
If these conflicting requirements are not resolved or if the Business Analyst doesn’t seek acceptance or compromise in an agreeable fashion from the relevant stakeholders, it can lead to those stakeholders disengaging from the project and consequently cause risks around the successful implementation of a solution. It is therefore essential for the Business Analyst to always explore alternative solutions or ideas to facilitate the resolution of conflicting requirements before it becomes a stakeholder relationship dilemma for the project.
The Business Analyst should throughout the requirements related activities, continuously validate and negotiate requirements in terms of quality criteria such as completeness, accuracy and agreement by all stakeholders involved.
Requirements conflicts must be resolved in order to complete the requirements validation processes and being able to progress to the next stage of the project or iteration progression.
Conflict management with requirements consists of four tasks:
- Task 1: Conflict Identification
- Task 2: Conflict Analysis
- Task 3: Conflict Resolution
- Task 4: Documentation of the conflict resolution
Let’s now look at what each of these four tasks entail:
Task 1: Conflict Identification
It is very common that different stakeholders might be requesting requirements to be included that conflict with each other. This is simply a result of conflicting priorities between stakeholder groups and they may not realize they are requesting conflicting requirements. This is why the Business Analyst should identify these types of conflicts as soon as they arise.
An example of a conflicting requirement might be that the Human Resources stakeholder group explicitly requests to capture the age of an employee, but the Data Privacy team is saying that the age of the employee may not be captured or used in reporting.
Task 2: Conflict Analysis
The first step after identifying that a conflict in the requirements has arisen is to determine what is the nature of the conflict. There are a few common types of conflicts that occur which are closely related to the reasons they occur.
The first type of conflict is a “data conflict”. This is typically where all stakeholders are not agreeing to a requirement that is specified in a certain way. For example, the business stakeholder might want to retrieve a 1000 records at a time in real-time whereas the technology stakeholder knows this is practically impossible and not feasible.
The second type of conflict is a conflict of interest. This type of conflict arises when two or more stakeholders have different priorities or goals within their own business area, which is determining the requirements they are asking for. An example of this could be that the customer services stakeholder is asking to be able to see all personal customer data when supporting a customer on the phone where the company’s Data Privacy stakeholder is saying that the personal information of their customers are sensitive and should not be available in it’s entirety to the customer services representatives.
The third type of conflict is referred to as a “conflict of value”. This type of conflict arises when the stakeholders have different values or beliefs about what is acceptable or not acceptable. For example, one stakeholder might believe it is acceptable to ask a customer to enter their cultural heritage, as a mandatory field on the screen during an online application for a welfare payout whereas the other stakeholder might believe this is an unacceptable request and should only be an optional field for the customer to provide if they choose to.
The fourth type of conflict is referred to as relationship conflict. This is the type of personal relationship conflict where two stakeholders do not get along. This causes some emotional anxiety during requirements meetings and often these types of stakeholders will try and force requirements on to the project purely based on “winning” the conflict with another stakeholder.
The fifth type of conflict is a “structural conflict” which is when a more senior team member or stakeholder continuously rejects the requirements contributions made by their less senior colleagues.
In most cases the conflicts that arise within the context of requirements management are a combination of these different types of conflicts. It is however important to understand the different types of conflicts to be able to effectively resolve the conflicts.
Task 3: Conflict Resolution
Conflict resolution is very important for requirements negotiation because the strategy of conflict resolution has a big influence on the willingness of the people involved to continue to work together. If even just one party who was involved in a conflict resolution is not satisfied with the outcome of the resolution, the project could potentially loose stakeholder engagement, which in turn could affect the overall project in a negative way. When the conflict has been resolved in a way that truly satisfies all parties involved it could have an additional positive effect on the overall project and its stakeholder relationships. So it is very important to handle the conflict resolution effectively.
There are a few key considerations when you have to manage the resolution of a conflict:
Ensure everyone that is involved in the conflict is being engaged to resolve the conflict.
The next consideration is to choose the most appropriate conflict resolution technique…
Technique 1: Agreement
Agreement is when the stakeholders work together to negotiate a solution to the conflict. This involves discussion of each other’s views in order to try to persuade people experiencing the conflict to agree a workable solution.
Technique 2: Compromise
This technique is about using alternative parts of various solutions to try and come up with a solution that could be a compromise for all stakeholders but an acceptable solution to go forward with.
Technique 3: Voting
This technique is simply to ask all stakeholders involved with the requirements and/or the conflict itself to vote on a set of alternative options for a solution. The solution with the most votes is accepted as the resolution for the conflict.
Technique 4: Definition of Variants
This technique is a way that is selected to develop the solution where the different stakeholders can apply their own variants to the solution as parameters. This way the different stakeholders get their preferred solution implemented.
Technique 5: Overruling
This technique is aligned with the organizational hierarchy. The more senior stakeholder’s requirements or proposed solution is the one that will be taken forward as the resolution.
Technique 6: Consider all facts (CAF)
This technique is about collecting all facts and influencing factors relating to the requirements that are in conflict. These facts and factors are then prioritized in readiness to be used as an input into the “Plus-Minus-Interesting” or PMI technique.
Technique 7: Plus-Minus-Interesting or PMI
With this technique all the positive and negative repercussions of a solution alternative is being analyzed. Two categories, one for Plus and one for Minus are developed in order to list the Positives and Negatives. When a fact or factor is neither a positive nor a negative item, it is placed in the Interesting column.
Technique 8: Decision Matrix
This technique to resolve a requirements conflict comprises of a comparison matrix of all key criteria that needs to be considered against each solution alternative. By compiling this comparison information in a matrix format it often highlights which is the best solution to choose. This therefore resolves any conflicts with the collated information provided.
Task 4: Documentation of the Conflict Resolution
The final task of Resolving Conflicts in Requirements Engineering involves the documentation of the resolution agreed. It is important to document the complete detail of a conflict resolution to prevent the same conflict from arising again during the life of the project. It is also useful to document these details in case the team later realizes that the solution that was agreed as a resolution before may not be appropriate anymore. The detailed documentation will enable the team to avoid going down the same resolution path again and be informed about what the reasons were for choosing the original resolution.
Conclusion
As you would now be able to appreciate, the art (and science) of requirements conflict resolution is manageable and an important part of effective requirements management. It however remains one of those unique tasks that requires effective stakeholder relationship management skills which are developed and improved as you progress through your career as a professional Business Analyst.
Other sources used to compile this article: IREB® CPRE® Foundation Level Syllabus
Please share your individual experiences with me – I would love to hear how you have managed your stick stakeholder situations!
