Why not ask the stakeholders for once

Imagine you are going to an Italian restaurant. As soon as you’re there the waiter approaches you and presents you with a peperoni pizza and a glass of wine. How nice of him, but actually you were hoping for tortellini and blush wine. But the waiter doesn’t ask, he thinks he knows what you want. In reality these things don’t happen. In every restaurant you will be asked about what you want to eat or drink. Tortellini alla Panna or scampi with spinach? Blush wine from Sicily or from Tuscany? When it is the most common thing to be asked for your wishes when eating out, why are so many stakeholders in projects not asked about their goals and wishes?

Stakeholders and their Goals

A stakeholder is an entity that has a direct or indirect interest in a project and its outcome. If a stakeholder orders a pizza and gets tortellini instead, he will not be satisfied with the result. In projects there are also dissatisfied stakeholders, and the best way of increasing the amount of satisfaction of a stakeholder is through analysis of existing systems, of documents, brainstorming sessions, or code analysis. Still, there is one thing missing: the goals of our stakeholders. Knowing the goals of the stakeholders is a prerequisite for delivering results that reflect these goals.

One Project, Many Stakeholders

According to study by Swiss Q, 69,4% of the respondents think that the main reasons for insufficient requirements are incomplete or faulty sources (i.e. stakeholders).¹ What happens if you are acquainted with the goals of some of your stakeholders but not all? You make assumptions, which might work in some cases. But you probably ouldn’t want to make a habit out of it, just as you probably avoid visiting a restaurant trying to attract customers with the slogan Our pasta tastes delicious in some cases! And how do you prioritize if you are aware of only a fraction of the goals? Who decides if the waiter provides you with an entire bottle of Casa Gheller Rosato Frizzante or something else? Should he ask your company? And what about your kids?

This Italian restaurant in Berlin made a habit out of serving awesome food and wine. Highly recommended.

It’s About Time, and Timing

After he asked for your wishes the waiter serves the food and drinks you desired. A little later he inquires whether you are satisfied, and if you would like a dessert, an espresso or a digestif. He asks not only once, but multiple times. In projects, this is often not the case. But goals change, as do requirements. To know about these changes is paramount when it comes to developing fine products. Naturally, stakeholder analysis will gain importance this way and subsequently require more effort. But it would result in satisfied stakeholders, a very desirable goal.

 

Sources

[1] Trends & Benchmarks Report Schweiz, Requirements 2013, Swiss Q in Kooperation mit dem Institut für Technologiemanagement der Universität St. Gallen

Interested in a tool made for requirements management and stakeholder analysis? Please take a look.

 

 

My name is Michael Schenkel – and I believe in tools, if they are useful. Tools that support users in their work, tools that provide a common working environment for all types of roles in a project.

Tags:
2 replies
  1. Sharon Jenkins says:

    In my view too few in the “business analyst” role ask the searching, challenging questions required to find out what problem the customer is trying to solve to define what he might need, before diving into how that need might be fulfilled. A clear understanding of the stakeholders’ overall strategy, goals and objectives also supports context for the need and the potential solution. For example if the long term strategy is to reduce headcount, proposing a solution that increases headcount is probably not sensible – even if it’s a cheaper option in the short-term than a technology solution. :-)

    Reply
  2. Wilco Charité says:

    Goals, demands, desires and expectations are the first station to visit. A little typical roleplay: on day one I sometimes take the stakeholder towards the future, shake hands and congratulate him with his new system and ask him, while doing that, what do you want to do with this system, what benefits you want to meet? And the opposite, what not? After that it is to the analyst where to look further.

    Reply

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *