Opposing requirements by stakeholder groups

Hi Nenad,

I'm not sure if your real context allows you to do that, but, making a small experiment (like prototyping or mock ups) of both opposing "products" directly with possible end customers could give you lots of hacks on which requirements (wishes, desires, whatever...) to attack first.

It would also give you solid arguments to defend your position in front of the non-satisfied group and even other stakeholders.

Att,
Suleander

Create a business case for both product lines.

Requirements need to be defined in requirement document, review with all and get approvals. But before that, meeting with all stakeholders is needed to decide on priority of features. Define what will be in scope for this release and next ones.

Requirements, opposing or not, should be ranked according to value x urgency = priority. This will allow you to determine which are the high-value requirements contributing most to the business. Opposing requirement won't ever have the same value, i.e. why does one stakeholder want a white product as oppose to a grey one? Maybe it will add more value to the business? It is important to determine this, for all requirements. So basically the discussion won't be about who is right or wrong, who is senior or junior but rather about value added to the business. Maybe the end result is neither white or gray but rather red.

BTW, I respectfully disagree with Sergio re the statement that there are times when the concept of a stakeholder is not valid. Stakeholders are always valid, whether the view is project or product. A single stakeholder not managed correctly can sink a project very quickly.