Answer.

History of the issue:

In classic projects, requirements are often fixed in a "batch" without indicating priorities, which ultimately leads to an even distribution of efforts and slows down the product's time to market. There arose a need for a systematic approach to prioritization and management of conflicting interests of various stakeholders.

Problem:

Without a unified prioritization mechanism, the team's resources are used inefficiently, minimal business value is achieved, and stakeholder dissatisfaction grows.

Solution:

The systems analyst uses transparent, formalized prioritization methods:

• Surveys stakeholders, records their expectations and constraints.
• Applies methodologies (MoSCoW, Kano, Value vs. Complexity)
• Forms decomposed backlogs, aligns them with the product owner and key buyers.
• Proposes MVP or iterative product development — "quick wins" to reduce resistance and increase team engagement.

Key features:

• Always record who and why assigns a particular priority.
• Promote MVP thinking and short cycles.
• Use formal weighting methods (e.g., Impact Mapping, Value Stream Mapping).

Trick questions.

Is it correct to prioritize based on the principle of 'who shouts the loudest' (whoever is the most persistent stakeholder)?

Correct: No. The analyst should consider business value, strategic goals, and technical constraints, not just pressure from above.

Can we do without formal agreement on priorities, leaving everything to the team's discretion?

Correct: No. Without formalization, conflict is possible, important tasks may be lost, and goals may become unstable.

Should priorities be reviewed as new data/feedback comes in?

Correct: Yes. Priorities are dynamic and adjusted at each stage of design and development.

Typical mistakes and anti-patterns

• Once established, a priority is set in stone (should change as new inputs arise).
• Formalization for the sake of formalization, without agreeing on the meaning of priorities with stakeholders.
• Focusing only on one "important" client, ignoring others.

Real-life example

Negative case: The team initially implemented requests from the largest stakeholder, ignoring smaller but strategic tasks from other participants.

Pros: Gained loyalty from the strong client. Cons: Lost support from other departments, decreased overall product value.

Positive case: The analyst regularly collected value assessments from different departments through interviews, introduced MoSCoW and business evaluation of tasks, and agreed on priority changes every two weeks.

Pros: Business priorities are respected, the product flexibly responds to new inputs. Cons: Requires time for the process of coordination and data collection.