Your job as a Product Owner (PO) or Project Manager (PM) is not to have all the answers. Your job is to have a vision, and to communicate options to stakeholders and business decision-makers.
Analysis and Solutions
What if somebody is asking a salary increase? if I keep him, I have higher costs. Hence probably my budget will blow up. I can try to replace him or raise the budget.
In a long-running project, scope creep and cost creep are almost inevitable. If you didn't plan for raises or cost adjustments in a multi-year plan, then you may share some responsibility for the problem, but you don't actually own it.
The project sponsor, steering committee, or executive leadership (depending on project and company structure) actually own this risk. Whether they allowed for enough slack in the project or not, they own the risk now. So, what can you do within your role?
In most cases, you simply communicate the risk. You inform the decision-making executives of the issues, present possible solutions along with your recommendations (if any), and then let them do their jobs and make business decisions in the best interests of the company.
Management's choices include getting additional budget appropriations for the raise, cutting features that they lack resources to develop, or adjusting schedule to allow time to add new resources to the project. In the last case, Brooks' Law says that adding resources to a late project will generally make the project later, but that's still a viable choice for management to make.
In the rare case that you yourself have actual budget authority across a portfolio of projects, you can make the same set of choices or request additional funding from the financial arm of the organization. The choices don't really change; all that changes is who is responsible for selecting the most optimal strategy for the company from among the available options.
Take-Aways for the Future
Whatever decisions you make, ensure that your project does some sort of post-mortem or retrospective activity to learn from this situation. I suspect this activity, if properly done, will yield the following list (among other possible lessons learned):
- Treating people like fungible assets leads to budget, scope, and scheduling problems.
- Assigning critical work to individuals, rather than cross-functional teams, creates resource constraints.
- Assuming a best-case scenario for schedule or budget leaves no slack in your process.
- Treating all aspects of the iron triangle (scope, schedule, and cost) as non-negotiable leaves no options to compensate for change of any kind.
- Creating responsibility without authority leads to no-win situations for everyone. NB: If you are responsible for delivery, but lack authority to fully control the necessary resources for successful delivery (including personnel and budget), then this certainly describes your role.
- Using an agile framework for a fixed-scope project is usually a framework-selection error. (There are exceptions, but this is probably not one of them.)
- No matter what framework you select, you can't inflexibly meet scope, schedule, cost, and quality goals all at the same time. This creates business risk, and management owns that.
- Risk must be accepted, controlled, or transferred. Senior management must decide how they will own all residual risk.
Everyone involved in the project must do some soul-searching about how they contributed to the current situation. There are certainly solutions, but none of them will come without cost (in either dollars or project risk). The key is to understand how the current situation arose without looking to affix blame, and then to take concrete steps to mitigate the situation now and in the future.