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.
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?
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?
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?