Answer

Considering priorities is one of the most challenging tasks for a business analyst. Initially, the analyst collects a complete list of requirements from each stakeholder. Then, they define criteria for prioritization: business value, risks, urgency, costs, user impact, technical feasibility. To systematize, tools like the MoSCoW matrix (Must/Should/Could/Won’t) and methodologies such as Weighted Shortest Job First (WSJF), RICE, etc., are often used.

Multi-criteria analysis helps explain to stakeholders why one participant's requirements are prioritized for implementation while another's are postponed. As a result, a prioritization map is created:

| Requirement    | Stakeholder  | Impact   | Priority  | Expected Release |
|----------------|--------------|----------|-----------|------------------|
| Integration X  | TEAM_A      | High     | High      | 1.0              |
| Feature Y      | TEAM_B      | Medium   | Medium    | 1.1              |

The analyst justifies the choice based on the criteria and involves the project curator for escalations.

Key features:

• Use of transparent prioritization approaches with explanations.
• Focus on achieving a compromise between business and technical requirements.
• Open discussions of priorities with all stakeholder groups.

Trick Questions.

Can we rely solely on the opinion of the most influential stakeholder?

No. Following the opinion of one stakeholder leads to losses in other important areas of the project and potential conflicts.

Should we prioritize only based on task urgency?

No. Urgency is just one parameter; the overall impact on goals, costs, and risks needs to be assessed.

Is the final priorities map static throughout the project?

No, priorities should be flexibly reviewed as business goals change, or new constraints or information arise.

Common Mistakes and Anti-Patterns

• Unjustified acceptance of requirements without analysis and rationale.
• Ignoring a transparent procedure for revising priorities.
• Insufficient communication with teams when conflicts arise.

Real-Life Example

Negative Case: At the demand of a top manager, a poorly defined feature was added urgently to the ERP system, sidelining the needs of key users.

Pros: Increased loyalty of one stakeholder. Cons: Overall satisfaction dropped and costs for revisions increased.

Positive Case: The analyst initiated a meeting: using the MoSCoW matrix, a balanced task list was developed with the functional leaders.

Pros: Increased transparency in requirements acceptance, improved teamwork. Cons: More time was required for approval.