A Developer estimates between 70 to 100 hours for a task. Due to the urgency of the task and the developer's unavailability, a far less experienced developer is assigned to the project. The new developer takes 200 hours to complete the task.


  1. From a risk and stakeholder management perspective, what should have the PM done to mitigate and communicate the issue to senior management when realizing the initial estimate was going to get blown out of the water?

  2. Given that the original developer's estimate was more or less on track, should the excess 100 hours be applied to the project?

    A. Or should those 100 hours be eaten up by the management team (company "investment"), which would mean the project's budget sheet would 100 hours only and on track? Is this misleading and not telling the true story?

    B. Or should the full 200 hours be reflected on the project's budget sheet and let the issue logs tell the story?

  3. I have seen in smaller agencies where if a developer goes over his initial estimate, he "pays" for it. This would happen if the issue is due to the developer's fault (example: misunderstood a portion of the requirements and not seeking clarification).

    In such a scenario, the developer is told not to clock his time to the project and should spend the additional time needed to get the task done.

    Similar to 2A, is this not misleading? Rather, shouldn't it be documented in the Issue Log and Lessons Learned to prevent a future repeat of the error?

  • 6
    As a developer, if I knew 3) was being used, then I would pad my estimates for every possible contingency. This can lead to estimates like "this will take between 70 and 1500 hours". Nov 8, 2015 at 10:32
  • 4
    You're asking too many questions in one post. But the short answer is that your premise is basically flawed: the real schedule was never accurately estimated.
    – Todd A. Jacobs
    Nov 8, 2015 at 16:55
  • 3
    As a developer, if (3) were being used, I would find a new job as quickly as possible.
    – Caleb
    Nov 9, 2015 at 17:36
  • 2
    You do understand (as some of the answers point out, particularly CodeGnome's) that if you change the team you need to re-estimate? This is pretty much the main point you should take away from this question.
    – Nathan
    Nov 16, 2015 at 23:57
  • 1
    The moment a far less experienced developer is assigned to the project a red flag should be raised, all the way up to management. They would then decide how/if to proceed. Feb 29, 2016 at 12:58

2 Answers 2


Management Owns Cost-Overruns

A Developer estimates between 70 to 100 hours for a task. Due to the urgency of the task and the developer's unavailability, a far less experienced developer is assigned to the project. The new developer takes 200 hours to complete the task.

This is the agency's responsibility 100% of the time. Whether the estimate was wrong, the agency substituted task performers (thereby invalidating the original estimate), or even if the estimate was on target but deadlines were missed due to unforeseen complications, the responsibility for deliverables is always, without fail, the responsibility of the agency's management team.

Who Covers Cost Overruns

That said, who covers the cost of the overrun is a contractual issue. If the agency contracted with the client for fixed-bid deliverables, then the agency covers the cost. If the agency contracted with the client on a time and materials basis, then the client pays the additional costs. More complicated contracts have more complicated answers, but it still boils down to contract-based cost-shifting or cost-sharing in the end.

Trying to Cost-Shift to Employees

In the United States, you can't legally require an hourly employee to work for free. The rules are more complicated for exempt employees, but expecting employees of any type to eat the costs on behalf of a management decision is unreasonable and unlikely to result in long-term success for the organization.

Future Mitigations

In future, always ensure that estimates are provided by the actual task performers assigned to the work. It doesn't matter how easy or hard Developer X thinks a job will be; what matters is how much time Developer Y (who is actually doing the work) needs to complete it properly.

Furthermore, anytime you have a change in your resources, assumptions, or scheduling baseline, you should immediately raise the issue to senior management. At a minimum, the schedule should be re-estimated based on new information and current resource allocations, and management may choose to take other actions as well. These actions might include:

  1. Adding resources to the project.
  2. Adjusting project scope.
  3. Renegotiating the contract with the customer.
  4. Accepting the project risk.
  5. Transferring the project risk (e.g. buying a performance bond or outsourcing the project).

Potential solutions are limited only by the capabilities and the imagination of the leadership team. However, strategic decisions can't be made without accurate information, and ensuring that accurate information about the state of the project (including both planned and unexpected changes) is shared with senior management is an essential function of a good project manager.


There is a difference between an estimate and planning value. An estimate is a probabilistic range and should include variables such as less qualified resources doing the work plus about 1,000 other aleatory and epistemic variables. Therefore, the proper estimate should have been 70 to 200+ hours. In this range, you need to chose the planning value, say 120 hours, against which you are going to measure your performance.

Actual hours should always be tracked as accurately as possible because this feeds future estimates. If you cause your workers to stop recording hours so that it appears everything is on track, you lose valuable information. Plus your reporting is simply not honest and transparent. In the US in the federal space, it is illegal to do anything else but track work hours accurately.

There are many things a PM could do to mitigate variances but every mitigation action you deploy has its own secondary set of risks and penalties. You add resources to recover the schedule, you will pay for it in costs. If you try to remove resources to recover costs you will pay for it in your schedule and / or quality. No mitigation action comes free.

Who pays for it depends on how the work is contracted. In a seller-buyer relationship, if the contract is firm fixed price, the seller of services will pay for the overrun. If the contract is T&M or cost plus, then the buyer needs to pay for it. And if they received the proper estimate of a possibility of 200+ hours, then the buyer would have had contingency reserves to pay for it.

If you truly understand your probabilistic range in the work you do, and you choose competitive, realistic planning values--say at the P60 of the range--then this absolutely means you will underrun and overrun your work from time to time, e.g., 60% to 40% respectively as the P60 suggests. There is no shame in overrunning your work. There is shame in not having early indicators to show the overrun trend, not communicating early and often about the possibility of overrunning, and not doing the planning required to have the degree of contingency reserves necessary to pay for an overrun.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.