What can I do when I can't adjust scope, resources, or schedule and a team member wants a raise?

Question

After almost 20y programming and 5y managing I have arrived at a state to be so confused with the basics that I need help from outside!

At the project management we have 3 pillars:

1. Scope: features and functionality
2. Resources: costs and budget
3. Schedule: time

And those 3 results the product with a kind of the quality.

Most of the programmers are employed. They have a fixed time based costs. But they have hidden costs too: example producing bugs.

Managers or product owners usually have a yearly budget or a budget for feature set. Usually 2 they have at fixed from 3.

That resulting the 3rd it is adjustable somewhat or the 4th: quality Example 1 year budget for development of X feature is Y sum. At PM level is the similar: for the next Sprint in 3 week we need to do 10 backlogs, and I know the team costs ( salary)

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.

What if I can't keep him, but can't lose him, because hard to replace him (maybe takes to much time or even higher salary requests are), and the feature set need to met and the quality can't be lowered?

Answer 1

TL;DR

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):

1. Treating people like fungible assets leads to budget, scope, and scheduling problems.
2. Assigning critical work to individuals, rather than cross-functional teams, creates resource constraints.
3. Assuming a best-case scenario for schedule or budget leaves no slack in your process.
4. Treating all aspects of the iron triangle (scope, schedule, and cost) as non-negotiable leaves no options to compensate for change of any kind.
5. 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.
6. 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.)
7. 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.
8. 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.

Answer 2

Let's simplify your question down. Feature A is expected to cost $X to deliver and in reality costs $1.2X to deliver. This can be because of a raise, inflation, change in needs, or a ton of other reasons.

Let's assume for a moment that quality is a constant and you can't just release shoddy work to meet your deadlines. You mentioned the traditional iron triangle: Scope-Cost-Time. The problem we run into with programming is that Cost and Time are linked. Most of my cost (if not all) is labor and I often am working with a set team of people. You can actually increase cost for the same time by adding people (mythical man-month problems aside) but that doesn't help in your situation because you have a fixed budget. Project Management 101 tells us that fixing all three arms of the iron triangle will lead to problems, so in your situation scope must be variable.

Now usually at this point in a conversation someone says "No, the scope is fixed" and that's just silly. The iron triangle rule isn't suggesting that you shouldn't fix all three, it's saying that it isn't possible to fix all three. At some point you either run out of money, are forced to spend more money, or development stops.

So, back to your scenario, you were budgeted for $X and because of a raise it now costs $1.2X (nice raise). Your only option is to develop a version of that feature that is more limited in scope. You mention product owners, so I'll assume you are practicing Scrum. In Scrum, I would be looking to have the core needs of that feature met by $0.5X at the latest. Then everything after that is nice-to-have's. If the team didn't think they could do that, I'd tell the stakeholders that they should consider not developing it at all because there was a risk that you'd work through the money and not be able to deliver what they need. If they want to move forward after that and accept the risk, that's their call.

Answer 3

If you want a salary increase, I need to be able to justify it by showing that your your work saves costs on other elements of the project.

• Is your code of sufficient quality that the total cost of fixing bugs/technical debt is reduced?

• Is your code faster than it was last year so that I can show that the salary increase will actually save us money because you're more productive than other programmers?

Ultimately, your job is to communicate risks to the stakeholders/sponsor. If this employee doesn't get the salary increase, and that will result in the employee leaving, what is the impact to the project? You can estimate the cost to the project of replacing that employee (on the order of one year's salary between recruitment cost and retraining costs). Of course you'll have to defend the likelihood that the employee will leave. Are they actually paid (total compensation package) less than comparable employees? Are there other disincentives? (People don't leave for pay, they leave for better management/leadership).

Is it simply a good investment? Are there alternative ways to incentivize the employee?

Answer 4

I think the most affecting factor (increasing the cost) is the time, long time impacts much cost.The market maybe changes its vision and you may reach to state where you need another business requirements, what is i try to say that increasing the salaries may increase the cost but it is really small weight.Try to change the development life cycle, speed up the development by Agile, ask the team to work parallel in timed iteration, assign expert developers to higher business-value projects.